On 28/12/14 18:12, Lea Verou wrote: > The font matching algorithm outlined in [1] results in cases of very > odd matching when it comes to missing font weights and it should be > changed. For example, if the requested font weight is 100 (extra > light) and only 900 is available (which is black) or vice versa, this > one will be used instead of falling back to the next family in the > font stack. When the difference between desired and available weights > is so dramatic, falling back would be a more appropriate choice in > most cases. > > This issue was brought to my attention when a colleague sent me [2], > asking why the different behavior between Firefox & Chrome. Upon > further investigation, it appeared that he only had UltraBold for > Gill Sans and Chrome used that for all weights to avoid falling back > to Gill Sans MT. One would expect that Chrome’s behavior is the buggy > one here, but according to the existing algorithm [2], Chrome is > perfectly correct and Firefox is buggy! There's considerable discussion of this case in the bug that introduced this behavior in Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=551313 JKReceived on Sunday, 28 December 2014 21:43:42 UTC
This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:49 UTC