MobileRead Forums - New Sigil Release: Sigil-0.8.901

Page 3 of 10

Last »

Show 40 post(s) from this thread on one page

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

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

- - New Sigil Release: Sigil-0.8.901 (https://www.mobileread.com/forums/showthread.php?t=266008)

KevinH

10-06-2015 08:22 PM

Hi,

As far as I can tell, gumbo will happily parse all types of doctypes and return then to their original condition including html5 doctypes !DOCTYPE html.

If you find a case where it does not do that, please report it and I will try to track down where things are getting messed up.

Take care,

Kevin

Quote:

Originally Posted by pete6055 (Post 3183538)

Hello:

Very nice release guys!

I do, however, have a question:
Will the next non-beta release rewrite the tags:

at the top of html documents? Sigil 8.6 did so, depending on how clean source was set, but the new gumbo-parcer and gumbo-pretty print seem to handle this differently.

I sometimes start with html from the web, and the initial declaration is sometimes different, so short of copying the snippet to before the <body> tag, is there a more efficient way (perhaps a plugin)?

Thanks….

eggheadbooks1

10-06-2015 11:22 PM

I installed this latest version today and the ePub I made it in will not display properly in any of my ePub testing apps (ADE, Aldiko), nor my Kobo; it's as if the CSS cannot be read. Yet it displays properly in Sigil, and I can convert the file to Kindle using Kindlegen and the ebook displays as coded.

All my ePubs built using earlier versions display properly in my ePub apps. I have compared the header code and Content.opf code between the old ebooks and this new one and cannot find anything amiss.

Any ideas?

eggheadbooks1

10-06-2015 11:37 PM

Quote:

Originally Posted by eggheadbooks1 (Post 3183636)

Well isn't this the way ... no sooner do I post this message than I found the problem. Odd that Kindlegen converted properly...

theducks

10-06-2015 11:38 PM

Quote:

Originally Posted by eggheadbooks1 (Post 3183636)

Check the CSS for Errors (ADE will barf on the tiniest malformed rule that others deal with)
Right-click on the CSS in the Book browser: Validate with W3C (the red ones)

DiapDealer

10-07-2015 12:00 AM

Yep. Looks fine using WebKit, but not with ADE/RMSDK = CSS syntax error. Nine times out of ten. The tenth time = an embedded font that's incompatible with ADE/RMSDK. ;)

eggheadbooks1

10-07-2015 01:08 AM

Quote:

Originally Posted by theducks (Post 3183648)

Check the CSS for Errors (ADE will barf on the tiniest malformed rule that others deal with)
Right-click on the CSS in the Book browser: Validate with W3C (the red ones)

I did find it earlier, but the CSS was indeed the problem. A missing closing bracket. (I had added a new style by copying and pasting and missed the closing bracket.) I was too busy checking all the other code, trying to find the problem, that I missed the typo in the CSS.

Thanks for the tip to validate with W3C. Will try that next time I run into a problem.

eschwartz

10-07-2015 01:55 AM

Quote:

Originally Posted by KevinH (Post 3183494)

Hi,
The change you want makes no sense as it removes whitespace that may in fact be part of the paragraph both before and after the exact text (up to one character of each.

Now it doesn't work, I tried it with the two Cleaning types (at Windows machine).

Yes, pretty print has changed a lot, It will no longer trim whitespace from inside of paragraph tags as it should not since whitespace can be important both before and after any text (at least up to one character's worth).

And how would you expect this to turn out? Is there at least one char of white space after the footnote marker and before the "Some text." and after the text?

I am not sure either of these are bugs. You seem to be asking for the old Tidy approach of a deep clean. I am sorry but those days are pretty much gone. If you want me to modify prettyprint to reduce multiple spaces into one space inside of the p tag, that may be doable, but stripping it all away is simply incorrect.

KevinH

Also spaces from the beginning or end of the paragraph. ;)

FWIW, calibre preserves whitespace entirely, on the rationale that when using <pre>, whitespace matters.
IIRC, only whitespace outside a block-level tag gets reformatted when pretty-printing.

Sigil may or may not wish to follow the same approach. :)

...

Seems like an unwise (and unlikely) thing to use, IMHO, but I'd hate to be responsible for Sigil breaking a book because of this. :D

KevinH

10-07-2015 12:22 PM

Hi eschwartz,

Yes, I agree. That is why we moved away from Tidy (it cleaned too much and did not fully support all html5 tags, svg tags, and math tags). Regular gumbo serialization, changes no whitespace whatsoever. gumbo prettyprinting will now condense multiple whitespace on any allowed tag (and that is quite a specific list to prevent problems) and will trim leading and trailing whitespace from inside p tags only. All other places, people will just have to live with it or edit it by hand.

I am thinking of creating a "Clean-and-Sanitize" plugin using the html5lib's parser and sanitize code and a few things like that just to give people the option of "heavy cleaning" if they end up starting with heaping piles of crap html code (ie. read that they have unpacked an entire mobi7 book to one huge html file with lots of out of date html 3.2 pieces flying around.

Thanks!

KevinH

DiapDealer

10-07-2015 12:48 PM

I'm think that in the future (not immediate mind you ;) ), we may want to add a new pretty-print plugin type. One that can be used in the"traditional" PluginRunner dialog setting (for debugging purposes), but can also be "assigned" via the clean source settings using a combobox populated with installed pretty-print plugins.

I've been mulling the idea around in my head for a bit. And it'll probably mull a little longer. The bottom line is: Sigil's not overly concerned with making your code look "pretty" any more. It's more concerned with not breaking anything. We are, however, dedicated to providing a framework that offers users a way to manipulate their code in any way they see fit--through a robust plugin system.

My two cents anyway.

Leonatus

10-07-2015 03:37 PM

Windows 10, 32-bit.
Sigil crashes repeatedly
a) at uploading a cover image (in "Tools"->add cover, not at uploading other Images in the respective Folder of the book browser)),
b) when trying to create TOC via Tools->TOC->create Toc.

