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

Description of some constants in MATH table needs clarification #285

Closed
SergeyMalkin opened this issue Aug 6, 2019 · 10 comments
Closed

Comments

@SergeyMalkin
Copy link

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.

@fred-wang
Copy link

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:

  • What is "the default rule thickness" suggested in the spec? (see first row in the table above)

  • Why is there a suggestion for radicalKernAfterDegree and radicalDegreeBottomRaisePercent but not for radicalKernBeforeDegree? Again, the corresponding row in the table above uses 5/18 em, −10/18 em and 60%.

  • For spaceAfterScript, what does "0.5pt for a 12pt font" mean? How to interpret that for different font size?

@SergeyMalkin
Copy link
Author

  • Default rule thickness: there is no recommended value, it completely depends on typeface design. It makes sense to make it equal to thickness of minus sign
  • Radical kerning: recommended values com from TeX. It was too long time ago to remember, but it is probably just an omission.
  • spaceAfterScript is a constant in TeX that doesn't change with font size. So we fixed some common body font size as a base for 0.5pt /scriptspace, but did no go as far as recommend 1/24em ratio. In Word all constants including this one are scaled linearly with font size.

@fred-wang
Copy link

@SergeyMalkin Thanks for the feedback. More comments:

* Default rule thickness: there is no recommended value, it completely depends on typeface design. It makes sense to make it equal to thickness of minus sign

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?

* Radical kerning: recommended values com from TeX. It was too long time ago to remember, but it is probably just an omission.

Thanks. So I guess you plan to fix that?

* spaceAfterScript is a constant in TeX that doesn't change with font size. So we fixed some common body font size as a base for 0.5pt /scriptspace, but did no go as far as recommend 1/24em ratio. In Word all constants including this one are scaled linearly with font size.

Suggesting 1/24em sounds good to me as we need the fallback to work for arbitrary font size.

@flideros
Copy link

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

@PeterCon
Copy link
Collaborator

PeterCon commented Sep 1, 2020

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

@PeterCon
Copy link
Collaborator

@fred-wang : I'm wondering if you're monitoring and can provide clarification. Thanks.

@fred-wang
Copy link

@PeterCon Sorry I missed your previous comment. I can open separate issues later.

@PeterCon
Copy link
Collaborator

@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

@fred-wang
Copy link

@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."
"Standard shift up/down applied"

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.

@PeterCon
Copy link
Collaborator

PeterCon commented Oct 6, 2020

Proposed fixes for the next version:

In the text immediately prior to the table defining the MathConstants table:

  • Shift — Defines a vertical shift applied to an element sitting on a baseline. Note that the value is an amount of adjustment to the position of an element, not the resulting distance from the baseline or other reference line.
  • Dist — Defines a distance between baselines of two elements.

The descriptions for several fields refer to default rule thickness. Layout engines control how rules are drawn and how their thickness is set. It is recommended that rules have the same thickness as a minus sign, low line, or a similar font value such as OS/2.yStrikeoutSize. For fields that are described in reference to default rule thickness, one of these should be assumed.

Descriptions of spaceAfterScript and radicalKernBeforeDegree:

MathValueRecord spaceAfterScript Extra white space to be added after each subscript and superscript. Suggested: 0.5 pt for a 12 pt font. (Note that, in some math layout implementations, a constant value, such as 0.5 pt, may be used for all text sizes. Some implementations may use a constant ratio of text size, such as 1/24 of em.)
...
MathValueRecord radicalKernBeforeDegree Extra horizontal kern before the degree of a radical, if such is present. Suggested: 5/18 of em.

@PeterCon PeterCon closed this as completed Oct 6, 2020
@PeterCon PeterCon added this to the OpenType 1.8.4 milestone Nov 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants