[Openfontlibrary] Font File Type and Admins?

[Gustavo Ferreira]

hi george,

responding to your comments/questions:

>>>UFO has no support for ligatures nor any other substitutions (no GSUB at
>>>all).
>>
>>ufo stores opentype features in a dictionary which lives in the lib.plist.
>>
>>the standard key for the opentype entry is "org.robofab.opentype.features" - see
>> also http://robofab.org/objects/lib.html.
>
>This page contains no useful information.
>
>Giving me a standard key is no help since the data to be stored are
>quite complex. I have no idea how those data should be formated and the
>page you refer me to does not describe it.

please give me some days and i'll make a sample ufo file for you.

but, basically, opentype features are stored as a dictionary in the lib.plist – the names of the features  
are the keys, the substitutions are the values (as strings). like this:

(...)
<key>org.robofab.opentype.features</key>
<dict>
	<key>liga</key>
	<string>feature liga {
sub f i by fi; 
sub f f by ff; 
} liga; 
	</string>
	<key>salt</key>
	<string>feature salt { 
sub g by g.alt; 
} salt; 
	</string>
</dict>
(...)

this is just a way to store the features inside the ufo file. using fontlab, it is still necessary to hit the 
compile button in the opentype window to make the features work.

but there are other ways and tools to include opentype features in a font. for large families, for 
example, it is better to store the features in separate files so they can be easily shared between the 
fonts. in fontlab it is possible to import features from text files; the adobe fdk (afaik) also stores 
features in separate .fea files.

i just looked at fontforge and couldn't find a way to work with opentype features there. i opened an 
opentype-cff font in fontforge; i can see what features the font has with the "show aat" option, but i 
haven't found a way to access the opentype code and work on it from inside fontforge.

how/where should one work with opentype features in fontforge?
(i'm on mac osx, fontforge version 15/july/2006)

>Furthermore, kerning >is< an opentype feature, and it is already stored
>outside of the lib object. Which suggests that not all features are
>stored here.
>
>I am prepared to believe that RoboFab stores these data, but without
>better documentation I cannot duplicate their behavior.

kerning can be done with classes (opentype or not) or without classes (flat kerning). 

here is some information about the different types of kerning in fontlab:
http://groups.msn.com/fontlab/tipsandtricks.msnw?
action=get_message&mview=0&ID_Message=1109

the robofab kerning object (font.kerning) is a dictionary representing flat kerning, and is stored as a 
separate file called kerning.plist. 

opentype kerning is opentype code, so i think it is stored in the fontlib with all the other opentype 
features.

>>>UFO appears to support the ttf 'name' table -- but only for one language
>>>(which to my mind renders this support useless).
>>
>>this can also be stored in a dictionary in the font.lib.
>
>Of course it can. But if I go off and extend UFO to support something
>that RoboFab does not support then that's useless, as they won't update
>those data correctly. They need to define support for this in their
>format. Then I will be able to implement it.

i should correct what i wrote in my previous email: naming information belongs to the font.info 
object, so it should be stored in the fontinfo.plist file and not in the lib.plist.

you can extend .ufo to do anything you want - in fact, many foundries/designers do that.

ufo doesn't have standard fields for opentype-specific names because this object was broken in 
fontlab 4.6 – acessing it would cause fontlab to crash. this has been fixed in fontlab 5, so i believe 
that some foundries/designers have already implemented these fields internally. i suppose this has 
not been included in the ufo documentation because of compatibility reasons with 4.6 users. (the 
same is true for hints.) 

i think you can go on and implement it in a way that works for fontforge. it's just a matter of adding 
the fields you want to the fontinfo.plist, and writing a script to transfer this information to the 
appropriate fields in fontforge.

>>ufo has limitations, for example lack of support for either ps or tt hints and
>>bitmaps. but then every 
>>glyph has a lib which can be used to store custom stuff...
>
>In other words you are saying that I can extend UFO/GLIF to support the
>minimal requirements of a font format. But if I do that those data will
>not be recognized by RoboFab. This is not my format. I can't extend it,
>I can't implement things which are not documented.
>
>So I continue to believe that the UFO/GLIF format -- as described on
>their website -- is not adequate for production work. That's why I
>didn't bother to implement it when it was first brought to my attention.

what i am saying is that ufo/glif is an open, extensible, customisable _source_ format.

robofab recognizes anything that is part of the robofab object model*; for other things, it's just a 
matter of writing scripts to extract custom information and put it somewhere else. as ufo, robofab is 
open, extensible, customisable.

* http://robofab.org/objects/model.html

robofab is _widely_ used for professional production work – most major type-foundries use it exactly 
because of that. but each foundry has its own workflow, quality standards and private tools and 
customises robofab/ufo according to its own needs. 

by not bothering to implement robofab/ufo you are ignoring the needs of professional type-
designers, preventing fontforge to be used by experts and isolating fontforge users.

robofab can do a lot of things with font data, but for the most important things in font-design it still 
depends on the fontlab environment:

- to display outlines and edit them visually
- to perform complex outline operations
- to generate font binaries

...and this is the reasons why type-designers still need to use fontlab.

you said fontforge can now read and write .ufo files – that's an important step. now there are "only" 2 
features missing...

- support for python-scripting
- having robofab and fontforge objects talking to eachother

how difficult is it to implement these two features into fontforge?

i would be very glad to help you with it, since i would like to be independent from fontlab. i'm not a 
programmer, but i have some python knowledge and am a fontlab/robofab user. i can offer you 
feedback and testing if you want.


best regards,
- gustavo.


ps: have you ever talked to erik van blokland about all these issues? i can imagine he is very 
interested in having robofab working with fontforge. and if somebody can help you implementing it, 
then that's him and just. 


ps2: i have just talked to erik. his answer to the question "how difficult is it to implement these two 
features (python scripting / robofab object model) into fontforge?" is: "python needs to be compiled 
into the app binary. This is all C or C++. then more work in C to make connections between python 
objects and internal font and glyph data".

this sounds like a lot of work, and i understand that you are probably not willing to undertake this.

i might find time to look at fontforge's own scripting engine someday. or not. we'll see...

best,
- g.