5

イラストレーター ファイルまたは PDF を XAML に処理するための代替手段は何ですか。私の現在のワークフローは次のように機能します。

  1. PDFファイルをAdobeイラストレーターで開く
  2. ファイルを .ai (Adobe Illustrator) ファイルとして保存します。
  3. Expression Design で開く
  4. 主に要素をレイヤーに分離し、不要な部分を削除します。
  5. XAML として保存
  6. XAML を Blend プロジェクトに追加する

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

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

4

4 に答える 4

4

あなたが望むのは、パスの代わりにグリフ要素を持つことだと思います。問題は、Glyphs 要素ではフォント ファイルの URI を指定する必要があることです。また、Glyphs 要素は、フォント ファイルへのインデックスによってグリフを参照します (Microsoft XPS Document Writer などの Glyphs 要素を生成するコンバーターが、フォント サブセット ファイルへのインデックスを使用する場合があります。したがって、これらのインデックスは、元のフォント ファイルで定義されているものと同じグリフ)。独自の PDF から XAML への変換ツールを使用して、この問題を 2 つの方法で "解決" することができました。

1. アプローチ: 生成された XAML コードに BASE64 でコード化されたフォント サブセット ファイルを埋め込み、アプリケーションにクラスを実装させます。このクラスは、読み込み時に、埋め込まれたフォント サブセット ファイルを抽出して一時的な場所にデコードし、有効な URI をその一時ファイルを XAML ローダーに戻します。

または、2. アプローチ: アプリケーションと共にほとんどのフォント ファイルが既にインストールされており、XAML コードの読み込み時にフォント名をインストール済みフォント ファイルの URI に置き換えるアプリケーションによるサポートを追加します。この 2 番目のアプローチの問題点は、インストールされたフォント ファイルにグリフ インデックスを正しくマップする必要があることです。(私のブログで、この読み込み方法用に生成されたサンプル ファイルへのリンクを見つけることができます。特に、ファイルtruncatedcone-xaml.txtをのぞいてみてください)

要するに、どちらのソリューションも、特別な PDF から XAML へのコンバーターと、読み込みアプリケーションによるサポートを必要とします。PDF をパスのみに変換するのではなく、このようにしたかった理由は、アプリケーションが共有ホワイトボードであるためです。したがって、ベクター グラフィックスをできるだけ小さくしたいのです。(パスへの変換は、ほとんどの場合、XAML コードを 10 倍以上に膨らませる傾向があります)。

3 番目のアプローチの実装を検討しています。これは、一度だけ使用されるすべてのグリフのアウトラインを生成することで構成されます。次に、私のアプリケーションによるサポートを追加して、これらのグリフのアウトラインを変換して配置する方法を、Glyphs 要素が行うことと非常によく似た方法で生成します。利点は、生成された XAML が依然として比較的小さい (前述の 2 番目の方法に匹敵する) ことであり、関連するフォント ファイルをアプリケーションと共にインストールする必要がなく、グリフ インデックスをサブセット ファイルからインストールされたフォントにマップする必要もありません。ファイル。これを本格的に実装しようとまだ試みていない理由は 2 つあります。まず、現在の (2 番目の) アプローチは、現在必要としているものに対して既に非常にうまく機能しています。次に、この 3 番目のアプローチでは、読み込みやレンダリングに関してパフォーマンスの問題が発生する可能性があります。

于 2010-12-27T05:23:35.673 に答える
2

XAML にエクスポートするための (無料の) Adob​​e Illustrator プラグインがあります。ただし、探しているものが正確に機能するかどうかはわかりません。

http://www.miceswanson.com/XAMLExport/で見つけてください。

于 2010-09-03T14:30:10.887 に答える
1

@gyurisc: フォント ファイルの保持は機能するはずですが、テキストの保持が問題になる可能性があります。グリフは文字ではないためです。特定のグリフが含まれるフォント ファイルを調べることで文字を特定できるかもしれませんが、それにはフォント ファイルの解析が必要になります。運が悪ければ、PDF から XPS へのコンバーターは、フォント サブセット ファイルに十分な情報を保持しておらず、特定のグリフ (可能性が非常に高い) が表す文字を特定できません。

例: Microsoft の XPS Document Writer を使用して PDF ファイルを XPS に変換し、その XPS ドキュメントからテキストの一部を選択しようとすると、クリップボードに (明らかに) コピーできます。ただし、それを Word 文書に貼り付けると、ガベージが発生します。一方、元の PDF 文書で同じテキストを選択して同じ Word 文書に貼り付けると、かなり意味のあるテキストが得られます。したがって、Microsoft の XPS ドキュメント ライターは、「グリフ ラン」をテキストとして解釈することを気にしないようです。そのため、生成された XPS コードで見つけたグリフ インデックスと、それらが意味する文字との間のリンクは、表すことは、その時点ですでに壊れています。（しかし、確かに、それは単なる推測です。）

テキストの表現(一連のグリフとは対照的に) は、XAML の TextBlock 要素になると思います。ただし、一般的な PDF から XPS へのコンバーターが TextBlock 要素を生成する可能性は低いと思います。XPSは主に、画面または紙にレンダリングすることを目的としています-データ交換（この場合はテキストの交換）に特に適したファイル形式として提案されていません。

于 2010-12-31T18:32:23.570 に答える
1

XPS ファイルは実際には ZIP ファイルです。したがって、ZIP アーカイバーで開くか、拡張子を ZIP に変更すると、中身を確認できます。ページは XAML コードとして既に含まれています (これらのファイルの形式は [pagenumber].fpage です)。ただし、その XAML コードは、その ZIP アーカイブに含まれる他のファイル (ラスター イメージやフォント サブセット ファイルなど、通常は odttf ファイル - 基本的に暗号化された True Type ファイル) を参照する場合があります。つまり、XPS ドキュメントで見つかった XAML コードは、アプリケーションで純粋な XAML として直接使用できない場合があります。XPS ドキュメント (Microsoft XPS Document Writer によって生成された) から取得した XAML を変換して、アプリケーションが読み込むことができる XAML ファイルを取得する Python スクリプトを作成しました (上記の方法 1 と 2 を参照)。

于 2010-12-29T17:07:57.637 に答える