w3c / w3c/mathml-core

Interpretation of DisplayOperatorMinHeight

Open
#126 19 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

MathML Core opentype / tex
Dominant language
HTML
Stars
56
Forks
20
PR merge metrics
No merged PRs in 30d

Description

Just converting comment from the appendix

It is not clear how the DisplayOperatorMinHeight is supposed to be used or whether it is really reliable. More specifically, integral symbols (e.g. INTEGRAL U+222B) are typically taller than N-ary operators (e.g. N-ARY SUMMATION U+2211) so a unique minimal height may not always be enough to determine the display size. Suppose for example that the sum has three size variants: the base size of height 1em, the display size of height 2em and a bigger variant of height 3em. Suppose that the integral has three sizes: a base size of height 1em, a larger size variant of height 2em and a display size of height 3em. If DisplayOperatorMinHeight is less than 3em then it does not force the display size of the integral to be selected. If it is more than 3em then none of the available sizes satisfies the condition. How to interpret that? Should we pick the largest as a fallback? If it is 3em, the desired size will be selected for the integral in display size but the one selected for the sum in display size will be too large. A heuristic is proposed in section 3.2.3 to workaround limitations of DisplayOperatorMinHeight.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading the appendix comment about DisplayOperatorMinHeight and the heuristic proposed in section 3.2.3. Review the existing discussion to determine whether the specification needs a clarified interpretation or fallback behavior, and consider the issue resolved when the expected handling is explicitly agreed and documented.

Written by the indexing model from the issue text.

Assessment

Tech stack
html
Domain
documentation
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.