What exactly is the limit to the metric width (my own testing suggests 4096) and bbox width of glyphs that can be printed from within Adobe InDesign?
There seem to be no differences between TTF and CFF, unless first exported into a PDF and printed from Preview.app. Then, wide glyphs show in TTFs, but still no luck with wide CFF glyphs.
Anyone with more insight on this on the forum?
2
Comments
I ran into a glyph width problem when supplying artwork for a book a few years ago. I mistakingly sent the un-outlined version before going on vacation and no one picked up the error while proofing (whatever happened to press checks?).
It's a chunk of lettering drawn as two overlapping glyphs (slightly rotated).This is how the art was printed, getting flattened part way through each glyph.
And here are the drawings in Fontlab, with guides placed approximately where the error totally collapses, which is around 6100 upm wide. Although if you look closely, the art starts to warp in the x direction at around 4000 upms. And the first glyph seems to be more dramatically warped than the second.
Interestingly, both in indesign & illustrator, the glyph does show fully when outlining. So any glyph information outside the draw range does still 'exist' but isn't drawn. (Mind, this is logical, seeing the cut off happens mid-bezierpath)
"Type 1 BuildChar expects that the absolute coordinate values that define a character outline do not deviate too far outside of the one user space unit to which the character space coordinates will be transformed. Absolute coordinate values in both x and y directions must be between -2000 and +2000. (When coordinate values are computed using the div command, its operands may be out of this range; the final result of such a computation however, must be within this range.)"
So actually, the spec limit is -2000 to +2000. Implementations may be more flexible, and I do believe that Adobe has commonly supported up to +/- 4096. But there is a spec limit below that.
The 16384 units come from the head table spec. The UPM range is 16 to 16384.
I think we should hold a design competition for 16 UPM fonts.
An ornate connecting script, maybe?
until a better candidate emerges, I'd vote for
https://www.dropbox.com/s/5syahszk6nl89sl/Unifont-16ppm-pxcom.ttf?dl=0
It's a 16 UPM font with >57,000 glyphs, each one made of "pixel" composites that refer to a glyph which is made out of a 1x1 unit rectangle. It contains glyphs for all Unicode 8 BMP codepoints, and is licensed under GPL2. I've built it yesterday from the BDF bitmap font published on: http://unifoundry.com/unifont.html
A.
Thomas: "So actually, the spec limit is -2000 to +2000. "
So, I guess if 1/2 of our CFF design space is to the left of the origin, with the minimal implementation in mind, the glyphs beyond 2000 would just need to have HUGE positive kerning pairs to work.
I'll get on it right away, to make this happen at productization, with the glyphs being designed in TT with normal spacing, including glyphs beyond 2 ems wide, and then on CFF generation, shifting all said wide glyphs, and adding corrective kerning pairs to the normal kerning pairs, so all the glyphs will "fit" in a CFF, with the minimal implementation in mind. Have I got that right?
Jackson's issue is different, I think, (besides begging for grated parmigiano). When outputting to PS, there is a transformation of all curves to tiny vectors you can never ever see or have access to, in order to render. Plotting the intersections of a lot of little straight lines is faster than doing the math on bezier curve-to-grid intersections to get to the pixels. PS runs out of storage for all the little vectors at some point, and won't render the rest, the printing is interrupted to flush the vector barf, and you see what happens. This is a per-glyph issue, so breaking your masterpiece in two, and in two, and in two until it works, is the best solution I know.
TT is -64k to 64k so there are rather generous limits for uber-sourcing, (along with overlapping parts, definitive hints and superior curve technology), but it don't help with the above because adobe never did, and probably never will, implement native apple font technology. Besides needing cross-platform font tech, Adobe software developers wanted certainty in things pre-web. Pages are a certain size, target resolutions are knowns, and fonts resident, to operate at maximum speed and minimum memory requirements. Now, the restrictions that apply to Type1 & CFF, thanks to OT, seem to apply to all fonts, print or web, right or wrong.
I hope that helps.
I recall Behdad Esfahbod pointing out recently on the OpenType mailing list the calculations involving the left side-bearing as found in the hmtx table, and how this moves the glyph drawing.
That was something I had to be reminded of, frankly, because it’s easy to forget that in TrueType the left side-bearing is independent from x-zero, and that it’s only the font editors that often treat the two as equivalent. But, while the baseline is usually assumed on y-zero by the layout engine, the position of the outline along the x-axis has more freedom in this respect — that is, as long as the side-bearings in the metrics table are adjusted accordingly. TrueType spec is pretty clear about that, at least in Apple’s version, just below the discussion on the master grid. I assume font makers involved in Asian markets find all this pretty obvious, since in vertical line layout having side-bearings more or less symmetrical to the origin seems more intuitive.
But to the point: I wonder whether this side-bearing adjustment happens ‘within’ or ‘in addition to’ the glyph’s design space. Because if the design space is unaffected, then not only one could draw an outline on both sides of the origin (following David’s thinking in CFF) and thus have a total of 32K units of design space (-16K through +16K), but with the side-bearing set appropriately, one could still have the glyph laid out in line as expected by default.
In Apple’s version of the spec, the lower limit has been changed to 64. No idea when or why this was done so, but I’ve also checked the copy of the spec distributed with their tool suite dated October 2011 and it’s the same there.