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