Menu
▾
▴
gnuplot-beta
|
From: Jonathan T. <jt...@as...> - 2010-03-28 17:13:28
|
I have stumbled on what looks to me like a bug in postscript dash
patterns when using parametric mode. In particular, when using
'set term postscript eps', the 'with lines linetype 2' dash pattern
seems to differ between
(a) plotting a certain horizontal line (about 3 dashes long) using a
pair of of parametric functions to specify x and y, versus
(b) plotting that same horizontal line using '-' inline data to explicitly
specify the endpoint coordinates of the line.
(b) produces the usual dash pattern, while (in my test case) (a) seems
to be broken.
In particular, consider the gnuplot script given below. (This is
abstracted from a larger "real-world" script.) Notice that this draws
two dashed lines of the same length, both 'with lines linetype 2'.
Using gnuplot 4.2.6 compiled from source ('show version long' output
also given below), this produces an eps file showing a pair of labelled
dashed lines. Viewing the eps file with gv (version 3.5.8p5, based on
ghostscript 8.63p7), the left dashed line (the one specified by a pair
of parametric functions) has a dash pattern which looks like this:
------- ------- -------
This does not match the dash pattern of other 'with lines linetype 2'
plots in my real-world script. :( In contrast, the right dashed line
(the one specified by explicit endpoint coordinates) has a dash pattern
which looks like this:
------- ------- -------
This *does* match the dash pattern of other 'with lines linetype 2' plots.
To me, this (the left dash line's wierd dash pattern) looks like a bug.
I have checked that the wierd dash pattern is unchanged when I disable
antialiasing in gv.
--- begin gnuplot script ---
set term postscript eps enhanced monochrome 18 size 8cm,8cm
set output 'par-dash.eps'
unset key
set lmargin 9.0
set rmargin 2.5
unset xtics
unset ytics
unset x2tics
unset y2tics
unset xlabel
unset ylabel
set border 0
set xrange [20:40]
set yrange [0.0:1.0]
set parametric
set dummy ell
set trange [0:1]
# map t=[0:1] --> [a:b]
map(a,b,t) = a + (b-a)*t
f6_x = 20.00
f8_x = 33.00
dash_dx = 1.00
dash_y = 0.1625
label_dx = 1.50
label_dy = 0.00
set label "f_6(ell) parametric fn" at f6_x+label_dx, dash_y+label_dy
set label "f_6(ell) data" at f8_x+label_dx, dash_y+label_dy
plot f6_x+map(0,dash_dx,ell), dash_y \
notitle \
with lines linetype 2 linewidth 3.0 linecolor -1, \
'-' \
notitle \
with lines linetype 2 linewidth 3.0 linecolor -1
# data for '-' plot above
33.00 0.1625
34.00 0.1625
eof
set output
--- end gnuplot script ---
--- begin 'show version long' output ---
gnuplot> show version long
G N U P L O T
Version 4.2 patchlevel 6
last modified Sep 2009
System: OpenBSD 4.6
Copyright (C) 1986 - 1993, 1998, 2004, 2007 - 2009
Thomas Williams, Colin Kelley and many others
Type `help` to access the on-line reference manual.
The gnuplot FAQ is available from http://www.gnuplot.info/faq/
Send bug reports and suggestions to <http://sourceforge.net/projects/gnuplot>
Compile options:
-READLINE +LIBREADLINE -HISTORY +BACKWARDS_COMPATIBILITY +BINARY_DATA
+GD_PNG +GD_JPEG +GD_TTF +GD_GIF +ANIMATION
-NOCWDRC +X11 +X11_POLYGON +MULTIBYTE +USE_MOUSE +HIDDEN3D_QUADTREE
+DATASTRINGS +HISTOGRAMS +OBJECTS +STRINGVARS +MACROS +IMAGE
DRIVER_DIR = "/usr/local/libexec/gnuplot/4.2"
GNUPLOT_PS_DIR = "/usr/local/share/gnuplot/4.2/PostScript"
HELPFILE = "/usr/local/share/gnuplot/4.2/gnuplot.gih"
gnuplot>
--- end 'show version long' output ---
ciao,
--
-- "Jonathan Thornburg [remove -animal to reply]" <jt...@as...>
Dept of Astronomy, Indiana University, Bloomington, Indiana, USA
"C++ is to programming as sex is to reproduction. Better ways might
technically exist but they're not nearly as much fun." -- Nikolai Irgens
|
|
From: Jonathan T. <jt...@as...> - 2010-03-28 17:27:21
|
On Sun, 28 Mar 2010, Jonathan Thornburg wrote:
> I have stumbled on what looks to me like a bug in postscript dash
> patterns when using parametric mode. [[...]]
In hindsight, that E-mail came out quite officious (not to mention
repeating itself a bit). I apologise for this -- it was sloppy editing
on my part. I've been using gnuplot since sometime in the 1980s
(I remember 2.* versions), I'm actually very happy with it.
ciao,
--
-- "Jonathan Thornburg [remove -animal to reply]" <jt...@as...>
Dept of Astronomy, Indiana University, Bloomington, Indiana, USA
"C++ is to programming as sex is to reproduction. Better ways might
technically exist but they're not nearly as much fun." -- Nikolai Irgens
|
|
From: Ethan M. <merritt@u.washington.edu> - 2010-03-28 18:29:28
|
On Sunday 28 March 2010 10:13:12 Jonathan Thornburg wrote:
> I have stumbled on what looks to me like a bug in postscript dash
> patterns when using parametric mode. In particular, when using
> 'set term postscript eps', the 'with lines linetype 2' dash pattern
> seems to differ between
> (a) plotting a certain horizontal line (about 3 dashes long) using a
> pair of of parametric functions to specify x and y, versus
> (b) plotting that same horizontal line using '-' inline data to explicitly
> specify the endpoint coordinates of the line.
Thank you for your detailed bug report.
Unfortunately, I cannot reproduce it the problem.
Using either 4.2.6 or current CVS, the two lines produced by your example
script are indistinguishable to my eyes even at 10x magnification. Perhaps
in the CVS output one of the component dashes is ever so slightly longer,
but if so it is at the very edge of perceptible difference.
Could you please file this report on SourceForge, and attach an
output PostScript file demonstrating the problem?
Notwithstanding my failure to reproduce this, I'm going to guess that
the problem lies in the PostScript implementation. From your description,
I'm guessing that the dot-dash pattern associated with the line is re-started
for each line segment, so if you draw a line made up of multiple segments
(as is likely for a parametric curve) the pattern is discontinuous at each
break point.
But I could be wrong. Let's see whether your output file looks the same
as the one I get here.
Ethan
> (b) produces the usual dash pattern, while (in my test case) (a) seems
> to be broken.
>
> In particular, consider the gnuplot script given below. (This is
> abstracted from a larger "real-world" script.) Notice that this draws
> two dashed lines of the same length, both 'with lines linetype 2'.
>
> Using gnuplot 4.2.6 compiled from source ('show version long' output
> also given below), this produces an eps file showing a pair of labelled
> dashed lines. Viewing the eps file with gv (version 3.5.8p5, based on
> ghostscript 8.63p7), the left dashed line (the one specified by a pair
> of parametric functions) has a dash pattern which looks like this:
> ------- ------- -------
> This does not match the dash pattern of other 'with lines linetype 2'
> plots in my real-world script. :( In contrast, the right dashed line
> (the one specified by explicit endpoint coordinates) has a dash pattern
> which looks like this:
> ------- ------- -------
> This *does* match the dash pattern of other 'with lines linetype 2' plots.
>
> To me, this (the left dash line's wierd dash pattern) looks like a bug.
> I have checked that the wierd dash pattern is unchanged when I disable
> antialiasing in gv.
>
> --- begin gnuplot script ---
> set term postscript eps enhanced monochrome 18 size 8cm,8cm
> set output 'par-dash.eps'
>
> unset key
>
> set lmargin 9.0
> set rmargin 2.5
>
> unset xtics
> unset ytics
> unset x2tics
> unset y2tics
>
> unset xlabel
> unset ylabel
>
> set border 0
>
> set xrange [20:40]
> set yrange [0.0:1.0]
>
> set parametric
> set dummy ell
> set trange [0:1]
>
> # map t=[0:1] --> [a:b]
> map(a,b,t) = a + (b-a)*t
>
> f6_x = 20.00
> f8_x = 33.00
> dash_dx = 1.00
> dash_y = 0.1625
> label_dx = 1.50
> label_dy = 0.00
>
> set label "f_6(ell) parametric fn" at f6_x+label_dx, dash_y+label_dy
> set label "f_6(ell) data" at f8_x+label_dx, dash_y+label_dy
>
> plot f6_x+map(0,dash_dx,ell), dash_y \
> notitle \
> with lines linetype 2 linewidth 3.0 linecolor -1, \
> '-' \
> notitle \
> with lines linetype 2 linewidth 3.0 linecolor -1
>
> # data for '-' plot above
> 33.00 0.1625
> 34.00 0.1625
> eof
>
> set output
> --- end gnuplot script ---
>
> --- begin 'show version long' output ---
> gnuplot> show version long
>
> G N U P L O T
> Version 4.2 patchlevel 6
> last modified Sep 2009
> System: OpenBSD 4.6
>
> Copyright (C) 1986 - 1993, 1998, 2004, 2007 - 2009
> Thomas Williams, Colin Kelley and many others
>
> Type `help` to access the on-line reference manual.
> The gnuplot FAQ is available from http://www.gnuplot.info/faq/
>
> Send bug reports and suggestions to <http://sourceforge.net/projects/gnuplot>
>
> Compile options:
> -READLINE +LIBREADLINE -HISTORY +BACKWARDS_COMPATIBILITY +BINARY_DATA
> +GD_PNG +GD_JPEG +GD_TTF +GD_GIF +ANIMATION
> -NOCWDRC +X11 +X11_POLYGON +MULTIBYTE +USE_MOUSE +HIDDEN3D_QUADTREE
> +DATASTRINGS +HISTOGRAMS +OBJECTS +STRINGVARS +MACROS +IMAGE
>
> DRIVER_DIR = "/usr/local/libexec/gnuplot/4.2"
> GNUPLOT_PS_DIR = "/usr/local/share/gnuplot/4.2/PostScript"
> HELPFILE = "/usr/local/share/gnuplot/4.2/gnuplot.gih"
>
> gnuplot>
> --- end 'show version long' output ---
>
> ciao,
>
> --
> -- "Jonathan Thornburg [remove -animal to reply]" <jt...@as...>
> Dept of Astronomy, Indiana University, Bloomington, Indiana, USA
> "C++ is to programming as sex is to reproduction. Better ways might
> technically exist but they're not nearly as much fun." -- Nikolai Irgens
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742
|
|
From: Jonathan T. <jt...@as...> - 2010-03-29 19:31:18
|
Hi, On Sunday 28 March 2010 10:13:12 I wrote: | I have stumbled on what looks to me like a bug in postscript dash | patterns when using parametric mode. In particular, when using | 'set term postscript eps', the 'with lines linetype 2' dash pattern | seems to differ between | (a) plotting a certain horizontal line (about 3 dashes long) using a | pair of of parametric functions to specify x and y, versus | (b) plotting that same horizontal line using '-' inline data to explicitly | specify the endpoint coordinates of the line. On Sun, 28 Mar 2010, Ethan Merritt wrote: > Thank you for your detailed bug report. > Unfortunately, I cannot reproduce it the problem. > Using either 4.2.6 or current CVS, the two lines produced by your example > script are indistinguishable to my eyes even at 10x magnification. Perhaps > in the CVS output one of the component dashes is ever so slightly longer, > but if so it is at the very edge of perceptible difference. > > Could you please file this report on SourceForge, and attach an > output PostScript file demonstrating the problem? Ok, I have done this, it's sourceforge bug id #2978743, description "postscript dash patterns differ between parametric & data pl" (it looks like they truncated my description string), https://sourceforge.net/tracker/?func=detail&aid=2978743&group_id=2055&atid=102055 I have attached 3 files to the bug report: * my gnuplot script 'par-dash.gnuplot' * the eps output produced by gnuplot 4.2.6 on my computer, 'par-dash.eps' * an X windows screen dump (from 'xwd', converted to a jpeg image via 'xwdtopnm | pnmtojpeg -quality 95') showing 'gv' on my computer viewing the eps file (with antialiasing turned OFF so as not to confuse things), with the wierd dash pattern visible on the left and the normal dash pattern visible on the right > Notwithstanding my failure to reproduce this, I'm going to guess that > the problem lies in the PostScript implementation. From your description, > I'm guessing that the dot-dash pattern associated with the line is re-started > for each line segment, so if you draw a line made up of multiple segments > (as is likely for a parametric curve) the pattern is discontinuous at each > break point. That does seem plausible. And maybe there's an uninitialized variable or suchlike hiding in the code to explain why the output is different on my computer than on your computer. > But I could be wrong. Let's see whether your output file looks the same > as the one I get here. Yes, I'm interested in what your postscript viewer shows when pointed at my eps file -- this should at least resolve the question of whether the problem I see is in my gnuplot or in my postscript viewer ('gv'). ciao, -- -- "Jonathan Thornburg [remove -animal to reply]" <jt...@as...> Dept of Astronomy, Indiana University, Bloomington, Indiana, USA "Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral." -- quote by Freire / poster by Oxfam |
|
From: Mojca M. <moj...@gm...> - 2010-03-29 20:46:05
|
On Mon, Mar 29, 2010 at 21:31, Jonathan Thornburg wrote: > Hi, > > Ok, I have done this, it's sourceforge bug id #2978743, description > "postscript dash patterns differ between parametric & data pl" > (it looks like they truncated my description string), > https://sourceforge.net/tracker/?func=detail&aid=2978743&group_id=2055&atid=102055 > I have attached 3 files to the bug report: > * my gnuplot script 'par-dash.gnuplot' > * the eps output produced by gnuplot 4.2.6 on my computer, 'par-dash.eps' > * an X windows screen dump (from 'xwd', converted to a jpeg image via > 'xwdtopnm | pnmtojpeg -quality 95') showing 'gv' on my computer viewing > the eps file (with antialiasing turned OFF so as not to confuse things), > with the wierd dash pattern visible on the left and the normal dash > pattern visible on the right On my viewer (Preview.app on Mac; conversion done by Mac OS X) it looks OK. After conversion with ps2pdf and using the same viewer for PDF it shows a weird patterns - most probably the same as yours. Mojca |
|
From: Hans-Bernhard B. <HBB...@t-...> - 2010-03-29 21:33:34
|
Jonathan Thornburg wrote: > I have stumbled on what looks to me like a bug in postscript dash > patterns when using parametric mode. In particular, when using > 'set term postscript eps', the 'with lines linetype 2' dash pattern > seems to differ between > (a) plotting a certain horizontal line (about 3 dashes long) using a > pair of of parametric functions to specify x and y, versus > (b) plotting that same horizontal line using '-' inline data to explicitly > specify the endpoint coordinates of the line. I'll venture a guess, then: the difference disappears if you use the same number of points for both lines, right? I.e. if you 'set samples 2' for (a), the two plots will be the same. Or if you output the sampled function to a data file (--> help table), and plot that in place of the inline data, the two plots will again be the same. |
|
From: Jonathan T. <jt...@as...> - 2010-03-29 22:13:39
|
Hi, all,
On Mon, 29 Mar 2010, Hans-Bernhard Br?ker wrote:
> I'll venture a guess, then: the difference disappears if you use the same
> number of points for both lines, right? I.e. if you 'set samples 2' for (a),
> the two plots will be the same. Or if you output the sampled function to a
> data file (--> help table), and plot that in place of the inline data, the two
> plots will again be the same.
Success! I've experimented with placing 'set samples N' for various N
near the start of my test gnuplot script, with the following results
(this is still using gnuplot 4.2.6 on my computer; I've just downloaded
gnuplot-4.4.0.tar.gz but haven't compiled/installed it yet):
N result
1000 wierd dash pattern for parametric line
300 wierd dash pattern for parametric line
200 wierd dash pattern for parametric line
150 almost-normal dash pattern for parametric line
(very slightly different from that for explicit-data
line when viewed at high magnification)
100 normal dash pattern for parametric line
2 normal dash pattern for parametric line
Moreover, this now explains the apparent system-dependence (i.e.,
Ethan not being able to reproduce the problem): my personal
$HOME/.gnuplot file contains (among other things) 'set samples 1000'.
Question: Ethan, do you see the wierd dash patterns (or even the
same eps file as I do?) if you put 'set samples 1000' at the start
of my gnuplot script?
In any case, I think Hans-Bernhard's guess-which-turns-out-to-be-right
supports Ethan's hypothesis
# I'm guessing that the dot-dash pattern associated with the line is re-started
# for each line segment, so if you draw a line made up of multiple segments
# (as is likely for a parametric curve) the pattern is discontinuous at each
# break point.
There is also still Mojca Miklavec's observation that on a Mac,
Apple's viewer and ps2pdf give different results when viewing the eps
file I uploaded to sourceforge. Can anyone else on a different type
of computer try viewing the eps file I generated? I'm at home & don't
have a postscript printer available, though I can try printing this at
work on wednesday. Of course, some postscript printers internally
use ghostscript (just as my viewer 'gv' does), so consistency there
may not mean quite as much as one might hope.....
ciao,
--
-- "Jonathan Thornburg [remove -animal to reply]" <jt...@as...>
Dept of Astronomy, Indiana University, Bloomington, Indiana, USA
"Washing one's hands of the conflict between the powerful and the
powerless means to side with the powerful, not to be neutral."
-- quote by Freire / poster by Oxfam
|
|
From: Mojca M. <moj...@gm...> - 2010-03-29 22:43:25
|
2010/3/30 Jonathan Thornburg wrote: > Hi, all, > > On Mon, 29 Mar 2010, Hans-Bernhard Br?ker wrote: >> I'll venture a guess, then: the difference disappears if you use the same >> number of points for both lines, right? I.e. if you 'set samples 2' for (a), >> the two plots will be the same. Or if you output the sampled function to a >> data file (--> help table), and plot that in place of the inline data, the two >> plots will again be the same. > > Success! I've experimented with placing 'set samples N' for various N > near the start of my test gnuplot script, with the following results > (this is still using gnuplot 4.2.6 on my computer; I've just downloaded > gnuplot-4.4.0.tar.gz but haven't compiled/installed it yet): > N result > 1000 wierd dash pattern for parametric line > 300 wierd dash pattern for parametric line > 200 wierd dash pattern for parametric line > 150 almost-normal dash pattern for parametric line > (very slightly different from that for explicit-data > line when viewed at high magnification) > 100 normal dash pattern for parametric line > 2 normal dash pattern for parametric line > > Moreover, this now explains the apparent system-dependence (i.e., > Ethan not being able to reproduce the problem): my personal > $HOME/.gnuplot file contains (among other things) 'set samples 1000'. > > Question: Ethan, do you see the wierd dash patterns (or even the > same eps file as I do?) if you put 'set samples 1000' at the start > of my gnuplot script? Oh, nice observation. At 104-105-106 gnuplot (or maybe PS terminal) most probably starts being a bit more "careful" about too long lines. with 'set samples 104': 1 0 V 2 0 V 2 0 V % End plot #1 % Begin plot #2 stroke with 'set samples 105': 1 0 V 2 0 V 2 0 V stroke 1137 882 M % End plot #1 % Begin plot #2 stroke with 'set samples 106': 2 0 V 1 0 V 2 0 V stroke 1135 882 M 2 0 V % End plot #1 % Begin plot #2 stroke At least the example with 'set samples 105' seems very weird to me. Mojca (PS: one could definitely optimize the output with zillions of lines like 2 0 V 2 0 V 1 0 V 2 0 V 1 0 V 2 0 V 1 0 V 2 0 V 2 0 V ) |
|
From: Mojca M. <moj...@gm...> - 2010-03-29 21:34:25
|
Hello, I'm sending a minimal example (an EPS file) that reproduces the problem (it's exactly the same line that you sent, but shifted and with all the overhead removed completely). Apple's software and ps2pdf give different results. This could be called "a bug in renderer" (though I'm not sure whether it's Apple or GS that's buggy - it's just inconsistent). I can send screenshots if that helps anyone. The other question is why gnuplot draws two lines (and also: why it draws "1 0 rlineto" more than hundred times in a row). I didn't try to understand what the gnuplot code does. %!PS-Adobe-2.0 EPSF-2.0 %%BoundingBox: -2 0 166 40 %%EndComment 10 setlinewidth [40 20] 0 setdash % first line 0 10 moveto 104 0 rlineto stroke 104 10 moveto 61 0 rlineto stroke % second line 0 30 moveto 164 0 rlineto stroke showpage %%Trailer The code corresponds to the following part from your original EPS: 972 883 M 1 0 V 1 0 V 1 0 V ... 1 0 V stroke 1076 883 M 1 0 V ... 1 0 V stroke LT1 LCb setrgbcolor 3112 883 M 164 0 V 1.000 UP stroke Mojca |
|
From: Mojca M. <moj...@gm...> - 2010-03-29 21:44:07
|
On Mon, Mar 29, 2010 at 23:34, Mojca Miklavec wrote: > Hello, > > I'm sending a minimal example (an EPS file) that reproduces the > problem (it's exactly the same line that you sent, but shifted and > with all the overhead removed completely). > > Apple's software and ps2pdf give different results. This could be > called "a bug in renderer" (though I'm not sure whether it's Apple or > GS that's buggy - it's just inconsistent). I can send screenshots if > that helps anyone. > > The other question is why gnuplot draws two lines (and also: why it > draws "1 0 rlineto" more than hundred times in a row). I didn't try to > understand what the gnuplot code does. I have played with EPS file before. Now I have tried to run your gnuplot code and the problem disapears even with GS. It now draws only a single long line as opposed to what it did on your output: % Begin plot #1 3.000 UL LT1 LCb setrgbcolor 972 882 M 2 0 V 1 0 V 2 0 V 2 0 V 1 0 V ... 2 0 V 2 0 V 1 0 V 2 0 V 2 0 V % End plot #1 % Begin plot #2 stroke You seem to have compiled the example with gnuplot 4.2 patchlevel 6, while I have gnuplot 4.5 patchlevel 0 (I'm not sure about the exact version). Mojca |
|
From: Hans-Bernhard B. <HBB...@t-...> - 2010-03-29 23:03:34
|
Mojca Miklavec wrote: > Oh, nice observation. At 104-105-106 gnuplot (or maybe PS terminal) > most probably starts being a bit more "careful" about too long lines. That's actually the effect of a bug fix we put in to accomodate renderers that accumulate round-off errors if a single PS polyline path becomes too long. That bug fix has been in there for 7 years now. > (PS: one could definitely optimize the output with zillions of lines like > 2 0 V > 2 0 V Not really one couldn't, because a straight line is a very special case of a parametric curve. The short moves are strictly necessary to make curves that actually curve out of straight segments. |
|
From: Mojca M. <moj...@gm...> - 2010-03-29 23:23:58
|
2010/3/30 Hans-Bernhard Bröker wrote: > >> (PS: one could definitely optimize the output with zillions of lines like >> 2 0 V >> 2 0 V > > Not really one couldn't, because a straight line is a very special case of a > parametric curve. The short moves are strictly necessary to make curves > that actually curve out of straight segments. One could optimize "if two consecutive line segments are straight and point to the same direction, remove point in the middle", but this would not remove the bug. Mojca PS: if it's only about the round-off error - why not putting some "lineto" statements every now and then instead of rlineto? I guess rlineto result in smaller files, but one doesn't need to "stroke" the line in the middle of curve. |
|
From: sfeam (E. Merritt) <eam...@gm...> - 2010-03-30 05:16:16
|
On Monday 29 March 2010, Mojca Miklavec wrote:
> PS: if it's only about the round-off error - why not putting some
> "lineto" statements every now and then instead of rlineto? I guess
> rlineto result in smaller files, but one doesn't need to "stroke" the
> line in the middle of curve.
That would work to overcome the current problem. But according to
the comments in post.trm this runs into a separate problem:
/* Ghostscript has a "pile-up of rounding errors" bug: a sequence of many
* rmove's or rlineto's does not yield the same line as move's or lineto's.
* Therefore, we periodically force an update of the absolute position.
* There was a case when 400 rlineto's were too much, so let's go a little
* bit higher than the default function sampling rate in gnuplot.
* This runs into a second ghostscript bug, that mixing relative and absolute
* lineto with no intervening 'stroke' is ridiculously slow to render.
* So we stroke the partial line, update the position in absolute terms,
* then continue. This whole section can go away if ghostscript/gv is fixed.
*/
# define MAX_REL_PATHLEN 105
if (ps_path_count >= MAX_REL_PATHLEN) {
fprintf(gppsfile, "stroke %d %d M\n", x, y);
ps_path_count = 1;
}
I suppose we could make MAX_REL_PATHLEN configurable, and skip the section if
it is set to zero.
So, has ghostscript/gv been fixed during the intervening years?
I don't know.
|
