links in "Contents" panel do not work

[bobh0303]

In v0.9-alpha1:

All the links in genindex.html start with a /, requiring the project to be on the root of the drive to work. Example:

<a class="reference internal" href="/opentype-shaping-indic-general.html">Indic general</a>

[bobh0303]

Looks to be true in most of the files.

[n8willis]

All the links in genindex.html start with a /, requiring the project to be on the root of the drive to work.

Where are you encountering genindex.html? My recollection was that that's an internal file that Sphinx creates — which is not to say that you shouldn't look at it, but I don't recall there being any links to it so it's important to understand how/when it comes up.

That's tangential, but important as part of the build. The start page is meant to be index.html, which would (naturally) get served up automatically by most web servers. I do want to understand what's going on with genindex.html nevertheless.

Looks to be true in most of the files.

Can you give me a specific file and paragraph? I need to see what you're seeing. Even just one. I can see quite a lot of links for which that's not true, myself, so it would save me some time to not have to search them all.

[bobh0303]

referring to genindex was a mistake, sorry.

None of the links in the "Contents" panel work for me. If I make the window wide enough, the table of contents appears to left of main document. If the window is narrow it appears at the bottom of the page. In either case the links do not have the current directory prefixed.

Perhaps I'm not doing something correct, but here's my experience:

Steps to repeat:

• Downloaded https://github.com/n8willis/opentype-shaping-documents/releases/download/v0.9-alpha.1/ShapingDocumentsHTML.zip and unpacked it somewhere other than the root folder of C:
• Open, for example, opentype-shaping-arabic.html , in Chrome.
• Make window wide enough to expose "Contents" on the left.
• Click any link in the Contents

Result:
The "Indic" link directs me to file:///C:/opentype-shaping-indic-general.html which causes a File Not Found error. Other links give similar File Not Found error.

The attached video demonstrates this.

Recording.showing.broken.links.mp4

[n8willis]

None of the links in the "Contents" panel work for me.

Okay, so that (sidebar) is content that comes only from the theme, rather than from the document sources.

I've just pushed some changes that ought to improve it a lot; please take a look and let me know if it resolves the links issue.

What the changes do is build a purely static navigation block through Jinja templates, bypassing the Sphinx builder. I'm sure that the issue you were seeing was just due to path manipulation shortcomings; the fix that I pushed just adds some logic to use full internal URL paths and create them in the template.

Steps to repeat:

• Downloaded https://github.com/n8willis/opentype-shaping-documents/releases/download/v0.9-alpha.1/ShapingDocumentsHTML.zip and unpacked it somewhere other than the root folder of C:

Correct; the download should work; it's just that the previous build expected to be on a server, so full Windows paths tripped up the URLs. The just=pushed change ought to fix that. Please do give it a try.

There is one other factor that can matter for potential downstream users. Sphinx provides a html_baseurl variable that you can set in the top-level conf.py file. That might be something that someone would care to set if publishing the doc set on their own server, but currently the project's configuration leaves it unset.

The sidebar navigation template should pick it up if it is present, however, and still produce correct links. So if anybody (@bobh0303 or otherwise) has a need for it, please do feel free to test the HTML build on an installation where you set html_baseurl.

If it works, I'll tag it as a new beta version.

[n8willis]

Also theme-related, I think that the horizontal alignment problem noted by @wezm in #171 (comment) is also mostly cleaned up.

The base Sphinx theme always puts the navigation block at the bottom of the page on mobile screens with a narrow enough viewport, so that's not simple to fix, but getting the horizontal block alignment to be more sensible is doable at least. It's a little circuitous how the theming works, with the blocks placed differently between the base theme and Alabaster, so it may need another tweak. But it is improved in my testing.