Font Best Practices

[Hitch]

Originally Posted by AliceWonder

This I'm curious about.

What about monospace fonts `work badly' in eBooks?

I haven't seen anything I'm doing with them `work badly'.

I wouldn't use them as the main content font, but they are great for some things.

Most books use them for text associated with barcodes (such as ISBN number), LOC number, etc. - and they are also necessary for ASCII art.

What eBooks have you seen that use Monospaced fonts for the barcode, LOC or anything else, deliberately, other than something like the name on a door or a sign?

Just like monospaced font always did, you end up with rivers, if you use it for more than a word or so.

ASCII art? In an eBook? Rotsa ruck with that, as Scooby-Doo would say.

Hitch

[AliceWonder]

Wasn't suggesting to use it for the paragraph text, but ePub uses html and both 'pre' and 'code' elements are suppose to render with a monospace font.

So like it or not, readers that do not have a monospace font have incomplete support for the specification which unfortunately requires books that do use pre and code to include a monospace font to deal with those readers.

Maybe not very many books need those tags, but they are part of the standard.

[Hitch]

Originally Posted by AliceWonder

Wasn't suggesting to use it for the paragraph text, but ePub uses html and both 'pre' and 'code' elements are suppose to render with a monospace font.

So like it or not, readers that do not have a monospace font have incomplete support for the specification which unfortunately requires books that do use pre and code to include a monospace font to deal with those readers.

Maybe not very many books need those tags, but they are part of the standard.

Your faith in the standard is nice, but I think you'll find that "x" being part of the standard doesn't mean much on real devices. We all wish it did, but we have threads here weekly that deal with "standard" coding, elements, etc. that are blithely ignored.

Not to mention all the devices that won't display an embedded font, no matter what one does, OR the devices and software readers that will allow the end user to completely override what the designer intended.

It's nothing to do with what I like. It's just...the devices, software, etc.

But, again--it's your book and you can do with it what you will. If you want to use monospace font for something, have at it! :-)

Hitch

[JSWolf]

Originally Posted by AliceWonder

Wasn't suggesting to use it for the paragraph text, but ePub uses html and both 'pre' and 'code' elements are suppose to render with a monospace font.

So like it or not, readers that do not have a monospace font have incomplete support for the specification which unfortunately requires books that do use pre and code to include a monospace font to deal with those readers.

Maybe not very many books need those tags, but they are part of the standard.

Forget pre and code. They can be a rather large fail. I've seen too many instances where the text it too long for the width of the screen and it just goes off to the right not to be fully seen. You cannot control this as you won't know what font size is going to be used or what size screen is going to be used.

What is it you need to use a monospace font for? Is it something you can use the default sans-serif font instead?

Also, Hitch is a professional and knows what she is talking about when it comes to fonts. I agree as I've seen plenty of embedded fonts that are a big fail. What to do is make a test eBook that embeds the fonts you want and try them with a 300DPI eInk Reader and see how they look. Do they have enough weight? My guess is no they don't.

[doubleshuffle]

Originally Posted by AliceWonder

I use a shell script to pack the final .ePub - not GUI tools. I don't like GUI tools. They change from one version to another, they break when a library they are built against changes, etc. They tend to lock you in to their product.

I have very bad experiences with GUI tools. They are useful, but not for critical parts of the workflow.

I'd really be interested in how Sigil and Calibre are supposed to be locking me in. I've been using them both for ages, jumping between the two and Notepad++ to boot, and I feel free as a bird. I can't remember anything ever breaking, just improving. (Not commenting on your workflow, mind, of course you should do what works best for you. I just wonder where that idea of being locked in is coming from. Apple, E-book stores etc. - they try to lock people in (though not extremely successfully so far...))

[najgori]

"The last year within the Digital Publishing Toolkit research project, Hogeschool van Amsterdam and Hogeschool Rotterdam together with various designers and developers, collaboratively worked on the EPUB From Print to Ebooks: a Hybrid Publishing Toolkit for the Arts."
...

