“Old” Mainly Linguistics Stuff from College Days

This morning I got inspired to go over some relatively old stuff that I worked on in college. There are several linguistics projects that I think are pretty interesting (the first three especially):

And then I found an old chart I made of my racial makup.

And then there is a little web app for SPU’s Nickerson Signal which attempts to model a traffic signal so that upcoming crossing times can be predicted. (Didn’t end up accurately modeling reality.)

And finally there is the Semantic Linking tool (mentioned in my last post) which is a prototype for an upcoming tool which enables contributors to link the semantic units between manuscripts and translations.

Open Scriptures at BibleTech

(This post has been cross-posted on the Open Scriptures blog.)

Register Now for BibleTech:2009, March 27/28 in Seattle, WashingtonFor the past several years, I’ve been dreaming about an open source community-driven Web application for Scripture. In the past few months, things have really been kicking into high gear. At BibleTech:2009 I’m presenting the project in the talk Open Scriptures: Picking Up the Mantle of the Re:Greek – Open Source Initiative:

Open Scriptures seeks to be a comprehensive open-source Web repository for integrated scriptural data and a general application framework for building internationalized social applications of scripture. An abundance of scriptural resources are now available online—manuscripts, translations, and annotations are all being made available by students and scholars alike at an ever-increasing rate. These diverse scriptural resources, however, are isolated from each other and fragmented across the Internet. Thus mashing up the available data into new scriptural applications is not currently possible for the community at large because the resources’ interrelationships are not systematically documented. Open Scriptures aims to establish a scriptural database for interlinked textual resources such as merged manuscripts, the differences among them, and the links between their semantic units and the semantic units of their translations. With such a foundation in place, derived scriptural data like cross-references may be stored in a translation-neutral and internationalized manner so as to be accessible to the community no matter what language they speak or version they prefer.

Think of it as a Wikipedia for scriptural data. Just as Wikipedia has become the go-to place to find open encyclopedia information, Open Scriptures seeks to be the go-to place for open scriptural data. (Non-free data could also be stored, but it would be restricted to non-commercial personal use, as Wikipedia does with fair use or by obtaining special permission.)

Interested? The project needs you! I’d love for a core group of scholars and developers to come together with the shared vision of open access to scriptural data employing open standards and best practices of the Web.

It’d be better without Flash.

I was hiking with my dad and father-in-law in the Columbia Gorge a few weekends ago. At one point along the trail my dad took out his camera to take a picture; my father-in-law, who is a photographer, mentioned to my dad, “It’d be better without flash.” I was struck by how he profoundly and unknowingly affirmed my convictions about work in my field. It would be better without Flash. Why? Flash can do some amazingly cool things, but as a firm believer in the Open Web, the nature of Flash is quite troublesome: it is a proprietary technology and uses a binary format not consisting of Web technologies (as I recently blogged about at work).

In spite of the closed nature of Flash, many things are currently impossible without Flash, of course. However, now with stepped up efforts by browser developers (including Gears) and the development of the HTML5 specification, the things which are impossible without Flash are dwindling. Browser vendors are rapidly implementing cutting-edge technologies such as SVG, CSS transitions and animation, HTML5’s audio, video, and canvas elements, and custom fonts with @font-face; at the same time browser developers are competing for the fastest performance with blazing new JavaScript engines such as Mozilla’s TraceMonkey, WebKit’s SquirrelFish Extreme, and Google’s V8. The JavaScript language itself is being furthered now by a new harmonious momentum on ECMAScript 3.1, some features of which the IE team has been quick to include in the upcoming IE8.

In short, the technological foundation of the Open Web has been quickly growing to provide the compelling features which Flash now makes available. Nevertheless, while the things which have depended on Flash are dwindling, it is still currently a lot harder to do these things without Flash because Adobe’s IDE makes designing and developing Flash apps relatively easy for people not intimately familiar with the technical details. What the Open Web needs, therefore, is an IDE which can provide the same level of abstraction as Adobe Flash. We need an IDE which is able to intuitively generate and manipulate the technologies of the Open Web. Mozilla’s new effort on Open Web development tools, led by Dion and Ben of Ajaxian, seems like a great start. In fact, I think it would be great if the Firebug Working Group joined this new effort, and if the Firebug extension itself would be the development tool which would be the focus of the new developer tool set.

