[Openfontlibrary] Font site wishlist

Tue Oct 31 10:18:27 PST 2006

<topPost />

Could you please start a page for this new font file format

http://openfontlibrary.org/wiki/index.php/Ideal_Font_Format

This way, we can start to track this. I would say first of all, that I
put my faith in standards, so how we could use SVG would be great.
Possibly, we could do this and expand the spec with specific
OpenFontLibrary namespace. Also, this way we could drive the future SVG
font specifications with our needs...which to me is the right approach
to get large scale adoption. Also, it would be great to develop this
spec so that it is large enough scale to be a mother/source format for
most of the other formats out there.

However, I would like to reiterate that we should keep our eye on the
prize as to this project, which is to collect open fonts :) So, however
we can support this aim through what you all are talking bout is
important...

Jon

On Tue, 2006-10-31 at 08:24 -0800, George Williams wrote:
> 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?
> 
> _______________________________________________
> Openfontlibrary mailing list
> Openfontlibrary at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openfontlibrary
> 
-- 
Jon Phillips

San Francisco, CA
USA PH 510.499.0894
jon at rejon.org
http://www.rejon.org

MSN, AIM, Yahoo Chat: kidproto
Jabber Chat: rejon at gristle.org
IRC: rejon at irc.freenode.net