otini discovers math typesetting 

These fraction rules are too thick; but which value am I to use? The math constants table of my math font (XITS) says 0.66, but 0.66 what? 😕

otini discovers math typesetting 

i can haz debuggin

Show thread

otini discovers math typesetting 

@otini Wow. That looks very similar to what I did. What did you base it on? I went through many iterations before I figured out some basics with respect to for example how a faction should be aligned with respect to the baseline.

Most of the time I was generating an expression using LaTeX and then checking how it's done there.

I even went to the source code of TeX to see how they did some things.

Is there some documentation somewhere?

otini discovers math typesetting 

@loke So this is all based on the work by Rui Xia at github.com/simoncozens/sile/pu, where he implemented the base typesetting algorithm as described by the TeXbook.

As for me, to style things I read chapters 16 to 18 in the TeXbook for general guidelines, and I use the “math constants” included in my math font. For instance, the height of the fraction rule relatively to the baseline (what Knuth calls “the axis”) is one of the constants.

otini discovers math typesetting 

@loke And I found documentation about OpenType math features, such as the constants table, there: docs.microsoft.com/en-us/typog
But it is not very satisfactory, as I complained in my initial toot.

otini discovers math typesetting 

@otini Wow. That's a lot of detail, and certainly not something I've paid attention to. 🙂 I've basically just picked measurements that seems to make sense, and the end result is OK, although not perfect by any definition.

otini discovers math typesetting 

@otini What is next for me is to try to somehow implement a line-breaking system for long expressions. I really don't know how to get started on that.

otini discovers math typesetting 

@loke The simplest way to do that would be to have predefined spots where a break can occur, e.g. before and after binary operators, and when a line is too long, break at the spot closest to the right edge.
TeX's algorithm is more complicated but produces justified text, which is probably not needed for math.

otini discovers math typesetting 

@otini I discovered that my formatting for sums and products isn't as good as yours. I'm not aligning the symbols correctly with respect to the baseline.

otini discovers math typesetting 

@loke Strange, this is something I didn't have to care about since it encoded in the font. What do you use to render the glyphs?

Follow

otini discovers math typesetting 

@otini
What is encoded in the font? The problem here is how the large sum symbol should be aligned relative to the baseline of the summed expression.

I think the solution is to align the centre of the sum symbol to the centre of the expression. The baseline of the whole thing would be the baseline of the summed expression.

I don't know how the font can help me with this calculation. It only gives me the measurements, yes?

otini discovers math typesetting 

@otini
Here's my code, if you're curious. github.com/lokedhs/maxima-clie

Do you have a repository for your implementation?

@loke The sum operator has a part that is supposed to be under the baseline, like the tail of the lowercase “y”, and that information is in the font. Here is a screenshot of that glyph in the XITS font, in Fontforge. I would expect this to be taken into account by the font renderer.

@otini But what does that look like if you have an expression that is unbalanced vertically? How does your renderer handle a sum over this expression? 1/f(a/g(d/e))

@loke I can try when I get home tonight, but I already predict that the result will look awful, as always with stacked fractions 😄
But I don't quite understand what you're trying to show me. In your renderer too, the sum operator is a big operator that takes up a lot of space. The difference between our rendering should only be the relative height of the sum operand to the sigma.

@otini Well, my problem is that the vertical alignment is off. Turns out that not even LaTeX has solved this issue, as it has exactly the same issue as my renderer. Try putting this into LaTeX:

\sum_{a=q}^{w}{{{1}\over{f\left({{a}\over{g\left({{d}\over{e}}\right)}}\right)}}}

@otini What I'm getting at is that I'm trying to understand is how the sum operator's baseline is used, since my results seem to be identical to both yours and that of LaTeX, and that's without actually using that information. I only use the top and bottom extent of the symbol.

@loke So I get this. The empty space above the a is ugly, but it's due to the parentheses around the fraction introducing an inconvenient symmetry.

@otini Actually, that was not what I was referring to (my renderer doesn' t have the problem with the a).

Instead, I feel that the entire expression hangs way too low, and instead should probably be centred vertically relative to the sum symbol.

This is because the expression is aligned based on the fraction, and the lower half is so much hether than the digit 1.

I can't solve this edge case by centring vertically because then most normal fractions would look bad.

@loke Alright, that is indeed an unsolved problem, but I didn't claim it would be solved by putting the bottom of the operator below the baseline. In fact, I didn't really do it on purpose, the font library just did it on its own ^^

@loke If I try to rephrase our debate, you think it would be better to align the vertical centers of the sigma and the summed expression, rather than having the axis at always the same position. Is that correct?

@otini Yes, pretty much that. I have a hard time thinking of a case where that would not produce good, (or even better?) results.

For measurement, I have come up with some exceptions (for example, for symbols with subscripts, I don't count the subscript when measuring dimensions).

@loke You just showed me an example where it wouldn't look nice, however.

Generally I have the impression that in most cases, it looks better to have the main fraction rule aligned with the center of the sigma.

otini discovers math typesetting 

@loke github.com/OlivierNicole/sile/ is my current implementation of big operator rendering in Lua if you're interested. The output of the glyph itself is left to the text renderer, so the code is agnostic in the big operator glyph (called `base`). The base has three dimensions: width, height (height above baseline) and depth (height below baseline).

Sign in to participate in the conversation
Functional Café

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!