On Saturday, September 8, 2012 10:22:34 AM UTC-7, SaGS wrote:
> 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).
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:
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):
