Problem of sigil's html reformat

[The_book]

When I use sigil's html reformat function, it cause problem. It changes format in <pre></pre>, which should not be changed.

[DiapDealer]

Must be a fairly old version, then. Sigil's Mend/Prettify has preserved the whitespace inside of pre tags for quite some time now.

Just ran a test on some pre formatted sections and Reformat Html didn't touch them. Do you have a small sample we can use to try to reproduce your issue (provided you verify you're using a recent version of Sigil)?

[The_book]

Originally Posted by DiapDealer

Must be a fairly old version, then. Sigil's Mend/Prettify has preserved the whitespace inside of pre tags for quite some time now.

Just ran a test on some pre formatted sections and Reformat Html didn't touch them. Do you have a small sample we can use to try to reproduce your issue (provided you verify you're using a recent version of Sigil)?

Thanks. By testing, I find the problem is I use <pre><code></code></pre>, which can cause reformat.

[DiapDealer]

Yes. The prettify function is not infallible. If there's a lot of nested html inside a pre section, there's bound to be some line-break alteration. It's probably best not to prettify in those rare situations. The use of pre tags in epubs should be pretty judicious to begin with. It's too easy to create scenarios where content can overflow screen boundaries if not very careful.

[carmenchu]

Originally Posted by DiapDealer

... The use of pre tags in epubs should be pretty judicious to begin with. It's too easy to create scenarios where content can overflow screen boundaries if not very careful.

Well, you solve that with (picked up from W3Schools):

code, pre {white-space: pre-wrap;}

I add it to
-- the stylesheet of any ebook containing code (manuals...)
-- my user stylesheet in the viewer (calibre)
and everything behaves, without preventing past&copy...

If other viewers don't respect it, I feel strongly that they should...

[DiapDealer]

Originally Posted by carmenchu

If other viewers don't respect it, I feel strongly that they should...

Epub doesn't actually work on strong "feels" and W3Schools is not EpubSchools.

But regardless ... this isn't an issue of respecting or rendering. Sigil's Preview handles (and correctly honors) pre code-wrapped content sections just fine (including the pre-wrap css attribute you mentioned). The issue is whether Sigil's Prettyify html feature (found under the Reformat HTML menu) can potentially alter how that same content renders. And the answer is yes... it sometimes can.

Luckily, though; un-Prettified xhtml renders just as correctly in Sigil's Preview. If you have complex pre/code sections with nested html inside that renders precisely how you want it to, it's in your best interest NOT to try and "Prettify" it with any kind of automatic tool.

This kind of situation is exactly why we made "Reformat HTML" an optional, manual choice, rather than the continuously running process it used to be: so people could always choose "correct" over "pretty."

[The_book]

I understand. Thanks.

[carmenchu]

Sorry--maybe there is some misunderstanding.
My comment was meant just for the quoted paragraph, which read 'almost' as a warning against <pre></pre> and <code></code>--or a hint towards some heavy manual editing.
For my part, the only issues I have ever encountered came from the lack of {withespace: pre-wrap}--no more editing seems necessary.
As I am just making manuals from some downloaded html pages, I would appreciate to known in advance if I happen to be wrong...

[KevinH]

The problem is the semantic only code tag wrapping the entire contents of the pre tag including text. I will look into modifying the Sigil source prettify to treat code tags just like pre. Or alternatively change the order so that the code wraps the pre tag since it is only a semantic marker.

[DiapDealer]

Originally Posted by carmenchu

Sorry--maybe there is some misunderstanding.
My comment was meant just for the quoted paragraph, which read 'almost' as a warning against <pre></pre> and <code></code>

Oh, no 'almost' about it! You're, not wrong. I hate pre and all of its attributes and would absolutely recommend not using them in an epub unless absolutely necessary. It's just asking for trouble on various devices/apps, in my opinion.

But Sigil will allow you to use it and it will render it all correctly. You just might not be able to Prettify the code without altering how it renders (depending on if Kevin can make Prettify contend with the semantic-only code tags or not).

[jhowell]

Of course someone is eventually going to come along with a book that uses the “white-space: pre” style on a div and complain that making it pretty messes up the rendering.

[DiapDealer]

INDD is notorious for inflicting “white-space: pre” on huge swathes of body content. Essentially making every line-break in the code relevant and thus unalterable.

[KevinH]

This should now be fixed in master as changing whitespace of anything inside a "code" tag whether wrapped in a pre or not really makes no sense.

[AlanHK]

Originally Posted by jhowell

Of course someone is eventually going to come along with a book that uses the “white-space: pre” style on a div and complain that making it pretty messes up the rendering.

That did happen to me a couple of years ago.

There was some ascii art I did as a "p" style, which worked until Pretty trashed it. I made it a "pre" style and that worked.

So I learned that Pretty did not parse CSS, only respected default tags.

[KevinH]

Yes, the inheritance rules of css make it hard to easily determine which rules will impact which tags and in what way without doing a complete browser layout andparsing. Since users can change what css is active by changing the css file, it is never perfectly clear when to prettify, so we only use the tags.