I seem to be hitting some issues in FC Pro 11.5.0.2430 on Win7x64 with fonts that have very large glyphs.
It appears that coordinate points of a glyph are bounded by -32,768 to +32,767 (I can’t find this in the OTSpec, and I’ve asked this question in the FontCreator - Support forum under the title Max Size of a Glyph, … but I think that’s a reasonable assumption given the int16 declaration for point coordinates).
FC shows a working grid of with X and Y ranges bounded by -16,383 to +16,383, but allows you to move points pretty much anywhere. You can’t scroll past the working grid bounds, but you can zoom (way) out and happily move points anywhere off the grid, even beyond 64K bounds. FC will save such modifications to .fcp files and read them back in OK, but then on export to .ttf, the affected contours get badly mangled (as you might expect).
- Should FC have some check / guard against points with out-of-bounds coordinates?
- Could the working grid be expanded to accommodate the full range of -32,768 to +32,767?
I’m working with Arabic fonts that have glyphs with contours that extend out to about +23,000 (with a UPM of 2048), so this is not a pathological case. One such font is Khaled Hosny’s Amiri Regular, glyph #6781 (which is unmapped and simple, but used in composite glyphs). I have attached that font, since it is OFL.
You may not get a reply from Erwin until after the Easter break.
I can confirm the issue. There is a category in the Overview side panel for glyphs with outline issues.
You could temporarily move the offending contours by a round number of funits using the Transform Toolbar so that you can work on it, then move it back again, but that is not going to fix issues with exported fonts. Perhaps making any composite glyphs that use the simple glyph as members into simple glyphs might fix it. Scaling and rotation of component glyphs is know to cause issue, so it is recommended to make them simple before export.
Thanks for that! …
I never thought of transform / moving the contours into “safe space” and then sliding them back … btw, it looks like, as long as the contours are within -32,768 to +32,767, the exported font is AOK.
Scaling and rotation of component glyphs is know to cause issue, so it is recommended to make them simple before export.
Hmmm. Is there more detail on this? (another post??) I have not seen this, and some of the fonts I work with have composite glyphs 5 levels deep (ugh).
See this thread, for example.
With over 20 years of code, it is possible this is legacy, but I’m not sure.
If more people are in need of a larger grid, then we might take time to look into this.
I see this issue with a couple of large glyphs in my Odana font. I did not notice any problem with the exported font.
I too have see no problems with exported fonts … and the work-around you suggested is AOK. The only problem would be if data points exceed the +/- 32K limit, which is really extreme.
I’m thinking this is definitely a low-priority issue, and not worth risking the issues that might crop up from expanding the working grid.
I only hit this when scaling an Arabic font to adjust its UPM when importing it’s glyphs into another, higher-UPM, font.
-Clint