where to put user editable css-like file for ease of editing - Page 3

KevinH · 04-15-2026, 08:52 PM

Does that happen with the earlier version as well? I am trying to figure out if this was due to my cleanup or a logic bug.

In the original xhtml before the prettyprint were there spaces or line ends before or after these inline tags?

Given there are no existing pcss rules for inline tags in this code at all, I can not see how the space before or after an i or b tag is not being trimmed away by this code. When dealing with inline tags you can never both trim and condense.

Perhaps I will have to create a new pcss property to not trim pre and post text before or after after inline tags?

KevinH · 04-15-2026, 09:46 PM

Yes, this is a logic bug in that gitee code which never supported condensing anyway. Me adding that it did not help. Using previously trimmed code is never correct for inline tags. I will try to fix it.

DNSB · 04-16-2026, 01:32 AM

Guess my response that it happened with v 0.3.0 is no longer needed.

BeckyEbook · 04-16-2026, 02:15 AM

Ooh…
I’ve only just noticed that! I was testing version 0.4.0 and I’d actually missed the fact that I’d already messed up one EPUB (it’s not a huge problem, as I’ve got a copy).
But it never would have occurred to me that those tags were being altered.

EDIT: All inline tags are touched:

Code:

 <p>It’s <i>just</i> <b>a</b> <em>test</em>, <strong>but</strong> <u>I</u> <del>need</del> <sub>to</sub> <sup>look</sup> <span xml:lang="en">into</span> <a href="#">the</a> problem <br/> thoroughly <img alt="asterism" src="test.jpg"/>.</p>

KevinH · 04-16-2026, 08:59 AM

Yes and unfortunately, the original code has no pseudo css properties to not tell it to trim and no way to differentiate left trimming from right. All are needed when dealing with inline tags.

So it's design, while nice, is quite incomplete. I will try to save it but ...

KevinH · 04-16-2026, 11:25 AM

I am not sure this design can be saved. The problem is all you know is the previousText and the upcoming tag.

But if you think about it:

Code:

<p>

     It’s   <i>just</i>         <b>a</b>   this is the end.
               </p>

The above can be split into many text pieces and each text piece may need to be handled in a different way.

The first piece is from the start p tag to the first i tag. It should be trimmed on the left (not the right) and then condensed.

The second piece is between the i and the end i and it must not be trimmed at all and only can be condensed.

The third piece is from the end-i to the start b tag, and it must only be condensed never trimmed.

The fourth piece is from the b start tag to the b end tag, and again it must only be condensed and never trimmed.

Finally the fifth piece is from the end b tag until the end p tag and this piece of text must be right trimmed and condensed.

---------

So you can see keeping only the previous text and current tag is not enough state information to understand how to properly handle the previous text.

This is why the recursive build up your own contents approach taken by our Prettify works as it keeps full state information.

Interesting design but much more state info is needed to properly work.
Also a full list of tags that are considered inline must be added.

So I am not sure if this PrettyPrinter is worth saving at all.

BeckyEbook · 04-16-2026, 12:07 PM

Unfortunately, that’s exactly how it looks

The Prettifier in Sigil-modified had a fundamental flaw, so you’ll still need to keep adding tags and handling edge cases in the plugin.
It’s rather discouraging.

It’s a real shame that I focused on the positives in the test files and didn’t take a look at more complex text layouts.
Interestingly enough – I actually saw a few isolated cases, but – horror of horrors! – I thought it was just a poorly formatted e-book

KevinH · 04-16-2026, 12:46 PM

Hi All,

One last shot at it before giving it up.

Here is my testcase:

Code:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html>

<html xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops">
<head>
  <title></title>
</head>

<body>
  <p>*</p>


<p>

     It’s   <i>just</i>         <b>a</b>   this is the end.
               </p>

 <p>It’s <i>just</i> <b>a</b> <em>test</em>, <strong>but</strong> <u>I</u> <del>need</del> <sub>to</sub> <sup>look</sup> <span xml:lang="en">into</span> <a href="#">the</a> problem <br/> thoroughly <img alt="asterism" src="test.jpg"/>.</p>


