View Single Post
Old 10-16-2012, 08:14 PM   #49
DiapDealer
Grand Sorcerer
DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.
 
DiapDealer's Avatar
 
Posts: 27,546
Karma: 193191846
Join Date: Jan 2010
Device: Nexus 7, Kindle Fire HD
Quote:
Originally Posted by meme View Post
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.
Ouch. I always need all of my toc entries pointing directly to an html file rather than an anchor. It probably won't cause any issues with epubs specifically (and I know that's what Sigil is designed for at the end of the day), but it has the potential to cause problems for ePubs that are destined to be converted to mobi. There's always been a potential rendering issue when linking to anchors that are inside of (or part of, in the case of ids used as anchors) formatted elements.

I know it's probably not the sort if issue you were looking for, but if left as is, I'll need to remember to go through and remove each url fragment from all the toc entries in my epubs. Something I didn't have to worry about before.

Last edited by DiapDealer; 10-16-2012 at 08:25 PM.
DiapDealer is offline