The Digital Declaration of Independence

We hold this truth to be self-evident: That every human has an equal and unalienable right to the means to create, distribute and consume information to realize their full potential for Life, Liberty and the Pursuit of Happiness - regardless of the country they live in, their gender, beliefs, racial origin, language or any impairments they may have. (Bill Hill, 2007)

Take away imagination, pity, hope, history, belief and all the other intangibles from humanity, and all you have left is an ape that falls out of trees a lot - (with apologies to Terry Pratchett)

Wednesday, June 10, 2009

eBooks Will Make More Headway On Reading Than The "Vanilla Web"...




Here's what I want my online book to look like to the reader: A screenshot of the original print version, taken from Adobe InDesign on the Macintosh

As my online friend Richard Fink surmised, I was unable to resist making some experiments to try reproducing Tanya's illustrated book on the Web.

If you read the comments on my previous post, you'll see also that Roger Sperberg asked a key question
: "Do you think that ebooks — even ones on ereaders that share rendering engines with browsers, like Bookworm — will make more headway on (readability) than the web in general?"

I'm sorry to have to say that the answer is that I'm certain readers will do better - at least the ones that don't share rendering engines with browsers - and that the Web cannot become a real platform for publishing while the final display of book content for the reader is at the mercy of those different rendering engines, because they destroy any hope of consistency for publishers - even using standard markup.

It's a sad fact that increasingly-popular Web standards are no help to the online book publisher at all. To test this, I was careful to use only Web-standards HTML and CSS3, and validate it with the W3C's tools.



Here's what FireFox did with my content on the Macintosh. Safari 4 did exactly the same. The image failed to move up to the second column. So now the reader has to scroll to see the image, and can't see the image title in the heading - which should appear alongside it.



Internet Explorer produced pretty much the same on Windows as FF and Safari did on the Macintosh


The best of a poor bunch...FireFox on Windows

As you can see from these screen shots, the results were disappointing. The pages were all created on my MacBook Pro laptop, 17-inch, 133ppi (1920 x 1200). I had hoped (oh, you poor deluded and naive fool, Bill!) that if I got the results the way I wanted on my screen, then users with smaller displays could use browser zoom to make the pages fit their own. That's the way it ought to work.

