MobileRead Forums - View Single Post

meme · 10-16-2012, 05:45 PM

One change I'd like feedback on is with the Generate TOC function.

Previously if you used Generate TOC and had a heading 'near' the top of the file, it would use just the filename for the link in the TOC.

At this point in the beta, Generate TOC will always use the full filename#id reference in the TOC. This avoids 'guessing' what to do and always creating the entries consistently.

I don't believe this causes any issues with the TOC on ereaders. That is, if you click on the link in the TOC it will still take you to the right page, but it might 'scroll' the view down so that the heading is exactly at the top instead of displaying the file from the very beginning.

I know if you generate an HTML version, then the heading is scrolled to the top which causes issues with any prev/next links at the top of the page, but I don't know if this causes problems with ereaders.

So I'm just looking for feedback if the current approach is okay, or if the previous approach has to be restored to avoid 'breaking' things.

10-16-2012, 05:45 PM	#46
meme Sigil developer Posts: 1,275 Karma: 1101600 Join Date: Jan 2011 Location: UK Device: Kindle PW, K4 NT, K3, Kobo Touch	One change I'd like feedback on is with the Generate TOC function. Previously if you used Generate TOC and had a heading 'near' the top of the file, it would use just the filename for the link in the TOC. At this point in the beta, Generate TOC will always use the full filename#id reference in the TOC. This avoids 'guessing' what to do and always creating the entries consistently. I don't believe this causes any issues with the TOC on ereaders. That is, if you click on the link in the TOC it will still take you to the right page, but it might 'scroll' the view down so that the heading is exactly at the top instead of displaying the file from the very beginning. I know if you generate an HTML version, then the heading is scrolled to the top which causes issues with any prev/next links at the top of the page, but I don't know if this causes problems with ereaders. So I'm just looking for feedback if the current approach is okay, or if the previous approach has to be restored to avoid 'breaking' things.