Sigil-0.8.900 released for testing - Wait for Sigil-0.8.901 - Page 7

v_x · 10-02-2015, 10:00 AM

Quote:

Originally Posted by Doitsu

I've opened and saved your test file with the 0.8.9 Windows and Linux Sigil versions and the spine order hasn't changed. It is therefore rather unlikely, though not impossible, that the OSX version behaves differently, unless there's something strange about your file.

EDIT: If you manually edit the .opf file in Sigil, Sigil will under certain circumstances regenerate the .opf file. Did you by any chance manually edit the .opf file? If so what did you change?

No! I just open normal file and see the alphabet order in the Text folder. Just open. Hope it's bug only in Mac OS X and it's fixable.

KevinH · 10-02-2015, 10:44 AM

Hi,

Its fixable but not just a bug in Mac OS X. Your test case actually has a valid opf. The bug happens when Sigil passes the contents of the file as a full unicode string to sigil_bs4 which doesn't seem to detect that it is full unicode properly because it gets confused by the xml utf-8 header that is at the top of the contents that are passed in.

If I modify the sigil_bs4/builder/_lxml.py to hard code the encoding to full unicode and remove the xml header before we pass it in, the lxml based xml parser all works. Or alternatively, if I encode it the data to utf-8 and keep the xml header, and pass it as bytes, things will work as well.

