RE: Calculation Error

So I just had a Friday epiphany.  As long as you test with a browser that supports the CSS “calc” function and “ch” units, font adaption can be tested easily with a very simple and elegant style assignment to letter-spacing.

First, we pick the widest font we expect to reasonably adapt… let’s say Verdana for now.  We know 1ch is the width of the “0” character, so we convert that away from a width-dependent unit to about 0.6354em.  Now, the calculation “0.6354em – 1ch: would represent the extra width it would take to convert the author’s font to Verdana (e.g. it would be 0 if the author is already using Verdana, and about 0.021em using Arial).  We’d come up with a fudge factor to account for letter frequency (since all zeroes is obviously not the norm) and word length (since letter spacing is only applied between characters), and then you could have the simple CSS assignment:

Letter-spacing: calc(0.045em + fudgeFactor * (0.6354em – 1ch));

We’d still need to internationalize this and somehow apply to PDF, etc., but seems feasible to me.  A minor hiccup might also be when the author‘s font is already wider than Verdana which may result in a negative letter-spacing, which I think browsers handle differently.

Wayne,
I’m having a really tough time figuring out how you derived this equation:
(1+letterSpacing)*(1+(1/5)wordSpacing)

Why is 1em factoring into a width calculation?  Why would word and letter spacing be multiplied together?  I don’t think this is correct.

Steve

From: Repsher, Stephen J
Sent: Friday, June 09, 2017 1:17 PM
To: Alastair Campbell <acampbell@nomensa.com>; Wayne Dick <wayneedick@gmail.com>; public-low-vision-a11y-tf <public-low-vision-a11y-tf@w3.org>
Subject: RE: Calculation Error

I don’t see any need to try to squash word spacing into equivalent letter spacing.  They are both easy to test and having values in the normative standard directly based on empirical evidence of readability has a lot of value.  Moreover, we shouldn’t make assumptions that the number of words will always be much less than the number of letters.

I also think that using a percentage increase factor as a guide is fine, but (a) we need to be careful about the algebra and (b) we need to keep in mind that large variances can occur given the characters use.  For example, factors for the sentences “Wayne has eyes” and “Jill is ill” should be quite different.

I tried to be thorough about the algebra in my GitHub comment<https://github.com/w3c/wcag21/issues/78#issuecomment-306992047>, which I’ll dumb down just to the final equation for space taken up per letter here:

spacePerLetter = avgLetterWidth + letterSpacing + (0.25em + wordSpacing - letterSpacing)*(numWords - 1)/numLetters

The default word spacing of 0.25em enters the equation, and this assumes of course that we can simplify the width of a letter to the averages computed by Wayne for a given font.  So, according to Wayne’s table, a typical font like Open Sans, Noto Sans, or similar have widths of about 8.6px (or 0.54em).

Next, we’ll assume the words-to-letters ratio is typical of Alastair’s example sentence, which has 49 letters and 8 words, so the final factor is 7/49 = 1/7.  (Note this is similar to Wayne’s use of 5em.)

Using this equation, the original space with no extra letter or word spacing would be:
0.54 + 0.25/7 = 0.576em

And with 0.045 letter and 0.16 word spacing (same font):
0.54 + 0.045 + (0.25 + 0.16 – 0.045)/7 = 0.637em

That’s about an 11% increase, which is different from Alastair’s 15% result because it doesn’t take into account the actual width of each letter in his sentence (or my math is just wrong ;)).

If we really want to get font in the success criterion somehow, either directly or indirectly, then we need to apply letter frequency analysis<https://en.wikipedia.org/wiki/Letter_frequency> first to get a more accurate picture of font width in practice.  The difference in frequency between the most and least common letters (at least in English) is quite extreme.

Steve

From: Alastair Campbell [mailto:acampbell@nomensa.com]
Sent: Friday, June 09, 2017 5:39 AM
To: Wayne Dick <wayneedick@gmail.com<mailto:wayneedick@gmail.com>>; public-low-vision-a11y-tf <public-low-vision-a11y-tf@w3.org<mailto:public-low-vision-a11y-tf@w3.org>>
Subject: Re: Calculation Error

Ah, that’s great, we can get a useful result without as big an impact as I thought it might be.

I suggest two actions:

1.  We try to come to one measure for horizontal space increase.

2.  We use Wayne’s calculations (or a summary of) in the understanding doc to show the justification.

Wayne, we’re looking to come up with a total increase from possible letter space, font-family substitution and word spacing.

So if letter spacing is 0.045em, and word spacing is 0.16em, that makes a roughly 15% increase in width on my test sentence:
https://alastairc.ac/tests/word-spacing.html (at the bottom).

If we used a letter-spacing only of 0.065em, that comes out at the same size horizontally. (Note tiny differences in letter-spacing make a big difference, word-spacing not so much.)

Would that letter-spacing value suffice?

Cheers,

-Alastair


From: Wayne Dick

Just in  case I made some more errors, here is my code.

http://nosetothepage.org/fontApps/src/HTML/

http://nosetothepage.org/fontApps/src/js/

The relevant files are:
For indivudula font family at a time
fontWidth.html
fontWidthX.js
famStatt.HTML
famStats.js
famWidth.js
GoogleFonts.js
Please check my work

Wayne


On Thu, Jun 8, 2017 at 3:46 PM, Wayne Dick <wayneedick@gmail.com<mailto:wayneedick@gmail.com>> wrote:
The empirical test I left off: I used my sample string unicode 32-126 and inserted  spaces every five characters. Then I set the letter spacing to 0.045 and word spacing to 0.16. Then I ran the test on Tahoma. I got that the average space taken by each character was 9.24px. Without the spaces  and with normal spacing I got an average of 8.6px. 9.20/8.6=1.074. Pretty close to the theoretical estimate.

On Thu, Jun 8, 2017 at 3:10 PM, Wayne Dick <wayneedick@gmail.com<mailto:wayneedick@gmail.com>> wrote:
When Alastair did his computations and got 150% enlargement that set off a red flag for me. I double checked Alastair's computations and he is right.
Letter spacing should change to 0.045em NOT 0.12em.

My mistake was in using the research percentages applied to whole letters, not the space between them as the researcher MacLiesh suggested. Thus, our letter spacing should be applied to the spacing between letters, not to letters. That is 0.12x0.25=.03em.  There was actually an improvement up to 0.24 of the space between letters. Then the improvement flattened. I did a linear interpolation from 0 to 0.24 when I got 0.12. I think in this case the research max 0.06em could make size problems for developers, but the min 0.03em is a little small from my personal experience, and the research plots in the MacLeish research. Thus, I recommend linear interpolation again to get 0.045em.
Word spacing is correct because it is applied to 1em, (a space character approximately). However when we compute the size increase due to word spacing we must divide by the average word size (language dependent (about 5 in English usage)).  So, to compute the effect of letter spacing on text length we should apply the following multiplication factor:
(1+letter-spacing)(1+(1/5)word-spacing)<= (1+0.045)(1+0.32)=1.07844<1.08.
Empirical Evidence: Let us look at an average font like Tahoma. The average character width is 8.69px including normal letter spacing.

Conclusion:
Word spacing should not change. Letter spacing should change from 0.12em to 0.045em.
Wayne