The Gecko Layout Engine added Graphite Smart Fonts support starting in Firefox 11. The Mozilla Firefox documentation for Graphite is still under construction but already contains lots of useful information for Web Designers and Developers.
The number of people who will benefit from Graphite is the small subset of the population that reads and writes with lesser-known scripts that require complex ligatures and rules for glyph substitution. In other words, we expect this work will appeal to a rather small underrepresented percentage of the web who communicate using uncommon writing systems. Firefox fully supports OpenType for the majority of writing systems on the web.
The key benefit of Graphite is that it allows type designers to build in complex script handling logic into fonts themselves, rather than relying on an application library like OpenType to explicitly implement support for it. That’s why it’s so useful for display and layout of scripts that require features not available in OpenType. There’s a lot of overlap with OpenType and the format itself simply adds extra data to OpenType fonts (the glyph and metric data is the same).
Graphite allows fonts to embed rich programs that implement the complex rules that govern glyph behavior in relation to other glyphs in a text run. This rich API presents challenges in an application as widely-distributed as Firefox, especially in regards to security and integration with the rest of the text subsystems. We’re currently testing, validating and documenting the Graphite feature in Firefox. We’re interested in getting feedback from the Font Developer community to ensure that Graphite is expressive enough for complex writing systems. If you have experience with OpenType layout, we’d like to see similar layout functionality implemented using Graphite. We’re looking for examples that could include non-Latin script support (e.g. Arabic, Thai, Indic scripts) or Latin/Cyrillic/Greek fonts with extensive feature support. A symbolic “WingDings” font with complex layout rules could also be a useful example. Please reply in the blog comments if you are interested and available to help us test and verify Graphite’s Layout API’s.
I’m posting about Graphite because it’s another example of why working on Firefox is so different from working on anything else. We don’t optimize our actions to generate maximum revenue, we do things because we want to give the entire planet equal and open access to the web. Proper text layout and rendering for complex scripts enables free expression across communities who would otherwise not have a global voice. We think it’s well worth it in service of the greater good for an Open Web.
I think that this blog entry is very old (Time-scale of web technologies). I am replying anyway. Usually, my comments on this subject were mostly scorned at or ignored because I say that Unicode has made a mistake.
These comments apply to Indic, but also sort of apply to Arabic too. Indic user group is by no measure a ‘small subset of the population’. One fifth of humanity speak Indic. As you say, the scripts are ‘lesser-known scripts’ because of their bad implementation on the computer. Unicode double-byte that adopted Indian ISCII trumped singe-byte ISO-8859 idea. More reasons later…
I developed a set of test smartfonts for Singhala in 2004. At that time, only SIL’s WorldPad was able to display it. They have only lookup tables.
Here are the two web sites that use one of these fonts:
http://www.lovatasinhala.com/ (hand coded)
http://www.ahangama.com/ (WordPress blog)
The font actually implements romanized Singhala in the native script by means of the feature. It is intuitive to type. It needs no double-byte code supporting software, only OpenType aware apps. If NBH is implemented, it could be typed mixing two orthographies never needing any double-byte characters (specifically, ZWNJ). Before jumping into conclusions, please recall that the underlying code set used for Fraktur is Latin, though the letter shapes are different.
The smartfont debunks the notion that Indic is so complex that it would always be a limping script on the computer (Abugida!). The approach taken by Unicode to digitize Indic made it very awkward on the computer. Counting Indic web sites, we see how terrible it must be.
Unicode applied the same principle to Indic as used to define the Latin script. That is, a script is a set of letter symbols for writing a script, with no significance in the grammar of the language. That is well and good for languages using the Latin script because letters hardly change shape in combination. (English has only may be five optional ligatures and Fraktur has a few more)
Unicode solution for Indic is complex. The fonts should make internal shapes that are not necessarily letters of the script but component parts of complex letters, and then write internal routines that implement their assembly. Typing Unicode Singhala, one of the more complex of Indic scripts, is very frustrating. It is forcing us forget our orthographies and is interfered by habits with the English keyboard. This is unfortunate because the computer overcomes all difficulties of letterpress printing and yet we cannot implement Indic with that happy outcome.
As a native user of Singhala, I know that we write by first thinking of the sound and then putting down its shape. In contrast, with English, we write the dictionary spelling of a word.
In Sanskrit grammar, the first and the foundation lesson is the description of ‘akshara’. The Sanskrit akshara set (hodiya) is extended to form the hodiya of each Indic language. The sound (shabda) of an akshara defines the letter as we conceive it. It is the phoneme or as we call, the vowel or consonant. The shape of the akshara called ‘ruupa’ depends on the local script (Nagari, Tamil or Singhala?). The script has its specific convention(s) of writing or orthography. A perfect application of this principle is the Harvard-Kyoto Sanskrit alphabet:
http://www.sanskrit-lexicon.uni-koeln.de/scans/MWScan/tamil/index.html
It is Sanskrit implemented in the Latin script and has no orthographic constraints.
Notice that the chart (hodiya) is in table form unlike an alphabet. It is like IPA chart in its original form.
The problem was to find a way to show Singhala text that closely matches its orthography. Singhala script has three orthographies — one each for Singhala, Sanskrit and Pali (correctly, Magadhi). Modern Singhala mixes Singhala and Sanskrit. Pali is written separately. When you write Singhala, that always mixes in Sanskrit, the Sanskrit words combine letters according to the rule set of Sanskrit. We should either make separate smartfonts for each orthography or use the more complex font and use ZWNJ to prevent conjoints inside the less complex Sinhala words. (few and far apart).
This solution could also be called the dual-script solution for Indic. That makes OCR simple making it possible to digitize old Indic books.
JC
ahangama@gmail.com
817-473-9984
Correction:
I meant to say, ‘They have feature lookup tables’ when I said, “They have only lookup tables”.
Microsoft limits the ‘simple’ script Latin to feature. That is ample for the Dual-script solution. You transliterate the script into Latin taking care that it goes close to the English keyboard. Next, you use orthography to make the tables. You must be well versed in the script to make the tables. I know Singhala. Devanagari is not as complex as Singhala.
I forgot to say that romanized Singhala and Unicode Singhala can be round-trip converted in either direction. If the smartfonts are hosted by Google, then there is no need for web sites to supply the downloadable font like I do. As you see, transliteration obviates the need for the limping double-byte solution. (You can read Singhala as Latin script or native script, convenient for my daughter who was born in US and never learned Sinhala writing. The military and spy agencies may get other ideas too, such as voice to text).
Thanks.
JC
Oops!
This edit box mistook my angle-bracketed word for an html tag or something like that. Let me try again:
‘They have feature lookup tables’, should read,
They have >liga< feature lookup tables
LOL, try again JC:
Not ‘They have feature lookup tables’,
But They have <liga> feature lookup tables