Re: Calculation Error

​
​Let me recalculate this. It may be ​off.


On Fri, Jun 9, 2017 at 12:21 PM, Repsher, Stephen J <
stephen.j.repsher@boeing.com> wrote:

> 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
> <acampbell@nomensa.com>]
> *Sent:* Friday, June 09, 2017 5:39 AM
> *To:* Wayne Dick <wayneedick@gmail.com>; public-low-vision-a11y-tf <
> 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> 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> 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
>
>
>
>
>
>
>
>
>
>
>

Received on Saturday, 10 June 2017 00:09:40 UTC