</body>
</html>

and here is what it looks like after running PrettyPrinter_v050.zip

Code:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html>

<html xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops">
<head>
  <title></title>
</head>

<body>
  <p>*</p>

  <p>It’s <i>just</i> <b>a</b> this is the end.</p>

  <p>It’s <i>just</i> <b>a</b> <em>test</em>, <strong>but</strong> <u>I</u> <del>need</del> <sub>to</sub> <sup>look</sup> <span xml:lang="en">into</span> <a href="#">the</a> problem <br/> thoroughly <img alt="asterism" src="test.jpg"/>.</p>

</body>
</html>

So I think it is working. I had to add a previous_tag to the state , a list of tags to treat as inline tags, and instead of full trimming, trimming on left, or right, or both before condensing depending on previous_tag state and current inline tag status.

See the attached.

I have my fingers crossed that this saves the plugin. But ...

BeckyEbook · 04-16-2026, 02:00 PM

That looks promising!
I’ll be testing version 0.5.0.
It’s definitely worth adding a condition that also catches cases where a file is missing. It might seem like a minor detail, but it took me quite a while

Sample file to demonstrate the error (the test.css file is missing and the plugin throws errors):

Spoiler:

KevinH · 04-16-2026, 02:22 PM

Yes that is from the code to see if it is safe to condense whitespace. It needs to examine all linked in css files, all style tags in head, and all style attributes to make sure that neither the white-space property nor the white-space-collapse property is being used.

Yes the bk.bookpath_to_id(bkpath) will return a garbage id if bkpath does not existand trying to read the contents of a non-existent id will throw an error.

I will add some code to prevent that.

KevinH · 04-16-2026, 02:50 PM

Okay, the above issue with non-existtent css files should be fixed in the attached PrettyPrinter_v051.zip

KevinH · 04-16-2026, 03:35 PM

And for the record, I have updated master to better handle body doublespace vs single space mode in Sigiil's gumbo based Mend and Prettify.

With a current build from master and a few tweaks to the new prettyprint.xml file and your table test case now looks like this:

Code:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html>

<html xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops">
<head>
  <title>test</title>
  <link href="../Styles/style.css" type="text/css" rel="stylesheet"/>
  <style></style>
</head>
<body>
  <h1>Chapter</h1>
  <p>*</p>
  <table>
    <thead>
      <tr>
        <th>sample text</th>
        <th>sample text</th>
        <th>sample text</th>
        <th>sample text</th>
      </tr>
    </thead>
    <tbody>
      <tr style="color: blue;">
        <td>sample text</td>
        <td>sample text</td>
        <td>sample text</td>
        <td>sample text</td>
      </tr>
      <tr>
        <td>sample text</td>
        <td>sample text</td>
        <td style="color:red;">sample text</td>
        <td>sample text</td>
      </tr>
      <tr>
        <td>sample text</td>
        <td class="big">sample text</td>
        <td>sample text</td>
        <td>sample text</td>
      </tr>
    </tbody>
    <tfoot>
      <tr>
        <td colspan="4">sample text</td>
      </tr>
    </tfoot>
  </table>
</body>
</html>

I have attached the prettyprint.xml file in case anyone builds from current master.

BeckyEbook · 04-16-2026, 04:06 PM

v.0.5.1
Insert sample code with pre and run the plugin a few times.

Spoiler:

DNSB · 04-16-2026, 04:35 PM

Tested 0.5.1 and not quite ready for release yet. At this point, I would suggest deep-sixing the PrettyPrinter plugin. It looks as if it is going to take a lot more effort to fix all the issues with it for a minimal return.

If anyone is interested in testing the changes in the built-in PrettyPrinter, install Sigil from this link: Sigil-2.7.6-Windows-x64-Setup.exe and replace the prettyprinter.xml file in C:\Users\<username>\AppData\Local\sigil-ebook\sigil\ with the one in message #42 in this thread.

KevinH · 04-16-2026, 05:40 PM

The indent is fine and the end </pre> must appear on its own line not indented otherwise you change the contents of the pre tag.

