Mishandling GIFs during FrameMaker import

[dsch_tw]

I am working in Flare 4.2.1, importing from FrameMaker 7.2 via Acrobat 9.

My gifs look catastrophic. Apparently during the import, the generator creates PDFs out of the GIF graphics and in the end result, the graphics are are super-grainy and lose all their original sharpness. In the past, when I worked with RoboHelp, my graphics looked good.
I noticed that the import process changed the Acrobat Distiller job option settings to a Print-based settings, instead of using my configured default which had the settings I want. This means cancelling the Distilling, changing the job option setting, and starting the import again (and keeping fingers crossed). Ugh!

I was told to refer to the Best Practices document.

Having not seeing any improvements in the GIFs after following the Best Practices suggestions, I copied and pasted my GIFs from my FrameMaker project's Graphics folder into the Output folder. Voila! They look great.
I'm running it now from our application and they look great.
In other words, the FrameMaker-to-Flare import process significantly degrades the quality of the GIFs, despite turning off all downsampling in the Distiller settings and trying both deselecting and selecting "Preserve Image Size".
Please look at the attachments. The BadGIF part shows the quality of the graphic in the Help after the graphic was imported to Flare and published to Output with no downsampling and "Preserve Image Size" turned on. The GoodGIF part shows the quality after I copied my original GIFs into the Output, replacing the GIFs that Flare gave me. I'm sure you agree with me that there's no comparison and the BadGIF result is unacceptable.

Thank you,
David

--
David Schor
Technical Writer
Afcon Software and Electronics
Mobile: 054 478 8253
davids@afcon-inc.com
dsch.tw@gmail.com
http://www.linkedin.com/in/davidschortw

[KevinDAmery]

Hi, David, and welcome to the forums.

This looks like a good catch. Just so you know, these are peer-to-peer support forums: Madcap personnel do monitor them, but for the most part we're Flare users like yourself. So I would recommend submitting your findings directly to Madcap through a bug report. You can make a bug report here:

http://www.madcapsoftware.com/bugs/submit.aspx

I'm not sure if Madcap is aware of this or not: however, even if they are, they've always recommended to us to submit bug reports and feature requests to them anyway, because they factor the number of people who report something into their prioritization decisions for what to address (i.e. the more people report it, the higher priority it becomes).

[dsch_tw]

I've notified Madcap staff about this and have yet to hear a solution. The suggested Acrobat Distiller settings in the Best Practices document did not yield acceptable results. I am hoping that there are people who participate or lurk on this list that have a better solution for this than my workaround, and are willing to share it. And that Madcap solves this.

What I want is simply for the Import process to copy the GIFs (As Is) from their original FrameMaker project folder to the Flare project's Content folder without opening or doing anything to them - just copy and paste the files.

TIA for any helpful feedback.

David
--
David Schor
Technical Writer
Afcon Software and Electronics
Mobile: 054 478 8253
davids@afcon-inc.com
dsch.tw@gmail.com
http://www.linkedin.com/in/davidschortw

[GregStenhouse]

For me, using Flare 4.1, Frame 8, Acrobat 7, Flare successfully copies across referenced GIFs, maintaining the filenames. My graphics properties in FrameMaker are Scale 75%, 96 DPI

I've had problems similar to you when:
- there is an odd DPI setting (e.g. 300) in FrameMaker. 96 is best for online, and is what Flare seems to like?
- I have exported GIFs via Corel PhotoPaint. In this case, simply opening the GIFs in IrfanView and resaving means they are copied across correctly in Flare. Maybe your image tool is saving as a type of GIF that Flare doesn't like?

A couple of things for you to try maybe.

Cheers
Greg

[dsch_tw]

Greg wrote:

I've had problems similar to you when:
- there is an odd DPI setting (e.g. 300) in FrameMaker. 96 is best for online, and is what Flare seems to like?
- I have exported GIFs via Corel PhotoPaint. In this case, simply opening the GIFs in IrfanView and resaving means they are copied across correctly in Flare. Maybe your image tool is saving as a type of GIF that Flare doesn't like?

Me:
My FrameMaker sources include two conditions, Help and PDF. The Help GIFs are 96 DPI, the PDF GIFs are 150 DPI. However, in its ultimate wisdom, Flare imports both conditions even though I hid the PDF condition (another issue about which I've complained to Madcap). Not only that, the import converts both at 150 DPI, completely ignoring the 96 DPI settings. Of course, if I try to enlargen the image in Flare, the result is even worse!
I created my GIFs in Adobe PhotoShop, which is one of our industry's flagship programs for image processing. Then, the images look perfectly fine in my PDFs. It doesn't justify why Flare has to play around with the image files at all - just copy them into the Content folder (or another user-designated folder) and leave them there! Just add an "href" tag to them and leave them alone otherwise.

Thanks! All the best,
David

David Schor
Technical Writer
Afcon Software and Electronics
Mobile: 054 478 8253
davids@afcon-inc.com
dsch.tw@gmail.com
http://www.linkedin.com/in/davidschortw

[LeslieT]

I reported this bug back in February, and I received a response from Tech Support that indeed this was a defect and has been present since 4.0 (I was wanting to roll back in order to avoid this problem). The 3.1 version did not do this, so this is a significant regression in my book.

Anyway, it really should not convert graphics if they are already a web-based file format (such as gif, png, or jpeg). The only reason to do any processing would be if you used Frame's drawing tools to annotate the graphic and you don't want to lose those.

The only workaround that I have found is to copy your graphics into the project Content folder after import and overwrite the files generated by Flare. Unfortunately, I usually have to go into each topic and re-set all the graphics that are not "Print-only," which is a real pain!

[RiverMonster]

Hi David,

I reported problems like this to MadCap back in February too and commented briefly on it in this post (http://forums.madcapsoftware.com/viewto ... =13&t=8032) in relation to graphics that have callouts.

Regarding the job options file I poked around a bit and found that Flare is looking in the "Documents and Settings\All
>Users\Application Data\Adobe\Adobe PDF\Settings" folder and using whatever file it finds alphabetically first there. However, even making sure the "expected" job options file is placed there and alphabetically first does not help matters as the resulting quality of GIFs remains dire...at least in my tests.

Hopefully, this will be improved in V5...

Adrian

[pdxwordsmith]

Madcap knows about this issue. I went though this with them in January. I believe the bug number is 23624.

Here's the topic depicting my struggles:
http://forums.madcapsoftware.com/viewto ... 799#p43708

At the suggestion of one wise person on these forums, my "solution" was to tag images as PrintOnly or OnlineOnly. For print, they're the way you have them. For online, I generate a .jpg file and then include a PassThrough marker with the image information:
<img src="../Resources/Images/4_ClientsCampaignsButton/Slide1.JPG" />

I copy the jpgs over to the Output\Content\Resources\Images folder.

It's a pain, but it works.

[mattbnh]

Anyone know if this problem is fixed in 4.2 (does not seem to be) or 5.0?
Thanks

[GregStenhouse]

From what I've seen so far, v5 seems to handle images much better. The release notes also give a couple of mentions to images from FrameMaker:
* Preserve Image size option is not being honored when Importing Frame docs with images.
* On FrameMaker import, images with high DPI settings in anchored frames are resized to tiny proportions

So on the surface, yes, it looks like v5 fixes this problem.

Cheers
Greg