Straight Quote/Apostrophe Issues with HTML5 Output

[davidcfrye]

I've run into a very weird problem when generating HTML5 after the latest Frame 2019 update to 15.0.7.973.

Wherever there are single straight quotes in text, if I generate HTML5, one of a couple of different things happens, based on the exact position/pairing of the apostrophe.

1. If something says "clients' rights," the ouput removes both the apostrophe and the spacing, e.g. "clientsrights."
2. If something says "client's right to appeal the decision," the output removes the apostrophe and everything after it, e.g., "client."  
3. The text removal doesn't run past the paragraph marker.

The text appears normal in the PDF output. The text appears fine in the Frame file. There is another oddity--when I prepared examples for this post, I copied the the relevant statement into a Word document. When I paste directly, the resulting text has the same issues as the HTML. If I paste as Unformatted, the text is correct.

I performed a lot of troubleshooting to figure out the issue, but I'm stumped for the moment:

1. This problem didn't occur before updating.
2. It occurs on multiple different machines, both physical and virtual.
3. I have confirmed that copies on multiple machines that had not yet been updated (version 15.0.6.956) do not have this issue.
4. All of the testing used the same files, settings, etc.
5. It didn't matter if any of the files were on the local machine or network machine or both.
6. If I copy/paste text from the version 15.0.6.956 update into a Word doc, it does not have the oddity mentioned above.

It seems conclusive that it is related to the update. I've checked all the settings that I can think of that might be related to this, but I haven't found anything obviously tied to it. I don't see anything about straight quotes or changes to paragraph styles. The Word oddity seems to point in the direction of some underlying paragraph tag issue or setting.

Does anyone have any thoughts about what the issue might be? I can find no other mentions of this issue anywhere. We recognize that we can use curly apostrophes/quotes and that is our temporary solution. However, we would prefer not to have our choices limited if they don't have to be.

[Winfried Reng]

Hi,

When this had worked in the 15.0.6 and now it does not, then this seems to be a bug.

Can you check how such a sentence looked like in the HTML code in 15.0.6 and how it looks like in the 15.0.7?

Just enter something like mmmmmm and then search for this text across files with a decent text editor (e.g. Notepad++).

In the FrameMaker online help (at least in FM 2020) it is described that a straight double quote is converted to: "

Best regards

Winfried

[davidcfrye]

HTML from previous update:

  <p dir="ltr" class="FM_Numbered_L1_Policy"><span class="FM_BodyNum_Policy">10<span style="padding-left: 26pt;" class="FMAutoNumber_1"></span></span>Prior authorization requests may be submitted to the Prior Authorization Department via mail, fax, or the electronic portal. Prescribing or ordering providers, dispensing providers, clients' responsible adults, and clients may sign prior authorization forms and supporting documentation using electronic or wet signatures. For additional information about electronic signatures, please refer to the 'Electronic Signatures in Prior Authorizations' medical policy.</p>

HTML from updated version:

  <p dir="ltr" class="FM_Numbered_L1_Policy"><span class="FM_BodyNum_Policy">10<span style="padding-left: 26pt;" class="FMAutoNumber_1"></span></span>Prior authorization requests may be submitted to the Prior Authorization Department via mail, fax, or the electronic portal. Prescribing or ordering providers, dispensing providers, clientsresponsible adults, and clients may sign prior authorization forms and supporting documentation using electronic or wet signatures. For additional information about electronic signatures, please refer to the </p>

[Jeff_Coatsworth]

Yup, sounds like a bug all right. Just to check, can you try downloading the FM2020 trial on a non-production machine and update a copy of the docs on it to see if the bug persists? That would give you good ammo for logging a bug in the Tracker (https://tracker.adobe.com/).

[davidcfrye]

Unfortunately, we don't have a non-production machine to experiment on. Due to tech support constraints, we're at the limit of available virtual machines, so I can't even get a temp setup.

This all kicked off when I was helping troubleshoot a newer employee's HTML output. The issue was centered around the left-hand nav on the HTML. Instead of breaking it down along the lines of headings, it was doing it by file, similar to what happens if you generate HTML from a book that doesn't have an active TOC (or one that has been excluded).

I tried a couple of common solutions but wasn't getting anywhere. As a standard troubleshooting step, I checked her version and discovered the change to 16.0. It turned out that when she set up her virtual machine, rather than download frame 2019 to match the rest of us, she went through the main Frame page and trial copy link, which installed 2020. She then opened and updated a book. Unfortunately, she is not the only person who uses those files. After a bit of panic all around, we recovered the folder from our data warehouse, wiped her virtual machine, and reinstalled with 2019. At that point, we realized we were behind an update, so a couple of us updated. That's when this new error cropped up (having a large contract client point out chunks of missing text in the output is painful for so many reasons, not least having to explain that a bug undercut what is otherwise a well-oiled QA process).

Which is all to say, 2020 was already looking like it had HTML generation issues. I'm not sure I can reduce the variables for bug hunting purposes even if I could test it now. I usually wait until the second or third update before getting into the latest release, so the bugs are already worked out.

Thanks for confirming I'm not crazy or just missing something.

[Winfried Reng]

Hi,

The export to HTML5 changed with FrameMaker 2020. Therefore Adobe will fix HTML5 bugs from 2019 only, if they appear also in FrameMaker 2020.

When I copy your problem sentence into a new FrameMaker file (FM 2020) and export this to HTML5, then everything is fine:

Prescribing or ordering providers, dispensing providers, clients' responsible adults, and clients may sign prior authorization forms and supporting documentation using electronic or wet signatures. For additional information about electronic signatures, please refer to the 'Electronic Signatures in Prior Authorizations' medical policy.

Best regards

Winfried

[Jeff_Coatsworth]

You haven't got a machine at home to play with?? I'm sure somebody must have one that they could use to test it out...

[Amitojsingh]

Hi All

We are working on fixing this issue and plan to release out an update for the same. In the interim, we recommend to uninstall FM update 7 and reinstall update 6 and use that for now.

Link for downloading update 6 is available here:

https://supportdownloads.adobe.com/product.jsp?product=22&platform=Windows

the issue is specific to FM -> MIF -> Fm workflows. 

Thanks

Amitoj Singh