Re: U.F.O. 3 Implementation Questions
vernon adams <[email protected]>
| Newsgroups | gmane.comp.fonts.fontforge.devel |
|---|---|
| Message-ID | <[email protected]> |
> > 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. A main point of UFO is easy and fast movement from app to app in real time, i.e. 4 apps working on the same UFO file; save in one, file is updated in all others. For this to work effectively FF must write UFO’s that do not lose any data that the other apps have written, and, do not add any data that would hinder the other apps updating that ufo into their GUI’s. So, the nearer FF generated UFO’s are to say Robofont generated UFO’s the better, imo :) -v > > 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> ------------------------------------------------------------------------------ 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