Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Strange (to me) stringwidth behavoir

46 views
Skip to first unread message

Jeffrey H. Coffield

unread,
Sep 8, 2012, 11:39:32 AM9/8/12
to
I recently saw a problem in using stringwidth to determine when to break
a line in a paragraph. The following code demonstrates the problem:
-----------------------------------------------
%!PS

/Helvetica 24 selectfont

100 100 moveto
(somedata) stringwidth pop 10 string cvs show

showpage
-----------------------------------------------

The problem is that the number shown changes with the output device.

Using GPL Ghostscript 9.00 on Suse Linux 11.4:

Running "gs x.ps" shows 105.367.

Using emacs postscript mode shows 105.379.

Using "gs -sOutputFile=x.jpg -sDEVICE=jpeg x.ps" shows 105.379

Using "gs -sOutputFile=x.pdf -sDEVICE=pdfwrite x.ps" shows 105.382

When I send it to a printer I get yet another number.

This happens with any font even ones that are loaded from a .gsf file
that was also loaded on the printer. I also tested this on OpenVMS
Itanium 8.4 with AFPL Ghostscript 8.51 and I get different numbers.

Why would the stringwidth vary depending on the output device?

I am aware the PLRM recommends that the font metrics from the AFM file
be used instead of using PostScript, but that will be a big change and I
don't have the .AFM file for all the fonts I need to use.

Jeff Coffield
www.digitalsynergyinc.com

Helge Blischke

unread,
Sep 8, 2012, 12:51:34 PM9/8/12
to
I suspect the reason is that, on different platforms, there are different
variants of Helvetica implemented.

Helge

SaGS

unread,
Sep 8, 2012, 1:22:34 PM9/8/12
to
On Sep 8, 6:39 pm, "Jeffrey H. Coffield"
<jeff...@digitalsynergyinc.com> wrote:
> I recently saw a problem in using stringwidth to determine when to break
> a line in a paragraph. The following code demonstrates the problem:
> -----------------------------------------------
> %!PS
>
> /Helvetica 24 selectfont
>
> 100 100 moveto
> (somedata) stringwidth pop 10 string cvs show
>
> showpage
> -----------------------------------------------
> ...
> Why would the stringwidth vary depending on the output device?
> ...

Another reason, in addition to the one mentioned previously by Helge,
is the resolution. Things like hinting/ grid fitting/ rounding to
device pixels might alter glyphs widths slightly.

I tried Ghostscript with devices pdfwrite, jpeg, png16m and display.
The same executable on the same computer (and so using exactly the
same fonts) gave different widths for different resolutions, but the
same widths for the same resolution even with different devices. For
example a resolution of 300 gave a width of 105.379 for all 4 devices,
96dpi gave 105.369 and 720dpi gave 105.382. Also note that different
devices have different default resolutions: pdfwrite defaults to
720dpi, while jpeg and png16m to 72dpi; the display device defaulted
to 96dpi (maybe it's the host adapter's resolution).

tlvp

unread,
Sep 8, 2012, 9:56:27 PM9/8/12
to
A comparable annoyance (with similar etiology, I warrant) is MS Word's
tendency to reflow lines upon a change in your choice of default printer.

Cheers, -- tlvp
--
Avant de repondre, jeter la poubelle, SVP.

deed...@gmail.com

unread,
Sep 9, 2012, 3:54:30 PM9/9/12
to
Check for this with the transform and itransform operators, Adobe app print headers always had a scrap of code to lock down to the device grid. I don't remember exactly but after you move to your starting point, do something like

currentpoint transform round exch round exch itransform moveto

Then show your test string and see what the new current point is. You should always advance a consistent amount, which should be the real stringwidth. You might also notice a pattern if you keep track of the CTM along with the stringwidth you are recording, there might be some correlation:

([ )show matrix currentmatrix {10 string show ( )show}forall (])show

To check for font outline differences like Helge suggested you can use the pathforall operator to walk the outline (try it with and without the grid-locking code above):

0 0 moveto /Helvetica findfont 1000 scalefont setfont
(A) true charpath

mark {/moveto}{/lineto}{/curveto}{/closepath}pathforall

/Courier findfont 12 scalefont setfont
/s 12 string def
100 700 moveto
counttomark {counttomark -1 roll
dup type /nametype eq exch s cvs show( )show
{100 currentpoint 14 sub exch pop moveto}if
}repeat

---------
Note that you may get an invalidaccess error in some environments, that magic number 1183615869 might help in such cases, do a search for internaldict and superexec, a full discussion of which is beyond the scope of a Sunday afternoon right before the 49ers kickoff.
0 new messages