Re: U.F.O. 3 Implementation Questions

Dear Dave,

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

I agree.

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

That's a little strong, perhaps we can say normal(ufo) == normal(ff(ufo)). That is FF doesn't have to save the UFO in exactly the same plist order or surface textual format as every other tool out there.

One thing I think that is needed is some kind of normalization of ufo that allows for easy version control. I wonder if we were to tweak the output process of ff, whether ff could become that normalizer? Is this something we would like to see happen? For example, a line based vcs is going to do a better job on:

	<key>ascender</key><integer>1010</integer>

than

	<key>ascender</key>
	<integer>1010</integer>

which is what we have at the moment.

Although something like this is probably open to debate as to what is really needed for good vcs.

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

I think a standard mapping between ff and public.* would be helpful.

Yours,
Martin

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