OK, this is Bill Hill. Sorry about the change of username. For some reason I couldn't connect with my old one, so I had to create a new one.
First thing to say is that I was utterly staggered and humbled to see that by now more than 140,000 people have watched this video. Thanks, everyone!
Second thing: What is a space?
If you're using a typewriter, or a monospaced font designed to emulate one, a space is a fixed size. Choose one after a period, or choose two, it's unimportant. Whatever makes you feel good and looks right to you. If you want it to look like it was typed on
a typewriter, two probably looks more authentic. In fact, you need two spaces to differentiate from the single space between words.
I was talking about proportionally-spaced fonts - which these days means most fonts on your system - in which a "wordspace" could be different in any line, depending on how much or how little the composition engine has to distribute between the words.
The designer who spent months or years designing the font you're using also took the trouble to design what he or she calculated was the optimum value of a "space".
One space after a period was what the designer envisaged. And it'll be proportional to the type size you're using. And it will be easier to read. But if you think
you know better, by all means go ahead and use two.
However, if I ever find myself editing your copy, the first thing I'll do is run Search-and-Replace to replace all the double-spaces with a single space, including all the ones between words that you never actually
meant to be double-spaces - which I've found to be the single most common typo these days.
It's easy to do, because it's sometimes hard to tell with a proportionally-spaced font that you've typed two spaces, especially at smaller sizes. But they can cause reflow problems if left in. A global S-&-R is an easy operation, so leaving them in is sloppy
and unprofessional IMO. Search-and-Replace is usually the very last thing I do on any copy, including my own, as a final cleanup.
So there's a practical reason for using only one space, too. Unless you want to step through all your spaces manually, replace only the mistakes, and keep the ones at the ends of sentences.
It's a work in progress. Two years from now I hope I don't have to do even a fraction of the manual work I've had to do this time around.
It was a lot of work, but I wanted do it to squeeze the maximum level of readability I could, with the functionality we have today, using Web-standards content. Then I can help specify exactly what has to happen to fix the many issues I've identified.
There are things I'd like to see happen in Internet Explorer, there are things that need to happen to evolve better Web standards, and there are things that could be done to improve authoring tools.
If the web really is the publishing platform of the future - and of course it is - then we need to give that platform all the capabilities authors and developers require to create professional-quality typography and layout - in an environment where the content
creator does not know the characteristics of the display device. What he or she does know, however, are the characteristics of the human who'll be reading it - for those haven't changed in millions of years.
It's a fundamental change from the way we've designed the display of information for 35,000 years. So it's going to take a while. Times Roman was not built in a day
Thanks, deedubb! No, you're the first person to send this. I'll certainly try it. The Mabinogion text file had some other problems, though. Either the original translator (or, much more probably, the person who plain-texted it for Project Gutenberg) occasionally
forgot to put closing quotes after opening quotes. So any automated search-and-replace procedure would get out of wack. If I used Notepad++, I could use Replace as follows:
Run through once by hitting "Replace", then "Find Next", effectively skipping every second ".
Then run through again hitting "Replace" for every one.
At first I made the mistake of putting all the HTML header stuff in. Also, my normal paragraph opening tag is <p class="hyphenate">.
This meant there were lots of " marks which couldn't be replaced - therefore I couldn't use "Replace All".
All stuff you learn the hard way.
But even if you got the automated process right, you still have to check everything by eye because of the initial transcription errors. Well, if you've been a professional editor like me for more than two decades you do
Moral: Do all the S&R work on the plaintext file before you put any tags, DOCTYPE or other declarations in it.
The other issue I had with the Mabinogion text was that it was written in 1849, a very different era in which paragraphs nine or ten sentences long were acceptable. This caused two problems, one aesthetic and one technical.
Aesthetically, it's hard for us more modern folks (even folks as old as me) to read paragraphs that long; that's not the way people write today.
I found that you could get around this by breaking the long paragraphs into shorter ones, effectively creating more opportunities for "good" column breaks (ie at the ends of paragraphs). Sometimes I had to go in and create or remove paragraph breaks higher
up in column 1 of the text, or lower down in column 2, to force "good" column breaks.
At the end of a chapter, I often had to put in multiple <br> tags at the end of the text to force a decent column break - which is why the columns at the ends of chapters aren't equally balanced.
In other words, there was still a lot of manual work to get column and page-breaks right...
I know how we can make a huge number of those issues go away. Which was one of the reasons for doing this project
Ah, I know exactly what you're seeing and why. No font embedding in FF, therefore you're getting font substitution. You also aren't running on Vista, or don't have Microsoft Office 2007 or Mac Office 2008 installed on your machine, or the fonts would be
The masthead <div> Bill Hill's Blog, has another font subtituted, which makes it longer, which overflows into the next div, and so on and so on down the page.
The site was designed to show off font embedding, which IE has had since 1996. With IE8 Beta 2 it works great. However, because the code uses cross-browser standards, if you have the right fonts it also renders fine in Safari and FF. I've tested on both (although
FF's multicolumn support can do funky things at times. It uses its own proprietary tags - which don't validate with the W3C's CSS3 validation tool. I put the Mozilla tags in at first. But I wanted to have the pages absolutely standards-compliant, so I took
I assume you're talking about Embedded OpenType - which, by the way, is also the Web font embedding scheme which Adobe supports.
We never had any thought of extracting license fees from competitors for this technology, now or in the future. It's implicit in handing it over to the W3C as a Web standard that granting rights to any IP it uses is part of the package.
Re your request: (Edit: links to the different chapters would also be nice. )
Just did that.
Re: The request to have the Page/ Chapter navigation buttons at the bottom right rather than middle top. I started out with "Next page" buttons at the bottom right of the pages. Problem is they might be hidden until the window is made FullScreen. This is one
of the areas where I plan to go back and do some more experimentation.
non-trivial (ie extremely fiddly).
I think I'd also like to experiment with more subtle arrow buttons that don't stand out as much but are there where and when you need them.
The big - and I mean big - task is to convert the whole book from Project Gutenberg's plain text into standards compliant HTML. I've built 77 separate Web pages so far, and will probably end up with at least 100... Anyway, I'd like to have a "whole book" rather
than just a few "demo pages" with which to experiment. And I'd love other people to try reading it too and send feedback.
The other thing to say is that the files are incredibly disorganized. I started out thinking I'd do just a few pages. Once I saw how good they looked, I got excited to try the whole thing. Along the way, I should of course have been creating "Chapter" folders
with the files for each chapter in them. That way I wouldn't have to scroll so much when opening files for editing. Techniques that you can get by with for just a few pages don't work for a production-level task like this.
However, the whole purpose of the exercise was:
To see how far I could push readability with Web-standards content
To explore production issues
To experiment with "Reading UI"
To figure out what's still missing in terms of Internet Explorer functionality, Web-standards markup, authoring tool support, etc.
Thanks so much for your interest and comments. Stay in touch, and drop in on my site from time to time, since it's developing day by day,