Skip to content
This repository was archived by the owner on Sep 23, 2018. It is now read-only.

Roadmap

Jump to bottom
Sharpie edited this page Dec 6, 2011 · 19 revisions

This is a rough plan for the future of the tikzDevice up to version 1.0

0.6

See milestone v0.6 for development status.

  • Support for new graphics primitives that were added after R 2.10.x

    R 2.11.x

    R 2.12.x

    • Polypaths (polygons w/ holes)

  • Initial UTF8 Support

    • Get UTF8 working in some preliminary way
    • Sort out all the hairy details associated with accepting this kind of input (metrics in particular)

  • Refactor package support systems

    • Migrate documentation to Roxygen to decrease the distance between the code and the docs.

    • Re-write tests using the test_that package so that changes which break package functionality can be discovered faster issue 18

0.7

See milestone v0.7 for development status.

Support for all LaTeX engines

  • pdflatex DONE!
  • xelatex (native UTF8 support) DONE!
  • lualatex (native UTF8 support) See issue #28.

Investigate ways to speed up metrics calculations

As much ~50% of the time involved in producing a figure using tikz can be spent inside the metrics calculation routines. Some ideas for speeding this up:

  • Produce a .fmt file (a.k.a. precompiled preamble) for each graphics device. This may drop the amount of time it takes a TeX engine to start up.

  • Instead of making a system call to TeX each time a calculation needs to be done, start one instance of the TeX engine per graphics device and use interprocess communication to extract metrics from it.

    This probably won't work. The problem is that in order to get real call and response communication with a subprogram, the caller has to communicate with it via a pseudo-terminal or some sort of console device on Windows. The logistics of doing this reliably in a cross-platform manner are mind-bogglingly difficult. As far as I know, noone has even made a cross platform library that solves this problem.

Some detailed profiling is needed to determine the best course of action.

Support for TikZ annotations in Grid Graphics

Two step process for adding support for tikzAnnotate and tikzCoord in Grid-based graphics:

  • Add functionality for converting Grid coordinates to device coordinates and for representing TikZ annotations as Grid grob objects. Work progressing in issue #37.

  • Add functionality for adding annotations to GGplot graphics. This is difficult as GGplot2 has an additional level of coordinate system manipulation that exists above the Grid coordinate system.

0.8

See milestone v0.8 for development status.

Support for all TeX dialects

In addition to LaTeX, add support for:

  • plain TeX issue #34

  • ConTeXt issue #5

  • More R functions for outputting custom TikZ code?

  • Raster "screen shots" (Issue 9)?

0.9

  • Incorporate alien technology?

  • Convince Kanye West to do a rap about us.

1.0

  • Remove beta flag.
  • Clothing line.
  • tikzDevice fruit snacks.
  • Prepare for the development of tikzDevice v. 2.0: Electric Boogaloo, which will support breakdancing as a viable means of entering UTF-8 encoded information.
  • Profit!

Misc

Ideas that don't have a home yet.

Support Moar Graphics Packages

Possibilities are:

  • METAPOST: Already mostly implemented in the experimental/metapost branch

  • Asymptote: Would be fun because it can embed 3D imagry into TeX documents.

  • PSTricks: Possibly. But I'm not getting a warm fuzzy feeling about this one at the moment.

Spot Color Support

Would be great for authors who want to take advantage of two-color printing. Experimental implementation in the METAPOST branch. Difficult because it requires dodging around the R color handling system.

Clone this wiki locally