Quote:
Originally Posted by BetterRed
And because I find the metadata that publishers include in their products is inconsistent, I don't place any value on having calibre extract it from the format file when I add a book. My experience is that it takes more time to check, correct, and complete what calibre is able to extract, than it takes to enter it directly into the book list cells (that's not a criticism of calibre, it can only extract what's there, and if that's garbage…). I gather the metadata before I add a book and have it pinned so I can see it. As often as not, I can use calibre's metadata copy and paste features to replicate columns from an existing book into the book I'm adding.
|
I mean yeah, metadata included is definitely inconsistent, like some publishers put
ISBN in an unofficial place, I've seen it in like a dozen different places, but most of the time calibre pulls it anyway, & sometimes
Translator &
Illustrator are in
Creator while other times they are under
Contributor. But the fact of the matter is that there are
OFFICAL tags that are part of the ePUB3 & ePUB2 standards. Some things are kinda ambiguous so I understand them not being recognized, but an eBook software
SHOULD support all of the
official tags, it doesn't make sense for them to not. I mean there's no specification that specifically says that the
Translator goes under
Contributor instead of
Creator but the standard gives
examples that
all put
Translator &
Editor under
Contributor while they give inconsistent examples that have
Illustrator under both. If calibre recognized just one of the standard ones then you could use software to preprocess & convert anything with the
Translator Role under
Creator into
Contributor.
It shouldn't even be hard to do just a single one. Calibre recognizes ISBNs that are in many different formats, even very obscure ones that are not even close to any version ever outlined in any ePUB revision I'm aware of.
*
dc:identifier urn:isbn:#############
*
dc:identifier #############
- - *
ID Attribute ISBN
*
dc:identifier #############
- - *
ID Attribute UID
*
dc:identifier #############
- - *
Identifier Type ISBN
*
dc:identifier #############
- - *
Scheme ISBN
*
dc:identifier #############
- - *
Scheme International Standard Book Number
*
dc:identifier #############
- - *
Scheme URNISBN
*
Source #############
*
Source eBook ISBN: #############
*
Source #############
- - *
ID Attribute SourceISBN
*
Source URN:ISBN#############
*
Source URN:ISBN#############
- - *
ID Attribute src-id
All those, or at least most of them, were recognized by calibre & put in the correct spot without issue. Why is a standard, specified value with only 2 possible arrangements not possible?
Quote:
Originally Posted by BetterRed
My experience is that it takes more time to check, correct, and complete what calibre is able to extract, than it takes to enter it directly into the book list cells
|
I don't see the point here? The field often exists, so uniformly that someone made a plugin as a workaround to easily get it from the ePUB metadata... There's no reason I should have to manually type it in all the time. I just added a bunch of series for my sister, they
all have the
translator field populated. Some of the series have
20 volumes & the books in those sets don't all have the same translator. Manually checking the ePUB's metadata is annoying, time consuming, & shouldn't be necessary. That's a lot of work for something that should bee automatic. For books I got myself metadata is easi
er because if nothing else it's on the box or the digital listing page, but
translator is one that doesn't always get listed or is sometimes listed but not easy to see. I really wish more publishers actually put
ISBNs on their ePUBs, that's the
most annoying thing to find, since there are often multiple editions so if I'm importing one for someone else in my household who may have had it for years & doesn't know which version it is I have to look at the ePUB, try to find it, if it's not there find the publisher, year, edition & search Goodreads for it.
At the very least there should be a way within Calibre to add a field &
assign it to a metadata tag, so if a book is imported that has that tag it'll be populated. I mean calibre does that for it's fields already, it even imports
Belongs to a Collection data even though it uses it's own unofficial
SERIES tag for that information.
Quote:
Originally Posted by Sarmat89
The Calibre author doesn't use that feature (and doesn't care about the users), so it is not there.
|
I guess that's really it. I mean if I was making something because I wanted to use it I wouldn't include things that I didn't need or want, but if I was sharing it with others I'd at least make it easy for them to add their own things.
A personal example would be when making tuna sandwiches. My sister & her kids live with me, so often others want some too. They, for some reason, want to have pepper in it, but they don't like the dill relish I put in it. My mom prefers sweet relish in hers so lets pretend she's over too. It's easy enough for me to make it without pepper or relish & let each person add it to their own. There's one, however, who doesn't like that I use Ranch for ¼ of the mayo when I make it. They have to just deal with it or make their own because it's not something you can just add in later conveniently, so I'm gonna make it the way I like, but I can accommodate things that don't cause problems for me & only a little inconvenience, but I'm not gonna harm my own enjoyment for others convenience.
I imagine Calibre's creators feel the same, so I can't fault them for not doing some things, but not letting us use a custom metadata pull field seems like locking the pepper &/or relish in the cupboard so other's
can't use it if they want.