October 29, 2008 at 21:32Typography. Comparing sIFR and typeface.js
This article is inspired by the recent frujo topic about the typeface.js library , which allows you to display text on web pages using an arbitrary font that is not present on the end user’s system.
Naturally, there was a desire to compare the new method with the long-known - sIFR & hellip
sIFR uses Flash to substitute the font. Using a fla-file, a font is embedded in it in a Flash editor, a Flash movie is generated, then when displaying a page using JavaScript, a Flash movie is inserted in the place of the replaced element, occupying the same place and having the same dimensions as the replaced text . Inside the embedded video, the replaced text is displayed, but already using the required, non-standard font.
Thus, using sIFR requires an installed Flash plug-in in the browser and JavaScript enabled. To use sIFR during development, an installed Flash editor is required.
The new method works in a similar way, but in a slightly different way. Instead of the generated Flash-movie, the description of each font character in JSON format is used. Further, the JavaScript library uses canvas (in FF, Opera and Safari) or VML (IE) to render the replaced element.
Thus, to use this technology on the client side, only JavaScript is required. For the developer, no additional tools are required - conversion can be done on the project website.
To compare technologies, I created a simple page with three headings and three paragraphs of text. One heading and paragraph were left untouched, the rest were replaced - one with sIFR, the second with typeface.js. Also in the first paragraph two words were chosen and each of which was replaced using one of the methods. For testing, the Ariac font was used, I did not have it in the OS font set, if it is present with you, the results may vary.
Thus, I tested the replacement of block elements and inline elements in the markup. The result can be seen on the page elifantiev.ru/sifr-and-typeface-compare
You can see that sIFR and typeface.js draw differently. sIFR draws bolder text.When ClearType is enabled, font antialiasing is different . Here I made a serious mistake ... I used one of the standard OS fonts to replace ... That is why the appearance was different when the antialiasing was turned on and off ...
Also, when replacing the inline element, sIFR makes an error. The replaced text is above the rest (see the word "bicycle" in the example). For adjustment you have to add “offsetTop = 5” to sFlashVars when initializing the replacement.
However, typeface.js also makes a similar mistake ... And I have not yet found cross-browser ways to change it, searches continue ... At the same time, the result of rendering typeface.js is more adequate in terms of the occupied width, but the replaced text in the inline element looks larger.
The display difference also becomes noticeable when you zoom in on the page after it is rendered. sIFR does not recount the changed page scale and the font size does not change. When using typeface.js, the font size in the replaced block changes along with the scale of the entire page.
One of the drawbacks of typeface is the inability to select a piece of replaced text. However, the text is highlighted and copied when selecting the entire text of the page by Ctrl-A
typeface.js is unfortunately more resource intensive. This is noticeable in old browsers (I tested in IE6 and Opera8). Also, typeface.js is more in volume. The total size of typeface.js files in my example was 83 kb (of which 67 kb is the font), while the sIFR files were only 31 kb (of which the font is 17 kb.). In both cases, the same character set was "embedded" in font files.
In general, typeface.js seems more convenient for the developer. It does not require installing unnecessary software for converting fonts, all the work on introducing the technology is to connect 2-x JavaScript files - a library and a font file. typeface.js is more flexible and "native" is configured - to change the parameters of its display does not require setting additional parameters anywhere other than CSS. Activation of a replacement for any block is performed only by setting the class on the object.
sIFR has usability advantages. The inability to select text and copy to the buffer when replacing with typeface.js is IMHO very annoying and can significantly interfere with the user's work with the site
UPD: The text of the article is modified taking into account the mistake made - the font present in the OS was originally used.
UPD2: arestov is right - it doesn’t work in Opera 9.61 - the text does not appear at all. In Opera 8 - the text is displayed but in a standard font.
Naturally, there was a desire to compare the new method with the long-known - sIFR & hellip
Description of Methods
sIFR
sIFR uses Flash to substitute the font. Using a fla-file, a font is embedded in it in a Flash editor, a Flash movie is generated, then when displaying a page using JavaScript, a Flash movie is inserted in the place of the replaced element, occupying the same place and having the same dimensions as the replaced text . Inside the embedded video, the replaced text is displayed, but already using the required, non-standard font.
Thus, using sIFR requires an installed Flash plug-in in the browser and JavaScript enabled. To use sIFR during development, an installed Flash editor is required.
typeface.js
The new method works in a similar way, but in a slightly different way. Instead of the generated Flash-movie, the description of each font character in JSON format is used. Further, the JavaScript library uses canvas (in FF, Opera and Safari) or VML (IE) to render the replaced element.
Thus, to use this technology on the client side, only JavaScript is required. For the developer, no additional tools are required - conversion can be done on the project website.
Technology Comparison in Action
To compare technologies, I created a simple page with three headings and three paragraphs of text. One heading and paragraph were left untouched, the rest were replaced - one with sIFR, the second with typeface.js. Also in the first paragraph two words were chosen and each of which was replaced using one of the methods. For testing, the Ariac font was used, I did not have it in the OS font set, if it is present with you, the results may vary.
Thus, I tested the replacement of block elements and inline elements in the markup. The result can be seen on the page elifantiev.ru/sifr-and-typeface-compare
Visual differences
You can see that sIFR and typeface.js draw differently. sIFR draws bolder text.
Also, when replacing the inline element, sIFR makes an error. The replaced text is above the rest (see the word "bicycle" in the example). For adjustment you have to add “offsetTop = 5” to sFlashVars when initializing the replacement.
However, typeface.js also makes a similar mistake ... And I have not yet found cross-browser ways to change it, searches continue ... At the same time, the result of rendering typeface.js is more adequate in terms of the occupied width, but the replaced text in the inline element looks larger.
The display difference also becomes noticeable when you zoom in on the page after it is rendered. sIFR does not recount the changed page scale and the font size does not change. When using typeface.js, the font size in the replaced block changes along with the scale of the entire page.
One of the drawbacks of typeface is the inability to select a piece of replaced text. However, the text is highlighted and copied when selecting the entire text of the page by Ctrl-A
Performance
typeface.js is unfortunately more resource intensive. This is noticeable in old browsers (I tested in IE6 and Opera8). Also, typeface.js is more in volume. The total size of typeface.js files in my example was 83 kb (of which 67 kb is the font), while the sIFR files were only 31 kb (of which the font is 17 kb.). In both cases, the same character set was "embedded" in font files.
Ease of use
In general, typeface.js seems more convenient for the developer. It does not require installing unnecessary software for converting fonts, all the work on introducing the technology is to connect 2-x JavaScript files - a library and a font file. typeface.js is more flexible and "native" is configured - to change the parameters of its display does not require setting additional parameters anywhere other than CSS. Activation of a replacement for any block is performed only by setting the class on the object.
sIFR has usability advantages. The inability to select text and copy to the buffer when replacing with typeface.js is IMHO very annoying and can significantly interfere with the user's work with the site
What else to read?
UPD: The text of the article is modified taking into account the mistake made - the font present in the OS was originally used.
UPD2: arestov is right - it doesn’t work in Opera 9.61 - the text does not appear at all. In Opera 8 - the text is displayed but in a standard font.