将 Illustrator 或 pdf 文件处理为 XAML
将 illustrator 文件或 PDF 处理为 XAML 的替代方法有哪些。我当前的工作流程是这样的：
- 在 Adobe illustrator 中打开 PDF 文件
- 将文件另存为 .ai (Adobe Illustrator) 文件
- 在 Expression Design 中打开
- 进行一些处理，主要是将元素分离到图层并删除不需要的部分。
- 另存为 XAML
- 将 XAML 添加到 Blend 项目
我唯一的问题是，通过这种方式，文本会转换为路径。我想将文本保留在 XAML 中而不是路径中。
有没有其他方法可以做到这一点，所以我保留文本？还有其他工具吗？
What are the alternatives to process illustrator files or PDFs into XAML. My Current workflow works like this:
- Open the PDF file in Adobe illustrator
- Save the file as .ai (Adobe Illustrator) file
- Open in Expression Design
- Do some processing, mainly separating elements to layers and removing unneeded parts.
- Save as XAML
- Add XAML to Blend project
My only problem is that this way the text gets converted to paths. I would like to keep my text in XAML as well instead of paths.
Is there any other way to do this, so I keep the text? Any other tools?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我认为你想要的是拥有字形元素而不是路径。
问题是 Glyphs 元素要求您指定字体文件的 URI。此外，Glyphs 元素通过其索引将字形引用到字体文件中（生成 Glyphs 元素的转换器（例如 Microsoft XPS Document Writer）可能会使用字体子集文件中的索引：因此这些索引可能会不是原始字体文件中定义的相同字形的正确索引）。我已经能够使用自己的 PDF 到 XAML 转换工具以两种方式“解决”这个问题。
1.方法：在生成的 XAML 代码中嵌入 BASE64 编码的字体子集文件，并让应用程序实现一个类，该类在加载时将嵌入的字体子集文件提取和解码到临时位置，并提供有效的该临时文件的 URI 返回到 XAML 加载程序。
或者，2。方法：大多数字体文件已与我的应用程序一起安装，并且再次由我的应用程序添加一些支持，在加载 XAML 代码时将字体名称替换为已安装字体文件的 URI。第二种方法的问题是字形索引需要正确映射到已安装的字体文件，这可能并不是那么简单。 （您可以在我的博客上找到针对这种加载方式生成的示例文件的链接：特别是查看文件 truncatedcone-xaml.txt)
简而言之：这两种解决方案都需要特殊的 PDF 到 XAML 转换器以及加载应用程序的支持。我想这样做而不是仅仅将 PDF 转换为路径的原因是我的应用程序是共享白板：因此我希望我的矢量图形尽可能小。 （在大多数情况下，转换为路径往往会使 XAML 代码膨胀 10 倍或更多）。
我正在考虑实施第三种方法：这包括为每个仅使用一次的字形生成轮廓，然后添加我的应用程序对转换和定位的支持这些字形轮廓的方式与必须生成的字形元素的作用非常相似。优点是生成的 XAML 仍然相对较小（与上述第二种方法相比），无需将相关字体文件与应用程序一起安装，也无需将字形索引从子集文件映射到已安装的字体文件。我还没有尝试认真实施这一点的原因有两个：首先，我当前的（第二种）方法已经非常适合我当前的需要；其次，第三种方法在加载和/或渲染方面可能存在性能问题。
I think what you want is to have Glyphs elements instead of Paths.
The problem is that Glyphs elements require you to specify the URI of the font file. Also, Glyphs elements reference glyphs by their index into a font file (it may happen that a converter that generates Glyphs elements - like the Microsoft XPS Document Writer - uses indices into font subset files: so these indices may not be the right indices to the same glyphs as defined in the original font file). I have been able to "solve" this problem in two ways with my own PDF to XAML conversion tools.
1. approach: Embed the font-subset file, BASE64 coded, in the generated XAML code and have the application implement a class that, upon loading, extracts and decodes an embedded font-subset file to a temporary location and hands a valid URI to that temporary file back to the XAML loader.
or, 2. approach: Have most font files already installed along with my application and, again, adding some support by my application that replaces the font name by an URI to the installed font file upon loading of the XAML code. The problem with this second approach is that glyph indices need to be correctly mapped to the installed font file, which may not be all that trivial to do. (You can find a link to an example file that has been generated for this way of loading on my blog: in particular take a peek at the file truncatedcone-xaml.txt)
In short: both solutions require a special PDF to XAML converter and support by the loading application. The reason I wanted to do it this way instead of just having my PDFs converted to Paths only is that my application is a shared whiteboard: thus I want my vector graphics to be as small as possible. (Conversion to paths tends to blow up the XAML code by a factor of 10 or more in most cases).
I am contemplating the implementation of a third approach: this would consist in generating the outline for every glyph that is used only once and then add support by my application to transform and position these glyph outlines in a way closely analogous to what Glyphs elements do that would otherwise have to be generated. The advantage would be that the generated XAML would still be relatively small (comparable to the second approach described above) without requiring the relevant font files to be installed along with the application and without having to map glyph indices from a subset file to the installed font file. The reason I have not yet tried to implement this in earnest is twofold: first, my current (second) approach already works very well for what I currently need; second, there might be performance problems with this third approach as reagards loading and / or rendering.
有一个（免费）Adobe Illustrator 插件可以导出到 XAML。但不确定它是否完全符合您的要求。
可以在 http://www.mikeswanson.com/XAMLExport/ 找到它
There's a (free) Adobe Illustrator plugin to export to XAML. Not sure it does exactly what you are looking for, though.
Find it at http://www.mikeswanson.com/XAMLExport/
XPS 文件实际上是一个 ZIP 文件。因此，如果您使用 ZIP 存档器打开它，或者将其扩展名重命名为 ZIP，您就可以看到里面的内容。它已包含 XAML 代码形式的页面（这些文件的格式为 [pagenumber].fpage）。但是，该 XAML 代码可能引用该 ZIP 存档中也包含的其他文件（例如光栅图像和字体子集文件，这些文件通常是 odttf 文件 - 基本上是加密的真实类型文件）。这意味着，您在 XPS 文档中找到的 XAML 代码可能无法在您的应用程序中直接用作纯 XAML。我编写了 python 脚本来转换从 XPS 文档（由 Microsoft XPS Document Writer 生成）中获取的 XAML，以获得我的应用程序可以加载的 XAML 文件（请参阅上面的方法 1 和 2）。我可以向您发送这些 python 脚本的副本（它们不是特别出色的代码，但这对我来说没有问题，因为我现在使用不同的方法将 PDF 转换为 XAML）。
Well an XPS file is actually a ZIP file. So if you open it with a ZIP-archiver or if you rename its extension to ZIP you can see what is inside. It already contains the pages as XAML code (those files have the form [pagenumber].fpage). However, that XAML code may refer to other files (like raster images and font subset files, those are typically odttf files - basically encrypted true type files) that are included in that ZIP archive as well. Which means, that the XAML code that you find in an XPS document may not be directly usable as pure XAML in your application. I have written python scripts to do the conversion of XAML taken from XPS documents (generated by the Microsoft XPS Document Writer) to get XAML files that my application can load (see approaches 1 and 2 above). I could send you copies of those python scripts (they are not particularly great code, which is no problem for me since I am now using a different approach to convert PDFs to XAML anyway).
@gyurisc：保留字体文件应该可行，但保留文本可能会成为一个问题，因为，你看，字形不是字符。您可能可以通过检查给定字形所属的字体文件来找出字符，但这将涉及解析字体文件。如果您不幸运，您的 PDF 到 XPS 转换器甚至没有在字体子集文件中保留足够的信息来找出给定字形（很可能）代表的字符。
例如：如果我在 Microsoft 的 XPS Document Writer 的帮助下将 PDF 文件转换为 XPS，然后尝试从该 XPS 文档中选择一段文本，我可以（只是表面上）将其复制到剪贴板。但是，如果我随后将其粘贴回 Word 文档，则会得到垃圾。然而，如果我选择原始 PDF 文档中的相同文本并将其粘贴到同一个 Word 文档中，我会得到相当有意义的文本。因此，微软的 XPS Document Writer 显然并不关心将“字形运行”解释为文本，因此在我看来，在生成的 XPS 代码中找到的字形索引与它们所代表的字符之间的联系很可能是存在的代表在这一点上已经被打破了。 （但是，不可否认，这只是一个猜测。）
我认为，文本 的表示（而不是一系列字形）将是 XAML 中的 TextBlock 元素。然而，我的猜测是，典型的 PDF 到 XPS 转换器不太可能生成 TextBlock 元素。 XPS 主要用于渲染 - 在屏幕上或纸上 - 它并不建议自己作为一种特别适合数据交换（在您的情况下交换文本）的文件格式。
@gyurisc: Keeping the font file should work but keeping the text might turn out to be a problem, because, you see, glyphs are not characters. It might be that you could figure out the character by examining the font file that a given glyph is part of, but that would involve parsing the font file. If you are unlucky, your PDF to XPS converter does even not keep enough information in the font subset files to figure out the character a given glyph (very likely) represents.
For example: If I convert a PDF file to XPS with the help of Microsoft's XPS Document Writer, and then try to select a piece of text from that XPS document, I can (only apparently) copy it to the clipboard. However, if I then paste it back into a Word document, I get garbage. Whereas if I select that same piece of text in the original PDF document and paste it into the same Word document, I get reasonably meaningful text. So Microsoft's XPS Document Writer apparently does not care about the interpretation of a "glyph run" as text, and thus it seems very likely to me that the link between the glyph indices that one finds in the generated XPS code and the characters they are meant to represent is already broken at that point. (But, admittedly, that's just a guess.)
A representation of text (as opposed to a run of glyphs) would be a TextBlock element in XAML, I suppose. However, my guess is that a typical PDF to XPS converter is unlikely to generate TextBlock elements. XPS is mainly meant to be rendered - on screen or on paper - it doesn't suggest itself as a file format that is particularly suitable for data exchange (exchange of text in your case).