What can you do about a fail in Microsoft Font Validator "AvgCharWidth"

[EbenSorkin]

Observed behaviour

I get this MS-FonVal: The xAvgCharWidth field does not equal the calculated value DETAILS: actual = 541, calc = 548

Expected behaviour

I am not sure what I expect instead but I would like suggestions about how to address this either here or ideally in the tool because I don't see a way to deal with it in Glyphs. It might be the naswer is use font forge or FL5? Is it?

Resources and exact process needed to replicate

Here is a file to test with
Aplos-Regular.ttf.zip

[m4rc1e]

I hate these avg width tests as well. I've written about them here #1622.

Imo, I only really care about the glyf checks in Ms Validator. Can we just check this table using Ms Val's table param? mono FontValidator -file font.ttf -table 'glyf' -reportdir ~/Desktop

After Rubikgate, I check font rendering using Browserstack.

It may be worthwhile for us to review all the checks Ms Val offers.

[felipesanches]

It may be worthwhile for us to review all the checks Ms Val offers.

There's a task for that: issue #1541

[davelab6]

I agree that to solve this we should change the way we call msfontval to only check the glyf table, and then revisit the checks it offers one by one.

[felipesanches]

My vague understanding of the xAvgAdvanceWidth value is that it might be used for font substitution algorithms by estimating how much space some arbitrary text may take on screen/paper and then comparing this value with all other available fonts' xAvg values to decide which other font would have the same effect in terms of image buffer area usage.

The description above is my interpretation after hunting down the historical origins of this field. I found no place online (neither at O'Reilley's "Fonts & Encodings" book by Yannis Haralambous) where I could get a straight & precise description of the actual usage of the value. All I could found was vague descriptions followed by somewhat precise specs on how to compute it. But I got no real answer to the "why" question.

The way this is computed may involve a weigthed sum. And I guess this is an attempt to shape the value into something meaningful when comparing text written in some language, by means of weigthing the sum with the frequencies of occurences of each letter in that given language.

Since nowadays the world is pretty much biased towards english (and this bias is specially pronounced in technology, unfortunately) I would guess that the frequency weigths used in the opentype spec were originally computed based on some reference english text, making it completely useless for font substitution in any other language.

I spent some time looking up the freetype codebase to see where xAvgAdvanceWidth is used. The codebase is big and so I am not sure (it would require some more time to have a definite answer), but I had the impression that even though the value is parsed and used in computing a "width" property of font strikes of all of the available fixed sizes, this same width property does not seem to be actually used anywhere else. But, again, I may be wrong about it. Might be easier to ask the freetype devs.

I obviously lack access to the sources of Mac and Windows font engines, but I wonder if anyone knows if this is actually used somewhere...

[felipesanches]

It might also be used on the application level, but it seems to me that font substitution is very much font-engine business.

[davelab6]

Werner at freetype says, " IIRC, it's related to some ancient Windows 3.0 API."

[felipesanches]

Sounds like we should forget about it then! Should this lead to a deprecation? Or is this check useful at all nowadays?

[davelab6]

The msfontval one we can forget about as Marc and I have suggested above :)

[EbenSorkin]

Thanks!

[HinTak]

This was perhaps fixed post 2.1
. See HinTak/Font-Validator#33

[EbenSorkin]

Fixed as in Font Bakery no longer throws what might be considered a false error? I was also wondering if anyone knows what tool if any let's you directly edit that data.

…

-e.

On Mon, Jul 30, 2018 at 8:12 AM HinTak ***@***.***> wrote: This was perhaps fixed post 2.1 . See HinTak/Font-Validator#33 <HinTak/Font-Validator#33> — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1894 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACFIXT-0IOaeyot-SbuxpoRKG0_vwqiEks5uLvgngaJpZM4USNVb> .

[felipesanches]

A coupe weeks ago I made a change to the FVAL check on Font Bakery so that it overrides a feel FAILs to be treated / reported as simply WARNs:

https://github.com/googlefonts/fontbakery/pull/1975/files

[felipesanches]

This change will be included in the upcoming 0.5.0 release.Or you can already benefit from it in case you're running Font Bakery directly from git sources.