Main

August 15, 2008

Catching up with the movies

Photosynth This follow up to Microsoft's Photosynth is spectacular. This makes all the "Now enhance it, and let me look at it from another angle" nonsense in the movies seem not so far away.

Now all they need to do is integrate this technology with live video feeds, and we can be virtual tourists in real time. Or, the most perfectly surveilled police state ever!

September 4, 2007

Streaming video needs fast forward

I think Microsoft's Silverlight is pretty cool, and I'm glad we'll have a way to leverage XAML/WPF/C# for rich UI on the web.

But the trend towards Flash and Silverlight video players is killing my favorite feature: "Play Speed > Fast"

Being able to watch one-hour technical talks at 1.4x speed is real value-add. The presenters may be brilliant,but they are rarely concise speakers. And when they start coding a sample live...it's a lot like watching grass grow. Or watching someone type.

Ctrl+Shift+G (in Windows Media Player) and we're in hyperdrive. Everybody sounds smarter, and I get change from my hour investment.

Channel 9, Google Tech Talks, every conference session video... don't leave me in real-time! Please don't go to Flash or Silverlight without fast playback.

May 11, 2007

Visual Syntactic Text Formatting

Years ago I saw some framed Bible verses made with scraps of paper and wire in a way that emphasized the structure of the text and specific words. (Gift products distributed by Zondervan -- but I've forgotten the name.) It got me thinking about how text might be arranged on screen to enhance reading, and I did a little research on the subject. But I never figured out how to use that in Logos, or if it would be worth the trouble.

Today I found a link to Live Ink, which got me thinking about it again. Logos Bible Software users do a lot of on screen reading; would this help?

April 19, 2007

Improving table support

We wrote the rich-text display engine for the Logos Library System, which lives on in the Libronix Digital Library System, before there was HTML. There was no XML, and SGML, its ancient ancestor, was huge and complicated and difficult to work with. (XML is just a dumbed-down version of SGML, which was too powerful for its own good.)

So we built our text format on RTF, which was the Microsoft Word export format, and also the basis for the Windows Help and Windows MediaView hypertext systems. Our goal was to support everything that Help, MediaView, and Word supported. (The supported feature set grew in that order.)

A pleasant side effect of this plan was that we had a powerful, WYSIWYG editor available for creating and testing e-books. We got pretty good at generating RTF manually, but RTF tables were terribly complicated. So we would often create them in Word and then export the RTF for the table and copy and paste it into the larger document.

We got an interactive table editor “for free”, but I felt a lot of responsibility to implement all the table features Word supported. I didn’t want people making a beautiful table and then discovering that our display engine couldn’t render it properly.

It was a lot of work, but eventually it was pretty thoroughly done. We support Word’s background colors and patterns, most of the border formatting (except multi-line borders joining at corners), and we can even rotate text in cells. (Lots of stuff we haven't really used.) I tested our implementation by using Word to re-create the little cards in my wallet (insurance, punch cards, license, etc.) and then compiling them into an e-book.

The table model in Word is very powerful, but it’s very hard to type out freehand in markup. The HTML table model is easier to understand, is familiar to more people, and is also supported by many tools. And it is designed to work easily with a smart, dynamic sizing algorithm that optimizes column widths automatically. (Word has a paper-output orientation, and so its tables are generally fixed width, or at least fixed proportion.)

So that is why we’re messing around with our text display engine: to add support for HTML-style tables. Later this year we’ll be shipping books using the new table format, but you probably won’t be able to tell. Our text development team is the group that will really appreciate the change. They’ll have an easier workflow, better tools, and simpler markup.