Re: Fwd: [ gnuplot-Bugs-1517932 ] epslatex terminal spews useless output

[Ethan A M. <merritt@u.washington.edu>]

On Saturday 08 July 2006 02:21 am, Petr Mikulik wrote:
> I'm enclosing eg7.zip, with 1.tex+1.eps as generated by eg7.gp script, and 
> the same output into ps terminal 2.eps, wherefrom I've removed the color 
> surface part (see "@@@ Petr" in 2.eps) to demonstrate those many
>   LT0
>   3775 3671 M
>   stroke
> have no effect.

As Dan Sebald pointed out, these are caused by the following section
in post.trm|

  #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

This comment is almost certainly out of date, as predates version 3.5. 
The code has changed radically since then!

"make check" and all.dem seem to work properly if the redundancy test is
restored, and I am agreeable to doing so. This reduces the size of the 
all.dem postscript output by 3%.


Related issue
=============

More annoying to me are all the output lines
  Blacktext { gsave 0 setgray } if
  <something>
  Blacktext { grestore } if
These amount to 4.6% of the output file size from all.dem, and their only
utility is to allow users to toggle the "blacktext" option in the output
file rather than as a 'set term' option.  Is this worth the cost?

At the least, perhaps we should define shorthand forms in the prolog:
  /BTon { Blacktext { gsave 0 setgray } if } def
  /Btoff { Blacktext { grestore } if } def


> Further 2.eps shows that gnuplot core is generating many sequent numbers 
> like:
> 
> .4891 g .4673 g .4462 g .4259 g .4068 g .3893 g .3735 g .3599 g .3485 g 
> .3397 g ...
> 
> I think that these two excessivenesses should be eliminated by (hidden3d?) 
> code, because they don't appear normally, and it could be easier to fix 
> there than in all terminal drivers.

This only affects drivers which create an output stream 
for later execution.  The pixel-based drivers don't care.

In fact, I'm not certain it affects any drivers other than post and svg.
The other candidates would be emf and pdf, but emf doesn't support
that color mode, and I think the pdf library already optimizes this out.
Can you think of any others?

	Ethan

> 
> Petr
> 
> 
> > Do you have a sample script that demonstrates this problem?
> >
> > 	Ethan
> >
> >
> >> Comment By: Petr Mikulik (mikulik)
> >> Date: 2006-07-07 12:21
> >>
> >> I have found that these lines
> >>
> >> LT0
> >> 3775 3671 M
> >> stroke
> >> LT0
> >> 4124 2937 M
> >> stroke
> >>
> >> are written by the command
> >>
> >> set hidden3d offset 1 trianglepattern 3 undefined 1
> >> altdiagonal bentover
> >>
> >> and they appear even for "set term postscript"

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742