Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.postscript > #950 > unrolled thread

Strange (to me) stringwidth behavoir

Back to article view | Back to comp.lang.postscript

Contents

  Strange (to me) stringwidth behavoir "Jeffrey H. Coffield" <jeffrey@digitalsynergyinc.com> - 2012-09-08 08:39 -0700
    Re: Strange (to me) stringwidth behavoir Helge Blischke <h.blischke@acm.org> - 2012-09-08 18:51 +0200
    Re: Strange (to me) stringwidth behavoir SaGS <sags5495@gmail.com> - 2012-09-08 10:22 -0700
      Re: Strange (to me) stringwidth behavoir deedubman@gmail.com - 2012-09-09 12:54 -0700
    Re: Strange (to me) stringwidth behavoir tlvp <mPiOsUcB.EtLlLvEp@att.net> - 2012-09-08 21:56 -0400

#950 — Strange (to me) stringwidth behavoir

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

[toc] | [next] | [standalone]

#951

Jeffrey H. Coffield 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
> -----------------------------------------------
> 
> 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

I suspect the reason is that, on different platforms, there are different 
variants of Helvetica implemented.

Helge

[toc] | [prev] | [next] | [standalone]

#952

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).

[toc] | [prev] | [next] | [standalone]

#954

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).

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.

[toc] | [prev] | [next] | [standalone]

#953

On Sat, 08 Sep 2012 08:39:32 -0700, Jeffrey H. Coffield 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
> -----------------------------------------------
> 
> 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

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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.postscript

csiph-web