There are a number of font issues that have been around for some time. 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
