Sigil-0.9.0 Release

[dynabook]

I am seeing something akin to what I saw in Sigil 8.901 w.r.t. spaces being introduced in the text. Using HarryT's version of "Bleak House" look for an italic span or an href. After the </span> or </a> 4 spaces are being introduced at least with PrettyPrint Gumbo.

I can remove the spaces and they come back with a save or switch between Code View and Book View. The spaces render as a single space in Book View. Google Gumbo does not add the spaces back.
--MH

[KevinH]

Please post here a piece of code that is showing an issue with prettyprint.

Also, running with prettprint enabled all of the time, is probably never going to be a good idea. After prettyprinting the code, I recommend that you change preferences back to normal gumbo. In a future update, prettyprint will be pulled into its own plugin to be run only when requested by the user.

KevinH

[JeffJ]

Originally Posted by DiapDealer

I don't think I was paying close-enough attention to what you were saying. Are you saying that Pretty-Print causes ToC titles to be truncated (when using Generate Table of Contents) where Gumbo-Parser does not? I'm not seeing that in my tests with your sample. I do see the newlines being included in the Table of Contents widget and in the NCX (which may or may not be be problematic by itself), but no truncation is happening for me.

If the code is this
<div id="header">
<h2 class="hdr-2" id="Ch01">Chapter 1:<br/>
Chapter Title</h2>
</div>
and the ToC is correct as in the first attachment.

If you then change the cleaning type to Pretty Gumbo and save the file (so the cleaning takes place) the code is modified to this (with the extra line)
<div id="header">
<h2 class="hdr-2" id="Ch01">Chapter 1:<br/>

Chapter Title</h2>
</div>
and the ToC is truncated as in the second attachment.

The Google Gumbo parser doesn't add the extra line.

The thing is that I don't think it really has anything to do with the gumbo parser at all. I think the problem is in whatever is generating the ToC. Please keep in mind that I'm not even close to an expert at html code at all so I might be totally wrong here, but I thought that extra lines were supposed to be ignored.

[DiapDealer]

I see what you're saying now. The text is truncated in the dialog that indicates what "Generate Table of Contents" is going to do. However, if you go ahead with the generation of the ToC, you'll see that no content is actually being truncated in the generated ToC.

The newlines created by pretty-print are, however, being included in the generated ncx (and are being displayed in the Table of contents widget). As I mentioned before, this is probably what needs to be addressed foremost.

Thanks for the report.

[Toxaris]

Guys, I found a bug. If I use tags in my description (metadata), the description is removed upon saving. This was not the case in 0.8.6. I use tags to have multiple paragraphs and things like italic. Calibre interprets that very nicely. I tried it with and without tags. Funny thing, if I make the description this: This <i>is</i> a test, the description becomes a test.

So, tags and their contents are stripped including what is in front of it. I can't imagine that is intentional.

Also, is it new that a modification is placed in the metadata everytime I save? Could that be an option, I find it very annoying.

[KevinH]

Hi Toxaris,

Yes, not much work was done on metadata editing via the gui because the whole gui will have to be reworked for epub3 metadata.

Right now the only way to work around this is to escape any html tags then everything should work. In other words, use the proper xml escape replacements when entering metadata into the gui.

By example, if you enter the following, it should work correctly:

This is <i>is</i> a test

If it doesn't please let me know.

I will try to fix this for the next point release.

FWIW: Until we get a fix for this - a quick and dirty way to escape everything is to paste it into an empty BV and then go and copy out of its associated CV and paste that into the metadata gui.

KevinH

[Toxaris]

Ok, will do that. Lol, now BV comes to use! I never experienced this in the old version though.

[CalibUser]

There appears to be another issue with Sigil 0.9 for plugins that import CSS files. After tidying an ePub file using the plugin at https://www.mobileread.com/forums/sho...d.php?t=264378 a CSS file could be imported under Sigil 0.87 without any issues. Under Sigil 0.9 I find that the same plugin will corrupt the eBook - I get the dialog box that states "The operation you requested cannot be performed because Section0001.xhtml is not a well-formed XML document....". I am using the same ebook to carry out this test with the option "use bundled Python" unchecked.

[DiapDealer]

Going to need a sample epub (non-commercial/non-copyrighted please) and the steps to reproduce the error. There's just not enough info there to troubleshoot what might be happening.

