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

[KevinH]

Hi All,
Just pushed fixes for a number of issues reported here and elsewhere:

- TOC segfaults,
- Missing TOC headers when text nested inside spans (or any other tags)
- A fix for our Windows stability issue (Thank the stars!)
- A fix for self-closing iframe tags in the body making gumbo stumble

With the earlier crash fixes and hang on adding cover fixes, I think I am up to date on reported bugs.

So if anyone is building their own please pull once again from Master and rebuild and please let DiapDealer and I know if you run into any other nastiness.

Thanks,

KevinH

[Doitsu]

Originally Posted by KevinH

- TOC segfaults,
- Missing TOC headers when text nested inside spans (or any other tags)
- A fix for self-closing iframe tags in the body making gumbo stumble

The above bugs have been fixed; at least they no longer occur in Linux builds based on the latest github files.

[DiapDealer]

Anyone who hasn't already, might want to take notice that Flightcrew (which is no longer an integral feature of Sigil) is available as a plugin (from the releases page). There is a separate plugin for each platform.

FlightCrew_v0.9.0(osx|unx|win).zip.

[Notjohn]

Any trick to installing plug-ins? (I've done it in Calibre; never in Sigil.) I love Flight Crew!

[Doitsu]

Originally Posted by Notjohn

Any trick to installing plug-ins? (I've done it in Calibre; never in Sigil.) I love Flight Crew!

It's all pretty straightforward.

1. Download FlightCrew if you have a Windows PC. Otherwise select the OSX version.
2. Select Plugins > Manage Plugins
3. Click the Auto button after Python 3.4
4. Click Add Plugin, select the plugin zip file and click OK.
5. Select Plugins > Validation > FlightCrew.

Since the first Sigil 0.8.9 Windows build has some bugs, you may want to postpone your Sigil 0.8.9 update until KevinH has uploaded a new Windows version.

[eschwartz]

Or hopefully a versioned minor release.
Bad habit to make releases not match source code.

[DiapDealer]

Originally Posted by eschwartz

Or hopefully a versioned minor release.
Bad habit to make releases not match source code.

Well the (pre)release version DID match the source code at the time it was tagged/released. And of course the next versioned minor pre-release will match the source-code when it's tagged. I'm not sure I'm following you. We've had one pre-release so far (0.8.900). Bugs were discovered and fixed. We are now preparing for a second versioned pre-release. In the meantime, there are a few Linux users who are now building from the development source to take advantage of those bugfixes (as is their perogative). Windows and Mac users are of course free to do the same.

Doitsu's advice was basically, "there are some bugs in the first pre-release. You may want to wait until the next pre-release version." There are no "bad habits" in play here. There's been no release that doesn't match the source code. Nor will there be. Surely you didn't think we were going to upload an updated windows binary to an pre-existing release?

[eschwartz]

Sorry, awkward wording did indeed make me think that for a second Happened a couple times for calibre, which didn't thrill me.

I shouldn't have made that association.

[DiapDealer]

No prob. I was fairly certain we were doing it "right." But you never know.

[v_x]

Originally Posted by KevinH

Hi v_x,



I am running the same build on the same Mac OS X and not seeing this at all.

The only reason it would rename the files on load would be if the same file names (ignoring directories) exist inside the epub. So please pm me here a link to the exact book that causes this issue for you.

Alternatively, you can simply do the following on your Mac

1. copy the offending epub to your Desktop and rename it test.epub

2. Open Terminal.app and enter these commands in the resulting terminal and post the results here

cd ~/Desktop
unzip -t test.epub


That will tell me if the offending book has duplicate file names someplace.

Thanks,

KevinH

Yes, please, link to the epub:
https://www.dropbox.com/s/czi2imsp4g...elot.epub?dl=0
But this bug repeats in any files. I tested dozen epubs and the same result ;(

[Doitsu]

Originally Posted by v_x

Yes, please, link to the epub:
https://www.dropbox.com/s/czi2imsp4g...elot.epub?dl=0
But this bug repeats in any files. I tested dozen epubs and the same result ;(

@v_x: I've had a look at your file and I believe that you most likely misinterpret the display of your OSX archiving software, because Sigil won't rearrange files in the spine unless you tell it to. Sigil will normalize the input files and put them in dedicated folders, but that's all.
If you manipulate epubs outside of Sigl and rezip the epub file, some archive managers might actually display the files in the order in which they were physically added to a zip file. However, most apps will sort the files by file name (see screen capture).
If you resave an epub file, Sigil might save the files in a different order in the zip file, however, none of this matters for epub files. The only requirements is that the mimetype file needs to be added first to the archive.

1. How exactly did you create the epub before you opened it for the first time with Sigil?
2. What kind of archive manager do you use?

[Notjohn]

Originally Posted by Doitsu

It's all pretty straightforward.

Thanks. I've printed out your List, against the day.

[v_x]

Originally Posted by Doitsu

@v_x: I've had a look at your file and I believe that you most likely misinterpret the display of your OSX archiving software, because Sigil won't rearrange files in the spine unless you tell it to. Sigil will normalize the input files and put them in dedicated folders, but that's all.
If you manipulate epubs outside of Sigl and rezip the epub file, some archive managers might actually display the files in the order in which they were physically added to a zip file. However, most apps will sort the files by file name (see screen capture).
If you resave an epub file, Sigil might save the files in a different order in the zip file, however, none of this matters for epub files. The only requirements is that the mimetype file needs to be added first to the archive.

1. How exactly did you create the epub before you opened it for the first time with Sigil?
2. What kind of archive manager do you use?

Dear Doitsu,
file was created year ago in previous versions of Sigil. I did not use any archive apps. The right order in file in screenshot (from Sigil 0.8.7) https://www.dropbox.com/s/ee3dzfyj3i...04.12.jpg?dl=0
or in content.opf file:
<spine toc="id6">
<itemref idref="main.xhtml" />
<itemref idref="epi.xhtml" />
<itemref idref="lanc1.xhtml" />
<itemref idref="schm.xhtml" />
<itemref idref="fund.xhtml" />
<itemref idref="mikh.xhtml" />
<itemref idref="mikh-notes.xhtml" />
<itemref idref="zab.xhtml" />
<itemref idref="zab-notes.xhtml" />
<itemref idref="notes-lanc.xhtml" />
<itemref idref="about.xhtml" />
</spine>

[Doitsu]

Originally Posted by v_x

The right order in [the] content.opf file:

<spine toc="id6">
    <itemref idref="main.xhtml" />
    <itemref idref="epi.xhtml" />
    <itemref idref="lanc1.xhtml" />
    <itemref idref="schm.xhtml" />
    <itemref idref="fund.xhtml" />
    <itemref idref="mikh.xhtml" />
    <itemref idref="mikh-notes.xhtml" />
    <itemref idref="zab.xhtml" />
    <itemref idref="zab-notes.xhtml" />
    <itemref idref="notes-lanc.xhtml" />
    <itemref idref="about.xhtml" />
</spine>

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?

[DiapDealer]

Doitsu has a point. Sigil will recreate an opf that it deems to be broken. The spine will likely be alphabetized in that situation. There will be a comment in the opf file indicating that is what happened, though.