Typography. SIFR versus typeface.js
This article is inspired by the recent frujo topic about typeface.js library, which allows you to display text on web pages using an arbitrary font that is not present in the system with the end user.
Naturally, there was a desire to compare the new method with the already well known - sIFR & hellip
sIFR for font substitution uses Flash. Using a fla-file, a font is embedded in the Flash editor, a Flash movie is generated, then when a page is rendered using JavaScript, a Flash movie is inserted into the place of the replaced element and occupies the same space and has the same dimensions as the replaced text . Inside the embedded video, the replaced text is displayed, but using the required, non-standard font.
Thus, to use sIFR, you need an installed Flash plugin 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. Next, the JavaScript library uses canvas (in FF, Opera, and Safari) or VML (IE) to draw the item to be replaced.
Thus, to use this technology on the client side, only enabled JavaScript is required. For the developer, no additional tools are required - the 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 was left untouched, the rest were replaced - one with sIFR, the second with typeface.js. Also in the first paragraph two words were selected 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 you have one, the results may differ.
So 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 are drawn differently. sIFR draws bold text.When ClearType is on, font anti-aliasing is different . Here I made a serious mistake ... I used to replace one of the standard OS fonts ... That is why the appearance with anti-aliasing turned on and off was different ...
Also, when replacing an inline element, sIFR makes a mistake. The replaced text is above the rest (see the word “bicycle” in the example). For the correction, one has to add “offsetTop = 5” to sFlashVars during the initialization of the replacement.
However, typeface.js also makes a similar error ... And I haven’t yet found cross-browser ways to change it, the search continues ... At the same time, the result of drawing typeface.js is more adequate in the occupied width, but the replaced text in the inline element looks larger.
The difference in the display also becomes noticeable when the page is scaled after it is rendered. sIFR does not recalculate page scaling and 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 selected and copied when the entire text of the page is selected by Ctrl-A
typeface.js is unfortunately more resource intensive. This is noticeable in the eye in old browsers (I checked in IE6 and Opera8). Also, typeface.js is larger in scope. The total size of the typeface.js files in my example was 83 Kb (of which 67 Kb occupies the font), while the size of the sIFR files was only 31 Kb (of which the font is 17 Kb). In both cases, the same set of characters was “embedded” in the font files.
In general, typeface.js seems to be more convenient for the developer. No need to install extra software to convert fonts, all the work on the implementation of the technology is to connect 2-x JavaScript files - a library and a font file. typeface.js is more flexible and “natively” configurable - to change the parameters of its display, no additional parameters need to be specified elsewhere where CSS is required. Activation of replacement for any block is performed only by installing the class on the object.
sIFR has advantages in terms of usability. The inability to select text and copy to 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 was modified to reflect the mistakes made - the font that was present in the OS was originally used.
UPD2: arestov rights - in Opera 9.61 does not work - the text is not displayed at all. In Opera 8, the text is displayed in a standard font.
Naturally, there was a desire to compare the new method with the already well known - sIFR & hellip
Description of methods
sIFR
sIFR for font substitution uses Flash. Using a fla-file, a font is embedded in the Flash editor, a Flash movie is generated, then when a page is rendered using JavaScript, a Flash movie is inserted into the place of the replaced element and occupies the same space and has the same dimensions as the replaced text . Inside the embedded video, the replaced text is displayed, but using the required, non-standard font.
Thus, to use sIFR, you need an installed Flash plugin 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. Next, the JavaScript library uses canvas (in FF, Opera, and Safari) or VML (IE) to draw the item to be replaced.
Thus, to use this technology on the client side, only enabled JavaScript is required. For the developer, no additional tools are required - the conversion can be done on the project website.
Comparison of technology in action
To compare technologies, I created a simple page with three headings and three paragraphs of text. One heading and paragraph was left untouched, the rest were replaced - one with sIFR, the second with typeface.js. Also in the first paragraph two words were selected 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 you have one, the results may differ.
So 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 are drawn differently. sIFR draws bold text.
Also, when replacing an inline element, sIFR makes a mistake. The replaced text is above the rest (see the word “bicycle” in the example). For the correction, one has to add “offsetTop = 5” to sFlashVars during the initialization of the replacement.
However, typeface.js also makes a similar error ... And I haven’t yet found cross-browser ways to change it, the search continues ... At the same time, the result of drawing typeface.js is more adequate in the occupied width, but the replaced text in the inline element looks larger.
The difference in the display also becomes noticeable when the page is scaled after it is rendered. sIFR does not recalculate page scaling and 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 selected and copied when the entire text of the page is selected by Ctrl-A
Performance
typeface.js is unfortunately more resource intensive. This is noticeable in the eye in old browsers (I checked in IE6 and Opera8). Also, typeface.js is larger in scope. The total size of the typeface.js files in my example was 83 Kb (of which 67 Kb occupies the font), while the size of the sIFR files was only 31 Kb (of which the font is 17 Kb). In both cases, the same set of characters was “embedded” in the font files.
The convenience of use
In general, typeface.js seems to be more convenient for the developer. No need to install extra software to convert fonts, all the work on the implementation of the technology is to connect 2-x JavaScript files - a library and a font file. typeface.js is more flexible and “natively” configurable - to change the parameters of its display, no additional parameters need to be specified elsewhere where CSS is required. Activation of replacement for any block is performed only by installing the class on the object.
sIFR has advantages in terms of usability. The inability to select text and copy to 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?
- Job Description with sIFR
- sIFR - a lot of things about technology
- About sIFR on Habré
- Site typeface.js
UPD: The text of the article was modified to reflect the mistakes made - the font that was present in the OS was originally used.
UPD2: arestov rights - in Opera 9.61 does not work - the text is not displayed at all. In Opera 8, the text is displayed in a standard font.
Source: https://habr.com/ru/post/43542/
All Articles