I'm working on a catalog in FrameMaker. I'm placing a searchable PDF into my document but when I file>print that content is no longer searchable. What is the correct way to import and export so that stays searchable the entire time?
[Title abbreviated by moderator]
FrameMaker treats PDFs as a graphic. It converts them to an EPS (on the fly) for internal use, hence any original interactivity is stripped out.
However, if by "searchable" you mean that no text content in the imported PDF can be found, then something seems fishy. Which version of FM are using? How are you "placing" the PDF? Are the fonts embedded in the PDF? What type of font and which one(s)? Do you have AdobePDF as your default printer for the FM session? Have you tried the SaveAsPDF route? etc., etc.
The more details that you can provide, the better the chance that someone may have an inkling of what's going on.
I can confirm that problem, we're experiencing it here, too. The problem seems to be related to the internal character encoding in the PDF which changes on the way through FrameMaker (2015).
Detailed example: we're creating images in Adobe Indesign (existing XML workflow) which are then placed in FrameMaker. For years we have exported these images to EPS which worked flawlessly in FrameMaker. PDF output from FM still maintains the text in the images as such, which can be copy/pasted or searched in the resulting PDF afterwards.
Recently we started to output the images from Indesign to PDF (high quality print joboptions) instead of EPS, because the preview quality in FrameMaker is better and the format more up-to-date and universably usable. The PDF itself still contains the text correctly encoded and searchable. However, when importing these images to FrameMaker and saving a PDF from there renders the text in the images to garbage with an unusable ("identity-H") encoding.
The fonts (unicode, OTF or TTF) are embedded as subsets in both the EPS and PDF exports from Indesign. Imported EPS in FrameMaker creates searchable PDF output, imported PDF does not. So using EPS instead of PDF might solve the OP's problem for now. I haven't yet found a reproducible solution for the imported PDF.
Update: made a simple PDF that demonstrates the problem.
re: Recently we started to output the images from Indesign to PDF (high quality print joboptions) instead of EPS, because the preview quality in FrameMaker is better and
Coarse EPS preview can be enhanced by using the scaling trick, but that adds a step to the workflow, and usually requires making sure you are also removing metadata downstream, because it can inflate the size of that particular meta by 4-16x.
re: The fonts (unicode, OTF or TTF) are embedded as subsets in both the EPS and PDF exports from Indesign.
Can you just turn that off in the workflow?
turning off font embedding in an exported PDF is not an option which Indesign offers. I can just control if I embed subsets or the full font, with the default being "subset when less than 100%". I could turn this function off for EPS, but EPS is not the problem here.
I just tried importing a PDF page generated from FM back into FM 2017 and then creating a PDF. No problems!! Text encoding is correct and fully searchable.
Can you verify that the PDF created from InDesign didn't improperly convert the fonts to a Type 1 CID-H subset. I suspect that the culprit here is actually ID. I looked at your sample PDF and there are two types of ArialMT fonts.
I think this may also be Jenni problem - the PDF doesn't have the fonts properly encoded in the first place, so GIGO (garbage in, garbage out).
I think you're on to something. We've been using Arial and Arial Unicode fonts, because these fonts are also used in the original software of the device. The problem seems related to the following factors:
I've done several tests with several fonts and got a PDF with new results, some images are working and some are not. The conclusion from this file (although this is not a statistically relevant number of fonts and formats) seems to be: