sharpie / rtikzdevice Goto Github PK
View Code? Open in Web Editor NEWA R package for producing graphics output as PGF/TikZ code for use in TeX documents.
A R package for producing graphics output as PGF/TikZ code for use in TeX documents.
TikZ can produce output that is friendly for both plain TeX and ConTeXt. Look into supporting these systems.
On some systems, systems calls to latex return warnings of a non-zero exit status since we use \@@end
to stop the process. Warnings look like:
running command '/usr/texbin/latex -interaction=batchmode -output-directory /var/folders/Qs/Qs80pcjVHlm3bMdyHfy2W++++TI/-Tmp-//RtmpK8pfqt /var/folders/Qs/Qs80pcjVHlm3bMdyHfy2W++++TI/-Tmp-//RtmpK8pfqt/tikzStringWidthCalc.tex 2>/dev/null' had status 1
R CMD CHECK is throwing warning messages on CRAN for the Solaris operating system. This is the explanation and bug report from Brian Ripley:
It looks like you have not consulted the Value section of the current help page for Sys.which:
Value:
A character vector of the same length as ‘names’, named by
‘names’. The elements are either the full path to the
executable/script or some indication that no executable of that
name was found. Typically the indication is ‘""’, but this does
depend on the OS (and is a message on Solaris).So you need an additional check that the result actually is a command (e.g. via file.exists).
Can we please have an update addressing this.
(It is likely that Sys.which will be changed in future to incorporate this check, but package changes are still needed to work with current and earlier versions of R.)
It would be nice if detailed error is presented to end user instead of generic one. I copy/pasted part of my pgfSweave document and forgot that I specified prefix.string option with folder in it. It took me a while to realize that I don't have output folder for tikz result.
Error in tikzDevice::tikz(file = paste(chunkprefix, "tikz", sep = "."), :
TikZ device setup was unsuccessful!
Grid-based graphics tend to produce tons of useless clipping (that is, clipping scopes within which nothing is drawn). Even just calling grid.newpage
by itself...
suppressPackageStartupMessages({
library(tikzDevice)
library(grid)
})
tikz("grid1.tex", standAlone=TRUE, width=2, height=2)
grid.newpage()
invisible(dev.off())
produces a picture environment containing two useless empty clipping scopes:
\begin{tikzpicture}[x=1pt,y=1pt]
\definecolor[named]{drawColor}{rgb}{0.00,0.00,0.00}
\definecolor[named]{fillColor}{rgb}{1.00,1.00,1.00}
\fill[color=fillColor,fill opacity=0.00,] (0,0) rectangle (144.54,144.54);
\begin{scope}
\path[clip] ( 0.00, 0.00) rectangle (144.54,144.54);
\end{scope}
\begin{scope}
\path[clip] ( 0.00, 0.00) rectangle (144.54,144.54);
\end{scope}
\end{tikzpicture}
Doing anything more complicated can produce dozens of these useless clips: for instance, the output of
library(ggplot2)
tikz("grid1.tex", standAlone=TRUE, width=2, height=2)
qplot(1, 1, geom="point")
invisible(dev.off())
contains 157 of them.
This is, strictly speaking, grid's fault rather than tikzDevice's, but I can imagine that it might be easier to fix at the device level. Bonus points for also eliminating clipping paths that are useless not because nothing is drawn, but because everything that is drawn is strictly inside the clip.
It would be nice to store the log files of failed runs in a list, say the last 5 bad ones. Then instead of dumping pages of text to the console, we would just print an error message and say something like "run tikz_showlog
to see the logfile".
This could also be extended to keeping every log if the device is built in debug mode which would help with package development.
The tikz testsuite is getting a little bit long in the tooth. Specifically, two issues related to R 2.12.x should have been caught by the testsuite which would have removed the need for a 0.5.3 release:
Proposal:
Migrate the test scripts to a unit testing framework, such as Hadley's test_that
.
Benefits:
test_that
provides excellent capabilities for isolating tests so that the actions and results of one test do not affect the execution of another test.test_that
contains failure checks. Tests can be designed to fail and the framework checks to see that the expected error/warning message is generated.Comments?
The footer text passed to tikz
is never inserted into the output. Don't know if we ever used the footer since the text wasn't even properly stored at the C level until commit df8b27b.
Anyway, since this is an advertised option, it should be actually implemented.
As reported by Baptiste Auguie:
A simple plot of several lines with various thicknesses using grid
graphics:
require(grid)
require(tikzDevice)
tikz('line_width.tex', standAlone = TRUE)
plot.new()
segments(0,seq(-1,1,by=0.2),1,seq(-1,1,by=0.2),lwd=seq(0.2,by=0.2,length=11))
dev.off()
Produces output with far less variation in line thickness than the lwd
parameter would suggest:
\draw[color=drawColor,line cap=round,line join=round,fill opacity=0.00,] ( 65.18, 2.61) -- (464.71, 2.61);
\draw[color=drawColor,line cap=round,line join=round,fill opacity=0.00,] ( 65.18, 75.85) -- (464.71, 75.85);
\draw[color=drawColor,line cap=round,line join=round,fill opacity=0.00,] ( 65.18,149.09) -- (464.71,149.09);
\draw[color=drawColor,line cap=round,line join=round,fill opacity=0.00,] ( 65.18,222.33) -- (464.71,222.33);
\draw[color=drawColor,line cap=round,line join=round,fill opacity=0.00,] ( 65.18,295.56) -- (464.71,295.56);
\draw[color=drawColor,line width= 0.8pt,line cap=round,line join=round,fill opacity=0.00,] ( 65.18,368.80) -- (464.71,368.80);
\draw[color=drawColor,line width= 0.8pt,line cap=round,line join=round,fill opacity=0.00,] ( 65.18,442.04) -- (464.71,442.04);
The parameter values passed to TikZ_Line
in plotParams->lwd
are:
1.0000
1.2000
1.4000
1.6000
1.8000
2.0000
2.2000
Reported in issue 15. Apparently only happens when Sweave is invoked from Rgui or Rscript.
Appears to be related to the creation of temporary metrics dictionaries:
5 : echo term verbatim tikz sanitize (label=mv_fig)
Creating temporary TikZ metrics dictionary at:
C:\DOCUME~1\user\LOCALS~1\Temp\Rtmp52vg3A/tikzMetricsDictionary
Error: no function to return from, jumping to top level
Execution halted
Files to reproduce located at:
http://www.sendspace.com/file/obbg5h
EDIT: Changed the name of the issue because it is not specific to Sweave
Running the entire graphics testsuite can be a pain when you just want to see if a given category of graphs is broken or fixed yet. Waiting for all the other graphs to run is a waste of time.
Should be easy to do by adding a tag field to the test structure and running the test list through Filter
in test_graphics.R
:
if (!is.null(tags_to_test)) {
test_graphs <- Filter(function(graph){any(graph$tags %in% tags_to_test)}, test_graphs)
}
Where tags_to_test
could be a list of tags specified on the command line.
Use ImageMagick's compare
utility to check the results of the testsuite against a "control" PDF that we know is a correct version of the test graph. This way, if we break some metric calculation or drawing routine compare
will notice a large difference and flag the test as failed. This addition would also mean that the results of the testsuite don't have to be manually inspected before a release to see if something went funky.
The C code in the tikzDevice has grown rather organically over the last few releases and lots of things have simply been dumped into it. The code should be reviewed to ensure comments are still valid, reorganized to make sure functions are laid out in a logical order and possibly improved by combining/eliminating unused or duplicated functions and replacing some common operations with Preprocessor macros.
A good target for replacement by a macro would be the operation that grabs the tikzDevice namespace:
#define TIKZ_NAMESPACE eval(lang2(install("getNamespace"), mkString("tikzDevice")), R_GlobalEnv)
The example of using bareBones
in the Vignette is pretty uninspiring. If I recall, it was added at the eleventh hour before the first version shipped just to get something in there.
I have a better example from my capstone project that uses tikzAnnotate
to insert named coordinates into the plot of a map and then includes the resulting bareBones
output into a larger TikZ image that attaches labels and arrows to the coordinates. Something like this would be a lot better than the lame Brownian Motion example (it is still impressive that TIkZ can enable TeX to calculate a Brownian though).
There is a .net in the address of r-forge when it should be .org. So:
install.packages( 'tikzDevice',
repos='http://r-forge.r-project.org' )
It would be nice to drop coordinates and annotations into grid graphics. For base graphics, the grconvertX
and grconvertY
functions are used. However, grid graphics are a bit different because the actual location of a point is unknown until it is rendered to a viewport --- not technically true, locations in a viewport are unknown until it is pushed to a graphics device.
A possible solution could be to provide an "annotation object" that could be combined with other grid
objects and printed to viewports. Upon printing, this annotation object would insert information at the appropriate point.
Improve the testthat
output with a better reporter. This gist contains a start.
Some nice features to have:
.tex
files such as metric calculations.I have two quick suggestions for zzz.R since I see it is slightly slow to load tikzDevice:
require(filehash)
as long as it is stated in DESCRIPTION.Rprofile
), tikzDevice may just go with them and do not go through the process of checking pdflatex and xelatexFigure out how to do UTF8 support using pdftex
in a sane way. pdftex
is the garden variety of TeX that everyone has and uses to power latex
and pdflatex
.
The changes implemented in the fontsize branch provide better handling of string widths-- especially in ggplot2 graphics. However I just noticed an issue with the placement of exponents arising from ggplot2 scales such as:
plot_x_log10()
I still need to make a test case the definitively isolates this problem.
TikZ can produce output that is friendly for both plain TeX and ConTeXt. Look into supporting these systems.
The Vignette contains many sections that are essentially duplicates of the manual pages for various functions --- specifically sections 3 and 4.1 -- 4.4. It is a pain to ensure both copies of this information are in sync with each other, so perhaps they should be removed.
Another option would be to figure out if it is somehow possible to attach the PDF versions of the manpage as an Appendix to the vignette thus keeping the functionality of the Vignette as a "one stop" reference for the package.
Similar to the onefile
option to the pdf()
device.
This could be useful for micro-managing how plots are arranged in a tex document yet still generating them in a loop. May be especially useful when using Sweave.
So users have access to package changes from the news
function.
I am rather new to R so forgive me if this is obviously stupid. Using the following example with tikzDevice 0.6.2:
library(tikzDevice)
x <- 1:10
y <- sin(x)
tikz("test.tex",standAlone=TRUE)
plot(x,y)
dev.off()
pdf("test2.pdf")
plot(x,y)
dev.off()
q()
I get rather equal distances of the tick labels to the ticks for x and y axes. The tikzdevice output (when run through pdflatex) has different spacings when comparing x and y axis. The space between ticks and labels of the x axis are larger than for the y axis. Is this expected? What can I do?
There are a lot of places where the tikzDevice version number and datestamp are used in source code, documentation, etc. Updating these version numbers should be made automagic by good use of git tag -a
and git describe
.
This involves fleshing out the TikZ_Cap()
function which is currently a stub in version 0.5.0
.
Following changes to warnings/errors concerning unicode:
If XeLaTeX doesn't have a glyph for a given character it will print the following log message:
Missing character: There is no α in font cmr10!
getMetricsFromLatex
should detect these messages in the log file and:
Change pdftex
unicode error to a warning. This error is currently thrown because it is very difficult to determine which packages need to be loaded in order to provide glyphs for a given Unicode character (XeTeX resolves this with better support for fonts). However, many users will know what to place in tikzLatexPackages
in order to make things work. Therefore, the error should be changed to a warning that:
xetex
or manually edit tikzLatexPackages
for best results.R 2.14.0 is adding some new functions to the graphics API. From Brian Ripley:
Secondly, there is the opportunity to add some new facilities in R-devel,
to be released as R 2.14.0 on October 31. These are the componentsdevHoldFlush()
haveTransparency
haveTransparentBg
haveCapture
haveRaster
haveLocatordocumented in src/include/GraphicsDevice.h. (If you include them, you
should condiitionalize onif R_GE_version >= 9
endif
.) Screen devices (cairo*, JavaGD ...) will benefit from implementing
dev.hold/dev.flush (see their help page),
I dont believe there is a way to specify the background border color but tikzDevice uses it nontheless when drawing the background rectangle. The result is not visible on a white background but is when using different colors. See the original report:
I am trying to get a plot with the same background color than the background color of the LaTeX page. However, it seems that tikzDevice is introducing by default a command:
\definecolor[named]{fillColor}{rgb}{1.00,1.00,1.00}
\fill[color=fillColor,] (0,0) rectangle (238.49,238.49);
I searched around to see how to remove this line... did not find... is there any way to remove it?
I am using R 2.13 and tikzDevice 0.6.1 (see below for full sesionInfo).
Here would be full reproducible code:
library(ggplot2)
library(tikzDevice)
part1_main70bis<-rgb(0.05,0.4,0.5,maxColorValue=1)
theme_update(
plot.background = theme_rect(fill = part1_main70bis, colour=part1_main70bis)
)
options(tikzLatexPackages=c("\\usepackage{tikz}","\\usepackage{color}\n\\definecolor{part1}{rgb}{0.05,0.4,0.5}\n\\pagecolor{part1}\n"))
tikz(standAlone=TRUE)
qplot(1,1)
dev.off()
It is this white border I would like to remove, do you see it? The guilty line is this one (line 13):
% \fillcolor=fillColor, rectangle (505.89,505.89);Thanks!
Matthieu
> sessionInfo()
R version 2.13.1 (2011-07-08)
Platform: x86_64-pc-linux-gnu (64-bit)
locale:
[1] LC_CTYPE=fr_FR.UTF-8 LC_NUMERIC=C
[3] LC_TIME=fr_FR.UTF-8 LC_COLLATE=fr_FR.UTF-8
[5] LC_MONETARY=fr_FR.UTF-8 LC_MESSAGES=en_US.utf8
[7] LC_PAPER=fr_FR.UTF-8 LC_NAME=fr_FR.UTF-8
[9] LC_ADDRESS=fr_FR.UTF-8 LC_TELEPHONE=fr_FR.UTF-8
[11] LC_MEASUREMENT=fr_FR.UTF-8 LC_IDENTIFICATION=fr_FR.UTF-8
attached base packages:
[1] grid stats graphics grDevices utils datasets methods
[8] base
other attached packages:
[1] ggplot2_0.8.9 proto_0.3-9.2 reshape_0.8.4 plyr_1.6
[5] tikzDevice_0.6.1 filehash_2.2 rkward_0.5.6
loaded via a namespace (and not attached):
[1] tools_2.13.1
Currently figure sizes must be specified in inches. This should be generalized to at least include centimeters.
source('http://addictedtor.free.fr/graphiques/sources/source_122.R')
The function diagwl from the climatol package calls plot.new() which creates a new tikzpicture; then it calls par() which closes the tikzpicture without creating any content but throws in a \end{scope}, causing compilation to fail.
This is the offending chunk:
\begin{tikzpicture}[x=1pt,y=1pt]
\draw[color=white,opacity=0] (0,0) rectangle (505.89,505.89);
\end{scope}
\end{tikzpicture}
A tikzpicture should NOT be created when there is not content to put in. pdf() does not create a blank page here so we should not.
I'm using lattice to produce plots. I decided to give a try to sanitize text strings. However resulting tikz files miss all my text at all :(
Whenever a color to be used is a shade of gray (r=g=b), tikzDevice should define it with the {gray} model rather than the {rgb} model.
The latest version of the tikzDevice, 0.5.1, was checked against R 2.12.0 while that release of R was in development. This was in order to verify that the the implementation of a stub function for polypath()
worked correctly.
The SVN version of R 2.12.0 used in these tests was r52686
. When R CMD check
is run on 0.5.1 using this version everything passes. However, as shown by:
http://cran.r-project.org/web/checks/check_results_tikzDevice.html
R CMD check produces some pretty gnarly looking errors when compiling the vignette using the latest builds of R 2.12.0 or 2.13.0.
Apparently something happened to R since r52686
that could be causing major issues with our package. Stay tuned.
This was requested by a user a while back, It would likely require a some restructuring of the C code. Usage would be something like ggplot2:
p <- tikz(raw=TRUE)
plot(...)
dev.off()
Or
tikz(raw=TRUE,object='p')
plot(...)
dev.off()
then the user could
print(p)
to print to the screen or
print(p,file='foo.tex')
to print to a file.
The second method would probably be more feasible.
This involves fleshing out the TikZ_Raster()
function which is currently a stub in version 0.5.0.
Adding a useDynLib
statement to the NAMESPACE file is cleaner than calling library.dynam
inside of .onLoad
in zzz.R
. In addition, we can explicitly declare which C-level routines should be visible to R:
Appears there is some issue preventing the vignette from building. This is blocking binary builds on CRAN although it is being flagged as a NOTE rather than a ERROR. Just ran into it for the first time when prepping the r-forge
branch for a release. Gist of log here.
Coincidentally, Murphy's law is goddamn spooky. I ran this operation for three different versions of R on 3 different platforms and the bug doesn't show up until AFTER the CRAN release? WTF!?!
Now that XeTeX is officially supported by the tikzDevice. It should be easy to add support for LuaTeX as it is also Unicode-based and can use many of the advanced font handling packages available to XeTeX.
A key difference between XeTeX and LuaTeX is that XeTeX is DVI-based (routing it's output through xdvipdfmx
) and therefore cannot use some packages that require a direct route to PDF. On the other hand, LuaTeX is the official sucessor to PdfTeX and therefore renders directly to PDF.
With the default bg="transparent", we get this at the beginning of every tikzDevice picture:
\fill[color=fillColor,fill opacity=0.00,] (0,0) rectangle (width, height);
This command's only effect is to bulk up the generated PDF. It should not be emitted at all. In general, \fill[...,fill opacity=0,...]
should never be generated. A closely related phenomenon is
\draw[fill=fillColor, draw opacity=0.00,] ... ;
which should be optimized to
\fill[color=fillColor] ...;
(And even these are only special cases of the general observation that {fill/draw} opacity=0
and {fill/draw} opacity=1
should never appear in the generated drawing.)
In commit 00b8efb5f3a
> tikz()
Warning: stack imbalance in '.External', 8 then 9
Warning: stack imbalance in '{', 6 then 7
Likely something in Print_Tikz_Header
The Vignette needs to be updated before the release of R 2.13.0 on April 16. Known issues:
2.13.0 requires that Vignettes containing non-ASCII characters load the LaTeX inputenc
package and declare their encoding. As I recall, loading inputenc
causes fonts to be horribly pixelated when scaled on certain platforms, such as Windows. Wierd bug.
Possible Solutions:
comp.text.tex
and tex.stackexchange.com and figure out what causes this inputenc
bug and how to avoid it.I'm leaning towards option 2 as a quick fix, unless the XeTeX additions currently under review add more UTF8 content to the Vignette.
Updates to the Sweave internals have broken the Mother of All R hacks. Again. Need to make a new driver patch and update patchSweave.R
.
The R Graphics API Version will be bumped again in 2.12.0 to support "polygons with holes". See the following post by Paul Murrell for details:
http://r.789695.n4.nabble.com/support-for-polygons-with-holes-td2270301.html#a2270301
Constructs such as
\begin{tikzpicture}[x=1pt,y=1pt]
\definecolor[named]{drawColor}{rgb}{0.00,0.00,0.00}
\definecolor[named]{fillColor}{rgb}{1.00,1.00,1.00}
\begin{scope}
\path[clip] ( 0.00, 0.00) rectangle (144.54,144.54);
\definecolor[named]{fillColor}{rgb}{1.00,1.00,1.00}
\fill[color=fillColor] ( 0.00, 0.00) rectangle (144.54,144.54);
\end{scope}
\begin{scope}
\path[clip] ( 0.00, 0.00) rectangle (144.54,144.54);
\definecolor[named]{drawColor}{rgb}{0.00,0.00,0.00}
\node[color=drawColor,anchor=base,inner sep=0pt, outer sep=0pt, scale= 1.20] at ( 73.39, 9.03) {1};
\end{scope}
\begin{scope}
\path[clip] ( 0.00, 0.00) rectangle (144.54,144.54);
\definecolor[named]{drawColor}{rgb}{0.00,0.00,0.00}
\node[rotate= 90.00,color=drawColor,anchor=base,inner sep=0pt, outer sep=0pt, scale= 1.20] at ( 17.30, 76.40) {1};
\end{scope}
\end{tikzpicture}
contain a great deal of repetitive clipping and color specification. It would be better to emit
\begin{tikzpicture}[x=1pt,y=1pt]
\definecolor[named]{drawColor}{rgb}{0.00,0.00,0.00}
\definecolor[named]{fillColor}{rgb}{1.00,1.00,1.00}
\path[clip] ( 0.00, 0.00) rectangle (144.54,144.54);
\fill[color=fillColor] ( 0.00, 0.00) rectangle (144.54,144.54);
\node[color=drawColor,anchor=base,inner sep=0pt, outer sep=0pt, scale= 1.20] at ( 73.39, 9.03) {1};
\node[rotate= 90.00,color=drawColor,anchor=base,inner sep=0pt, outer sep=0pt, scale= 1.20] at ( 17.30, 76.40) {1};
\end{tikzpicture}
or, even better, noticing that the colors used are black and white,
\begin{tikzpicture}[x=1pt,y=1pt]
\path[clip] ( 0.00, 0.00) rectangle (144.54,144.54);
\fill[color=white] ( 0.00, 0.00) rectangle (144.54,144.54);
\node[anchor=base,inner sep=0pt, outer sep=0pt, scale= 1.20]
at ( 73.39, 9.03) {1};
\node[rotate= 90.00,anchor=base,inner sep=0pt, outer sep=0pt, scale= 1.20]
at ( 17.30, 76.40) {1};
\end{tikzpicture}
Once Annotations for grid graphics is completed TikZ annotations will be available as Grid grob
objects and would be nice to provide GGplot graphics with easy access to TikZ annotation using a custom geom
object.
Something like the way geom_text
works:
p <- qplot(wt, mpg, data = mtcars) + geom_tikz(1,1, 'node', "wow!")
print(p)
The actual semantics of geom_tikz
can be worked out later. The first step will be to ensure GGplot coordinate transformations are taken into account when placing annotations.
The following code demonstrates the bug:
tikz("try.tex", standAlone=TRUE)
op<-par(bg=11,bty="n", cex=2, mar=c(3,4,1,2)+0.1)
x <- runif(100)
plot(x, las=1, yaxt="n",tcl=0, ann=F, type="l", lwd=2, col="blue")
grid(col="white", lty="solid", nx=NA, ny=NULL, lwd=2)
lines(x, col="blue", lwd=2)
axis(1, tcl=0, labels=FALSE, col="black", lwd=1, at=as.Date(c("1970-01-01","2011-01-01")))
axis(2, las=2, tick=FALSE)
par(op)
dev.off()
There should be a green background but it is white. In addition, changing the tikz 'bg' parameter actually has no effect, it is never actually used in the code.
The hack in question is used by the vignette to beat some flexibility into Sweave. Recently, the code had to be redone in order to accomodate changes to Sweave in R 2.12.0.
The result has grown even more monstrous as it checks the R SVN revision number in order to determine which version of the hack to apply---eventually the hack will become a maintenance nightmare.
There is hope in that Romain Francois recently submitted a patch to R-devel that will allow Vignettes to load their own custom Sweave drivers---it is not in R-trunk yet but hopefully it will make it.
tikzDevice.c:1425: warning: initialization discards qualifiers from pointer target type
This is due to mismatches of char *
with const char *
. Need to fix before v0.5 on CRAN.
Plotmath expressions are not handled really at all by tikzDevice; anything that uses %operators%
causes the string sanitizer to barf, Greek letters show up as the Latin letter corresponding to the position of the character in the Adobe Symbol font, and those are just the problems I've noticed so far.
Ideal behavior would be for the device to translate plotmath into proper TeX math expressions, but I've no idea how difficult that would be.
Concrete test case 1:
suppressPackageStartupMessages(library(tikzDevice))
tikz("plotmath.tex", standAlone=TRUE, width=1, height=1)
par(mai=c(0,0,0,0))
plot.new()
# the next two lines should produce identical (but for positioning)
# draw commands in the output, but they don't
text(.5, .6, expression(alpha+beta+gamma+delta))
text(.5, .4, "$\\alpha+\\beta+\\gamma+\\delta$")
invisible(dev.off())
Concrete test case 2:
suppressPackageStartupMessages(library(tikzDevice))
tikz("plotmath2.tex", standAlone=TRUE, sanitize=TRUE)
demo(plotmath)
invisible(dev.off())
-->
> draw.plotmath.cell(expression(x %+-% y), i, nr); i <- i + 1
Error in function (string, strip = getOption("tikzSanitizeCharacters"), :
Unable to sanitize string, you may be trying to pass in an unsupported symbol
To be clear, I see this as a feature request rather than a bug, and I do have a workaround (edit all my graphics and replace plotmath with proper TeX math).
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.