Menu
▾
▴
gnuplot-beta
|
From: Hans-Bernhard B. <br...@ph...> - 2004-07-15 12:49:14
|
Hello, all,
a newsgroup poster just found out a problem with (at least) post.trm pm3d
output exposed by turning on antialiasing (type 'a' in gv or ghostview)
--- there's a Moir'e pattern of very thin (single-pixel) white lines
exposed at the border between neighboring rectangles of pm3d plots. The
colour scale box displays incorrectly in both 4.0.2 and 4.1, as soon as
antialiasing is turned on: there's a rather visible ripple in it.
To give you something to look at: the seventh plot of 'pm3d.dem' exposes
the problem.
At 64x magnification (in gv) of 4.0.2 output it becomes obvious that
ghostscript leaves thin white margins between any two polygons --- whether
they appear at normal display scales or not is a spatial aliasing effect.
Mysteriously, although there's no ChangeLog entry pointing to a bug having
been found and fixed in this area --- it seems like this difference is
just an lucky side-effect of Ethan's changes to support pattern fills for
term->polygon().
Looking at the generated postscript, it seems as if the only significant
difference between 4.0.2 and 4.1 is the order of output points, and, of
course, the PostScript macro being used:
---------4.0: ---------------
.3293 g 5148 927 N 0 -114 114 0 0 114 h
.3148 g 5033 927 N 0 -114 115 0 0 114 h
.2934 g 4918 927 N 0 -114 115 0 0 114 h
/h {rlineto rlineto rlineto fill} bind def
---------4.1: ---------------
.3293 g 5148 927 N 0 114 V 114 0 V 0 -114 V 1.0 PolyFill
.3148 g 5033 927 N 0 114 V 115 0 V 0 -114 V 1.0 PolyFill
.2934 g 4918 927 N 0 114 V 115 0 V 0 -114 V 1.0 PolyFill
/V {rlineto} bind def
/PolyFill {
gsave
/Fillden exch def
currentrgbcolor
/ColB exch def /ColG exch def /ColR exch def
/ColR ColR Fillden mul Fillden sub 1 add def
/ColG ColG Fillden mul Fillden sub 1 add def
/ColB ColB Fillden mul Fillden sub 1 add def
ColR ColG ColB setrgbcolor
fill grestore } def
------- end excerpts ------
Expanding the macros a bit, this becomes
4.0: .3293 g 5148 927 N 0 -114 114 0 0 114 rlineto rlineto rlineto fill
4.1: .3293 g 5148 927 N 0 114 rlineto 114 0 rlineto 0 -114 rlineto \
[... colour stuff ...] fill
Now, I'm certainly no PostScript guru, but to my understanding, the
above should render the same result.
--
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.
|
|
From: Petr M. <mi...@ph...> - 2004-07-15 13:37:37
|
> a newsgroup poster just found out a problem with (at least) post.trm pm3d
> output exposed by turning on antialiasing (type 'a' in gv or ghostview)
> --- there's a Moir'e pattern of very thin (single-pixel) white lines
> exposed at the border between neighboring rectangles of pm3d plots.
It was always like that -- happens if you set option "Graphics Alpha" to 4
bits (in gsview, I don't know how to change it in gv).
> just an lucky side-effect of Ethan's changes to support pattern fills for
> term->polygon().
>
> Looking at the generated postscript, it seems as if the only significant
> difference between 4.0.2 and 4.1 is the order of output points, and, of
> course, the PostScript macro being used:
>
> ---------4.0: ---------------
> .3293 g 5148 927 N 0 -114 114 0 0 114 h
> .3148 g 5033 927 N 0 -114 115 0 0 114 h
> .2934 g 4918 927 N 0 -114 115 0 0 114 h
>
> /h {rlineto rlineto rlineto fill} bind def
>
> ---------4.1: ---------------
> .3293 g 5148 927 N 0 114 V 114 0 V 0 -114 V 1.0 PolyFill
> .3148 g 5033 927 N 0 114 V 115 0 V 0 -114 V 1.0 PolyFill
> .2934 g 4918 927 N 0 114 V 115 0 V 0 -114 V 1.0 PolyFill
That's the new postscript code in 4.1?! I don't like it, sorry! It breaks
compatibility with all those pm3dConvert* scripts, and puts a lot of
"useless characters" into maps. I'm against this change!
The syntax
.3293 g 5148 927 N 0 -114 114 0 0 114 h
is intended to produce line as short as possible and I insists it stays like
that. (My demo example of a non-grid reciprocal space reflectivity maps
using "pm3d map" contains 40000 points and I don't wish to have any increase
of the postscript file size.)
I.e., "pm3d map" should not be interfered by PolyFill. Why did this happen?
Isn't this bug?
(Anyway, why to write "1.0 PolyFill" and not "1 PolyFill"? Please keep
postscript file as short as possible.)
---
PM
|
|
From: Ethan M. <merritt@u.washington.edu> - 2004-07-15 17:06:17
|
On Thursday 15 July 2004 06:37 am, Petr Mikulik wrote:
>
> > just an lucky side-effect of Ethan's changes to support pattern fills for
> > term->polygon().
> >
> > Looking at the generated postscript, it seems as if the only significant
> > difference between 4.0.2 and 4.1 is the order of output points, and, of
> > course, the PostScript macro being used:
> >
> > ---------4.0: ---------------
> > .3293 g 5148 927 N 0 -114 114 0 0 114 h
> > .3148 g 5033 927 N 0 -114 115 0 0 114 h
> > .2934 g 4918 927 N 0 -114 115 0 0 114 h
> >
> > /h {rlineto rlineto rlineto fill} bind def
> >
> > ---------4.1: ---------------
> > .3293 g 5148 927 N 0 114 V 114 0 V 0 -114 V 1.0 PolyFill
> > .3148 g 5033 927 N 0 114 V 115 0 V 0 -114 V 1.0 PolyFill
> > .2934 g 4918 927 N 0 114 V 115 0 V 0 -114 V 1.0 PolyFill
>
>
> That's the new postscript code in 4.1?! I don't like it, sorry! It breaks
> compatibility with all those pm3dConvert* scripts, and puts a lot of
> "useless characters" into maps. I'm against this change!
Sorry, I don't understand. What do you mean by "useless characters"?
Is it such a major problem to require updated scripts to go with updated
code in 4.1? I'm sure there will be more things than this that change as
we develop 4.1.
Would it suffice to re-introduce "h" as a macro for "1.0 PolyFill"?
> > I.e., "pm3d map" should not be interfered by PolyFill. Why did this happen?
Because the PolyFill routine is more general than the older code.
I saw no reason to keep a separate, less-capable, routine when
instead boxfill() could just pass the request along to filled_polygon().
But feel free to go ahead and convince me otherwise.
> The syntax
> .3293 g 5148 927 N 0 -114 114 0 0 114 h
>
> is intended to produce line as short as possible and I insists it stays like
> that.
Should we not first determine if the newer version is less buggy
in additional to being more general?
> (My demo example of a non-grid reciprocal space reflectivity maps
> using "pm3d map" contains 40000 points and I don't wish to have any increase
> of the postscript file size.)
We can certainly look at making the current PolyFill macro more compact,
if you feel that is a major issue. But your script is going to crunch this down
further anyhow, isn't it? How much difference in size would there be after
running the [modified] script?
> (Anyway, why to write "1.0 PolyFill" and not "1 PolyFill"? Please keep
> postscript file as short as possible.)
Because that parameter is the fill density, on a scale from 0.0 to 1.0.
But yes, we could treat 1.0 as a very common special case and drop
the decimal point. I can make that change immediately.
--
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195
|
|
From: Daniel J S. <dan...@ie...> - 2004-07-15 17:43:40
|
The example with the lines, i.e., "maps" could in some cases be done using the trm->image() routine to get rid of the white lines, and reduce the size of files. Oddly, when doing ps2pdf on the postscript output, the white lines aren't visible in Acroread. (In some cases 'though I see strange little blips at the corners of pm3d elements.) Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-07-15 18:12:53
|
On Thursday 15 July 2004 11:08 am, Daniel J Sebald wrote: > The example with the lines, i.e., "maps" could in some cases be done > using the trm->image() routine to get rid of the white lines, and reduce > the size of files. Oddly, when doing ps2pdf on the postscript output, > the white lines aren't visible in Acroread. (In some cases 'though I > see strange little blips at the corners of pm3d elements.) What is so odd about that? The bug is in the gv viewer, or rather the ghostscript conversion to X11, not in the PostScript file. If you convert to pdf and use a different viewer then you bypass the bug entirely. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Daniel J S. <dan...@ie...> - 2004-07-15 19:49:38
|
Ethan Merritt wrote: >On Thursday 15 July 2004 11:08 am, Daniel J Sebald wrote: > > >>The example with the lines, i.e., "maps" could in some cases be done >>using the trm->image() routine to get rid of the white lines, and reduce >>the size of files. Oddly, when doing ps2pdf on the postscript output, >>the white lines aren't visible in Acroread. (In some cases 'though I >>see strange little blips at the corners of pm3d elements.) >> >> > >What is so odd about that? >The bug is in the gv viewer, or rather the ghostscript conversion >to X11, not in the PostScript file. >If you convert to pdf and use a different viewer then you bypass >the bug entirely. > Yeah. I'm not so sure this is a gnuplot problem. Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-07-15 20:06:06
|
> > just an lucky side-effect of Ethan's changes to support pattern fills for
> > term->polygon().
Indeed it was a lucky side-effect.
> > Looking at the generated postscript, it seems as if the only significant
> > difference between 4.0.2 and 4.1 is the order of output points, and, of
> > course, the PostScript macro being used:
My conclusion from trying many combinations of PostScript maco
options on pm3d.dem is that the following change is the minimal one
sufficient to work around this ghostscript/gv bug:
> >
> > ---------4.0: ---------------
> > .3293 g 5148 927 N 0 -114 114 0 0 114 h
> > .3148 g 5033 927 N 0 -114 115 0 0 114 h
> > .2934 g 4918 927 N 0 -114 115 0 0 114 h
> >
> > /h {rlineto rlineto rlineto fill} bind def
Minimal revised version
-----------------------------
/h {rlineto rlineto rlineto gsave fill grestore} bind def
Please check on your machines and on other test cases.
I was able to reproduce the problem with plot 7 of pm3d.dem,
but not the original problem reported on the newsgroup.
Are you OK with that as a fix for version 4.0, Petr?
As to version 4.1, I can try to trap filled quadrangles belonging to
the pm3d surface plots as a special case in the 4.1 code,
and emit the same PostScript code that version 4.0 did.
This may send us into a period of bug-reporting when it
turns out the special-case code is either triggered or not
triggered correctly in all cases.
--
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X