Sigil's error messages

[philja]

Sigil's error messages, displayed in a pink box at the top of the Preview pane, are difficult to read and misleading in several respects.

This causes difficulty in explaining to fellow authors who I'm trying to convert to Sigil. In making small edits using copy/paste, they quite frequently damage a tag.

1. If the Preview pane is not wide enough, the message runs off the side of the screen. The text does not wrap. See Ex-1.png

2. Depending on what's wrong in the code, the message refers to the wrong line/column combination. See Ex-2.png

In the example screenshots, there is a missing < at the closing </p> tag on line 14, column 433 (as witnessed at the bottom, RHS of the screen). See Ex-3.png

The error message reports "line 75, column 8" which in reality is the location in this file at the end of the </body> tag.

3. If the closing > is the one missing at the end of the same paragraph, (on line 14, column 436), the error message returns error at line 16, column 3.

I can see a certain logic in this case because after the use of the 'Mend and Prettify' tool, there is a blank line 15 and line 16 starts at column 3.

Encouraging the use of Prettify complicates the finding of a simple error.
Instead of reporting the last available place where the missing element could be, could Sigil report the first possible place?

There are several instances where the message is difficult to understand but the location is ok. Also, there are occasions when the message gets truncated like this:

"error on line 16 at column 44: Opening and ending tag mismatch: h2 line 16 and a".

And that is not a case of the Preview pane having insufficient width. Moreover, the error in this case was a missing < at column 27, inside an edited internet link.

Links are another item that our non-tech authors often mangle.

[DiapDealer]

Have you considered recommending to non xhtml code savvy authors that they use PageEdit to make small edits? Pretty hard to damage tags in a wysiwyg editor.

If we could easily make the pink QtWebEngine error messages more helpful/accurate, we most certainly would. But we have very little control over them.

[BeckyEbook]

Point 1 can be fixed and the others are IMHO beyond the reach of Sigil, which has no control over the content of these messages on the pink background.

To ensure that the error text does not escape outside the pink frame – create or edit the custom_preview_style.css file in the Sigil Preferences folder. Where's the folder?
Open "Preferences" and click on the "Open Preferences Location" button in the lower left corner. It's there.

Add to custom_preview_style.css file this line:

html parsererror h3, html parsererror div {white-space: normal;}

[DiapDealer]

