No method of creating PDF files via Adobe software guarantees that you will be able to fully embed all fonts. In the case of creating PDF via distillation of PostScript via the Acrobat Distiller, you definitely cannot assume that all fonts will be embedded fully. TrueType fonts usually are not fully embedded by Distiller, regardless of the joboptions specified.
With regards to creating PDF files via direct export from InDesign (the method endorsed by Adobe), you may likewise find it nearly impossible to avoid subset embedding.
To create a PDF file with layers, you have no choice other than to use direct PDF export from InDesign.
A more important question is why you believe it is necessary to fully embed fonts as opposed to subset? There is no tangible advantage in terms of display or RIP/print functionality. You only end up with much larger PDF files. In the case of newer OpenType fonts that support many languages, these OpenType fonts may be exceptionally large (up to a megabyte or more in size, much larger for fonts with CJK alphabets). And fully embedding a font does not allow Acrobat to edit text using the font actually embedded in the PDF file. All text touch-up functionality in Acrobat does require that the font for the text being touched up be installed on the system at the time of edit; the embedded font is not used! And even if it could use the emvbedded font, a fully embedded font does not include all the font metric informatin necessary to fully and properly edit text.
Dov Isaacs wrote:
Is that a change? I thought way back around Acrobat 5 or 6 we used to be able to use the embedded fonts for touchup, but I may be misremembering.
For better or worse, you are “misremembering” - I believe that it may have been possible back in the days of Acrobat 2 or 3, but in no releases in the last dozen years. It is a popular urban legend, though!
I had thought PDF was a 'self contained' file format, containing all the necessary information within the file itself. I thought that If I embedded the fonts, then gave the PDF to someone else, that person woud have all the necessary 'parts' so they could edit the text. I was trying to get rid of the subset so that a character not used in the original version of the document could be added using the same font.
I got this idea from one of our customers who requires all fonts to be completely embedded with no subset in their PDF files so they can do exactly what I have described above.
You're saying that the only way to really do this is for me to pass along the PDF, and the fonts, then have the recipient load the fonts onto the system first before editing the document using Acrobat's touch-up feature.
PDF isn't meant as an editable file format, so this workflow is dodgy at best. Why would you have anyone edit a PDF when you can provide the original files as well?
Unfortunately, your customer is wrong. They cannot edit text in a PDF file using just the fonts, subset or otherwise, in the PDF file. Nor can you open such a PDF file in Adobe Illustrator and so-edit the text. You must have the fonts themselves installed on the system.
Two issues. First, as I mentioned in my original response, what is actually embedded in a PDF file in terms of fonts does not include all the metrics necessary to fully and properly edit text formatted with that font. Secondly, there are a number of intellectural property / legal issues associated with subsequent use of the embedded fonts (itself an issue that could take many pages of text to discuss fully).
Always think of PDF as a Final Form File Format for purposes of display, print, or direct repurposing (such a placement without modification into another document such as another InDesign or Illustrator document). The PDF file created from InDesign, Illustrator, and/or Photoshop is not a replacement for your original source graphic arts source files. For edits, go back to the original InDesign, Illustrator, and/or Photoshop files.
Dov, I have what is perhaps a foolishly tangential question:
What happens in the VDP (Variable Data Printing) world, and with PDF/VT? I don't really know how this works, but I assume a PDF is generated with some placeholder text or fields and the moral equivalent of a spreadsheet can later be attached with all the field contents. How does that interact with subsetting?
I suppose there are similar questions for PDF forms, though maybe they are a lot less important?
You asked an exceptioanlly good question which I am often called upon to respond to as co-chair of the ISO PDF/VT standards committee!
Actually, PDF/VT is also a final form file format, but in this case for data that was already merged into a template, composited, and exported to PDF. There are no “variables” in PDF/VT! The content and layout of a PDF/VT is fully “fixed!” What distinguishes PDF/VT from PDF/X-4, for example, is that with PDF/VT, objects that are used multiple times, such as a logo, paragraphs worth of boilerplate text, images, etc. are defined only once in the PDF file using constructs known as image XObjects, forms XObjects, and reference XObjects but referenced as many times as needed. (A Reference XObject is actually a reference to a page of an external PDF/X-4 file from a PDF/X-5 file which gets included in the output.)
This hyper-optimization using XObjects has two results for PDF files used for VDP:
(1) The size of these files is dramatically reduced since most of the content in VDP files is common, even in so-called variables.
(2) By intelligently caching the content of XObjects, RIPs that are optimized for PDF/VT, such as those employing the Adobe PDF Print Engine (blatent product plug), are able to keep very high speed digital color presses (toner and inkjet in the hundreds of pages per minute range) printing at full speed even though the content is very graphically rich.
The “forms feature” of Acrobat and PDF ironically is not at all involved in PDF/VT.
Oh my, I see red, Dov!
Of course I am not completely ignorant of your postion inf the PDF/VT standardization world :-). I did not realize that a PDF/VT file was a final form fixed file. Since you don't mention one, I can only assume there is not a supported workflow that involves creation of a template PDF and later merging of that template with a data stream, but instead the template must be a non-PDF format, at least with today's tools and workflows?
I suppose the PDF/VT difference is about these reference XObjects, since PDF/X-4 files support image XObjects, and indeed, I understand that InDesign uses them if you export a PDF with the same linked image on multiple pages, especially on a master page. So it doesn't sound all that different.
My question about the "forms feature" of PDF was not about PDF/VT. But rather, if a PDF with fillable forms is produced, and a font is specified for the fillable form field, how does that interact with subsetting if the font is not available on the enduser's system (the enduser is filling out the form). I don't use fillable forms very often, so perhaps this is an extremely naive question. (Perhaps the answers are "it doesn't work at all!" or "No one cares!").
In terms of PDF/VT, the typical template these days is an InDesign document for which some third party plug-ins, such as those from XMPie and the like create the final PDF via internally accessing InDesign's (and InDesign Server's) PDF export capability.
Conceivably, one could put together an application that uses a PDF file with Acrobat forms fields as such a template, but the Acrobat forms fields would need to be totally replaced with standard PDF objects. No one is doing this yet since simply stated, Acrobat is really a lousy layout program. It is easier to do the layout using InDesign, for example.
With regards to fonts and fillable forms fields, Acrobat only allows you to use certain fonts for those fields, fonts that Adobe knows are legally embeddable for edit use. In that case, the full font is embedded and if the font is an OpenType CFF font, the full OpenType CFF font is embedded including all the font metrics. Defined forms fields can be edited with such fonts, but text touch-up will not use them for non-forms fields. (This really gets into an area where even our lawyers fear to tread!)
Ok, than you for your reply. I have learned something new.
...but... and you knew I was going to ask this...
If PDF is a final file format, which is not intended to be edited, why build a tool into Acrobat which let us edit the PDF?
There is a significant difference between editing and touch-up.
The tools provided by Acrobat are for simple touch-up and correcting certain common technical issues and problems associated with PDF files, no more and no less.
The specification for PDF is slmost thicker than the Manhattan phone directory. Providing a tool that can comprehensively and easily edit all aspects of a PDF file is somewhat of a contradiction in terms. Furthermore, there is not any known end-user content generation / editing program that supports absolutely all aspects of the PDF specification.
If the speedometer on my car ends at 80MPH, I shouldn't complain when fire and smoke start coming out of the engine when I try to make it go 100... In other words, use it as it was intended to be used.
Thanks again for your help with this topic.