W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2017

Re: Mean character width for 16px Google Fonts (818 Families)

From: Laura Carlson <laura.lee.carlson@gmail.com>
Date: Wed, 31 May 2017 07:06:48 -0500
Message-ID: <CAOavpvfuFjk2G59xFOQwHvPo+eTekMPCR2KxKSjKW3o9pqj2Bg@mail.gmail.com>
To: Wayne Dick <wayneedick@gmail.com>
Cc: public-low-vision-a11y-tf <public-low-vision-a11y-tf@w3.org>, GLWAI Guidelines WG org <w3c-wai-gl@w3.org>
Hi Wayne,

Thank you for your email.

Since as your research indicates "591 out of 818 fonts won’t disrupt
layout more that changes in resolution, screen size and other
variables on the web", are you saying we do not or do not need the
letter spacing bullet in the Adapting text SC to accommodate for  when
a large font-family is selected via user style sheet?

Do you still recommend the current spacing metrics in the Adapting Text SC [1]?

* line spacing (leading) to at least 1.5
* letter spacing (tracking) to at least 0.12 em
* word spacing to at least 0.16 em

Thank you.

Kindest Regards,
Laura

[1] https://github.com/w3c/wcag21/issues/78

On 5/31/17, Wayne Dick <wayneedick@gmail.com> wrote:
>  *Font Width*
>
> Two important issues came up during the discussion of personalization to
> accommodate low vision. The first was line length. The group objected to
> character count as a measure. The second was related to font substitution.
> Would substitution of wide fonts disrupt layout severely. Since both are
> serious from the user perspective, I decided we needed some more
> understanding as to the distribution of font widths.
>
> The Google Web Fonts database provides 818 font families covering most
> categories of font. That seemed like a good starting point. I devised a
> method to measure average space taken by one character when it is laid out
> in a major browser. This is not the actual character width. It includes the
> average amount of space each character is allocated by the browser to
> separate it from other characters.
>
> For my sample character set I used the ASCII visible character sequence.
> That is characters 32 through 126. These are: (the space character, through
> lots of punctuation, the digits, the lower-case alphabet and the upper-case
> alphabet. I listed them in the order below:
>
> !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`
> abcdefghijk
> lmnopqrstuvwxyz{|}~
>
> I inserted the space between the ‘backward tick’ and the lower-case ‘a’ to
> avoid any trimming by user agents. To promote string breaking I placed a
> <wbr> between characters. That way the string could break anywhere. I call
> this the Typewriter Set (TS). It is the keys you see on a standard
> typewriter.
> *The Algorithm*
>
> Set font size to 16px. Place a TS in a paragraph element and give it a big
> width. I chose 1600px, but 2048 would be safer. To measure the length of
> the TS use a loop to decrease the width until the TS takes more than one
> line. That is the width of the TS, W. The average character width is W /
> (126-32)=W/94. I looped through the Google Font Families (regular variants)
> and obtained some interesting results.
>
> 1.      The width of TS varies among browsers.
>
> 2.     The average character width in Chrome is 8.313px
>
> 3.  The standard deviation is 1.4px
>
> 4.   If we take the average of character width / the mean width you get
> virtually 1. It is 1.000030982 precisely.
>
> 5.     591 font families lie within 1 sd from the mean (72%). That is close
> to 2/3 the expected number for a normal distribution. We would expect
> something pretty normal from a distribution of 818 averages.
>
> Settles a few things.  For example, counting characters is a very practical
> way to measure line length because fonts don’t vary that much. Also, 591
> out of 818 fonts won’t disrupt layout more that changes in resolution,
> screen size and other variables on the web. As far as needing to limit
> choices for low vision to a small set of fonts. Well 591 will do, just in
> the Google Font set.
>
> A complete font width table is at.
>
> http://nosetothepage.org/fontFamStatsChrome.html.
>
>
>
> Sincerely, Wayne
>
> On Tue, May 30, 2017 at 8:50 AM, Laura Carlson
> <laura.lee.carlson@gmail.com>
> wrote:
>
>> Hi Wayne,
>>
>> Thank you very much for doing this research. Based on this new
>> information, do you still consider the spacing metrics in the Adapting
>> Text SC [1] adequate for when a large font-family is selected and/or
>> increased spacing is applied to text? It currently is:
>>
>> * line spacing (leading) to at least 1.5
>> * letter spacing (tracking) to at least 0.12 em
>> * word spacing to at least 0.16 em
>>
>> Do we need to increase it or is it still okay?
>>
>> Thanks again.
>>
>> Kindest Regards,
>> Laura
>>
>> [1] https://github.com/w3c/wcag21/issues/78
>>
>> On 5/30/17, Wayne Dick <wayneedick@gmail.com> wrote:
>> > I did some calculations.
>> > It is pretty clear that the distribution of font width is pretty
>> > narrow.
>> > I have more data but here is the raw stuff without analysis.
>> >
>> > http://nosetothepage.org/fontFamStatsChrome.html
>> >
>> > Wayne
>> >
>>
>>
>> --
>> Laura L. Carlson
>>
>


-- 
Laura L. Carlson
Received on Wednesday, 31 May 2017 12:07:23 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 21:08:13 UTC