About the v4.2 patch and PNGs

[garyjgeoaccess]

I installed the v4.2 patch and did some tests. Here are the results.

As the readme in the patch warns, PNG files will get converted to JPEG. JPEG files can be several times the size of comparable files in PNG format. So it should come as no surprise then that the patch doesn't help with the file-size issue. It isn't meant to address this problem.

Note: If you're not familiar with the file-size issue, PDFs generated from FrameMaker (with Acrobat's default settings) can be just a fraction of the size of PDFs generated with Flare -- when multiple PNG files are involved. This is because Acrobat does NOT convert PNGs to JPEGs, as happens with Flare.

With the v4.2 patch, Flare has removed the medium compression limitation on JPEGs. In my docs, the images now generated from Flare look exceptionally crisp. However, if I understand right, Flare is still converting PNGs to JPEGs. So the patch has most likely addressed the image-quality issue by cranking up the compression quality to the top of the chart.

(Note: If you're not familiar with the image-quality issue, Flare converts all images to JPEG, regardless of the original format. AND pre-patch v4.2 used medium compression quality for these JPEGs, resulting in splotchy images with considerable artifacts, particularly noticeable if the images were originally screenshots of a software interface.)

So what's the effect of cranking up the compression quality to the top of the chart? The file size for Flare-generated PDFs has jumped even higher (particularly noticeable when the PDFs include PNGs of a software-interface nature).

In my test, the original PDF as generated from FrameMaker was 5MB in size.
With Flare, pre-v4.2 patch, the PDF was 12.5MB in size (with Flare's default medium quality compression of JPEGs).
With Flare, v4.2 patch, the PDF was a whopping 25MB (with Flare's default maximum quality compression of JPEGs).
(Note: in this test, the output contained over 100 screenshots, all originally in PNG format.)

Instead of making a compression decision for us (and letting MadCap support deal with our complaints), Flare simply gives us the highest quality output possible (with JPEGs being used for all images, which is a considerable compromise). Then, if we want to optimize the PDF, us Adobe Acrobat users (don't most all technical writers have Adobe Acrobat?) can run the files through Acrobat's PDF optimizer. I did this with multiple settings.

Here is what happened to a file that was originally 25MB (as generated from v4.2 patch:
1) Optimizer settings: files over 150dpi were compressed to 150dpi--with low compression. File size result: 5.5MB. Quality? Images were filled with artifacts and unusable.
2) Optimizer settings: files over 150dpi were compressed to 150dpi--with medium compression: File size result: 6.6MB. Quality? Images better but still unusable.
3) Optimizer settings: files over 150dpi were compressed to 150dpi--with high compression: File size result: 9.0MB. Quality? Images still contained considerable artifacts, but were moving toward being usable.
4) Optimizer settings: files over 150dpi were compressed to 150dpi--with maximum compression: File size result: 12.6MB. Quality? Images contained some artifacts but looked decent and were usable.
5) Optimizer settings: files over 150dpi were compressed to 225dpi--with maximum compression: File size result: 22.7MB. Quality? Images were sharp and contained very few artifacts. Definitely usable.

The conclusion here is that JPEG is NOT a good format for screenshots in a PDF. Even when using Acrobat's PDF Optimizer to apply image compression, the file size becomes absurdly large. MadCap needs a PDF generation engine that doesn't rely upon converting PNGs to JPEGs.

MadCap promises to provide controls regarding PDF output in target properties. These controls would allow for tweaking image size/compression. Yes, that is great. But unless MadCap rethinks how they're converting all images to JPEG, they'll still have inferior PDFs.

I want to move away from FrameMaker completely. I want Flare to be the product that allows me to move away from FrameMaker. However, I can't move away from FrameMaker until MadCap comes up with a complete solution for PDF generation. It ain't there yet. But I'm rooting that MadCap succeeds.

[doc_guy]

Thanks for that analysis.

Things are certainly moving in the right direction, PDF-wise.

[LTinker68]

Nice observations. Good info. Make sure you submit that as a bug report (again) to MadCap. Include a reference back to your post, since you clearly show the before and after patch numbers and before and after Acrobat compression.

And everyone else who is producing PDF output should submit a request, too, and reference this post. The more people who complain, the faster it'll get fixed. Submit bug reports to http://www.madcapsoftware.com/bugs/submit.aspx.

[mattbnh]

Has Madcap explained their technical decision to perform this conversion in PDF output?

Have they communicated a future direction that includes support of direct PNG -> PDF without JPEG conversion?

I for one will file a bug report today, because I consider this a major blocking issue for moving away from Framemaker, or even continuing to use Flare for PDF.

I am expecting corporate pressure to go to Adobe TCS because other Tech Comm groups (who now have the same manager as me) stayed with Adobe when we went to Flare. Things like this make it harder for me to stick my neck out, especially in the current job market.

We are being told by management that our tech comm groups must move to using the same authoring tools and formats by the end of the fiscal year. If graphic quality vs PDF size becomes an issue, Flare will lose. (It probably won't become an issue, but the risk is certainly there. All it takes is one customer.)

[garyjgeoaccess]

Has Madcap explained their technical decision to perform this conversion in PDF output?

Not in detail, no. However, the readme that comes with the patch has the genesis of an explanation:
"Because we must convert the PNG files to JPG, projects with large quantities of png files might find their PDF files to grow in size compaired to 4.1. Because of compile times and memory issues in 4.1 - We had to make a decision regarding PNG files and for Flare 4.2 we must convert them to HQ Jpg files."

This decision might be necessary with the approach that they've taken for PDF generation. I assume they are using third-party software for PDF generation. I assume they are not dealing with Adobe. I assume Adobe prices their own solutions a little high for MadCap to afford. However, MadCap simply MUST understand that this solution (converting all images to JPEG) is unacceptable. They need to hear from everyone who hopes to generate PDFs with Flare. Submit a bug report!

Have they communicated a future direction that includes support of direct PNG -> PDF without JPEG conversion?

Once again, not in detail. However, the readme file indicates they do understand at least some of the ramifications of their decisions regarding image conversion and the PNG-to-JPEG problem:

"As we continue to work on solutions in the next version, we hope to address this issue and provide the ability to control image size/quality in the target file. "

So excellent, I think. They'll be working on the problem. However, if the problem is to simply give us controls for the compression--while still converting all images to JPEG--that is not a solution. So once again, submit your bug reports, please. MadCap needs to hear from everyone.

This is an absolute deal breaker for using Flare to generate PDFs. PNGs must NOT be converted when Flare generates PDFs. Adobe Acrobat allows its users to decide if images will be converted to JPEG. This is how Flare's PDF generation engine also needs to work--otherwise PDFs will be hopelessly bloated (and image quality compromised).

[siskamoens]

I totally agree with all that's being said here.
Feature request is submitted!

[garyjgeoaccess]

This problem has been addressed with Flare v4.2.1.

PNGs now go directly into PDFs. As a result, PDF file size has dropped dramatically.

In addition, a control for compression has been added to the Basic tab of Targets (click the Options buttons). The compression control is fairly simple at this point. These controls aren't very well explained by the on-screen help, but the "default" option seems to work great in the limited testing that I've done thus far.