Menu
▾
▴
gnuplot-beta
|
From: Petr M. <mi...@ph...> - 2006-07-04 20:20:57
|
Currently, "make tutorial" fails due to "TeX capacity exceeded".
Reason: try
gnuplot eg7.plt
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.
Can a pslatex.trm guru have a look?
---
PM
|
|
From: Daniel J S. <dan...@ie...> - 2006-07-04 22:08:54
|
Petr Mikulik wrote:
> Currently, "make tutorial" fails due to "TeX capacity exceeded".
>
> Reason: try
> gnuplot eg7.plt
>
> 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.
Another question is why does the following line, attributable to EPSLATEX_linetype(int linetype), appear so often in a row:
\csname LT0\endcsname
Dan
|
|
From: Daniel J S. <dan...@ie...> - 2006-07-04 23:27:31
|
Daniel J Sebald wrote:
> Petr Mikulik wrote:
>
>>Currently, "make tutorial" fails due to "TeX capacity exceeded".
>>
>>Reason: try
>> gnuplot eg7.plt
>>
>>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.
>
>
> Another question is why does the following line, attributable to EPSLATEX_linetype(int linetype), appear so often in a row:
>
> \csname LT0\endcsname
This probably falls in the category of setting line types, palettes, etc more than necessary in the core. There appears to be no accepted strategy in the README files about this sort of thing. But there are two approaches to take:
1) In the core, only change settings in the terminal when necessary. If the terminal needs to reuse or reissue such information like palette (a bug and all its consequences that Ethan and I looked at in the PostScript terminal), then it should save that information and recall it.
2) In the core, ensure the terminal is properly set by resending information before a plot action even if it hasn't changed. The terminal driver's job is then, at least in the case of PostScript, to weed out all the extraneous calls, e.g., if the _linetype() function is called and the line type is the same as previous, then do not put a PostScript command in the file.
We've seen this issue crop up several times now. Personally, I'd prefer approach #1 to be the accepted strategy. The less "traffic" the better. It's a bit of a danger to mess with this before 4.2 in the core.
In fact, I'm wondering, is there someone taking the lead on the PostScript, combined PS/LatTeX, etc? This used to be fairly well organized, but looking into the problem that Petr reports, I find a couple things.
One, here is the linetype function in pslatex:
TERM_PUBLIC void
EPSLATEX_linetype(int linetype)
{
PS_linetype(linetype);
if (gpoutfile) {
/* from PS_linetype, should better not be used in twice
* in source code */
if (ps_params->oldstyle)
linetype = (linetype % 4) + 3;
else
linetype = (linetype % 9) + 3;
if (linetype < 0) /* LT_NODRAW, LT_BACKGROUND, LT_UNDEFINED */
linetype = 0;
fprintf(gpoutfile," \\csname LT%c\\endcsname\n",
"wba012345678"[linetype]);
}
}
which calls PS_linetype(linetype), and that linetype function inside post.trm looks almost identical:
TERM_PUBLIC void
PS_linetype(int linetype)
{
if ((ps_params->terminal == PSTERM_EPSLATEX) && ps_params->oldstyle)
linetype = (linetype % 4) + 3;
else
linetype = (linetype % 9) + 3;
if (linetype < 0) /* LT_NODRAW, LT_BACKGROUND, LT_UNDEFINED */
linetype = 0;
PS_relative_ok = FALSE;
#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
/* HBB 20031219: use PS_FLUSH_PATH! */
/* PS_relative_ok = FALSE; */
PS_FLUSH_PATH;
PS_linetype_last = linetype;
fprintf(gppsfile, "LT%c\n", "wba012345678"[linetype]);
ps_path_count = 0;
}
I really wish that the practice of code reuse were implemented here, so there is only need to maintain one "functional" hunk of code. I.e., create a function that has an output file pointer as an argument and call it twice with different output file pointers.
Two, you can see where the above is leading. In the post.trm version of the routine is the line
if (PS_linetype_last == linetype) return;
which effectively "weeds out" repetitive calls to the routine when parameters don't actually change. Naturally, there needs to be a similar thing in the pslatex.trm version.
But, even still, this "weed out" conditional is currently commented out in the post.trm version, with an explanation that seems more conjecture than anything else. This is really the kind of thing that should be tossed to the discussion list and resolved before being moved into the CVS tree.
Although this looks to be a not-too-difficult fix, I think I'll pass on this one.
Dan
|
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-07-05 02:45:38
|
On Tuesday 04 July 2006 01:20 pm, Petr Mikulik wrote:
> Currently, "make tutorial" fails due to "TeX capacity exceeded".
>
> Reason: try
> gnuplot eg7.plt
>
> 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.
>
> Can a pslatex.trm guru have a look?
That may be a side effect of this bugfix:
2006-06-18 Ethan A Merritt <merritt@u.washington.edu>
* term/emf.trm (EMF_linetype EMF_dashtype): It is necessary to set the
line color and dash type every time either is changed.
Bugfix.
I'll have another look at it.
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742
|
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-07-05 04:22:46
|
On Tuesday 04 July 2006 07:45 pm, Ethan A Merritt wrote: > > Can a pslatex.trm guru have a look? > > That may be a side effect of this bugfix: > > 2006-06-18 Ethan A Merritt <merritt@u.washington.edu> > * term/emf.trm (EMF_linetype EMF_dashtype): It is necessary to set the Never mind. I totally mis-read which terminal you were talking about. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-07-06 05:07:10
|
On Tuesday 04 July 2006 01:20 pm, Petr Mikulik wrote:
> Currently, "make tutorial" fails due to "TeX capacity exceeded".
>
> Reason: try
> gnuplot eg7.plt
>
> 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.
Ugh.
It's worse than that.
The *.tex file is full of these useless color commands that belong to
the postscript half.
Similarly the *.eps file is full of thousands of useless triplets:
LT0
2715 2933 M
stroke
LT0
2719 2865 M
stroke
[ repeat 6000 times ]
Net result: nothing.
OK, this goes to the top of the must-fix list.
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742
|
|
From: Daniel J S. <dan...@ie...> - 2006-07-06 05:50:43
|
Ethan A Merritt wrote:
> On Tuesday 04 July 2006 01:20 pm, Petr Mikulik wrote:
>
>>Currently, "make tutorial" fails due to "TeX capacity exceeded".
>>
>>Reason: try
>> gnuplot eg7.plt
>>
>>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.
>
>
> Ugh.
> It's worse than that.
Note my email from a couple days ago. Perhaps begin by looking at this strange defined-out line of code:
#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
Again, we probably shouldn't be getting _linetype() called so often, but I don't know if that can be addressed before 4.2.
Also, could this bug have something to do with bug report:
[ 1512210 ] buffer overflow using pgnuplot
? This says:
pgnuplot < gnuplotfile.gnuplot
crashes if gnuplotfile.gnuplot
contains a lot of postscript plots from datafiles
(in my case 20 were enough)
which sounds like the person means they are attempting to create some PostScript plot. Maybe the system is trying to create bloated PostScript plots and is running out of buffered memory.
Dan
|
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-07-06 06:23:30
|
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
> #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.
> Also, could this bug have something to do with bug report:
> [ 1512210 ] buffer overflow using pgnuplot
Nope.
> crashes if gnuplotfile.gnuplot
> contains a lot of postscript plots from datafiles
Again - not the same driver.
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742
|
|
From: Daniel J S. <dan...@ie...> - 2006-07-06 08:28:03
|
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
|
