iTextSharp 国际文本
我在 asp.net 页面中有一个表格,并尝试将其导出为 PDF 文件,我有几个国际字符未显示在生成的 PDF 文件中,请提供任何建议,
提前致谢
I have a table in asp.net page,and trying to export it as a PDF file,I have couple of international characters that are not shown in generated PDF file,any suggestions,
Thanks in advance
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
正确显示替代字符集(俄语、中文、日语等)的关键是在创建 BaseFont 时使用 IDENTITY_H 编码。
IDENTITY_H 为您选择的字体提供 unicode 支持,因此您应该能够显示几乎任何字符。我用它来表示俄语、希腊语和所有不同的欧洲语言字母。
编辑 - 2013 年 5 月 28 日
这也适用于 iTextSharp v5.0.2。
编辑 - 2015 年 6 月 23 日
下面给出的是完整的代码示例(C# 语言):
这是创建的 pdf 文件的屏幕截图:
要记住的重要一点是,如果您选择的字体不支持您尝试发送到 pdf 文件的字符,则您在 iTextSharp 中执行的任何操作都不会起作用改变这一点。 Verdana 很好地显示了我所知道的所有欧洲字体中的字符。
其他字体可能无法显示那么多字符。
The key for proper display of alternate characters sets (Russian, Chinese, Japanese, etc.) is to use IDENTITY_H encoding when creating the BaseFont.
IDENTITY_H provides unicode support for your chosen font, so you should be able to display pretty much any character. I've used it for Russian, Greek, and all the different European language letters.
EDIT - 2013-May-28
This also works for v5.0.2 of iTextSharp.
EDIT - 2015-June-23
Given below is a complete code sample (in C#):
This is a screenshot of the pdf file that is created:
An important point to remember is that if the font you have chosen does not support the characters you are trying to send to the pdf file, nothing you do in iTextSharp is going to change that. Verdana nicely displays the characters from all the European fonts I know of.
Other fonts may not be able to display as many characters.
未呈现字符有两个潜在原因:
这是要求嵌入子集的另一个充分理由。因为想要添加几个中文字形而增加几兆字节有点陡峭。
如果您感到偏执,您可以使用
myBaseFont.charExists(someChar)
根据给定的 BaseFont 实例(我相信这也考虑了编码)检查您的字符串。如果你有一个你有信心的字体,我不会打扰。PS:Identity-H 需要嵌入子集还有另一个很好的理由。 Identity-H 从内容流中读取字节作为字形索引。一种字体与另一种字体的字形顺序可能会有很大差异,甚至同一字体的不同版本之间也会有很大差异。依赖查看器系统拥有完全相同的字体是一个坏主意,因此它是非法的......特别是当 Acrobat/Reader 开始替换字体时,因为它无法找到您要求的确切字体并且您没有嵌入它。
There are two potential reasons characters aren't rendered:
That's another good reason to require embedding SUBSETS. Tacking on a few megabytes because you wanted to add a couple Chinese glyphs is a bit steep.
If you're feeling paranoid, you can check your strings against a given BaseFont instance (which I believe takes the encoding into account as well) with
myBaseFont.charExists(someChar)
. If you have a font you're confident in, I wouldn't bother.PS: There's another good reason that Identity-H requires an embedded subset. Identity-H reads the bytes from the content stream as Glyph Indexes. The order of glyphs can vary wildly from one font to the next, or even between versions of the same font. Relying on a viewers system to have the EXACT same font is a bad idea, so its illegal... particularly when Acrobat/Reader starts substituting fonts because it couldn't find the exact font you asked for and you didn't embed it.
您可以尝试设置您正在使用的字体的编码。在 Java 中会是这样的:
其中 BaseFont.CP1252 是编码。尝试搜索要显示的字符所需的确切编码。
You can try setting the encoding for the font you are using. In Java would be something like this:
where the BaseFont.CP1252 is the encoding. Try to search for the exact encoding you need for the characters to be displayed.
这是由默认的 iTextSharp 字体 - Helvetica - 引起的,它不支持除基本字符之外的其他字符(或不支持所有其他字符)。
实际上有 2 个选项:
It caused by default iTextSharp font - Helvetica - that does not support other than base characters (or not support all other characters.
There are actually 2 options: