Copy link to clipboard
Copied
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.
Are you sure this is the root cause of your particular issue? Version 17.0.0.226 had the issue. Version 17.0.1.305 fixed it. Version 17.0.2.431 seems to have broken it again. But, I had a member of my team experiment with 17.0.2.546 and it appeared to be fixed again. We were able to simultaneously compare output of the exact same links, from the exact same source files, using all of those versions. Can you confirm that the affected copy of Frame you experienced this with was the version you note
...Copy link to clipboard
Copied
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).
Copy link to clipboard
Copied
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?
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
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).
Copy link to clipboard
Copied
Now I'm wondering how many people even use the HTML publishing option. Getting a lot of thread views, but no comments.
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
This bug was fixed in the latest release.
Copy link to clipboard
Copied
It was not fixed. The Version 17.0.3.546 has the same Mistake. What can we do?
Copy link to clipboard
Copied
@Daniel25310388xr77 - if that version (latest Nov 2023) has the issue again, then you need to fire off a bug report using the Tracker (https://tracker.adobe.com/). Send an email to the FM folks too - tcssup@adobe.com
Copy link to clipboard
Copied
Are you sure this is the root cause of your particular issue? Version 17.0.0.226 had the issue. Version 17.0.1.305 fixed it. Version 17.0.2.431 seems to have broken it again. But, I had a member of my team experiment with 17.0.2.546 and it appeared to be fixed again. We were able to simultaneously compare output of the exact same links, from the exact same source files, using all of those versions. Can you confirm that the affected copy of Frame you experienced this with was the version you noted? Perhaps someone on your team is a version behind?
Copy link to clipboard
Copied
I have been wondering too, how many use the html5 publishing option. I most cases it works ok, but there ARE snags and they can, unfortunately, be very time consuming to fix.
Copy link to clipboard
Copied
I too use the HTML5 publishing, and if I search within my HTML after publishing, any title that has a character like a / or , has been replaced with the character code. Underneath, in the actual search result it looks fine.
Copy link to clipboard
Copied
This is neither an answer nor correct.
Copy link to clipboard
Copied
@davidcfrye - corrected now