However, the same markup rendered differently on each browser. FireFox on Windows, and Internet Explorer, at least have FullScreen views (and the FF developers have done some work on it recently - I can tell because I filed a repaint bug a few weeks ago, and now the problem's gone...)

I want FullScreen because I want readers to be able to get the effect of the book design without any annoying menus, toolbars, favorites bars or any of the other rubbish which is necessary when you're browsing, but visually distracting when you're trying to read. I never want scrolling in a book of this type!

FullScreen doesn't exist in Safari, or in FireFox on the Macintosh.

Are any of the browser developers listening to publishers of content meant for sustained, immersive reading? It doesn't look like it to me.

The potential of the Web for illustrated content ought to be huge. For example, there are thousands of beautifully illustrated books which not many people can afford - like for instance, the Arthur Rackham-illustrated version of Shakespeare's "A Midsummer Night's Dream". It ought to be easily possible to put works like this online. But the only really satisfactory versions of these I've seen are in "reader" applications created for that purpose (either as browser plugins or standalone applications).

As long as there's no consistency between rendering on different Web browsers, they'll never be able to handle this kind of content in the right way. And does anyone seriously believe we'd ever get all the browser teams to agree to do this? No chance whatsoever.

One interesting fact I did find during this experiment was that - on my 133ppi machine - the best rendering of the text itself, in the particular font I used, was on the Macintosh, and not using ClearType on Windows...

Don't get me wrong. I still believe that the best reading experience you can get is on Windows, using ClearType with a font optimized for that purpose.

However, creating a font like that involves a non-trivial amount of hinting. The font I chose for the book was Papyrus, which isn't well-hinted at all, and has a deliberately-ragged edge to the characters, which are themselves pretty thin and spidery.

I picked Papyrus for its artistic look. It suited the content admirably, and works nicely when printed. On the screen, however, the best-rendered versions are definitely the ones created using the Macintosh engine. It's probably also a result of the higher resolution of this screen. At lower resolutions, Mac rendering is blurrier - but the blur becomes less intrusive as resolution gets better. I've included a comparison below as a 24-bit bitmap graphic so there's no fudging of the issue by JPEG or other compression. Click on it to see the actual unscaled image.

Rendering comparisons: The Macintosh versions on the left look much better on my display than the ClearType ones on the right. Safari 4 rendering on the Macintosh is identical to FireFox - which is the best by a long way (and obviously both using the same Mac OSX system rendering) - even better than the original in InDesign for reading on screen...

32 comments:

Andrew C. said...

Another great post. I just wanted to let you know that I've become addicted to your blog and to congratulate you on the well written and unbiased articles.

Steven Hall said...

Bill,

Do you have a URL for the sample text above? And can you post it here?

I'd like to see how Opera (my browser of choice) renders it in full screen. I will, of course, get a screen capture to you for comparison.

Thanks,
Steven Hall

Bill Hill said...

The URL is

http://www.billhillsite.com/sanctuaryp1.htm

Anonymous said...

Don't assume a screen size. Don't use absolute point sizes. Definitely don't mix absolute point sizes with pixel sizes, if you must use point sizes.

Don't assume a column will wrap when you want it to wrap. If you want a picture to the right of the text, don't put it at the end of the text and hope that the wrap will manage to place it at the top of the second column. Most of the time it won't. Use the CSS float attributes to put it there.

http://css.maxdesign.com.au/floatutorial/

If you specify a particular font, also specify a generic substitute that will do. You can't be sure that the viewing machine will the font you want.

It sounds like what you really want is a PDF, not an HTML page.

Bill Hill said...

@ anonymous

Nope, I certainly don't want PDF.

I know exactly what I want, and I know it's possible.

Absolute point sizes are necessary, so you can know exactly what the reader is seeing. But the technology must also be capable of adapting the layout when the reader wants to read the text larger, or smaller.

You need to be able to depend on the right font being there. If it's not on the reader's system, it should be embedded in the book or downloaded as required.

I appreciate what you're trying to do, which is give me good advice on how to make the best of what's available on the Web today.

But I've looked at what's available today and it's not good enough.

I'm focused on where we need to go, not where we are now.

The blog's called "The Future of Reading" - not "The Present of Reading" :-)

bowerbird said...

bill said:
> I'm sorry to have to say that
> the answer is that I'm certain
> readers will do better - at least
> the ones that don't share
> rendering engines with browsers -
> and that the Web cannot become
> a real platform for publishing while
> the final display of book content
> for the reader is at the mercy of
> those different rendering engines,
> because they destroy any hope of
> consistency for publishers -
> even using standard markup.

well, i see you've come around to
what i've been telling you all along.

now when you're interested in seeing
the app i wrote for you, let me know.

-bowerbird

Micah said...

Browsers do handle things inconsistently as do platforms. This is one advantage to Flash. Not saying it is a silver bullet. Cross platform consistency is just one pro in a matrix of procons. TLF is a nice step too - and one might note they chose not to use CSS for formatting. The ideas behind CSS are great, the reality, less so.

Steven Hall said...

Bill,

Thanks for the sanctuary URL. Tests with the latest public release of Opera for Windows XP (ver 9.64) seem pretty consistent with FF for Windows. The text appears to the left and the image to the right with a line of text the top.

Unfortunately, my video card/monitor combination only allow up to 1680x1050 so at 100 percent size the text and image scroll both horzintally and vertically. At 80 percent scaling the page fits neatly on the full screen.

PNG screenshot images can be found at:

http://www.ecuad.ca/~stevenhall/billhill/sanctuary(1680x1050)-100percent.png

and

http://www.ecuad.ca/~stevenhall/billhill/sanctuary(1680x1050)-80percent.png

Steven Hall

Paul Durrant said...

I'm the anonymous from comment 4.

Forgive me, but it seems to be that you do want PDF. You want to specify the font and font size, you want to specify exactly how the text fits to the page, you want the user not to have to scroll to view anything, you want to "know exactly what the reader is seeing". I think the question puzzling me is why, given all that, you don't want to use PDF?

Font embedding - yes, I agree, some form of font embedding is definitely needed. It's a sad lack in current web pages. It is now available in ePUB, I'm glad to say.

I now see more what you're doing, but if we're looking for what more needs to be done, we must also make sure we're not misunderstanding or underestimating what is already available.

I've done a little with your page to show what I mean. It could certainly be tidied up a lot more in the coding, but I think it gets a lot closer to what you wanted.

http://homepage.mac.com/durrantsoftware/BillHill/Book.html

I think that the main feature you're like to see is to specify that the text auto-resizes so that it neatly fills the space next to the picture.

That would be neat. I don't think it's possible with current coding. Which, I suppose, is where the future bit comes in....

Liza said...

How should such a book appear on my mobile device?

Richard Fink said...

Ten years from now - or much sooner, I feel - we will all be going around saying, "Remember when you had to use an E-Reader?"
And that will be because we will have figured out how to do books - better than books, really, the term "book", like "record album", will have been redefined - in web browsers.
Both Bill and Anonmymous are right.
What we have isn't good enough.
But we're better off and much closer to the goal than is generally thought.

Bill Hill said...

@ Liza:

Well, first of all I think a mobile device is probably not ideal for viewing this kind of book. You really want to see detailed illustrations at a decent size. Take an Arthur Rackham illustration, for instance - you'd lose so much detail scaled down...

However, that said, I believe you could still have a reasonable viewing experience.

Illustrations would take up a full screen ("page') and the text would be paged, not scrolled.

You'd lose the ability to see the illustrations opposite the headings, but that's the price you'd pay for viewing on a less-than-optimal device for that type of content.

There is a good reason books are the size they are. It's not whim, or random. It's to do with the way human vision works.

Mobile devices are great. I read books on my phone. But they're really suitable for "text-only" books - like novels, etc - and while they're convenient and handy, they're not ideal reading devices.

Optimal text size for humans reading is 11point type - too big to read on a mobile device and still fit enough text on the screen.

Bill Hill said...

@ Micah:

Nope, Flash isn't it, either - unless it's radically changed since I last looked at it.

Time I had another look, anyway.

Bill Hill said...

@ steven:

Thanks for doing this. Looks pretty much identical to FF on Vista.

I should put Opera on my machine as well.

Trouble is with two operating systems (Vista and Mac OSX) and all the browsers, I could spend my life as a fulltime browser updater :-)

Ian said...

But browser zooming of the whole page is only going to work on some screens. If my screen is too small, I'll get a perfectly laid out version of your page, but the text will be too small to read and the picture will be the only thing you can make out.

I can understand the desire to control the exact layout of a page, but there are some complications that come with the digital medium. Screen size is one such, as is the variable nature of text.

My grandfather uses a larger type for everything he reads, my co-workers have very particular ideas about what a "pleasantly readably" font is, as do people on this site; now that the technology allows each reader to make those decisions themselves, we need to at least take their choice into account when doing our layout.

Bill Hill said...

@ Paul:

Thanks for doing this, Paul. It loos pretty good on my browser (FF on Vista) but I'd like to try it out on the other browsers and on Mac before commenting on detail.

The picture needs to be scaled down on my machine, but that should be trivial.

Now, what I'd like is for the reader to be able to increase or decrease the text size, but for the picture to remain anchored on the page opposite the heading.

Goes without saying that I want the book paginated, not scrolling. And of course the pagination would have to change as the reader changed text size - or read the book on a different-sized display.

It can all be done - just not with Web markup and CSS today...

Roger said...

I wonder what the optimal size for an e-reading device would be.

Initial feedback on Amazon's Kindle DX seems to be that you don't really want that big a device except when displaying the content requires it (which would seem to be the case with 'Sactuary!' and, presumably, many textbooks).

Maybe when the screen diagonal gets to be around 9 inches we'll be in the zone that allows for more comfortable e-book/p-book same-design strategies.

Roger said...

Bill Hill wrote: "I'd like ... the picture to remain anchored on the page opposite the heading."

As you note, this is a result of the state of CSS today.

CSS3, I've learned recently, has a "fit-position" specifier that would let you place the image in the top-right position.

So the day is coming ...

Bill Hill said...

@ Ian

You're right. Browser zooming should make the page fit the screen. And then the reader should be able to change the text size.

Look, what I envisage may seem, on the surface, like it's fairly straightforward. But it's not. It involves a complete re-thinking of the design paradigm of the past 35,000 year.

For 35,000 years, humans have designed information display based on a "fixed size of space".

We need a new design paradigm based on designing information display in a dynamic world.

We are still trying to make the old paradigm fit the new world.

But a pixel is not a fixed size. A display is not a fixed size. The text an individual reader wants to read is not a fixed size.

I'm trying to describe The Second Age of Design. If I struggle sometimes it's because it's such a big job.

But if it can be described, it can be built.

bowerbird said...

bill said:
> if it can be described,
> it can be built.

it can be.

except that...

you haven't described it.

you give an example,
incomplete and specified
poorly if at all, and then
you give another one,
equally incomplete and
specified equally poorly,
then you're off to your
next example...

do you want a solution?

or just to complain?

-bowerbird

bowerbird said...

roger said:
> I wonder what the optimal size
> for an e-reading device would be.

what is the optimal size for a car?
for a shoe? for a glove? for a hat?

can you answer me that?

however, if you're looking for a
size that could be a "standard",
i'd suggest that you consider
the fact that we seem to have
a whole lot of paper out there
in the real world that has been
cut to a size of 8.5*11 inches,
more or less in both directions.

so 9*12 would be a start, with
variations stemming therefrom.

-bowerbird

Bill Hill said...

Uh, uh. Paper sizes have more to do with paper manufacturing and cutting processes than optimization for humans.

In Europe, for instance you end up with A4 when you start out with a sheet of (I want to say SRA8), fold it in half, cut, fold in half again, cut, and so on.

I assume something similar happened in the USA.

In fact, if you half A4 again, to A5, or you half 8.5 x 11, you end up with a size close to most paperback books.

Paul Durrant said...

I do agree that the amount of control over layout isn't as good as one would like ideally.

Current ebooks have static layout choices, that are set when the ebook is created. I think you're arguing that ebooks need to incorporate layout hints, so that the ebook display software can adjust the layout for different display aspect ratios and font sizes.

So, in your example pages, if the display is landscape, the picture should float to the right of the heading, but if it's in portrait mode, the picture should appear underneath the heading, and scaled to fill the rest of that page.

If the text doesn't quite fit a screen at the chosen point size (say it runs two two lines over), the hints should tell the display software what vertical space can be removed and/or by how much the headlines or body text can be reduced from the user's chosen base font size. (Or enlarged to make it exactly fit if it's undersized)

This kind of dynamic (almost programatic) layout is currently not available, and would be really useful for high quality ebooks with illustrations.

bowerbird said...

bill said:
> optimization for humans

you just don't get it, do you, bill?

take the words "optimization" and
"optimal" out of your vocabulary...
they do not belong in this dialog;
they describe nonexistent animals.

besides, the fact that american
and european paper-sizes did
_not_ start with the same units,
but ended up with roughly the
same sizes _is_ meaningful about
what happens to be _convenient_
for the purpose for human beings.

but even that is beside the point,
when it comes to a decision about
what size should be our "standard".

we have trillions of pieces of paper
that are of a rather specific size,
and it only makes sense that we
should use variants on that size
for the screens that we'll be using
to view the content on those pieces.

if we'd been using 6*16 all this time,
or 14*4, or 20*15, i'd be saying that
we should be using those sizes now.
it's the only practical way to proceed.

now, seriously, i decided on that
conclusion over 20 years ago now,
and i have seen no reason -- none,
not a single one -- to change it, so
i'm pretty confident that when you
spend the next 20 years mulling it,
you will not discover a better answer.


> In fact, if you half A4 again, to A5, or
> you half 8.5 x 11, you end up with
> a size close to most paperback books.

which is why i have suggested that
e-books use a 2-up facing-pages
display sized at 5*8 for some time...
it prints nicely on our paper and it
renders nicely on landscape screens.

and i have explained all of this to you
repeatedly in earlier e-mail exchanges.

so, here we are again, where you start
by seemingly "disagreeing" with me, but
you argue my side of the argument, and
even use arguments which i have fed you.
it's beginning to seem quite bizarre, bill...

-bowerbird

Roger said...

Paul wrote: This kind of dynamic (almost programmatic) layout is currently not available

Pagination programs do have this kind of control built in, so I think part of the piece that's missing is access to a scripting language.

That is, access outside of the e-reader from within the book file, without creating a security problem and yet not restricting the designer to just one scripting language.

Then this same capability can be migrated to our e-books or e-readers.

XSL-FO also has this type of control IIRC; but it was designed from the beginning primarily for print's needs.

Apart from CSS adopting the full print capabilities of XSL-FO, perhaps some XSL transformation could occur at (or just before) rendering time, once the display size is determined and the reader (the human kind) has picked a font size. I'm not sure if it's possible or practical, but this might be worth looking into.

Roger Sperberg
firstinitial nospace lastname gmail

PS: I have astigmatism and recently took to wearing contact lenses, which require me to use reading glasses. This combination is nowhere near as good as a different pair of reading glasses worn without contacts. Depending on the time of day (and hence whether my contacts are out), I need the type size to be larger on my screen not for aesthetics but simply to make out the words.

It also appears my computer's LCD screen (at just above 102 ppi) is never going to provide me with sharp-enough text. Some type is illegible to me with the contacts/glasses combination while similarly sized text printed on paper is readable.

I'm examining how the 225ppi Nokia N810 screen serves, as well as the Kindle 2 e-ink (166 ppi?) screen, by comparison. (Maybe I just need a better monitor; my optometrist favors the 24-inch iMac so maybe there's something to that Quartz 2D advantage I should utilize.)

All of which is to say: there may need to be a great deal more computation done at the e-book/e-reader end than we've previously thought, even for a single individual's reading.

bowerbird said...

paul said:
> so that the ebook display software
> can adjust the layout for different
> display aspect ratios and font sizes.

bingo.


> This kind of dynamic
> (almost programatic) layout
> is currently not available

bill and richard should realize that
this is exactly what i was referring to
when i talked about the importance
of _copy-fitting_ to this task in our
earlier backchannel e-mail dialog...

it's also why underspecification of
bill's examples is so confounding,
because without clear delineation
of what he'd _like_ to have happen
under various conditions, it's very
difficult to know how to build such
a program to do dynamic layout...

-bowerbird

Bill Hill said...

@ Roger:

We have both the 24" iMac (Tanya's machine) and the 17" MacBook Pro. If you want sharp, go with the MacBook if you can afford it.

But if you want REALLY sharp text at reading sizes, use BootCamp to instal Windows Vista (or 7, when it ships) and get the benefit of ClearType and CT-optimized fonts like Cambria or Calibri.

bowerbird said...

more on "copy-fitting"...

see this, on the making of
the "new york time reader":
https://xd.adobe.com/#/featured/video/200

there's no timing display
on the video-player there,
but about 25% in, you get
this, from one of the people:

"instead of a templating
approach, which is kind of
the status quo right now,
we took an approach of using
an "art directing" algorithm,
or an algorithm that could
make decisions and modify
the template on-the-fly
depending on the
size of the window
and the content available."

he then continues:
"it allowed every page to
look and feel more like a
printed paper, and to be
easier to read and to feel
more natural than what
you'll traditionally get
on a website."

this is what you want,
except you don't want
to have to entomb your
text in flash to get it...
(sorry, micah, but it
simply needs to be said.)

once you understand
this is what needs to
be done, it's really not
all that hard to do it...

-bowerbird

Bill Hill said...

@ bowerbird (&micah)

I agree, this is what you want. Bowerbird's evocatively-direct language expresses the same misgivings I have about using Flash.

You should have been a diplomat, BB...

bowerbird said...

i'm a poet.

the poet's job is diametrically
opposed to the diplomat's job.

the poet must tell the truth,
regardless of how that might
affect the mission.

the diplomat must achieve the
mission, without regard to truth.

a poet can be the leader of a
country, but not a diplomat...

beware of any country who sends
you a poet as a diplomat, because
you will quickly suspect them of
using words to manipulate you...

-bowerbird

bowerbird said...

and, because i am a poet,
and therefore have the luxury
of being able to speak truth,
i can also say that micah
is using flash to produce
some very beautiful stuff.

> http://www.bluefire.tv

i think he also worked on
"adobe digital editions",
which though not nearly
so beautiful, has many
of the qualities that are of
considerable interest here.
some of them were not
implemented very well,
but they are in evidence.

-bowerbird

dan said...

''The job of making the screen as comfortable to read as paper is not yet completed. I've come to believe that it is the development of Web standards, and standards-based rendering, which will take us the rest of the way.''

Yes. Well said, Bill. Still, Luddite that I am, even with a good sense of humour, I still believe that the screen is a machine, part of a damned machine, and hums, and it can NEVER be comfortable as paper reading, reading a book on paper. Books are fine. Why do we even NEED computers? In a way, they have messed up the world, creating a generation of lazy people who just want to play play play. Whatever happened to reading, deep reading, and thinking, analysis, ideas, things like that? The computer revolution has turned society into a mass market of consumers who only want to spend spend spend and buy the latest gadget. We never needed computers. We never needed email. This entire computer revolution has backfired, although it sure LOOKED cool at the beginning. Look at the results, Bill. Society has just gotten dumber an dumber. I blame screening. Give me a book, or give me death!