- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 31 May 2017 10:40:36 +0100
- To: w3c-wai-gl@w3.org
Just wondering: as useful as this research is, is there a risk that this (and the related proposed SC) is going to cause issues of internationalisation (CJK fonts, arabic fonts, etc, as well as vertical text)? The proposed SC should cover these scenarios too, or at the very least mention them. P On 31/05/2017 07:42, Wayne Dick 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[\]^_` > abcdefghijklmnopqrstuvwxyz{|}~ > > 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.000030982precisely. > > 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 <mailto: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 > <https://github.com/w3c/wcag21/issues/78> > > On 5/30/17, Wayne Dick <wayneedick@gmail.com > <mailto: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 > <http://nosetothepage.org/fontFamStatsChrome.html> > > > > Wayne > > > > > -- > Laura L. Carlson > > -- Patrick H. Lauke www.splintered.co.uk | https://github.com/patrickhlauke http://flickr.com/photos/redux/ | http://redux.deviantart.com twitter: @patrick_h_lauke | skype: patrick_h_lauke
Received on Wednesday, 31 May 2017 09:41:11 UTC