WARNING: It'll take a loooong time to open the Add screen on that one...

Thanks!

I see what you mean by loooong.. Well if there is any performance enhancement to do I think we have a perfect candidate to study here. But so people don't freak out, not every book has 27 000 pages and a anchor at every line.

Quote:

Originally Posted by nrapallo

If you open my Websters Dictionary 1913_ver21.epub, in the Add screen, the filename is truncated after the third hyphen and I can't tell which filename is being shown (they all look the same)

Thanks!

Just widen the column and you will see it all, I do not not why it gets cut off at the hyphen (logically you should be able to see up to the end of the column, but this is not part of my code, it is part of the tree control i am using)

I see what you mean by loooong.. Well if there is any performance enhancement to do I think we have a perfect candidate to study here. But so people don't freak out, not every book has 27 000 pages and a anchor at every line.

Yeah, this one is not a sample .epub to learn how to use ePubFixer with...

Oh, and by the way, I'm fine with the performance hit, as you note this baby has a lot of hyperlinks and html files! It's a gargantuan epub like my Wikipedia 2006 which is a 40MB .epub.

Quote:

Just widen the column and you will see it all, I do not not why it gets cut off at the hyphen (logically you should be able to see up to the end of the column, but this is not part of my code, it is part of the tree control i am using)

Thanks! I didn't think of that!

On an unreleated note: One more thing to think about, how about a companion PdfFixer so that it's TOC can be manipulated after the .pdf ebook has been created? There sure are a lot of .pdf ebooks out there with chapter headings just begging to be accessed...

Thanks for such a usefull tool, have corrected quite a few toc's but have today discovered a problem. Not sure if there is any standards for the actual name of the .ncx file but i have discovered that epubfixer only looks for toc.ncx. I have a couple of books that are named differently and epubfixer shows an empty toc.

Thanks for such a usefull tool, have corrected quite a few toc's but have today discovered a problem. Not sure if there is any standards for the actual name of the .ncx file but i have discovered that epubfixer only looks for toc.ncx. I have a couple of books that are named differently and epubfixer shows an empty toc.

You are right it only looks at toc.ncx (for opf it looks at only the opf extension), I did not have any problem so I didn't look into it further.

I could do the following change either just look at the extension ncx.

Or a more proper way would be to check for the mimetype application/x-dtbncx+xml in the opf file. I will change it in the next version if there are some problem with some files. But I would like to see your opf & ncx file, just to be sure.

Another reason why the screen would be blank is because the ncx can't be parsed.

You are right it only looks at toc.ncx (for opf it looks at only the opf extension), I did not have any problem so I didn't look into it further.

I could do the following change either just look at the extension ncx.

Or a more proper way would be to check for the mimetype application/x-dtbncx+xml in the opf file. I will change it in the next version if there are some problem with some files. But I would like to see your opf & ncx file, just to be sure.

Another reason why the screen would be blank is because the ncx can't be parsed.

Thanks for the quick reply, to confirm my suspicions i have just had a peek at the source but as i am a vb sort of person it didn't mean much to me but i did find the bit where it looks for toc.ncx.
Here are both files from both books that alerted me to the problem. Hope they are of some use.book1.zip

Nigol, can you look at possibly fixing the behaviour of the "TOC Editor" screen's "Apply" or "Save" button when the "Add" screen is open.

I was in the middle of editing one of my huge .epubs, at the Add screen, and wanted to save my work-in-progress thus far. I clicked the Save button and the Add screen was closed. After opening the Add screen again (it took a loooong time on that .epub ), I tried to click just the Apply button and the same thing happened. Instant closure of the Add screen.

Can you just leave that Add screen "as is" and wait for the user to Close that screen and then click Close to exit the TOC Editor screen to finish. This will allow multiple saves while the editing task is still in progress!

Or a more proper way would be to check for the mimetype application/x-dtbncx+xml in the opf file. I will change it in the next version if there are some problem with some files. But I would like to see your opf & ncx file, just to be sure.

The really proper way would be:

- For the OPF file, look into META-INF/container.xml (this filename does not change), and you'll find something like:

Here are the changes in the new update. It should fix most of the problems that were reported.

