MobileRead Forums
Register Guidelines E-Books Today's Posts Search

Go Back   MobileRead Forums > E-Book Software > Calibre > Plugins
Reload this Page [GUI Plugin] Modify ePub

Notices

Reply
Page 87 of 119 « First 83848586 87 88899091 Last »
 
Thread Tools Search this Thread
Old 10-10-2019, 06:33 PM   #1291
Rev. Bob
Wizard
Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.
 
Rev. Bob's Avatar
 
Posts: 1,760
Karma: 9918418
Join Date: Feb 2013
Location: Here on the perimeter, there are no stars
Device: Kobo H2O, iPad mini 3, Kindle Touch
Ooookay, here's what I'm gonna call v1.4.0 RC1. Changes from the earlier beta:

- A notice has been added in the enclosed HTML help file to clarify that removing the Adobe resource meta tags will break obfuscated fonts.
- The Google Play pagemap removal function has been moved out of the Kobo option and into the general-purpose pagemap removal option.
- The general-purpose pagemap removal function no longer looks for one specific filename, but scans based on the MIME type assigned to pagemap files.

Specific desired feedback:

- "Nothing broke!" (if true)
- Bug reports, of course.
- Info on pagemaps in ebooks which did NOT come from Google Play. Specifically, if it's feasible to safely identify and remove their anchors, might as well give that a go. If such a book is legitimately available for free within the U.S., I'm willing to download it for dedicated testing.

If nobody spots any bugs in this one before, say, 11:59pm Eastern on the 17th, let's make it the official release. (Non-GP pagemap info is not a showstopper here. I'd rather get an official 1.4.0 out there and work on that enhancement for a 1.4.x update than delay this release over it.)

EDIT: Removed outdated build, see message 1296.
Last edited by Rev. Bob; 10-11-2019 at 11:11 AM.
Rev. Bob is offline   Reply With Quote
Old 10-10-2019, 06:58 PM   #1292
Rev. Bob
Wizard
Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.
 
Rev. Bob's Avatar
 
Posts: 1,760
Karma: 9918418
Join Date: Feb 2013
Location: Here on the perimeter, there are no stars
Device: Kobo H2O, iPad mini 3, Kindle Touch
Quote:
Originally Posted by JSWolf View Post
I found what may be a bug. An ePub that is not a KePub is showing that Kobo Spans have been stripped.

Can you have a look and see why this is happening and what it's actually doing? I've attached a scrambled version of the eBook that's showing this behavior.
In this case, it looks like the HR element is getting checked and processed without actually being changed. That's part of a safety check to guard against unclosed BR and HR elements.

It's not strictly a Kobo issue, and the same logic appears in the generic "strip spans" routine as well. I don't recall why it's in both places; perhaps I saw the issue in some Kobo books and put the logic there for extra security (in case the user didn't also have strip_spans checked).

