转换为图像时文本中的字符之间出现无法解释的间距
我已经使用带有 imagettftext 的系统一段时间了,向网站添加 nog 标准字体。几个月前,我为了更好的选择而放弃了这种方法,但我在一年多前创建的一个网站上遇到了问题。
该网站已转移到新服务器,除了稳定性问题和性能之外,该服务器还具有更新的 php 版本以及其他改进。 除了一个细节之外,这次搬迁很完美。从那时起,生成的图像文本按钮的所有出现都在特定字母之间具有间距。最值得注意的是 W 和 J。生成图像的脚本本身似乎没有错误,因为它是从头开始重建的,并且使用了其他程序员使用的几种实现。
不同的字体显示不同的结果,并且相当多的字体不显示问题。
现在,合乎逻辑的解决方案是切换到 cufon 甚至 fontface 等系统,但这两种解决方案都有两个主要缺点。
- 这样做非常耗时(实现 imagettftext 解决方案的低效方式是我停止使用它的原因之一)
- 该站点还有一个 html 时事通讯系统,显然它不支持这两种解决方案。
所以基本上我很困惑。我不太确定我应该从这里走向哪个方向,任何帮助将不胜感激。
I've been using a system with imagettftext for a while now to add nog standard fonts to websites. I've abandoned this method for better options a few months back but I've encountered a problem on one of the websites I've created over a year ago.
The website has been moved to a new server, aside from stability issues and performance the server also has a newer php version among other improvements.
The move went perfect except for a single detail. Since then all occurences of the generated image-text buttons have spacing between specific letters. Most notably W and J. The script generating the images itself is not at fault it seems, since it's been rebuilt from scratch as wel as having used several implementations used by other programmers.
Different fonts show different results and quite a few do not show the problem.
Now, the logical solution would be to switch to a system like cufon or even fontface, but both solution have two major drawbacks.
- It's enormously timeconsuming to do this ( the inefficient way of implementing the imagettftext solution is one of the reasons I stopped using it )
- The site also has a html newsletter system which obviously supports neither solution.
So basicly I'm stumped. I'm not really sure which direction I should be headed from here, and any help would be highly appreciated.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
这是一个字体问题。几千年来,印刷工作者一直在面对这个问题并解决它,甚至在活字印刷术发明之前,而且肯定在计算机发明之前。它甚至还有一个技术名称:称为字距调整。
这是一个经过充分研究和很好解决的问题。计算机字体的出现导致了更多可以应用自动字距调整的算法的发明。大多数情况下,它需要字体本身支持渲染器的“提示”。不幸的是,计算机的出现似乎也催生了懒惰的字体设计师:那些拥有工具但没有接受过培训的人。我所说的培训并不是指如何使用工具的培训,而是字体工匠艺术的培训:排版培训。与此同时,我们还看到设计糟糕的数字字体的兴起。
所以,问题不在于你的库、代码或编程语言,问题在于你使用了设计糟糕的字体。我建议简单地避免它们并为按钮使用设计更好的字体。如果您确实需要字体既美观又完美,那么可能是时候投资为屏幕设计的专业商业字体(为打印设计的字体不合适,而且可能更昂贵)。
很抱歉回答很长,但有时您只需要了解历史就可以知道您要解决的“真正”问题。
PS:我说渲染器不应该受到责备,但我有点撒谎,但这只是因为如果包括渲染器所扮演的角色,故事会变得更加复杂。
如果您以前的解决方案可以使用相同的字体,但在网络浏览器中出现字距调整错误,那么这是字体问题。您之前使用的渲染器很可能使用了自己的自动字距调整算法,该算法不依赖于字体提示,我知道 Gimp 可以做到这一点。
但是,如果它按原样在网络浏览器中工作(即简单地将字体属性设置为自定义字体),但在使用当前方法时中断,那么这是渲染器问题。 Web 浏览器使用操作系统提供的系统渲染器,该渲染器尊重字体提示。某些渲染器(例如 Adobe PhotoShop)只是不理解字体提示。
This is a Font problem. Typographers have been facing this problem and solving it for the past thousands of years, even before the invention of movable type and definitely before computers were invented. It even has a technical name: it's called kerning.
This is a well studied and well solved problem. The advent of computerized font led to the invention of many more algorithms that can apply automatic kerning. Mostly it requires the font itself to support "hints" to the renderer. Unfortunately, the advent of computers also seems to give rise to lazy font designers: those with the tools but not the training. By training I don't mean training on how to use the tools but training in the art of the font craftsman: training in typography. And with this we also see the rise of badly designed digital fonts.
So, the issue is not your library or code or programming language, the issue is that you are using badly designed fonts. I would advise to simply avoid them and use the better designed fonts for the buttons. If you really do need the font to be fancy but perfect at the same time then it may be time to invest in professionally made commercial fonts designed for the screen (fonts designed for print are not suitable and can be even more expensive).
Sorry for the long answer but sometimes you just need to know the history to know the "real" problem you're trying to solve.
PS: I said that the renderer is not to blame but I sort of lied, but only because the story gets much more complicated if you include the role played by the renderer.
If your previous solution works with the same fonts but you get bad kerning in a web browser then it's a font problem. The renderer you previously used most likely used its own auto-kerning algorithm that does not depend on font hinting, I know Gimp can do this.
But if it works in the web browser as-is (that is simply setting the font property to the custom font) but breaks when using your current method then it is a renderer problem. Web browsers use the system renderer provided by the operating system which respects font hints. Some renderers, Adobe PhotoShop for example, just don't understand font hints.
我意识到这是旧的并且已经标记为完成,但问题是 PHP 中的回归,而不是字体。我相当确定所有版本 > 5.2.9有这个问题。 imagettftext() 函数出现问题。
I realize this is old and already marked completed, but the problem is with a regression in PHP, not with the font. I'm fairly certain that all versions > 5.2.9 have this problem. Something wrong with the imagettftext() function.