Re: U.F.O. 3 Implementation Questions

On 6 December 2013 15:18, Frank Trampe <[email protected]> wrote:
> 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?

Yes! UFO is used as a file interchange format, so that you can edit a
font in several task-specific editors at the same time. So if you LOSE
information when round tripping a UFO through FontForge, this is a
disaster.

Therefore, one simple 'unit test' style test to apply to the UFO
load/save code, is that opening a UFO and the saving it with a new
file name should give a 0 size diff. This is formally called 'binary
idempotence' I believe. http://en.wikipedia.org/wiki/Idempotence

> 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?

I think almost all data described by UFO is supported in FontForge
already, and anything missing should be trivial to add.

http://fontforge.org/sfdformat.html may help you, tho its out of date
compared to the code.

> Dealing with stuff in the data directory is similarly tricky since Fontforge
> isn't a native U.F.O. editor;

You are making it a native UFO 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?

I don't like it - it will get lost :)


Supposing we wanted to make ufo2sfd round trip, I think a nice thing
about SFD is that they are self contained single files. I forget which
standard FF uses -
http://en.wikipedia.org/wiki/Binary-to-text_encoding#Encoding_standards
- but it has one of those to store eg the license text as a binary
embedded SFD, with line returns etc preserved, which could be reused.
I think. I hope someone else could comment.

But making ufo2sfd round trip isn't my goal. I just want UFO to be
fully supported in FontForge. Anything in data is outside the UFO
spec, so for sfd2ufo we can use it, but if a non-fontforge UFO is
loaded with stuff in the 'data' dir, and then the font is saved to a
non-UFO format like SFD, non-FF stuff in the data folder should be
discarded.

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

They are in the NAME table. The LangName entries in SFD represent this data.

> 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?

I will do.

> 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?

I can try... :)

http://dmtr.org/ff.php#Font says

"Note: The layers that live in the font are different from layers that
live in a glyph. These objects do not have the Layer type documented
earlier."

FontForge has this structure:

Font -> Layer
Font -> Layer -> Glyph

UFO has this structure:

Font -> Layer -> Glyph

I guess we can have a FF convention to support the Font -> Layer
objects, similar to the public.* convention described in
http://unifiedfontobject.org/versions/ufo3/layercontents.html -
perhaps like public.background we can have fontforge.guide.* ?

-- 
Cheers
Dave

------------------------------------------------------------------------------
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