Procesamiento de Illustrator o PDF en XAML

Question

¿Cuáles son las alternativas a los archivos de Illustrator proceso o archivos PDF en XAML. Mi flujo de trabajo actual funciona de esta manera:

1. Abra el archivo PDF en Adobe Illustrator
2. Guarde el archivo como .ai (Adobe Illustrator) Archivo
3. Abrir en Expression Design
4. hacer algo de procesamiento, separando principalmente elementos a capas y la eliminación de partes que no sean necesarios.
5. Guardar como XAML
6. Añadir XAML al proyecto de fusión

Mi único problema es que de esta manera el texto se convierte en trazados. Me gustaría mantener mi texto en XAML, así en lugar de caminos.

¿Hay alguna otra manera de hacer esto, así que me quedo con el texto? Cualquier otra herramienta?

Answer 1

Hay una (libre) Adobe Illustrator plugin para la exportación a XAML. No estoy seguro de que hace exactamente lo que está buscando, sin embargo.

Lo encontrarás en http://www.mikeswanson.com/XAMLExport/

Answer 2

Creo que lo que quiere es tener elementos de glifos en lugar de Caminos. El problema es que los elementos glifos requieren que se especifique el URI del archivo de fuente. Asimismo, hacen referencia a elementos Glifos Glifos por su index en un archivo de fuente (puede suceder que un convertidor que genera elementos de glifos - como el Microsoft XPS Document Writer - índices de usos en archivos subconjunto de las fuentes: por lo que estos índices pueden no ser los índices adecuados a los mismos glifos tal como se definen en el archivo fuente original). He sido capaz de "resolver" este problema de dos maneras con mi propia PDF a herramientas de conversión de XAML.

1. enfoque : Insertar el archivo de fuente-subconjunto, BASE64 codificado, en el código XAML generado y tener la aplicación implementar una clase que, durante la carga, extractos y descodifica un archivo de fuente-subconjunto incrustado en una ubicación temporal y las manos de un válidos URI para que allá archivo temporal para el cargador de XAML.

o, 2. enfoque : Tiene la mayoría de archivos de fuentes ya instaladas junto con mi solicitud y, de nuevo, añadiendo un poco de apoyo por mi aplicación que reemplaza el nombre de la fuente por un URI en el fichero fuente instalada durante la carga del código XAML. El problema de este segundo enfoque es que los índices de glifo se deben asignar correctamente al archivo fuente instalada, que puede no ser tan trivial para hacerlo. (Usted puede encontrar un enlace a un archivo de ejemplo que se ha generado para este modo de carga en mi blog: en particular, es una oportunidad única el archivo truncatedcone-xaml.txt )

En pocas palabras: las dos soluciones requieren un PDF especial al convertidor y el apoyo XAML por la aplicación de carga. La razón por la que quería hacerlo de esta manera en lugar de sólo tener mis archivos PDF convertidos en trazados única es que mi solicitud es una pizarra compartida: así quiero que mis gráficos vectoriales sean lo más pequeño como sea posible . (Conversión a caminos tiende a volar el código XAML en un factor de 10 o más en la mayoría de los casos).

Estoy contemplando la implementación de un tercer enfoque : esto consistiría en generar el contorno para cada glifo que se utiliza sólo una vez y luego añadir el apoyo de mi solicitud transformar y posición de estos contornos de glifo de un modo muy análogo a lo que los elementos glifos hacer que de otra manera tendrían que ser generada. La ventaja sería que el XAML generado todavía sería relativamente pequeño (comparable a la segunda enfoque descrito anteriormente) sin necesidad de los archivos de fuentes pertinentes para ser instalados junto con la aplicación y sin tener que asignar índices de glifo de un archivo de subconjunto a la fuente instalada archivo. La razón por la que aún no he tratado de implementar esto en serio es doble: en primer lugar, mi enfoque actual (segunda) ya funciona muy bien para lo que actualmente necesito; segundo, podría haber problemas de rendimiento con este tercer enfoque como reagards carga y / o de la prestación.

Answer 3

Bueno un archivo XPS es realmente un archivo ZIP. Así que si lo abre con una postal-archivador o si cambia el nombre a su extensión ZIP que puede ver lo que hay dentro. Que ya contiene las páginas como código XAML (los archivos tienen la forma [número de página] .fpage). Sin embargo, ese código XAML puede hacer referencia a otros archivos (como imágenes de mapa de bits y archivos de subconjuntos de fuentes, esos son normalmente los archivos cifrados odttf - básicamente verdaderos archivos de tipo) que se incluyen en ese archivo ZIP también. Lo que significa, que el código XAML que se encuentran en un documento XPS puede no ser directamente utilizable como XAML pura en su aplicación. He escrito scripts de Python para hacer la conversión de XAML tomada de documentos XPS (generada por el escritor de documentos XPS de Microsoft) para obtener archivos XAML que mi aplicación se carga (Ver enfoques 1 y 2 anteriores). Te podría enviar copias de los scripts de Python (que no son especialmente grandes código, que no es ningún problema para mí ya que ahora estoy utilizando un enfoque diferente a PDF Convertir a XAML de todos modos).

Answer 4

@gyurisc: Mantener el archivo de fuentes debería funcionar pero manteniendo el texto podría llegar a ser un problema, porque, como ven, glifos no son caracteres . Podría ser que usted podría averiguar el carácter examinando el archivo fuente que un glifo dado es parte de, pero eso implicaría analizar el archivo de fuente. Si tienes la mala suerte, el convertidor de PDF a XPS no tiene ni siquiera mantener suficiente información en los archivos fuente de subconjuntos de averiguar el carácter de un glifo dado (muy probable) representa.

Por ejemplo: Si puedo convertir un archivo PDF a XPS con la ayuda del escritor de documentos XPS de Microsoft, y luego tratar de seleccionar una parte del texto de ese documento XPS, que puede (sólo aparentemente) copiarlo en el portapapeles. Sin embargo, si a continuación, volver a pegarla en un documento de Word, recibo de basura. Mientras que si selecciono que mismo fragmento de texto en el documento PDF original y pegarlo en el mismo documento de Word, me sale el texto razonablemente significativa. Así escritor de documentos XPS de Microsoft al parecer no se preocupa por la interpretación de una "corrida glifo" como texto, y por lo tanto parece muy probable para mí que la relación entre los índices de glifo que se encuentra en el código XPS generada y los personajes que están destinados para representar ya está roto en ese punto. (Sin embargo, es cierto, eso es sólo una conjetura.)

Una representación de texto (en contraposición a una racha de glifos) sería un elemento TextBlock en XAML, supongo. Sin embargo, mi opinión es que un PDF típica al convertidor de XPS es poco probable que genere elementos TextBlock. XPS está destinado principalmente a ser prestados - en la pantalla o en papel -. No sugiere como un formato de archivo que es particularmente adecuado para el intercambio de datos (intercambio de texto en su caso)