% Sign Being Changed to %25 during HTML5 Conversion

[davidcfrye]

Has anyone run into issues with the HTML5 conversion in Frame 2022 automatically changing % into %25 (the UTF code for %)? There was a similar issue with ? in Frame 2020 (https://tracker.adobe.com/#/view/FRMAKER-11210). While the issue specific to ? has been fixed (theoretically), this issue remains. I'd like to confirm whether anyone else has or can reproduce the issue. Browser type makes no difference. Most current version of Frame--17.0. 

Note: we have links in our materials to sites we don't control, so changing paths or naming conventions isn't always going to be an option. 

[Bob_Niland]

What's the context in which the % is being percent-encoded,
and what's an example string in which this is happening?

Although the % character is Unicode U+0025, ASCII 25h, the % notation was actually developed for escaping ASCII characters that are problematic in URIs (URLS). Even % itself is expected to sometimes be %-encoded, especially if the string it's in might be confused for %-encoding when it's not (for example, the source string has digits following the %, e.g. abc%12345).

[davidcfrye]

The URL is in a hypertext marker. We're doing a standard Publish as HTML5 Responsive file generation. The URLs are lifted from various places and already have things like %20 or %2F etc in the visible URL. When the HTML is generated, the hyperlinks are converted to something like %2520 for %20. It appears to be a straight up conversion of all % signs in the hypertext marker into %25. Does that help clarify the issue? 

[Bob_Niland]

re: Does that help clarify the issue?

For those with experience in HTML5 gen from FM, I'll bet it helps.

I don't use FM to generate HTML, but have some awareness of wider character encoding issues, in this case that the "escaping" character itself probably needs to be escaped because it already is elsewhere in the string(s).

I had been wondering if this was just a matter of some mapping option or table in the Publish workflow, but where the hypertext already includes %-encoded content, the presence of a literal % may be triggering some logic that has no user controls.

Nonetheless, I would expect the encoding to not cause problems. Servers & clients should be accustomed to this notation, and serve the object as requested.

[davidcfrye]

It's very similar to an issue where the ? was being converted into the UTF/ASCII/whatever code. It killed all links where it was present. It wasn't an issue until Frame 2020. There was another, sort of similar issue in Frame 2019 that was fixed in release 8, which was that the presence of straight quotes in text would cause a conversion issue where the straight quote and all text between it and the next punctuation mark would just disappear from the HTML output. I can see how the escape character issue might play into that one. 

I haven't been able to find anything that I can do to solve the problem with the tools and settings I can access. I played around with encoding in the .sts file settings, but to no avail. I think it's notable that it only occurs to URLs within a hypertext marker. A URL in open text and with no marker prints as expected (though it is not a clickable link obviously). 

[davidcfrye]

Now I'm wondering how many people even use the HTML publishing option. Getting a lot of thread views, but no comments. 

[K.Daube]

I'm ALSO just watching...

For me the process is still too cumbersome compared to PDF. Which of all these problems and pitfalls can be avoided by proper documentation? I have only little hope to be able to update my "compendium" appropriately next year.

[davidcfrye · Accepted solution]

This bug was fixed in the latest release.