Robofab + Fontforge + fsType Table
vernon adams
it looks like this in a fontforge generated fontinfo.plist (for a font with no install or embedding restrictions) and it seems to follow the MS specs at least.
<key>openTypeOS2Type</key>
<array>
<integer>0</integer>
<integer>0</integer>
<integer>0</integer>
<integer>0</integer>
<integer>0</integer>
<integer>0</integer>
<integer>0</integer>
<integer>0</integer>
<integer>0</integer>
<integer>0</integer>
<integer>0</integer>
<integer>0</integer>
<integer>0</integer>
<integer>0</integer>
<integer>0</integer>
<integer>0</integer>
</array>
Basically, if this table is in the fontinfo.plist then e.g. Robofab fails to import the UFO into Fontlab. If I just remove the whole table from fontinfo.plist. then the UFO is imported fine. Some other python based apps Metrics Machine and Glyphs import these tables fine, but Robofab, Prepolator and Superpolator do not. I seem to remember an explanation from George Williams that fontforge's implememtation of the table is correct, but it's robofab etc that are not following the OS2 specs. ;)
-v
Erik van Blokland
On Feb 10, 9:00 am, vernon adams <vernnob...@gmail.com> wrote:
> Basically, if this table is in the fontinfo.plist then e.g. Robofab fails
> to import the UFO into Fontlab.
FontLab, which import script, a demo UFO?
If I just remove the whole table
> from fontinfo.plist. then the UFO is imported fine. Some other python based
> apps Metrics Machine and Glyphs import these tables fine, but Robofab,
> Prepolator and Superpolator do not. I seem to remember an explanation from
> George Williams that fontforge's implememtation of the table is correct,
> but it's robofab etc that are not following the OS2 specs. ;)
Tal Leming
On Feb 10, 2012, at 3:00 AM, vernon adams wrote:
> <key>openTypeOS2Type</key>
> <array>
> <integer>0</integer>
> <integer>0</integer>
> <integer>0</integer>
> <integer>0</integer>
> <integer>0</integer>
> <integer>0</integer>
> <integer>0</integer>
> <integer>0</integer>
> <integer>0</integer>
> <integer>0</integer>
> <integer>0</integer>
> <integer>0</integer>
> <integer>0</integer>
> <integer>0</integer>
> <integer>0</integer>
> <integer>0</integer>
> </array>
This is very wrong. FontForge generated this?
RoboFab and the Python based apps use ufoLib for reading and writing UFOs. ufoLib does validation on the incoming and outgoing data. So, what you are probably seeing is ufoLib tossing up an invalid data error.
Tal
Ben Kiel
--
You received this message because you are subscribed to the Google Groups "RoboFab" group.
To post to this group, send email to rob...@googlegroups.com
To unsubscribe from this group, send email to robofab-u...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/robofab?hl=en
Messages from newly joined members are subject to moderation.
Download RoboFab and documentation at http://robofab.com !DSPAM:4f34d42e27981143213823!
Dave Crossland
Tal Leming
On Feb 10, 2012, at 11:45 AM, Adam Twardoch (List) wrote:
> From this perspective, I must admit that the way the description for
> openTypeOS2Type is worded by itself is a bit weak: "A list of bit
> numbers indicating the embedding type" -- it does not give the helpful
> hint that it's only the true/enabled/on/set bits that should be
> included.
I'll fix this in the UFO 3 spec.
Thanks,
Tal
vernon adams
Basically, if this table is in the fontinfo.plist then e.g. Robofab failsto import the UFO into Fontlab.
Can you elaborate on this? which version of robofab, version of
FontLab, which import script, a demo UFO?
This is very wrong. FontForge generated this?
RoboFab and the Python based apps use ufoLib for reading and writing UFOs. ufoLib does validation on the incoming and outgoing data. So, what you are probably seeing is ufoLib tossing up an invalid data error.
Tal
Vernon:There is a standard: http://unifiedfontobject.org/versions/ufo2/fontinfo.htmlIt looks like rather than listing the bit numbers to turn on in the fsType (listed at the MS OT spec), i.e. for Print/Preview embedding it'd look like:<key>openTypeOS2Type</key><array><integer>2</integer></array>For no install or embedding restrictions, if you read the MS spec, you don't set a FS bit at all, so there would be no openTypeOS2Type key in the UFO.Looks like FontForge is listing the range of possible bit slots and then setting them to 0 or (I assume) 1 (off/on), but that's not at all how the UFO spec is written.Ben
Ben Kiel
The implementation above does make more sense to me, and i presume the fontforge implementation is based on an overly literal reading of the spec because the MS specs do state that "If multiple embedding bits are set, the least restrictive license granted takes precedence". It's impossible to set multiple bits in the implemetation above (i think), so it's arguably wrong, which i think may explain the fontforge implementation.
<array>
<integer>2</integer>
</array>
Ben Kiel
I realized that this is a bit unclear:
> Again, if you want to set no embedding restrictions in a UFO, just as the MS spec states, you set no bits, so you don't have a openTypeOS2Type table in your UFO.
One either doesn't have a openTypeOS2Type key (not table) in their ufo, or they have it, but the array is empty, like so:
<key>openTypeOS2Type</key>
<array>
</array>
I guess it's a question for Tal which way is more correct (RoboFont does the former, UFOCentral the later), but both ways seem correct from the spec.
Ben
Tal Leming
On Feb 11, 2012, at 8:45 AM, Ben Kiel wrote:
> I guess it's a question for Tal which way is more correct (RoboFont does the former, UFOCentral the later), but both ways seem correct from the spec.
It is correct either way. No openTypeOS2Type present indicates no bits are set. An empty array for openTypeOS2Type indicates no bits are set.
Tal
vernon adams
I will suggest to the fontforge developers to implement a robofab
comaptible fsType tables.
-v
Tal Leming
Tal
Ben Kiel
I'm sure that George would love a patch, looks like you could find the code to fix here:
Ben
On Feb 12, 2012, at 11:01 AM, vernon adams wrote:
> !DSPAM:4f37e25b27988148618246!
vernon adams
i've looked before at the fontforge source for clues, and in the code
for outputting the fsType is the following noteable comment;
/* Now the spec SAYS we should output bit >numbers<. */
/* What is MEANT is that bit >values< should be output. */
:) To be honest i'm not over concerned which is the correct
interpretation of the spec - i just want to be able to import
fontforge UFOs into fontlab easy, just like i can import them into
Robofont, Glyphs, Metricsmachine and the *polators. I'm concluding
that there are different interpetations of the spec, but robofab and
UFOcentral only allows 1 of them :)
-v
Tal Leming
On Feb 12, 2012, at 2:39 PM, vernon adams wrote:
> :) To be honest i'm not over concerned which is the correct
> interpretation of the spec
Arrrggghhhh! This is very frustrating. I'm the UFO spec editor and I'm stating FOR THE RECORD, based on the information that has been presented by you in this discussion*, that the FontForge implementation is wrong.
*I have not performed a code review for FontForge. That's not my job so I can only go off of the limited information that you have provided.
> - i just want to be able to import
> fontforge UFOs
There is no such thing as a "FontForge UFO" or a "RoboFab UFO" or a "Glyphs UFO" or a "RoboFont UFO" or a "<insert UFO reader/writer here> UFO." There is only one UFO spec. FontForge is writing invalid UFOs. Just as you can't put a bunch of garbage in the middle of a PNG and expect browsers to render it correctly, you can't write a file that is labeled as a UFO that does not follow the UFO spec and expect UFO readers to be able to read it. That's simply not possible. This is why specs exist and have to be followed.
> I'm concluding
> that there are different interpetations of the spec, but robofab and
> UFOcentral only allows 1 of them :)
No! That is a completely incorrect conclusion. There is one spec and if someone implements it incorrectly that's not a "different interpretation." It's a bug in the implementation. Not a bug in the spec. Not a bug in everything else.
Tal
Ben Kiel
> /* Now the spec SAYS we should output bit >numbers<. */
> /* What is MEANT is that bit >values< should be output. */
This comment in the FontForge code is wrong. It is the author the comment reading the UFO spec, then deciding that what the spec says is not what the author of the comment has decided that the spec means. This does not mean that the author of the comment is right, which from reading what the spec says, I believe that all can agree that this comment's author has mis-interpeted the spec. No big deal, it's an honest mistake (and mis-reading specs happens all the time, see CSS), but one that can be easily corrected to make FontForge compliant with the UFO spec as it is written.
> Robofont, Glyphs, Metricsmachine and the *polators. I'm concluding
> that there are different interpetations of the spec, but robofab and
> UFOcentral only allows 1 of them :)
>
There may be more than one interpretation, but there is only one correct interpretation. All that you can take away from your ability to import a UFO made incorrectly in FontForge into other applications, is that those applications aren't as strictly checking the validity of the openTypeOS2Type key in the fontInfo.plist.
This will cease to be a problem with the bug in FontForge is patched.
Best,
Ben
> -v
>
> On 12 February 2012 17:35, Ben Kiel <b...@houseind.com> wrote:
>> Vernon,
>>
>> I'm sure that George would love a patch, looks like you could find the code to fix here:
>>
>> http://fontforge.git.sourceforge.net/git/gitweb.cgi?p=fontforge/fontforge;a=blob;f=fontforge/ufo.c;h=ea8e92289f2e26954f272cf65920a9e217cb8cb1;hb=HEAD#l575
>>
>> Ben
>>
>> On Feb 12, 2012, at 11:01 AM, vernon adams wrote:
>>
>>> Many thanks, very clear now.
>>> I will suggest to the fontforge developers to implement a robofab
>>> comaptible fsType tables.
>>> -v
>>>
>
> --
> You received this message because you are subscribed to the Google Groups "RoboFab" group.
> To post to this group, send email to rob...@googlegroups.com
> To unsubscribe from this group, send email to robofab-u...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/robofab?hl=en
>
> Messages from newly joined members are subject to moderation.
> Download RoboFab and documentation at http://robofab.com
>
> !DSPAM:4f38157927987697213578!
Ben Kiel
This is mis-worded, my apologies:
> There may be more than one interpretation, but there is only one correct interpretation.
I should have said that there may be invalid interpretations of the spec, but there is only one correct interpretation of the spec.
To echo what Tal said, a invalid UFO is an invalid UFO. That other applications open an invalid UFO doesn't mean that there are multiple UFO flavors, it only means that those applications should be more strict with the UFO data.
Ben
vernon adams
Tal & Ben, apologies for the frustration. You've convinced me.
Fontoforge (generated) ufos are buggy. It shall be patched.
many thanks again.
-vern
Georg Seifert
>
> To echo what Tal said, a invalid UFO is an invalid UFO. That other applications open an invalid UFO doesn't mean that there are multiple UFO flavors, it only means that those applications should be more strict with the UFO data.
>
Best
Georg
Tal Leming
On Feb 12, 2012, at 4:04 PM, Georg Seifert wrote:
>> I should have said that there may be invalid interpretations of the spec, but there is only one correct interpretation of the spec.
>>
>> To echo what Tal said, a invalid UFO is an invalid UFO. That other applications open an invalid UFO doesn't mean that there are multiple UFO flavors, it only means that those applications should be more strict with the UFO data.
>>
> I do not agree with that. I would suggest that the importing implementations should be more forgiving. Exporting should always be as strict as possible. But to refuse to import a otherwise perfect .ufo is annoying to the user.
I agree that it is annoying to the user. Specifically, what is annoying to the user is that they went to a menu, selected "Export UFO" or "Save UFO" and they got something other than a valid UFO as a result. The best way to solve that is for the writers of the UFO to, you know, write valid UFOs.
FWIW, the next version of ufoLib (the reader/writer underneath RoboFab and other tools) is very strict about these things. When it hits something that doesn't follow the spec it alerts the user to the problem in as much detail is possible. It does not skip and continue. My time working on WOFF has taught me that trying to work around faulty files is a dangerous game. One person's "quietly work around a file problem" is another person's "YOU DELETED MY DATA!!!!!"
Tal
Ben Kiel
> I do not agree with that. I would suggest that the importing implementations should be more forgiving. Exporting should always be as strict as possible. But to refuse to import a otherwise perfect .ufo is annoying to the user. So the importer should be lenient to some degree of diversion from the spec if the value is not essential (I know that are a lot maybes and it is not very exact but for the sake of the user). Give a big warning but go on with the importing.
This sounds appealing at first glance ("Things just work!"), but here is why it actually does both the user and the application developer a huge dis-service:
Taking Vernon's example:
FontForge is currently writing UFOs that say, in Vernon's case, set bit 0 of the OS/2 fsType to 1 13 times. Since bit 0 is reserved, and must be zero, this is clearly wrong. What FontForge means, in Vernon's case, is that there is no fsType bit set. If the user imports this UFO into an editor that isn't FontForge, and the application doesn't reject the UFO as being invalid, then it has a couple of choice:
1. It could to make a guess to the value –and what sort of embedding permissions one wants for their font is a pretty import value to be guessing around about–
2. It could implement both the correct way of reading the key and the FontForge way of reading the key
3. It could let the user know that they need to set the embedding bit, as it was invalid in the UFO they just opened
4. Ignore the invalid data
The first option is going to be tricky, and prone to getting it wrong.
The second option is going to be awful for the application developer, as now they have to spend time writing code for other people's bugs instead of improving their own application.
The third option is going to just as frustrating to the user, as the UFO they just made in another application is going to cause them to set the fsType again, even though it is set in FontForge. You can see from Vernon's questions, that this is confusing for a user, and it doesn't let them know that they need to go complain to the developer of the application making invalid UFOs, not the developer of the application that keeps on making them set again a value that they've set already.
The fourth option means that an application developer is loosing important info about a font and not telling the user.
In short, I don't believe that there are actually cases where the 'value is not essential'. If I export a UFO, it should capture, correctly, all of my design decisions. Those decisions are the sum of every value that the UFO can contain. If an application decides that my design decisions aren't essential, I may find the same thing about that application. It is up to an application developer to correctly save and open a UFO. If an application accepts a garbage UFO, then the maxim: Garbage in, garbage out applies.
Ben
Georg Seifert
I think option three is the way to go.
You state that this would annoy the user. Yes. But they can still use the UFO. In this case, nobody knows when FontForge will be fixed and there might be some "old" buggy .ufos lying around.
If there is a error message every time they open a .ufo should be enough incentive to call the developer to fix this. Having to fix the setting every time is 1000 times more useable then not being able to use the file at all.
And please fix the import and export of .ufos from FontLab before you complain about this minor bugs in the implementation of FontForge. The .ufos are not compliant to the specs in so many ways. THIS is really annoying for other developers end needs a LOT of option 1 and 2.
Georg
vernon adams
Fontforge cannot generate a fontinfo.plist with all 13 bits set to 1.
It will allways set all 13 bits, but either they are all 0, or Nos. 1,
or 2, or 3 can be set to 1. Only 1 bit can be set to 1 and bits 0 and
4-13 are allways set to 0, there's is no way for fontforge to set the
reserved bits to 1.
One issue i see is that if you generate an 'fsType installable' font
as a UFO, it should still have a table, because to not have a table
leaves us not knowing if the font is missing its fsType table because
of error.
-vern
Ben Kiel
> Fontforge cannot generate a fontinfo.plist with all 13 bits set to 1.
> It will allways set all 13 bits, but either they are all 0, or Nos. 1,
> or 2, or 3 can be set to 1. Only 1 bit can be set to 1 and bits 0 and
> 4-13 are allways set to 0, there's is no way for fontforge to set the
> reserved bits to 1.
If you read the UFO spec, it isn't about flipping bits to 1, but listing bit numbers that should be turned on. So a ufo with an array of 13 numerals, all 0 like what FontForge generates, says two things to a valid implementation of a UFO reader: 1. This is an invalid UFO. 2. If it were valid, it's telling me 13 times to turn on bit 0.
Yes, FontForge won't allow a user of it's interface to set bits that can't be set, but the UFO it generates isn't valid, as it makes a list of 13 numerals, either 0 or 1, instead of listing the bit numbers that should be on. Like 2, 8, and 9. Or 3. Or whatever.
> One issue i see is that if you generate an 'fsType installable' font
> as a UFO, it should still have a table, because to not have a table
> leaves us not knowing if the font is missing its fsType table because
> of error.
And that's perfectly valid output for a UFO to have.
Ben
Tal Leming
On Feb 12, 2012, at 6:44 PM, Georg Seifert wrote:
> And please fix the import and export of .ufos from FontLab before you complain about this minor bugs in the implementation of FontForge. The .ufos are not compliant to the specs in so many ways. THIS is really annoying for other developers end needs a LOT of option 1 and 2.
Can you be specific about the bugs in the UFO export/import in FontLab?
Tal
Ben Kiel
> You state that this would annoy the user. Yes. But they can still use the UFO. In this case, nobody knows when FontForge will be fixed and there might be some "old" buggy .ufos lying around.
> If there is a error message every time they open a .ufo should be enough incentive to call the developer to fix this. Having to fix the setting every time is 1000 times more useable then not being able to use the file at all.
So, applications should open invalid files?
The nice thing about the UFO is that it's XML, so if need be, one can fix a error in the UFO by hand. Not pretty, but very much possible. Much easier than fixing a error in a binary file.
If an application is loose about importing invalid files, there is no incentive to fix software to not produce invalid files. The answer isn't to loosen what an application will open, but to stick to the specification, so that other applications will know that if they don't do the same, their files won't work. It is this very looseness that caused Vernon to think that there are different interpretations of the UFO, and that all interpretations should be ok. This pretty much defeats what the UFO is about.
Speaking from the perspective of someone who does a fair amount of production, I don't trust applications that allow me to open up garbage files. I have no way of knowing if that application is warning me about everything it can't use, so I have to treat everything it outputs with suspicion. This becomes very tiresome, very quickly.
Georg Seifert
g
Tal Leming
Okay, whew. So these aren't bugs. They are feature requests.
> To begin with: Kerning and kerning classes. I know that the FLS kerning information is not easy to convert. But at least the import could be done lossless.
No. It can't be lossless in all cases. I've explained this to you in detail before.
> The Glyph Order,
The glyph order location is arriving in UFO 3. UFO 3 has not yet been implemented in RoboFab. By extension, it hasn't yet been implemented in FontLab. Heck, the UFO 3 spec isn't even final yet.
> The left and right bit of the kerning classes (if you stick with the broken syntax, you have to provide a way to export a font and reimport the same thing without loosing to much information.
See the above comment about lossless kerning data conversion. In UFO 3 there is a common kerning group prefix. That can, theoretically, be used for the FontLab kerning classes.
Just to follow up, you said this:
>> The .ufos are not compliant to the specs in so many ways.
What is not compliant?
Tal
Georg Seifert
Am 13.02.2012 um 01:59 schrieb Tal Leming:
> Hi Georg,
>
> Okay, whew. So these aren't bugs. They are feature requests.
>
>> To begin with: Kerning and kerning classes. I know that the FLS kerning information is not easy to convert. But at least the import could be done lossless.
>
> No. It can't be lossless in all cases. I've explained this to you in detail before.
i know that. But why do you export the kerning in the first place. If there is no way to use it? ;)
>> The Glyph Order,
>
> The glyph order location is arriving in UFO 3. UFO 3 has not yet been implemented in RoboFab. By extension, it hasn't yet been implemented in FontLab. Heck, the UFO 3 spec isn't even final yet.
ok, as most ufos that I encountered had a glyphorder present so I thought it should be used. Last time I check this it did not respected the info in the lib.org.robofab.glyphOrder. This seem to be fixed now. Sorry, my mistake.
>
>> The left and right bit of the kerning classes (if you stick with the broken syntax, you have to provide a way to export a font and reimport the same thing without loosing to much information.
>
> See the above comment about lossless kerning data conversion. In UFO 3 there is a common kerning group prefix. That can, theoretically, be used for the FontLab kerning classes.
Yes, but I meant that if you import a ufo in the FLS style kerning/classes, there is no way of round tripping. As the current implementation is a hack anyway, it would not hurt to add another hack to be able to define the left or right side class state. I proposed a easy and useful implementation (actually Eigi did write the code and published it a few years back).
> Just to follow up, you said this:
>
>>> The .ufos are not compliant to the specs in so many ways.
>
> What is not compliant?
Sorry for the harsh words from yesterday. My problem is not really the conformance to the specs but that I try to implement a ufo workflow between FLS, RoboFab/Font and Glyphs and this is quite frustrating (mostly because of the kerning/classes). I can’t fully stick to the specs as I lose a important use case (the file exchange with FLS) and on the other hand can’t ensure 100% text/sorting/whitespace compatibility because I use a different internal representation of the data.
So my problem is actually the same thing that you try to fight with your enforcement of the the specs. I needed a bit to realize this. Sorry for that.
Best
Georg
Ben Kiel
>>> The left and right bit of the kerning classes (if you stick with the broken syntax, you have to provide a way to export a font and reimport the same thing without loosing to much information.
>>
>> See the above comment about lossless kerning data conversion. In UFO 3 there is a common kerning group prefix. That can, theoretically, be used for the FontLab kerning classes.
>
> Yes, but I meant that if you import a ufo in the FLS style kerning/classes, there is no way of round tripping. As the current implementation is a hack anyway, it would not hurt to add another hack to be able to define the left or right side class state. I proposed a easy and useful implementation (actually Eigi did write the code and published it a few years back).
I dug back into the archive, and I think that Tal did give you a perfectly workable solution for this: https://groups.google.com/d/msg/robofab/Howex0W7dfo/7QZ4S0ZWQWcJ
By extending UFOCentral you can get a custom behavior for kerning export in FontLab (and the UFO will still follow the spec), and when UFO3 is released, you can edit your custom UFOCentral script to register the kerning groups you make. I don't think this is a problem for RoboFab, it's a problem for a script exporting a UFO from FontLab. All you need is in the code that you point to from Eigi and that Tal pointed you to.
I'm sure the community will appreciate an improved export script that deals with the 'interesting' kerning implementation of FontLab.
Best,
Ben
Georg Seifert
Yes, I know that. What I asked for is to add this piece of code to the official FLS>RoboFab export script. It is difficult enough to explain some users to install RoboFab. To ask them to patch it will not work.
Best
Georg
Ben Kiel
> Yes, I know that. What I asked for is to add this piece of code to the official FLS>RoboFab export script. It is difficult enough to explain some users to install RoboFab. To ask them to patch it will not work.
Users have to install some script into their macro folder to export a UFO, just installing RoboFab doesn't do this. Producing a script for download, or for the inclusion into the Robofab installer, isn't asking users do to anything more than they already do.
Second, it seems that this is something that has bothered you about UFO export in Fontlab since 2010, and that you have a solution. Why not submit a patch to the Robofab developers so that they can review it and incorporate it? It seems that this would be more helpful than complaining about a feature you would like in the official Robofab distribution, and have incorporated into your own copy.
Ben
Georg Seifert
> Second, it seems that this is something that has bothered you about UFO export in Fontlab since 2010, and that you have a solution. Why not submit a patch to the Robofab developers so that they can review it and incorporate it? It seems that this would be more helpful than complaining about a feature you would like in the official Robofab distribution, and have incorporated into your own copy.
I did suggest to add the code before. I was not familiar with SVN back than so I put it in an email. Can I renew my request to add that code to the repository? What I have to do to submit this correctly?
Georg
Tal Leming
On Feb 14, 2012, at 10:51 AM, Georg Seifert wrote:
>
>> Second, it seems that this is something that has bothered you about UFO export in Fontlab since 2010, and that you have a solution. Why not submit a patch to the Robofab developers so that they can review it and incorporate it? It seems that this would be more helpful than complaining about a feature you would like in the official Robofab distribution, and have incorporated into your own copy.
>
> I did suggest to add the code before. I was not familiar with SVN back than so I put it in an email. Can I renew my request to add that code to the repository? What I have to do to submit this correctly?
Send me a patch with all needed test cases (in either doctest or unittest format). It is really helpful if the code is very clearly written.
Tal
vernon adams
last (i hope) words on the matter. I just bought robofont, to replace
fontlab, as robofont wantonly ignores the specs and happilly opens
fontoforge's 'invalid' UFOs + i proved my point + i got some online
retail therapy :)
-vern
On 12 February 2012 23:18, Ben Kiel <b...@houseind.com> wrote:
> This sounds appealing at first glance ("Things just work!"), but here is why it actually does both the user and the application developer a huge dis-service:
>
> 1. It could to make a guess to the value –and what sort of embedding permissions one wants for their font is a pretty import value to be guessing around about–