Tolerance and parsing mistakes

[roger64]

Hi

Sigil 9.2. Archlinux 64 bits.

I now switch often between the Calibre Editor and Sigil (the lattter for some more advanced features or plugins). I like better the Editor because of its smooth selecting. I have the feeling that Sigil is "reluctant" to select and does it by small hiccups.

As an editing tool, Sigil should maybe be a bit more tolerant to user's mistakes. A case in point: on a fairly complex EPUB, on the Editor, I modified two tags on two different chapters and closed them, mistakenly of course, with /subtitle instead of /p. That's life...

I switched to Sigil to do another task: it informed me that two chapters were ill-formed and that the EPUB could not be opened. God! If the Editor does the same, I shall be kicked out of my book. Happily, the Editor welcomed me back and informed me of these two parsing errors.

The point I wanted to make is that, as an editing tool, Sigil maybe should be more tolerant to parsing errors of this kind.

[DiapDealer]

Originally Posted by roger64

I like better the Editor because of its smooth selecting. I have the feeling that Sigil is "reluctant" to select and does it by small hiccups.

This is a known issue with Qt on some Linux machines--mine included.

Originally Posted by roger64

I modified two tags on two different chapters and closed them, mistakenly of course, with /subtitle instead of /p. That's life...

I switched to Sigil to do another task: it informed me that two chapters were ill-formed and that the EPUB could not be opened.

I'm sorry, but Sigil informed you of no such thing. If you have Sigil configured to Mend Code on Open, it would have informed you of the well-formed issue and offered to automatically fix it for you. Answer "Yes," and it would have turned your /subtitles into /p's. Bada-bing. Answer "No," and Sigil will still open the epub and you would have been able to run the "Well-Formed" check (F7) and it would have informed you exactly where the problem was.

If you don't have the "Mend Code on Open" checked, it would have opened the epub, showed you a warning about the well-formed issue, and you would have been able to run the "Well-Formed" check (F7) and it would have informed you exactly where the problem was.

Well-formed errors will, quite simply, NOT stop Sigil from opening an epub. Ever. You're exaggerating. Like the calibre editor more all you want, but please don't come here and stretch the truth about problems you're having with Sigil.

[BetterRed]

On the first issue of 'smooth selecting' - care to elaborate. Oh, I see DD already has.

Windows here - My perception has always been that the calibre editor has more of lag when selecting text. To select text I use the keyboard, never the mouse. Been a while since I did any text editing with calibre editor though, so perhaps it's faster now. Never noticed any lags or stutters in Sigil - unlike almost any browser Ψ²

I also get the messages that DD speaks of when opening some public domain ePUBs published by EU agencies such as the EIB!

BR

[roger64]

@DiapDealer

Please believe me, I don't intend to strech the truth and sorry if I give you this feeling. I selected an option so as Sigil does nothing on opening an EPUB because of some Doctype issues I had reported about.

I did not invent this message from Sigil. OK next time, I'll send you a PM if you find my messages too unpleasant. Meanwhile, I will try to reproduce this.

Cheers

[roger64]

I wrote again the two mistaken subtitles. I got this. There was also another error I don't remember. This time the message is less frightening because I can't update only the two wrong chapters.

But I am still puzzled, what interest should I have not to speak the truth?

For the selection, good to know I am not alone experimenting this.

[Notjohn]

The people who write software are heavily invested in it, just like the people who write books. Neither sort takes criticism well.

And since English is not your native language, your post may have seemed harsher than you intended.

Don't take it personally! You can learn much on this forum.

[DiapDealer]

@roger64: Your image of the error still in NO way shows an epub that Sigil "can't open." After you dismiss thar error message, just run a Well Formed check to find where the error is and fix it manually.

My problem is with you saying that Sigil "can't open" the epub when that's simply not true. Mismatched tags are not enough of a problem to make Sigil fail to open an epub. In fact, there would have to serious structural issues involved for an epub to be unable to be opened by Sigil. Sigil will bark and warn you upon opening it about these well-formed issues, sure. But it won't stop you from opening and fixing them (either automatically or manually).

[DiapDealer]

Originally Posted by Notjohn

Neither sort takes criticism well.

I resent that. I take valid criticsm very well. Saying Sigil "can't open" an epub with well-formed errors, however, isn't crticism. It's a falsehood. Big difference.

I think roger64 would be very happy to tell you how helpful and appreciative I've been in fixing issues he's brought up with Sigil on Linux in the past.

[roger64]

Originally Posted by DiapDealer

I resent that. I take valid criticsm very well. Saying Sigil "can't open" an epub with well-formed errors, however, isn't crticism. It's a falsehood. Big difference.

I think roger64 would be very happy to tell you how helpful and appreciative I've been in fixing issues he's brought up with Sigil on Linux in the past.

Oh certainly you have - and still are - very helpful no question about that. For example you completed and perfected the code I had brought up written by pingouinux for the cm to em extension in Calibre (with a little hint of Kovid Goyal). and I keep using this extension for all my books. You also produced some Linux builds (Debian) for Sigil.

I certainly did not try to be mischievous and reported what I've seen displayed just because it surprised me even if my English is poor. Next time, I promise, you'll get a screenshot.

