处理插画家或PDF文件中的XAML

Question

将Illustrator文件或PDF处理到XAML中的替代方案是什么？我当前的工作流像这样工作：

1. 在Adobe Illustrator中打开PDF文件
2. 将文件保存为.ai（Adobe Illustrator）文件
3. 在表达设计中开放
4. 进行一些处理，主要是将元素分开到层和去除不需要的零件。
5. 另存为XAML
6. 将XAML添加到混合项目中

我唯一的问题是，这种方式将文本转换为路径。我也想将我的文本保留在XAML中而不是路径中。

还有其他方法可以这样做，所以我保留文字？还有其他工具吗？

Answer 1

有一个（免费的）Adobe Illustrator插件将导出到XAML。不确定它确实可以做到您要寻找的东西。

找到它 http://www.mikeswanson.com/xamlexport/

Answer 2

我认为您想要的是拥有字形元素而不是路径。问题是字形元素要求您指定字体文件的URI。另外，字形元素通过其参考字形 指数 进入字体文件（可能会发生生成字形元素的转换器（例如Microsoft XPS Document Writer）在字体子集文件中使用索引：因此，这些索引可能不是原始字体文件中定义的同一glyphs的正确索引）。我已经能够用自己的PDF到XAML转换工具以两种方式“解决”这个问题。

1.方法: ：嵌入了Font-subset文件，Base64编码，在生成的XAML代码中，并使应用程序实现一个类，该类在加载后提取并解码嵌入式Font-Subset文件到临时位置，并将有效的URI交给该临时文件返回XAML加载程序。

或者， 2.方法: ：将大多数字体文件与我的应用程序一起安装，并再次通过我的应用程序添加一些支持，该应用程序在加载XAML代码时将URI替换为已安装的字体文件的字体名称。第二种方法的问题是，必须正确映射字形索引到已安装的字体文件，这可能并不是那么琐碎。 （您可以在我的博客上找到已为这种加载方式生成的示例文件的链接：特别是窥视文件 truncatedCone-XAML.TXT)

简而言之：两种解决方案都需要特殊的PDF到XAML转换器，并通过加载应用程序支持。我想这样做的原因，而不仅仅是让我的PDF转换为路径，这是我的应用程序是一个共享的白板：因此，我希望我的矢量图形为 尽可能小. 。 （在大多数情况下，转换为路径往往会炸毁XAML代码10倍或更多）。

我正在考虑实施 第三种方法: ：这将包括生成每个使用的字形的大纲 只有一次 然后，通过我的应用程序增加支持，以转换和定位这些字形轮廓，以与诸如字形元素相似的方式，否则必须生成。优势是，生成的XAML仍然相对较小（与上述第二种方法相当），而无需与应用程序一起安装相关的字体文件，而无需将glyph索引从子集文件映射到已安装的字体文件。我尚未尝试认真实施这一点的原因是双重的：首先，我当前的（第二种）方法已经非常适合我目前的需求；其次，将第三种方法作为试剂加载和 /或渲染可能存在性能问题。

Answer 3

XPS文件实际上是一个zip文件。因此，如果您使用zip-arkiver打开它，或者将其命名为zip，则可以看到内部的内容。它已经包含页面作为XAML代码（这些文件具有[Pagenumber] .fpage的表单）。但是，XAML代码可以参考其他文件（例如栅格图像和字体子集文件，这些文件通常是ODTTF文件 - 基本上是加密的true Type文件），也包含在该ZIP档案中。这意味着，您在XPS文档中找到的XAML代码可能无法直接用作应用程序中的纯XAML。我已经编写了Python脚本来进行XAML从XPS文档（由Microsoft XPS Document Writer生成）获取的XAML，以获取我的应用程序可以加载的XAML文件（请参阅上面的方法1和2）。我可以将这些Python脚本的副本发送给您（它们不是特别好的代码，这对我来说没问题，因为我现在使用其他方法将PDF转换为XAML）。

Answer 4

@GyUrisc：保持字体文件应起作用，但要保留 文本 可能结果是一个问题，因为您看到， 字形不是字符. 。可能是您可以通过检查给定的字形是一部分的字体文件来找出字符，但这将涉及解析字体文件。如果您不幸，您的PDF到XPS转换器甚至不会在字体子集文件中保留足够的信息来找出给定的字形（很可能）代表的字符。

例如：如果我在Microsoft的XPS文档作者的帮助下将PDF文件转换为XPS，然后尝试从该XPS文档中选择一段文本，我可以（显然）将其复制到剪贴板上。但是，如果我然后将其粘贴到Word文档中，我会得到垃圾。而如果我选择 相同的 原始PDF文档中的文本并将其粘贴到同一Word文档中，我得到了有意义的文本。因此，Microsoft的XPS文档作者显然不在乎对“字形运行”作为文本的解释，因此，在我看来，人们很可能在生成的XPS代码中找到的Glyph索引之间的链接及其意思是他们所意味着的字符在这一点上代表已经打破了。 （但是，诚然，这只是一个猜测。）

代表 文本 （与文盲相反）我想是XAML中的文本块元素。但是，我的猜测是，典型的PDF到XPS转换器不太可能生成文本块元素。 XPS主要是要渲染的 - 在屏幕或纸上 - 它并不是将自己作为一个特别适合数据交换的文件格式（在您的情况下进行文本交换）。