“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.)

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

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");

<!--[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");

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"

#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}   !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?