Whatever the issue is, you seem to be saying that you have the exact same epub with the exact same version of the plugin (using the exact same plugin settings/preferences), and using that plugin on the epub in 0.9.0 will cause an error, where 0.8.7 doesn't. Is that right?

Keep in mind that if you have some regex Find & Replace going on in your plugin that relies heavily on code being formatted precisely the way the pretty-print in the Sigil 0.8.X series formatted things, then that regex very well could be broken when applying it to code formatted with the 0.8.9xx and higher Sigil's pretty-print. I'm not saying that's what's going on here, but it's something to keep in mind.

[KevinH]

Please note, the validator for well formed html is now gumbo. Its validation is strict to the html standard, so things link using numeric enties to encode linefeeds, and other strange things, like incomplete doctypes and things like that may be causing an issue. The only real way to get this fixed is a testcase just as DiapDealer requested so we can see what is causing the issue.

ps: I wonder if this is just the case of the pluginrunner trying to validate a new css file as xhtml when it should leave it alone. I will take a peek at the code to see.
edit: Nope, after looking at it, the code in PluginRunner looks correct.

Thanks,

Kevin

[Toxaris]

*nevermind*

[KevinH]

Hi,

Just a head's up, based on the above thread... we have 4 known issues in Sigil-0.9.0:

1. old bug with blank sgc_toc.css from template - already fixed in master

2. metadata gui needs to be properly xml-escaped and unescaped when going between gui and content.opf - workaround exists by using BV and CV to do the xml escape for you

3. prettyprint with br tags inside h1 to h6 tags creates extra blank lines that are unwanted in a TOC - workaround, do not use prettyprint in your clean settings

4. prettyprint with a and span tags nested inside divs (not p tags) with trailing text insert extra whitespace - workaround - do not use prettyprint in your clean settings

To help make things easier for beginners - we plan to change the default clean setting to use just gumbo not prettyprint gumbo on initial install

I will work on bugs 2, 3, and 4 this weekend when I finally have some time and hopefully we can put out a Sigil 0.9.1 bug fix point release soon to get a 100% solid version out there.

So if anyone finds any other issues with Sigil-0.9.0, please let me know if you can before the weekend.

Thanks,

KevinH

[DiapDealer]

I submitted a pull request for a potential fix for number 3 (with comments) this morning -- in case github forgot to notify you -- for your perusal.

[KevinH]

Hi Doug,

Just saw that now (I do not typically get home e-mail while at work but I do occasionally look at it via a web interface). Yes, that should do the trick - please merge your fix in.

Thanks!

KevinH

Originally Posted by DiapDealer

I submitted a pull request for a potential fix for number 3 (with comments) this morning -- in case github forgot to notify you -- for your perusal.

[DNSB]

A minor nit that gets moderately annoying at times.

When I open an epub that has a close to flat file structure which both Flightcrew and epubcheck are happy with reporting no errors, Sigil happily moves the stylesheets to a Styles directory, images to an Images directory, etc. Rather nice, standards compliant, warm fuzzy inducing(?) behaviour. However, Sigil then popups a warning the epub has HTML files that are not well formed, etc... Do you want Sigil to automatically fix the files with possible data loss warning, Yes/No.

I tend to say no since I have had Sigil do some rather nasty items in past when automatically fixing a file—leaving half the HTML files in an ebook empty comes to mind though it was quite a few versions back when I last tried automatic fixing.

Looking at the source of the errors, it appears that Sigil—unfortunately—does not modify the paths in the HTML files to match the file location changes unless you say yes to automatic modification.

In a sample epub file with an OPS directory and an OPS/images subdirectory:

Orignal link to stylesheet:
<link rel="stylesheet" type="text/css" href="style01.css"/>

Orginal link to image:
<p class="pc2"><img src="images/cover.jpg" style="height:100%;max-width:100%" alt="cover.jpg"/></p>

After opening with Sigil, the links remains unchanged and need to be manually edited to:
<link rel="stylesheet" type="text/css" href="../Styles/style.css"/> 

<p class="pc2"><img src="../Images/cover.jpg" style="height:100%;max-width:100%" alt="cover.jpg"/></p>

Is there an option that I have missed to have this done automatically without the popup when file locations are the only changes being made—Sigil is already munging the file structure so why not automagically change the paths when doing so? Preferably with a notification about what's happening.