Bill Hill

Bill Hill manotype

Niner since 2008


  • Bill Hill: The Future of Reading on the Web, Part 2

    Either should work. I prefer points.

  • Bill Hill - There is only one space after a period

    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.
  • Bill Hill: The Future of Reading on the Web, Part 2

    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 Smiley
  • Bill Hill: The Future of Reading on the Web, Part 2

    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 Smiley

    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.

    From a technical perspective, it caused problems because the multicolumn Javascript uses the DOM. That means its lowest level of granularity is the <p> element. So if you have long paragraphs you get very weird line-breaking at the bottoms and tops of columns. 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 Smiley

  • Bill Hill: The Future of Reading on the Web, Part 2

    Not bother with pagination?

    Sorry, but you're very, very wrong.

    We've just never seen it done right yet. But we will.
  • Bill Hill: The Future of Reading on the Web, Part 2

    Oh, I know how to solve it all right.

    Part of the purpose of creating those pages was to show why it should be solved for the Web...

    Go look at the New York Times reader or Seattle P-I Reader on your machine. The P-I one's free; it will install WPF in the process.
  • Bill Hill: The Future of Reading on the Web, Part 2

    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 there.

    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 them out).
  • Bill Hill: The Future of Reading on the Web, Part 2

    Mmm, yes, it's expected ugliness.

    Site was specifically designed to utilize IE8's Web standards rendering. Works in other Web standards browsers, but no embedded fonts.
  • Bill Hill: The Future of Reading on the Web, Part 2

    Thanks for the kind words.

    Some great books:

    "Guns, Germs and Steel" and "The Third Chimpanzee" by Jared Diamond.

    "The Journey of Man: A Genetic Odyssey" by Spencer Wells.

    You might like to read my paper "The Magic of Reading", which is posted on my website.
  • Bill Hill: The Future of Reading on the Web, Part 2

    Correct, the site is designed to use the default Web-standards rendering in IE8. A horizontal scroll bar, ugh!

    Try IE8 Beta 2 - it's terrific, very stable, and has a compatibility button so older websites don't break.

    And please let me know if you still have problems. 1440 x 900 should be ideal, that's what it was created on.

  • Bill Hill: The Future of Reading on the Web, Part 2

    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.

  • Bill Hill: The Future of Reading on the Web, Part 1

    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.

    I like the idea of putting the nav buttons at the bottom right. I may have to go in and adjust columns of text to make space on some pages. The Javascript I use for multicolumn does some weird linebreaking in certain circumstances so adjusting columns can be 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,

    best wishes,


View All