I sincerely wishes the best for Sigil because I begin to use it again.

[DiapDealer]

No problem, Roger. Getting a sample epub that will exhibit the issue would be extremely helpful as well. If you have an epub that calibre will allow you to edit that Sigil absolutely cannot open (I mean can't here, mind you, not "opens after errors/warnings"), then of course we will want to remedy that, if possible. All I'm saying is that the well-formed html issue you described (wrong closing tag), wouldn't be enough to make that happen. The tolerance for that kind of parsing error, that you were requesting, is already present. Whether there's a different kind of issue Sigil should be more tolerant of is yet to be determined.

Apologies for "snapping" at you, but you have to admit that you didn't really present this in a typical bug-report kind-of-way.

[theducks]

Originally Posted by DiapDealer

This is a known issue with Qt on some Linux machines--mine included.


I'm sorry, but Sigil informed you of no such thing. If you have Sigil configured to Mend Code on Open, it would have informed you of the well-formed issue and offered to automatically fix it for you. Answer "Yes," and it would have turned your /subtitles into /p's. Bada-bing. Answer "No," and Sigil will still open the epub and you would have been able to run the "Well-Formed" check (F7) and it would have informed you exactly where the problem was.

If you don't have the "Mend Code on Open" checked, it would have opened the epub, showed you a warning about the well-formed issue, and you would have been able to run the "Well-Formed" check (F7) and it would have informed you exactly where the problem was.

Well-formed errors will, quite simply, NOT stop Sigil from opening an epub. Ever. You're exaggerating. Like the calibre editor more all you want, but please don't come here and stretch the truth about problems you're having with Sigil.

I run Sigil with pretty/mend OFF on load

A 'Well formed' error DOES break the books paths (When Sigil stuffs Images, Styles). The links are NOT updated in the book, resulting in many broken images and no stylesheets and possible MASSIVE loss if you run a clean unused against the book

[DiapDealer]

Originally Posted by theducks

I run Sigil with pretty/mend OFF on load

A 'Well formed' error DOES break the books paths (When Sigil stuffs Images, Styles). The links are NOT updated in the book, resulting in many broken images and no stylesheets and possible MASSIVE loss if you run a clean unused against the book

Which is why you should learn to trust Mend, and turn it on.

Seriously, it's not Tidy. Turn it on and see for yourself. You can't blame Sigil for problems that might arise from instructing it NOT to fix the errors that it can easily and absolutely non-destructively fix. Turning it off is essentially telling Sigil that you're willing to work with broken code (or that you know absolutely that the the code is perfectly valid beforehand). It would then be up to the user (who was notified upon opening that there were problems) to manually fix that which they told Sigil specifically NOT to fix before proceeding to run any automated tasks.

Again: Mend is not Tidy. Turning it off when opening an epub entails taking full responsibility for properly dealing with problematic markup. It should only be turned off by those willing to accept that responsibility.

[KevinH]

Hi,
No surprise here but DiapDealer is exactly right. The gumbo parser is an automatic repair parser using the exact same html5 parsing rules as all major browsers. It will detect things that even epubcheck will not complain about and happily fix them if allowed. Browsers use these same rules and repair things silently. Turn on Develop in your browser or Inspector and see what the browser did to your code to verify this.

For example in html5 is it illegal to use the numeric entity for a carriage return:

& # X 000D ;
 or 
& # 13 ;

The spec is quite clear on this ...

The numeric character reference forms described above are allowed to reference any Unicode code point other than U+0000, U+000D, permanently undefined Unicode characters (noncharacters), surrogates (U+D800–U+DFFF), and control characters other than space characters.

Yes people try to do this to hide a carriage return inside a heading tag for example (instead of using <br/>).

Technically this is illegal and the well-formed check will barf about it, but happily accept it and replace it with the actual carriage return character (which will become a space). This is exactly what browsers will do as well. As more and more ebook reading software becomes webkit/gecko/blink/ browser based in mobile devices, these things become important.

So although the gumbo-based well-formed check is quite picky, it is also quite right about things (the gumbo version Sigil uses has passed the complete html5 testsuite with flying colors) and is safe to turn on. I enable Mend on Open all of the time as a result so that these little nits are fixed, tag mismatches are handled, and etc.

Hope this helps,

KevinH

[eschwartz]

I think the critical reason for me, why gumbo's mending is OK to leave on automatically, is that anything it changes -- even if it is something you didn't want -- will be changed to exactly the way a standards-compliant HTML5 rendering engine would interpret the malformed code anyway.

There is literally no way it can be worse than it was before. And the HTML5 parsing rules are pretty good about making the correct, reasonable call, so it is often the exact same change you would make yourself anyway.

Standards -- they're good for you.

[DiapDealer]

Thanks for the vote of Gumbo confidence.

With regards to malformed code, you are literally taking a greater risk by leaving it unchecked than you are by checking it. I know people are still gun-shy from the days of htmlTidy, but it really is true.

I would only consider unchecking it if I was opening markup that I was intimately familiar with and 100% certain of. And in that case ... there'd be no reason to turn it off since nothing would get altered anyway.