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

[Ethan M. <merritt@u.washington.edu>]

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