431559 - some characters are rendered large/stretched with STIX fonts installed

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[Szabolcs Horvát]

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 2.0.0.14

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)

Comment 1

[Szabolcs Horvát]

Attachment: Comparison of the rendering in Firefox 2 and Firefox 3

Comment 2

[Mike Beltzner [:beltzner, not reading bugmail]]

--> Core::GFX

Comment 3

[Mike Beltzner [:beltzner, not reading bugmail]]

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.

Comment 4

[Karl Tomlinson (:karlt)]

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.)

Comment 5

[Karl Tomlinson (:karlt)]

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.

Comment 7

[Henri Sivonen (:hsivonen)]

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.

Comment 8

[Takanori MATSUURA]

I cannot reproduce with hg:560eb81389cc.

Fedora 12 x86_64
stix fonts 0.9

Comment 9

[Takanori MATSUURA]

And
html5.enable;true

Comment 10

[Karl Tomlinson (:karlt)]

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.

Comment 11

[Jonathan Kew [:jfkthame]]

This could be addressed as part of bug 560472, if we decide to do something along those lines.

Comment 12

[Jonathan Kew [:jfkthame]]

(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.

Comment 13

[Jaquez]

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.

Comment 14

[Bas Schouten (:bas.schouten)]

IT seems this bug is still true, who is going to own this work?

Comment 15

[Bill Gianopoulos [:WG9s]]

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.

Comment 16

[Bill Gianopoulos [:WG9s]]

(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.

Comment 17

[Bill Gianopoulos [:WG9s]]

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.

Comment 18

[Szabolcs Horvát]

The wide DejaVu Serif will also make several sites which assume Times-like metrics somewhat uncomfortable ...

Comment 19

[Bill Gianopoulos [:WG9s]]

(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.

Comment 20

[u279076]

Does this still reproduce?

Comment 21

[Frédéric Wang (:fredw)]

The STIXGeneral fonts have now been deprecated for a long time. I would resolve this bug as worksforme.

Comment 22

[Gregory Pappas [:gregp]]

Closing per comment 21