Different endings when typing continuous letters

[Ridder, Fred]

Janet Underwood wrote:

>One of my students has asked a question I've never encountered or
thought 
>about before. He asks why he can type the letter "d" continuously and
the 
>line will go all the way to the right margin, but if he types the
letter "x" 
>continuously on a line, it wraps to the next line before reaching the
right 
>margin. He points out that other letters end at different places and
then 
>wrap to the next line. Any ideas?

In the interest of improved legibility on relatively low resolution 
devices like CRT or LCD monitors, the default configuration for
FrameMaker's screen display allows uses fixed widths for 
individual glyphs that may differ slightly (by sub-pixel amounts) 
from the width of the same glyph as reproduced by a relatively 
high resolution devices like laser printers. The line-wrapping 
logic, on the other hand, always uses the printer metrics (the
precise widths of the individual glyphs as reported by the 
printer driver) when determining where to break lines. 

In normal text using a proportional font and not using fully
justified alignment, the positive and negative deviations in width 
(the amount by which screen characters are wider than or 
narrower than the corresponding printed characters) tend to 
average out and you won't notice large deviations in line lengths.
(In fully justified text, you won't see line length difference at 
all because the inter-word spaces are adjusted to make all 
the lines equal length.) But if you repeat the same character
over and over, the width differences accumulate and line length
differences between become very noticeable. The line wrap
logic only displays as many characters per line as the specific
printer will actually produce, but the on-screen display of that
line may be narrower or wider than the printed line. In cases 
the on-screen display may show lines extending beyond the 
right-hand margin (or in extreme cases, commonly with 
monospace fonts, even beyond the page edge) in the on-screen
display. In the specific case you cite, the screen metrics of the 
"d" glyph apparent match the printer metrics fairly well, while
the screen version of the "x" glyph is apparently narrower than
the printed character. 

It's interesting to note that in the kind of test you describe 
(repeated characters with no spaces) you'll actually see the 
line length differences with a fully justified alignment as 
well as a ragged-right alignment because there are no 
inter-word spaces for FrameMaker to "fudge" to make things 
come out right. It's also worthwhile to note that the magnitude 
of the line length deviations (both absolute magnitude and 
relative magnitude between specific character pairs) will 
change as you change fonts (each font has its own unique 
metrics with different round-off errors for low-resolution display), 
when you change Windows printers (the font metrics come 
from the printer driver, and there may be subtle differences 
from one model to another), and when you change the 
FrameMaker zoom factor (the sub-pixel round-off errors are
a much smaller percentage of the on-screen character widths
at higher zoom factors).

But if you prefer to see the actual lengths of text lines in the
on-screen display, the Windows version of FrameMaker allows 
you to force the display to match the printer metrics, but with
some small sacrifice in the rendition of individual glyphs (a few
letter shapes may be slightly distorted in some lines) and 
inter-glyph spacing (some letters in some words may touch
or may appear to have extra space between them), particularly
with FrameMaker set to 100% or smaller. All you need to do is
open the maker.ini file (in the base FrameMaker installation 
directory) with a text editor and alter the value of the 
DisplayUsingPrinterMetrics parameter from its default "Off"
to "On". (This item is about half-way down in the file, which
is many hundreds of line long.) Remember to quit FrameMaker 
before editing maker.ini and to save the edited file as plain
text if you are using a word processor to do the editing.

My opinions only; I don't speak for Intel.
Fred Ridder (fred dot ridder at intel dot com)
Intel
Parsippany, NJ