Re: PM3D postscript microgaps vanished from 4.0 to 4.1...

[Petr M. <mi...@ph...>]

> 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