The sigil_bs4 code seems to take the length of the data passed in BEFORE it converts it to final form (in this case utf-8), and then feeds that to the lxml parser and runs out of full unicode chars before the end of the file (due to the long dc:description which has many utf-8 bytes per char compared to the number of full unicode chars.

So I can fix this, I just need to figure out what is best for xml files that are pased to python as full unicode before they are handed off to code that does the parsing in sigil_bs4/lxml. It would be a shame to convert from full unicode to utf-8 and then back again for no reason.

I will look into the problem and get a fix today some time.

Take care,

KevinH

KevinH · 10-02-2015, 11:18 AM

Hi,

I just pushed the fix for this to master. I have attached the fixed xmlprocessor.py in case anyone wants to play around with it.

After unzipping it, you place it inside Sigil's python3lib to replace its earlier version. this fix is useful to all platforms running Sigil 0.8.900 and it will appear in the next release.

To test this fix, you need to unzip the attached xmlprocessor.py.zip and then add the resulting xmlprocessor.py to Sigil's python3lib folder.

On a Mac, it can be found here:

/Applications/Sigil.app/Contents/python3lib/

If you are not good with command lines then do the following:

1. Open Your Applications folder
2. Right click on Sigil.app and choose "Show Package Contents"
3. Open the Contents folder
4. Open python3lib
5. Copy the new xmlprocessor.py to replace its namesake.

Please give this a try and verify this fix does the job for you.

Thanks,

KevinH

v_x · 10-02-2015, 04:42 PM

Quote:

Originally Posted by KevinH

Hi,

I just pushed the fix for this to master. I have attached the fixed xmlprocessor.py in case anyone wants to play around with it.

After unzipping it, you place it inside Sigil's python3lib to replace its earlier version. this fix is useful to all platforms running Sigil 0.8.900 and it will appear in the next release.

To test this fix, you need to unzip the attached xmlprocessor.py.zip and then add the resulting xmlprocessor.py to Sigil's python3lib folder.

On a Mac, it can be found here:

/Applications/Sigil.app/Contents/python3lib/

If you are not good with command lines then do the following:

1. Open Your Applications folder
2. Right click on Sigil.app and choose "Show Package Contents"
3. Open the Contents folder
4. Open python3lib
5. Copy the new xmlprocessor.py to replace its namesake.

Please give this a try and verify this fix does the job for you.

Thanks,

KevinH

Thank you very much, KevinH! It's work — the bug with alphabet reodering is fixed. Perfectlly.

SuicycoMania · 10-03-2015, 03:11 PM

I have installed Sigil-0.8.900-Windows-x64-Setup.exe on my Windows 7 Ultimate PC.
I have two text files Cover.xhtml and TitlePage.html in an ePub, both are the exact same code with just the name of the .JPG file changed and the file dimensions changed.
But, when I run Tools > Delete Unused Media it tells me that titlepage.jpg can be deleted, so assuming the program thinks it is not in use.
(See attached screen crop showing the exact code being used and the window showing that the file that is in the code can be deleted)
I have tried this one two different ebooks, and I get the SAME result.
Yet, when I run the SanityCheck EPUB, it reports No Problems.
This worked with the previous version I had installed (Sigil-0.8.7-Windows-x64-Setup.exe).

KevinH · 10-03-2015, 03:17 PM

Sanity check just checks for well formed xhtml. It does not check links or anything else. If you want to do that use the now external flightcrew plugin.

Also there is a bug (fixed now in master) that allowed the content.opf to be incomplete. Is your xhtml file that uses that image actually in the content.opf tag? Simply open it and take a look?

What does that report?

KevinH

DiapDealer · 10-03-2015, 03:52 PM

I think the problem is that the "Delete Unused Media" tool shouldn't be reporting that image as unused. I can't seem to duplicate the problem though.

Can you attach a small (uncopyrighted) sample epub that exhibits this behavior?

EDIT: Oops! I'm running a developer build, I'd better try to duplicate it using the 0.8.900 release

KevinH · 10-03-2015, 04:16 PM

If the xhtml file that linked to that jpeg never got put properly in th opf manifest, it would make that image "unused" according to the spine/manifest. I was trying to rule that bug out as it is caused by broken xmlprocessor.py, otherwise its a new bug.

Kevin

DiapDealer · 10-03-2015, 04:51 PM

Quote:

Originally Posted by KevinH

If the xhtml file that linked to that jpeg never got put properly in th opf manifest, it would make that image "unused" according to the spine/manifest. I was trying to rule that bug out as it is caused by broken xmlprocessor.py, otherwise its a new bug.

Kevin

Ah, I see.

I haven't been able to duplicate it yet with either version. Any advice on how to go about getting into an unmanifested image scenario?

KevinH · 10-03-2015, 05:08 PM

Try V_x's test case posted earlier in thi thread.

theducks · 10-03-2015, 05:46 PM

Quote:

Originally Posted by DiapDealer

Ah, I see.

I haven't been able to duplicate it yet with either version. Any advice on how to go about getting into an unmanifested image scenario?

Hand edit the OPF.
It amazes me the number of folk that eschew the use of the tools that make tasks simple (and valid) or try and trick things into their way

WolfBack · 10-03-2015, 05:50 PM

The Sigil 0.8.9 causes me a lot of crashes on Windows 7 x64...
My only solution is to roll back to 0.8.6...
I'm the only person with this problem?

DiapDealer · 10-03-2015, 06:32 PM

Quote:

Originally Posted by WolfBack

The Sigil 0.8.9 causes me a lot of crashes on Windows 7 x64...
My only solution is to roll back to 0.8.6...
I'm the only person with this problem?

No, you're not the only one. If you read the thread, there were several people who were experiencing and reporting crashes in 0.8.900. Most--if not all--of those bugs have been fixed. There's just been no new release with the fixes yet.

WolfBack · 10-03-2015, 07:05 PM

Quote:

Originally Posted by DiapDealer

No, you're not the only one. If you read the thread, there were several people who were experiencing and reporting crashes in 0.8.900. Most--if not all--of those bugs have been fixed. There's just been no new release with the fixes yet.

Thanks for the info, DiapDealer!
The 0.8.6 suite me fine and I'll stay with this until the bugs of 0.8.9 is fixed!

KevinH · 10-03-2015, 07:10 PM

Hi,

If you look at the content.opf tab you will see that the files that contains a link to this jpeg are not listed due to a bug in how the content.opf is parsed. The missing entries in the manifest cause the image file to appear as unused even tough it is in one of the files. I can recreate this exact behaviour with the test case lancelot epub posted earlier in this thread.

With current Sigil Master which has the fixed xmlprocessor.py (this fixed xmlprocessor.py was also posted earlier in this thread), this problem can not be recreated any longer.

Thank for your bug report. This is a known bug with a known fix. A Sigil 0.8.901 with all of these bug fixes should be released soon after we run some more robustness tests on it (assuming there are no other outstanding bug reports).

Thanks,

KevinH

Quote:

Originally Posted by SuicycoMania

I have installed Sigil-0.8.900-Windows-x64-Setup.exe on my Windows 7 Ultimate PC.
I have two text files Cover.xhtml and TitlePage.html in an ePub, both are the exact same code with just the name of the .JPG file changed and the file dimensions changed.
But, when I run Tools > Delete Unused Media it tells me that titlepage.jpg can be deleted, so assuming the program thinks it is not in use.
(See attached screen crop showing the exact code being used and the window showing that the file that is in the code can be deleted)
I have tried this one two different ebooks, and I get the SAME result.
Yet, when I run the SanityCheck EPUB, it reports No Problems.
This worked with the previous version I had installed (Sigil-0.8.7-Windows-x64-Setup.exe).

10-03-2015, 03:11 PM	#95
SuicycoMania Junior Member Posts: 3 Karma: 10 Join Date: Apr 2015 Location: Ontario, Canada Device: iPad	"Tools > Delete Unused Media Files" Not Working Properly? I have installed Sigil-0.8.900-Windows-x64-Setup.exe on my Windows 7 Ultimate PC. I have two text files Cover.xhtml and TitlePage.html in an ePub, both are the exact same code with just the name of the .JPG file changed and the file dimensions changed. But, when I run Tools > Delete Unused Media it tells me that titlepage.jpg can be deleted, so assuming the program thinks it is not in use. (See attached screen crop showing the exact code being used and the window showing that the file that is in the code can be deleted) I have tried this one two different ebooks, and I get the SAME result. Yet, when I run the SanityCheck EPUB, it reports No Problems. This worked with the previous version I had installed (Sigil-0.8.7-Windows-x64-Setup.exe). Attached Thumbnails

10-03-2015, 03:17 PM	#96
KevinH Sigil Developer Posts: 8,789 Karma: 6000000 Join Date: Nov 2009 Device: many	Sanity check just checks for well formed xhtml. It does not check links or anything else. If you want to do that use the now external flightcrew plugin. Also there is a bug (fixed now in master) that allowed the content.opf to be incomplete. Is your xhtml file that uses that image actually in the content.opf tag? Simply open it and take a look? What does that report? KevinH Last edited by KevinH; 10-03-2015 at 03:41 PM.

10-03-2015, 03:52 PM	#97
DiapDealer Grand Sorcerer Posts: 28,587 Karma: 204624552 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	I think the problem is that the "Delete Unused Media" tool shouldn't be reporting that image as unused. I can't seem to duplicate the problem though. Can you attach a small (uncopyrighted) sample epub that exhibits this behavior? EDIT: Oops! I'm running a developer build, I'd better try to duplicate it using the 0.8.900 release Last edited by DiapDealer; 10-03-2015 at 03:54 PM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
New Plugin Features in the upcoming Sigil 0.8.900	KevinH	Plugins	6	09-14-2015 02:48 PM
Sigil 0.8.0 Released	user_none	Sigil	126	10-11-2014 07:52 PM
Sigil 0.7.1 Released	user_none	Sigil	64	03-26-2013 10:02 PM
Sigil 0.4.2 Released	user_none	Sigil	41	10-26-2011 06:03 AM
Sigil 0.4.1 Released	user_none	Sigil	50	09-01-2011 04:58 PM

10-02-2015, 10:44 AM	#92
KevinH Sigil Developer Posts: 8,789 Karma: 6000000 Join Date: Nov 2009 Device: many	Hi, Its fixable but not just a bug in Mac OS X. Your test case actually has a valid opf. The bug happens when Sigil passes the contents of the file as a full unicode string to sigil_bs4 which doesn't seem to detect that it is full unicode properly because it gets confused by the xml utf-8 header that is at the top of the contents that are passed in. If I modify the sigil_bs4/builder/_lxml.py to hard code the encoding to full unicode and remove the xml header before we pass it in, the lxml based xml parser all works. Or alternatively, if I encode it the data to utf-8 and keep the xml header, and pass it as bytes, things will work as well. The sigil_bs4 code seems to take the length of the data passed in BEFORE it converts it to final form (in this case utf-8), and then feeds that to the lxml parser and runs out of full unicode chars before the end of the file (due to the long dc:description which has many utf-8 bytes per char compared to the number of full unicode chars. So I can fix this, I just need to figure out what is best for xml files that are pased to python as full unicode before they are handed off to code that does the parsing in sigil_bs4/lxml. It would be a shame to convert from full unicode to utf-8 and then back again for no reason. I will look into the problem and get a fix today some time. Take care, KevinH

10-03-2015, 04:16 PM	#98
KevinH Sigil Developer Posts: 8,789 Karma: 6000000 Join Date: Nov 2009 Device: many	If the xhtml file that linked to that jpeg never got put properly in th opf manifest, it would make that image "unused" according to the spine/manifest. I was trying to rule that bug out as it is caused by broken xmlprocessor.py, otherwise its a new bug. Kevin

10-03-2015, 05:08 PM	#100
KevinH Sigil Developer Posts: 8,789 Karma: 6000000 Join Date: Nov 2009 Device: many	Try V_x's test case posted earlier in thi thread.

10-03-2015, 05:50 PM	#102
WolfBack Zealot Posts: 122 Karma: 130628 Join Date: Aug 2015 Location: Athens, Greece Device: Kobo Aura 6'', Kobo Aura H2O, Kobo Glo HD	The Sigil 0.8.9 causes me a lot of crashes on Windows 7 x64... My only solution is to roll back to 0.8.6... I'm the only person with this problem?

Advert

Advert