RFR: 8328896: Fontmetrics for large Fonts has zero width

[Tejesh R]

On Tue, 9 Apr 2024 18:50:17 GMT, Phil Race <prr at openjdk.org> wrote:

> The main problem here is that we do not curate what font point size we passed to freetype,
> and would pass in one larger than freetype's maximum of FT_USHORT_MAX which is USHRT_MAX.
> This isn't documented, SFAICS, and is checked a couple of calls deep from the specific API we use.
> But generally anywhere near that size seems to cause freetype to choke as it uses signed 16.16
> values, so 32767 is really the max.
> But we have no need to go anywhere near that - 16384 seems like a plenty large enough pt size.
> And we can request bigger sizes than that by making use of the transform.
> At normal size ranges we use that just to account for rotation and decompose the glyph transform
> into point size and that rotation.
> 
> But at large sizes - which are not usefully rendered anyway - there are no hints etc to be lost
> from not specifying the target point size. So we can extend the range of sizes we allow.
> 
> If  this is still too large to be held decomposed into a pt size in the range less than 16384 and a scale of up to 32766 then we substitute the null scaler, as we generally do when values are out of range, such
> a for a NaN transform.
> 
> These extreme values aren't useful.
> 
> In looking at this I did find that getGlyphPixelBounds doesn't follow the maximum image size we use
> for rendering. Which is not useful and could lead to inconsistent results. I fixed that.
> 
> Also whilst macOS didn't have these problems it could be cleaned up a bit for consistency in the reported sizes for some cases.
> 
> The test is mainly around making sure that "sensible" things are returned for not sensible input.
> There's no 100% right answer to these extreme unrenderable sizes.

LGTM.

-------------

Marked as reviewed by tr (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18703#pullrequestreview-2016218880