Re: smooth shading & terminal specialities

[Mojca M. <moj...@gm...>]

On 5/10/06, Ethan Merritt wrote:
> On Tuesday 09 May 2006 03:52 pm, you wrote:
> > I'm sending a sample .ps file with gradient fill for the default palett=
e.
> >
> > I calculated the values at 11 equally spaced points and converted them
> > into hex numbers, now stored in /data. PostScript terminal currently
> > draws 1024 single-color rectangles. Does anyone notice any difference
> > in the palette produced by gradient fill and the one produced by 1024
> > samples?
>
> Aha.  You are using Level 3 extensions to PostScript.
>
> They are not mentioned in the PostScript Language Reference Manual
> (2nd Edition) that I have on my shelf.
> Your test file displays on my older machines, which surprises me,
> but the result looks truly awful.  My new machines have a newer gs
> installed that does indeed support these extensions.
>
> I guess I should go out and buy a new copy of the Language
> Reference Manual.

I downloaded the documentation and examples of files with smooth
shading from Adobe (it's not meant to be taken on holidays as reading
for relaxation ;). I'm sorry - I didn't thought about older machines
(Level3 is from the last century, but I agree that mostly older PS
printers might experience problems with it.) Level-dependent code
generation would be great!

> > OK. Let me try to explain, For drawing the "plotting area" in this
> > image (http://gnuplot.sourceforge.net/demo_4.1/pm3d.8.png), which is
> > nothing else but a bitmap image, gnuplot calls my terminal
> >     term->set_color(...)
> >     term->fillbox(...)
> > 49 x 49 times. For bitmap teminal this doesn't really matter, but for
> > my terminal it means constructing 49x49 paths and fill each one of
> > them separately (bot at compile time of the image and when displaying
> > it in GhostView or Acrobat), not to mention aliasing-artefacts (I
> > don't know how they are called, but GhostView shows white stripes all
> > over the plot).
>
> Yeah, we know.  That is the down-side of newer versions of gs/gv/ghostvie=
w.
> They have a bad aliasing bug.  It's a known bug, but even if they fix it
> there will be a lot of broken installations for a long time to come.
>
> > This is extremely inefficient. It would be much better
> > if gnuplot would call a routine
> >     term->image(49,49, ....)
> > The result would be the visually the same (only better since no
> > artefacts would occur) and both compiling and rendering would be more
> > efficient. If the driver doesn't support "images", it can still draw
> > 49 times 49 filled rectangles.
>
> But how does the higher level code tell a driver what to put in those
> 49x49 boxes?  In the general case each one has a different color, so
> I do not see how you end up saving anything.

Well ... storing 2500 boxes means 7500 lines of output like this for
my terminal (which also renders awfully):

gp_set_color_frac(0.1641);
p :=3D (104.66,20.10)--(108.91,20.10)--(108.91,20.47)--(104.66,20.47)--cycl=
e;
gp_fill(p,1);

Storing a field of 2500 RGB tripples means 7500 bytes instead and is
also rendered much more efficiently and with no antialiasing problems.

In the first case you also have to save coordinates, not only the
color (I could save some space with shorter names and such, but that
woudn't have much influence on efficiency).

Mojca