So the only real issue is not trimming the previous_text to the pre tag which results in more whitespace, none of which will impact what is displayed in Preview. It is that it is growing with each run. I think that can be easily taken care of.

So just for the record DNSB and BeckyEbook what other issues are you seeing? If there are other things that can not easily be taken care of, then I agree discarding PrettyPrinter is probably for the best.

04-15-2026, 08:52 PM	#31
KevinH Sigil Developer Posts: 9,658 Karma: 6774048 Join Date: Nov 2009 Device: many	Does that happen with the earlier version as well? I am trying to figure out if this was due to my cleanup or a logic bug. In the original xhtml before the prettyprint were there spaces or line ends before or after these inline tags? Given there are no existing pcss rules for inline tags in this code at all, I can not see how the space before or after an i or b tag is not being trimmed away by this code. When dealing with inline tags you can never both trim and condense. Perhaps I will have to create a new pcss property to not trim pre and post text before or after after inline tags? Last edited by KevinH; 04-15-2026 at 09:24 PM.

04-15-2026, 09:46 PM	#32
KevinH Sigil Developer Posts: 9,658 Karma: 6774048 Join Date: Nov 2009 Device: many	Yes, this is a logic bug in that gitee code which never supported condensing anyway. Me adding that it did not help. Using previously trimmed code is never correct for inline tags. I will try to fix it. Last edited by KevinH; 04-15-2026 at 09:50 PM.

04-16-2026, 02:15 AM	#34
BeckyEbook Guru Posts: 979 Karma: 3600000 Join Date: Jan 2017 Location: Poland Device: Various	Ooh… I’ve only just noticed that! I was testing version 0.4.0 and I’d actually missed the fact that I’d already messed up one EPUB (it’s not a huge problem, as I’ve got a copy). But it never would have occurred to me that those tags were being altered. EDIT: All inline tags are touched: Code: <p>It’s <i>just</i> <b>a</b> <em>test</em>, <strong>but</strong> <u>I</u> <del>need</del> <sub>to</sub> <sup>look</sup> <span xml:lang="en">into</span> <a href="#">the</a> problem <br/> thoroughly <img alt="asterism" src="test.jpg"/>.</p> Last edited by BeckyEbook; 04-16-2026 at 02:21 AM.

04-16-2026, 11:25 AM	#36
KevinH Sigil Developer Posts: 9,658 Karma: 6774048 Join Date: Nov 2009 Device: many	I am not sure this design can be saved. The problem is all you know is the previousText and the upcoming tag. But if you think about it: Code: <p> It’s <i>just</i> <b>a</b> this is the end. </p> The above can be split into many text pieces and each text piece may need to be handled in a different way. The first piece is from the start p tag to the first i tag. It should be trimmed on the left (not the right) and then condensed. The second piece is between the i and the end i and it must not be trimmed at all and only can be condensed. The third piece is from the end-i to the start b tag, and it must only be condensed never trimmed. The fourth piece is from the b start tag to the b end tag, and again it must only be condensed and never trimmed. Finally the fifth piece is from the end b tag until the end p tag and this piece of text must be right trimmed and condensed. --------- So you can see keeping only the previous text and current tag is not enough state information to understand how to properly handle the previous text. This is why the recursive build up your own contents approach taken by our Prettify works as it keeps full state information. Interesting design but much more state info is needed to properly work. Also a full list of tags that are considered inline must be added. So I am not sure if this PrettyPrinter is worth saving at all. Last edited by KevinH; 04-16-2026 at 11:45 AM.

04-16-2026, 02:00 PM	#39
BeckyEbook Guru Posts: 979 Karma: 3600000 Join Date: Jan 2017 Location: Poland Device: Various	That looks promising! I’ll be testing version 0.5.0. It’s definitely worth adding a condition that also catches cases where a file is missing. It might seem like a minor detail, but it took me quite a while Sample file to demonstrate the error (the test.css file is missing and the plugin throws errors): Spoiler: Code: <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE html> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops"> <head> <title></title> <link href="../Styles/test.css" type="text/css" rel="stylesheet"/> </head> <body> <p>*</p> </body> </html>

