Comments on: OpenType Small Caps Glitches

By: Ralf Herrmann

Ralf Herrmann — Tue, 13 May 2008 07:02:51 +0000

Speaking of turning off subsetting:
You need to check the EULA of your fonts. Nowadays most font vendors ONLY allow font embedding if you use subsetting, because a fully embedded font could be extracted from the PDF.

By: Bob Levine

Bob Levine — Mon, 12 May 2008 17:03:03 +0000

The only issue with subsetting is file size. Some of these fonts can really bloat a PDF. But that shouldn’t be an issue with a PDF heading to press. Fully embedding fonts is the safest way to avoid problems.

By: Anne-Marie

Anne-Marie — Mon, 12 May 2008 16:04:23 +0000

Anthony, I do believe it’s a RIP issue. As I said in the post, only a very small percentage of ID users (in my experience) ever have a problem with OT Small Caps. Since we’re all using the same application, the difference has to be the output device.

And, entering text as all caps and then scaling them manually falls into my “blech” category of fixes …

I do wish, though, that there was a way to turn off the substitution and force ID to scale the OT characters as it does for T1 and TT characters. I’ve heard from other users who would like this option even though their OT SC print fine… because they need the SCs at a larger size, for a particular project, for example. They’re willing to trade off the beauty of the custom-cut SC for more control.

By: David Blatner

David Blatner — Mon, 12 May 2008 15:28:59 +0000

Ole Kvern hates subsetting fonts when exporting PDF files from InDesign for print. He’s convinced that subsetting causes all kinds of problems like this (and global warming, and so on), so he sets the Subset Fonts percentage to 0% instead of 100%.

I totally agree with Bob that turning on “Download PPD Fonts” in the Graphics pane of the Print dialog box is also important.

By: Anthony

Anthony — Mon, 12 May 2008 14:07:40 +0000

This has happened in my office, and I figured out a quick-and-dirty solution. We assumed the problem was our RIP software, but now that I see this post, I know it’s an Indesign/typeface format issue.

The best fix is rather than click the “Small Caps” button to force a Small Caps on a typeface without an actual small caps, we take a full cap and scale by 70% vertically and horizontally. This is what Indesign does anyway to force a small cap (check your preferences, you can set it to whatever you want). I’ve heard from a lot of designers that 80% is better visually, but here at the office, the norm is 70%.

Hope this all works for you.

By: Anne-Marie

Anne-Marie — Sun, 11 May 2008 22:02:02 +0000

So something to do with subsetting, eh … makes sense! I’ll riffle through the old e-mails and see if I can follow-up with the questioners.

By: Bob Levine

Bob Levine — Sun, 11 May 2008 21:53:04 +0000

I seem to remember seeing this reported on the U2U forum and selecting download PPD fonts when printing or electing to fully embed fonts when exporting a PDF was a fairly reliable fix.

By: Dave Saunders

Dave Saunders — Sun, 11 May 2008 19:44:57 +0000

Anne-Marie,

I think I’ve seen this discussed in the U2U forum. If memory serves, its cause can be traced to subsetting fonts on printing. InDesign doesn’t know about the behind the scenes glyph substituting and so it sends the wrong subset.

Of course, there might be other reasons.

Dave

By: Ralf Herrmann

Ralf Herrmann — Sun, 11 May 2008 18:35:41 +0000

Would be interesting to know which fonts were involved or to have one of those PDFs, to see what is going on.
It’s most likely an encoding problem on the printer’s side.
In the PDF the characters are accessed by a glyph name. For alternate characters (discretionary ligatures, small caps, swash characters and so on) there is no consistent name reserved. It can be »A.alt1«, »A.alternate« or whatever. Seems like those printers can’t access those glyphs and only accept standard 8 bit encodings.