Highlighted

Robohelp 2017: hyperlinks to bookmarks in same topic not always working in Responsive HTML 5

New Here ,
Jul 22, 2020

Copy link to clipboard

Copied

In this topic, excluding the mini TOC, there are 3 hyperlinks for "ExportList=" .

In the current version of Chrome browser, none of them work.

 

If I check the frame source, the anchor is

<h3><a name="MiniTOCBookMark7"></a><a name="ExportList_" id="ExportList_"></a>ExportList=</h3>

and hyperlinks that link to it are typically like

See <span class="Codeinline"><a href="#Exportlist_">ExportList=</a></span> for more info...

 

This follows exactly the same format as other pairs of anchor/hyperlink that DO work correctly, such as 

<h3><a name="MiniTOCBookMark6"></a><a name="Export_" id="Export_"></a>Export=</h3>

and

See the <a href="#Export_"><span class="Codeinline">Export=</span></a> parameter below for info...

 

I'm sure this topic was initially created/edited in an earlier RH version, maybe 11 or 15. I currently use RH2017.

 

Just to try something, I deleted the "ExportList_" anchor and created a new one in its place called "ExportList2", then edited the 3 hyperlinks to point to the new anchor name.

Interestingly, this created a new anchor that looks like this, this time without the id= attribute:

<h3><a name="MiniTOCBookMark7"></a><a name="ExportList2"></a>ExportList=</h3>

And the updated hyperlinks to now WORK - all of them!

see <span class="Codeinline rh-hide" data-rhtags="-1"><a href="#ExportList2">ExportList=</a></span> below.

 

I am stymied as to why these didn't work before, and why the name change and/or removing the id= attribute makes this anchor work now.

My helpfile is littered with hundreds (if not thousands) of anchors that end with _ (thanks to my predecessor), and this topic alone has lots of anchors with the <a name="xx" id="xx"> attribute pair shown above.

So I don't understand why this one anchor wasn't working, and I don't know how worried to be that other non-functional anchors are present in my very large help project.

 

Any advice would be appreciated!  Thanks in advance!

  -Laura

Adobe Community Professional
Correct answer by Amebr | Adobe Community Professional

It's case sensitive I think. If you change the lowercase l to L in this link to match name="ExportList_" it should work:

See <span class="Codeinline"><a href="#Exportlist_">ExportList=</a></span> for more info...

 

Possibly there's been some change to the server that means case is now important. For example, IIS (windows web server) is normally case insensitive, and the link would have worked fine. But the server admin might have turned on case sensitivity for some reason. Or perhaps you moved to a linux based server which by default is case sensitive. Or perhaps the links were only ever tested locally on a window machine, where they would work fine (because windows doesn't care about case).

 

I think if you can get the server admin to change the server to case insensitive, you wouldn't have to change anything. Otherwise you will need to update all your bookmark links to match the case of the applicable <a name="xxx"> entry. I would also make sure id="xxx" matches name="xxx". (id is the modern way of specifying bookmarks, but name is supported for legacy reasons.)

Topics

Classic

Views

25

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more

Robohelp 2017: hyperlinks to bookmarks in same topic not always working in Responsive HTML 5

New Here ,
Jul 22, 2020

Copy link to clipboard

Copied

In this topic, excluding the mini TOC, there are 3 hyperlinks for "ExportList=" .

In the current version of Chrome browser, none of them work.

 

If I check the frame source, the anchor is

<h3><a name="MiniTOCBookMark7"></a><a name="ExportList_" id="ExportList_"></a>ExportList=</h3>

and hyperlinks that link to it are typically like

See <span class="Codeinline"><a href="#Exportlist_">ExportList=</a></span> for more info...

 

This follows exactly the same format as other pairs of anchor/hyperlink that DO work correctly, such as 

<h3><a name="MiniTOCBookMark6"></a><a name="Export_" id="Export_"></a>Export=</h3>

and

