Friday, June 14, 2013

Font Units in EPUB

Doubtless, this subject has probably been answered in many EPUB discussions. Still, the question as to what font unit of measurement to use in creating an EPUB is generally unanswered. Unlike in print, the variety of font units in EPUB files is sophisticated. In my opinion, the best way to determine what font unit to use in EPUB is to answer WHY we use it.

In print, font unit problem is not an issue. Units such as inches (in), centimeters (cm), points (pt), and picas (p) are absolute values. Points are the most common in print when setting font sizes and has probably become the standard through many years.

Absolute values are units that are independent from any other relationships. For example, a 12 points font size will always be 12 points.

The problem of font size in EPUBs is due to difference in size and resolution of various screens. Screen fonts use relative values such as pixels (px), ems (em), and percent (%). I think, as of this writing, no standard for font unit in EPUB has been established YET.

Relative values are units dependent from/to a relationship. If a font size for example is in pixels, it is relative (or dependent) to screen resolution. An em is relative to the default font size provided by a browser or ereader (usually 12pt = 16px in browsers).

EPUB is quite new and like its print counterpart, it’ll take time before a standard can be set. EPUBs whether we like or not, are web pages inside a .zip file and therefore can have quite similarly the rules of typography in web design.

Ems versus Pixels

An article in About.com under web design entitled Using Points, Pixels, Ems, or Percentages for CSS Fonts tackles the use of relative units in Cascading Style Sheets (CSS). The concepts presented by the author Jennifer Kyrnin can be applied to EPUB development.

Jennifer’s article focused on “ems” and “pixels” and explained when to use one over the other. She stated two rules of thumb that concerned “accessibility” versus “control”.

Accessibility

If accessibility is your biggest concern, then you should use ems. Ems are sized so that the font size is relative to the parent element. In the case of most Web pages, this is the body element - and so the font is sized relative to the standard size of the browser.

Using ems as your font size measurement ensures that your pages will be accessible to most browsers and platforms. Plus, if your readers choose to change the default font size on the fly, your page will scale to that new size. …

Control

If control over the look of your Web page is your biggest concern, then you should use pixels. Pixels are the standard unit of measure for screens and monitors, and fonts will be more precisely the size you want on the screen.

Pixels are the measure of resolution, and the resolution of your customers' monitors can affect the readability of your type. For example, most Windows machines are set at 96 dpi, while most Macintosh machines are set at 72 dpi. So, a font set at 72px will be 1 inch (approximately) tall on a Macintosh and three quarters of an inch tall on a Windows machine. Also, some OS's (most often Linux and Unix) can make fonts extremely jagged and hard to read if they try to scale the font sizes from the pixel sizes embedded on the OS. …

—Jennifer Kyrnin

If we pick which rule of thumb applies in creating EPUB files, “accessibility” is the answer. Accessibility is the reason ereaders have font size controls and also the reason why EPUBs are mostly reflowable.

Ereader manufacturers have also provided font guidelines for EPUB developers.

Amazon, Apple, and Barnes & Nobles (B&N) Font Guidelines

Amazon Font Guideline

The Amazon Kindle Publishing Guidelines prohibits developers in setting font size for Amazon format ebooks. Though the Kindle ereaders don’t fully support EPUB, the rules in the guideline aids in EPUB to Kindle format file conversion.

Apple/iBookstore Font Guideline

The iBookstore Asset Guide (downloadable if you sign up for an iTunes Connect account) instructs developers to use em or px for font sizes but also imposes that body fonts or main text should be left alone or should be set to 1em (which also means set to 100%).

B&N PubIt! Font Guideline

It’s unclear why B&N did not include font size specification in there EPUB Format Guide. Subliminally, they must have meant that EPUB developers should not set any font sizes.

Obviously, these three guidelines fairly instruct EPUB developers not to set font sizes, implying that the device should be the one to set the font size. This would seem practical but is somehow limiting for EPUB developers.

Export to EPUB Features of DTP Applications

