[ATimson]

Originally Posted by thrawn_aj

Precisely what I'm doing. The epub spec exists for a reason. It would be like me writing an application that, instead of using the file attributes that are always saved to any file header by the OS, completely ignored them and instead used the same data but only if it was saved in a proprietary format in some hidden location. Either they're stupid or they're malicious.

As a programmer, if a spec says "this optional field might appear on the file", but it never actually appears on any of the sample files to work from, I'm not going to add support unless specifically told to; it's not something that appears to be useful, and more importantly, it's not something that I can test.

Originally Posted by thrawn_aj

Regardless, they already edit the publisher's metadata for the title, author, publisher, etc. fields. We know this because these fields are already recognized and read for sideloaded books.

Those fields are read in sideloaded books, yes, and those fields are present in the ePubs that B&N sells. I don't see how you leap from "they're in the ePubs" to "B&N added them not the publisher".

Originally Posted by thrawn_aj

So, here are some simple facts without any speculation - several metadata fields are read from the epub file. Only the summary is not read from the epub file.

No, the other metadata for purchased books aren't read from the ePub file - I have at least one purchased book where the OPF title and the metadata title don't match, so it must be using the internal metadata for the title too.

Originally Posted by thrawn_aj

This is the worst possible I can think of to implement something.

You say it's the worst possible way to supplement the publisher's supplied metadata, I say it's the best. Obviously we're never going to agree on this.