search

simoncozens / rust-font-tools

A collection of Rust crates for building OpenType fonts
Apache License 2.0
64 stars 11 forks source link

TrueType node order is weird #3

Closed simoncozens closed 2 years ago

simoncozens commented 2 years ago

Acceptance tests are failing for PathOrder.ufo because I haven't quite worked out the order that nodes should be stored in the glyf table. It works fine except where there is a curve at the start or the end.

If anyone else (@madig) would like to investigate this while I'm away for the next couple of weeks: the node list from the source files is loaded by babelfont-rs, then converted into kurbo curves in babelfont::Path, then the cubics are converted to quadratics in the top half of fonticulus::glyph::babelfont_contours_to_glyf_contours, and the second half rearranges from Kurbo curves into truetype glyf nodes. I'm not sure initial conversion to kurbo curves is correct - the initial move command looks weird - and I'm not sure the final rearrangement into glyf nodes is correct either.

But PathOrder.ufo should be a good and pretty thorough test case. Run PYTHONPATH=Lib pytest test/harness.py -k PathOrder to see what's going on.

schriftgestalt commented 2 years ago

The general idea to handle nodes it to look for the last oncurve node in the list and use that as the initial moveTo. Mostly that would be the last node but there are cases that there are some off curve nodes until you find the oncurve.

simoncozens commented 2 years ago

OK. I have now got Glyphs files working, but the Glyphs node order and UFO node order is different. Glyphs stores the oncurve node last, UFO stores it first. Your suggestion of finding the last oncurve and rotating is what the Norad code - designed to work with UFO files - does, and fonticulus stole that code. The weird, weird thing, is that this approach works fine on Glyphs paths, but does not work for UFO paths!