Mathematical operators fixed and redesigned

[ivo-s]

Fixes #63, fixes #164, and fixes #227.

Mathematical operators were enlarged and vertically centred around the math axis 260. Centering is done with respect to vertical size of the glyph, or with respect to consistency among similar glyphs. Typical stroke thickness is now 50, typical operator widths are 540-550, stroke terminals are unified and side bearings are 50 on each side. Arrows are shorter to satisfy #164. Overlapping paths and references were merged together.

When deciding about alignment, proportions and style, I was guided by Latin Modern and STIX math fonts, although not too closely, because LM is very thin, round and extensive, while STIX is thick, sharp and more compact.

Table of changed glyphs and some example code (the last example is from #164):
operators_compare.pdf

Before the change, the operators were vertically centred around ~250, and less consistently so. Here is a comparison (#227):

[khaledhosny]

Can you rebase on master to fix the Travis build error?

In general I like the changes, thank you! Except the arrows, the new ones look two short. Is there a reason for making them that short, can you compare them with other math fonts?

[khaledhosny]

Also I like to keep references as practical as possible and only flatten them and remove the overlaps at build time, any reason for not doing that?

[khaledhosny]

The equal sign over U+2971 and the tilde over U+2972 and similar arrow is too thin in the new version, so should visually match the stroke thickness of the arrow.

[ivo-s]

Thanks for reviewing the changes! I will get to work on modifying the pull request. In the meantime, if you spot anything else, drop a comment here and I will incorporate the changes.

1. The arrows: it was some time ago and I actually don't remember why they are exactly this long/short. I can certainly make them a bit longer. The key requirements were that they are not too long for uses such as Resizing some math symbols #164 and that both horizontal and vertical arrows are of the same length. It was probably something like having a certain length ratio to a minus, but most likely nothing important. I noticed that LM has the vertical arrow reaching between the ascender and descender, which is probably the maximum acceptable length. I will try to come up with a good length and update the pull request.

2. I didn't know that these overlaps are corrected at build time 😮 I just saw that FontForge doesn't like overlapping stuff so I merged all paths in the new glyphs. This is really good, because I can rationalize many striked glyphs; most of them use a minus glyph that is shortened/prolonged and rotated. If there are multiple glyphs that use the same length and angle of the diagonal strike, I can make a seprate glyph for referencing. I will probably avoid messing with existing overlay strokes, because I don't want to break anything.

3. You are right. STIX has the small symbols a bit thinner, but not as much. I will fix it.

I will make the changes, rebase my branch on master and squash everything into one commit.

[khaledhosny]

Thanks.

I also see now that ↔ is much shorter than ⇔, I think they both same length (and I’d rather that be the longer of the two). Same for ↕, ⇕ and ⇳. In generals I fell that horizontal and vertical arrows of different kinds are less consistent now than they were before.

[ivo-s]

I revised and fixed a lot of stuff, below is the PDF with the up-to-date changes.

operators_compare.pdf

The arrows should be consistent. The ordinardy vertical arrows are now so long as to roughly reach to ascender height while being centred around math axis. Horizontal arrows are of the same length.

I replaced a lot of stuff with references. There are several new glyphs at the end for that purpose. They do not seem to get exported to OTF, but they are not intended for stand-alone use anyway.

The small symbols in U+2971 and others are now scaled by 0.8. It is similar to the way they are in STIX.

Sorry for multiple pushes, but I noticed Travis CI problems too late. I found out that I needed to set some unlinkRmOvrlpSave flags by hand.

[khaledhosny]

I revised and fixed a lot of stuff, below is the PDF with the up-to-date changes.

operators_compare.pdf

Looks good, thanks!

The arrows should be consistent. The ordinardy vertical arrows are now so long as to roughly reach to ascender height while being centred around math axis. Horizontal arrows are of the same length.

I replaced a lot of stuff with references. There are several new glyphs at the end for that purpose. They do not seem to get exported to OTF, but they are not intended for stand-alone use anyway.

Yes, the build script subsets the font and removed any inaccessible glyphs, but that is fine. For OTF files, references are purely a font editing feature and they don’t propagate to the generated file (CFF table uses something called subroutines which works at individual contours levels and it handled automatically by font builder).

The small symbols in U+2971 and others are now scaled by 0.8. It is similar to the way they are in STIX.

Nice.

Sorry for multiple pushes, but I noticed Travis CI problems too late. I found out that I needed to set some unlinkRmOvrlpSave flags by hand.

Sorry about that, I should have mentioned this explicitly in my previous comment.

[kauesena]

The work @ivo-s did was surely a great improvement. There were those alignment issues and the operators were indeed too small. The style of the symbols are a bit different though. I thought of redrawing the symbols in style closer to the original one. For example, keeping ⊂,≤, ± bigger but making ⊂,≤ less open and making ± disconnected. @alerque, is that a good candidate for an alternative set?

[alerque]

Yes, those redrawings are something I would consider for alternates or even replacing the current symbols. I agree the overall set of fixes was good, but I also see your style points, and those style changes were not part of the set of issues this was supposed to fix. For example ± being connected looks like an outright mistake to me. I'll have to do some research but a return to the disconnected style (but with the size, weight, and alignment fixed as in this PR) is something I would entertain.

[alerque]

@kauesena If you're going to work on this in the near future we can skip straight to a PR, otherwise can you open up a new issue for this so we don't loose track of it?

[kauesena]

Not in the near future. I'll open up an issue then.