Closed Bug 960115 Opened 6 years ago Closed 6 years ago

Restrict the cases where a scale transform is applied to operators

Categories

(Core :: MathML, defect, P5)

defect

Tracking

()

RESOLVED FIXED
mozilla31

People

(Reporter: fredw, Assigned: fredw)

References

(Depends on 2 open bugs)

Details

Attachments

(1 file, 1 obsolete file)

Currently we apply scale transforms to MathML operators when

1) It is a large op / integrals and we don't have a glyph of appropriate size.

2) It is a stretchy operators and either we don't have appropriate fonts to draw it or to correct the stretched size when it does not exactly match the target size.

3) It is a mirrorable operator in RTL mode.

I initially thought that the correction in 2) was an improvement but TeX does not do that and e.g. on the Torture Test some people don't want the radical to exactly match the size of its content but to go down below the base. Also, there are issues to consider like e.g. scaling changing the thickness of the radical hook or adding rounding errors etc.

When we have support for math fonts and better positioning and measuring with the MATH table, the scaling workaround becomes less necessary and even undesired. So I suggest the following:

For 2), only apply the scale when we don't have an appropriate size variant / construction. Also, don't apply it when it would distorse the glyph too much (bug 848725) but raise a signal so that the UI can warn about missing math fonts.

For 3), once bug 945183 is fixed, only apply the scale when we don't have an appropriate mirrored glyph.
Priority: -- → P5
When moving to MATH table I suggest to not apply a scale at all if we detect a MATH font; the missing big glyph is either a font feature or font bug and we should do nothing in Gecko for this. So this leaves only the case of a system with no MATH fonts at all (or user explicitly requesting a non-MATH font), here the situation is already poor so scaling is actually an improvement. Personally, I’d just not bother with scaling/transforming at all, it never was good (Now if we had dynamic, parametric fonts on the web, that would be an improvement over TeX).
Blocks: 947654
Attached patch Patch (obsolete) — Splinter Review
Extract this part from bug 407059.
Comment on attachment 8404896 [details] [diff] [review]
Patch

Review of attachment 8404896 [details] [diff] [review]:
-----------------------------------------------------------------

This patch modifies 2): when we found a variant/construction to draw a stretchy op, we no longer apply the transform to get closer to the target size. A typical example is test 13 of the torture test, where the radical will render like TeX (bottom not aligned).

For 1) and 2), we still apply the transform when we don't find a variant/construction. For MATH font, this is not what Khaled suggested in comment 1, but I think that won't make a difference in general since MATH font should have appropriate constructions (except for exotic characters like quadruple arrows). This could still be changed later.

3) will be handle in bug 945183. Again, I need to think about how to handle the current fallback VS the new MATH+rtlm support.
Attachment #8404896 - Flags: review?(karlt)
Comment on attachment 8404896 [details] [diff] [review]
Patch

>Bug 960115 - Restrict the cases where a scale transform is applied to operators. r=karl

Can you use a more descriptive comment please?

Something like "No longer scale stretchy operators when a variant of any size
is found", if that is accurate.

r=me, with that addressed, means the code is fine.

I don't see any good reasons for removing the scaling in this situation, but
it is your decision.

(In reply to Frédéric Wang (:fredw) from comment #3)
> A typical example is test 13 of the torture test, where the radical
> will render like TeX (bottom not aligned).

The TeX rendering extends the bottom of the radical further as it becomes
larger.  This change will mean that it sometimes extends below the baseline,
but how far is mostly random depending on exactly what sizes are available and
how they compare to the inner content height.

(In reply to Frédéric Wang (:fredw) from comment #0)
> Also, there are issues to consider like e.g. scaling changing the
> thickness of the radical hook or adding rounding errors etc.
> 
> When we have support for math fonts and better positioning and measuring
> with the MATH table, the scaling workaround becomes less necessary and even
> undesired.

If a font has enough variants then the additional stretching does not add much
distortion.  I don't know what the rounding errors are.  All glyphs for
scalable fonts are scaled in some way, so I assume rounding errors are either
no worse than regular glyphs or fixable.

> Also, don't apply it when it would distorse the glyph too
> much (bug 848725) but raise a signal so that the UI can warn about missing
> math fonts.

That sounds sensible to me.
Attachment #8404896 - Flags: review?(karlt) → review+
(In reply to Karl Tomlinson (:karlt) from comment #4)
> (In reply to Frédéric Wang (:fredw) from comment #3)
> > A typical example is test 13 of the torture test, where the radical
> > will render like TeX (bottom not aligned).
> 
> The TeX rendering extends the bottom of the radical further as it becomes
> larger.  This change will mean that it sometimes extends below the baseline,
> but how far is mostly random depending on exactly what sizes are available
> and
> how they compare to the inner content height.

One of the goal is to make the rendering closer to the OpenType MATH / TeX implementations. I guess it is subjective whether the scale correction is an improvement or not, but some people will just say that the rendering is bad if it does not follow TeX or does not use Knuth's Computer Modern style (I think the square root difference was mentioned again on the "drop mathml" thread on m.d.platform). I also think it would be better for font designer if they could have cross-compatible implementations of OpenType MATH (cf the issue with MinHeight).

> If a font has enough variants then the additional stretching does not add
> much
> distortion.  I don't know what the rounding errors are.  All glyphs for
> scalable fonts are scaled in some way, so I assume rounding errors are either
> no worse than regular glyphs or fixable.

One of the thing I was concerned about is e.g. bug 403958 where the scale might change the rule thickness of the glyphs and make rounding errors more unpredictable. That said, I admit my current set of patches didn't really fix that bug in all situations.
Attached patch PatchSplinter Review
Updating commit message.
Assignee: nobody → fred.wang
Attachment #8404896 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/5d5836028886
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla31
Depends on: 1045263
Blocks: 1156463
You need to log in before you can comment on or make changes to this bug.