Verarbeitung Illustrator oder PDF-Dateien in XAML

Question

Was sind die Alternativen zu Verfahren Illustrator-Dateien oder PDFs in XAML sind. Meine aktuelle Workflow funktioniert wie folgt:

1. Öffnen Sie die PDF-Datei in Adobe Illustrator
2. Speichern Sie die Datei als .ai (Adobe Illustrator-Datei)
3. Öffnen in Expression Design
4. Sie einige der Verarbeitung, vor allem Elemente Schichten zu trennen und nicht mehr benötigte Teile zu entfernen.
5. Speichern unter XAML
6. Fügen Sie XAML zu Blend-Projekt

Mein Problem ist nur, dass diese Art der Text in Pfade umgewandelt wird. Ich möchte meinen Text in XAML halten als auch anstelle von Pfaden.

Gibt es eine andere Möglichkeit, dies zu tun, so dass ich den Text zu halten? Alle anderen Tools?

Answer 1

Es gibt einen (kostenlosen) Adobe Illustrator Plugin, um den Export zu XAML. Nicht sicher, es tut genau das, was Sie suchen, though.

Wir informieren Sie unter http://www.mikeswanson.com/XAMLExport/

Answer 2

Ich denke, was Sie wollen, ist Glyphen Elemente statt Wege zu haben. Das Problem ist, dass Glyphen Elemente, die Sie benötigen den URI der Font-Datei angeben. Auch Glyphen Elemente verweisen Glyphen durch ihre Index in eine Font-Datei (es kann vorkommen, dass ein Konverter, der Glyphen Elemente erzeugt - wie das Microsoft XPS Document Writer - Anwendungen Indizes in Schriftunter Dateien: so diese Indizes können nicht die richtigen Indizes auf die gleichen Glyphen wie in der ursprünglichen Schriftdatei definiert). Ich habe in der Lage, dieses Problem auf zwei Wegen mit meinem eigenen PDF zu XAML-Konvertierungs-Tool „lösen“.

1. Ansatz : eingefügt die font-Subset-Datei, BASE64 codiert, in der generierten XAML-Code und haben die Anwendung eine Klasse implementieren, dass beim Laden, Extrakte und decodiert eine eingebettete Schriftart-Teilmenge Datei in ein temporäres Verzeichnis und Hände eine gültige URI zu dieser temporären Datei zurück auf die XAML-loader.

oder 2. Ansatz : Haben die meisten Font-Dateien bereits zusammen mit meiner Anwendung installiert und wieder eine gewisse Unterstützung durch meine Anwendung hinzufügen, die den Namen der Schriftart durch einen URI zu der installierten Schriftdatei beim Laden der XAML-Code ersetzt. Das Problem bei diesem zweiten Ansatz besteht darin, dass die Symbolindizes korrekt auf die installierten Schriftarten Datei zugeordnet werden müssen, die nicht so trivial zu tun sein kann. (Sie können eine Verknüpfung zu einer Beispieldatei finden, die für diese Art von Laden auf meinem Blog generiert wurde: insbesondere werfen Sie einen Blick auf die Datei Kegelstumpf-xaml.txt )

Kurz gesagt: Beide Lösungen erfordern eine spezielle PDF zu XAML-Konverter und Unterstützung durch die Lade Anwendung. Der Grund, warum ich wollte es auf diese Art und Weise zu tun, anstatt nur mit meiner PDFs in Pfade konvertiert ist nur, dass meine Anwendung ist ein Shared Whiteboard: so möchte ich meine Vektorgrafiken als klein wie möglich sein. (Umwandlung in Pfaden tendiert dazu, den XAML-Code um einen Faktor von 10 oder mehr in den meisten Fällen zu sprengen).