I'm wondering if we can safely inject that into Preview's CSS (via Sigil's code) without throwing any line counts off too badly?

[KevinH]

Yes, those error messages are not generated by Sigil. They are generated by the Chrome/QtWebengine browser widget used by Qt. They can not guess where the best "fix" is just where they detect that a "fix" (error) has definitely happened in the first place.

Simple missing < and > chars should also be detectable and reported by using Sigil's simple Well Formed check (aka SanityCheck) in the Validation window. So if in doubt you can get a second opinion.

I assume if a user wanted, instead of using the custom preview injected stylesheet for BeckyEbook's solution the user could simply add that css to their own stylesheet while they debug / build their epubs.

[philja]

Originally Posted by BeckyEbook

Point 1 can be fixed and the others are IMHO beyond the reach of Sigil, which has no control over the content of these messages on the pink background.

To ensure that the error text does not escape outside the pink frame – create or edit the custom_preview_style.css file in the Sigil Preferences folder. Where's the folder?
Open "Preferences" and click on the "Open Preferences Location" button in the lower left corner. It's there.

Add to custom_preview_style.css file this line:

html parsererror h3, html parsererror div {white-space: normal;}

Thanks Becky - I created that file and it works perfectly at keeping the whole message within the pink frame container.

[philja]

Originally Posted by DiapDealer

Have you considered recommending to non xhtml code savvy authors that they use PageEdit to make small edits? Pretty hard to damage tags in a wysiwyg editor.

If we could easily make the pink QtWebEngine error messages more helpful/accurate, we most certainly would. But we have very little control over them.

I'll have to have a look into PageEdit. Up to present, I've never considered using it, being quite happy with working in code view. If I want to do anything else in HTML, I use Bluefish.

From what I remember in reading other threads, PageEdit was made independent of Sigil so is not integrated and is limited to Wysiwyg code editing and Sigil is still required for other work on an eBook.

[philja]

Originally Posted by KevinH

Yes, those error messages are not generated by Sigil. They are generated by the Chrome/QtWebengine browser widget used by Qt. They can not guess where the best "fix" is just where they detect that a "fix" (error) has definitely happened in the first place.

Simple missing < and > chars should also be detectable and reported by using Sigil's simple Well Formed check (aka SanityCheck) in the Validation window. So if in doubt you can get a second opinion.

I assume if a user wanted, instead of using the custom preview injected stylesheet for BeckyEbook's solution the user could simply add that css to their own stylesheet while they debug / build their epubs.

I wondered what generated the error messages. Some are even crappier than the ones I mentioned. I've just seen a missing > in the closing paragraph tag referenced NOT to the next actual character position ie ignoring the Prettify white space BUT to a line/column position of the next but one paragraph.

Certainly, the Well Formed Check provides a correct error position indication but describes the error as "illegal character in text" rather than a missing character or even saying what character it expected to find.

[DiapDealer]

Originally Posted by philja

From what I remember in reading other threads, PageEdit was made independent of Sigil so is not integrated and is limited to Wysiwyg code editing and Sigil is still required for other work on an eBook.

Well, it's integrated in the sense that there's a button on Sigil's menu that can be configured to launch PageEdit with all of the current epub's xhtml files available to preview and/or edit (wysiwyg style). And changes that are made in PageEdit will be brought back into Sigil when finished with it.

I was mainly thinking of the fellow authors you mentioned who were making small edits to epubs. My thinking was that if they're not that xhtml inclined, then a wysiwyg editor could be perfect for the small edits you talked about. You can't destroy tags/links you're not copying over (but you can still format text and create/edit links in wysiwyg fashion). Save Sigil for the heavy lifting if/when it's needed.

Once the epub is fully fleshed out, making simple edits to any of the content in PageEdit's wysiwyg editor is quite possible.

[DNSB]

For what it may be worth, the authors I have worked with use Word/Libre Office/other word processor to create their documents. After beating the use of styles into their heads, it is relatively simple to convert the .docx to an ePub and work on formatting from there.

There are only two of the authors I've worked with who were willing to take the time and effort to learn to use Sigil or calibre's ebook-editor to get down and dirty with their ebooks and even those two prefer to have me prepare the ePubs for sending to the publishers.

[philja]

Unmatched or missing quotes on a class name cause various problems on W10 with Sigil 2.3.1 and on MacBook with 2.3.0

<p class=Textbody"> is picked up by the QtWebengine although as noted above in this thread its line/column location is a bit doubtful.

But it is not picked up by Sigil's 'Well-Formed Check EPUB' tool although <p class="Textbody> is caught by Well-Formed Check

Missing quotes <p class=Textbody> is not picked up by Well-Formed Check

<p class='Textbody"> These unmatched quotes are picked up by Well-Formed Check and QtWebengine.

And most curious of all for me is that a single occurence of one of these "quotes" examples produces a whole range of "Fragment identifier not defined" errors by the EpubCheck plugin with references to various pages, lines, and columns. These fragments are nowhere in the vicinity of the missing or unmatched quotes which the plugin does correctly locate.

As soon as the "quotes" error is fixed, a rerun of the EpubCheck plugin finds no faults at all.

So fixing a missing quote cures undefined fragments - hard to believe.

[DiapDealer]

I'm quite surprised that Sigil's well-formed check picks up on ANY mismatched attribute quotation marks, to be honest (in any version of Sigil). The Well-formed check is primarily concerned with mismatched tags or improperly nested tags.

Originally Posted by philja

So fixing a missing quote cures undefined fragments - hard to believe.

Not that hard to believe. **shrug**

It's not the first time that one error will move the goalpost to a different error in a validation routine. And it won't be the last. Not one of them are perfect in detecting all the various ways a user can mess code up.

[DiapDealer]

Having said that, however, the sanity check IS supposed to look for mismatched attribute quotes. And it does not look like it's currently finding any missing open quote instances. Only missing ending quotes.

[DiapDealer]

Potential solution: https://github.com/Sigil-Ebook/Sigil/pull/777

Unfortunately, Well-Formed Check Epub feature is not likely to ever be able flag attributes with no quotes at all. Not without a complete overhaul, anyway. But it's not really intended to be a complete xhtml validator. It's a quick, down and dirty sanity check.

[BeckyEbook]

Hmmm… My two cents:

1. Missing quotes are fixed by Mend & Prettify, not matched quotes are removed (if one occurrence) or shredded (if two or more).

1a.
<p class='test">Blah</p>
Single occurrence -> will be removed after Mend

1b.
<p class='test">Blah</p>
<p class='test">Blah</p>
Double occurrences -> will be "fixed" by Mend to:
<p class='test"&gt;Blah&lt;/p&gt;
&lt;p class=' test"="">Blah</p>

1c.
Other case (unmatched inverted quotes):
<p class='test">Blah</p>
<p class="test'>Blah</p>
will be "fixed" by Mend to:
<p class='test"&gt;Blah&lt;/p&gt;
&lt;p class="test'>Blah</p>


2. Possible real detect missing quotes.
In sanitycheck.py after line 185:

                    ...
                    val = s[b:p]
                    error_msg = 'Attribute "' + aname + '" has missing quotes surrounding the value'
                    self.errors.append((self.tag_start[0], self.tag_start[1], error_msg))
                    self.has_error = True
                    return None, None, None
                tattr[aname] = val
                ...

I feel that this is sufficient to catch missing quotes, as the previous conditions catch other cases.
Of course, this is worth checking. Fortunately, the sanitycheck.py file is available for editing directly (C:\Program Files\SigilBE\python3lib\sanitycheck.py), so the tests don't require rebuilding Sigil, just restarting it.

Of course, it's better to test it; I've only done about a dozen trials.