[Bug]: Warning for wrong formatted files on opening .epub, but no errors on F7 integrity check

[PhoenixIV]

Bug Description

Hi, I am new to Sigil.

I wanted to open a file I previously edited with calibre. When opening the file I got the error message that there are problems with the file and sigil can try to auto-correct them.

I chose no, because I wanted to see what is wrong. But when I then started the integrity check no errors were found.
This does not make much sense to me.

Platform (OS)

Linux

OS Version / Specifics

Mint 20.2

What version of Sigil are you using?

2.2.0

Any backtraces or crash reports

No response

[dougmassay]

This is not a bug. If you're unclear on how to interpret the warning (the F7 check is a very cursory check to make sure tags are closed and nested properly, nothing more), please ask in our user forum on Mobileread.com. The bug reports system is reserved for bugs, not general questions. Thanks.

…

On Wed, Jul 10, 2024, 8:13 AM Tobias ***@***.***> wrote: Bug Description Hi, I am new to Sigil. I wanted to open a file I previously edited with calibre. When opening the file I got the error message that there are problems with the file and sigil can try to auto-correct them. I chose no, because I wanted to see what is wrong. But when I then started the integrity check no errors were found. This does not make much sense to me. Platform (OS) Linux OS Version / Specifics Mint 20.2 What version of Sigil are you using? 2.2.0 Any backtraces or crash reports *No response* — Reply to this email directly, view it on GitHub <#763>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACG3CXTRYKEMCMSEQXHMRN3ZLUQNFAVCNFSM6AAAAABKUYXPX2VHI2DSMVQWIX3LMV43ASLTON2WKOZSGQYDANJZGY2TMOI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[kevinhendricks]

This is not a bug. This is how Sigil is designed.

The F7 wellformed (sanity) check just checks to see if there are proper closing tags for every opening tag, ie that the text is minimally parseable. The is typically enough for other Sigil tools to actually work. It is not a full epubcheck like validation. You should download and install the Sigil epubcheck plugin if you are looking for actual validation testing.

That error message told you exactly what you were missing: one of xml header, doctype, html ,head, or body tags. In your case it was most likely the doctype that was missing as calibre does not think those are important, or the xml header.

If you are paranoid about what is being changed, you can do the following: Open your epub, say no to the fixing, make a Checkpoint, then save it and close out of Sigil. Then and reopen your epub, allow it to auto fix, then use the Checkpoint Compare to get a side by side set of changes.

Closing this as this works as designed.

[PhoenixIV]

If you are paranoid about what is being changed, you can do the following: Open your epub, say no to the fixing, make a Checkpoint, then save it and close out of Sigil. Then and reopen your epub, allow it to auto fix, then use the Checkpoint Compare to get a side by side set of changes.

That's beautiful! I would not use the word paranoid - it is interesting to see. A lot is changed. Not always for the better.

This is not a bug.

Well, not knowing how simple the F7 wellformed check is, I think it is fair to assume the same outcome when running an integrity check. One could argue it makes no sense to run two different integrity checks.

Would be fun to be able to see what the assistant would like to change from the dialog window.

The W3C epubcheck tool does not care about the doctype, by the way. It does not complain. Even though it is supposed to show every little problem.

@kevinhendricks thank you for your reply. It assumed a little bit more knowledge on my side.

[PhoenixIV]

The W3C epubcheck tool does not care about the doctype, by the way. It does not complain. Even though it is supposed to show every little problem.

Ah, nevermind. I just found this to be a bug: w3c/epubcheck#982

[kevinhendricks]

Please make it very clear exactly what changes made by auto fixing you think are "Not always for the better". I have yet to see it do any damage in over 15 years of using and developing Sigil.

[PhoenixIV]

It's nice to see your detailed interest.

Nevermind, this was more about artifacts that are still left over from the conversion.

Many empty <p> </p> tags or other places with spaces that sigil converts to non-breaking spaces  
I could get rid of those anyways.

Another thing about personal taste of indentation. E.g. I prefer tabs or four whitespaces and there does not seem to be an option. (See request #318 - I would like the ability to easily alter tab/indentation size)
And I am just not used to body being on indentation level 0, as seen in the wizard, but it makes sense.

So see this thread as complete, thanks for the help.

[kevinhendricks]

What wizard? Sigil neither adds nor removes non-breaking spaces. It sounds like you are not properly using css to handle whitespace, indentation, margins, line spacing, etc. Or are you talking about code indentation? If the latter, If you want to change how code is displayed use Sigil's mend and prettify tools.

Asking basic questions is the purpose of our user Forum on MobileRead. We also have a Sigil User manual you may want to read.

[dougmassay]

For the record: using empty p tags for vertical spacing is frowned up just about everywhere. The most popular epub rendering engine in the world will simply ignore them. Adding the non-breaking character/entity will make RMSDK honor it. But even so... I know of no routine in Sigil that _adds_ a non-breaking entity to empty tags. It's more likely that calibre has inserted an invisible non-breaking space _character_ to do the same thing, and Sigil's default Preserve Entities feature converts it to an entity. Edit the Preserve Entities list and it will no longer do that.

…

On Wed, Jul 10, 2024, 11:31 AM Tobias ***@***.***> wrote: It's nice to see your detailed interest. Nevermind, this was more about artifacts that are still left over from the conversion. Many empty <p> </p> tags or other places with spaces that sigil converts to non-breaking spaces &#160; Another thing about personal taste of indentation. E.g. I prefer tabs or four whitespaces and there does not seem to be an option. (#318 <#318>) And I am just not used to body being on indentation level 0, as seen in the wizard, but it makes sense. — Reply to this email directly, view it on GitHub <#763 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACG3CXV4JH5UNGHEXTATYFTZLVHV7AVCNFSM6AAAAABKUYXPX2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRQHAZTEOJVGY> . You are receiving this because you commented.Message ID: ***@***.***>

[PhoenixIV]

Oh people, this is really getting OT. I maintained bug trackers myself and I would not have filed here if the original issue wasn't weird enough for me to let you know from a programming perspective.

calibre has inserted an invisible non-breaking space character to do the same thing, and Sigil's default Preserve Entities feature converts it to an entity.

You are right, this is what happened.

For the record: using empty p tags for vertical spacing is frowned up just about everywhere.

I frown, too. I got a file from a friend I am asked to convert. Still deciding if I want to put in that extra work or leave it as it is - good enough / works.

The most popular epub rendering engine in the world will simply ignore [empty p tags].

Thanks for the warning.

Let's leave it at that.

[dougmassay]

Let's leave it at that.

You mean give you the last word? ;)