U.F.O. 3 Implementation Questions

Hi, folks.

I'm working on adding support for U.F.O. 3 to Fontforge. I've worked on
Fontforge before, but I'm not yet an expert on the code base and have some
questions. Dave suggested that I post these to the main list in order to
get added perspective and depth.

As things stand, the U.F.O. handler writes out only values that Fontforge
uses (except when dealing with lib.plist), I think. For example, a value
specified for PostscriptOtherBlues in an incoming U.F.O. would not appear
in output.

Is this a problem? If so, we would need to extend internal data structures
and s.f.d. in order to losslessly accommodate foreign information, unless
some feature like this already exists. Thoughts?

Dealing with stuff in the data directory is similarly tricky since
Fontforge isn't a native U.F.O. editor; perhaps s.f.d. could have an
extension for an associated support files folder that gets copied into any
exported U.F.O.s. Thoughts?

Do we want to implement openTypeNameRecords? What's the corresponding
Fontforge entity?

Looking at fontforge/woff.c, it seems that the WOFF metadata just gets
dumped as a string, which is not how U.F.O. expects it. Can somebody send
me a sample WOFF file with metadata so that I can test conversions?

Fontforge (judging from the code) seems to store layers as children of
splinechars and also as children of splinefonts, and U.F.O. (judging from
the specification) seems to store them as parents of glyphs. Can somebody
explain this scheme better to me?

------------------------------------------------------------------------------
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk

_______________________________________________
Fontforge-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fontforge-devel