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 |