<samp> Tag on Ereaders?

[enuddleyarbl]

Playing around with another fiction book and I ran across the <samp> tag. At first, I thought I'd fat-fingered a search/replace. But, upon checking, there IS a <samp> tag:

https://www.w3schools.com/tags/tag_samp.asp

The <samp> tag is used to define sample output from a computer program. The content inside is displayed in the browser's default monospace font.

Tip: This tag is not deprecated. However, it is possible to achieve richer effect by using CSS.

That tag seems aimed at browsers. What do ereaders (with their Publisher Default or user-specified fonts) do when they run across these tags? And, I guess the same applies to the semi-quasi-related tags of:

<code> Defines a piece of computer code
<kbd> Defines keyboard input
<var> Defines a variable
<pre> Defines preformatted text

?

[hobnail]

A perennial gripe of mine is that the Kobo doesn't support monospace out of the box the way the Kindle does. E.g.,

.monospace {
  font-family: monospace;
}

Won't work unless you embed the font in the epub, or install one, Courier I think, and you have to name it a certain way.

So I'm guessing that none of those will work on a Kobo, although I don't know what would happen if you had embeded the font or installed Courier.

[JSWolf]

Originally Posted by hobnail

A perennial gripe of mine is that the Kobo doesn't support monospace out of the box the way the Kindle does. E.g.,

.monospace {
  font-family: monospace;
}

Won't work unless you embed the font in the epub, or install one, Courier I think, and you have to name it a certain way.

So I'm guessing that none of those will work on a Kobo, although I don't know what would happen if you had embeded the font or installed Courier.

The font has to be internally named Courier (I also externally named it Courier just to be safe) and put in the fonts directory. This only works for ePub. For KePub, you do have to embed a monospace font.

[enuddleyarbl]

The book is Sanderson's "Oathbringer:"

https://www.amazon.com/gp/product/B0...?ie=UTF8&psc=1

It's odd that they'd use that <samp> tag, then. I can't see that it would get them anything by doing that versus just using a <span> with a class (which is exactly how they used the <samp>.

Oh, well. I'd been hoping the <samp> would somehow override the ereader's lack of monospace. Thanks for the answers.

[JSWolf]

Originally Posted by enuddleyarbl

The book is Sanderson's "Oathbringer:"

https://www.amazon.com/gp/product/B0...?ie=UTF8&psc=1

It's odd that they'd use that <samp> tag, then. I can't see that it would get them anything by doing that versus just using a <span> with a class (which is exactly how they used the <samp>.

Oh, well. I'd been hoping the <samp> would somehow override the ereader's lack of monospace. Thanks for the answers.

It's trivial to change <samp> to <span> so it works in all cases.

[jhowell]

Originally Posted by enuddleyarbl

The book is Sanderson's "Oathbringer:"

https://www.amazon.com/gp/product/B0...?ie=UTF8&psc=1

I have that book and it appears that Tor really messed it up.

The CSS style sheet has lots of "dispaly: block" properties.

[enuddleyarbl]

Originally Posted by jhowell

I have that book and it appears that Tor really messed it up.

The CSS style sheet has lots of "dispaly: block" properties.

Yep. I saw those, too. Hard to believe a major publisher wouldn't have run a check on their code before actually sending the book out. I'd have also thought that they'd have fixed it after 5 years.

[JSWolf]

Originally Posted by enuddleyarbl

Yep. I saw those, too. Hard to believe a major publisher wouldn't have run a check on their code before actually sending the book out. I'd have also thought that they'd have fixed it after 5 years.

It's a bug in epubcheck. epubcheck verifies this with no errors. epubcheck needs to do a better job checking the CSS. That's where epubcheck falls flat.

[Tex2002ans]

<pre> is disastrous.

On many devices, the text will go flying off the edge of the screen.

Or if you're trying to read on a small/skinny device, like a cellphone, the linebreaks make it impossible to read.

Some of this <pre> discussion happened way back in:

• 2015: "Text alignment/spacing for Songbook"

but it hasn't been brought up on MobileRead in a very long time...

I remember <pre> used to be discussed often in the olden days, but I can't find those topics now.

Everyone probably collectively agreed how awful it was and hasn't brought it up since.

- - -

Side Note: And I swear I wrote a post on "code blocks" + syntax highlighting in ebooks... maybe that was in a personal email/rant I did to Hitch years ago.

There was this one programming ebook where I argued replacing every block with SVG and/or high-resolution PNGs generated directly from the source code... using something like LaTeX's minted to go from:

• raw code
• -> custom-sized PDF
• -> SVG or PNG.

This would allow you to generate line numbers and have much more complicated layout/breaks, without the need for Javascript or CSS3 overflows or any of that stuff (that wouldn't work on 99% of ereaders).

Not very Accessible, but at least it would be readable on nearly everything.

(Pinch/zoom on PNGs and/or perfectly laid-out+crisp text SVGs.)

(Reminds me of that 2014 topic on SVG Charts/Tables.)