Unable to Insert or Split Pages

[ChrisI]

I am working with an epub 2 document, and if I attempt to split any page at cursor, or even just insert a new blank page, Sigil crashes.

I was using 0.9.7, and upgraded to 0.9.9. No change.

I can do this successfully with other documents, but not this one, so I suspect there is a problem with the file.

However, Flight Crew says the epub is valid. Any ideas as to what else I can look for?

[KevinH]

What platform? Any message that comes with the crash? Sigil 0.9.9 actually has a bug fix to prevent just this bug that was fixed in 0.9.8 so stick with 0.9.9. Some new Windows boxes have the tmp directory default to be automatically emptied and this can cause lots of crashes as Sigil makes heavy use of tmp files.

If it is legal to post the problem epub2, please post it so that authors can try to recreate the issue.

[KevinH]

Also after upgrading to the newest version please use the Sigil About menu to verify the exact version being run.

Another thing to try is saving and renaming your sigil.ini file and let it be recreated to rule out a corrupted settings file.

[ChrisI]

Platform: Windows 7 64-bit.

Sigil About Menu: Version 0.9.9, Loaded Qt 5.6.2

Problem Details:

Problem signature:
Problem Event Name: APPCRASH
Application Name: Sigil.exe
Application Version: 0.9.9.0
Application Timestamp: 5a3c2e1c
Fault Module Name: Sigil.exe
Fault Module Version: 0.9.9.0
Fault Module Timestamp: 5a3c2e1c
Exception Code: c0000005
Exception Offset: 0000000000035e0c
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 1033
Additional Information 1: d518
Additional Information 2: d518e985c1e133e63c126fef71c422cd
Additional Information 3: 3b92
Additional Information 4: 3b928edad88f859fd7b40b3346f09b10


The book is copyrighted, but distributed without DRM. So is it legal to post it for debugging purposes?

[ChrisI]

I removed the Sigil.ini and let the system create a new one. No difference.

[DiapDealer]

Originally Posted by ChrisI

The book is copyrighted, but distributed without DRM. So is it legal to post it for debugging purposes?

No. Without explicit permission of the rights-holder, copyrighted works cannot be uploaded to Mobileread--regardless of its DRM status. What's the title? I'm usually willing to purchase a copy if it's not too terribly high-priced.

[ChrisI]

There are four books, as part of the same series, that I just purchased. All of them exhibit the problem.

Looking at the books, what they all have in common is the first file is named "cover.xml"

I renamed this file to be "cover.xhtml" and that solved the problem.

[DiapDealer]

I can recreate the problem. You're not attempting to split the .xml file, right? Because that should fail with a warning. It seems to only crash when a .xml file is the first file in the Book Browser treeview when splitting.

Thanks. We'll see if we can track it down. In the meantime, the workaround is to rename the .xml file (or temporarily drag it from the first position in the Book Browser treeview).

[ChrisI]

You are correct, I am not attempting to split the xml file.

The error happens if you try to split any file.

The error also happens if you try to "Add Blank HTML File", from the context menu on the Text folder.

Thanks for replying so quickly. It is no problem to rename the file, so the fix is not urgent.

[KevinH]

Wow, that is a strange one. I will try to recreate it on my Mac as well and try to get a backtrace from the crash. Thanks for finding and reporting this bug!

[DiapDealer]

This affects Linux, as well. It crashes any time a Split at Cursor, or Add Blank HTML file is performed when a file with a .xml extension is the first file in the Book Browser's Text container.

Split at Markers gives the "Cannot split since at least one file may not be an HTML file" warning. Which seems a little odd when the .xml file isn't one that's marked for splitting. But it's preferable to a crash.

[KevinH]

Okay I added s new html file and then changed its name to .xml and and moved it to the top.

