我正在尝试解决我正在开发的代码编辑器的问题，该问题仅在配备 Retina 显示屏的 Mac 上使用 OpenJDK 11 时出现。以下屏幕截图说明了该问题。顶部是 OpenJDK 11(AdoptOpenJDK 11.0.5 HotSpot)，底部是 JDK 8(我相信 Apple/Oracle JDK 8):
如您所见，OpenJDK 11 使字体变宽了。这是一个大问题，因为我正在使用 FontRenderContext#getStringBounds 来确定等宽列宽。使用默认的等宽字体(看起来像 Menlo)和字体大小 14，据报告每个字符前进 8 个像素，这正确对应于 JDK 8 渲染但不对应于 OpenJDK 11 渲染。更糟糕的是，在后一种情况下，我们似乎没有得到整数个像素，而是 8.5 个像素(第一个非注释行包含 38 个字符，在 JDK 8 上需要 38 * 8 * 2 = 608 个像素，但是在 OpenJDK 11 上约为 646 像素。
更奇怪的是，这个问题是使用Graphics2D#drawString渲染AttributedText实例引起的。如果我转换为纯文本，使用 g.setFont，OpenJDK 11 呈现完全像 JDK 8。所以它必须与呈现 AttributedCharacterIterator 的特定实现有关。
显然我不会因为这个错误而更改我的整个实现，所以我正在寻找解决方法(当然除了要求用户选择不同的字体之外)。也许有一些系统属性......？
编辑:经过一些进一步的调试 session 后，我可以看到差异来自 ExtendedTextSourceLabel#createGV 和更深层次的 SunLayoutEngine#layout然后调用 native 代码，尽管有相同的字体打击描述，但在 JDK 8 中，字形数据中的 _positions 被设置为整数，而在 OpenJDK 11 中，它们被设置为小数(以及实际上不是 0.5 的倍数，因此它似乎与我们在 Retina 显示屏上运行这一事实没有任何关系；不过，也许该字体由原生 macOS 字体支持)
最佳答案
This表明它取决于字体大小，而不取决于字体是“原生”字体还是捆绑字体:
这是类路径上的 Inconsolata .ttf，字体大小为 32。相比之下，字体大小为 33:
此处报告的字体提升，基于 FontRenderContext#getStringBounds，是 17.0——由灰色矩形可视化——但实际呈现稍微更窄。
关于java - 尽管关闭了小数宽度，但 OpenJDK 11 Swing 等宽字体在 macOS Retina 上呈现问题，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/59428963/