In comp.graphics.apps.gnuplot #32829
=46rom "news.uibk.ac.at" <Gre...@ui...> wrote
>I have some questions to the active developers of gnuplot, especially Etha=
n A.
>Merrit regarding the pattern fill definitions in the postscript and epslat=
ec
>terminal. (I am just trying to improve the epslatex terminal and stumbled =
on
>this point. And yes I know, there is a patch pending...)
>My impressions of the current status are (perhaps they are wrong): the
>epslatex terminal seems to use Poscript Level 1 pattern fill.=20
There are two separate driver routines that produce filled areas.
term->fillbox() does rectangles only
term->filled_polygon() does general polygons.
The latter routine is obviously more general, but as currently implemented
it requires PM3D support so not all terminals can provide it. I have been
slowly working to disentangle polygons from PM3D so that even non-PM3D
terminals can draw filled polygons.
As to epslatex:
The EPSL_filled_polygon() routine is just a pointer to the one in the
postscript driver.
The EPSL_fillbox() is a private routine to the epslatex driver. It
outputs calls to the same pattern-fill macros used by the postscript
driver until very recently. We cleaned up the postscript driver's own
Level1/Level2 support several months ago. Perhaps the same cleanup
should be applied to epslatex.
=20
>In the=20
>postscript terminal there are several possibilities present in the source
>code: Postscript Level 1 patterns, Level 2 patterns and a postscript macro
>that appropriately draws lines, but only can fill rectangular boxes.
Correct.
>Only the latter is used at the moment.
I'm not sure what you mean by that. The current (CVS) postscript driver
uses either Level1 or Level2 pattern fill depending on what the printer
supports. You can override this by a command line option or by editing the
output file. The current (CVS) epslatex driver uses Level2 pattern fill.
>From a technical point of view using Postscript pattern fill seems prefera=
ble
>since arbitrary shapes can be filled. However, the line draw method gives
>nicer results when viewed on screen (with ghostscript or Acrobat reader af=
ter
>conversion to pdf).
Both ghostview/gv and Acrobat are buggy in their own idiosynchratic ways.
There's not much we can do about that.
You could try xpdf or kpdf, which no doubt have their own set of problems.
>Now my questions:
>What are the rationales for the decisions that led to the current implemen=
tations?
Historical development. The generic pattern-fill macros were developed
so that we could fill areas other than rectangular boxes.
>What are the drawbacks when using the line draw method compared to the
>Postscript pattern fill method?
Only works for rectangles.
>Are there plans to support enhanced pattern fill possibilities (colored
>patterns, arbitrary shapes, more and user defined?
Colored patterns and arbitrary polygon fill are already supported.
As to user customization, there is in a sense a plan that would
allow this. Back when we were packaging up version 4.0 for release
we experimented briefly with pulling the PostScript Prolog, encoding
option code, and other initializations out of the driver source and
having them loaded at run time. The motivation at the time was to
reduce the code size of the postscript driver. But it has the nice
(IMHO) side effect that a user can modify the Prolog, including
macro definitions like pattern fill, without having to edit and
rebuild gnuplot itself. This would also allow site-specific
customization of page size, default character encoding, etc, for
PostScript output.
The only strong objection I recall was that keeping track of external
files required at run time may be problematic under Windows.
I am not familiar with Windows at either the development or user
level, so I'm of no help in sorting this out if it is in fact a
problem. From my side it would be easy enough to have the driver
look first in ~/.gnuplot/Prolog.ps and second in=20
/usr/local/share/gnuplot/Prolog.pa
=2D-=20
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195
|
