File problem in 0.4.0

[theducks]

Are you talking about the overall Name of the EPUB or the name of one of the pieces inside (what you see in the book browser window) the the EPUB package?

[adv_dp_fan]

Originally Posted by theducks

Are you talking about the overall Name of the EPUB or the name of one of the pieces inside (what you see in the book browser window) the the EPUB package?

Talking about the xhtml files in the book browser window. Also note that if you save after the split and reload, often the new split xhtml files will have vanished and the contents lost.

[theducks]

Originally Posted by adv_dp_fan

Talking about the xhtml files in the book browser window. Also note that if you save after the split and reload, often the new split xhtml files will have vanished and the contents lost.

Got it.
Had exactly that happen to me (RC1), too.
Salvaged the lost file from a copy on my reader (I use 'Open With' from within Calibre. so the original there was what got hosed.)

@charleski
Do you know when the fixes you did will be released in a new version?

[alansplace]

Originally Posted by adv_dp_fan

Talking about the xhtml files in the book browser window. Also note that if you save after the split and reload, often the new split xhtml files will have vanished and the contents lost.

ah ha! i never get that far. as soon as the problem occurs i close out sigil 4 and work on that book in sigil 3.4 which doesn't have that problem. now that i know what causes the problem, i won't lose anything as i can switch to 3.4 before the problem occurs by visually checking the filenames for spaces.

[charleski]

Originally Posted by theducks

@charleski
Do you know when the fixes you did will be released in a new version?

It's up to John, but it's in the source right now if you want to compile it.

If people had reported the problem on the RC2 test build it would have been caught earlier.

[charleski]

Originally Posted by crutledge

If the file (book) name is to be used as section names, a major problem with final book names is to be solved. The final epub file name will be the book name with underscores. If we go back to the old Section0002, Section0003,, etc. this problem goes away.

When splitting on chapter markers, Sigil now just uses the name of the originating file as the root for the names of the subsequent files. It doesn't have anything to do with the name of the book. It still uses the old Section000x.xhtml names for manual chapter splits as that's what the old code did - renaming the new chapter file to something meaningful is best left to the user in this case.

[theducks]

Originally Posted by charleski

It's up to John, but it's in the source right now if you want to compile it.

If people had reported the problem on the RC2 test build it would have been caught earlier.

I could not identify the steps and provide a guaranteed to fail test file to Valloric. He closed the report.

[Shelleyleo]

Originally Posted by charleski

When splitting on chapter markers, Sigil now just uses the name of the originating file as the root for the names of the subsequent files. It doesn't have anything to do with the name of the book. It still uses the old Section000x.xhtml names for manual chapter splits as that's what the old code did - renaming the new chapter file to something meaningful is best left to the user in this case.

This is actually the very thing I came here to hunt for before filing a "bug" or feature request on the dev site. I make all my ebooks (so far anyway) using one big template html file with each chapter set up with the Sigil chapter break tag in where I have other file format converters doing a page break before a chapter - I like having one html file plus a cover image for each book that I can use to create a fair few other formats of eBook out of. So I go for all kinds of consistency in creating my files.

Until 0.4.0 release (I was using one of the previous 0.4.0 pre-releases - Mar24 windows (x64) build 0.4.0β3) my standard procedure is to
1. import my HTML file of the final book (which pulls in the cover image and the linked style sheet)
2. Rename the html file (which is typically in the format of "auth-last, first - seriesname ### - book title.html") to "Section0001.xhtml"
3. Rename the cover file (same name format as the original HTML file only the extension differs) to "cover.jpg"
4. hit F10 so I'm in split view (for ease of snagging a bit of metadata to drop into the content.opf file), F8 to ensure my html file's metadata that Sigil links actually goes into the content.opf file, and F6/"Split on SGF Chapter Markers"
5. Fix the various new "Section0002.xhtml" and so on to the properly numbered order and generate my TOC after they are in the right order (the version I was using would randomly scramble the files, but they would be named such that if I put them in numerical order they would be in the right order).
6. Copy over my calibre series info from my html file metadata into the content.opf file
7. save and validate the ePub

Now...I rename the starting html file so I can get all my section####.xhtml files in order (since it never started with 0001 even if 0001 didn't exist, I always just named my starting file Section0001.xhtml) and use F6 and I get "Section0001_0002.xhtml" and so on with "_####" added to the Section0001 filename.

