[Openfontlibrary] Font site wishlist

[George Williams]

On Mon, 2006-10-30 at 09:11, Ed Trager wrote:
> No, please don't build version control into the font editor!  
Yes, after spending a day thinking of this, I realized this wasn't a
very good idea.
> Version
> control software is evolving all the time.  If you build it into the
> font editor, whatever choices you make will become obsolete too
> quickly.
And providing a version control UI as well as a font editor UI would be
more complex than I wish to deal with. And the potential for confusion
of novice users too great I fear.
>   It will be much better to simply make the font editor
> support some sort of SVG+XML file-system-based file format for fonts
> that all of the SCM systems - Git, SVK, SVN, etc. - will be able to
> support forever. Again please take a look at p. 16 of
> http://unifont.org/textlayout/TheBigPicture.pdf and see what you
> think.  
(Off topic, but mentioned in the paper: I don't know anything about
Graphite, but if someone from SIL wants to talk about integrating that
into FF I'd be happy to listen).

Ok, I see the reason for single glyph objects now.

As mentioned in the paper, svg doesn't support external glyphs.

UFO/GLIF is designed with each glyph in a separate file. However, adding
a glyph requires changing at least two files (the glyph file itself
needs to be added, and the contents list needs to be updated).

Personally I think it would have been better had the GLIF format
followed svg conventions.
Personally I think it would have been better if the contents file had
been omitted and all files in the glyph directory were required to
follow certain naming conventions (and were automagically included in
the font). (Perhaps there are logical constraints of the XML format
which I'm missing that require a contents file).

The big problem with UFO is how much it doesn't support, if this is
going to be a standard source format for OFLb it needs support for 
  * all of GPOS/GSUB 
     o  (and I'd like to see 'morx' as well personally) 
     o  and perhaps support for Graphite too.
  * Definitely needs support for PostScript Hints
	(per-glyph hints & private dictionary)
  * Definitely needs support for truetype instructions
	(and 'cvt ', 'prep', 'fpgm' tables)
  * support for the complexities of truetype components?
	(Use my metrics bit?)
	(component placement by point matching?)
  * full support for the 'name' table
  * support for OS/2 table
  * support for TeX information
  * some sort of hook to add extension 'sfnt' tables which aren't in
	the standard (lily pond has it's own tables. don't know what
	they do).
  * support for bitmaps perhaps?
And that's just off the top of my head.

I hesitate to extend UFO because
  1) It isn't my format
  2) I'd rather extend something based on svg as that is more likely
	to be understood. If the glyph objects were svg based more
	tools could edit them graphically. Perhaps.

> The only enhancement required of FontForge would be the addition of a
> new Save format. FontForge would remain agnostic...
Well FF now generates UFO blobs from Generate Fonts (rather than Save).
I don't think this is currently a solution, but it may be a step towards
a solution.

On Mon, 2006-10-30 at 10:19, Raph Levien wrote: 
> I don't think there's _that_ much difference between, say, UFO and sfd
> for the purpose of hosting a version-controlled repository. With UFO,
> an added glyph will show up as a new file, but there's also the
> metadata to keep track of. Having one file = one font is also simpler
> for keeping track of things
It is nice to have things all in one lump. But as someone pointed out,
downloading a 2Mb file each time a tiny change is made is a bit extreme.
  To me, with my 58kb modem, this is a telling point.
> Of course, I'm going to be implementing my own font format in the
> coming year or two, so there are lots of questions about coordinating
> that. What I've got so far is very simple, based on s-expressions, but
> I think I should take another look at ufo, for the sake of not
> reinventing the wheel too much.
Good. It would be nice to avoid even more formats.

On Mon, 2006-10-30 at 14:52, Pedro Amado wrote: 
> Don't you think it would be better to team up and
> develop the open font format UFO?
I don't think there has been much change to UFO, at least not to the
documentation on the wiki. It seems pretty similar to what I remember
when I looked at it ?a year ago?
> I don't know how the sfd works but the fact that you can use robofab to
> import/export UFO data to/from fontlab is great... maybe this can also be
> implemented on Fontforge natively by means of the API.
Ok, ok, it's there.

On Tue, 2006-10-31 at 05:32, Ed Trager wrote: 
> Having only just taken a first look at UFO, it looks pretty good to
> me.
I disagree. UFO is not currently usable as a source format for fonts.
See the list I generated above. All those issues need to be addressed
before it can be used in production.
  If all you are interested are unhinted, unligatured LCG fonts then it
is adequate, but it is missing so much needed for modern font work.
> If I were going to write an AJAX-based interactive font editor
> however, I think I would --for the purposes of such an application
> only-- drill the XML down to one-letter tags whereever possible to
> reduce bandwidth consumption and improve responsiveness.  For example,
Or use the svg format instead. Why didn't they? It's got small tags for
paths. (the other stuff can be kind of large, but the paths themselves
are small, and that's what most of a glyph file consists of).

On Tue, 2006-10-31 at 05:58, Dave Crossland wrote: 
> Ed, what do you think about extending FontForge towards being able to
> put RoboFab atop it?
If all RoboFab requires is UFO output, then that's done. What did you
have in mind?