[Tikzdevice-bugs] Two subsequent color def?
Charlie Sharpsteen
chuck at sharpsteen.net
Fri Apr 15 18:50:49 CEST 2011
On Fri, Apr 15, 2011 at 1:29 AM, Matthieu Stigler <
matthieu.stigler at gmail.com> wrote:
> Hi
>
> I notice that the .tex generated contains many lines where the same color
is
> defined twice:
>
> \definecolor[named]{drawColor}{rgb}{0.66,0.43,0.04}
>
> \definecolor[named]{drawColor}{rgb}{0.00,0.00,1.00}
>
>
> While the second lines is the one I wanted, the first contains a color
that
> I did not specify (in my case a brown). Where does it come from ? Can one
> prevent theis supplementary color to come?
>
> Thanks!!
Hi Matthieu,
The code that is responsible for handling style definitions, such as draw
colors, fill colors, etc, is fairly old. Sometimes it defines colors that
do not end up being used. In many places it also defines the same color
multiple times which is inefficient. The style definition code does need to
be re-worked to address these issues---but as long as the right colors end
up being used for plot elements it is not causing any bugs and is just
making the TeX compiler work a little harder.
It would be interesting to see the performance effects of some changes on
the runtime and memory use of TeX:
- Ensuring that each color only gets defined once and gets assigned a
unique name.
- Or, inlining each color definition into the path that it affects.
Right now, the tikzDevice receives graphics commands from R, translates them
to TikZ code and immediately writes the result to a file. If we were to
store the graphics commands in a data structure and wait until the device
was closed to write the code to the file, there are all sorts of
interesting optimizations that could be done---similar to what a compiler
does when it walks an abstract syntax tree and eliminates dead or
inefficient code before writing out it's results.
But that sort of work would require a lot of changes to the tikzDevice
internals.
-Charlie
More information about the Tikzdevice-bugs
mailing list