Re: "Interoperability is getting better" ... What does that mean?

Jukka K. Korpela, Wed, 09 Jan 2013 11:03:28 +0200:
> 2013-01-09 2:55, Leif Halvard Silli wrote:
>
>> The benefit of doing such a comparison is that we then get to
>> count both the HTML page *plus* all the extra fonts that is included in
>> the "romanized Singhala file". Thus, we get a more *real* basis for
>> comparing the relative size of the two pages.
>
> Not really. I don’t want to comment “romanized Singhala” any more,
> but I can’t leave a different fallacy uncommented.

Not sure which fallacy you have identified - see below.

> When comparing sizes of web pages, it is clearly not sufficient to
> compare just HTML pages only. It is not uncommon to have just a few
> kilobytes of HTML but with loads on JavaScript and images, totalling
> a megabyte or more. This makes it relatively irrelevant whether some
> characters occupy one byte or two bytes. (Besides, HTML often gets
> automatically compressed for transmission.)

On this we agree.

> But if we count font files as well, we should count them in all
> alternatives being compared. Although you can, in principle, write
> e.g. a web page in Sinhala by simply providing the text content,
> sitting back and expecting browsers to render it using whatever fonts
> they prefer using, that’s a very unrealistic approach in practice. It
> would work for English (though few web content providers do that –
> they mostly want to set fonts), but for Sinhala, it would mean that a
> very large part of users (possibly the majority) would not see the
> Sinhala letters. The reason is that their computers lack any font
> that contains them. (Well, not the only reason, but the most common
> one.)

In Opera for Mac OSX, the font-face embedding apparently did not work.
Thus, the "romanized Singhala" page did not render any Sinhala at all,
whereas for the Unicode version, then one got to see Sinhala letters,
though with many "gaps", so the Sinhala representation on Mac OS X
could indeed be wrong. OTOH, when I disabled CSS in a webkit browser
(iCab), the page rendered just fine, so I am not sure why it failed in
Opera - could be a more complicated reason.
  […]
> And, to be fair, Unicode-encoded fonts that contain Sinhala letters
> tend to be considerably larger than 8-bit ad-hoc encoded fonts. Then
> again, these days, size does not matter that much, and a downloadable
> font gets cached, and a Unicode-encoded font typically contains a
> much richer repertoire of characters, so that characters from
> different scripts (like Sinhala, English, and Common-script
> characters) have been designed to fit together.

It is indeed true that for the two pages in question, then the Unicode
font was a little larger than the "romanized Singhala" font. However,
like I told, the Unicode test page included two fonts, namely the
"romanized Singhala" font and a Unicode Singhala font, whereas the
other page only included one font - the "romanized Singhala" font.
However, despite this difference, the Unicode Singhala page came out
pretty well compared with the "romanized Singhala" page: It seemingly
loaded faster - for some reason. And it resulted in a smaller Webkit
webarchive. And, according to YSlow, it only contain 20-30% more total
weight than then "romanized Singhala" page contained.

It is of course true that it is debatable how much larger size really
matters — I did not say that it did or did not matter. But regardless:
There are authors and authoring tools such as YSlow, that focus on
exactly that issue: size and how that and other factors, affect the
page load and other user experience factors. And it was interesting to
see that even from that angle, the Unicode Singhala page seemed more
like the winner than the looser.

-- 
leif halvard silli