Calibre 9.11 internal link destination bugfix

[searching...]

Hi,

I just downgraded from Calibre portable v9.11.0 (the latest) to v8.16.2 to address a bug in the former.

In v9.11 conversions from epub/azw3 to pdf were landing internal link destinations too far above their link objects (by about 5-7em, circa 5 lines of text) affecting all ToC entries, footnotes and index links. Downgrading to v8.16.2 restores normal behavior, landing links directly above their objects.

And to fix affected pdf conversions after downgrading, just reopen the affected epub/azw3 in the editor, make any change to the html, eg add blank space, then resave and reconvert it.

Hope it helps,
Nick.

[kovidgoyal]

Anchor destination boxes are defined by chromium (the library calibre uses to render PDF) and are not in calibre's control. Likely a change in newer versions of chromium that come with newer versions of calibre.

[searching...]

Originally Posted by kovidgoyal

Anchor destination boxes are defined by chromium (the library calibre uses to render PDF) and are not in calibre's control. Likely a change in newer versions of chromium that come with newer versions of calibre.

Hi, I don't know how significant a bug you would consider it to be at your end, but I use the converter often enough to consider it significant at mine.

Would you like me to test all previous version 9 releases to find out when it changed? After which you could just confirm if you see the same behavior and leave a disclaimer somewhere, until resolved.

[kovidgoyal]

A few line offset when scrolling to an anchor in a paged format is not particularly significant to me. Indeed in paged mode its invisible since the unit of scrolling is pages not lines.

[searching...]

Ok, perhaps you don't understand the problem (but the issue is with the format converter app in Calibre, not the editor).

The problem is with the landing position on pdf pages, when internal links are clicked.

The landing position should always be above it's object destination, but not several lines above, which only makes the intended destination unclear, and will lose your position in the text, when using a reverse footnote link back.

[kovidgoyal]

Yes I understand it perfectly. PDF is a PAGED format. It's meant to be viewd a PAGE at a time. So landing destinations that are a few LINES off are irrelevant. That said if you find it bothersome feel free to contribute a patch to chromium to get it fixed.

[kovidgoyal]

Well, I had a few minutes, so: https://github.com/kovidgoyal/calibr...04c9bfe216c2d8

[Jaws]

Nick, for what it's worth, this is an assumption that's built in to a lot of PDF readers, too — including the free Acrobat Reader for Windows and at least three different browsers, but not the paid-for Acrobat since CS2 or the free Foxit and Sumatra readers. It will only show up when attempting go to an internal link destination in the reader, because the readers position themselves after the end of the link at the beginning of the next line (or CR/LF in one browser's reader!), not before the beginning of the link. It's just a programmer assumption at a deep level. (And creates real annoyances when not-very-tech-savvy managers, and government officials, take bookmarked documents home to read on their personal systems that have only the free readers installed and get different results from their work systems with different, paid software...)

There's something to be said for both ways of understanding what an internal link actually points to. And that something is not being acknowledged by the other way. It's sort of like the neverending argument over MSB/LSB data encoding.