v1.3.3
- The Show All checkbox will not be remembered anymore.
- The List of Anchors for each file will now be cached for each different Book.
- The Detected Text will now be cached for each different Book, along with the Anchors text.
- Removed the Apply button, it was replaced by a Add button.
- Using the Add command from the context menu will Add all the items under the selected node (instead of at the end of the document).
- The Save button will no longer close the window (and each related windows, exception is split chapters). You will now need to Save and Close.
- The file column width from the Add screen, will no longer have a maximum width.
- Also resizing the form will no longer adjust the columns width.
- The program will now correctly get the filenames for the NCX & OPF files
- For the OPF file it will get the path from the container.xml file (it used to check only for opf extension)
- For the NCX it will get the id from the spine and lookup the file associated with it in the manifest (it used to check for toc.ncx)
- In the Add window all files or anchors present in the TOC will be shown in Green.
- In the Add window with Show All deselected, Anchors present in the TOC will no longer appear.
- The Forms can now get on top of each other when opened and all will close when the main window closes (TOC or Reading Order editor).
- When opening the Add window, there will no longer be any validating to see if the files shown really exists in the ePub. It will instead
check if the file is present in the TOC when saving the ePub.
- When dragging and dropping Nodes they are no longer removed (with Show All off).
- The Add window will now remember if the nodes are Expanded when clicking Show All or Show Anchors.
- Fixed a problem with Reading order editor showing anchors.
- Shifting Chapters will now get the full source (with anchor) if the next/previous entry is the same file with a different anchor (before it just returned the top of the file).
- Fixed a problem when the source in the TOC was encoded with special characters (ex: %20 instead of a space).

Well it looks like it is not the only way. I have just discovered a book that does not behave like that. Took a free retail book and found out that it did not have any id in the spine element at all. The TOC failed to open in calibre viewer, but did open correctly in Adobe Digital Edition. So I am thinking that Adobe does not even look at the spine for the TOC reference, but calibre does.

I will do a quick update to force the program to look deeper if this situation arise.

Update : v1.3.4 Fixes this.

- Found a situation where the Spine did not have a reference to the TOC (on retail books), So the App will look deeper if this situation arise.
- If the above situation arises opening the Reading Order Editor and Saving will force the reference into the spine. (a message box will open warning you about it)

- Adding an anchor to the TOC Editor properly retains the link and makes it green, but dragging the same link using (ctrl)-click deletes the link from the Add screen, as before.

- In the Add screen, I can resize the "File" (filename) column, but I can't the "Detected Text" (anchor) column. What about allowing the columns to be sorted & reverse sorted?

- When saving a large epub (during a long edit session), there's no indication that the save is progressing while it's doing so. It just seems to freeze without any feedback. If I hit the Save button again it will crash saying the file is in use. Duh?

But, overall I very pleased with your efforts to date!!!

p.s. Nigol, did you know that Kindle ebooks also use a toc.ncx for their navigational d-pad and it is recommended to have one within .mobi ebooks by Kindle publishing standards?

- Adding an anchor to the TOC Editor properly retains the link and makes it green, but dragging the same link using (ctrl)-click deletes the link from the Add screen, as before.

This is by design. With Show All on it will retain the entry by both dragging and Adding with the checkbox. With Show All off it will remove the entry with both ways. In fact it basically reloads just like when first opening the screen. While I have tested it fully there might be a bug somewhere.

Quote:

Originally Posted by nrapallo

- In the Add screen, I can resize the "File" (filename) column, but I can't the "Detected Text" (anchor) column. What about allowing the columns to be sorted & reverse sorted?

You can actually resize both column, but there is a minimum width to respect. I actually enabled the sort columns value, but can't seems to get it to work, or I may have to put my own code to allow it to sort. Documentation is pretty poor for the treeview control.

Quote:

Originally Posted by nrapallo

- When saving a large epub (during a long edit session), there's no indication that the save is progressing while it's doing so. It just seems to freeze without any feedback. If I hit the Save button again it will crash saying the file is in use. Duh?

Actually the error you are getting is not because it is saving the file, but because it is extracting the files back to temp folder. You can see the progress bar at the bottom. The saving is all done before the extracting even begins. It is in fact very fast because there is just a little file to update, the program actually access the ePub pretty often without any hitch. I am re-extracting the files because if someone split the chapters it will have to re-extract the files for the preview to work correctly.

But I will put something to catch the error and prevent it from screwing your file when it arises.

What kind of format is the mobi files? It is not just a Zip file?

Update : Checking this has actually lead me to a big bug that will screw your file when saving more than once. SO please don't use it like that for now, I will post an update in a couple of minutes.