The problem here for me is that up until now - ALL my ePubs are consistently named internally as "Section0001.xhtml" format, so going forward my internal naming will be different, or I have to modify files going forward post-split - or go back and fix all my existing ePubs to the new standard. I could start the starter file with "Section.xhtml" then rename it post-split to "Section_0001.xhtml" as it still appears to begin numbering at _0002 instead of _0001 (I'd personally start it with 0001 if you're going to go with startingfilename_#### though)

I'm just anal retentive enough to go through and fix them - now or in the future to keep them all consistent. Please for the love of pete can we have a option on using the older file naming for those of us who don't have a bunch of files that we put into a book before the splits happen? If I'm only using one file and I use the Sigil chapter breaks - I'm willing to use the tag to tell Sigil what to name each split out file even if that's what it takes (since I use a template and paste my book chapters into a set format, I'd just have to modify the templates and could fix my original HTML files via find/replace regex for all my old files - the ePubs I already have converted would be fine since they lose the Sigil pagebreak tags when I F6 the file in Sigil anyway.)

Anyway - it's a minor complaint to some of the real issues out there, but I want my old split-naming back (and yes, I do realize how using the old naming could have been problematic for people who are starting with more than one content file - the new way does seem like it'd work best and I may just have to cope - and cry a lot while I fix my ePub collection due to my OCD)

[crutledge]

Continuing to experiment with A Young Man in a Hurry.epub.

Open the file you want to split and go to Code View and go to the location where you want the split.

Insert

<hr class="sigilChapterBreak" />

at the split point and press F6 [split].

The following appears in Book Browser:

A Young Man in a Hurry_0010.xhtml
A Young Man in a Hurry_0010_0002.xhtml

The naming of the file is just right and if you don't like the split point do a Merge With Previous and redo.

This is what should happen for any split.

[user_none]

Originally Posted by theducks

Do you know when the fixes you did will be released in a new version?

0.4.1 is planned for 2ish weeks.

[theducks]

Originally Posted by user_none

0.4.1 is planned for 2ish weeks.

Yes !

[Caleb666]

This seems like a pretty serious bug (people have reported dataloss)... why wait 2 weeks to release a fix, when you can have a minor point release?

[user_none]

Originally Posted by Caleb666

This seems like a pretty serious bug (people have reported dataloss)... why wait 2 weeks to release a fix, when you can have a minor point release?

1) The update checker for 0.4.0 won't work until I switch the code repository to Git. When that happens the update checker for any version less than 0.4.0 will break. So either I make the change early and people with previous versions don't know about the update or I put out a point release which people on 0.4.0 won't know about.

2) There is another data loss bug I'm looking into.

3)

Originally Posted by charleski

And SERIOUSLY, people - if you have a problem ATTACH AN EXAMPLE THAT SHOWS IT HAPPENING. Vague reports of problems aren't helpful

Q&A is necessary because this is the third(?) bug related to splitting that has been fixed.

[user_none]

Originally Posted by weedfreak

Now it does not matter if you have the auto correct on or off so you may as well delete that button. The page for selecting now whether to auto or manually correct seems to be doing the same thing whichever you select, that is reverting to the last version of the file, when you last changed view. Selecting manual correction does show the code for the 'error' but as soon as you try to edit it it reverts to the last version again. I have not yet seen any instance of auto correct doing anything like even attempting a fix, it only reverts the file.

I have been able to recreate this issue. It will be fixed for 0.4.1.

When the code view loses focus it checks for structural errors. If you click manual fix it puts you back in the code view. When the code view gains focus after the book view is selected it updates the contents of the code view with the contents of the book view. These two actions along with updating the book view from the code view are handled via signals. The order signals are processed is not guaranteed. So in your case you're unluckily having one signal overwrite the contents of the code view with old data.

[adv_dp_fan]

Originally Posted by user_none

When the code view loses focus it checks for structural errors. If you click manual fix it puts you back in the code view. When the code view gains focus after the book view is selected it updates the contents of the code view with the contents of the book view. These two actions along with updating the book view from the code view are handled via signals. The order signals are processed is not guaranteed. So in your case you're unluckily having one signal overwrite the contents of the code view with old data.

Could this be why sometimes when I am in code view, jump to the replace dialog and do a replace all in a page, then I click back to the code view all my replacements suddenly revert back to the pre-replace versions? Doesn't happen all the time.