UIFont 和变音符号
我正在编写一个 iPhone 应用程序，需要呈现 i18n 文本，其中包含 变音符号（波浪号、重音符号） ， ETC。）。 Apple 提供了 UIFont 类可用于获取给定字体/字体大小组合的前导、上升、下降等。
问题在于该信息不能准确反映变音符号。具体来说，大写字母上的变音符号通常会超过 lineHeight（UIFont 属性以前称为leading）。
整个框架都存在同样的问题，即。 NSString:sizeWithFont 也有同样的问题。
我需要知道文本的真实边界框，因为我使用的是 OpenGL，它不支持文本绘制，因此需要将文本渲染到纹理。
目前，我正在使用 hack 来解决这个问题。有更好的办法吗？
I'm writing a iPhone app that needs to render i18n text that includes diacriticals (tildes, accents, etc.). Apple provides the UIFont class which can be used to get a given typeface/font-size combination's leading, ascent, descent, etc.
The problem is that this information does not accurately reflect diacriticals. Specifically, diacriticals on capital letters often exceed the lineHeight (the UIFont property formerly known as leading).
The same problem exists throughout the frameworks, ie. NSString:sizeWithFont has the same issue.
I need to know the true bounding box for text as I am using OpenGL which does not have text drawing support and therefore requires rendering text to a texture.
Currently, I'm using a hack to get around this issue. Is there a better way?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
对于 NSString 来说这是不可能的，因为它只返回一个大小。您可以尝试 CoreText，它似乎支持返回边界框，但这有点矫枉过正。
当 Unicode 支持诸如 è̀̀̀（另见：zalgo）之类的内容时，这是一个难题；事物可以呈现在行的顶部上方，因此您不能只绘制字符。一些文本绘制 API 要求您指定基线并提供边界框，以便您可以获得上升部分和下降部分，但 UIKit 不会这样做。
然后，你就会看到疯狂的草书字体，偶尔会有巨大的上升部分。目前还不清楚如何处理这些。
懒惰的方法是渲染到顶部和底部有边距的纹理（0.5 行？1 行？），并且不太关心某些透明像素的额外开销。
我没怎么研究过 CoreText，但它看起来并不是特别有前途。
It's not possible with NSString, since it just returns a size. You can try CoreText which seems to support returning bounding boxes, but that's a bit overkill.
It's a difficult problem when Unicode supports things like è̀̀̀ (see also: zalgo); things can render above the top of a line so you can't just draw the characters. Some text-drawing APIs make you specify the baseline and give you the bounding box so you can get both ascenders and descenders, but UIKit doesn't do this.
Then, you have crazy cursive fonts with the occasional huge ascender. It's unclear how to handle these either.
The lazy way is to render to a texture with margins at the top and bottom (0.5 lines? 1 line?) and not care too much about the extra overhead of some transparent pixels.
I haven't looked at CoreText much, but it doesn't look particularly promising.