Well-known desktop publishing applications such as InDesign, QuarkXPress, and MS Word have export to EPUB features and most of them set the font sizes to em units. Printed books that were exported from these applications have helped in spreading of EPUBs that used em for font sizes.

A CSS generated by InDesign CS5

What About Percent?

The third unit, the percentage, though rarely mentioned plays a big part in web design when it comes to CSS reset. CSS reset can also be applied in EPUB development. The HTML5 Doctor CSS Reset is good for EPUB since it hasn’t stripped out the font-style and font-weight values of the <i> and <b> HTML tags. If you want to dive into knowing what CSS reset is, visit the article What Is A CSS Reset.

Percent is also used on drop caps and certain margins in EPUB. The best practice I can think of in using percentage is to first set all HTML tags to a font size of 100%. This will override the browser’s or ereader’s default font size for all tags (this is how the CSS reset works). Then use em units to set the font size for each HTML tag that you’ll use in the EPUB.

So why not use percentage for font sizes all the way? For one reason, we haven’t seen much EPUB files that used percentage to set the font sizes. Second reason, the em unit is used by desktop publishing applications as the unit of measure for font size. We might as well tag along in the use of em rather than use percent and wonder if we did the right thing.

Conclusion

To sum up, it seems that manufacturers don’t want EPUB developers to mess with font size in EPUB. But if we ever do need to set font sizes, let’s take note of WHY we should use a certain unit of measure.

Ems

  • Used for accessibility (in web design)
  • Used mostly by desktop publishing applications in export to EPUB feature

Pixels

  • Used for control (in web design)

Percent

  • Least used in EPUB font size

The em unit had the greatest fanbase for font size in EPUB. Perhaps sooner or later, this will be the standard in EPUB development.

The story doesn’t end here though. Not all devices are friendly in the use of em. I believe the e-ink Kindles are somewhat not fond of em units for font size and prefer pixels.

With all these observations, I therefore conclude that we should use em as unit of measure for font-size in EPUB development. If you have any other ideas as to what unit to use, please do share. Your ideas will be greatly appreciated.

P.S.

After checking how some mainstream ereaders support font units for screen, I've come up with the following output.

The Nook Color and Nook HD uses Adobe RMSDK (Reader Mobile Software Development Kit) which explains why they had the same behavior as Adobe Digital Editions (please excuse the misspell on Adobe Digital Editions in the table).

Monday, May 13, 2013

What’s New in EPUB 3 – Part 2

Navigation

This is one of the biggest changes in EPUB 3. What used to be a .ncx file in EPUB 2 is now gone and was replaced by an XHTML document that uses the nav element. The XHTML document also has restrictions in the use of certain HTML tags and uses mostly the ol and li tags. This new feature will require a fallback in case an ereader doesn’t support the new navigation system.

Linking

Basically, linking is as simple as using an a tag in EPUB 2 and this can still be used in EPUB 3. But the IDPF has established a new registry of linking schemes and one in particular (and the only available as of this writing) seems to be complex to implement. They call it, EPUBCFI or the EPUB Canonical Fragment Identifier. The EPUBCFI closely resembles a Regular Expression pattern.

Scripting and Interactivity

Another interesting, albeit optional, development in EPUB 3 is scripting. In EPUB 2 scripting wasn't allowed. JavaScript is the choice for EPUB 3 and EPUB 3 files will need a query method using epubReadingSystem JavaScript object to determine if an ereading device supports scripting.

Styling and Layout

EPUB 3 uses CSS2.1 with added CSS3 features. EPUB 2 used CSS2. The major change is the required embedding of fonts which uses either an OpenType font or a WOFF (Web Open Font Format). The @font-face is used in the CSS for embedding fonts in EPUB. Font-embed also needs a fallback font in case the ereader doesn’t support font-embedding.

Rich Media

EPUB 3 now boasts audio and video. But wait, weren't we able to play audio and video in EPUB 2? Well, actually that depended on the ereader and Apple was ahead of the game by supporting the audio and video tags which are HTML5 tags. The others, like Barnes and Nobles's Nook, only recently implemented them.

