Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for character-level and glyph-level mirroring of RTL operators #277

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

icesfont
Copy link

@icesfont icesfont commented Jan 6, 2025

Depends on #276.

Please see #67 and https://people.igalia.com/fwang/mathml-operator-mirroring-explainer.html.

This augments the various steps that get the glyph for the character in the "layout of operators" algorithm to additionally mirror the character/glyph in RTL writing modes, using Unicode's BIDI or OpenType's rtlm respectively.

spec.html Outdated Show resolved Hide resolved
spec.html Outdated
<ul>
<li>
If <code>c</code> can be mirrored, then return
the glyph corresponding to the result of mirroring <code>c</code>, and exit with success. [[BIDI]]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you please give us some references to the spec definition of "can be mirrored" and "mirroring"? That will help review this patch.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure -- in particular, it's this section of UAX9:

https://www.unicode.org/reports/tr9/#Mirroring

OpenType rtlm falls under HL6, I believe, so no check on Bidi_Mirrored is necessary:

https://www.unicode.org/reports/tr9/#HL6

The "corresponding codepoints" mentioned are given in Data9:

https://www.unicode.org/reports/tr41/tr41-34.html#Data9

spec.html Outdated
the glyph corresponding to the result of mirroring <code>c</code>, and exit with success. [[BIDI]]
</li>
<li>
Otherwise, if there exists an OpenType rtlm variant of the input glyph, return that and exit with success. [[OPEN-FONT-FORMAT]]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similarly for rtlm.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

spec.html Outdated Show resolved Hide resolved
spec.html Outdated
Otherwise, if there exists an OpenType rtlm variant of the input glyph, return that and exit with success. [[OPEN-FONT-FORMAT]]
</li>
<li>
Otherwise, return the input glyph and exit with success.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The algorithm is always successful... so I guess we don't need to specify "with success" here and elsewhere?

I think we indeed don't need to fail when a glyph is not mirrorable in RTL, we should just stretch the non-mirrored glyph.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I agree, I've added this extra fallback step. I initially explicitly specified "with success" since I thought that this could fail if it wasn't possible to get any glyph for a codepoint (i.e. if the font didn't map one), but comparing this to the old version of the spec this should be fine(?).

spec.html Outdated Show resolved Hide resolved
spec.html Outdated Show resolved Hide resolved
spec.html Outdated Show resolved Hide resolved
spec.html Outdated Show resolved Hide resolved
@icesfont icesfont force-pushed the feat/rtl branch 3 times, most recently from 7ed76b0 to 349f89b Compare January 14, 2025 22:21
@icesfont
Copy link
Author

I forgot to reference it, this is related to this issue: #67

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants