12.85 KB, image/png
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008043007 Minefield/3.0pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008043007 Minefield/3.0pre The character U+FF62 (⌈) is sometimes rendered vertically stretched when it should be rendered at normal proportions. This happens only with the STIX fonts installed (the STIX fonts are recommended for proper MathML rendering in Firefox 3). The problem is not present in Firefox 126.96.36.199 Reproducible: Always Steps to Reproduce: 1. Install the STIX fonts 2. Go to the linked URL and observe this special character in the 2nd and 3rd rows beginning with "print" in the Algol 68 example. Actual Results: The characters are approx 3 lines high Expected Results: They should be only 1 line high, as in Fx2 (or without STIX fonts installed)
Component: General → GFX
Product: Firefox → Core
QA Contact: general → general
Not blocking until we get confirmation that this is a bug. Karl, can you comment? Reporter claims that these are the recommended fonts for MathML ... Renom if new information makes you think this is a serious issue.
Flags: blocking1.9? → blocking1.9-
The character in the URL is U+2308 LEFT CEILING. (I'm not sure exactly what character Algol used in 1968 though.) The font-family specified in the document is "monospace" and lang="en". Apparently our preferred fonts for that combination don't support the character so font-fallback is happening. STIX fonts are recommended for MathML. This character is supported by several different fonts from STIX: STIXGeneral, STIXSize1, STIXSize2, STIXSize3, STIXSize4, STIXSize5. However, these each have the same code point represented at different sizes, and which of them gets used is more or less random (I guess). A solution could be to somehow cause STIXGeneral to be preferred. (Maybe the the non-normal sizes should have used PUA code points.) A hack-around could be to include STIXGeneral in the font.name-list.*.* prefs (or prefs for common symbols from all langs such as font.name-list.common.*) but I'm not entirely comfortable with that. What fontconfig seems to do is prefer the font that supports the most characters in the language, which works well here (and tends to give more consistent-looking rendering). Maybe that heuristic could be used on other platforms. (It would mean that code2000 would be used for fallback often, but then there's a chance that might happen anyway.)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Character U+FF62 is sometimes rendered stretched with STIX fonts installed → Character U+2308 is sometimes rendered stretched with STIX fonts installed
A font.fallback.blacklist might be simplest, but the problem may go away by itself in the next release of STIX fonts. http://www.stixfonts.org/ currently says: we are building "math tables" that should be compatible with Word 2007 and discussing how to rearrange the font assignments of glyphs for the final production version." "math tables" require all sizes to be in the same font, so they would not share the same code point.
Hardware: PC → All
Summary: Character U+2308 is sometimes rendered stretched with STIX fonts installed → [win32] some characters are rendered large/stretched with STIX fonts installed
Product: Core → Core Graveyard
Component: GFX → GFX: Thebes
Product: Core Graveyard → Core
QA Contact: general → thebes
This is also a problem with U+27E8 and U+27E9 in non-MathML content on Mac OS X. I suggest blacklisting the STIX faces with huge glyphs from generic non-MathML font fallback. Marking as blocking HTML5 parsing, because HTML5 maps ⟨ and ⟩ to U+27E8 and U+27E9 (per http://www.w3.org/TR/xml-entity-names/), so existing content with ⟨ or ⟩ would regress in rendering unless this bug gets fixed.
OS: Windows XP → All
Summary: [win32] some characters are rendered large/stretched with STIX fonts installed → some characters are rendered large/stretched with STIX fonts installed
I cannot reproduce with hg:560eb81389cc. Fedora 12 x86_64 stix fonts 0.9
On Linux, fontconfig choose the order of fallback fonts used to support the character, and prefers those that support the document language. STIXGeneral supports many document languages and so will be preferred in those cases. The situation is likely different on other platforms (I don't know how fallback fonts are prioritized there), and possibly even on Linux when the document language uses a script not supported by STIXGeneral.
This could be addressed as part of bug 560472, if we decide to do something along those lines.
(In reply to comment #5) > A font.fallback.blacklist might be simplest, but the problem may go away by > itself in the next release of STIX fonts. This is unlikely, unfortunately. The current STIX fonts are a beta set; the first production release, expected shortly, will be a similar collection of multiple fonts designed to make all the glyphs available without relying on complex OpenType support in the application. As such, the potential for "bad" fallback will still be there. *After* this upcoming release, the intention is to prepare a Word2007-compatible unified OpenType version that would collect all those differently-sized glyphs into a single font and access them via OT tables. But that's still some way off.
FYI, the STIX 1.0 fonts were just released (finally!) and I just installed them yesterday. I came across this bug today and I can say that it is still a problem as Jonathan expected.
IT seems this bug is still true, who is going to own this work?
It would be useful if anyone can actually verify that this occurs under any operating system other than Windows/XP, the operating system it was originally reported under. It is now set to all platforms, however I have tried to duplicate this under Windows 7 and also under Linux and am unable to do so. I have no problem duplicating this under Windows/XP though.
(In reply to Bill Gianopoulos from comment #15) > It would be useful if anyone can actually verify that this occurs under any > operating system other than Windows/XP, the operating system it was > originally reported under. > > It is now set to all platforms, however I have tried to duplicate this under > Windows 7 and also under Linux and am unable to do so. > > I have no problem duplicating this under Windows/XP though. Although perhaps that is because Linux and Windows 7 have some other font installed by default that it ends up using that is lacking on Windows/XP. So that although the testcase does not fail, the underlying issue is still present.
As a workaround for Windows/XP, you can install the DejaVu Font package and set your Firefox fonts as follows: Serif: DejaVu Serif Sans-serif: DejaVu Sans Monospace: DejaVu Sans Mono The DejaVu fonts have defined glyphs for all characters and therefore obviate any fallback issue.
The wide DejaVu Serif will also make several sites which assume Times-like metrics somewhat uncomfortable ...
(In reply to Szabolcs Horvát from comment #18) > The wide DejaVu Serif will also make several sites which assume Times-like > metrics somewhat uncomfortable ... Sites that want Times like metrics should not be using the default whatever the user chose serif font. HTey should be specifying Times specifically.
Does this still reproduce?
The STIXGeneral fonts have now been deprecated for a long time. I would resolve this bug as worksforme.
You need to log in before you can comment on or make changes to this bug.