Text-rendering

  • Revision slug: Talk:CSS/Text-rendering
  • Revision title: Text-rendering
  • Revision id: 138624
  • Created:
  • Creator: Athula
  • Is current revision? No
  • Comment 908 words removed

Revision Content

Supposedly this should work for HTML content, but even the live examples don't show any difference between the rendering types. You can test it yourself if you screen cap the live example and paste it into an image editing program. Line up identical glyphs and use XOR blending on the top layer. The result will be a pure black image (ie, there is no difference between text rendered for speed, legibility or precision).

The only thing I have noticed is that sometimes rendering for 'speed' will increase the spacing between certain pairs glyphs.

Does anyone know how this is supposed to work?

This is Athula:

In short, you can use it in HTML by using the SVG directive as a CSS directive, as here:

<body style="font-family: Calibri, sans serif; text-rendering: optimizeLegibility;">

But, you shouldn't have to do it. Mozilla did not understand it well.

I am familiar with the way Latin fonts are rendered. First understand that basic glyphs are located at Unicode codepoint positions inside the font. Then some fonts have what are called 'features'. The most common of these features is called <liga>. When a font supports <liga> feature, it has lookup tables that point to ligatures constructed out of several letters. Ligatures are 'glued together' letters typically, f+f, f+i, f+l, f+f+i and f+f+l (ff, fi, fl, ffi and ffl). Since no Unicode codepoints exist for these, the font foundry places their glyphs in locations in the area called Private Use Area, which are unassigned Unicode codepoints.

Now, if optimizeLegibility is set, the application allows the font to offer the ligatures as you type. For instance, if you type 'i' soon after typing 'f', the font replaces the 'f' already typed with 'fi' ligature. (Try this inside Notepad on Vista with Calibri font. You'll be able to move the cursor into the ligature!). As you could imagine, this process happens in microseconds (perhaps nanoseconds) in the main memory of the computer. There is no humanly discernible speed difference between rendering 'f' and then 'i' and rendering 'f' and then replacing it with 'fi'. Calibri has 5 ligatures. We tried this with a font that has 400 plus ligatures some using 3rd level lookups. This page is on the web for anyone to try. It has thousands of ligatures completely transforming a transliterated Indic language into its complex form simply via ligatures.

Do the following test inside a Windows machine:
Install this font: http://www.americansmartfonts.com/download/Suriyakumara.ttf
Then view this page: http://www.lovatasinhala.com/ inside Firefox 3.0
That page has thousands of ligatures.
View the same page inside IE. This time you see the romanized version of the same text. No ligature at all. Do you think this is any faster than the one rendered inside Firefox?

Revision Source

<p>Supposedly this should work for HTML content, but even the live examples don't show any difference between the rendering types. You can test it yourself if you screen cap the live example and paste it into an image editing program. Line up identical glyphs and use XOR blending on the top layer. The result will be a pure black image (ie, there is no difference between text rendered for speed, legibility or precision).</p>
<p>The only thing I have noticed is that sometimes rendering for 'speed' will increase the spacing between certain pairs glyphs.</p>
<p>Does anyone know how this is supposed to work?</p>
<p>This is Athula:</p>
<p>In short, you can use it in HTML by using the SVG directive as a CSS directive, as here:</p>
<p><code>&lt;body style="font-family: Calibri, sans serif; text-rendering: optimizeLegibility;"&gt;</code></p>
<p>But, you shouldn't have to do it. Mozilla did not understand it well.</p>
<p>I am familiar with the way Latin fonts are rendered. First understand that basic glyphs are located at Unicode codepoint positions inside the font. Then some fonts have what are called 'features'. The most common of these features is called &lt;liga&gt;. When a font supports &lt;liga&gt; feature, it has lookup tables that point to ligatures constructed out of several letters. Ligatures are 'glued together' letters typically, f+f, f+i, f+l, f+f+i and f+f+l (ff, fi, fl, ffi and ffl). Since no Unicode codepoints exist for these, the font foundry places their glyphs in locations in the area called Private Use Area, which are unassigned Unicode codepoints.</p>
<p>Now, if optimizeLegibility is set, the application allows the font to offer the ligatures as you type. For instance, if you type 'i' soon after typing 'f', the font replaces the 'f' already typed with 'fi' ligature. (Try this inside Notepad on Vista with Calibri font. You'll be able to move the cursor into the ligature!). As you could imagine, this process happens in microseconds (perhaps nanoseconds) in the main memory of the computer. There is no humanly discernible speed difference between rendering 'f' and then 'i' and rendering 'f' and then replacing it with 'fi'. Calibri has 5 ligatures. We tried this with a font that has 400 plus ligatures some using 3rd level lookups. This page is on the web for anyone to try. It has thousands of ligatures completely transforming a transliterated Indic language into its complex form simply via ligatures.</p>
<p>Do the following test inside a Windows machine:<br>
Install this font: <a class="external" href="http://www.americansmartfonts.com/download/Suriyakumara.ttf" title="http://www.americansmartfonts.com/download/Suriyakumara.ttf">http://www.americansmartfonts.com/download/Suriyakumara.ttf</a><br>
Then view this page: <a class="external" href="http://www.lovatasinhala.com/%20inside%20Firefox%203.0" title="http://www.lovatasinhala.com/ inside Firefox 3.0">http://www.lovatasinhala.com/ inside Firefox 3.0</a><br>
That page has thousands of ligatures.<br>
View the same page inside IE. This time you see the romanized version of the same text. No ligature at all. Do you think this is any faster than the one rendered inside Firefox?</p>
Revert to this revision