adobe-type-tools / afdko

Adobe Font Development Kit for OpenType
https://adobe-type-tools.github.io/afdko/
Other
1.06k stars 167 forks source link

max glyph count for mergeFonts #1752

Closed schriftgestalt closed 2 months ago

schriftgestalt commented 3 months ago

When trying to build a font with 65535 glyphs (like SourceHanSans), I get an error String INDEX limit exceeded:. I check the code and the limit is set to 65000. Is this possible with mergeFonts or do I miss something.

skef commented 3 months ago

According to the comments associated with the PR that added this #define your font is likely exceeding a CFF limit. See the documentation on the String INDEX:

https://adobe-type-tools.github.io/font-tech-notes/pdfs/5176.CFF.pdf#page=17

My initial guess would be that your build is attempting to retain all of the glyph names within the CFF table. Large CFF fonts have tended to be CID-based and don't retain names. There may be no spec-compliant way to do that with CFF-internal names.

There's no reason I can see why it wouldn't work to have all the names in a Version 2.0 post table instead. However, getting that workflow working with mergefonts might be tricky -- I would have to look into it.

punchcutter commented 3 months ago

For Source Han we do mergefonts with name keyed sources going to a CID-keyed output. Then build the CID-keyed CFF with that. For variable TTF I have a custom Python script that overrides some things to make it all work. I can post that if that's what you're talking about.

punchcutter commented 3 months ago

For mergefonts the command is like mergefonts -cid cidfontinfo.OTC.J merged_font part1.map part1.pfa part2.map part2.pfa etc

The cidfontinfo is like https://github.com/adobe-fonts/source-han-sans/blob/master/ExtraLight/OTC/cidfontinfo.OTC.J Map files are like this with the format destinationCID sourceglyphname

mergefonts font1 1
0 .notdef
1 whatever
etc
schriftgestalt commented 3 months ago

As far as I can see, the SourceHanSans fonts contain 65535 charstrings. I have a .pfa file containing the same number of char strings and try to build a CID keyed font from it: The .pfa file t is build from a .ps file that has as many chars like this:

/cid65534 ## RD {
 0 0 hsbw
endchar
} ND

Does this mean that the .pfa can’t be opened because it has too many glyph names?

punchcutter commented 3 months ago

The pfas for Source Han are CID-keyed. Those are used as the source to make OTFs. Those also open fine in Glyphs which is something I do all the time. If the pfa you have is name-keyed then it's probably going to fail with tx or mergefonts. If you break it into two pfas that are name-keyed and run mergefonts then it should work.

schriftgestalt commented 3 months ago

As far as I can see the .pfa is CID keyed. Or did I do it wrong? (the format is as seen above).

punchcutter commented 3 months ago

What does tx say if you run it on the file? tx whatever.pfa ? If I run on a Source Han file I get the first lines as

## Top Dict
Notice              "Copyright 2014-2021 Adobe (http://www.adobe.com/), with Reserved Font Name 'Source'. Source is a trademark of Adobe in the United States and/or other countries."
FullName            "Source Han Sans ExtraLight"
FamilyName          "Source Han Sans"
Weight              "ExtraLight"
UnderlinePosition   -150
FontBBox            {-991,-1050,2930,1810}
FSType              0
cid.CIDFontName     "SourceHanSansVF-ExtraLight"
cid.Registry        "Adobe"
cid.Ordering        "Identity"
cid.Supplement      0
cid.CIDFontVersion  2.004
cid.CIDCount        65535
sup.flags           0x00000001 (ABF_CID_FONT)
sup.srcFontType     Type 1 (cid-keyed)
sup.nGlyphs         65535
schriftgestalt commented 3 months ago

I get the same error. I did generate the .pfa from a .ps file with the type1 tool.

punchcutter commented 3 months ago

Well, it looks like that didn't make a CID-keyed pfa then. To really try that way I'd say split it in two like I mentioned above. Then tx should report name-keyed for each half and mergefonts should make a proper CID-keyed pfa. At least that's what I expect should happen.

schriftgestalt commented 3 months ago

I’ll do that. Thanks.

Is there a way to make a proper CID keyed .pfa?

punchcutter commented 3 months ago

As far as I know the type1 tool never had any CID specific capability. You mean make a proper CID keyed .pfa from scratch? I think we've just always used mergefonts to do that. So there's no 65535 glyph pfa just made from scratch. It's always made with map files and separate sources.

punchcutter commented 3 months ago

If you have a CID-keyed OTF you can run tx -t1 -o cidkeyed.pfa cidkeyed.otf to get that, but I'm not sure what exactly you need to do or what the source is.

schriftgestalt commented 3 months ago

When Glyphs writes any CFF based font, it writes a .ps file, uses type1 to convert it to .pfb (mergefonts to make CID) and then tx to CFF. I don’t write multiple font dicts for CID keyed fonts, yet. That's why it hits the glyph limit.

punchcutter commented 3 months ago

I don't understand what you mean. If you use type1 and then mergefonts then it should all work fine. That's not much different from what I'm doing all the time.

punchcutter commented 3 months ago

Oh, you mean since you're not doing multiple font dicts you only have a single .pfb? I don't even do it like that. I merge a bunch of random stuff and add the font dicts later. mergefonts will "make" font dicts per source, but I just trash that and redo it with what I want. This is all kind of messy, though. Ideally it would work like you are trying.

skef commented 2 months ago

I'm not going to close this yet but I think it's more of a discussion so I'm moving it there.