Copy link to clipboard
We are also struggling with the result of the HTML5 output. When the file is export as a PDF all hyperlinks work fine, but when exported to HTML5 the link adress is modified if the adress contain characters as "?".
If a link to a external file end like this: http:xxxx/view the adress in the HTML output is modified to http:xxxx/view%20
We have contacted the support about 15 times during the last six month, more or less without any response from Adobe and they just close down ticket. Still waiting for a solution -not any manual work around.
Also have the problems with broken internal X-ref.
Very disappointed of Adobe unproffessional support and ignorance of their customers. After this we now active looking for other solutions to create proffessional manuals with any Adobe involvment.
Copy link to clipboard
The trailing %20 leads me to believe there is an extra space after the URL, which is considered "part of" the weblink.
Additionally, http: should be either http:// or, more likely, https://
What is the full marker text for the failing hyperlinks?
Sincere apologies for the experience regarding the support extended, I will reach out to you for more details on the same so that we can address the gaps.
In context to the above query, we've validated at our end and have created a ticket for the same - please refer to the below url to track the status of this issue.
For me, the ? processes as %3F, and causes the link to fail.
FrameMaker 2019 processes the ? correctly.
I'm also experiencing this problem so have voted for the bug fix and a comment there with more detail. Hopefully this won't take too long to fix!
Our broken links contain a space which is being generated as %2520 instead of %20, causing them to fail.
Copy link to clipboard
We're experiencing this too and it's a MAJOR issue. We have more than 5000 broken links in ONE of our internal policy documents. When are we getting a fix for this? Or has someone found some other workaround?
Frame 2019's last update helped fix another bizarre set of HTML conversion issues surround straight quotes, but that went on for a long time before it got fixed. What is the deal with HTML conversion issues triggered by an inability to properly resolve characters?
What's your FrameMaker version? The latest one is 16.0.4 (Help | About).
There were some fixes for the HTML export. I do not know, if yours was fixed as well, but I would check.
188.8.131.522, which is the latest I believe. Tracker also doesn't show a resolved issue. Would love it if my fellow community members would open the tracker link and give it a vote. This is KILLING us.
FrameMaker team is investigating the issue , Respective stakeholder will update the Tracker issue soon .
I'm glad to hear there's some movement. Unfortunately, we've had to roll back all of our deliverables (40k+ pages of content) to Frame 2019. We tried a powershell script solution to find/replace ? in the the HTML files. However, in the process of investigating this bug, we discovered another--Frame is now adding the first line of text in a file to the left-hand HTML navigation. For example, if you have a volume title as the first bit of text, a chapter title as the second line, and you generate a TOC with the chapter title but no volume title, it adds the volume title into the left hand nav bar above the chapter title when you generate the HTML. I'll be reporting that one as well.
I have to say: the number of strange HTML generation errors in Frame 2019 and 2020 are troubling. While I can see how some people might view these as "just" bugs, they are having a serious impact on our relationship with our customer. The nature of our customer and our contract with them means that there are both possible liquidated damages and required root cause analyses for any sort of error that affects the integrity of the information we publish for them. If a poorly converted question mark creates a broken link to a page of legal disclaimers or appeals rights, it is not just a broken link--it's a failure to disclose legal rights and obligations, which, in turn, affects whether they're going to end up in court. If the presence of a straight apostrophe or quote results in poorly converted text in which everything between that apostrophe and the terminal punctuation mark is missing, it's not just missing text, it's a complete absence of legal policy information that may result in the customer having to pay out millions of dollars in claims that shouldn't be paid. These aren't bugs that affect some tiny website, a how to guide, or a self-published book. We're talking about 40,000 or more pages of highly complex legal text and policy information. Without the help of some sort of third party software or homemade script, there's no reliable way for us to even discover some of these issues in the final product because they're so large. Who notices a single missing half sentence in the middle of page 38303? Or link 2980 out of 10000?
I'm not sure what kind of testing gets done before the code is packaged and pushed, but it's clearly not enough.