Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Math operators are small #63

Closed
khaledhosny opened this issue Apr 19, 2017 · 3 comments · Fixed by #272
Closed

Math operators are small #63

khaledhosny opened this issue Apr 19, 2017 · 3 comments · Fixed by #272

Comments

@khaledhosny
Copy link
Contributor

The math operators are rather small compared to other math fonts. This might have been OK for the text font, but not so much for the math font.

@ivo-s
Copy link
Contributor

ivo-s commented Mar 12, 2019

@khaledhosny I am currently looking into this. I managed to get some work done already in my fork: https://github.com/ivo-s/libertinus/tree/math-fix
It's going well, so I decided I would see it through 😃

Because I am currently busy writing my thesis, I am only doing this in a few spare moments. So it might take a bit... If you feel like it, you can check my progress - any feedback is welcome. However, please keep in mind that some glyph references are still broken until I get to them.

The aim is to fix the most obvious issues so that conventionally typeset math looks nice. Because everything is linked, I need to:

  • resize/redraw operator glyps so that equations look balanced and comprehensive.
  • check references to everything that uses these glyphs and fix it
  • because the math axis needs to be united, all forms of brackets need to be moved/resized to be reasonably centred.
  • while I'm at it, might as well fix the brackets. The STIX glyps are sometimes too thick and the round brackets () are too round, which sometimes creates too much "air" between the wide part and some symbol after it. Also the bearings need to be optimized, because currently stuff like |0⟩ has asymmetrical spacing.
  • then, every vertical and horizontal variant and construction needs to be checked, the coordinates revised and MATH table double checked so that everything fits 😃

I plan to do a pull request after I finish with the operators, which is still a lot of work, but it's the minimal possible step that can be committed.

Some decisions so far:

I decided to use the math axis 260. It is already given in the MATH table, so it is used for constructing fractions in TeX. However, the symbols are centred around a different height, roughly 250. And the guide layer has a math axis at 290. After looking at other math fonts and considering x height, capital height, the need of brackets centering and vertical glyph descents, I decided that 260 would be best.

After studying the letter glyphs, I also decided that all stroke ends should not be straight and rectangular like in STIX, but pleasantly rounded like the Libertinus serifs (that we all love). I think it gives the font a consistent look. On the other hand, the asymmetric endinds in glyphs like + or = look like too much to me.

After everything is done, it should also resolve the issues #164 and #227.

@khaledhosny
Copy link
Contributor Author

Nice work!

The math axis should be whatever is currently on the MATH table. I vaguely recall having to change it to fix some issue, so please check closed math issues before deciding to change it.

Re-endings, I’m not very attached to the asymmetric ones, right they are in the original design but they look out of place in math, so I haven’t been paying too much attention to them in new designs.

@ivo-s
Copy link
Contributor

ivo-s commented Mar 15, 2019

Axis height: yes, 260 was originally in the MATH table and coincidentally, I thought it was the best choice. I only changed the respective guide in the guide layer and I'm using 260 for all operator glyphs - most of them were centred around 251 or so.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants