0.6 Beta take 4 (0.5.907)

[meme]

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.

[signum]

I really like the way it is now. Using 0.5.3, I found myself editing in the appropriate id for the first target on a page. If there is no specific id on the filename, the old sigil reader would pretty much land anywhere and I had to scroll up to see anything at the top. Annoying. This is much better now. Thanks for the change.

[signum]

As long as we're on the subject, there is another rough spot I believe needs to be smoothed out. When I split an html file or rename it, the previously generated Table of Contents is re-displayed. So far, so good. But, it is always displayed in collapsed mode. It would be really nice if the re-display would be in the same mode as the previous display. Chances are, if I split one html file, I'll be splitting it again several times until I'm satisfied with their length. Then, I'll rename everything. It would help if the expanded view, if previously selected, would remain throughout the entire process, or until I set it to something else.

Just my 2 cents.

[DiapDealer]

Originally Posted by meme

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.

[theducks]

Splitting has always caused problems with relative URL's
IMHO I would prefer an option (enabled by default) to always convert these to Full path upon import (this assumes they were valid to start )

[snarkophilus]

Originally Posted by meme

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

Is this hard to make a preferences setting? I also prefer TOC entries to point to the html file, but only because I think it looks cleaner in the TOC.

Thinking out loud, maybe a new class similar to sigilNotInTOC ("sigilAnchorAtHtml" or so - I suck at picking names) would also allow for fine-grained control for when you regenerate a TOC.

Cheers,
Simon.

[mrmikel]

Just a positive note. The handling of everything connected with footnotes is now very easy. Anchors and links used to be a pain, but now even doing a slug of them is easy. The controversy may swirl on over where they ought to be etc, but it is now very easy. Thanks.

I have noticed in the latest beta that it does not always belly flop when there is an invalid html error. For some errors, it does switch to bv, but it throws up a firefox type message at the beginning. This too is pleasant.

[kiwidude]

Originally Posted by signum

As long as we're on the subject, there is another rough spot I believe needs to be smoothed out. When I split an html file or rename it, the previously generated Table of Contents is re-displayed. So far, so good. But, it is always displayed in collapsed mode. It would be really nice if the re-display would be in the same mode as the previous display. Chances are, if I split one html file, I'll be splitting it again several times until I'm satisfied with their length. Then, I'll rename everything. It would help if the expanded view, if previously selected, would remain throughout the entire process, or until I set it to something else.

Not something we can change for 0.6, it is a non-trivial piece of work. Will add it to the list for future consideration though.

Originally Posted by theducks

Splitting has always caused problems with relative URL's
IMHO I would prefer an option (enabled by default) to always convert these to Full path upon import (this assumes they were valid to start )

Care to qualify this with an example from the 0.5.907 beta in particular of where this still goes wrong? I agree there has historically been issues, but I fixed a whole bunch of them (and in doing so added a new problem in 0.5.906 which was fixed again for 0.5.907).

[kiwidude]

Originally Posted by mrmikel

I have noticed in the latest beta that it does not always belly flop when there is an invalid html error. For some errors, it does switch to bv, but it throws up a firefox type message at the beginning. This too is pleasant.

Hmmm... you are talking Book View or Preview View? You should never be able to switch to Book View if the html is not well formed, but yes Preview View will give you the "red box of death" warning at the top if it detects an error.

If you managed to enter Book View with an error in your html then that is definitely not intended or desirable behaviour. We would need full repro steps for doing this please...

[mrmikel]

Originally Posted by kiwidude

If you managed to enter Book View with an error in your html then that is definitely not intended or desirable behaviour. We would need full repro steps for doing this please...

I just switched back to book view...or so I thought. I will try to figure it out.

I think it was not preview view because I don't remember the box at the bottom. Will try to reproduce.

Is it possible to access the undo list? Maybe I could track it back that way.

[theducks]

Originally Posted by kiwidude

Not something we can change for 0.6, it is a non-trivial piece of work. Will add it to the list for future consideration though.

Care to qualify this with an example from the 0.5.907 beta in particular of where this still goes wrong? I agree there has historically been issues, but I fixed a whole bunch of them (and in doing so added a new problem in 0.5.906 which was fixed again for 0.5.907).

No case in 907, that I have seen (Your fix may be why I have not seen any ).
The thing I have run into, have already been identified (and a fix committed )

[meme]

Originally Posted by DiapDealer

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.

I've rolled the behaviour back to use just the filename instead of the id if the heading is at the top of the file. It clearly does cause issues with conversion to HTML, and may cause issues with mobi conversions. I'd rather not 'break' anything, or suddenly require manual editing for common tasks at this point.

A checkbox to switch behaviours is possible, but not for this release.

Sigil should have no issue jumping you to the right place when using the TOC window as any positioning issues should be sorted.

[Toxaris]

Originally Posted by kiwidude

@Toxaris - that "Misc directory" is just a visual thing when seen in Sigil. When you actually save the ePub, the behaviour is the same as previous of retaining it into the META-INF directory? Or at least that is how it behaves for me, and this behaviour is all identical to Sigil 0.5.3?

Sigil still doesn't handle these particular files very "well", in that you can't edit or add them. But if they are present it should effectively ignore them.

You were right. It stayed at the correct location. False alarm, move along, nothing to see...

[mmat1]

1) Clip does not replace multiline-selection

Example:

Select:
</p>

<p>

Replace:
<br />

will not work (nothing happens, clip is not inserted)


2) Replacements of anything with Brackets () with "backreference" \1: Clip will not work in most cases. There's a special thing: if the brackets are the outer characters of the selection, then the replacement is made, but the brackets will land outside ...

[kiwidude]

@mmat1 - actually ElMiko reported both of those on the first page, both have been fixed for the 0.6 release.