[Rev. Bob]

Originally Posted by davidfor

And all that is my point. The standards don't actually state that there absolutely must be a monospace font available and used. It just says the text marked as such has to be rendered using something. If the app doesn't include one, or the base OS doesn't include one, then

Where technical specifications are concerned, there is a very distinct difference between the three levels of "must," "should"/"recommended," and "may"/"optional." To boil what follows down to a simple TL;DR line: You're interpreting "should" as "may," and that's completely incorrect.

Originally Posted by davidfor

I don't quite agree. The only books I have in my library that mention monospace are test books. Books someone has created purely to test how monospace works on these devices.

Not only do I own ebooks which use monospace, but I've made and published ebooks which use it.

The plural of "anecdote" is not "data."

Originally Posted by davidfor

That text is quite different to what you pointed to before. And it is a lot less restrictive. The first one is pretty much "You really, really should do this". The one for ePub 2 is more a "it is a good idea to do this".

You are absolutely, indisputably, provably incorrect.

First, some definitions.

The EPUB 2.0.1 spec consists of three major sections: OPS (content), OPF (packaging), and OCF (container). We are concerned here with OPS, since that's the part dealing with CSS and XHTML and other matters of content. Since the IDPF website is currently offline, and more recent snapshots at the Wayback Machine don't actually allow browsing of that spec, I'm specifically referencing this snapshot.

OPS 2.0.1 incorporates the CSS2 (most accurately, CSS 2.0) spec by reference; that spec is here.

Finally, when I refer to "CSS/x.y.z," that's shorthand for "the CSS 2.0 specification, section x.y.z."

Citing CSS/15.2.6:

Generic font families are a fallback mechanism, a means of preserving some of the style sheet author's intent in the worst case when none of the specified fonts can be selected. For optimum typographic control, particular named fonts should be used in style sheets.

All five generic font families are defined to exist in all CSS implementations (they need not necessarily map to five distinct actual fonts). User agents should provide reasonable default choices for the generic font families, which express the characteristics of each family as well as possible within the limits allowed by the underlying technology.

(Boldface mine.)

OPS/3.3 modifies this by dropping "fantasy" and "cursive" from the list of five. Note the highlighted phrases; monospace is inarguably well "within the limits allowed by the underlying technology" of an e-reader. Note also the word "should" in the final sentence; it has a specifically defined meaning in this context.

See also OPS/1.4.2.ii: "[The Reading System must] recognize all markup described as permitted in this specification and processes it consistently with the corresponding explanations in this specification and in those of XHTML 1.1, CSS 2, and DTBook (in case of any conflict, this specification takes precedence)".

Finally, consider OPS/3.4, which deals with embedded fonts:

Content creators must not assume that any particular font format is supported. Fonts could be included in multiple formats by using a list of files for the src descriptor; the first supported format should be used. At least one file in OpenType format should always be included in the list. It is advisable for a Reading System to support the OpenType font format, but this is not a conformance requirement; a reading system may support no embedded font formats at all. Content creators should use comma-separated lists for font-family properties to specify fallback font choices.

(Boldface and monospace in original. Note that "format" refers to file format, not font family.)

Now, remember how I said there was a significant difference between "should" and "may"?

Both CSS/3.1 and OPS/1.4 specifically state that certain keywords - specifically including "must" and "should" and "may" - are to be interpreted as defined in RFC 2119. You appear to believe that "should" means "this is a good idea, one we recommend following, but it's ultimately optional and this is just a guideline." That is not at all true. RFC 2119 states:

3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

Or, in layman's terms, you'd better have a damned good reason for not doing it. What such reason exists here?

Review time.

Reading Systems MUST comply with CSS2, except as modified by OPS/3.3, which drops the "fantasy" and "cursive" families but retains "monospace".

Reading Systems MAY completely decline to support embedded fonts.

Per CSS2, Reading Systems SHOULD "express the characteristics of each [generic] family as well as possible within the limits allowed by the underlying technology." That means that "monospace" should be rendered as monospace.

Bottom line? According to the relevant specs, a conscientious author is on firmer ground expecting that a Reading System will support "monospace" than he is if he assumes that it will support embedded fonts.

Therefore, your advice to "embed a monospace font if you want to use monospace" is completely wrongheaded. You are advising ebook designers to rely on an optional feature to patch a hole in a recommended feature.

This. Is. A. Bug. It's that simple.