FM 12.0.3 patch released

I installed it this morning. The Adobe Update Manager crashed at 97% completion.

Then I clicked OK and it said it had been successful.

Quality software

Good grief, they've finally enabled moving through table cells with the arrow keys! Astounding.

And you can resize the tiny cross-reference dialog. Hurrah!

Re: some of the bug fixes: I think the one about crashes when you had a 'corrupted colour definition' may have been mine, so nice to see that fixed.

I wonder if this one is anything to do with all the grief I've had with colours in Frame not looking the same in CHM output? We'll soon see, I guess...

"  In the output, a character style defined in a FrameMaker document is defined in theCSS inline style attribute as well as the CSS class attribute. The inline style attribute then overrides the class attribute."

Hmmm, well I just regenerated a CHM, and some of the mysterious instances of cross-references not retaining their formatting appeared to have gone away. I'd cautiously accept this as a fix!

(now all I need to do is repair/revert all the ad hoc workaround kludges I tried to put in to stop the problem )

I cannot get this update to install.

I have tried all the suggestions on Error "Adobe Application Manager is needed" | CS5, CS5.5 but could not get the final one to work.

I type Setup.exe--mode=silent  in the folder containing the application update but just get the error "Setup.exe is not recognised as an internal or external command, operable program or batch file"

I then asked our sys admin who made sure I was using DOS as admin and got me to enter AdobePatchInstall.exe in the folder containing the update. I did this, and got taken to the screen:

..which is the problem I was trying to solve....

Any ideas?

The fact that graphics from Reference Pages can now make it through the Publish command into CHM output is welcome..... although having just tried it there, I found the Publish engine's rasterization of them was so nasty that I got better results just sticking with my old workarounds!

E.g. I have boilerplate icons for "Warning", "Caution", "Note" etc - for my print/PDF manuals, I have vectorized PDF graphics of these on the documents' reference pages, so I can pull them in to the document text using paragraph/table formats... whereas on my online help, previously I just had to just manually position a PNG of the correct resolution where I wanted an icon.

When I tried making a CHM just then, the Publish engine invokes Distiller to make a nasty, overly compressed, low DPI JPEG of the vector PDF graphic on the reference page. It's not even the same *size* as it was in its anchored frame on the body page.

There doesn't seem to be any way in the Frame GUI to change which Distiller settings are used by the Publish command?