The EPUB 3 Specification on audio and video requires devices to support MP3 and MP4 format audio. Codecs H.264 and VP8 are required for video. Rich media needs a fallback mechanism.

Metadata

According to the EPUB 2 Specification, the required metadata for an EPUB file are dc:title, dc:identifier, and dc:language. The rests are optional. EPUB 3 metadata specification is much the same, with an added meta property dcterms:modified which defines when the EPUB file was changed.

Speech

The Text-to-Speech feature was not in EPUB 2, though iBooks seem to have supported it using VoiceOver. With EPUB 3 there is now Pronunciation Lexicons, SSML, and CSS3 Speech Module.

Manifest Fallbacks

When an ereader can't support HTML5 tags such as audio, video, object, and canvass, an EPUB 3 file will need a fallback mechanism to help the reader identify what a certain misrepresented eBook element is all about. Though setting up a fallback mechanism seem tedious, it is required, especially since EPUB 3 is still a young technology and not all ereaders will be able to support most of the features yet.

Containment

There's an issue here as to what the IDPF meant when they said, “There are new restrictions on references to remote resources”. I'll see if I can dig something out of it. The visible change in this part is the extended list of disallowed characters in the OCF file name.

XML and Unicode

IDPF said in EPUB 3, all XML documents must be conformant to XML 1.0. EPUB 2, with the XML declaration <?xml version="1.0" encoding="UTF-8"?">, is XML 1.0 as far as I know. But the <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> declaration is now replaced by <!DOCTYPE html>. I'll also dig into that a little sooner.

These are all the new and changed functionalities in EPUB 3. I'll tackle them in depth in more coming posts and perhaps make a table form.

Saturday, May 11, 2013

What’s New in EPUB 3 – Part 1

O’Reilly has started to make their eBooks EPUB 3 compliant. With this move, they are pushing the ereader development community to do the same, and if oreilly.com is heading for this direction, we might as well follow suit because eventually, that’s where we’re all heading.

After reading the EPUB 3 Specifications in the IDPF website, I tried to condense most of what I know about EPUB 2, compared them with EPUB 3, and chronicled them in this blog.

The following sections are only summaries of what’s new in EPUB 3. I will go into full detail soon after these summaries.

The Content Documents

EPUB 2–XHTML1.1, EPUB 3–HTML5

According to the EPUB 3 Specification, EPUB 3 is XHTML5 which is a serialization of XML and HTML5. But I don’t know if XML will stay. Rumors are spreading that HTML5 will replace XML (i.e., XHTML1.0, 1.1 and XHTML5) altogether. That always happens when a shiny new toy arrives.

EPUB 3 Supports SVG

The Scalable Vector Graphics has, under its hood, XML codes that describe how the graphics will be displayed, thus SVG is actually a vector graphics. So, referring to what I said earlier, if EPUB 3 will support SVG, how will XML die if SVG itself is XML? Maybe the death of XML was really just a rumor.

EPUB 3 Supports MathML

The EPUB 2 format was more of a novel author’s paradise rather than a technical writer’s. This is mainly due to EPUB 2 not supporting display of equations. To display equations in EPUB 2, developers would just use an image for an equation which is outrageously awful. Also, an equation in image format is not accessible and is unusable for the disabled. MathML, an application for XML, tries to solve this problem. If MathML pushes through for all ereaders, then EPUB 3 will be a great haven for technical eBooks.

The Semantic Inflection

If we want to get into further detail about semantics, which we should do because it is required in EPUB 3, I suggest we read Accessible EPUB 3 by Matt Garrish. It’s free for download in oreilly.com. For a start, semantic inflection is an addition of an epub tag, say epub:type, which will define an HTML tag. So to add definition to a <body> tag, we would write <body epub:type=”backmatter”>. We can read more information about this here.

Content Switching

