libertinus
libertinus copied to clipboard
alerque
Math style fixes
There is a number of open issues relating to mathematical glyphs, mainly addressing style inconsistencies. Some are oversights, some are orphans from earlier versions. The overall number of mathematical glyphs is overwhelming, so I follow a per-need basis. List of changed glyphs: LibertinusMath_compare.pdf
Resolved issues
- Fixes #406. I decoupled the ± glyph. The upper arm is a bit longer for optical symmetry. The minus lies on the baseline, not below, because this glyph is more often used with numbers and in-line text, as compared to, for example, ≤. (same choice in STIX) The set operators were also changed, see below. I decided not to narrow the <,> glyphs, because the angle of 52° and the size is quite standard for a math font. I would not see the original narrow glyphs as a design choice, because the mathematical glyphs in Linux Libertine were not designed for a mathematical font that needs big operators. In my opinion, the current version offers optimal legibility and can be more easily distinguished from ≺, ≻.
- Fixes #348. The vertical bar is now thicker, 50 points, and has 80-80 bearings (previously 81-80). I mainly encounter this glyph as a bracket and it definitely looks better in this role. I didn't change anything in the text fonts, which also holds for other mathematical glyphs. For the time being, I see it as a safe choice. I didn't touch the division and fraction slashes, U+2215 ∕, U+2044 ⁄. The reason is that they seem to be tied to other Unicode glyphs like fractions and units. I never see them as standalone glyphs. In math, there is always a normal solidus U+002F used for division, which has a standard thickness 50.
- Fixes #347. Here I went to other fonts for guidance, because from my hand-writing and school experience, the logical and set operators were always put on the baseline. It seems that both conditions need to be met - the math axis and the baseline. Becuase the set operators ∩, ⊂, should be just rotated versions, this imposes a condition for square symmetry. The operators are now consistent. I also revised my initial decision to compose them of a circular arc and two straight lines. Now, they are more pleasantly rounded in my opinion.
- Fixes #346. Fixed height, thickness, and style.
Issue #345 discussion
Some of the glyphs from #345 have been addressed, but I am not convinced about all of them. I don't think that all caps should necessarily be rounded. I am not familiar with the symbolics of some glyphs like ∾; some like delta and nabla should not have rounded edges, because neither does the corresponding Greek delta; some symbols like geometric shapes or musical sharp sign are not mathematical symbols. The sigma sum could have rounded edges like the Greek sigma, but the person who drew and scaled the bigger version of the sigma and pi operators U+220F, U+2211, clearly knew what they were doing, and I didn't want to disrupt this operator set. We can discuss this one. This is why I haven't marked #345 as resolved.
Operator alignment
In #347, the issue of operator alignment was referenced. The idea is that the vertical position of the operators should follow the numbers and the features lnum, onum. This would be neat in some situations, but generally I would advise against it. The main reason is different usage (at least in my experience, which is math and physics). I have never seen any number-related OTF features in math mode. The operators are centered on a math axis because, in most math in my experience, the operators are put between letters, not numbers. The math axis is a compromise that should work for both lowercase and uppercase letters. Old-style numbers would basically require a separate axis corresponding to lowercase letters. As far as I know, old-style numerals are never used in math. This whole feature would also most likely require duplicating all operators just for this feature. That is why I don't think it's worth it.
I will ping the individual issues to allow some discussion. I am also going to count on @alerque to handle the changelog and commit squashing upon merge.
I thought I already nailed it, but now that I'm looking at the PDF, I am thinking whether the arc in uni2221 and uni2222 should not extend more beyond the wedge. What do you guys think?
Having only taken a look at the attached PDF, the changes seem to be for the better :) Looking forward to seeing them in a live document.
In #347, the issue of operator alignment was referenced. The idea is that the vertical position of the operators should follow the numbers and the features lnum, onum. This would be neat in some situations, but generally I would advise against it. The main reason is different usage (at least in my experience, which is math and physics). I have never seen any number-related OTF features in math mode. The operators are centered on a math axis because, in most math in my experience, the operators are put between letters, not numbers. The math axis is a compromise that should work for both lowercase and uppercase letters. Old-style numbers would basically require a separate axis corresponding to lowercase letters. As far as I know, old-style numerals are never used in math. This whole feature would also most likely require duplicating all operators just for this feature. That is why I don't think it's worth it.
As I introduced the idea, let me clarify it.
Libertinus Serif has a case feature (we could wish for a few more glyphs, but that's already great). This allows for example (the third hyphen is a hyphen.case glyph):
I think a math axis that would be a compromise between the uppercase and lowercase (oldstyle) figures would be poorly designed. And I speak voluntarily of uppercase and lowercase figures, because in my opinion they shouldn't be seen otherwise, and the terms of "standard figures" and "old-style figures", although more conventional, obscure what should be their correct perception and treatment. In fact, I firmly believe that there should be as many math axes as there are figures cases, i.e. one or two for most fonts: if there are only uppercase figures or only lowercase figures, a single math axis, and if there are both, two math axes.
Libertinus Math only has uppercase figures, and, fortunately, its mathematical axis is not a compromise, but it's that of uppercase figures and uppercase letters (I'll come back to this).
So my remarks would be more directed towards Libertinus Serif (and I saw that wasn't the subject of this thread, but let's talk about it anyway). Libertinus Serif has lowercase figures, and the math axis is aligned to the axis of "letter operators", like hyphen:
Where things go wrong is when you put the text in all caps (InDesign has a feature like this, it change the case and activate lnum and case features): the figures follow (they become uppercase), the hyphen too, but not the math operators:
While it should be like this:
And coming back to Libertinus Math, it's actually well designed on this point: its math axis couldn't be much different from the uppercase letter axis (in the following example everything is in Libertinus Math except the hyphen, which is the hyphen.case of Libertinus Serif):
Hope it's clearer like this. I'm not arguing for lowercase figures to be added to Libertinus Math. But if this were to happen, or for fonts that have two figure cases (like Libertinus Serif), you need to take care of the two math axes: one in the same vertical axis as hyphen, dash, etc., and the other in the same vertical axis as hyphen.case, dash.case, etc.
I decoupled the ± glyph. The upper arm is a bit longer for optical symmetry.
I find the old glyph to be optically balanced than the new one. The old glyph is also closer to the Computer Modern one. In STIX Two math font, the plus and minus are not attached, but the lower arm is the longer one.
@thlinard I see that you are arguing the principle, not an implementation. From typographical point of view, I agree with your examples of uppercase/lowercase figures, and that operators should ideally follow the height of the glyphs that surround them. However, the problem to which I was referring, is that only one math axis is permitted by the OpenType format. As far as I know, this parameter is used to draw fraction lines so that fractions align with common horizontal operators. If one shifted all the operators, the elements that depend on the math axis parameter – like fractions – would be misaligned. For this reason, a suitable compromise needs to be found, because mathematical formulae use both uppercase and lowercase glyphs. Perhaps it's poor design, but it is a necessity.
I noticed that in your last picture, the math operators are placed very high and do not correpond to the math axis of the font. Is there something else at work? My math renditions look like this:
@khaledhosny I don't have any strong preference on this. In #406, it was argued that some of the design choices from Linux Libertine should be maintained so that that the typeface does not imitate Computer Modern too much. I think I read @alerque's comment somewhere where he was in favour of splitting the ±, but I can't find it. STIX does have a variant where the length ratios are different, but contrary to CM, the plus does not align with the + glyph. Also it seems to me that it makes the plus look uneven, but it's a subjective impression. Let's first decide on which variant is better, and if we pick the decoupled glyph, I'm more than happy to get advice on good optical balance. We can also put the minus below the baseline.
I noticed that in your last picture, the math operators are placed very high and do not correpond to the math axis of the font. Is there something else at work? My math renditions look like this:
You're right, my bad. This is the correct example:
For Libertinus Math, I agree the problem is probably insoluble. The chosen math axis doesn't really work with lowercase surroundings (too high) and doesn't work neither with uppercase surroundings (too low), but it does indeed seem difficult to do otherwise. It must be said that Libertinus has one of the smallest x-height (with Latin Modern and Garamond Math) among the math fonts that I know and that doesn't help: with less contrast between the lowercase height and uppercase height, the compromise would be less visible.
On the other hand, for Libertinus Serif (or Libertinus Sans, for that matter), we can very well consider two mathematical axes. Figures and math symbols in Libertinus Serif don't serve quite the same purpose as in Libertinus Math: rather for short, much simpler formulas (and besides the operators aren't the same size). The problem wouldn't arise if there were only uppercase figures, but since there are both, it would be consistent if there were two sets of operators.
The onum feature in Libertinus Serif contains only 0123456789. In Stix Two Text, it contains 0123456789$€£, and 0123456789$€£¥₹₺₽ in Cambria. We could imagine a few more symbols, closely related to figures (%‰°), but above all an alternate set of mathematical operators as found in common charsets (~<>=×÷+−¬±∞≈≠≤≥◊).
Regarding the changed length of “equality-like” symbols such as ⊆:
Maybe it makes sense to have these symbols all have the same consistent length (i.e. the length of the equality sign). This should (hopefully) ensure that when these symbols are aligned underneath each other, the contents next to them are aligned as well.
This PR is already going more in this direction, but is still a tiny bit off.
current version
new version (from this PR)
@cionx I am open to changes, but that would be too many conditions on the set operators :-) See the third point in my initial post – I believe that the set operators should be on the baseline, but also centred around the math axis. This creates a unique condition on the height of ⊂. Additionally, other set operators like ∩ should be just rotated (and on the baseline and around math axis). This creates a condition on square symmetry and makes it impossible to scale the width to match the equals sign. I think that the difference is tiny and the alignment can be handled by the typesetting engine. Also in my experience, one usually needs to align equals/less/more symbols rather than a mixture of arithmetic and set operators.
Having revisited this PR, I hope I can summarize the remaining open questions.
- The ± glyph. Should it be joined or not, and how the optical balancing should be done. Accepting any advice (or decisions from Caleb).
- uni2221 and uni2222, maybe the arc should extend a little bit more.
- uniform width of relational operators. I generally honor this principle, but I believe the set operators should be an exception for the reasons above.
I decided to modify the plusminus a bit; I don't think it has to align with the plus, these two symbols will never be side-by-side anyway. I think it now looks good in context:
The symbols uni2221 and uni2222 now have the circular arcs extending a bit more, which looks better in smaller font sizes.
Up-to-date changelog:
LibertinusMath_compare.pdf
@alerque I do not plan on making any further changes, as I think everything has been resolved.
@ivo-s anyway to fix this issue? https://github.com/alerque/libertinus/issues/464
@ivo-s anyway to fix this issue? #464
That is a big one and not really the subject here. I gave it a few hours here and there, but I most likely won't have time to tackle it in the near future. If I remember correctly, there are compromises to be made between italic-style font bearings for characters that follow each other to look natural, and italic correction that both symmetrizes the character in upright context and influences sub- and superscripts. Cannot tune all three independently.