04-16-2026, 01:32 AM	#33
DNSB Bibliophagist Posts: 51,748 Karma: 180002898 Join Date: Jul 2010 Location: Vancouver Device: Kobo Sage, Libra Colour, Lenovo M8 FHD, Paperwhite 4, Tolino epos	Guess my response that it happened with v 0.3.0 is no longer needed.

04-16-2026, 08:59 AM	#35
KevinH Sigil Developer Posts: 9,658 Karma: 6774048 Join Date: Nov 2009 Device: many	Yes and unfortunately, the original code has no pseudo css properties to not tell it to trim and no way to differentiate left trimming from right. All are needed when dealing with inline tags. So it's design, while nice, is quite incomplete. I will try to save it but ...

04-16-2026, 12:07 PM	#37
BeckyEbook Guru Posts: 979 Karma: 3600000 Join Date: Jan 2017 Location: Poland Device: Various	Unfortunately, that’s exactly how it looks The Prettifier in Sigil-modified had a fundamental flaw, so you’ll still need to keep adding tags and handling edge cases in the plugin. It’s rather discouraging. It’s a real shame that I focused on the positives in the test files and didn’t take a look at more complex text layouts. Interestingly enough – I actually saw a few isolated cases, but – horror of horrors! – I thought it was just a poorly formatted e-book

04-16-2026, 02:22 PM	#40
KevinH Sigil Developer Posts: 9,658 Karma: 6774048 Join Date: Nov 2009 Device: many	Yes that is from the code to see if it is safe to condense whitespace. It needs to examine all linked in css files, all style tags in head, and all style attributes to make sure that neither the white-space property nor the white-space-collapse property is being used. Yes the bk.bookpath_to_id(bkpath) will return a garbage id if bkpath does not existand trying to read the contents of a non-existent id will throw an error. I will add some code to prevent that. Last edited by KevinH; 04-16-2026 at 02:31 PM.

04-16-2026, 04:06 PM	#43
BeckyEbook Guru Posts: 979 Karma: 3600000 Join Date: Jan 2017 Location: Poland Device: Various	v.0.5.1 Insert sample code with pre and run the plugin a few times. Spoiler: Code: <pre>function helloEpub() { console.log("Hello World!"); } </pre>

04-16-2026, 04:35 PM	#44
DNSB Bibliophagist Posts: 51,748 Karma: 180002898 Join Date: Jul 2010 Location: Vancouver Device: Kobo Sage, Libra Colour, Lenovo M8 FHD, Paperwhite 4, Tolino epos	Tested 0.5.1 and not quite ready for release yet. At this point, I would suggest deep-sixing the PrettyPrinter plugin. It looks as if it is going to take a lot more effort to fix all the issues with it for a minimal return. If anyone is interested in testing the changes in the built-in PrettyPrinter, install Sigil from this link: Sigil-2.7.6-Windows-x64-Setup.exe and replace the prettyprinter.xml file in C:\Users\<username>\AppData\Local\sigil-ebook\sigil\ with the one in message #42 in this thread. Last edited by DNSB; 04-16-2026 at 04:45 PM. Reason: Added new build of Sigil

04-16-2026, 05:40 PM	#45
KevinH Sigil Developer Posts: 9,658 Karma: 6774048 Join Date: Nov 2009 Device: many	The indent is fine and the end </pre> must appear on its own line not indented otherwise you change the contents of the pre tag. So the only real issue is not trimming the previous_text to the pre tag which results in more whitespace, none of which will impact what is displayed in Preview. It is that it is growing with each run. I think that can be easily taken care of. So just for the record DNSB and BeckyEbook what other issues are you seeing? If there are other things that can not easily be taken care of, then I agree discarding PrettyPrinter is probably for the best.

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Assess if a pdf file is editable	RotAnal	Plugins	3	06-06-2018 06:54 PM
Where to put userStyle.css?	GeoffR	Kobo Reader	15	04-06-2013 04:57 PM
User-Editable HTML in Templates?	marcot	Calibre	0	06-15-2010 09:19 AM