Re: [Plplot-devel] Proper registration of text and graphics with pstex driver (fwd)

[Alan W. I. <ir...@be...>]

On 2004-10-24 12:19-0700 Alan W. Irwin wrote:

> ---------- Forwarded message ----------
> Date: Thu, 30 Sep 2004 14:05:01 -0700
> From: Bill Paxton <pa...@ki...>
> [...] The pstex driver tells TeX what the unitlength is for the
> picture, and this better agree with what the ps driver tells PostScript, or
> we'll get misaligned text.  The ps driver sets up the unit length by doing a
> scale with values from ps.h, XSIZE and XPSSIZE,  which gives 540/720 for
> unit length in PostScript.  The pstex driver sets the unit length to be
> 72./25.4/pls->xpmm.  Where pls->xpmm has been previously set by the ps
> driver to be YPSSIZE/LPAGE_X.  YPSSIZE is ENLARGE*YSIZE.  LPAGE_X is
> (PIXELS_X/VDPMM).  VDPMM is DPMM*32.  DPMM is 4.  PIXELS_X is 32768.  YSIZE
> is 720.  ENLARGE is 5.  Crank all this and you finally get a unitsize from
> pstex of 0.201575 vs. unitsize frm ps of 0.200000.   When pstex is changed
> to calculate unitsize in the same way that ps does, the registration problem
> goes away.  The change I made in pstex.c was in the plD_init_pstex
> procedure:
>
>  fprintf(fp,"\\setlength{\\unitlength}{%fbp}%%\n", 72./25.4/pls->xpmm);
>
> Becomes
>
>  fprintf(fp,"\\setlength{\\unitlength}{%fbp}%%\n", 1.0/ENLARGE);
>
> Heaven only knows what this change will cause to break elsewhere, but it
> seems to work for my test cases.

This morning I almost applied the one-line fix above, but I checked the code
looking for "25.4", and the factors 72./25.4/pls->xpmm and
72./25.4/pls->ypmm appear in a lot of places in the pstex.c code.  Thus, I
believe it is unlikely Bill's fix is complete for solving the registration
problems for this device so I decided to make no changes.  I suggest
instead, whoever fixes this look for "25.4" and carefully analyze (as in
Bill's detailed analysis above for the one instance) what the factor should
be in each case. Probably, it should be 1.0/ENLARGE, but I don't want to do
that change blindly without following Bill's analysis in each case,
and unfortunately I don't have time to do that at the moment.  If somebody
else wants to step forward now, be my guest, but otherwise, I will put this
on my ToDo list to deal with when I have more time for PLplot in the long
term.

>
>
> P.S.  TeX also seems to dislike getting blank strings, so proc_str in pstex
> should filter them out.  Try calling pllab("","","") to check it.

I think we should pursue a multi-prong approach here; on the one hand I hope
somebody fixes these known problems with pstex.c in the short term (or I
will do it in the long term), and in the long term I hope Rafael, Andrew
Ross, and Andrew Roach (all of whom expressed some interest) can agree on
and implement a solution for making non-Hershey fonts directly accessible to
ps.c.

I would also be willing to help out with such a project if somebody else
will organize it. In my view, such a project is really important for PLplot
because ps.c is one of our most heavily used devices, and the Hershey fonts
that we are limited to now for that device just don't cut it any more
compared to what our competitors are doing.  Case in point: I was showing
PLplot results to a colleague of mine a couple of months ago, and he lost
interest in PLplot as soon as he saw the Hershey fonts.

Alan
__________________________
Alan W. Irwin
email: ir...@be...
phone: 250-727-2902

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the
Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________