[Tikzdevice-bugs] Two subsequent color def?

[Cameron Bracken]

On Fri, Apr 15, 2011 at 10:50 AM, Charlie Sharpsteen
<chuck at sharpsteen.net> wrote:
> 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.

I think I tried to do this originally but was eventually pushed toward
the current behavior because of scoping. If a color is defined in a
scope, then it will get destroyed when the scope is ended.

>
>   - 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.

And all of it in C, bleh. Unless we did everything as callbacks like
the RGraphicsDevice package (http://www.omegahat.org/RGraphicsDevice/)
implements. In that case writing things to an R object would be
trivial.


-Cameron