See the <a href="#Export_"><span class="Codeinline">Export=</span></a> parameter below for info...

 

I'm sure this topic was initially created/edited in an earlier RH version, maybe 11 or 15. I currently use RH2017.

 

Just to try something, I deleted the "ExportList_" anchor and created a new one in its place called "ExportList2", then edited the 3 hyperlinks to point to the new anchor name.

Interestingly, this created a new anchor that looks like this, this time without the id= attribute:

<h3><a name="MiniTOCBookMark7"></a><a name="ExportList2"></a>ExportList=</h3>

And the updated hyperlinks to now WORK - all of them!

see <span class="Codeinline rh-hide" data-rhtags="-1"><a href="#ExportList2">ExportList=</a></span> below.

 

I am stymied as to why these didn't work before, and why the name change and/or removing the id= attribute makes this anchor work now.

My helpfile is littered with hundreds (if not thousands) of anchors that end with _ (thanks to my predecessor), and this topic alone has lots of anchors with the <a name="xx" id="xx"> attribute pair shown above.

So I don't understand why this one anchor wasn't working, and I don't know how worried to be that other non-functional anchors are present in my very large help project.

 

Any advice would be appreciated!  Thanks in advance!

  -Laura

Adobe Community Professional
Correct answer by Amebr | Adobe Community Professional

It's case sensitive I think. If you change the lowercase l to L in this link to match name="ExportList_" it should work:

See <span class="Codeinline"><a href="#Exportlist_">ExportList=</a></span> for more info...

 

Possibly there's been some change to the server that means case is now important. For example, IIS (windows web server) is normally case insensitive, and the link would have worked fine. But the server admin might have turned on case sensitivity for some reason. Or perhaps you moved to a linux based server which by default is case sensitive. Or perhaps the links were only ever tested locally on a window machine, where they would work fine (because windows doesn't care about case).

 

I think if you can get the server admin to change the server to case insensitive, you wouldn't have to change anything. Otherwise you will need to update all your bookmark links to match the case of the applicable <a name="xxx"> entry. I would also make sure id="xxx" matches name="xxx". (id is the modern way of specifying bookmarks, but name is supported for legacy reasons.)

Topics

Classic

Views

26

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
LEGEND ,
Jul 22, 2020

Copy link to clipboard

Copied

Hi there

 

Is the page short enough that it all fits on the screen? If so, the bookmarks are actually working, but the page is unable to scroll to position at the bookmark. 

 

The solution to this is to place the cursor at the bottom of the page (in the RoboHelp editor) and press the Enter key about 30 or so times so you add "white space" at the bottom of the page. This should then allow the page to scroll vertically and poisition at the bookmarks.

 

Note that you may have to experiment to see how many times you have to press Enter.

 

Cheers... Rick 🙂

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Adobe Community Professional ,
Jul 22, 2020

Copy link to clipboard

Copied

It's case sensitive I think. If you change the lowercase l to L in this link to match name="ExportList_" it should work:

See <span class="Codeinline"><a href="#Exportlist_">ExportList=</a></span> for more info...

 

Possibly there's been some change to the server that means case is now important. For example, IIS (windows web server) is normally case insensitive, and the link would have worked fine. But the server admin might have turned on case sensitivity for some reason. Or perhaps you moved to a linux based server which by default is case sensitive. Or perhaps the links were only ever tested locally on a window machine, where they would work fine (because windows doesn't care about case).

 

I think if you can get the server admin to change the server to case insensitive, you wouldn't have to change anything. Otherwise you will need to update all your bookmark links to match the case of the applicable <a name="xxx"> entry. I would also make sure id="xxx" matches name="xxx". (id is the modern way of specifying bookmarks, but name is supported for legacy reasons.)

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
HSIDEV LATEST
New Here ,
Jul 23, 2020

Copy link to clipboard

Copied

Thanks Amber!  Great catch - I did not even notice they were using a different case.  That is probably the issue.

I appreciate the help!

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...