On 4/29/20 2:33 pm, Philip Race wrote:
Now that is another topic and unrelated to max advance
I think a spec update and CSR would be required for getWidths()
and I'd still say this test is not worth it.
Probably yes, because it is currently states that "Gets the advance
widths of the first 256 characters " and it is bizarre that the
getMaxAdvance() may return smaller size even for the simple char's.
Currently ina few places we have code like this:
columnWidth = metrics.charWidth('m');
Which is far than optimal, and getMaxAdvance() should fit better than
the size of the "m"(or 'w'), but seems this method and its current
implementation is completely useless.
-phil
On 4/29/20, 2:21 PM, Sergey Bylokhov wrote:
On 4/28/20 4:28 pm, Philip Race wrote:
And max advance is NOT only about the advance of the first 256 characters anyway
Yes but it makes it a little bit more useful, it least it will always return
correct max
advance for the first characters.
Actually I'll argue it can be the opposite.
Doing this you ask it to go check in fallback fonts and in the failure I
analysed on macos we got a fallback from a CJK font for an unprintable
character.
Now whilst that may make it "more likely" if we include that in the maxadvance
and care only about chars 0-255 it will pass, you've now got a very different
max
advance returned than is the design centre for the primary font and REAL uses
of chars 0-255 which would never try to display char 132 etc.
Then probably we could skip any unprintable characters?
--
Best regards, Sergey.
