Printing very wide glyphs in InDesign

Rainer Erich Scheichelbauer

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?

Chris Lozos

I am so glad you posted this question.  I had tried several times to include a wide logo or wordmark as part of a font for a customer and been forced to make it quite small.

Alvaro Franca

Interesting, I would've assumed there weren't limitations in width. Why are there, anyway? Is it on the typesetting engine side of things or a shortcoming of OpenType itself?

Georg Seifert

I found a similar limit in UPM/Letter high what Indesign was able to properly convert to paths. There is a limit on the max coordinates possible in OpenType but that is much higher. And Indesign can display those fonts just fine, only some operation fail.

Alvaro Franca

Hi @Georg Seifert, that sounds very interesting, do you know what's the OpenType limit precisely? is that on some specification?

Jackson Showalter-Cavanaugh

I have no insight to the problem but I do have a specific case study to share: 

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. 

Thomas Phinney

I'm pretty sure that there is an OpenType / CFF format limit of +/- 4096 units in x or y, for any glyph coordinate. This is specific to CFF outlines as I recall, so using TrueType might be a good workaround. Not sure I recall the TT limit with certainty, but I think it might be 16K (16384).

Arthur Reinders Folmer

I ran into the same limit on glyphs, but rendering does happen till at least 5923 units in opentype (the widest I have so far) Originally it was wider, but due to the typeface running opentype tricks, it was impossible to circumvent and I had to give it a redesign.

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)

Georg Seifert

There is no limit below 16000 units in the OpenType spec that I know of. This is just a bug in Adobe apps. The fonts work fine in other apps. And even exporting as PDF was fine, you just can’t convert to outlines. 

Thomas Phinney

Well, CFF is defined as representing Type 1 font data. The Type 1 spec has a restriction, namely:

"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.

Georg Seifert

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.

I didn’t know that.

but I think it might be 16K (16384)

The 16384 units come from the head table spec. The UPM range is 16 to 16384. 

John Hudson

The UPM range is 16 to 16384. 

I think we should hold a design competition for 16 UPM fonts.

George Thomas

I think we should hold a design competition for 16 UPM fonts.

An ornate connecting script, maybe?

Adam Twardoch

@John Hudson , 
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.

Deleted Account

Very Cool Adam! I'm tempted to forward that to my tile contractor for an estimate in 1/2" marble.;)

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. 



 

Grzegorz Rolek

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.

The UPM range is 16 to 16384.

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.

Deleted Account

Though 2011 is around the time apple started work on quadrupling their screen resolutions.