IllustratorまたはPDFファイルをXAMLに処理します

Question

IllustratorファイルまたはPDFをXAMLに処理するための代替案は何ですか。私の現在のワークフローは次のように機能します：

1. Adobe IllustratorでPDFファイルを開きます
2. ファイルを.ai（Adobe Illustrator）ファイルとして保存します
3. 式デザインで開いています
4. いくつかの処理を行い、主に要素をレイヤーに分離し、不必要な部品を削除します。
5. xamlとして保存します
6. XAMLを追加してプロジェクトをブレンドします

私の唯一の問題は、このようにテキストがパスに変換されることです。パスの代わりにテキストをXAMLに保持したいと思います。

これを行う他の方法はありますか、私はテキストを保持していますか？他のツールはありますか？

Answer 1

XAMLにエクスポートする（無料の）Adobe Illustratorプラグインがあります。しかし、それがあなたが探していることを正確に行うかどうかはわかりません。

で見つけてください http://www.mikeswanson.com/xamlexport/

Answer 2

あなたが望むのは、パスの代わりにグリフ要素を持つことだと思います。問題は、Glyphs要素がフォントファイルのURIを指定する必要があることです。また、グリフ要素はグリフを参照しています 索引 フォントファイルへ）。自分のPDFからXAML変換ツールでこの問題を2つの方法で「解決」することができました。

1.アプローチ: ：生成されたXAMLコードにFont-Subsetファイル、Base64 Codededを埋め込み、アプリケーションに埋め込み、抽出時に埋め込まれたフォントサブセットファイルを一時的な場所に抽出し、デコードし、その一時ファイルに有効なURIを渡すクラスを実装するようにします。 XAMLローダーに戻ります。

また、 2.アプローチ: ：私のアプリケーションと一緒にほとんどのフォントファイルが既にインストールされており、再び、XAMLコードを読み込んだときにインストールされたフォントファイルにフォント名をURIで置き換えるアプリケーションによるサポートを追加します。この2番目のアプローチの問題は、グリフインデックスをインストールされたフォントファイルに正しくマッピングする必要があることです。これは、それほど些細なことではないかもしれません。 （私のブログでこのロードのために生成された例ファイルへのリンクを見つけることができます：特にファイルを覗いてみる TruncatedCone-Xaml.txt)

要するに、どちらのソリューションでも、XAMLコンバーターからXAMLコンバーターへの特別なPDFと、ロードアプリケーションによるサポートが必要です。 PDFSをパスに変換するだけでなく、この方法でやりたかったのは、アプリケーションが共有ホワイトボードであることです。 可能な限り小さい. 。 （パスへの変換は、ほとんどの場合、XAMLコードを10倍以上爆破する傾向があります）。

私はaの実装を検討しています 3番目のアプローチ: ：これは、使用されるすべてのグリフのアウトラインを生成することで構成されます 1回だけ そして、私のアプリケーションでサポートを追加して、これらのグリフの概要を変換して配置し、他の方法では生成する必要があるGlyphs要素に密接に類似しています。利点は、生成されたXAMLが、アプリケーションとともに関連するフォントファイルをインストールする必要なく、サブセットファイルからインストールされたフォントにGlyphインデックスをマッピングすることなく、比較的小さく（上記の2番目のアプローチに匹敵する）ことです。ファイル。私がまだこれを本格的に実装しようとしていない理由は2つあります。1つ目は、私の現在の（2番目の）アプローチがすでに必要なものに非常にうまく機能しています。第二に、この3番目のアプローチには、荷重やレンダリングを再獲得する際のパフォーマンスの問題があるかもしれません。

Answer 3

さて、XPSファイルは実際にはzipファイルです。したがって、zip-archiverで開く場合、またはその拡張機能をzipに変更した場合、内部が何があるかを確認できます。 XAMLコードとしてのページが既に含まれています（これらのファイルには[pageNumber] .fpageフォームがあります）。ただし、XAMLコードは、他のファイル（ラスター画像やフォントサブセットファイルなど、通常はodttfファイル（基本的に暗号化された真のタイプファイル）を参照する場合があります。つまり、XPSドキュメントで見つけたXAMLコードは、アプリケーションで純粋なXAMLとして直接使用できない場合があります。 XPSドキュメント（Microsoft XPS Document Writerによって生成されたXAMLの変換を行うために、アプリケーションがロードできるXAMLファイルを取得するためのPythonスクリプトを作成しました（上記のアプローチ1と2を参照）。これらのPythonスクリプトのコピーを送信できます（特に優れたコードではありません。これは、とにかくPDFをXAMLに変換するために別のアプローチを使用しているため問題ありません）。

Answer 4

@gyurisc：フォントファイルを保持する必要はありますが、 文章 あなたが見るので、問題であることが判明するかもしれません グリフはキャラクターではありません. 。特定のGlyphが一部であるフォントファイルを調べることでキャラクターを把握できるかもしれませんが、それにはフォントファイルの解析が含まれます。不運な場合、PDFからXPSコンバーターは、特定のグリフ（可能性が非常に高い）が表すキャラクターを把握するために、フォントサブセットファイルに十分な情報を保持していません。

たとえば、MicrosoftのXPSドキュメントライターの助けを借りてPDFファイルをXPSに変換し、そのXPSドキュメントからテキストを選択してみると、クリップボードにコピーできます。ただし、その後、Wordドキュメントに貼り付けると、ゴミが届きます。一方、それを選択した場合 同じ 元のPDFドキュメントのテキストの一部とそれを同じWord文書に貼り付けて、私はかなり意味のあるテキストを受け取ります。したがって、MicrosoftのXPSドキュメントライターは、「Glyph Run」のテキストとしての解釈を気にしていないようです。したがって、Glyphコードとそれらが意図されている文字で見つけるGlyphインデックス間のリンクは、私にとって非常に可能性が高いようです。その時点で表現することはすでに壊れています。 （しかし、確かに、それは単なる推測です。）

の表現 文章 （グリフの実行とは対照的に）XAMLのテキストブロック要素になると思います。ただし、私の推測では、典型的なPDFからXPSコンバーターがテキストブロック要素を生成する可能性は低いと思います。 XPSは、主に画面上または紙の上でレンダリングされることを意図しています - それは、データ交換（あなたの場合のテキストの交換）に特に適したファイル形式としてそれ自体を示唆していません。