[CLOSED] More bugs with UFO

FontCreator - Font Editor FontCreator - Bug Reports
1

Were reported in http://forum.high-logic.com:9080/t/fixed-multiple-issues-with-ufo-file-generated/8021/5 . Tested on 15.0.0.2974

  1. name ID=1 and 2 are still not exported even when explicitly in Font Properties - Font - Family Name and Instances - General - Style Name.
  2. Generated font files contains platformID=1 platEncID=0 while generated UFO files doesn’t.
  3. The features.fea file might sometimes contains glyph names that are over 63 characters long. E.g. name: katakanasmallhu_katakanahiraganasemivoicedsoundmarkcomb-kana.ccmp.1 is 65 characters long. This is auto-generated name by FontCreator.
  4. [new] Generated @BASE and @MARK class definition are written as @\BASE and @\MARK, causing parsing failure.

Also text files in UFO are still UTF-8 with BOM, but preferably should not have the BOM mark.

2

We don’t see any problems here. Please send us a font project to further look into it.

Platform 1 (Macintosh) is excluded by default. Did you uncheck the Exclude legacy data setting on the Font tab?
ExcludeLegacy.png

We try to follow the syntax as described in the Adobe OpenType Feature File Specification:
https://adobe-type-tools.github.io/afdko/OpenTypeFeatureFileSpecification.html

But we did not comply to one of the glyph name restrictions, being:

A glyph name may be up to 63 characters in length

Please send us a font project with this issue, so we can try to fix it.

We think we it is correct to use a backslash after the ampersand, like @/nameofglyphclass, but we feel the specification is unclear about it:

2.g.ii. Named glyph classes
A glyph class can be named by assigning it to a glyph class name, which begins with the “@” character, and then referred to later on by the glyph class name.

The part of the glyph class name after the “@” is subject to the same name restrictions that apply to a production glyph name except that hyphens are also allowed.

An initial backslash serves to differentiate a glyph name from an identical keyword in the feature file language.


We actually prefer a BOM, is there some formal statement that explains to avoid it?

3
  1. name ID=1 and 2 are still not exported even when explicitly in Font Properties - Font - Family Name and Instances - General - Style Name.

Sorry I was unclear on this one: localised names in UFO are missing ID=1 and 2. In the attached UFO (zipped) file, you can see there is only name ID=16 but no ID=1, but the binary font file has ID=1 and no ID=16.


Platform 1 (Macintosh) is excluded by default. Did you uncheck the Exclude legacy data setting on the Font tab?

Sorry, this is on me.

The features.fea file might sometimes contains glyph names that are over 63 characters long

The glyphs and combined glyph which had the 65 characters name are in the FCP file for reference. I have removed all custom names in the TTF, and opening it in FontCreator still autocompletes the long name. The name is in the UFO fea file too.

We think we it is correct to use a backslash after the ampersand, like @/nameofglyphclass, but we feel the specification is unclear about it:

The specification only specified the restrictions are the same, it do not explicitly say class names after the @ can follow the glyph name specification:

The part of the glyph class name after the “@” is > subject to the same name restrictions > that apply to a production glyph name except that hyphens are also allowed.

which in this case I don’t think the backslash is allowed in class names; the specification only allows glyph names to have backslash.

Also even if backslash is allowed, the GDEF fea is not using the backslash making it unable to be matched.

@\BASE = [A Aacute Acircumflex Agrave Amacron];
@\MARK = [gravecomb acutecomb u0302 u030C u0304];

table GDEF {
    GlyphClassDef @BASE,, @MARK,;
} GDEF;

I would say to use class names without backslash (@BASE, @MARK) as AFDKO makeotf and fonttools raise errors in parsing this feature syntax.

We actually prefer a BOM, is there some formal statement that explains to avoid it?

Not in the UFO spec (file names has to be UTF-8 but not the contents). However, Unicode does not recommend using BOM in UTF-8.
https://www.unicode.org/versions/Unicode15.0.0/ch02.pdf

Use of a BOM is neither required nor recommended for UTF-8, but
may be encountered in contexts where UTF-8 data is converted from other encoding forms
that use a BOM or where the BOM is used as a UTF-8 signature. See the “Byte Order
Mark” subsection in Section 23.8, Specials, for more information.

Currently FontTools breaks when parsing features.fea file.
MyFont-Regular.ufo.zip (81.7 KB)
MyFont-Regular-customnamesremoved.ttf (8.3 KB)
My Font.fcp (7.9 KB)

4

They are generated on exporting as Web or Desktop font, but they are not automatically generated on exporting as UFO. So you need to provide both StyleMapFamily and StyleMapFamily.

In a next update we will shorten the glyph names that are too long.

Consider it done.

We will stop adding a BOM.

5

This release solves the issues.

https://www.high-logic.com/tmp/fontcreator/FontCreatorSetup15.0.0.2982-x64.exe

Please let us know your results.

6

Thanks, most seem to be resolved.

They are generated on exporting as Web or Desktop font, but they are not automatically generated on exporting as UFO. So you need to provide both StyleMapFamily and StyleMapFamily.

I believe you meant StyleMapFamilyName and StyleMapStyleName in Font Properties - Instances.

I would like to ask what does Font Properties - Font - Family Name does in this case if it doesn’t provide the nameID=1.

7

Yes, I meant those two names.

Then it might be used to generate Full Font Name and Unique Font Identifier.