Re: [Fontforge-devel] Fontforge generated UFOs

[<ve...@ne...>]

Ok so it's not just me then? :)

Problem may lie with Robofab's implementation, or a combi of both implementaions i guess.

I haven't had time to test this fully but so far i have noted that the FForge generated UFOs fail to open in Metrics Machine & Area 51.

They do however open fine in Prepolator and most of the time in Superpolator. 

Getting them into Fontlab via the various Robofab import tools is patchy. Importing a UFO as a new font file allways fails for me (both RoboFab & UFOcentral), though importing individual glyphs via RoboFab seems to work fine.

I'm not the smartest :) but this makes me think that the main offending breakage is not at UFO glyph level? but at UFO font level somewhere?

vernon


On 12 Feb 2011, at 11:26, Schrijver wrote:

> I’ve been looking into this.
> 
> The UFO’s generated by Fontforge are quite different from those generated with RoboFab (which powers the UFO implementations in both Fontlab and Prepolator)
> 
> For proper versioning, ideally, they should be as similar as possible: then, in collaborative projects, both users of Fontlab and of Fontforge could make contributions.
> 
> To test, I roundtripped the (RoboFab generated) Open Baskerville UFO through FontForge: I opened it and generated it as a font with the same name.
> 
> here’s a colored diff:
> http://schr.fr/tlkng/ufo-roundtrip.html
> 
> (or, in git: https://github.com/klepas/open-baskerville/tree/fontforge-roundtrip (though there’s no easy way to check out just this branch in git if I’m not mistaken))
> 
> Some things that struck me:
> 
> -- The *.glif files get their underscores in a different place
> A _ should be added after a capital letter for case-insensitive platforms. FontForge appends the _ to the end of the filename, whereas Robofab adds it right after the letter.
> FF makes Aacute_.glif instead of A_acute.glif and CR_.glif instead of C_R_.glif
> But I’m reading the spec now, and it actually looks like FontForge is the one following the spec…
> http://unifiedfontobject.org/filestructure/glyphs.html
> I’ll ask on the RoboFab mailing list…
> ’Cause what Robofab does is this:
> http://www.robofab.org/howto/glifnames.html
> 
> -- The features.fea file is called feature.fea and doesn’t contain the features previously defined in features.fea
> 
> -- ascender and descender values are changed to fontforge defaults
> 
> Cosmetic details, but important for versioning:
> 
> To be the same as robofab, glif files should:
> -- have unicode hex values be uppercase
> -- lines and curves default to smooth="no", so you can leave this off
> -- in robofab, components without offset values come first (don’t know the implementation details of that)
> 
> And there’s more, I don’t know exactly what is causing the crashes.
> But it would be great if we could work to make the UFO export functionality as robust as possible..
> 
> Cheers,
> 
> Eric
> 
> 
> 
> Op 12 feb 2011, om 00:20 heeft ve...@ne... het volgende geschreven:
> 
>> Are the UFO's generated by Fontforge 'buggy' ?
>> I have noticed that UFOs from fontforge often fail to open properly in Fontlab, Prepolator etc.
>> 
>> Is this documented at all?
>> 
>> many thanks
>> 
>> vernon
>> ------------------------------------------------------------------------------
>> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
>> Pinpoint memory and threading errors before they happen.
>> Find and fix more than 250 security defects in the development cycle.
>> Locate bottlenecks in serial and parallel code that limit performance.
>> http://p.sf.net/sfu/intel-dev2devfeb
>> _______________________________________________
>> Fontforge-devel mailing list
>> Fon...@li...
>> https://lists.sourceforge.net/lists/listinfo/fontforge-devel
> 
> 
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Fontforge-devel mailing list
> Fon...@li...
> https://lists.sourceforge.net/lists/listinfo/fontforge-devel