Re: Font metrics in AFPDS?

On 3/18/2015 6:42 PM, James H. H. Lampert wrote:

Fellow Midrange Geeks:

My first (and so far, only) project involving both an
externally-described print file and AFPDS keywords is going rather well,
but it could be a lot better if I could determine the set-width of a
character string, in the font in which it is presented.

There are numerous fields that have too little space on the page to
accommodate the full field length, in which I'm applying variable
horizontal scaling, based on the RPG %LEN(%TRIM()) of the field. They'd
work a lot better if I could calculate the horizontal scaling from the
actual set-width.

One of those fields, in addition, is one where it would be nice if, for
values that take up less than the available space even without
horizontal scaling, I could accurately center the value (which of course
can't be done without knowing the set-width.

Surely I'm not the first one in this position?

You aren't the first, but this is a difficult problem due to the
complete lack of documentation describing 'How wide is the letter X in
font 222?' Letter I? Letter i?

The last time I did this I printed every character I wanted, in each
font I wanted and used vernier calipers to measure width. (These days,
inexpensive digital calipers make this job a lot simpler!) Then I built
a character-width/font table so I could calculate (to a first
approximation) how wide a given string would be in a given font.

That of course is usually the opposite of what I want to know - what I
really need to know is what font will 'shrink' the string enough to fit
in 'this many' inches. Which makes the problem one of iterating through
the various font calculations until one finds the one that fits best.

This is somewhat compute intensive when printing thousands of documents
each having dozens of these fields. A shortcut, therefore, is to do a
one-time calibration run. Say you're trying to fit a product
description into a 3 inch wide field. Read each product record,
calculate the width that each font would occupy, and take the average
for each font. Also take the standard deviation so you can form an
opinion about how many rows will fall outside your 'this fits' criteria.
Having done that, you can hard code the font based on the average
size/font instead calculating it on the fly for each individual product.

That's not so easy to do if one is distributing a software package and
every client has a different data set (and therefore a different set of
average width/font numbers).

It would be a lot easier if the DDS had a FONT(*FIT) keyword, which
ideally would be more like FONTFAMILY(*COURIER *FIT). I doubt that IBM
is remotely interested in improving their AFPDS printing capabilities at
this late date, but it wouldn't hurt to ask.