Re: pslatex.trm: useless \colorgray into tex file

[Daniel J S. <dan...@ie...>]

Ethan A Merritt wrote:
> On Wednesday 05 July 2006 10:59 pm, Daniel J Sebald wrote:
> 
>>>>There seems to be a bug: EPSLATEX_set_color() produces many many 
>>>>\colorgray{} commands into output .tex file, which are completely useless, 
>>>>because color for filled rectangles is set directly in .eps file.
>>
>>Note my email from a couple days ago.  
>>Perhaps begin by looking at this strange defined-out line of code: 
> 
> 
> Wrong driver. We're talking about the *.tex output from pslatex.trm

True.  However, I've a feeling that post.trm and pslatex.trm behave in a similar fashion, and if pslatex.trm goes down the path post.trm appears to have gone, it could end up a similarly tangled web.



> 
>>#if 0
>>    /*  In order to make 'PS_linewidth' work properly, I need to comment
>>     *  this line out.  Especially in combination with the line width
>>     *  extension of the `set arrow` command this is necessary.
>>     *  Can we live with that drawback?  (JFi)
>>     */
>>    if (PS_linetype_last == linetype) return;
>>#endif
> 
> 
> But I agree that this comment is probably obsolete.
> I tested re-enabling this test quite a while back, and found no problems.
> But also it didn't produce any substantial saving in the output file size,
> so I left it alone.  We can look at it again later.

It's noticable.  Not huge, say 15-20% in that eg7.plt example.  But the bottom line is that there seems to be a lot of unnecessary repetition in PostScript output instructions and pslatex instructions.

Seeing this in a few places makes me worry.

    PS_linewidth_last = PS_linetype_last =  -1; /* force next linetype change */

It isn't the fact that there are some "state variables", it is where they are placed, e.g., after doing _point() or _fillbox().

I wonder if it is some property of PostScript interpretation that is driving that, or someone has used this as an inappropriate solution to a problem.

...

Thinking of what you and I looked at the other week, Ethan, (that issue with needing the palette at the start of every page otherwise jumping around nonlinearly in "gv" produces incorrect results) I wonder if there are similar problems with LT0, etc... That is, if it isn't the case that LT? were not written every time before line draw.

It seems to me that the PostScript like drivers should have a whole group of "state variables" to account for the fact that we don't want to put commands on a PS page unless needed.  Say for example, if the page doesn't need a palette, then we don't want a palette command at the start of that page.  So, let's say we have

   bool page_palette_specified;
   bool page_linetype_specified;
   bool page_linewidth_specified;
   etc.

Whenever, PS_graphic() is called, it sets

   page_palette_specified = 0;
   page_linetype_specified = 0;
   page_linewidth_specified = 0;
   etc.

Then, at the start of every terminal routine there is a call to some routine, say

   require_property(PALETTE | LINETYPE);

and require_property will check if those have been specified yet, if not call the appropriate routines with the previous contents.

Without going into too much more detail, I hope I've gotten my point across, which is the idea of having an organized set of state variables.

Right now, it seems the concept is to count on the core routine having called the necessary property beforehand and creatively using  PS_linewidth_last = PS_linetype_last =  -1; and such.  I think state variables would be much more effective.  In some sense, that is what PS_linewidth_last, etc. are, state variables, but it approaching things from an unusual way.


>>Also, could this bug have something to do with bug report: 
>>[ 1512210 ] buffer overflow using pgnuplot
> 
> 
> Nope.

I'm not so sure...  I don't have a good feeling about this one.

Dan