Poor quality reference page images in HTML5 output

[edwardg1189618]

I have been struggling with poor image quality output for all of my graphics that are stored on my reference pages when publishing to html5 or other digital format.

Here are the details:

• I have several high quality svg images that are stored in my reference pages for automatic placement above and below paragraphs.
• These images look great on screen and in pdf output
• All options have been set correctly in Publish output (Outputs->Optimization-Convert SVG to Raster Image not selected, Style Mapping->Image settings-Use distiller to generate image not selected, default format as is)
• I have tried changing preferred dimensions to 0 , 0 - no change
• Framemaker is converting all of the svg files embedded in the reference pages to horrid quality jpeg images
• If I copy and paste the images from the reference page to a body page, everything works fine (the output is a good quality svg)
• Text in the reference pages is also blurry and poor quality jpeg images

Is there a way to get Framemaker to output svg images on the reference pages as true svg images or am I out of luck?

[Bob_Niland]

What version of FM?

[edwardg1189618]

13.01.385

[Arnis_Gubins]

Have you tried setting the Publish to use Distiller to generate the image? This usually produces better quality images.

However, I suspect you've come across a buglet. The SVG should stay as SVG. This function was introduced in the last patch for FM12.

You should file a bug report with samples showing how this is not working.

[edwardg1189618]

Yes I have tried changing the setting to 'Publish to use Distiller' and every other option to no avail.

This is extremely frustrating as one of the main features I moved to FM 2015 was to use the HTML5 publishing. It seems the only way to get this to work properly is to not use reference graphics, which would be a nightmare to manage and increase my pdf doc size.

Here is a sample of my once perfect svg file

[edwardg1189618]

Bug report filed (#4079909)

[AMAGARWA]

Thanks for reporting the bug to us.

Yes, currently we have a limitation of not able to preserve the .svg brought from the reference pages in the published output. They have to be rasterized before output generation.

Would it be possible to use a temporary workaround of:

• using them directly on the body page
• referring some other image type (after conversion of svg to other image type) from the ref-page

Meanwhile we will explore more to see if there are other workarounds too.

Amit

[edwardg1189618]

• The practice of placing images individually in the body pages defeats the whole purpose of reference pages and goes against good document management techniques as each image is then independent and difficult to manage creating overrides throughout the document.
• Have tried using high quality jpg files in the reference pages and get the same result. Again, everything looks great if these same images are placed in the body pages.

This is a huge setback for my project and I am not sure how to proceed. Is there any hope of this being fixed in the near future?

[Bob_Niland · Accepted solution]

>> Would it be possible to use a temporary workaround of:
>> using them directly on the body page

Presumably as imported-by-reference in anchored frames. That, of course, cannot be easily emulated if the RefPage implementation was via FrameAbove, given that FM has no anchor frame position option for AboveCurrentLine (despite people asking for it for a quarter century or so).

> This is a huge setback for my project and I am not sure how to proceed.

What's the output delivery format? If it's some plain text format, like HTML5 or XML, I'd seriously look at writing a script to use late in workflow to replace whatever raster rubbish Adobe is generating with the original SVG. Since it appears that these images are notice and/or safety admonishment panels, there's probably a very small number of identical data patterns to search and replace on.

> Is there any hope of this being fixed in the near future?

I can't recall seeing Adobe commit to such a thing in this forum, which is understandable for multiple reasons. Given how long it took them to support such SVG pass-through preservation as actually works (relative to when SVG import was first supported, and that was years), I would begin implementing a Plan B, and maybe a Plan C immediately.

[Bob_Niland]

Although it might not be helpful in the case of whatever icon that is above, for normal ANSI/IEC safety alerts, I'm wondering they could just be done as text, perhaps even as auto-numbers, using the Unicode \u26a0 symbol, text color, text background color and perhaps forced return \r to get alert-above. This one would be white text on a safety-red bg:
⚠ DANGER
(I wasn't able to get this forum editor to accept the in-line CSS to fully emulate this)

[edwardg1189618]

Thanks for the helpful information Bob. It's good to know that I should move on to plan B and C as soon as possible instead of wasting more time on trying to get this to work.

One work around I developed for html5 output was replacing the rasterized jpeg files with higher quality jpeg files, although this will be a pain to do during updates and increases the image size over SVG.

I like the idea of using Unicode characters and may do that for some of the ANSI alerts, and use the other method for the images that cannot be converted to Unicode text.

One issue I can't figure out is how to get the Unicode \u26a0 symbol to display properly in FrameMaker. It appears as a question mark in the display, but when I publish, it correctly shows the symbol.

[Bob_Niland]

re: One issue I can't figure out is how to get the Unicode \u26a0 symbol to display properly in FrameMaker. It appears as a question mark in the display, but when I publish, it correctly shows the symbol.

That means the font you are using doesn't populate that glyph at the U+26A0 code point.

You'll need to use a font that does (perhaps applied as a Character Format), and as with darn near any Unicode glyph above the Basic Latin (ASCII) code points, you'll need to verify that what survives into the HTML or XML is in fact visible on random client devices.

In that regard, not having used FM's output to HTML (after 7.x, which was pretty useless), I have no idea how such chars get encoded in the output text (UTF-8,  HMTL Entity numbers or Entity names). I also have no idea if you can get FM to embedded a supporting web font in that stream (as Distiller can do for the PDF workflow).

Getting font foundries to comprehensively document exactly which code point they cover is another major frustration. You're usually lucky if you get a list of script blocks. Unicode 8.0 catalogs 120,737 characters (not all displayable glyphs). The vast majority of fonts only populate a small fraction of them. Wiki sez less than a dozen fonts even attempt to support just a majority of the characters.

Further keep in mind that what you see at any time on the web (and in MS Character Map) may be a mere simulation of reality, with all sorts of substitutions and even outright glyph synthesis going on behind the scenes, undocumented. On this blog, that "⚠" is apparently being emitted as UTF-8, with no obvious font declaration, which glyph may or may not be in your default/preferred browser body font, but your browser is covering for you, and finding something suitable somewhere if it isn't.