Another tiny point: any graphic on a body page is given a tooltip in CHM output (by default, its filename... you can specify one in via the anchored frame's properties) - however, when a graphic is taken from a reference page, it doesn't get a tooltip?

This upgrade, applied to my colleagues installation of FM12, has resulted in the disappearance of all body page elements appearing on even numbered pages in books she PDFs. Reinstalling FM12 and updating brings back working PDFs with 12.0.0 and the two updates (12.0.1 and 12.0.2). Installing the 12.0.3 update breaks the PDF rendering. The elements are there (you can click on the "blank" TOC and it jumps to the linked page, for instance. However, that page will be blank (except for master page elements) if it happens to use a right master page.

BEWARE!!!

Craig

Sorry, I meant odd numbered pages missing the visible representation on those pages. The even pages appear normally.

Craig

Arnis, that worked for me now. Thanks very much.

And I have no subsequent PDF blank pages either. :-)

Thanks

SaveAs PDF, CMYK, High Quality Job Options.

Our IT guys have reinstalled FM12 for Allison (my colleague) and applied updates to 12.0.2 so further experimentation is not possible at this time. They did this after the initial problem appeared, but the problem recurred again once the 12.0.3 patch was applied--but not before--so they reinstalled a second time. We want the files to be used for press work, so RGB is not an option. I can't recall if it worked under RGB, or even if we tried that--I think we did and that it produced a RGB pdf without blank pages, but there was a lot of hub-bub yesterday and I didn't keep a log. However, we really need the CMYK setting. Adobe is looking into the issue with sample files supplied from me.

Are we to understand that the regression test spec for Frame 12.0.3 did not include anything so esoteric as "Can you still make a PDF without it going pear-shaped"? :/

Adobe has found that the presence of an .ai referenced graphic (a small logo) on the right master page was what caused the problem. Not sure if changing it to .pdf will solve the problem or not since we no longer have the upgrade installed. Does someone want to experiment with this and let us know? (The suggestion that we move the master page graphic to the body pages is really not a workable solution.)

Tech Comm Suite 4 had Illustrator packaged together with FM and list FM lists .ai as one of the importable formats. The advantage for referenced graphics being in .ai is that you can click on them to open immediately in Illustrator for editing. That advantage is really minimal for a master page graphic (how often will a logo be edited), so changing it to PDF or EPS (ugly) is easily done if it solves the problem with the 12.0.3 update and applying new master pages to affected documents is easy in FM, but costs a bit of time.

The rationale for using .ai graphics is to avoid multiple formats (.ai save to EPS or PDF) and being able to click to open and edit (not really necessary for master page elements).

Craig

Yes, but that OLE workflow is fairly old-fashioned these days and isn’t much supported as robustly as it once was due to security tightening up.

Are you saying being able to click on a imported graphic (of any sort) is OLE? I think OLE is a rather more specific (Microsoft centric and perhaps problematic) application than what is happening here. Any graphic you click on will open in the application assigned by Windows Properties. For instance, clicking on a PDF will open it in Acrobat (pretty useless from an editing standpoint). But not really an old fashioned way to expect applications to behave, I'd argue.

Surely Adobe has a bunch of standard test files, .fm documents containing all the supported imported graphics formats (which DOES include .ai), and runs regression tests on them for any patch update, including elementary things such as "can you still generate a PDF?) (And all this can be scripted of course!)

Arnis, whilst you are not wrong, of course, it is really not helpful to talk like this!

FrameMaker 12's help (Working with documents > Importing and linking files > Import graphics) clearly states: "You can import Adobe® Photoshop®, JPEG 2000, SVG, and Adobe® Illustrator® files into FrameMaker."

If it doesn't work, then it is a bug! End of.

An interesting perspective…but more interesting if you cited the epoch of Dov’s long career for these opinions, but if we assume this is in relation to the current versions….I certainly defer to Dov’s immense knowledge of all things PDF.

(BTW: I’m not expressing idle doubt, since I’ve seen Dov citations circa 2003 applied blindly to things circa 2013 which have clearly changed.)

And I am silly enough to think that expression of functionally of software actually ought to work, otherwise those expressions ought to be removed from the documentation.

Thanks.

Craig

In terms of support of Adobe Illustrator .ai files in FrameMaker, what I posted a number of years back still holds true today!

FrameMaker support of Illustrator files is based upon its support of PDF files which is based upon its support of the old legacy .eps files, nothing more and nothing less.

When you first save an Illustrator document as a .ai file, it is saved as what looks like the structure of a PDF file. The actual contents of the Illustrator document is stored as “private data” within the PDF file structure. Neither Acrobat nor FrameMaker have any knowledge of this private data file format.

One of the options when saving an Illustrator document as a .ai file is an option labeled Create PDF Compatible File. Enabled (i.e., “on”) by default, this option causes Illustrator to no only store the private data within the PDF file format, but also puts PDF graphical objects into the resultant .ai file such that if you open the .ai file with either Adobe Reader or Adobe Acrobat, the Illustrator document objects may be displayed or printed. Note that this option may also terribly bloats the size of the .ai file, i.e., this is not particularly space efficient. If you disable the Create PDF Compatible File option, you only see a blank page if you open the .ai file in either Adobe Reader or Adobe Acrobat. For FrameMaker users who import such an Illustrator .ai file created with the Create PDF Compatible File option disabled, you likewise do not see any of the Illustrator document's content.

Further note that what is really going on is that when FrameMaker imports a .ai file, it treats it no differently than if it was placing a .pdf file. The PDF file's graphical content is used to create a high quality preview, but for subsequent purposes including high quality printing and PDF creation, is internally converted to the equivalent of an encapsulated PostScript, .eps file in which all color management is lost and transparency flattened. This aspect of FrameMaker has not changed over the years!!!!

In terms of my personal recommendations, if I was trying to get Illustrator content into FrameMaker, I would save my Illustrator document as a .ai file strictly for purposes of maintaining the Illustrator document's source material and nothing else. At the same time (including after making any subsequent edits), I would recommend that copies of the same file be saved as (1) a PostScript language level 3 .eps file with high quality flattening for purposes of FrameMaker import and (2) a PDF/X-4 file (no flattening or color conversion required) for purposes of InDesign placement. Yes, this yields extra files, but it is a hell of a lot more reliable. I have similar recommendations for getting InDesign content into FrameMaker. Export your InDesign file's page as a PostScript language level 3 .eps file with high quality flattening and import that into FrameMaker.

          - Dov

It would be helpful if FrameMaker's user guide explained all that, Dov, rather than simply stating "You can import Adobe® Photoshop®, JPEG 2000, SVG, and Adobe® Illustrator® files into FrameMaker."