.NET DrawString() 改变图形比例时不同的文本布局
我正在使用简单的代码在指定的矩形内绘制文本。一切正常，除了有时文本布局会根据图形比例（通过 Graphics.ScaleTransform 方法设置）而有所不同。
很难用语言描述这个问题，所以请看一下示例 image
- ScaleTransform设置为 0.3 左右 - 文本适合指定矩形内的一行。
- ScaleTransform 设置为 0.6 左右 - 文本在最后一个单词之前换行。
在这两种情况下，它具有相同的字体、文本、布局矩形、StringFormatting 等。唯一改变的是规模。请注意，我不使用“字体缩放”！在这两种情况下，它甚至是相同的字体对象。未设置 StringFormatFlags。
我该如何解决这个问题？我不在乎文本是否会换行 - 我只需要一致性。无论规模大小，始终包裹或不包裹。怎么做呢？
I'm using simple code to draw text inside specified rectangle. Everything works fine, except that sometimes text layout is different depending on graphics scale (set via Graphics.ScaleTransform method).
It's hard to describe the issue in words, so take a look at example image
- ScaleTransform set to something around 0.3 - text fits in one line within specified rectangle.
- ScaleTransform set to something around 0.6 - text is wrapped before last word.
In both cases it's the same font, text, layout rectangle, StringFormatting and so on. The only thing that changes is the scale. Note that I do not use "font scaling"! In both cases IT IS even the same font object. No StringFormatFlags set.
How can I fix that? I don't care if text will be wrapped or not - I just need the consistency. Always wrapped or not, no matter the scale. How to do that?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
感谢 Hans 的线索，可能的解决方案是将 Graphics.TextRenderingHint 设置为 SingleBitPerPixel 或 SingleBitPerPixelGridFit - 它会有所帮助，渲染的文本看起来总是像第一个。但没有抗锯齿功能，文本看起来很丑（如第二个示例）。
不幸的是，这并不能解决我的问题，因为文本稍后会转换为 GraphicsPath，并且结果始终类似于示例图像中显示的第二个结果。但是，该问题有一个替代解决方案：首先将文本转换为 GraphicsPath，然后绘制它。
但是，存在一些可能的问题：
GraphicsPath，所以总体开销是最小的。
文本更改 - 但这仅当您在用户期间连续显示文本时才重要
像所见即所得应用程序中一样输入。
GraphicsPath必须是在文本输入期间每次击键时都会重新创建。这可能是一个
严重的性能瓶颈。确保测试目标
配置，因为您的里程可能会有所不同。
Graphics.SmoothingMode需要设置为AntiAlias（或HighQuality这是相同的）以获得平滑的曲线 - 另一件事是
可能会影响性能。
最有趣的部分是，将文本转换为
GraphicsPath的解决方案优于传统的Graphics.DrawString方法。 另请注意，字体本身是一个重要的因素因素 - 带有花式字母的更复杂的字体使用更多的曲线点，因此它们需要更多的 CPU 时间来绘制。在我的测试过程中，我注意到当字符串长度超过几千个字符时（i5 760 CPU，只有一个大的 GraphicsPath 需要绘制），速度明显变慢
Thanks to clues from Hans, the possible solution is to set
Graphics.TextRenderingHinttoSingleBitPerPixelorSingleBitPerPixelGridFit- it helps and rendered text looks always like the first one. But there is no anti aliasing and text looks ugly (like in second example).Unfortunately this does not solve my problem, because the text is later converted to
GraphicsPathand the result is always like the second one shown on example image. However, there is an alternative solution for that problem: converting text toGraphicsPathfirst and then drawing it.However there are some possible issues:
GraphicsPathis updated only when text changes,so overall overhead would be minimal.
text change - but this is important only if you are continuously displaying text during user
input like in WYSIWYG app. The
GraphicsPathwould have to berecreated on every keystroke during text input. This might be a
serious performance bottleneck. Make sure you test for a target
configuration as your mileage may vary.
Graphics.SmoothingModeneeds to be set toAntiAlias(orHighQualitywhich is the same) to get smooth curves - yet another thing that
might affect performance.
The most interesting part is that the solution with text converted to
GraphicsPathoutperforms traditionalGraphics.DrawStringmethod. Also note that the font itself is an important factor - more complex fonts with fancy-shaped letters uses more curve points hence they need more CPU time to draw.During my tests I've noticed visible slowdowns when strings were longer that few thousand chars (i5 760 CPU, only one large GraphicsPath to draw)