Fontforge needs to pretty-print glyph data the same as Robofab

[codingisacopingstrategy]

To accept patches from FontForge users, the data needs to be formatted the same as the existing data—otherwise it becomes hard to track changes in the versioning system.

This is a Robofab generated font roundtripped through fontforge: http://schr.fr/tlkng/ufo-roundtrip.html There’s some more issues here but they should be addressed in separate tickets.

Robofab uses Python XML Sax which seems to work similar to Libxml2: as using Nokigiri on the ufo data works very well in maintaining the same pretty-print.

Here’s how Fontforge ideally should output the Glyph XML:

• When the curve is unsmooth, this is default, so you don’t mention it:

  <point x="424" y="489" type="curve" smooth="no"/>
  -->
  <point x="419" y="678" type="curve"/>

• hex value’s should be uppercase

  <unicode hex="00d6"/>
  --> 
  <unicode hex="00D6"/>

• outline components should be organised alphabetically:

  <component base="grave" xOffset="205" yOffset="228"/>
  <component base="O" xOffset="1"/>
  -->
  <component base="O" xOffset="1"/>
  <component base="grave" xOffset="205" yOffset="228"/>

[klepas]

Good point. I’m not yet up to speed how all this works so I’m not sure how to go about doing it.

[codingisacopingstrategy]

I’ve brought this issue up on the fontforge-devel mailing list:

http://sourceforge.net/mailarchive/forum.php?thread_name=4DC95DB8.6000001%40twardoch.com&forum_name=fontforge-devel

It’s up to the FontForge dev’s now, I hope they can implement this. I don’t know FontForge’s codebase well enough to write a patch… Anyone reading this is welcome to do so of course :)

[codingisacopingstrategy]

This actually got implemented in the FontForge codebase:

http://fontforge.git.sourceforge.net/git/gitweb.cgi?p=fontforge/fontforge;a=commit;h=691f3a187a9762d6087072eec4f2556764d5587b

Hurray! Another problem remains with FontForge output, but I will file a seperate bug for that.