MobileRead Forums - View Single Post

drMerry · 10-01-2011, 01:36 PM

Hi Kiwidude,

Thanks for the response.

Maybe I wasn't clear enough.
The problem is not that I can't compare with winmerge.
Winmerge just did it's Job very well, that's how I found these problems.

Lets re-explain my case.

I see 2 books. In my opinion, the 2 books are equal.
When I do a binary duplicate check, it turns out they are not equal.
That's where Winmerge jumps in.
I used it to compare the files and I found the problems described. Winmerge tells me both files are equal, except for 1, 2, 3 or 4.
So if I change it, a binary duplicate compare tells me that the files are equal.
While comments and empty lines are only useless load that also takes (some) memory on my reader, it would be great to have it removed.
And if it is, I'd also be able to remove a lot of my books because in that case it would turn out that they are duplicates.

For example, I have x books with same author, the same title and (app.) the same size. While they are not binary equal, I have to open all the books to see if there is a difference. If not at first sight, I have to do a compare with e.g. winmerge to see if the difference is on the metadata files or on the real text.

If the plugin could remove just the comments and empty lines, I would only have left 10 percent of my current duplicates that are not binary equal and that I will have to check.

Did this text make the problem clear?
(So lets concentrate on 2 and 3). 1 is indeed a discussion and could only be solved if you implemented a lot of options so the user should tell which one to use (not worth the effort).
For option 4 are other ways.

On the cover problem. I'd really appreciate to have the cover update function split. The reason is clear (to me). I have a lot of books. I want them to be identifiable in calibre by using the cover browser. These extracted covers consume a lot of space so I set all my covers to be max 250x250.
If I update the metadata on my books, I want to keep the original big cover. To display on my reader or to import on a later moment in calibre. Reducing the cover-size saved me about 1GB!!!!! on files so you can imagine that I do not want to reset all the covers just to be able to update my metadata.

At the other hand, I do sometimes have metadata I'm not completely sure about. But the cover is better than the cover currently in the epub file. In that case, I'd like to easily add the cover to the epub by pushing the update button in the plugin without exploding the epub, adding the file and than again compacting the epub.

10-01-2011, 01:36 PM	#193
drMerry Addict Posts: 293 Karma: 21022 Join Date: Mar 2011 Location: NL Device: Sony PRS-650	Hi Kiwidude, Thanks for the response. Maybe I wasn't clear enough. The problem is not that I can't compare with winmerge. Winmerge just did it's Job very well, that's how I found these problems. Lets re-explain my case. I see 2 books. In my opinion, the 2 books are equal. When I do a binary duplicate check, it turns out they are not equal. That's where Winmerge jumps in. I used it to compare the files and I found the problems described. Winmerge tells me both files are equal, except for 1, 2, 3 or 4. So if I change it, a binary duplicate compare tells me that the files are equal. While comments and empty lines are only useless load that also takes (some) memory on my reader, it would be great to have it removed. And if it is, I'd also be able to remove a lot of my books because in that case it would turn out that they are duplicates. For example, I have x books with same author, the same title and (app.) the same size. While they are not binary equal, I have to open all the books to see if there is a difference. If not at first sight, I have to do a compare with e.g. winmerge to see if the difference is on the metadata files or on the real text. If the plugin could remove just the comments and empty lines, I would only have left 10 percent of my current duplicates that are not binary equal and that I will have to check. Did this text make the problem clear? (So lets concentrate on 2 and 3). 1 is indeed a discussion and could only be solved if you implemented a lot of options so the user should tell which one to use (not worth the effort). For option 4 are other ways. On the cover problem. I'd really appreciate to have the cover update function split. The reason is clear (to me). I have a lot of books. I want them to be identifiable in calibre by using the cover browser. These extracted covers consume a lot of space so I set all my covers to be max 250x250. If I update the metadata on my books, I want to keep the original big cover. To display on my reader or to import on a later moment in calibre. Reducing the cover-size saved me about 1GB!!!!! on files so you can imagine that I do not want to reset all the covers just to be able to update my metadata. At the other hand, I do sometimes have metadata I'm not completely sure about. But the cover is better than the cover currently in the epub file. In that case, I'd like to easily add the cover to the epub by pushing the update button in the plugin without exploding the epub, adding the file and than again compacting the epub.