Honestly, I don’t have much of an idea about content switching. Some examples of this were the switch and case tags in EPUB 2, but I was never able to use them. EPUB 2, from some of the examples in the IDPF website, used them for MathML. But MathML was not fully supported in EPUB 2. Anyway, now that EPUB 3 supports MathML, these elements have made their comeback as epub:switch and epub:case.

I have covered only a tip of a glacier here which is EPUB 3. I will be posting more and will cover in greater detail each and every aspect of this new eBook format.

Thursday, May 9, 2013

How to Add an Affiliate Banner in Blogger

After rummaging the internet again for such a question I could not easily answer myself, I was able to get hold of some good answers from Peter McCartney and he also mentioned a support site from Google.

It took me a great deal of time searching for an answer so to try and help others out, I’m going to enumerate my procedure on how I managed to add an affiliate banner to this blog.

First off, find the “Layout” button link on your Blogger Administrator Panel. I would assume that you already know what I meant with Blogger Administrator Panel.

You will then see the overall layout of your Blogger Template and will notice that you can add gadgets to certain areas. Proceed by clicking “Add a Gadget” on an area where you wish your Affiliate banner to appear.

The pop-up window “Add a Gadget” will then appear.

Scroll down and look for the “HTML/JavaScript” gadget, then press the plus button.

This will take you to a configuration pop-up window. You can choose not to add a title, for me it looks better that way. In the content box, add the HTML tag for the banner that your Affiliate provided.

Now view your blog. If the Affiliate banner doesn’t appear, try placing it in a different area, or you might try changing your template. Some of the free templates don’t seem to display the added gadgets well.

Wednesday, May 8, 2013

Adobe’s Game – Is It a Win-Win Situation?

A recent news in The Telegraph says that Adobe, Inc. is starting to build its environment in the Cloud. Meaning all Adobe Creative Suite applications will be available only in the Cloud. There last version without the CC will be Adobe CS6.

Indeed this is a bold move for Adobe. The most I could imagine is that, they will have monthly paid subscriptions in the Cloud. Now imagine the number of users that will pay monthly just to float in that Cloud. That’s a lot of money. Can Adobe handle a great load of users when this system is in place? Can they provide security to any copyrighted material? It’s like they’re trying to take control of the whole publishing system.

On the bright side, many companies won’t need to buy new software that only had added features. That’s the way Adobe products seem to be. A new version arrives, with new features and new tools, but the environment is basically the same.

Or so I think it’s a bright side. Thinking again, this is only good for large companies that can afford the Cloud. Small companies that still use, say, Adobe CS3 products, because they can’t afford the price for new Adobe software, are already left behind. And with this system in place, how can they compete in the Cloud? The best they can do is to buy the last version without the Cloud which is CS6 and stick with it forever.

In my holistic opinion, this is a win-win situation for Adobe and large publishing companies. Small publishing businesses will have a hard time running in this race. And when these small publishers go bankrupt, the competition will get narrower, and the prices of printed, or multi, media will skyrocket bringing the larger companies to cloud 9.

What’s your opinion?

Friday, May 3, 2013

An Emerging Philippine Online eBookstore

Flipping through the pages of the internet (actually, surfing is the more appropriate term) I found a Philippine-based online ebookstore some months ago. Only recently have I checked back on it and discovered so many changes in their site. They look more like Amazon or O’Reilly with their new look. This Philippine online ebookstore is flipreads.com, and judging by the way their website has improved in a few months’ time, they seem to be heading for glory. Their lists of Publishers are not few, and most are real big time hotshots.

I’ve checked out some free ePubs and PDFs a moment ago, and the designs are much better than the free ePubs and PDFs I’ve downloaded some months back. They really are improving. Kudos to flipreads.com

Friday, March 22, 2013

According to a recent blog in Publishing Perspectives, the book reading public is declining.

This could be a bad sign for the future, even for ereading devices. But optimistically, maybe the reading public are just resting from the overload of reading materials that are very much available on the internet. It's just a little break.