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? 😕

Follow

otini discovers math typesetting 

i can haz debuggin

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

Show thread

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

Show thread

I can't see a difference now. SILE math prototype (left) vs LuaLaTeX (right).

Show thread

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

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?

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?

Show more

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

otini discovers math typesetting 

@loke @otini Honestly, anyone doing computer typesetting should read the TeXbook. You don't need to do everything Knuth's way, but understanding his work is a good place to start.

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 

@tfb @otini
I will look up the book again though. Since both of you are saying there is useful information in there, it's pretty clear I didn't read that part.

It's unsurprising, since when I read it I wasn't interested in maths layout

otini discovers math typesetting 

@loke @tfb I would advice the beginning of chapter 17 (More About Math) which talks about the 8 possible styles (that determine font size and sub–superscript positions). This way of doing things has become so standard that it is directly present in the math features of OpenType.

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.

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

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

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!