Bottom line: it doesn't hurt anything, it's not changing the code in this specific case (aside from some spacing that doesn't affect anything), and thus it's more of a circumstantial oddity than a bug.
Rev. Bob is offline   Reply With Quote
Old 10-10-2019, 07:46 PM   #1293
BetterRed
null operator (he/him)
BetterRed ought to be getting tired of karma fortunes by now.BetterRed ought to be getting tired of karma fortunes by now.BetterRed ought to be getting tired of karma fortunes by now.BetterRed ought to be getting tired of karma fortunes by now.BetterRed ought to be getting tired of karma fortunes by now.BetterRed ought to be getting tired of karma fortunes by now.BetterRed ought to be getting tired of karma fortunes by now.BetterRed ought to be getting tired of karma fortunes by now.BetterRed ought to be getting tired of karma fortunes by now.BetterRed ought to be getting tired of karma fortunes by now.BetterRed ought to be getting tired of karma fortunes by now.
 
Posts: 21,727
Karma: 29711016
Join Date: Mar 2012
Location: Sydney Australia
Device: none
@Rev. Bob - No problems with my 3 saved configurations.

BR
BetterRed is online now   Reply With Quote
Old 10-11-2019, 06:38 AM   #1294
JSWolf
Resident Curmudgeon
JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.
 
JSWolf's Avatar
 
Posts: 79,758
Karma: 145864619
Join Date: Nov 2006
Location: Roslindale, Massachusetts
Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3
@Rev. Bob So far so good on the Google Play ePub I tested RC1 on.
JSWolf is offline   Reply With Quote
Old 10-11-2019, 08:33 AM   #1295
JSWolf
Resident Curmudgeon
JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.
 
JSWolf's Avatar
 
Posts: 79,758
Karma: 145864619
Join Date: Nov 2006
Location: Roslindale, Massachusetts
Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3
I'm using RC1 and I've found a bug. The plugin has removed a couple of images as unused images when they are being used. They are being used in the CSS. So (IMHO) the code for checking for unused images should also check CSS.

Code:
hr.tb {
  border: none;
  text-align: center;
  margin: 1em 0;
  background: url(../image/3_asts.png) no-repeat 50%;
  height: 1em;
}
hr.x5ast {
  border: none;
  text-align: center;
  margin: 1em 0;
  background: url(../image/5_asts.png) no-repeat 50%;
  height: 1em;
}
JSWolf is offline   Reply With Quote
Old 10-11-2019, 11:08 AM   #1296
Rev. Bob
Wizard
Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.
 
Rev. Bob's Avatar
 
Posts: 1,760
Karma: 9918418
Join Date: Feb 2013
Location: Here on the perimeter, there are no stars
Device: Kobo H2O, iPad mini 3, Kindle Touch
Quote:
Originally Posted by JSWolf View Post
I'm using RC1 and I've found a bug. The plugin has removed a couple of images as unused images when they are being used. They are being used in the CSS. So (IMHO) the code for checking for unused images should also check CSS.
Hmm.

Okay, on the one hand, I agree with you that image removal ought to be checking the CSS, so at least from the conceptual angle, it's a bug. Not a new one, though, which leads me to two counterpoints.

First, not being new, fixing it is of necessity further down my list than squashing any bugs introduced in the new version.

Second, the help file description of the routine only claims to check HTML; it says nothing about going through the CSS:

Quote:
Looks for orphaned jpg, png and gif files that are not referred to from the html content pages and can be removed from the ePub. This can happen if for instance in Sigil you delete a page without removing the associated image(s).
(Emphasis mine.)

Finally, but by no means least significant: In studying modify.py and container.py, I see a way to search CSS files for given strings; the XPGT removal does that. However, I don't see a good way to scan the CSS for general classes (like "images"), and I'm not familiar enough with that routine to be confident that I could quickly hack it to properly check for relative paths - that is, to distinguish "../images/separator.jpg" in 1/css/styles.css from "../images/separator.jpg" in 2/stylesheet.css.

So, as much as I'd like to see this fixed, and as willing as I am to incorporate a patch from someone else in the community, I think that's going to have to wait for a later release.

Meanwhile, I have attached a new build which adds an explicit warning about this into the help file and incorporates a couple of other small fixes.

EDIT: Removed in favor of the final release version.
Last edited by Rev. Bob; 10-18-2019 at 11:55 AM.
Rev. Bob is offline   Reply With Quote
Old 10-11-2019, 01:08 PM   #1297
JSWolf
Resident Curmudgeon
JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.
 
JSWolf's Avatar
 
Posts: 79,758
Karma: 145864619
Join Date: Nov 2006
Location: Roslindale, Massachusetts
Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3
Quote:
Originally Posted by Rev. Bob View Post
Hmm.

Okay, on the one hand, I agree with you that image removal ought to be checking the CSS, so at least from the conceptual angle, it's a bug. Not a new one, though, which leads me to two counterpoints.

First, not being new, fixing it is of necessity further down my list than squashing any bugs introduced in the new version.

Second, the help file description of the routine only claims to check HTML; it says nothing about going through the CSS:

(Emphasis mine.)

Finally, but by no means least significant: In studying modify.py and container.py, I see a way to search CSS files for given strings; the XPGT removal does that. However, I don't see a good way to scan the CSS for general classes (like "images"), and I'm not familiar enough with that routine to be confident that I could quickly hack it to properly check for relative paths - that is, to distinguish "../images/separator.jpg" in 1/css/styles.css from "../images/separator.jpg" in 2/stylesheet.css.

So, as much as I'd like to see this fixed, and as willing as I am to incorporate a patch from someone else in the community, I think that's going to have to wait for a later release.
Personally, I don't like the way it the images were done in CSS. I think they should be done in the HTML code. It makes it a lot easier to see where these images are being used in the HTML when you see the image code.

But the one thing I do like is that I have the original ePub and I was able ot go into the original ePub, grab the two images and put them back into the ePub. Problem solved.
JSWolf is offline   Reply With Quote
Old 10-11-2019, 10:17 PM   #1298
DNSB
Bibliophagist
DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.
 
DNSB's Avatar
 
Posts: 46,220
Karma: 168983734
Join Date: Jul 2010
Location: Vancouver
Device: Kobo Sage, Libra Colour, Lenovo M8 FHD, Paperwhite 4, Tolino epos
Quote:
Originally Posted by Rev. Bob View Post
Okay, on review… this is what we in The Biz call a PEBKAC error: Problem Exists Between Keyboard And Chair.

The obfuscated font is an Adobe resource, one which is protected by DRM.

You have instructed Modify to remove Adobe resource DRM meta tags.

Without that tag, readers no longer have the keys required to decode the DRM which obfuscates the font.

Modify is doing exactly what you’ve told it to do. The problem is that you’ve told it to break your book’s fonts.

This is not a bug, nor is it new behavior.

It may be that some additional warnings about this scenario are warranted, but this is at its heart a plugin which exists to allow the user to make significant changes. Some of those are dangerous… and this is one of them.
I would disagree that the tag is solely an Adobe resource DRM meta tag though it is used for that purpose. It is after all one of the few registered Identifier Schemes.

Code:
UUID

    A Universally-Unique Identifier (also referred to as a GUID).

    <dc:identifier opf:scheme="uuid">50f9f8b1-8a81-4dd5-b104-0766188d7d2c</dc:identifier>

    <dc:identifier opf:scheme="uuid">urn:uuid:a1b0d67e-2e81-4df5-9e67-a64cbe366809</dc:identifier>
ModifyEpub can and does add multiple dc:identifier tags most of which I find relatively useless.

Code:
    <dc:identifier id="uid">3502494312</dc:identifier>
    <dc:identifier opf:scheme="calibre">3ef7f9c4-ada8-4147-8dfb-4c97c03a767f</dc:identifier>
    <dc:identifier opf:scheme="AMAZON">B07NPX4L18</dc:identifier>
    <dc:identifier opf:scheme="ISBN">1988891003</dc:identifier>
    <dc:identifier opf:scheme="KOBO">book_title_3</dc:identifier>
Last edited by DNSB; 10-11-2019 at 10:25 PM.
DNSB is online now   Reply With Quote
Old 10-11-2019, 11:17 PM   #1299
Rev. Bob
Wizard
Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.
 
Rev. Bob's Avatar
 
Posts: 1,760
Karma: 9918418
Join Date: Feb 2013
Location: Here on the perimeter, there are no stars
Device: Kobo H2O, iPad mini 3, Kindle Touch
Quote:
Originally Posted by DNSB View Post
I would disagree that the tag is solely an Adobe resource DRM meta tag though it is used for that purpose. It is after all one of the few registered Identifier Schemes.
Uh, no. That’s not even remotely connected to my diagnosis. See the attached thumbnail – the same one you posted, but now with a bonus red box to highlight the option where you’re telling Modify to break your fonts.

Quote:
Originally Posted by DNSB
ModifyEpub can and does add multiple dc:identifier tags most of which I find relatively useless.

Code:
    <dc:identifier id="uid">3502494312</dc:identifier>
    <dc:identifier opf:scheme="calibre">3ef7f9c4-ada8-4147-8dfb-4c97c03a767f</dc:identifier>
    <dc:identifier opf:scheme="AMAZON">B07NPX4L18</dc:identifier>
    <dc:identifier opf:scheme="ISBN">1988891003</dc:identifier>
    <dc:identifier opf:scheme="KOBO">book_title_3</dc:identifier>
Modify ePub doesn’t generate those. Those come from calibre.

EDIT TO CLARIFY:

When you tell Modify to “update metadata” (the green box on the thumbnail) – that can include those identifiers, but only if you’re calling Modify on an ebook you’ve already saved from calibre and have since gone back and made changes to its entry in the calibre library. My normal workflow is to use the “download metadata” feature of calibre proper and straighten all of that out before I save the EPUB elsewhere, so I never even touch that option… but every ID listed in calibre’s metadata dialog gets its own dc:identifier element in the OPF file.

And that’s true even if you never use Modify ePub on the book.

I can edit the book within the standard calibre editor interface, after acquiring metadata but before doing anything else and without ever running Modify on it, and that list of identifiers is already there.
Attached Thumbnails
Click image for larger version Name: 5F10DF3A-8F8F-437C-ABCD-3F3DFA3B6232.jpeg Views: 194 Size: 196.4 KB ID: 174181  
Last edited by Rev. Bob; 10-11-2019 at 11:35 PM.
Rev. Bob is offline   Reply With Quote
Old 10-12-2019, 09:55 PM   #1300
DNSB
Bibliophagist
DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.
 
DNSB's Avatar
 
Posts: 46,220
Karma: 168983734
Join Date: Jul 2010
Location: Vancouver
Device: Kobo Sage, Libra Colour, Lenovo M8 FHD, Paperwhite 4, Tolino epos
Quote:
Originally Posted by Rev. Bob View Post
When you tell Modify to “update metadata” (the green box on the thumbnail) – that can include those identifiers, but only if you’re calling Modify on an ebook you’ve already saved from calibre and have since gone back and made changes to its entry in the calibre library. My normal workflow is to use the “download metadata” feature of calibre proper and straighten all of that out before I save the EPUB elsewhere, so I never even touch that option… but every ID listed in calibre’s metadata dialog gets its own dc:identifier element in the OPF file.

And that’s true even if you never use Modify ePub on the book.

I can edit the book within the standard calibre editor interface, after acquiring metadata but before doing anything else and without ever running Modify on it, and that list of identifiers is already there.
Interesting. I re-imported the book to calibre. I then ran ModifyEpub on it. The <dc:identifier opf:scheme="UUID">urn:uuid:e6f8ccbf-f756-4a24-8f2e-7fa9b76df046</dc:identifier> line disappeared. And 4 dc:identifier lines were added to content.opf. So basically, import the epub file to calibre and run ModifyEpub. No updating metadata, no editing in calibre, no polishing, etc. Those lines were added by ModifyEpub likely from metadata extracted from the epub by calibre. I will admit I used Sigil not the calibre editor but that should make no difference.

I will also still disagree that the dc:identifier line that is being removed is a "Adobe resource DRM meta tag" though it is used by Adobe's font obfuscation. After all the blasted epub was downloaded from Kobo as one of their GUID named.epub downloads which says no Adobe ADEPT DRM was being used.
DNSB is online now   Reply With Quote
Old 10-12-2019, 10:52 PM   #1301
DNSB
Bibliophagist
DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.
 
DNSB's Avatar
 
Posts: 46,220
Karma: 168983734
Join Date: Jul 2010
Location: Vancouver
Device: Kobo Sage, Libra Colour, Lenovo M8 FHD, Paperwhite 4, Tolino epos
Quote:
Originally Posted by Rev. Bob View Post
Uh, no. That’s not even remotely connected to my diagnosis. See the attached thumbnail – the same one you posted, but now with a bonus red box to highlight the option where you’re telling Modify to break your fonts.

I did some digging to find out just where that dc:identifier line was removed since the code used for the Adobe DRM removal did not seem to be capable of detecting a dc:identifier tag. I first removed the check from Remove Adobe resource DRM meta tags. Ran ModifyEpub and the dc:identifier line disappeared. Removed the checks in the Known Artifacts section and the dc:identifier line disappeared. Removed the checks from each section in turn leaving only the Metadata, section and shock and disbelief, the dc:identifier line disappeared. At this point the only checkbox left checked was the update metadata checkbox. So I removed that check box and checked the Strip spans checkbox. The dc:identifier line stayed.

At this point I would have to say that this disappearance has nothing to do with removing Adobe DRM and is (IMNSHO) a bug in the metadata update routine within calibre itself.

As a crosscheck, I opened the epub in calibre's editor and the dc:identifier line had disappeared when I opened the content.opf file. Nastily, even if I opened the book and closed the calibre processes from Task Manager, the change in content.opf was still saved.
Attached Thumbnails
Click image for larger version Name: Modify_epub_options.png Views: 191 Size: 56.2 KB ID: 174200  
DNSB is online now   Reply With Quote
Old 10-13-2019, 01:52 AM   #1302
jhowell
Grand Sorcerer
jhowell ought to be getting tired of karma fortunes by now.jhowell ought to be getting tired of karma fortunes by now.jhowell ought to be getting tired of karma fortunes by now.jhowell ought to be getting tired of karma fortunes by now.jhowell ought to be getting tired of karma fortunes by now.jhowell ought to be getting tired of karma fortunes by now.jhowell ought to be getting tired of karma fortunes by now.jhowell ought to be getting tired of karma fortunes by now.jhowell ought to be getting tired of karma fortunes by now.jhowell ought to be getting tired of karma fortunes by now.jhowell ought to be getting tired of karma fortunes by now.
 
jhowell's Avatar
 
Posts: 7,072
Karma: 91577715
Join Date: Nov 2011
Location: Charlottesville, VA
Device: Kindles
Quote:
Originally Posted by DNSB View Post
As a crosscheck, I opened the epub in calibre's editor and the dc:identifier line had disappeared when I opened the content.opf file. Nastily, even if I opened the book and closed the calibre processes from Task Manager, the change in content.opf was still saved.
The calibre editor has an option in the "Integration with calibre" tab: Update metadata embedded in the book when opening.

I make sure to turn that off to prevent unintended changes to edited files.
jhowell is online now   Reply With Quote
Old 10-13-2019, 11:51 AM   #1303
Rev. Bob
Wizard
Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.
 
Rev. Bob's Avatar
 
Posts: 1,760
Karma: 9918418
Join Date: Feb 2013
Location: Here on the perimeter, there are no stars
Device: Kobo H2O, iPad mini 3, Kindle Touch
Quote:
Originally Posted by DNSB View Post
At this point I would have to say that this disappearance has nothing to do with removing Adobe DRM and is (IMNSHO) a bug in the metadata update routine within calibre itself.
If it’s a calibre bug, it ain’t my problem. I can’t fix those.

If it’s an “Adobe resource DRM meta tag” or an “Update metadata” (in Modify) problem, it is not a bug introduced by Modify 1.4.0; I haven’t touched those routines.

My suggestion at this point would be to revert your copy of Modify to the one in this thread’s first post (1.3.13) and verify the behavior with it. If you see the same bug – which you should, because as I’ve just explained, 1.4.0 uses the same code for all of the routines you’ve mentioned – then we can confirm once and for all that it’s not a 1.4.0 problem and thus should not block the release of the 1.4.0 update.

I will also remind you that calibre itself has seen a major update (to 4.x) recently, which is a considerably more likely culprit. Once again, this is not a calibre bug thread. It is a Modify ePub thread.
Rev. Bob is offline   Reply With Quote
Old 10-13-2019, 07:18 PM   #1304
DNSB
Bibliophagist
DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.
 
DNSB's Avatar
 
Posts: 46,220
Karma: 168983734
Join Date: Jul 2010
Location: Vancouver
Device: Kobo Sage, Libra Colour, Lenovo M8 FHD, Paperwhite 4, Tolino epos
Quote:
Originally Posted by Rev. Bob View Post
I will also remind you that calibre itself has seen a major update (to 4.x) recently, which is a considerably more likely culprit. Once again, this is not a calibre bug thread. It is a Modify ePub thread.
I went back to the oldest version of ModifyEpub that I have kicking around in my archives that would work with Calibre 4 and the issue persisted. I did a quick and dirty test that imported set_metadata and executed it and bye bye dc:identifier.

If it works (it's been a bit since I filed a calibre bug report), I've created a bug report for the issue.

As for ModifyEpub 1.40, I have to say it was an innocent bystander. Of course, in the spirit of Kovid working around bugs in QT, etc., have you no desire to work around a bug in calibre?
Last edited by DNSB; 10-13-2019 at 07:21 PM.
DNSB is online now   Reply With Quote
Old 10-13-2019, 07:54 PM   #1305
Rev. Bob
Wizard
Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.
 
Rev. Bob's Avatar
 
Posts: 1,760
Karma: 9918418
Join Date: Feb 2013
Location: Here on the perimeter, there are no stars
Device: Kobo H2O, iPad mini 3, Kindle Touch
Quote:
Originally Posted by DNSB View Post
Of course, in the spirit of Kovid working around bugs in QT, etc., have you no desire to work around a bug in calibre?
I already do, to some extent; I manually patch the source code in my machines’ dev environments to use my preferred cover page code. I’m tempted to try tracking down a long-time bug that Kovid doesn’t see as one, though: the “depth” value calibre calculates for NCX files is too high by one.

(Kovid’s explanation is that the value is not allowed to be zero, as it would be for an empty NCX, thus he sets empty to 1, a single level to 2, etc. My rebuttal was to point out that an NCX is not allowed to be empty in the first place; at least one node is required by the spec. He responded that an empty NCX doesn’t break on any known readers, so there. Neither of us is going to persuade the other, and it’s his software, so he wins.)
Rev. Bob is offline   Reply With Quote
Reply
Page 87 of 119 « First 83848586 87 88899091 Last »

Tags
modify epub

« Previous Thread | Next Thread »

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
[GUI Plugin] Quality Check kiwidude Plugins 1251 07-07-2025 09:13 PM
[GUI Plugin] Open With kiwidude Plugins 404 02-21-2025 05:42 AM
[GUI Plugin] Manage Series kiwidude Plugins 167 07-28-2024 03:07 PM
Modify ePub plugin dev thread kiwidude Development 346 09-02-2013 05:14 PM
[GUI Plugin] Plugin Updater **Deprecated** kiwidude Plugins 159 06-19-2011 12:27 PM


All times are GMT -4. The time now is 06:56 PM.

Contact Us - FAQ - Guidelines - Privacy - Top

MobileRead.com is a privately owned, operated and funded community.