Now, save for the size of big operators in display style, I think they are almost identical.

Show thread

I should move on to extensible operators (like brackets, overset arrows, etc) but I'm laaaazy

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 https://github.com/simoncozens/sile/pull/578, 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: https://docs.microsoft.com/en-us/typography/opentype/otspec170/math

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?

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. https://github.com/lokedhs/maxima-client/blob/47c147325bd8d1b0ea46f7c2b00d2c3cef779861/src/renderer.lisp#L593

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 discovers math typesetting

@loke https://github.com/OlivierNicole/sile/blob/bigop/core/math.lua#L455 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).

otini discovers math typesetting

@tfb

I have read parts of it. But it talks about TeX, and as far as I remember doesn't go into the rules for laying out equations. After all, this knowledge is encoded in TeX itself, so if you're using that tool, there is no need to know all of that.

The place I found that contains all of this is the TeX source code. It's written using literate programming and can be typeset as a book. It's very detailed though and it takes time to find things.

@otini

otini discovers math typesetting

otini discovers math typesetting

@otini

I see. Extra opentype information isn't exposed to McCLIM at the moment, and I didn't even know such information was available in opentype.

I guess I'll have to investigate this some more, and perhaps improve the McCLIM interface to it.

However, I've managed to get a decent result even without it so perhaps it's acceptable.

@tfb

@otini I'd say yours is the one on the left because the spacing between the subscripts and the variables in the second line seems off.

@abs And you are right.

@otini That's really quite good, but the size and alignment of the sub and superscripts still needs work. (Yours on the left, TeX on the right)

@otini spacing before the word "text"

@axiom Ah yes, I forgot to say: I don't yet work on integration of math into text. Once I have more math operators implemented I will tackle the issue (as well as line breaking inside math).

otini@otini@functional.cafeThis is a challenge for typographers (which I am not). Can you tell apart our rendering (amateurish) from LuaLaTeX's?