Re: [docbook-apps] Webhelp: My adventures therein

Hi, 

Changing 

$('html,body')

to

$('#content')

seemed to work for us.

Regards, 

Robert

On Wed, Nov 2, 2016 at 6:13 PM, Sebastian Holder <> wrote:
Hi Mary, hi all,

under

https://sourceforge.net/p/docbook/bugs/1390/

I have created a bug report (including one possible solution) for the issue with links to local (within-page) IDs. (see quote below)

Best regards,

Sebastian Holder

--

levigo solutions gmbh --------- ein unternehmen der levigo gruppe

Bebelsbergstraße 31                     Telefon: 07031 / 4161-20

D-71088 Holzgerlingen                   Telefax: 07031 / 4161-21

GF: Jürgen Maestling, Jörg Henne        http://solutions.levigo.de/

Registergericht: Stuttgart HRB 245 178  USt-ID: DE216017084

-----------------------------

> -----Ursprüngliche Nachricht-----

> Von: Mary Tabasko [mailto:]

> Gesendet: Dienstag, 9. September 2014 02:45

> An: 

> Betreff: [docbook-apps] Webhelp: My adventures therein

>

> Hi, all.

>

>

> Issues with links to local (within-page) IDs.

>

>   We noted that within-page links did not work. We found the

>   messages on the docbook-apps list about this, and tried

>   commenting out the salient block in the "main.js" file. This

>   fixed the problem for most links within a page (those within "content".

>   (We tried using the fix in the later snapshot, but we didn't see any

>   difference.)

>

>   We also noted another problem with generated links from the sidebar TOC.

>   If you were on a page like, say, "bk01.html" and tried to navigate

>   to "bk02ch01s04#id-4.1.3.4.6" (a totally made-up id value, but

>   the format is what we got), the correct page and local link would load

>   (that is, the new page would be scrolled to the local link), but the

>   sidebar disappeared, and the sidebar toggle would not bring it back.

>

>   (Clicking the Next link followed by the Previous link would restore

>   it, but the direct navigation from the sidebar TOC always clobbered the

>   sidebar.)

>

>   The problem only occurred with generated IDs. Navigating from the

>   sidebar TOC on "bk01.html" to "bk02ch01s04#using-passwords" worked

>   fine. Looking at the gross structure of the links in the sidebar

>   TOC revealed no differences. The difference had to be in the structure

>   of the values of the IDs.

>

>   By default, the "object.id" template with "generate.consistent.ids"

>   set makes values like "id-4.2.6.3". I played around with these values

>   a bit and determined that changing the "dots" to "dashes" solved the

>   problem. That is, links with id values like "id-4-2-6-3" worked just

>   fine. (The original ids work fine within the content block; it's only

>   using them from the sidebar TOC that causes the problem.

>

>   I could find no way to tell the "generate-id" function to alter this

>   structure, so I had to override "object.id" and do it myself. (The

>   problem appears to be in some piece of _javascript_, but I have not

>   attempted to find it. The browser follows the links fine.)

>

>   For completeness, I put "." characters into a couple of our explicitly

>   provided IDs and the links to them. They then exhibit the same problem:

>   the sidebar does not appear when you traverse to such an ID. (This

>   was not a browser-specific problem, either.)

>

>   Note: Unless you have "." in your explicit IDs or have set

>   "generate.consistent.ids" for some other reason, this issue wouldn't

> affect

>   anyone who didn't generate the sidebar TOC separately like we did.

>

---------------------------------------------------------------------

To unsubscribe, e-mail: 

For additional commands, e-mail: