Last Comment Bug 311046 - Some stretchy gryphes dissapear in Deer Park
: Some stretchy gryphes dissapear in Deer Park
: fixed1.8
Product: Core
Classification: Components
Component: MathML (show other bugs)
: Trunk
: PowerPC Mac OS X
-- normal (vote)
: ---
Assigned To: rbs
: Hixie (not reading bugmail)
: Anthony Jones (:kentuckyfriedtakahe, :k17e)
Depends on:
  Show dependency treegraph
Reported: 2005-10-04 06:02 PDT by YAMASHITA Makoto
Modified: 2005-10-23 20:26 PDT (History)
1 user (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

patch (1.58 KB, patch)
2005-10-19 01:55 PDT, rbs
roc: review+
roc: superreview+
asa: approval1.8rc1+
Details | Diff | Splinter Review

Description User image YAMASHITA Makoto 2005-10-04 06:02:47 PDT
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20051002 Firefox/1.6a1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20051002 Firefox/1.6a1

Deer Park a2 on MacOSX has some trouble with stretchy font rendering. Larger
root gryphes are not displayed in the "Torture Test" #13 and so are the
over/underbraces ("glue" part in particular) of #19 and #22.
Zooming in makes these rendered correctly. This problem was not encountered in
Firefox 1.5b (with copied, ref bug #228804 comment #7).
I put the screenshots at
Further, I edited and to
change the "glue" part of these gryphes to "not relevant to the char" (\uFFFD) like
\u221A = \uF8FF\uFFFD\uF8FF\uFFFD\u221A\uF8FF\uF8FF\uF8FF # Sqrt, radic (the
forth of the right hand side is changed)
and got preferable rendering, see the screenshot page.
I have no idea what the point in dissociating the glue parts which *become*
rendered quite fine.
Is this specific to Mac? Should this tweak be incorporated as the fix for this
problem, or should we fix the code to avoid similar paradoxes in, say, STIX

Reproducible: Always

Steps to Reproduce:
1. Download the nightly build of Firefox
2. Go to
3. See the tests #13, #19 and #22

Actual Results:  
Larger root gryphes disappears, overbraces and underbraces are shattered (no
"glue" parts)

Expected Results:  
Correct rendering like the sample images in the left column
Comment 1 User image YAMASHITA Makoto 2005-10-12 02:37:45 PDT
Firefox 1.5b2 is with this problem (and the same procedure works for it) too.

> I have no idea what the point in dissociating...
Having that said, I now suspect the canges made to
(between v1.109 and v1.110 "Prevent gaps in stretchy chars") might have someting
to do with this.
THe glue gryphes from Mathematica fonts look very small in the encoding table, 
they might be cut down to zero-size and causing troubles... So that zooming in
makes this problem dissapear.
I don't know what fix to do so can anybody check this?
Comment 2 User image rbs 2005-10-19 01:55:18 PDT
Created attachment 200059 [details] [diff] [review]

This is a regression from bug 307157. I should have been more careful to avoid
turning the glue into nothingness. This patch makes sure to clamp the amount by
which the glue is pretended to be smaller than it is. 

The glue in Mathematica fonts can really be tiny:
Comment 3 User image Asa Dotzler [:asa] 2005-10-19 11:30:34 PDT
Comment on attachment 200059 [details] [diff] [review]

please don't request approval until you've got sufficient reviews, landed and
been verified on the trunk. Thanks.
Comment 4 User image rbs 2005-10-19 17:29:12 PDT
Checked in the trunk.
Comment 5 User image Asa Dotzler [:asa] 2005-10-20 17:41:16 PDT
Comment on attachment 200059 [details] [diff] [review]

too late for non-critical bugs in this release.
Comment 6 User image rbs 2005-10-20 20:13:07 PDT
Comment on attachment 200059 [details] [diff] [review]

drivers, I am re-requesting approval because it is a _critical_ fix. Without
it, many of the achievements that have gone into getting MathML on the Mac are
annihilated. As you might recollect from my earlier requests, MathML is all
about appearance. Without this fix, there are ugly "holes" in strecthy MathML
characters, leading to formulas that don't make sense -- we get meaningless
renderings such as these:

instead of these correct ones:
Comment 7 User image rbs 2005-10-23 20:26:12 PDT
Checked in the 1.8 branch.

Note You need to log in before you can comment on or make changes to this bug.