White floods on imported AI files print pink-ish when printed directly from FM

[schervinsky]

We've recently run into a problem when printing directly from FM (using FM 12, structured, EDD - not DTD)

We import Illustrator .ai files into our FM files. Some are schematics that use white fills inside boxes (essentially line art with white fills). These files print as intended from Illustrator as well as from a generated PDF - even when I print a screen resolution (aka RGB, low-res) PDF file.

The AI files are created in Illustrator from scratch in a CMYK color space. They are saved as CMYK .ai files. They are imported into FM as referenced illustrations. We print to a Canon iR-ADV C5045/5051 color laser printer using its postscript driver. Color management settings for the printer are set to system default for all renderings.

While it is possible for us to generate pdf files and print exclusively from those, I'm trying to troubleshoot why this is happening all of a sudden (last week, printing direct from FM was fine). Where would you start looking?

Thanks for any help on this.

[Arnis Gubins]

There are a number of pitfalls in your described workflow.

1. Directly importing .ai files into FM only sems to work because the internal structure is PDF-like and FM is using it's PDF import filter to internally convert this into an EPS. There is information that is being lost in this process. Either save as PDF or EPS from Illustrator first [you've been down this road before]. See Dov Isaacs comments on this: Re: FM 12.0.3 patch released

2. Printing directly to a postscript printer from FM uses the Windows GDI for output resulting in RGB output. If you have CMYK data in the FM file, it is then output to RGB and then printed on a CMYK device. How many non-linear transformations are taking place?

3. The recommended route for direct CMYK output for FM is to use the SaveAsPDF route with the CMYK option. Alternatively, you could try using Grafikhuset's PubliPDF to transform FM's RGB postscript to CMYK in a more controlled way.

4. The GetLibraryColorRGBFromCMYK setting in the maker.ini file has four different values (Print, Screen, Print & Screen, None) that will affect how FM outputs colours.

Even though it seems easier to print directly, I would recommend first creating a CMYK PDF from FM and then feeding that to your printer to minimize the number of places where colour-space transformations may take place.

[schervinsky]

Thanks for the reply.

Not to stray too far from the topic, but for your advice on #3, I've had issues with "Save As PDF" in the past, so I've always been in the habit of printing to PDF (File, Print, select Adobe PDF as the printer). The other editors here work as you described and have had no issues. When I say "issues", they've ranged from unpredictable print output to pixelated displays of screen shots (different company, where I was a software tech writer).

Back to the response - my big concern is that there were no problems last week and there are problems this week. I wasn't sure if there may have been some sort of update that was released over the weekend. Our systems are highly controlled by IT, so I don't know what updates are applied or when. These updates may have been to our computers, or maybe to the printers. I'm just trying to isolate why things were ok a week ago.

[Arnis Gubins]

There were issues with the SaveAsPDF route in much earlier FM editions due to various reasons (Adobe changed default locations for Acrobat joboptions files at one point which messed things up; not having the AdobePDF as the default printer also was a big factor; the first iteration of the CMYK PDF function in FM10 failed with some fonts and graphics, etc.), but it is quite stable now [when properly configured].

There have been no updates on the FM side, since the FM12.0.4 release back at the end of January. Perhaps there are some configuration/profile selections in the Canon printer that have changed?

[Mike-Hardy]

We have ongoing problems with font embedding if we use Save As PDF in the CMYK colorspace.

This issue occurs in all versions of FrameMaker 12, including the most recent 12.0.4. The issue is most likely to occur for larger books, and is not seen for simple single files. The resulting PDF has fonts embedded in it, but these fonts often omit many of the glyphs that the document uses. This causes large sections of missing text when the output or display device does not itself have the fonts. Of course, your own system does have the fonts, so the issue is not apparent if you proof your documents on screen.

To reliably create CMYK PDFs, we instead print to the Adobe PDF printer, using system fonts only:

One-off setup for system:

1. From the Windows menu, choose Devices and Printers.
2. Right-click on Adobe PDF.
3. Click Printing Preferences.
4. On the Adobe PDF Settings tab, ensure that Rely on system fonts only is checked.

This is necessary to ensure that all required fonts are embedded.

One-off setup for documents in book:

1. Select all files in your book.
2. Choose Format > Document > PDF Setup, and select CMYK.

This ensures that the CMYK colorspace is used.

To output a PDF:

1. Choose File > Print Book….
2. Click Setup, and set the printer to Adobe PDF.
3. Ensure that Generate Acrobat Data is checked.
4. Ensure that Print to File is clear.
5. Click Print.
6. When prompted, choose the PDF destination. This dialog sometimes opens behind others; the print stalls until you complete it.

[Arnis Gubins]

Mike,

AFAIK, if you use the Print function, FM still uses the original RGB postscript header and route, regardless of what you have set in your PDF Setup. This is not the same as using the SaveAsPDF CMYK one. Unfortunately, the CMYK header [pinched from the unix versions and old PS Level 1 to boot] is hardcoded internally in the executables (unlike the RGB file-based ones that can actually be tweaked by postscript-savvy users). There are seldom font issues with the RGB route using SaveAsPDF, which is why you're probably not seeing any problems when you print to PDF. The CMYK PDF route still has issues with some OTF Pro-level and TTF WGL fonts - I suspect it's due to the PS Level 1 vestiges that are introduced into the postscript stream.

The most reliable route [still] for me to get press-ready CMYK output is to use the Print to File and then pass the postscript through Jacob Schäffer's PubliPDF to control the RGB to CMYK & Spot conversions.