Re: Cut-off characters

[poynton@xxxxxxxxxxx (Charles Poynton)]

(A copy of this message has also been posted to the following newsgroups:
comp.text.frame)

David Cramer <dacramer@videon.wave.ca> writes to the Framers,

> ... I believe I found a reference to cut-off letters
>  in a really old Framers thread

He quotes a recent query from a colleague of his:

> in our German manuals we are still encountering subtle (and 
> not-so-subtle) font changes once the FrameMaker source files have
> been sent to Production as PDF files. In particular, "long" letters, such 
> as "g" and "y" are "cut-off" at the bottom.

This behavior results from what I consider a serious bug in FrameMaker -
all versions, as far as I know, but certainly all from 4.0 through 5.5.6. 
I wish I could give you a short answer - "Adobe is fixing it." However, the
bad news is that I have explained it to people at Adobe several times 
over the past several years, and anyone I've tried to explain it to 
there hasn't got the drift.

THE BUG

For text placed in a text frame within an anchored frame (e.g., a figure
caption), the extremities of certain character "glyphs" on the top line,
bottom line, left edge, or right edge, are susceptible to being clipped.

THE WORKAROUND

Whenever you place a text frame within an anchored frame, either

(a) make sure that no boundary of the enclosed text frame comes within 2
points of the enclosing anchored frame, or

or

(b) make sure that the top and bottom boundary of the enclosed text frame
are at least 2 points from the enclosing anchored frame, AND ensure that
every paragraph format within the enclosed text frame has both left and
right indent of 2 points or greater.

My choice of 2 points is based upon the maximum "overhang" of any
character at any reasonable text size.

THE DETAILS

The problem arises from the relationship between the coordinate system of
character glyphs (shapes), defined in the font, and the coordinates 
at which FrameMaker sets text within text frames.

The primary datum of a glyph (in western languages) is on the baseline,
near the left edge of the glyph. Below the baseline you can imagine a
latitude line at the bottom of the descenders. Above the baseline you can
imagine two latitude lines, one at x-height, another at caps height.

The basic measurement of a typeface is the body size. Every mark from
any glyph must lie within the body height. (Different typefaces all of
10-point body size may appear to be different sizes, because the typeface
designer can make the caps height and the x-height anything he or she 
likes, within the body height.) Marks may be placed above the caps line,
and below the descender line; that depends upon how the designer wanted
the typeface to look.

The baseline does not live at a standardized latitude within the body
height - that is left as a  parameter for the type designer. However, in
any page composition system that can mix typefaces, arrangements must be
made for the BASELINES of the different faces to be lined up. (This
necessitates the bodies NOT necessarily being at the same elevation for
different typefaces, even when all at the same point size.)

In the design of FrameMaker, the design decision was made that the
reference baseline lies 1/3 of the way up the body height. When text
with fixed line spacing is set in a text frame, its baseline lives 2/3 of
the point size down from the top of the frame. (I use fixed spacing
exclusively, because it leads to better typography. If the first
paragraph in the text frame has automatic [non-fixed] spacing, its baseline
will be placed at an offset down from the top of the frame equal to 2/3 of
the point size of the largest character in the line.)

In FrameMaker, portions of a glyph that extend outside the text frame are
retained. Consequently, the problem never appears on a text frame
placed directly on the page. However - here is the problem - a text frame
within an anchored frame is unconditionally clipped by the enclosing frame.
If a text frame abuts its enclosing anchored frame, and Frame's [1/3, 2/3]
assumption is exceeded by a particular glyph, then portions of that glyph
will be lost. I find it an objectionable artifact, even in  ten-point type
on a 300 dpi laserprinter, because the chopping is quite abrupt. Even 
if most glyphs in a font are printed correctly, without clipping, it 
is very common for a few glyphs in a font to have excursions above 
the caps height, or below the nominal descender depth. The typeface
designer must be allowed to include these excursions, because they are
necessary to achieve a consistent optical height. Next time you're walking
along the street next to a parked FedEx truck, examine the FedEx logotype -
you'll notice that the bottom of the "e" and the bottom of the bowl of the
"d" extend quite far below the baseline. If those features were to lie
exactly on the baseline, it would seem from a distance that the "e" and the
"d' were set above the baseline - the baseline would be seen to wiggle up
and down. A similar situation pertains up at the caps line.

To prevent this behavior in FrameMaker, you must sacrifice alignment and
offset the frame downward slightly, say a point or so (for typical body
type size). This means that you can't achieve good typography by simply
dragging a figure caption to the top of its anchored frame and letting it
snap to the top boundary -- if you do that, your characters are susceptible
to being clipped. When you drag a text column by its upper edge within an
anchored frame, FrameMaker will snap it to the anchored frame boundary.
However, in that position, the characters within are susceptible to being
clipped. I drag text frames there, but then perform this sequence from
muscle memory: Option-click, Command-Option-P, tab, tab, 2, Return. That
offsets the frame down vertically by two points.

There is an analogous  problem in the horizontal dimension. FrameMaker sets
type in a text column starting at the horizontal datum for a glyph - in
western languages, a point on the baseline, near the left edge of the
character. But the typeface designer can choose to have a "negative side
bearing" where some marks are made to the left of that point. An example is
the "beta" character - the tail of the beta is to the left of the character
position datum. In Times-Italic, the "fi" and "fl" ligatures have negative
side-bearings. When placed in a text frame directly on the page, the edges
of these characters appear cropped on-screen, but print properly. However,
when enclosed in a FrameMaker anchored frame with an Offset from Left of
zero, these characters are cropped on display and upon printing. In
Times-Italic, the beta character is the worst case: to avoid Frame's poor
behavior you must manually introduce an Offset from Left of about 1/5 of
the point size.

The typeface designer can also give a glyph a positive right 
side-bearing. Frame's width calculations might find the character 
fitting at the right-hand end of the line, but have portions of the 
character make marks to the right of what Frame thinks is the width 
of the character. Frame has access to the actual width of the marks 
made by the glyph, but the clipping thing comes into play again. So, 
leave a few points to the right of a text frame in an anchored frame.

Analogously to the vertical case, when you drag a text column by its left
edge within an anchored frame, FrameMaker will snap it to the anchored
frame boundary. However, in that position, the characters within are
susceptible to being clipped. I could execute Option-click,
Command-Option-P, tab, tab, tab, 2, Return. Instead, for any paragraph
format that I might use within an anchored frame, I set left and right
indents of 2 points. Even if the left and right boundaries of the text
frame are coincident with the enclosing anchored frame, there's two points
of clearance to prevent clipping.

The correct solution is a bug-fix in FrameMaker. Imported graphics, and
elements drawn with the Frame drawing tools, should be subject to clipping
by a surrounding anchored frame boundaries. However, any character glyph
should print in its entirety, without clipping, even if it makes marks
outside its text frame or outside an enclosing anchored frame. For 
FrameMaker to do otherwise - for FrameMaker to do as it does now -
makes it overly difficult to achieve excellent typography.

C.

[Please send courtesy copies of any posted replies by e-mail;
I'll be away from news for several weeks.]

-- 
Charles Poynton
<mailto:poynton@poynton.com> [Mac Eudora/MIME/BinHex/uu]
<http://www.inforamp.net/~poynton/>


** To unsubscribe, send a message to majordomo@omsys.com **
** with "unsubscribe framers" (no quotes) in the body.   **