MobileRead Forums - Sigil-0.9.0 Release

MobileRead Forums (https://www.mobileread.com/forums/index.php)

- Sigil (https://www.mobileread.com/forums/forumdisplay.php?f=203)

- - Sigil-0.9.0 Release (https://www.mobileread.com/forums/showthread.php?t=267232)

Quote:

Originally Posted by KevinH (Post 3204649)

ps: fix now pushed to master
pps: rebuilt and I can confirm this fixes the issue my test platform Mac OSX

Cool. Thanks! Will build/test when I get home later.

Hi Toxaris,

Just pushed a fix for this to github master. The next point release will autohandle encoding and decoding of html stored inside Metadata fields by the gui.

Thanks for your bug report!

Kevin

Quote:

Originally Posted by Toxaris (Post 3203374)

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.

Very nice!
All of the recent changes work as expected in my testing.

Hi DiapDealer,

Glad to hear that it all works.
I think that just leaves a few minor things to fix this weekend then:

1. fix for prettyprint adding whitespace after a and span tags inside div and not p tags
2. default all new sigil installs to clean wih just gumbo, not prettyprint
3. adjust python hunspell ctypes code to prevent missing libhunspell from impacting all plugins
4. create a testplugins.zip plugin for packagers to test with from testme3

Do you know of anything else that needs fixing?

With each heading (e.g. h1) containing <br/>, Sigil-0.9.0 will gererate 2 lines in TOC.
Please check! Thanks.

Yes, if you read the thread, this was already talked about. The two lines will still exist, but the the whitespace will be simplified when the TOC and HTML TOC are generated.

Kevin

Hi, I think I found another bug in Sigil 0.9.0:

The attached ePub file contains two paragraphs of text. The following steps lead to an error:

1. Switch to bookview.
2. Select all the text.
3. Click the bullet button on the Toolbar.
4. Switch to Codeview.
5. Switch back to BookView. An box appears stating that "The operation you requested cannot be performed because Section0001.xhtml is not a well-formed XML document...."

Quote:

Originally Posted by CalibUser (Post 3205898)

5. Switch back to BookView. An box appears stating that "The operation you requested cannot be performed because Section0001.xhtml is not a well-formed XML document...."

Only when you have all clean source options turned off.

Thanks for the report.

Actually,

The gumbo parser is correct here. Although BV and preview will still show it, gumbo detects the error and reports it. So technically the following is illegal code:

Code:

<p>For instance, this fantastic sentence has bullets relating to

<ul>

 <li>wizards,

 <li>faster-than-light travel, and

 <li>telepathy,

</ul>

and is further discussed below.</p>

According to the spec ...

http://www.w3.org/TR/html5/grouping-...#the-p-element

"List elements (in particular, ol and ul elements) cannot be children of p elements."

In an example in that sections says the correct way to best handle this is to rewrite it as follows:

Code:

div>For instance, this fantastic sentence has bullets relating to

<ul>

 <li>wizards,

 <li>faster-than-light travel, and

 <li>telepathy,

</ul>

and is further discussed below.</div>

Personally, I see this as just the general stupidity of trying to edit anything while in BV. BV supports it, BV displays it, but technically is is incorrect html and incorrect in our context. Gumbo properly detects the incorrect html and warns you about it before reloading it into BV. If you let it, gumbo will properly fix the code to make it technically correct.

Not sure how to handle this. It is technically not a bug.

KevinH

I agree RE editing in Book View. But in all fairness, It's the Bullet button in Book View that seems to be generating invalid code (and that button only works in Book View). Sure, allowing gumbo to do its thing will correct it, but then ... why do we have button in Book View that will generate invalid code in the first place?

I'm somewhat confused. Further down in the link you cited is http://www.w3.org/TR/html5/grouping-...the-ul-element

Here it shows

Code:

<p>I have lived in the following countries:</p>

<ul>

 <li>Norway

 <li>Switzerland

 <li>United Kingdom

 <li>United States

</ul>

as a valid example.

Good Point.

All that button does is run a built in QWebpage command called insertUnorderedList and that is the culprit. We can't control it.

KevinH

Quote:

Originally Posted by DiapDealer (Post 3205971)

Quote:

Originally Posted by PeterT (Post 3205983)

I'm somewhat confused. Further down in the link you cited is http://www.w3.org/TR/html5/grouping-...the-ul-element

Here it shows

Code:

<p>I have lived in the following countries:</p>

<ul>

 <li>Norway

 <li>Switzerland

 <li>United Kingdom

 <li>United States

</ul>

as a valid example.

It is valid. The ul element is not a child of the p element. It's a sibling.

Hi PeterT,

The first example I gave has the ul tag as a child of the p tag which is illegal.
See the missing closing p tag before the start of the ul tag in the example I posted.

The reason I used that example is because this is what CalibUser's sequence of steps generates inside of BV when it follow it. It creates a ul child of a p.

Quote:

Originally Posted by PeterT (Post 3205983)

I'm somewhat confused. Further down in the link you cited is http://www.w3.org/TR/html5/grouping-...the-ul-element

Here it shows

Code:

<p>I have lived in the following countries:</p>

<ul>

 <li>Norway

 <li>Switzerland

 <li>United Kingdom

 <li>United States

</ul>

as a valid example.

The above is correct. The closing p tag at the end of the first line prevents the ul tag from being the child of a p tag. The only issue with the above is you can not style it easily as a whole single paragraph, which is why the spec calls for using a div instead to allow that (but it is not required).

Sorry to be confusing. I should have just used CalibUser's example instead of one borrowed from the spec.

To be more specific CalibUser's sequence of events generates the following:

Code:

<?xml version="1.0" encoding="utf-8"?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"><html xmlns="http://www.w3.org/1999/xhtml">

<head>

  <title></title>

</head>

<body>

<p>

<ul>

<li>Takes advantage of the new facilities in Sigil version 0.9.0.0 so that it is no longer necessary to install external libraries eg Beautiful Soup.<br /></li>

<li>Files for processing can be selected in Sigil before the plugin runs; these files are highlighted in the list in the ePubTidy dialog.<br /></li>

</ul>

</p>

</body>

</html>

In other words it makes a ul a child of a p tag.

Hope this is clearer.

KevinH

Quote:

Originally Posted by KevinH (Post 3205986)

Good Point.

All that button does is run a built in QWebpage command called insertUnorderedList and that is the culprit. We can't control it.

KevinH

I see what you mean. I guess the rule of thumb should be, "Don't try this (editing in Book View) without a safety net." And that safety net is gumbo.

Out of curiosity, do we know if Sigil's previous well-formed check just ignored this (since the functionality of the button obviously hasn't changed)?