Preview error box using custom fonts

[Vanguard3000]

Hi, I've noticed this for a long time, but thought I'd bring it up for discussion. Basically, the red error window in the Preview pane uses headers and paragraphs that respect stylesheets linked in the document, and I think that maybe they shouldn't if possible.

From time to time, I'll be editing an ebook that uses a custom font for chapter headers (<h2>). Because the error message in the Preview pane respects linked styles, the error header (and presumably the body text if that is styled) will be presented using the defined styles from the linked sheet. Normally, this'll just mean an amusingly themed error heading, but in some cases it can make the error header illegible.

The instance that prompted me to post this is an ebook I'm editing that uses alien number glyphs as chapter headers. See attached for a sanitized example.

I know it's not a big deal but it seems like it ought to be a pretty quick improvement - the error headers and body text could just override the font-family style.

As a bonus, it'd be nice if they could word wrap, but that's not as big an issue in my opinion.

In any case, Sigil is great - keep up the good work, devs!

[DiapDealer]

Sigil doesn't generate that error page. It's the Chromium default error page. I'm not sure how we could fix that without having to code our own custom parsing error reporting.

Inspector shows the message is not even in the body of the html page--it's in the head with its own inline styling. So it's odd that the book's css would affect it.

We'll have to do some investigating.

[BeckyEbook]

h3 in parseerror is without inline styling.

This error is extremely rare when the CSS for h3 contains an unreadable font family.

Adding one line:

parsererror h3 {font-family: initial!important;}

to a custom_preview_style.css file should suffice as a workaround.