Ich bin die Implementierung eines dritten Ansatz der Betrachtung : dies würde darin bestehen, in den Entwurf für jede Glyphe zu erzeugen, die verwendet wird nur einmal und dann Unterstützung hinzufügen, indem Sie meine Bewerbung transformieren und diese Position Glyphe Umrisse in einer Art und Weise sehr analog zu dem, was Glyphen Elementen tun, die sonst erzeugt werden müßten. Der Vorteil wäre, dass die erzeugte XAML noch relativ klein sein würde (vergleichbar mit dem zweiten Ansatz oben beschrieben), ohne die entsprechenden Schriftart-Dateien zu erfordern die Anwendung installiert werden entlang und ohne Symbolindizes aus einer Teilmenge Datei auf die installierten Schriftarten zur Karte Datei. Der Grund, warum ich noch nicht versucht, dies ernsthaft zu implementieren ist zweifach: Erstens, mein aktueller (zweite) Ansatz funktioniert schon sehr gut für das, was ich zur Zeit brauchen; zweitens könnte es Performance-Probleme werden mit diesem dritten Ansatz als reagards Belastungs- und / oder Rendering.

Answer 3

Nun eine XPS-Datei ist eigentlich eine ZIP-Datei. Also, wenn Sie es mit einem ZIP-Archiver öffnen oder wenn Sie seine Erweiterung umbenennen, um ZIP können Sie sehen, was drin ist. Sie enthält bereits die Seiten als XAML-Code (diese Dateien haben die Form [Seitennummer] .fpage). Jedoch, dass XAML-Code auf andere Dateien verweisen kann (wie Rasterbilder und Schriftunter Dateien, das sind typischerweise odttf Dateien - grundsätzlich verschlüsselt True-Type-Dateien), die auch in diesem ZIP-Archiv enthalten sind. Was bedeutet, dass der XAML-Code, dass Sie in einem XPS-Dokument finden kann nicht direkt als reine XAML in Ihrer Anwendung einsetzbar sein. Ich habe Python-Skripte geschrieben, um die Umwandlung von XAML von XPS-Dokumenten genommen zu tun (erzeugt durch den Microsoft XPS Document Writer) XAML-Dateien zu erhalten, dass meine Anwendung laden (siehe Ansätze 1 und 2 oben). Ich könnte Ihnen Kopien dieses Python-Skripte senden (sie sind nicht besonders groß Code, der kein Problem für mich, da ich nun einen anderen Ansatz zu konvertieren PDFs zu XAML sowieso bin mit).

Answer 4

@gyurisc: Halten Sie die Font-Datei arbeiten sollte, aber halten Sie die Text könnte sich als ein Problem sein, denn, sehen Sie, Glyphen sind nicht Zeichen . Es könnte sein, dass Sie durch die Untersuchung der Font-Datei den Charakter herausfinden konnte, dass ein gegebenes Glyphe Teil ist, aber das würde bedeuten, die Font-Datei parsen. Wenn Sie Pech haben, wird Ihre PDF-XPS-Konverter auch halten nicht genügend Informationen in der Schriftart Teilmenge von Dateien, um herauszufinden, den Charakter einer gegebenen Glyphe (sehr wahrscheinlich) darstellt.

Zum Beispiel: Wenn ich eine PDF-Datei XPS mit Hilfe von Microsoft XPS Document Writer konvertieren, und dann versuchen, ein Stück Text aus diesem XPS-Dokument zu wählen, kann ich (nur scheinbar) kopieren Sie sie in die Zwischenablage. Allerdings, wenn ich es dann in ein Word-Dokument einfügen zurück, erhalte ich Müll. Während, wenn ich wählen Sie die gleichen Stück Text in der ursprünglichen PDF-Dokument und in das gleiche Word-Dokument einfügen, ich einigermaßen sinnvollen Text. So Microsofts XPS Document Writer schert offenbar nicht um die Interpretation eines „Glyphe run“ als Text, und so scheint es mir sehr wahrscheinlich, dass die Verbindung zwischen dem Symbolindizes, dass man Funden im generierten XPS-Code und die Charaktere, die sie gemeint sind darzustellen, ist bereits an dieser Stelle unterbrochen. (Aber freilich, das ist nur eine Vermutung.)

Eine Darstellung von text (im Gegensatz zu einem Laufe von Glyphen gegen) ein Textblock-Element in XAML sein würde, nehme ich an. Aber meine Vermutung ist, dass ein typischer PDF-XPS-Konverter unwahrscheinlich ist TextBlock- Elemente zu erzeugen. XPS ist vor allem gemeint gerendert wird - auf dem Bildschirm oder auf Papier -. Sie sich nicht als ein Dateiformat, das besonders geeignet ist für den Datenaustausch (Austausch von Text in Ihrem Fall)