enjoy monospaced headings

Originally Posted by Hitch

What eBooks have you seen that use Monospaced fonts for the barcode, LOC or anything else, deliberately, other than something like the name on a door or a sign?

Just like monospaced font always did, you end up with rivers, if you use it for more than a word or so.

ASCII art? In an eBook? Rotsa ruck with that, as Scooby-Doo would say.

Hitch

[Hitch]

Originally Posted by najgori

"The last year within the Digital Publishing Toolkit research project, Hogeschool van Amsterdam and Hogeschool Rotterdam together with various designers and developers, collaboratively worked on the EPUB From Print to Ebooks: a Hybrid Publishing Toolkit for the Arts."
...

enjoy monospaced headings

Like I said--other than something like a sign or the name on a door. These doofuses (would that be doofi?) decided to use it for headings. Certainly not my rave fave, by ANY means, but...at least it's not used for regular reading. (I'll refrain from further comment on the aesthetics, etc. as I'm quite sure that Wolfie will be along shortly...)

When I see that they set this NOT to hyphenate, and deliberately used monospaced layout and a mono font... this is going to look really bloody clunky in a smaller device.

Also--does anyone remember why I'm thinking that these headings are going to break queerly on Nooks? Something about this is dinging my noggin'. Anybody else remember? Dubshuff? Do you recall why this is making me think it would break on a Nook?

Hitch

[doubleshuffle]

Originally Posted by Hitch

Dubshuff? Do you recall why this is making me think it would break on a Nook?

Hitch

Sorry, dahlin', but I'm in Europe; ain't no Nooks here, so I blithely ignore anything anyone might say about them...

[AliceWonder]

Originally Posted by JSWolf

What is it you need to use a monospace font for?

Knock Knock, Neo

The Matrix has you...

Follow the white rabbit

A monospace font was used in one of the most iconic and successful movies of the 90s, so don't you think its a bit silly to suggest we should do w/o it?

Think Differently

or on iOS, drop the ly.

[JSWolf]

Originally Posted by najgori

"The last year within the Digital Publishing Toolkit research project, Hogeschool van Amsterdam and Hogeschool Rotterdam together with various designers and developers, collaboratively worked on the EPUB From Print to Ebooks: a Hybrid Publishing Toolkit for the Arts."
...

enjoy monospaced headings

You've done some things wrong. Left/right margins, monospace headers, paragraph spaces, and no indents make for one not nice eBook to try to read. If you cannot get your eBook formatting correct, why should anyone actually bother to take the advice of what's in the book?

[AliceWonder]

Originally Posted by doubleshuffle

I'd really be interested in how Sigil and Calibre are supposed to be locking me in. I've been using them both for ages, jumping between the two and Notepad++ to boot, and I feel free as a bird. I can't remember anything ever breaking, just improving. (Not commenting on your workflow, mind, of course you should do what works best for you. I just wonder where that idea of being locked in is coming from. Apple, E-book stores etc. - they try to lock people in (though not extremely successfully so far...))

Note sure what this is suppose to do, buy I came across this while looking at other ePubs:

        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
        <meta name="calibre:cover" content="true"/>
        <title>Cover</title>

Calibre seems to use its own namespace in metatags. Not sure what it uses it for, but if it has no purpose, why is it there? If it does have a purpose, is that purpose preserved when changing editors?

[JSWolf]

Originally Posted by AliceWonder

Note sure what this is suppose to do, buy I came across this while looking at other ePubs:

        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
        <meta name="calibre:cover" content="true"/>
        <title>Cover</title>

Calibre seems to use its own namespace in metatags. Not sure what it uses it for, but if it has no purpose, why is it there? If it does have a purpose, is that purpose preserved when changing editors?

You can set the options in the Calibre Editor to not update the metadata when you load an ePub. That will prevent the editor from making any changes without you doing so.

To change the options, you want..

