Skip to main content
Participant
February 8, 2023
Answered

Equations and graphics in HTML output from FrameMaker are blurry images

  • February 8, 2023
  • 2 replies
  • 951 views

We are using FrameMaker 2017 for a document that typically publishes to PDF but now must publish to HTML, as well. 

 

We've resolved most of the mapping issues, but we continue to struggle with the output graphics, particularly with equations. Equations are converted to images in the HTML output (and in most non-PDF outputs I've tested), but the images are so blurry and poorly rendered that they can't be used. In the Style Mapping settings, the JPEG resolution option only goes up to 100! I've tried multiple setting changes and it only gets worse, not better.

 

Is there some way to increase the equations output resolution or is this a known issue for which Adobe has no solution yet? 

This topic has been closed for replies.
Correct answer Bob_Niland

Are you using the legacy FM Equations feature, or XML (MathML, MathFlow, MathType)?

As far as I know, the legacy Eqs always export to HTML as raster images, which is rather less than ideal.

2 replies

Bob_Niland
Community Expert
Community Expert
December 27, 2023

Just to hang these remarks where they might be searched on, I was just playing around with the legacy Eq palette in FM2020, and discovered that, to PDF output, FM is rendering Equation special characters and operator symbols
  as BMP Unicode, in PUA space (U+F0xx range),
and not, as I might have expected,
  as Latin1 codepoints with font Symbol applied.
Interesting. Here's an example:

 

In legacy FM, using character ⊗ in user text would have been:
Latin1 "Ä" (\xC4) with codepage/overlay font Symbol applied (circlemultiply).

 

In FM8 or later, one might have expected the Eq palette to use:
⊗ U+2297 CIRCLED TIMES
(and all the instances of ⊗ in this reply are U+2297)

 

But what FM2020 renders into PDF is:
⊗ U+F0C4 {unnamed Private Use Area codepoint}
and presumably with an embedded font with the glyph for that. The C4 is likely not coincidental.

 

Now, for extra weird, the FM7 (2002, pre-Unicode) Character_Sets.pdf document, which, based on the metadata, was authored in FM6, contains a ⊗ character that's encoded in that PDF as: U+2297 (the proper Unicode for that character). So some Unicode work must have been going on for FM well prior to FM8.

 

Why didn't the Eq palette shift to stock Unicode at FM8? Possibly because no font at that time cleanly populated all the needed code points, but perhaps more seriously because at least one of the needed code points was above U+FFFF (into the SMP code space, U+10000 & up), which FM didn't support then … and still doesn't (FRMAKER-10976).

Bob_Niland
Community Expert
Bob_NilandCommunity ExpertCorrect answer
Community Expert
February 8, 2023

Are you using the legacy FM Equations feature, or XML (MathML, MathFlow, MathType)?

As far as I know, the legacy Eqs always export to HTML as raster images, which is rather less than ideal.

Participant
February 9, 2023

Thanks for the response! It must be the legacy version (we go to Insert > Equations instead of Insert > MathML Equation). This is definitely less than ideal. We can work with images, but they need to be decent quality so people can read them. Is there no way to improve the resolution in the output? Or a way to easily convert the legacy equations to MathML?

Bob_Niland
Community Expert
Community Expert
February 9, 2023

re: Is there no way to improve the resolution in the output?

As I recall, there's a choice of raster formats, and some of the workflow options might allow a higher possible resolution, but equations as raster is just sad, in an era where their semantics and text representation would ideally just be preserved into the deliverables.

Converting FM Eqs to XML has been asked about before, but I'm not quickly seeing a solution.

There may also be a further issue with MathFlow in FM, as FRMAKER-11189 seems to still be open.

If I needed to deal with equations these days, I'd probably rely on an external MathML editor, and import whatever XML, or at least SVG, output from that seemed to be satisfactory.