Closed schriftgestalt closed 2 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.
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.
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
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?
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.
As far as I can see the .pfa is CID keyed. Or did I do it wrong? (the format is as seen above).
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
I get the same error. I did generate the .pfa from a .ps file with the type1
tool.
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.
I’ll do that. Thanks.
Is there a way to make a proper CID keyed .pfa?
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.
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.
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.
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.
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.
I'm not going to close this yet but I think it's more of a discussion so I'm moving it there.
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.