Zim

Exporting to HTML - Index page linking is broken

Bug #1625977 reported by santiago
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Zim
Fix Committed
Undecided
Unassigned
zim (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

I'm using Zim 0.65 in Windows 10 and there's a problem exporting to HTML with:

1 Complete notebook
2. Default_with_index.html template
3. Each page to a separate file
4. An index page named "index" is specified

The problem is that all index page links are generated as:

<a href='index'>Index</a>

The index page is sucessfully generated as "index.html" in the same folder as the root page, but the index page links have no ".html" extension and they are interpreted as relative to the current page.

I attach a test notebook and generated html.

Santiago

Thanks

NOTE. Yesterday I thought that it is the same bug as in https://bugs.launchpad.net/zim/+bug/545225 and I posted a comment there. But today I realized that in my case the index page is succesfully generated and link generation is different.

Tags: export html
Revision history for this message
santiago (serware) wrote :
description: updated
Revision history for this message
santiago (serware) wrote :

I'm in a hurry and I have programmed a turnaround in the default_with_index template.

In advance warn that I'm a programmer but not a Phyton programmer, and that the template phyton language subset is very restricted.

The turnaround is somewhat tricky because it uses in a tricky way the only function that returns a current page relative uri: resource (maybe there is other function that returns it but I only found this).

The trick consists in get the address of a dummy resource and then replace the part of the address corresponding to the dummy resource by the index one.

To use the turnaorund, in the default_whith_index template replace the code that generates the index link by:

        [% SET indexPage=links.get("index") %]
        [% IF indexPage %]
            [% SET dummyURL=resource("dummy") %]
            [% SET indexURL=dummyURL.replace("_resources/dummy","") %]
            [ <a href='[% indexURL %][% indexPage %].html'>Index</a> ]
        [% ELSE %]
            [ <span class='insen'>Index</span> ]
        [% END %]

Notes:

1. You don't need to have a resources folder with the template name to obtain the dummy relative path
2. Maybe it seems strange to not directly replace the address of the index, but apparently the functions only supports literals.

I attach a test notebook, the default_with_index template renamed as Default_with_index_dummyTrick and modified and generated html where the index links works in all pages.

Santiago

Revision history for this message
santiago (serware) wrote :

I am ordering export templates and I have come to realize that the problem also affects the Default.html template.

The name "Default_With_index" means that the template will generate a left side index panel, because if a index name is specified in the Export dialog the index page is always generated regardless of the template used.

The header links to the index document broken in each page are generated by the following template code included in Default_With_index.html and also in Default.html:

        [% IF links.get("index") %]
        [ <a href='[% uri(links.get("index")) %]'>Index</a> ]
        [% ELSE %]
        [ <span class='insen'>Index</span> ]
        [% END %]

And the problem arises because "uri(links.get("index"))" doesn't return current page relative paths.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in zim (Ubuntu):
status: New → Confirmed
Revision history for this message
Jaap Karssenberg (jaap.karssenberg) wrote :

I believe it is working correctly in zim 0.66 / 0.67

Changed in zim:
status: New → Fix Committed
Revision history for this message
santiago (serware) wrote :

Still working with 0.65, I'll update the last to check.

Thank you very much.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.