Sigil-0.9.0 Release
 

Hi All,

Just to let you know that Sigil-0.9.0 is out now. This is a full release (not a beta or pre-release) of the redesigned Sigil. It is hoped this release will provide a long-term, stable and up-to-date version of Sigil while we begin development work on adding additional epub3 support features.

The release notes, list of changes and the binaries themselves can be found here:

https://github.com/Sigil-Ebook/Sigil/releases/tag/0.9.0

Have fun!

KevinH and DiapDelaer

W10 x64

Just installed, First file I opened: :eek: The Book Browser was SORTED by name with no user input
Titlepage and Jacket are now at the END. Thankfully, the other sections were simple-sequential and stayed in order.

BTW I think this (unwanted sorting) was what happened to me with 901, but in that case, the files had various Names and I had :rolleyes:fun :rolleyes: putting things back to rights

BTW I have now removed the tick for gumbo tidy on open and will see if that helps

Please try to attach a sample that can be used to reproduce the problem. I days of old, that would only happen with a broken opf file.

Hi theDucks,

Please try opening a known good epub ike the Sigil User's Manual or some other known good epub and let us know what you see in regards to the BookBrowser. I am not seeing what you are at all. Perhaps that epub or your computer file system is corrupt?

KevinH

BTW Sigil opened with a 'Not Well formed" message

If I dismiss the message:


then run Reformat HTML -Clean source (all HTML files) :thumbsup:

HTH

Hi theDucks,
Which epub? Again, please try with a known good epub, not a broken one. Let us know if the problem is restricted to just that broken epub or is a general problem. Then privately pm a link to KevinH or DiapDelaer with the location of where we can get a copy of the (!!!! non-commercial !!!!) epub that is broken so that we can figure out why.

Thanks,

KevinH

Good books are fine.
This problem seems to be a 'self pub' caused (is appears, it was missing a Doctype entry) issue, annoying, I will contact the Author. Bad input is just Bad.

Thanks for all the work guys!

I was totally amazed at how much quicker it opened up, and the GUI looks ... cleaner ... although I can't point my finger at exactly what it is yet.

I did notice that the disappearing CSS is still present in 9.0....just happened again after using the "Create HTML Table of Contents" tool. I'll go back to adding a space to the CSS file so Sigil treats it as something that needs to be saved.

Thanks again!

Remind me again what the "disappearing css" is? And how to duplicate it? :blink:

Thanks for all the time and effort you have put into this development.

I will download the update and look forward to using it.

IIRC it was that the new CSS file wasn't being tagged properly when being created...if I went in and put a space somewhere in the css file it would tag it as "updated" or somesuch and then it would save the file properly. Otherwise it had a tendency to clear the entire sheet...leaving a blank css file.

let me see if I can find the thread where we talked about it. I think Kevin was the one to find the problem and fixed it for 8.7.


Edit:
Here it is from this thread

I was under the impressions that that bug had been fixed. I never noticed your "it's back" post at the end of that thread, and no one has ever mentioned it happening in the 0.8.9XX series.

I can't reproduce it with the steps we nailed it down with last time, so it must be something else.

Has this been happening for you all along with the pre-releases?

I haven't had time to test the pre-releases. I just installed 9.0 last night. I tried not using my work araound and it happened on the second book.

Hi,
The changes made to fix that disappearing css bug in the Sigil-0.8.X series are correctly in master. So this is a different bug causing the same issue. Please give an exact sequence of steps needed to recreate this with Sigil-0.9.0.

Thanks,

KevinH

Hi,

Tested the sequence of steps from the previous issue (see below), and it confirms that bug has been fixed.

So please see if you can develop a similar sequence of steps that shows the new error. It will not matter what is actually in the stylesheet just that you added an existing stylesheet and link it in, and then doing something that will force all ebook files to be written back to disk.

If you can figure out a similar sequence, post it here and I should be able to use it to track down and fix this new but obviously related bug.

Thanks,

KevinH

Fairly short process:

- Generate Table of Contents
- Save ePub
- Generate HTML Table of Contents
- Edit HTML TOC
- Save ePub
- Check "sgc-toc.css" that was generated from a template when creating HTML TOC.
- SOMETIMES the css is blank, other times it's not.

It will never blank if I edit the css file and add a space somewhere as soon as it's created.

Here is the css template file if you'd like to look, but I doubt that is the issue since it does work sometimes.

Hi,
If it comes from the sgc-toc.css stored as a template in Prefs location, and if I can track down where that file is first loaded in BookBrowser, and your steps will recreate it at least randomly, I should be able to make it do an initial load as well.

Thanks!

KevinH

Hi,

I still can't reproduce it but from examining the code, the same issue we fixed for Adding Existing CSS files, seems to exist when the template css file from Preferences is used in its place.

So our next release will include a fix for this issue (required changes to MainWindow.cpp similar to what we added to BookBrowser).

This is quite a long-standing bug in Sigil since Sigil 0.7 or even Sigil 0.6 I think. Nice to finally track this one down and get it fixed.

Thanks,

KevinH

On Windows can I install 0.9.0 64bit and 0.8.6 32bit on the same machine and have them use the same settings data in %userprofile%/appdata/local/sigil-ebook. I do not want to run both concurrently.

BR

You can, but it's not really recommended. All versions of Sigil (official versions) installed on the same machine (under the same user) will share the same user-settings. There may be no problems at this time, but there's no guarantee that settings in the 0.9.X (and newer) series will remain backward-compatible with older versions of sigil.

Has there been a change in the way <br> is treated within headers?

I've recently upgraded to 0.9 and seen this change upon opening an existing file.

<h2>1<br /> Bla Bla</h2> v0.8.7

<h2>1<br />

Bla Bla</h2>v0.9.0

:thumbsup:

BR

Glad to help! Thanks!!

It's been doing that as far back as I can remember.

Hi,
If you are talking about prettyprint gumbo, then yes Sigil will do that. If you don't want Sigil to prettyprint then change your preferences to use just gumbo.

KevinH

I have v0.9.0 x64 installed on Windows 7 and have noticed a problem with the table of contents. When I 'add existing files' with this header
<h2 class="hdr-2" id="Ch01">Chapter 1:<br />Chapter Title</h2>
it gets added as
<h2 class="hdr-2" id="Ch01">Chapter 1:<br/>

Chapter Title</h2>
This produces a truncated table of contents entry
Chapter 1:
but the correct HTML table of contents entry
Chapter 1: Chapter Title

If I remove the extraneous blank line like so it's like this
<h2 class="hdr-2" id="Ch01">Chapter 1:<br/>
Chapter Title</h2>
both the table of contents entry and the HTML table of contents entry are correct.
Chapter 1: Chapter Title
Chapter 1: Chapter Title

Although it's fairly easy to go and remove the extra blank line this seems almost like a bug to me, but what do I know.

Are you setting your Preferences to clean on Open or Save and if so are you telling it to use PrettyPrint or not? If so, do not use PrettyPrint Gumbo. Use normal Gumbo which makes fewer changes.

Thanks

'Automatically Clean and Format HTML Source Code' has both Open and Save checked.
'When Cleaning, Use This Type' is set to 'Pretty Print Gumbo'.

If 'Google Gumbo-Parser' is selected the extra line isn't added.

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.

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

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

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.

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.

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.

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:
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

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

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.

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.

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