No Problem when I add a cover/TOC in a different program and open the epub afterwards in Sigil.

Am I the only concerned Person?

gbm	10-07-2015 03:38 PM

When you release Sigil 0.9.0 are you including "make uninstall" target for Linux users?

Maybe have them use "checkinstall" instead of "make install".

bernie

KevinH

10-07-2015 03:46 PM

Hi Leonatus,

Those are all problems with Sigil 0.8.900 released about two weeks ago, not the just released Sigil 0.8.901 build which was specifically made to fix those issues (and others).
Are you sure you are using Sigil-0.8.901 instead of Sigil-0.900?
Which are you using?

KevinH

Quote:

Originally Posted by Leonatus (Post 3184076)

KevinH

10-07-2015 03:49 PM

Hi bernie,

Are you talking about a cmake target for people building their own or something else?

KevinH

Quote:

Originally Posted by gbm (Post 3184077)

When you release Sigil 0.9.0 are you including "make uninstall" target for Linux users?

Maybe have them use "checkinstall" instead of "make install".

bernie

gbm	10-07-2015 04:02 PM

Quote:

Originally Posted by KevinH (Post 3184082)

Hi bernie,

Are you talking about a cmake target for people building their own or something else?

KevinH

If you are not releasing packages--i.i. deb or yum-- then the answer is yes. What I am interested in is giving people who are causal users an easy uninstall option.

bernie

DiapDealer

10-07-2015 04:05 PM

No, I have no current plans to include a make uninstall target for Linux. Maybe someday, though. As for telling people to use checkinstall; the people who need that sort of functionality already know how to use it. I see no reason to suggest every one needs to do so.

Feel free to submit a patch/pull request to have cmake generate an uninstall target, if you like. If it's mergeable and doesn't break anything else, I'll be happy to include it.

All times are GMT -4. The time now is 08:14 PM.

Page 3 of 10

Last »

Show 40 post(s) from this thread on one page