*** From the Archives ***
This article is from July 3, 2010, and is no longer current.
Document Fonts Feature in InDesign CS5 Appears Buggy with Small Caps
Among InDesign CS5’s new features is one called “document fonts.” Briefly, it works by allowing the recipient of a packaged InDesign file–a client, service bureau, ect.– to open that file and utilize the fonts in the document without having to install them in the system.
This is terrific in theory, but it looks like something’s not quite right when using small caps. A recent post on Adobe’s User to User forums as well as a post here at InDesign Secrets got me curious so I tried it out myself.
Check out the screen shots below:
The top is the original document while the bottom one is packaged InDesign file.
Sure enough, the packaged file does not display the small caps. Even more curious is that the text does appear to have the small caps attribute assigned. Checking the character panel or the control panel with the text highlighted confirms this.
I’ve been able to reproduce this with fonts that don’t have real small caps built in, but with the few I tried that do, I couldn’t reproduce it. I can even change the font attribute to a full featured OpenType font such as Minion Pro and the small caps is honored. Change it back to Arial Rounded and it loses the formatting.
I don’t have any solid advice here except to be very aware of this if you use small caps and send packaged InDesign files to others.
Update 4/26/11: This bug, along with several others has reportedly been fixed with the 7.0.4 update
 |
No doubt a big problem. I just tested it there too. I found that if I removed the font from the Fonts folder generated by InDesign the fonts restore to their Small Caps state.
Is there no way to tell InDesign not to point to the fonts folder that’s generated from the package?
i agree with eugene… that’s a HUGE problem for printers like me who are supplied finished art prepared using the package feature but NOT necessarily supplied hard copy of the files, therefore having nothing to compare to. is adobe onto the case yet?
Collywolly: you can file a Bug here
https://www.adobe.com/cfusion/mmform/index.cfm?name=wishform
Does the same problem happen to fonts that are in the InDesign/Fonts folder?
It doesn’t appear to matter, Fred. It looks like the fonts in the package folder take precedence.
(Thinking ahead)
The very first time I noticed it, it happened with Small Caps. If one of you can reliably (so to speak) create this problem, can you also check a few random other Opentype features?
I’d do it but it keeps on working whatever I try. Bummer!
Not only with Small caps, some type 1 fonts are not at all recognized by Indesign even though the fonts are loaded with the Document Fonts.
It showed “Missing Fonts”.
It is fantastic feature if this is be solved. No heck moments in loading the fonts before process. It is very useful for ePublishing field, we generally load the fonts related to particular job and even de-load the system fonts if conflict arises. Very Senstive kind of workflow.
Does this bug happen if the fonts are not included in the package? If so, a workaround might be to package the file twice, once with fonts and once without, and send Fonts folder separately. We haven’t gone to 5 yet.
@Rick: AFAICT, it doesn’t happen if you don’t package the fonts.
Rick: Nothing goes wrong on packaging — it goes egg-shaped when ID CS5 tries to use these fonts.
The workaround is to package as usual, so you are still sending the fonts along, but on opening not have ID see them as “Document Fonts”. You need to temporary install them into your system (or copy into your InDesign/Fonts folder) and rename the “Document Fonts” folder to anything else, so ID will not try to use them anyway.
As always, you have to be very careful you are not trying to install two different versions of the same font (and I believe that was one of the reasons to devise this system).
This sounds like the same problem we have with CS3 and auto-activated fonts. We have found that we need to activate the fonts first before the document is opened to have the small caps print properly. (Note: not all fonts are affected though.)
Hmm. Yet another ID small caps bug. We’re still having problems with small caps reverting to upper and lower (even though the small caps icon is still highlighted), and this goes back to CS2. Our work-around: find and replace all small caps attributes with a character stylesheet that makes the letters uppercase and sets the vertical and horizontal sizes to 70%. That’s what ID’s “fake” small caps function is SUPPOSED to do anyway, but we’ve had too many occasions where they simply drop out, and usually when you’re not looking.
I haven’t had a chance to thoroughly test this problem, but I have a suspicion it may occur only when using PostScript fonts. I’ve never seen the problem with TrueType or OpenType that I can recall….
Richard: there are no PostScript (Type 1) fonts that have small caps that ID can use … And no real TTFs either (I mean, TTFs that are not OTFs).
The only font type that may contain a ‘small caps feature’ is OTF, and only when it’s defined in the font, ID uses this instead of downscaling capitals. For every other font, ID immediately uses the downscaling trick.
I’ve had small caps failures before, with either CS or CS2, but in those cases it was due to a badly-formed OTF. All OTF features are linked to scripts (Latin, Cyrillic, Greek, Thai, and so on), and per script, may be linked to different languages. This has been designed to, for example, allow some ligatures in every language, and others not (Turkish ‘fi’ ligatures should not loose their dot; the common fix is to disallow the ‘fi’ ligature for Turkish). In the fonts I had Small caps fail with, they were only linked to English …
Can you give a font name where you have to resort to fully manually created small caps, i.e., one where ID’s automated system fails?
On my system, in CS5, open-type-all-small-caps will not work at all (no matter what font) if the language is set to “no language”. If I change the language to English (USA) it works.
The runaround I came up with was to rename the font folder from “Document Fonts” to just “Fonts” that way InDesign doesn’t find the folder, yet they fonts are collected to give to my printer.
Just caused a full-color rerun in our shop when we upgraded to CS5. A file that worked perfectly until CS5 packaged the file. No one noticed until the customer received the job.
From a design standpoint font formatting is a great feature. But as a printer we’ve tried to steer our clients and their designers away from it and instead use small caps fonts or bold, oblique, italic or what have you. There’s just been too many problems going back to the earliest versions of ID (orQuark). What looks good on one guys screen doesn’t always display our output as intended on another, and it either costs time to remedy on the front end, or time and money on re-runs.
MY EASY SOLUTION. I just began having this problem after using CS5 since May 2010. After much hair-tearing I discovered that pulling the InDesign document out of the gather file fixed the issue; when the InDesign document is pulled out of the gather file, the small cap attribution remains in place. I then put both the gather file (with fonts, links, etc.) and the CS5 document into a new file I name and send it to the printer this way. This is clunky, but it works.
I hope we will see a dot release to fix this dangerous bug for CS5 and that the solution is not to update to CS5.5!
Here’s a quick fix this problem when packaging a project in CS5…
Package the project. Open the package folder and rename the fonts folder from ‘Document fonts’ to ‘Fonts’. This way the directory that InDesign is trying to auto load the fonts from doesn’t exist. It seems like the Adobe font list file (.lst) in the fonts folder can also be deleted without any repercussions. Open the packaged indd file and the Small Caps should be working. Printers will then have to manually load the fonts as they would with CS4 packaging.
Obviously this is still a problem that needs to be fixed, but this is a quick solution. There is, however, always the doubt of what other styles it’s loosing, such as any manual kerning. Definitely makes you loose a little trust…