Upcoming font changes
Roger B. Sidje
For example, clicking mozilla.org's checkins link, and viewing the diffs
with bonsai shows the patches in a larger fixed-width font size than
Nav4.x (that's bug 32536: "text gets wrong font size", and I guess
I am not the only only who don't use Mozilla to view bonsai diffs
because of the problem...). There are also some core issues that are
more severe and apparent to i18n.
The font changes are aimed at addressing these issues from their root,
providing therefore a better foundation for the long term.
If you look at the screenshot:
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=42985
the left image shows the expected rendering whilst the right image
shows the current rendering that one will get on the trunk (provided
your build is MathML-enabled and has the needed fonts...). As the ugly
overlapping on the image imply, layout is allocating insufficient
heights to the strings. The height being used is in fact the height
where ASCII characters would fit. That's a manifestation of the
dreaded bug 20394: "[TEXT] change layout engine to get font heights
dynamically {ll}".
Another example experienced by those who attempt to change the font-size
of 'Monospace' on the Fonts preference dialog. Sometimes, it seems to work.
Other times it doesn't seem to work at all. Curiously, sometimes also it
seems to work in unexpected ways. Lurking behind this pref is something
internally known as "-moz-fixed" which in reality doesn't play nice with
"monospace", its CSS generic namesake, and although it is doing what
it is supposed to be doing, users are simply confused.
The font changes are aimed at fixing such bugs as well as consolidating the
foundation of the font sub-system with other elements that add flexibility
in the selection of multiple fonts associated to the CSS generic fonts.
An important aspect of the fix revolves around adding a function called
GetDimensions() in the nsIRenderingContext API. To better understand why
it is needed, you will have to read bug 20394 and bug 74186. In brief,
since font-switching may arise when rendering a string fragment, it is not
enough to use GetWidth() and nsIFontMetrics::GetMaxAscent/GetMaxDescent.
Rather, it is important to think of a string in terms of its |nsDimensions|.
GetDimensions() provides the information equivalent to what TeX uses for its
placements. Depending on the context, one can get string metrics via
GetDimensions() and choose to ignore them. But the bottom line is that its
availability provides a means to make layout rather robust in the face of
erratic intl fonts needed for full Unicode support now and in the long run.
Unfortunately, its support doesn't come for free. All platforms have to
implement it. And this is blocking the whole migration process - bug 96609.
Code-wise, the function has little extra performance impact, if at all (cf. the
patches attached to the bugs) but at the rendering stage, the caller is required
to send back the computed nsDimensions::ascent. This has resulted in adding a
|mAscent| member field in nsTextFrame -- the chief consumer of the new APIs.
When another |mAscent| creep in, I can only mention yet again that changing
nsIFrame::mRect to nsIFrame::mArea would alleviate the problem - bug 64763.
Perhaps someday, this other core bug would eventually be fixed.
Below are some bugs (not including their dependencies) that could potentially
be solved by the font changes:
- bug 20394 - [TEXT] change layout engine to get font heights dynamically {ll}
- bug 30910 - Pref for minimum font size
- bug 32536 - text gets wrong font size
- bug 61883 - Smarter default prefs for the 5 basic CSS fonts
- bug 74186 - Unable to choose different size for serif and sans-serif fonts
- bug 96535 - Font sizes too large for Japanese UI
---
RBS