OK. Let's summarize:
There are some fonts where tmHeight is in fact 0. If Hin-Tak Leang is
correct, these may be Open-Source fonts possibly with proprietary
equivalents. Since I have hundreds of fonts installed on my system, it
is almost certain that I have one or more. Identifying which without
support in wine is a large task, not to be undertaken lightly.
Dmitry argues that this should not happen. Fine :-(. That's a Coulda,
Shoulda, Woulda argument. When it meets reality, it holds no water. It
is the reality that has to be dealt with.
The code in the 'sanity test' is too low quality. It throws divide by
zero exceptions. That is *not* acceptable. The patch I made leaves
that code practically unchanged and works around only the exception
problem. It is an absolutely minimalist change. It changes only what
is absolutely necessary. A better patch is possible, but it hides the
direct source of the problem (which makes the designation 'better'
debatable):
+ if ( font->aveWidth ) {
+ if ((font->aveWidth + font->potm->otmTextMetrics.tmHeight - 1) >
+ (font->potm->otmTextMetrics.tmHeight) * 100)) {
WARN("Ignoring too large font->aveWidth %d\n", font->aveWidth);
font->aveWidth = 0;
}
}
Either my original patch or this one *must* be applied to remove the
possibility of a divide by zero exception.
All discussion about what *SHOULD* be done when tmHeight is 0 is another
issue and has *NOTHING* directly to do with this patch. It is, however,
a significant question, and does need to be investigated. It probably
deserves a bugzilla entry, but it is *ANOTHER ISSUE*. As part of *THAT*
issue, I totally think the current 'conformance test' is inadequate and
needs expansion, but I am *NOT* the person to do that. *NOR* am I the
person who would be best at addressing *THAT* problem.
