Open NightFurySL2001 opened 1 year ago
compiling maxp is blowing up, maybe you've oveflown the maximum number of glyphs (65535) that an OpenType font can contains at the moment. How many SVGs did you pass as input?
Uhhh... is 700 too much? 😓
no, that should be fine..
Could you please try to apply this patch to a local clone of github.com/fonttools/fonttools and install fonttools from that directory in editable mode (pip install -e .
) and see what you get:
diff --git a/Lib/fontTools/misc/sstruct.py b/Lib/fontTools/misc/sstruct.py
index d35bc9a5c..6f54f769c 100644
--- a/Lib/fontTools/misc/sstruct.py
+++ b/Lib/fontTools/misc/sstruct.py
@@ -72,7 +72,12 @@ def pack(fmt, obj):
elif isinstance(value, str):
value = tobytes(value)
elements.append(value)
- data = struct.pack(*(formatstring,) + tuple(elements))
+ try:
+ data = struct.pack(*(formatstring,) + tuple(elements))
+ except struct.error:
+ print("formatstring:", formatstring)
+ print("elements:", elements)
+ raise
return data
struct.error: 'H' format requires 0 <= number <= 65535
formatstring: >HHHHHHHHHHHHH
elements: [81, 2, 152196, 7464, 1, 0, 0, 0, 0, 0, 0, 7464, 1]
ninja: build stopped: subcommand failed.
the third field of maxp is maxPoints, there's a glyph that contains more than the maximum number of points (also an unsigned short)...
These source files are raw data input from one of the testers. All of these are stroked paths made in Adobe Illustrator. Using only 4 SVG, it seems that all the glyph are concentrated on uni000A
, with the remaining strokes on separate glyphs.
have you been able to indentify the offending SVG file that makes the maxp explode? Could you upload here or send privately via email so I can take a look? We should definitely improve the error messages
All the svg are uploaded in the zip file in the first comment. I think it's probably the --glyphmap_file csv file not working. Using even more glyphs it shows that all the glyphs are imported into uni000A
, not to individual glyphs, probably why it exploded.
csv format:
Artboard 2.svg,,醍
OK, I see. So the --glyphmap_file option is a private flag of the nanoemoji.write_fonts submodule, which is not meant to be passed directly to the main nanoemoji
CLI tool. Right now nanoemoji attempts to write a glyphmap csv file by parsing the svg input filenames (guessing the codepoints from the file name, e.g. emoji_u1F055_A425.svg -- I made this up). The default implementation is in nanoemoji.write_glyphmap, which takes the input SVG files and writes the glyphmap CSV.
One can override that by providing a custom --glyphmap_generator script with a similar interface but implementing a different logic. This is quite complicated feature and I've never liked very much, for it requires a user to write python code.
I think if one already has a glyphmap in CSV they should be able to simply pass it to nanoemoji with the existing --glyphmap_file option, just like you did.
I started to implement this in #454, please have a try if you can (you can clone namoemoji, checkout the 'custom-glyphmap' branch and install editable from there).
Note that the CSV must contain four (or more) columns: the first two are respectively the SVG and PNG file names (usually you only need the first and can leave the second one empty, it's only used for bitmap color tables); the third column is the desired glyph name, and the fourth, fifth, etc. are the unicode codepoints. These must be in hexadecimal format, so instead of writing it as text 醍
like you did inside "test-strokesvg.csv", the codepoint column is expected to look like 918D
. If the codepoints are left empty, no entry will be added to the cmap table, which makes a glyph practically unreachable unless you have other means (GSUB) to get to it, so in general it's advisable that you add at least one codepoint. Multiple codepoints are interpreted not as alternative character mappings for the same glyph, but rather as a rule for generating a GSUB ligature to substitute that glyph when the sequence of codepoints appear in a string (this is meant to support emoji sequences). When the glyph_name (third) column is left empty, in that PR of mine, I'm using the codepoints to create a glyph name (some glyph name is required to identify glyphs internally, but are not going to be stored in the font unless --keep_glyph_names option is used).
I hope this helps a bit. Thanks for trying out out tools and providing feedback!
I see, thank you. I would also like to ask if it is possible to not separate each element as its own glyph since I don't see such options? I understand it is used for glyf
colour font (glyf_colr_0
, glyf_colr_1
), but I'm not sure why glyf
has them seperated.
Sorry I don't understand what you mean when you say "not separate each element as its own glyph", can you please clarify/make example? Thanks
When running the following code, it reports
'H' format requires 0 <= number <= 65535
.test-strokesvg.csv SVG files: test-strokesvg.zip