For some inspiration, check out the Antisocial demo and its accompanying demotool.

Efficiently Serving Custom Web Fonts

Note 2009-10-07: Paul Irish published a Bulletproof @font-face syntax, which is a much better way to specify cross-browser downloadable fonts. His technique deprecates what I outlined below. Good work, Paul!

Update 2008-09: Removed superfluous “+” from last RewriteRule.

Update: Acknowledged that Ben was pointing to a solution by John Allsopp.

Ben Galbraith at Ajaxian recently posted again about using custom fonts. He points to a cross-browser solution by John Allsopp which serves EOT fonts and TTF fonts to both IE and non-IE browsers respectively. The idea is to include two @font-face rules with different font-family names (such as "Foo" as the name for the EOT, and "Bar" as the name for the TTF), and then in order to apply these fonts to text in the page you provide both names for the font-family property, such as "Foo, Bar, sans-serif". While this does work, it is also problematic: the client potentially downloads both font files and then throws away the one it doesn’t understand; this problem of wasted HTTP request is intensified by the fact that font files are often quite big (note that Safari appears to skip downloading font files that end in “.eot”, but MSIE doesn’t skip files that end in “.ttf”). There is a more efficient way to serve these font.

In projects I’ve worked on at Shepherd Interactive what I have done is use conditional comments to serve one @font-face rule for IE and another for everyone else. It is also very helpful to include the official name of the file in the CSS3 Web Fonts local() value in the case that the font is already locally installed (also include an additional src:url(...) declaration first in case local() isn’t understood, but if it is then the following src:local(...) declaration will override the previous one).

For example, given a font named “FooBarBaz”, the following is very best way I can conceive to serve web fonts:

<!--[if IE]>
<style type="text/css">
/* Font rule for MSIE referencing EOT font */
@font-face {
    font-family: "FooBarBaz";
    src: url("/fonts/foobarbaz.eot");
    /* above included in case local() isn't *
     * understood, which it isn't by IE7)   */
    src: local("FooBarBaz"), url("/fonts/foobarbaz.eot");
}
</style>
<![endif]-->

<!--[if !IE]>-->
<style type="text/css">
/* Font rule for other browsers referencing TTF font */
@font-face {
    font-family: "FooBarBaz";
    src: url("/fonts/foobarbaz.ttf");
    /* above included in case local() isn't *
     * understood, but Safari 3.1 does      */
    src: local("FooBarBaz"), url("/fonts/foobarbaz.ttf");
}
</style>
<!--<![endif]-->

Of course this assumes that only IE will ever support EOT fonts.

Another way which would remove the need for conditional comments is to use some form of content negotiation (perhaps with mod_rewrite) to serve the appropriate font file based on the user agent (IE or not IE). For example in a CSS file:

@font-face {
    font-family: "FooBarBaz";
    src: url("/fonts/foobarbaz.font");
    src: local("FooBarBaz"), url("/fonts/foobarbaz.font");
}

And then in an .htaccess file:

#Make sure that font files are cached
ExpiresActive On
<FilesMatch "\.(eot|ttf|otf)$">
    ExpiresDefault "access plus 10 years"
</filesMatch>

#Serve "proper" MIME types (they aren't standardized yet)
AddType application/vnd.ms-fontobject .eot
AddType font/ttf .ttf
AddType font/otf .otf

RewriteEngine On

#Serve EOT font if MSIE
RewriteCond %{HTTP_USER_AGENT}   MSIE
RewriteCond %{HTTP_USER_AGENT}   !Opera
RewriteRule (.+)\.font$          $1.eot       [L]

#Serve OTF file if it exists
RewriteCond %{REQUEST_FILENAME}  (.+?)([^/]+)\.font$
RewriteCond %1%2.otf             -f
RewriteRule .+                   %2.otf       [L]

#Serve TTF file otherwise
RewriteRule (.+)\.font$          $1.ttf       [L]

This, however, depends on the client sending a truthful User Agent string.

Any suggestions for further improvements?