Sigil-0.9.6 Released

[DiapDealer]

Originally Posted by KevinH

Instead please try what I just pushed to master. I am still not sure the save to disk is needed but that bug fix is needed for editing content content.opf.

Seemed to work great on the Linux side of things. Now doing a Windows build to verify (but I suspect it will work fine there, too).

EDIT: does the trick on Windows, too.

[KevinH]

Good to know! We can decide if that is annoying enough for a new release once we see if any other bugs come up.

[icallaci]

Originally Posted by DiapDealer

In my case: it's simply a matter of editing any css file in any epub on Windows Vista (the only O.S. I've tested so far).

As soon as you make an edit (any edit) to the css file, the code repositions itself so the line you just edited is in the center (vertically) of the Code View Tab. No matter where the line was vertically before you altered it, it will end up in the center after.

I currently can't make it NOT happen on that machine.

Ditto here. It happens on every CSS file, every time (although I'm running Win 8.1, not Vista). Sorry for my slow response; I've been traveling all day.

Edited to add: Just saw the latest posts that indicate you may have found the problem. Thanks!

[st_albert]

Originally Posted by KevinH

Good to know! We can decide if that is annoying enough for a new release once we see if any other bugs come up.

Well, it's not my place to say whether a release is called for, but it is very annoying IMHO.

[eschwartz]

That is why git development versions exist.

[st_albert]

Originally Posted by eschwartz

That is why git development versions exist.

Indeed. That thought occurred to me, and maybe when I'm feeling adventurous one day, I'll go that route. But for now, it's "better the devil you know than the devil you don't know."



Albert

[Tex2002ans]

So I ran into this oddity (bug?) today.

Finereader 12 outputs this footnote code:

<p><a id="bookmark1"><sup><a href="#footnote1">1</a></sup></a></p>

Sigil 0.8.6 + W3C's XHTML Validator thought the above code was well formed... while Sigil 0.9.6 thought it was not.

If I allowed Sigil 0.9.6 to repair the file, it changed the code to this:

<p><a id="bookmark1"><sup></sup></a><a href="#footnote1">1</a></p>

I suspect it has to do with a difference between XHTML 1.1 <-> HTML4/5 and allowing nested <a> tags.

[KevinH]

You are correct, nested anchors are not allowed. As it turns out according to the xhtml 1.1 dtd / schema nested anchors are not allowed in xhtml 1.1 (if you choose strict vs tr it should be caught by a validator). They are also not allowed in html4 or html5 according to the rules and therefore are not allowed in xhtml5 either.

That said, most browsers did display nested anchors as expected, so people still use them but techically should not.

[roger64]

.../...<sup></sup>.../...

Really? When I meet this, I usually suppress it.
And then the two links blend into one. A little like for a Tetris game.

[DiapDealer]

Sup tags always make me hungry.

[theducks]

Originally Posted by DiapDealer

Sup tags always make me hungry.

I thought it was <sub> tags that brought on hunger


For those lurkers
A 'Sub" (or hoagie) is a Sandwich made on roll

[Tex2002ans]

Originally Posted by KevinH

As it turns out according to the xhtml 1.1 dtd / schema nested anchors are not allowed in xhtml 1.1 (if you choose strict vs tr it should be caught by a validator).

That said, most browsers did display nested anchors as expected, so people still use them but techically should not.

Thanks for the info.

Originally Posted by roger64

.../...<sup></sup>.../...

Really? When I meet this, I usually suppress it.

I agree, in most cases an empty tag like that is absolutely useless. I typically strip those things out as one of the initial cleaning steps.

In this case, it is important to see exactly how Sigil decided to alter the code.

In the Before, the footnote number is superscript. After Sigil 0.9.6 does its magic, the number is no longer superscript.

Before: <p><a id="bookmark1">^{<a href="#footnote1">1</a>}</a></p>

After: <p><a id="bookmark1"></a><a href="#footnote1">1</a></p>

I never really noticed this too much since Sigil never complained before + I have a set of Regex I have been using for years and years to clean/condense a bunch of the Finereader cruft. This Regex is one of them:

Search: <p><a id="[^"]+">^{<a href="[^"]+">([0-9]+)</a>}</a></p>\s+<p>
Replace: <p>^\1

Originally Posted by theducks

I thought it was <sub> tags that brought on hunger


For those lurkers
A 'Sub" (or hoagie) is a Sandwich made on roll

Always great when you need to add an explanatory note to your jokes.

[LonelyTutor]

With the latest version of Sigil on OSX 10.11.5, I ran in a rather peculiar issue: Sigil deleted the contents of my images folder. Anybody else ran into that issue?

[KevinH]

Deleted or moved???

Sigil when opening an epub, always changes it to match is internal model. In this case you should find an Images folder (case sensitive name) and it should appear in the BookBrowser window on the far left size of the screen. All images will be moved to be inside that new Images folder and all of the links to them should be properly updated.

If not, please post a sample of your epub showing the issue (if it can be publicly shared - no copyright or license restrictions). If it is private and can not be shared, you can use personal mail (pm) here to send us a link to it (KevinH, or DiapDealer) so we can see if we can recreate your issue.

KevinH

[Toxaris]

The only time I saw that happen, was quite a while ago. The images were referenced correctly in the XHTML files, but with a wrong extension in the OPF. I suspect it was a anti-piracy measure. Since Sigil reads the OPF to see which files to read, the images were not loaded. I don't know if this has changed, at least Sigil also some special files in other directories like the META-INF.
Mind you, this was about 2-3 years ago.