Sigil 0.4.0 betas

[Pablo]

Originally Posted by theducks

1 an 2 says there is a href with a call to a file 4.html somewhere(s) in your book.
add the file or remove the call

First of all, thanks for your answer!!!

My original html file is called "4.html". When I open it with Sigil, I see "4.html" as the only text file (normal behaviour). I think it should have been included in the opf automatically.

When I save as ePub, close and reopen the ePub, "4.html" has dissapeared from the text folder. This is repetitive, so I think there's something wrong with 0.4.0RC1.

And there's no href anywhere in my document.

Regards,
Pablo

[st_albert]

I am seeing similar FC errors with Sigil 0.4-RC1 when I create new files by splitting one large file into several chapters. In my case, all the files are physically present in the epub archive, but several are not listed in the manifest or spine sections of the content.opf file. That, and the order of files in the spine is munged up too.

That's what I think FC means when it says something to the effect that "such-and-such.xhtml is reachable but not listed in the <manifest>" etc.

So my guess is that for some reason RC1 is not properly updating the content.opf file.

[Pablo]

Originally Posted by st_albert

I am seeing similar FC errors with Sigil 0.4-RC1 when I create new files by splitting one large file into several chapters.

Yes, I also noted that.

[LGN]

I'm still a bit unsure why someone would want to hand-edit some of the files that normally would be generated. Are there some advantages to hand-editing? I just assumed these files just have to meet the criteria of the ePUB and nothing more so am wondering since the first Beta what one can do with them.

I admit I still haven't tried the Beta's or RC's because I'm making an ePUB but I still wonder where the advantage lies exactly.

[Pablo]

Originally Posted by LGN

I'm still a bit unsure why someone would want to hand-edit some of the files that normally would be generated.

Maybe to fix a non-Sigil generated broken ePub?

[st_albert]

@LGN:
In my case, I'm adding lots of metadata to the content.opf from a file supplied by the publisher as a text file with the properly formatted metadata tags in it. It's far easier to edit content.opf and paste in the tags than to use the pre-0.4 metadata editor in Sigil.

Once the bugs in 0.4 are ironed out, I'll be able to do that within Sigil instead of having to save / unzip / edit / rezip. Should be quite a time saver.

But if you're not making epubs for sale, this may not be of any interest to you.

[crutledge]

When I load an html file with <hr class="sigilChapterBreak" /> in all the desired places and split the file, the bookname.html (which contains the cover) comes out as the last entry in the text part of BB. I can then move this the the head of the text entries. Any other sections out of sequence are also moved.

When I initially press Alt F3 the toc shows up in the correct order with cover as the first item. I press Generrate TOC and the old type display appears and everything is fine except cover is always last. Sigil refuses any attempt I have made to correct this.

The only solution I have found is the copy toc.ncx to my external editor, move the cover record to the first position and then use GREP to re-number the display sequence, and copy this back into the sigil toc.ncx. This works but is very un-elegant.

Combine this with having to edit the OPF for missing entries almost makes me miss BD.

Have I missed something? I would very much like to have a experience.

[st_albert]

Originally Posted by crutledge

When I load an html file with <hr class="sigilChapterBreak" /> in all the desired places and split the file, the bookname.html (which contains the cover) comes out as the last entry in the text part of BB. I can then move this the the head of the text entries. Any other sections out of sequence are also moved.

When I initially press Alt F3 the toc shows up in the correct order with cover as the first item. I press Generrate TOC and the old type display appears and everything is fine except cover is always last. Sigil refuses any attempt I have made to correct this.

The only solution I have found is the copy toc.ncx to my external editor, move the cover record to the first position and then use GREP to re-number the display sequence, and copy this back into the sigil toc.ncx. This works but is very un-elegant.

Combine this with having to edit the OPF for missing entries almost makes me miss BD.

Have I missed something? I would very much like to have a experience.

I think this is related to Issue 863 and Issue 865. When the file is initially loaded into Sigil 0.4RC1, the toc.ncx is built from the unsplit file. Everything should be in order. If you look at the toc.ncx, all the file refs point to the single .xhtml file. After the split, the toc.ncx remains unchanged until you hit the "generate toc" button. Then the toc.ncx is rebuilt, with the garbled chapter order due to the garbled file split order as discussed above.

As an aside, the toc.ncx will have (at least in my experience) references to all of the chapter headers, even though some of the files will not be included in the content.opf <manifest> and/or <spine> sections.

Hence the FC errors like "file is reachable, but not in the manifest" because the toc.ncx does refer to it even though the content.opf doesn't have it.

[christinerose]

Originally Posted by theducks

Yes and No
Those are errors in your document

1 an 2 says there is a href with a call to a file 4.html somewhere(s) in your book. add the file or remove the call

I'm getting the same error message multiple times, for every file in my Book Browser. It says the file is not there, but I'm looking right at them in the Book Browser.

I don't understand.

When you say "add the file" -- where do I add the file? It's already part of my book in my book browser under the folder "Text."

I'm having the same issues with images. Says they're not present and not being used, but they are present and they are being used.

Mac OS X. Just downloaded Sigil last week, so latest version?

[theducks]

OK I think I saw this happen (after a split) also (1 time).
I saved and quit Sigil. Restarted Sigil and FC passed (at least that set of errors )
It is as if FC does not see the 'current' NCX/OPF

[st_albert]

Originally Posted by theducks

OK I think I saw this happen (after a split) also (1 time).
I saved and quit Sigil. Restarted Sigil and FC passed (at least that set of errors )
It is as if FC does not see the 'current' NCX/OPF

After splitting a file, saving, quitting Sigil, restarting it doesn't help for me. The content.opf is incorrect. (missing some entries, others in wrong order.)

I still get the usual errors in FC.

[Toxaris]

Perhaps a bit trivial, but have you hit the 'generate toc' button on the right-bottom after splitting? If you don't do that, files will bound not to be entered in the ncx or opf.

[st_albert]

Originally Posted by Toxaris

Perhaps a bit trivial, but have you hit the 'generate toc' button on the right-bottom after splitting? If you don't do that, files will bound not to be entered in the ncx or opf.

yes, I have. Doesn't help.

[crutledge]

Originally Posted by st_albert

yes, I have. Doesn't help.

I find it necessary to edit the toc.ncx to put the cover at the top of the toc. This also requires the sequence numbers to be redone.

I also have to edit the opf to get all files into the manifest and spline and in the proper order; and the guide into the proper order.

Once you get used to what is screwed up (usually the same things) it becomes simple manual editing.

Much fun.

I can imagine that this is not a simple fix for Valloric.

Hopefully, he will have a moment.

[EowynCarter]

I installed sigil beta on my netbook yesterday (Linux version). This morning i start to netbook to work on a book, and ouch !

First thing I notice, the text file have been re-ordered on alphabetical order. (Not so good).
Oh, whatever, i'll put these in the right order. So I drag and drop the file, sigil moves the file, but in the file list, i see a blank space. Saving the book, closing and re-opening shows everything correct.

I'll try to have a closer look at that when I'm back home.