Tools > Preferences > Editor settings and uncheck Beautify individual files automatically when they are open
Tools > Preferences > Integ... (last icon on the left side) and uncheck Update metadata embedded in the book when opening.

By doing this, the ePub will not be changed when loaded in the the editor.

[Tex2002ans]

Originally Posted by AliceWonder

Wasn't suggesting to use it for the paragraph text, but ePub uses html and both 'pre' and 'code' elements are suppose to render with a monospace font.

[...]

Maybe not very many books need those tags, but they are part of the standard.

Yeah... like JSWolf said, <pre> is broken on many real life ereaders. In many cases, the text scrolls right off the end of the screen (especially with larger font sizes).

And remember:

• There are very skinny/small devices too (cell phones).
• Many devices don't even have touch.

Any sort of fancy CSS3 scrollbars don't work.

So many of the other solutions online try to use Javascript to help line breaking (displaying indented arrows, numbering lines, etc.)... can't rely on that in ebooks either.

[AliceWonder]

The point isn't that huge code listings in an ePub is a good idea.

The point is that there are legitimate reasons for monospace fonts in currently produced media, such as was used on the Thomas A. Anderson's computer screen in The Matrix when Trinity contacted him.

And none of those lines would cause a problem in a book if using the code tag, which allows for line wrapping when needed.

Readers without monospace fonts are an unfortunate decision because there are legitimate reasons for publishers to use them where a variable-width font does not give the atmosphere to the reader. I do not understand why that is hard for some to comprehend.

Publishers who use a code tag, a perfectly legal tag to use - or even a span if they want monospace but it's not semantic code - have no choice but to bundle their own because some devices lack the ability to properly render HTML that is specifically supported by ePub.

[Hitch]

Originally Posted by AliceWonder

The point isn't that huge code listings in an ePub is a good idea.

The point is that there are legitimate reasons for monospace fonts in currently produced media, such as was used on the Thomas A. Anderson's computer screen in The Matrix when Trinity contacted him.

And none of those lines would cause a problem in a book if using the code tag, which allows for line wrapping when needed.

Readers without monospace fonts are an unfortunate decision because there are legitimate reasons for publishers to use them where a variable-width font does not give the atmosphere to the reader. I do not understand why that is hard for some to comprehend.

It has nothing to do with comprehension. It has to do with years of experience, in making hundreds and thousands of books, on untold numbers of devices, and seeing everything that can, and does, go wrong.

Publishers who use a code tag, a perfectly legal tag to use - or even a span if they want monospace but it's not semantic code - have no choice but to bundle their own because some devices lack the ability to properly render HTML that is specifically supported by ePub.

You have one book to worry about. You can, as you control that book, make certain assumptions about where it will be read, on what devices and all that. For those of us that do this professionally, we have to assume that the book will be read on devices that are positively unfriendly to the standards--and unsurprisingly, most really ARE downright unfriendly thereto. Apple's one of the worst offenders; KDP for all the horsecrap that people say about MOBI, is actually more compliant than is iBooks. B&N's Nook is another headache.

Then you get the eReaders, software "devices" built by every Tom, Dick and Harriet, which will either automatically override all, repeat, ALL the CSS and HTML that you've put in the book, or only "some" and/or will allow the user to do so.

And new-to-it users, who think that everything in the standard is, of course, supported someplace when in reality, the opposite is true. Sure--there are some pure, plain,to-the-standards eReaders out there, but by and large, it's the sellers of the devices that are driving the bus. Don't believe me? Look at the last few revisions and "updates" to the ePUB standard, notice how much of it has to do with multimedia and Apple and then cogitate on who is maintaining the "standards" and for whom....

There are plenty of readers w/o monospace fonts. As I tried to explain, initially, I have no issue with them when used in a limited way. As long as they aren't used for the reading material, by and large, hey--your book. Your choice.

Vis: the calibre metadata tags--I recommend you review what Calibre is for--a library tool--and why those tags exist. They have nothing to do with walled gardens.

Hitch