Then tried to create a new empty html file and it barfed with this backtrace:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   com.sigil-ebook.Sigil.app     	0x000000010fbf3484 Resource::GetEpubVersion() const + 4
1   com.sigil-ebook.Sigil.app     	0x000000010fba0b4c Book::CreateEmptyHTMLFile(HTMLResource*) + 44
2   com.sigil-ebook.Sigil.app     	0x000000010fed9072 BookBrowser::AddNewHTML() + 98
3   org.qt-project.QtCore         	0x000000011398bb4c QMetaObject::activate(QObject*, int, int, void**) + 3020
...

And the routine in question: CreateEmptyHTMLFile calls CreateNewHTMLFile almost immediately ...

HTMLResource *Book::CreateNewHTMLFile()
{
    TempFolder tempfolder;
    QString fullfilepath = tempfolder.GetPath() + "/" + GetFirstUniqueSectionName();
    Utility::WriteUnicodeTextFile(PLACEHOLDER_TEXT, fullfilepath);
    HTMLResource *html_resource = qobject_cast<HTMLResource *>(m_Mainfolder->AddContentFileToFolder(fullfilepath));
    SetModified(true);
    return html_resource;
}

The call to GetFirstUniqueSectionName actually defaults to use the same extension of the first file in the list (in this case a .xml file not an xhtml or html file).

The problem is then that raw xml files when added to FolderKeeper are not recognized as an html resource and instead is recognized as a misc xml resource since there is no mimetype passed along.

QString Book::GetFirstUniqueSectionName(QString extension)
{
    // If not files just return the default first name
    QList<HTMLResource *> html_resources = m_Mainfolder->GetResourceTypeList<HTMLResource>(true);

    if (html_resources.count() < 1) {
        return FIRST_SECTION_NAME;
    }

    // Get the extension of the current file
    QString first_html_file = html_resources.first()->Filename();
    QString first_html_filename = first_html_file.left(first_html_file.lastIndexOf("."));

    if (extension.isEmpty()) {
        extension = first_html_file.right(first_html_file.length() - first_html_file.lastIndexOf("."));

        // If no extension use the default first name extension
        if (extension.isEmpty()) {
            extension = FIRST_SECTION_NAME;
            extension = extension.right(extension.length() - extension.lastIndexOf("."));
        }
    }

    QString filename = FIRST_SECTION_PREFIX + extension;
    return m_Mainfolder->GetUniqueFilenameVersion(filename);
}

And then AddContentToFodler creates an miscellaneous XML resource object and that can not be cast to an HTMLResource *.

So we need to do a number of things in Book.cpp and FolderKeeper.cpp:

1. Teach it to treat files with pure xml extensions to default to xhtml files unless a specific mimetype is passed in that would indicate some other xml file.

2. When creating new html resources/files, we should pass in the correct mimetype so that AddContentToFolder in FolderKeeper actually knows we want a xhtml file regardless of the extension.

This may happen in a lot of places in the code base where empty xhtml files are created (such as the nav, toc.xhtml, etc) so we should search the code to handle that case and not rely on the file extension since it can be flakey.

I am away from my computer almost all day today, so I will try to fix this tomrrow evening in master. I think the same problem happens when splitting files because they start with a new blank xhtml file also.

[ChrisI]

I'm curious...

Are there advantages to using different file types in an epub?

Why not, for example, just make every file .xhtml?

Perhaps there needs to be a system option for the user to select the file type for newly created files. In the case of split file, I would assume that the new file would be the same type as the file being split.

[KevinH]

No in fact using different file types/extensions for text in the same epub is a huge pain in the ass. The epub3 standard recommends using only one: .xhtml. For epub2 you see both .xhtml and .html but the .html is a misnomer since proper xhtml is required.

Another problem is xhtml is xml but xml need not be xhtml. Any ebook author that tries to write chapters with mixed extensions is really just asking for trouble, imho.

I had never seen a book with a cover.xml followed by lots of .html or .xhtml files before. We can handle it but it really is not a good design approach for any ebook author.

[KevinH]

This is now fixed with the latest commit to Sigil master.
Thank you for your bug report which helped make Sigil better!

KevinH