|
JSWolf — sorry for the delay, and thank you for pushing on it. I went and checked properly rather than answering from memory, and the short version is that I think the rename is right and the original declaration is not an error. Here is the reasoning, so you can tell me where it is wrong.
First, I measured the fonts in my own library, concluded that epubsana was renaming TrueType files to an OpenType media type, and opened an issue against epubveri asking for a rule. That issue was closed as not a defect, and after reading the specifications rather than the file names I agree with the closure.
The premise we were both working from is that a font with glyf outlines is a TrueType font and therefore not an OpenType font. That is the part that does not hold:
1. The OpenType specification says an OpenType font containing TrueType outlines should use the value 0x00010000 for sfntVersion. So a file starting with those four bytes is not thereby excluded from being an OpenType font — that signature is exactly what OpenType prescribes for the glyf flavour.
2. RFC 8081, which registers the font top-level type, gives font/otf a magic number list containing both 0x00010000 and OTTO. Only font/ttf is restricted to 0x00010000 alone. So the bytes rule spellings out, not in: an OTTO file cannot be font/ttf under any reading, but a 0x00010000 file is admitted by both.
3. EPUB 3.3's Core Media Types table lists media types in rows, and says the first entry in a row is the preferred one. application/vnd.ms-opentype appears only on the OpenType row, and that row's first entry is font/otf. Renaming it to font/ttf would move the file off the row its own declaration sits on, which is a bigger change than correcting a spelling.
So the declaration in your book is a valid Core Media Type under a name the specification has superseded, and font/otf is the name it says to prefer. That is also why epubveri reports it at usage severity rather than as an error, and why epubcheck does not complain: nothing is wrong with the file, only with the spelling.
On the "epubveri gets this wrong" half: if the original declaration were genuinely contradicted by the file, epubveri would be wrong not to say so, and I would want to fix it. So I measured my own library rather than arguing about it, reading the sfnt table directory of every font a manifest declares.
Of the files declared application/vnd.ms-opentype whose bytes I could read, the majority are CFF-flavoured — they start with OTTO, and nobody disputes that those are OpenType. The rest are the glyf ones you are describing, sitting on the same row of the same table under the same declaration. Every one of them, both flavours, carries an OS/2 table, which OpenType requires and Apple's TrueType reference does not; most carry GSUB and GPOS as well.
The direction that would be a genuine error is the other one: a file whose first four bytes are OTTO, which is CFF and cannot be TrueType, declared under a ttf spelling. Not one font in my library is that.
If you have a book where that is not true, I would very much like it. A font whose first four bytes are OTTO under a ttf media type, or a WOFF under an sfnt one, is a real defect and I will chase it. That is a concrete thing to look for rather than a general suspicion, and it is the kind of report I cannot generate myself.
Your report did change something, for what it is worth. application/font-sfnt is a spelling that genuinely does not say which flavour it is, and epubveri now answers that row from the file's own signature instead of guessing — and it stops proposing a replacement the bytes rule out. epubsana 0.15.0 will take the replacement from the finding rather than from a table of its own, so the two tools can no longer disagree about what to write.
|