Traitement Illustrator ou fichiers pdf en XAML

Question

Quelles sont les alternatives aux fichiers Illustrator de processus ou des fichiers PDF en XAML. Mon flux de travail actuel fonctionne comme ceci:

1. Ouvrez le fichier PDF dans Adobe Illustrator
2. Enregistrez le fichier en tant que fichier .ai (Adobe Illustrator)
3. Open in Expression Design
4. Effectuer un traitement, notamment des éléments de séparation à couches et enlever des parties inutiles.
5. Enregistrer sous XAML
6. Ajouter au projet XAML Blend

Mon seul problème est que cette façon dont le texte est converti en chemins. Je voudrais garder mon texte en XAML et au lieu de chemins.

Y at-il une autre façon de le faire, alors je garde le texte? Tous les autres outils?

Answer 1

Il y a un (gratuit) plug-in Adobe Illustrator à l'exportation vers XAML. Je ne sais pas ce fait exactement ce que vous cherchez, cependant.

Trouvez-le sur http://www.mikeswanson.com/XAMLExport/

Answer 2

Je pense que ce que vous voulez est d'avoir des éléments de Glyphes au lieu des chemins. Le problème est que les éléments de Glyphes nécessitent de spécifier l'URI du fichier de police. En outre, Glyphes éléments de référence Glyphes par leur indice dans un fichier de police (il peut arriver qu'un convertisseur qui génère Glyphes éléments - comme le document Writer Microsoft XPS - utilise des indices dans les fichiers de sous-ensemble de police: si ces indices peuvent pas les indices droit aux mêmes glyphes tels que définis dans le fichier de police d'origine). Je suis en mesure de « résoudre » ce problème de deux façons avec mon propre PDF aux outils de conversion XAML.

1. approche : Intégrer le fichier sous-ensemble de la police, BASE64 codé, dans le code XAML généré et que l'application mettre en œuvre une classe qui, lors du chargement, des extraits et décode un fichier de sous-ensemble de police intégrée à un emplacement temporaire et les mains VALIDE URI à ce retour de fichier temporaire au chargeur XAML.

ou 2. approche : avoir des fichiers déjà installés plus de police ainsi que ma demande et, encore une fois, en ajoutant un certain soutien par mon application qui remplace le nom de la police par un URI dans le fichier de police installé lors du chargement du code XAML. Le problème avec cette deuxième approche est que les indices de glyphe doivent être correctement mis en correspondance avec le fichier de police installé, ce qui peut ne pas être tout ce trivial à faire. (Vous pouvez trouver un lien vers un fichier exemple qui a été généré pour cette façon de charger sur mon blog: en particulier prendre un coup d'oeil au fichier truncatedcone-xaml.txt )

En bref: les deux solutions exigent un PDF spécial convertisseur XAML et support par l'application de chargement. La raison pour laquelle je voulais le faire de cette façon au lieu d'avoir mes fichiers PDF convertis en chemins seulement que mon application est un tableau blanc partagé: donc je veux que mes graphiques vectoriels pour être comme petite que possible . (Conversion des chemins tend à faire exploser le code XAML par un facteur de 10 ou plus dans la plupart des cas).

J'envisage la mise en œuvre d'une approche troisième : ce consisterait à générer les grandes lignes pour chaque glyphe qui est utilisé une seule fois , puis ajouter le support par ma demande transformer et la position de ces lignes glyphe d'une manière très analogue à ce que les éléments glyphes faire qui autrement à générer. L'avantage serait que le XAML généré serait encore relativement faible (comparable à la deuxième approche décrite ci-dessus) sans nécessiter les fichiers de police concernés à installer ainsi que l'application et sans avoir à cartographier les indices de glyphe à partir d'un fichier de sous-ensemble à la police installée fichier. La raison pour laquelle je ne l'ai pas encore essayé de mettre en œuvre cette sérieusement est double: d'abord, mon approche actuelle (seconde) fonctionne déjà très bien pour ce que je besoin actuellement; D'autre part, il pourrait y avoir des problèmes de performance avec cette troisième approche que reagards chargement et / ou le rendu.

Answer 3

Eh bien un fichier XPS est en fait un fichier ZIP. Donc, si vous l'ouvrez avec un ZIP ou archiveur si vous renommez son extension ZIP, vous pouvez voir ce qui est à l'intérieur. Il contient déjà les pages que le code XAML (ces fichiers ont la forme [pagenumber] .fpage). Toutefois, ce code XAML peut se référer à d'autres fichiers (comme des images raster et les fichiers de sous-ensemble de polices, ce sont généralement des fichiers odttf - fichiers true type essentiellement cryptés) qui sont inclus dans cette archive ZIP ainsi. Ce qui signifie que le code XAML que vous trouvez dans un document XPS ne peut pas être directement utilisable comme XAML pur dans votre application. Je scripts python écrit pour effectuer la conversion de XAML extraites de documents XPS (généré par le Microsoft XPS Document Writer) pour obtenir des fichiers XAML que mon application peut charger (voir les approches 1 et 2 ci-dessus). Je pourrais vous envoyer des copies de ces scripts python (ils ne sont pas particulièrement grand code, ce qui est pas un problème pour moi depuis que je suis maintenant en utilisant une approche différente des fichiers PDF convertir à XAML de toute façon).

Answer 4

@gyurisc: Garder le fichier de police devrait fonctionner mais en gardant le texte pourrait se révéler être un problème, parce que, voyez-vous, Glyphes ne sont pas des caractères . Il est peut-être que vous pourriez comprendre le caractère en examinant le fichier de police qu'un glyphe donné fait partie, mais cela impliquerait l'analyse du fichier de police. Si vous êtes malchanceux, votre PDF convertisseur XPS ne tient pas même assez d'informations dans les fichiers de sous-ensemble de la police à comprendre le caractère d'un glyphe donné (très probable) représente.

Par exemple: Si je convertir un fichier PDF au format XPS avec l'aide du XPS Document Writer de Microsoft, et essayez de sélectionner un morceau de texte de ce document XPS, je peux (seulement en apparence) le copier dans le presse-papiers. Cependant, si je puis collez-le dans un document Word, je reçois des ordures. Alors que si je choisis que même morceau de texte dans le document PDF d'origine et de le coller dans le même document Word, je reçois le texte raisonnablement significatif. Donc XPS Document Writer de Microsoft ne semble se soucie pas de l'interprétation d'un « run glyphe » sous forme de texte, et donc il me semble très probable que le lien entre les indices de glyphe que l'on trouve dans le code XPS généré et les personnages qu'ils sont censés pour représenter déjà rompu à ce moment-là. (Mais, il est vrai, c'est juste une supposition.)

Une représentation de text (par opposition à une série de Glyphes) serait un élément TextBlock en XAML, je suppose. Cependant, je suppose qu'un PDF typique convertisseur XPS est peu susceptible de générer des éléments TextBlock. XPS est principalement destiné à être rendu - à l'écran ou sur papier -. Il ne se propose pas comme un format de fichier qui est particulièrement adapté à l'échange de données (échange de texte dans votre cas)