Poor graphic quality on FM import

I am experiencing this issue as well. I have a large (600+ pages) book with several screenshots and other jpgs on each page. Each anchored frame also contains a FrameMaker callout in either a text frame, or as graphic text. Some have lines, arrows, etc., while others do not. The resolution of the graphics vary widely.
The issue that I see is that when the images are converted into RH, they are terribly pixelated and unreadable. The text that is clear in FM is unreadable in RH, and the lines and arrows are converted in a variety of ways - none of which match the original FM layout.
I also have the border of the anchored frame as a 1pt line in FM. The RH conversion drops the border from two sides of the image and shifts the remaining two sides over and down so that the border overlays the image by about an inch (it looks like a giant L across the converted image).
Finally, I have found that if the anchored frame in FM contains a graphic frame, which in turn contains a text frame, the RH conversion process causes FM to crash (the good old FrameMaker has encountered an unexpected error and must close...).
My current workaround is to conditionalize all of the graphic elements in my FM book so that the RH Help I am generated has no images in it at all. This is sub-optimal. I have a small group of writers and we do not have the time nor the resources to rework all of the anchored frames in this book. I agree with an earlier poster - RoboHelp for FrameMaker converted anchored frames almost flawlessly. TCS has taken a giant step backward in this regard.

Hi Tom,

I have only a couple of instances where we used FrameMaker's integrated drawing tools to create a vector overlay on top of an underlying bitmap (screenshot).

These images did not import to RoboHelp correctly. The underlying bitmaps were downsized while the vector overlay stays at the original size. (In one instance bitmap numeric callout overlays were flipped upside-down.)

These images are not correctly imported into Flare either. In Flare, Only the vector overlay is imported, and it appears over a gray background block where the screenshot should appear. The rendered Help output looks the same - no screenshot, only the vector drawing.

However, in Flare, at least the vector overlay is sharp, but also not antialiased (so curved and diagonal lines appear to be a little ragged).


Hope this helps.

Wndsfr.

Hi All,

I downloaded the trial version of MadCap flare and it imports my FM 8 books and exports all the images perfectly. (Set no resize on import)

You can trade in your RoboHelp licenses and get $400 off Flare.

Hi,

I have the latest patches, but this problem prevails.

My workaround is to add text and callouts to the screen captures, when necessary, using Snag-it so they become part of the bitmap and won't cause the severe degradation I would otherwise see by using callouts and text from FrameMaker before the RoboHelp import.

Even doing this, the quality at normal size for the Frame page is unacceptable when imported to RoboHelp, so I:

1. create a second copy of the anchored frame with the screenshot with callouts, etc. in Frame
2. put it on a separate paragraph line and anchor
3. increase the frame and image size by about 50 percent
4. condition the whole new version out for the printed docs
5. condition the original (smaller) version out for the online help (make sure the conditional tags are imported into the help system)

This is a painful workaround that decreases the quality of the printed and the online help outputs, but it is the only compromise I've found that gets me close to where I want to be. As with the other numerous remaining shortcomings of the TC suite, coming up with this half-baked solution has been a big time drain.

Regards,

Tom

> my company has decided not to use RH for help....

Same here.

I'm having a slightly different flavor of image problem in RoboHelp:

When I bring my FM content into RH, or simply update it, all the images come in with a lot of extra space around them. I am forced to use the RH image editor to crop the images (it's the images that get the extra margins mostly on the left and the right). Of course, this means that unless I check Preserve Modifications for every topic with a screenshot, I lose all my edits upon update.

Has anybody seen this problem, and is there something I can do on the FM side to prevent this from happening? My images in FM by the way look fine; the anchored frames that hold my images fit snugly around each image.

Any word on this - does Adobe even acknowledge that is is a problem?

Hi MarkPringle

Please reset the settings in FrameMaker File -> Preferences -> General - "Greek Screen Text smaller than :" and make it smaller than 7pt - say 3pt. This should solve the issue of Greek text "xxx" in your images.

I have updated to RH 7.02.001 and FM 8.0p277 but it has made no difference. In a test FM8 file, an imported source PNG image of 49KB @ 972x724px is arbitrarily converted to 28kb @ 527x341px in the RH7 Webhelp rendering process.

My expectation is that a "fix" will simply pass through the source art file unchanged.

Whatever RH is doing, it is a killer for screenshots of GUIs and Web pages, because the text rendering is particularly bad when RoboHelp resizes the images.

The only thing that seems to work reliably is manually reinserting the source art into the RH files.

They do know the definition of "single source" down in Adobe land, right?