Menu
▾
▴
gnuplot-beta
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-07-08 21:07:08
|
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
|
|
From: Petr M. <mi...@ph...> - 2006-07-08 21:57:39
|
>> LT0
>> 3775 3671 M
>> stroke
>> have no effect.
>
> if (PS_linetype_last == linetype) return;
>
> 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%.
then please commit it
> Related issue
> =============
>
> More annoying to me are all the output lines
> Blacktext { gsave 0 setgray } if
> <something>
> Blacktext { grestore } if
> At the least, perhaps we should define shorthand forms in the prolog:
> /BTon { Blacktext { gsave 0 setgray } if } def
> /Btoff { Blacktext { grestore } if } def
I think the following is the correct solution:
/Rshow {Blacktext { gsave 0 setgray } if
currentpoint stroke M dup stringwidth pop neg vshift R show
Blacktext { grestore } if} def
and same for Cshow and Lshow.
>> 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?
I think it "affects" all, if term->set_color() has to do something ... e.g.
pm.trm send the info through pipe to gnupmdrv.exe, win.trm saves all these
"new color" commmands into its drawing buffer...
I think that the "producer" of these ".4068 g" should eliminate to call
term->set_color() if it is not needed for any drawing. Is it some "hidden3d"
code?
---
PM
|
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-07-08 22:37:56
|
On Saturday 08 July 2006 02:57 pm, Petr Mikulik wrote: > I think that the "producer" of these ".4068 g" should eliminate to call > term->set_color() if it is not needed for any drawing. Is it some "hidden3d" > code? It's not so easy as you make it sound. The logic of the higher level code is 1) determine color of rectangle (or other object) 2) set color 3) draw the object But the object is drawn by invoking a hierarchy of lower level routines, and at those levels hidden3d, or clipping, or various other filters, may cause the object not to be passed through to the driver after all. By that time the set_color command has already been sent. Have a look at the second patch to pslatex.trm that I posted on SourceForge for this bug. The amount of code added to pslatex.trm to filter out unnecessary set_color commands is relatively small. A similar thing could be done, I think, for the small number of other drivers that need it. But each one will have to be considered on its own. To do this in the core code would be much, much messier. In fact, it would be impossible to do correctly for epslatex. epslatex has two output streams, and the commands are properly sent to one but not the other. How would you have the core code deal with that? I think that specific micro-optimization is too driver-dependent to be done at a higher level. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: <br...@ph...> - 2006-07-09 10:27:45
|
Petr Mikulik wrote: > I think that the "producer" of these ".4068 g" should eliminate to call > term->set_color() if it is not needed for any drawing. I'm afraid you think quite wrongly here. The problem is that there's no way the core can know whether that call is needed to get a correct drawing or not. The API call's name is "set color", not "change color", so it should be obvious that the core is perfectly allowed to set the color to the same value as often as it likes. If a driver has a problem with that, it should take care of it itself. If there are many such drivers, let them delegate the work to a shared lower-level function or let term.c offer an intermediate layer (along the lines of term.c:term_suspend, the only caller of term->suspend). We almost have such an intermediate function already: there are rather few functions of the core that actually call term->set_color: color.c:set_color() color.c:set_rgbcolor() gadgets.c: apply_pm3dcolor() > Is it some "hidden3d" code? I must say I'm rather negatively surprised by you asking this question at this time. How come that you have to ask, days after you rather openly blamed hidden3d for this? |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-08-03 16:11:28
|
On Thursday 03 August 2006 08:41 am, Petr Mikulik wrote:
>
> The enclosed patch moves these lines into the definitions of {M}{CLR}show,
> so that the postscript body is clean.
>
> (I'll commit the patch unless some negative feedback is reported.)
Looks OK to me, except that I think your patch contains a modified
file prologues.h that doesn't belong in it. (It reverts iso8559-15
to iso8559-1).
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742
|
|
From: Petr M. <mi...@ph...> - 2006-08-03 16:35:46
|
>> The enclosed patch moves these lines into the definitions of {M}{CLR}show,
>> so that the postscript body is clean.
>>
>> (I'll commit the patch unless some negative feedback is reported.)
>
> Looks OK to me, except that I think your patch contains a modified
> file prologues.h that doesn't belong in it. (It reverts iso8559-15
> to iso8559-1).
It comes out from running the ps_header.sh script; and that what you see is
that on my system as well as for LC_ALL=C, the order is:
prologue_8859_1_ps
prologue_8859_15_ps
while on that somebody's system who committed it to cvs it was:
prologue_8859_15_ps
prologue_8859_1_ps
I prefer the former order.
---
PM
|
|
From: Ethan M. <merritt@u.washington.edu> - 2006-08-03 17:11:05
|
On Thursday 03 August 2006 09:35 am, Petr Mikulik wrote: > > > > Looks OK to me, except that I think your patch contains a modified > > file prologues.h that doesn't belong in it. (It reverts iso8559-15 > > to iso8559-1). > > It comes out from running the ps_header.sh script; and that what you > see is that on my system as well as for LC_ALL=C, the order is: > while on that somebody's system who committed it to cvs it was: > > prologue_8859_15_ps > prologue_8859_1_ps > > I prefer the former order. My point was that such a change has nothing to do with BlackText, and does not belong in the same patchset. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From: Petr M. <mi...@ph...> - 2006-08-03 17:29:01
|
>>> Looks OK to me, except that I think your patch contains a modified >>> file prologues.h that doesn't belong in it. (It reverts iso8559-15 >>> to iso8559-1). >> >> It comes out from running the ps_header.sh script; and that what you >> see is that on my system as well as for LC_ALL=C, the order is: >> while on that somebody's system who committed it to cvs it was: >> >> prologue_8859_15_ps >> prologue_8859_1_ps >> >> I prefer the former order. > > My point was that such a change has nothing to do with BlackText, > and does not belong in the same patchset. OK, regeneration of prologues.h is an independent action. How to updated the script so that it always generates the same sequence of files? I propose this for ps_header.sh: for i in `ls -1 *.ps | LC_ALL=C sort` --- PM |
|
From: <tim...@en...> - 2006-08-03 17:35:32
|
Petr Mikulik wrote: > How to updated the script so that it always generates the same sequence= of=20 > files? I propose this for ps_header.sh: > > for i in `ls -1 *.ps | LC_ALL=3DC sort` > =20 Seems ok to me. Timoth=E9e |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-08-03 17:41:32
|
On Thursday 03 August 2006 12:35 pm, Timoth=E9e Lecomte wrote: > Petr Mikulik wrote: > > How to updated the script so that it always generates the same > > sequence of files? I propose this for ps_header.sh: > > > > for i in `ls -1 *.ps | LC_ALL=3DC sort` > > Seems ok to me. =46ine. =20 Anyhow, the output file, prologues.h, is only being provided for convenience (like gnuplot.texi). Really it should be=20 regenerated at the time a binary is built for the target machine to ensure consistency with the source files being used. =2D-=20 Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
