-
Notifications
You must be signed in to change notification settings - Fork 21
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
Description of some constants in MATH table needs clarification #285
Comments
Not sure whether I should open a separate issue for this, but there is currently some discussions in https://github.com/mathml-refresh/mathml/issues/69 about what the default values should be in MathML Core. The relevant section in the spec is https://mathml-refresh.github.io/mathml-core/#layout-constants-mathconstants Last years I had created a table with some possible values from TeX, OpenType MATH, MathPlayer and browsers: https://mathml-refresh.github.io/math-constants.html More specifically, I have three questions for Microsoft:
|
|
@SergeyMalkin Thanks for the feedback. More comments:
Someone suggested underlineThickness form https://docs.microsoft.com/en-us/typography/opentype/spec/post#header which should be also the same as https://docs.microsoft.com/en-us/typography/opentype/spec/os2#ss and the thickness of the underscore character (U+005F LOW LINE). Do you think you could add a suggestion like this as the fallback value?
Thanks. So I guess you plan to fix that?
Suggesting 1/24em sounds good to me as we need the fallback to work for arbitrary font size. |
I am experimenting with the math table values in a WPF control. There might be something in my code you could use visualize the table values. https://github.com/flideros/fSharp-Symbolic-Math-Lab |
@SergeyMalkin @fred-wang : The opening comment for this issue pertained to "shift" values. But the discussion later brought up rule thickness, radical kerning and spaceAfterScript. It's not clear what changes are being requested. If changes are desired in regard to any of these other three items, I think it would be helpful to open a separate issue for each, and revise the title of this to focus on the "shift" issue. |
@fred-wang : I'm wondering if you're monitoring and can provide clarification. Thanks. |
@PeterCon Sorry I missed your previous comment. I can open separate issues later. |
@fred-wang Thanks. I'm also trying to get clarity on what example wasn't currently clear in regard to "shift", and wonder if you could provide some clarification on that. As I read the spec, I understand these as positioning adjustments, with the values given as the size of the position adjustment from the initial glyph position. From Sergey's initial comment when opening the issue, he mentioned potential ambiguity wrt baseline vs. math axis, though if the values are adjustments (rather than resulting offsets) it doesn't seem ambiguous to me. But apparently the current wording wasn't as clear enough to avoid confusion for some (hence probably many). If you can clarify was was creating confusion, that would help. Thanks |
@PeterCon I think in general https://docs.microsoft.com/en-us/typography/opentype/spec/math does not really say how to interpret the parameters, so one has to read the TeXBook and figure out what is the correspondence and interpretation. Ideally, the spec should be self-contained. Regarding shifts, these are the only things we have: "Shift — Defines a vertical shift applied to an element sitting on a baseline." which I can agree is understandable once you already know how to place things, but not sure it really discards an interpretation like "amount of which the baseline of the numerator is shifted away from the math axis". I believe https://www.tug.org/~vieth/papers/bachotex2009/ot-math-paper.pdf was initially used by Gecko/WebKit, but Figure 2 is confusing because the math axis is the same as the baseline. Similarly, in table 2 of this pdf the StretchStackTopShiftUp/StretchStackTopShiftUp are said to match zeta11 and zeta12 and figure 1 draws these zeta's with respect to the ink bottom/top of the base, not with respect to the baseline. |
Proposed fixes for the next version: In the text immediately prior to the table defining the MathConstants table:
Descriptions of spaceAfterScript and radicalKernBeforeDegree:
|
Various shift values in constants section are applied from default position on baseline. Spec should be clear about this. Otherwise, things like fraction numerator shift-up can be interpreted as offset from math axis (i.e. position of fraction bar).
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
The text was updated successfully, but these errors were encountered: