the advance of 'm' is a commonly used proxy for the design width of a
latin font.
But I agree it is also not really a great estimate once you consider any
international text.
Anyway I am not sure where you are headed with that and the
discussion of charWidth() or charWidths().
I am not trying to "fix the world" here, I am just removing a test
that it is pointless to maintain.
-phil.
On 4/29/20, 2:54 PM, Sergey Bylokhov wrote:
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?
