Обработка иллюстратора или PDF файлов в XAML

Question

Каковы альтернативы для обработки файлов Illustrator или PDFS в XAML. Мой текущий рабочий процесс работает так:

1. Откройте файл PDF в Adobe Illustrator
2. Сохраните файл как .ai (Adobe Illustrator) файл
3. Открыть в дизайне выражения
4. Сделайте некоторую обработку, в основном разделяющие элементы к слоям и удаления ненужных частей.
5. Сохранить как Xaml.
6. Добавить XAML в Blend Project

Моя единственная проблема заключается в том, что таким образом текст превращается в пути. Я хотел бы сохранить свой текст в XAML, а не на пути.

Есть ли другой способ сделать это, поэтому я держу текст? Любые другие инструменты?

Answer 1

Есть (бесплатный) плагин Adobe Illustrator для экспорта в XAML. Не уверен, что это именно то, что вы ищете, хотя.

Найди это http://www.mikeswanson.com/xamlexport/

Answer 2

Я думаю, что вы хотите, это иметь элементы Glyphs вместо путей. Проблема в том, что элементы Glyphs требуют, чтобы вы указываете URI файла шрифта. Кроме того, элементы глифов ссылочные глифы своими показатель В файл шрифта (может произойти тот, что конвертер, который генерирует элементы Glyphs - как Microsoft XPS-документ - использует индексы в файлах подмножества шрифта: поэтому эти показатели могут быть не правильными индексами к тому же глифу, как определено в исходном файле шрифта. ). Я смог «решить» эту проблему двумя способами с моим собственным PDF для инструментов преобразования XAML.

1. Подход: Встраивать файл подмножества шрифта, кодирован BASE64, в сгенерированном XAML-коде и имел приложение, реализующую класс, который при загрузке, извлеченных и декодирует встроенный файл подмножества шрифта во временное местоположение и передает действительный URI для этого временного файла Вернуться к XAML-погрузчику.

или, 2. Подход: У большинства файлов шрифтов уже установлены вместе с моим приложением, и, опять же, добавляя некоторую поддержку моему приложению, которое заменяет имя шрифта URI в установленный файл шрифта при загрузке кода XAML. Проблема с этим вторым подходом заключается в том, что индексы Glyph должны быть правильно сопоставлены с установленным файлом шрифта, который не может быть всем таким тривиальным для выполнения. (Вы можете найти ссылку на пример файла, который был сгенерирован для этого способа загрузки в моем блоге: в частности, возьмите заглянуть в файл TRUNCEDCONE-XAML.TXT.)

Короче говоря: оба решения требуют специального PDF к XAML-преобразованию и поддержку приложению загрузки. Причина, по которой я хотел сделать это таким образом, вместо того, чтобы просто иметь свои PDFS, преобразованные только в пути к путям, так это то, что мое приложение - это общая доска: Таким образом, я хочу, чтобы моя Векторная графика была как как можно меньше. Отказ (Конвертация к путям имеет тенденцию взорвать код XAML в 10 или более случаях в большинстве случаев).

Я обдумываю реализацию Третий подход: Это будет состоять в создании наброски для каждого используемого глифа только один раз И затем добавьте поддержку моего приложения для преобразования и положения этих группных очерких таким образом, чтобы тесно аналогичные к тому, какие элементы Glyphs делают, которые в противном случае должны быть сгенерированы. Преимущество заключается в том, что генерируемый XAML все равно будет относительно небольшим (сопоставимым со вторым подходом, описанным выше), не требуя установки соответствующих файлов шрифтов вместе с приложением и без необходимости отображения индексов Glyph из подмножества файла к установленному шрифту. файл. Причина, по которой я еще не пытался реализовать это, это в два раза - в два раза: во-первых, мой текущий (второй) подход уже очень хорошо работает для того, что мне нужно; Во-вторых, могут возникнуть проблемы с производительностью с этим третьим подходом в качестве погрузки и / или рендеринга реакции.

Answer 3

Ну, файл XPS на самом деле является zip-файлом. Поэтому, если вы открываете его с помощью ZIP-архиватора или если вы переименовываете его расширение на ZIP, вы можете увидеть, что находится внутри. Он уже содержит страницы как код XAML (эти файлы имеют форму [PageNumber] .fage). Однако этот XAML-код может обратиться к другим файлам (например, растровые изображения и файлы подмножества шрифтов, которые обычно являются файлами ODTTF - в основном зашифрованные файлы True Type), которые также включены в этот ZIP-архив. Это означает, что код XAML, который вы нашли в документе XPS, могут быть непосредственно использоваться в качестве чистого XAML в вашем приложении. Я написал сценарии Python, чтобы выполнить преобразование XAML, взятых из документов XPS (сгенерировано Microsoft XPS Whocient Acer), чтобы получить XAML-файлы, которые моим приложением может загружаться (см. Подходы 1 и 2 выше). Я мог бы отправить вам копии этих сценариев Python (они не особенно отличный код, который нет для меня, поскольку я сейчас использую другой подход для преобразования PDFS в XAML в любом случае).

Answer 4

@gyurisc: сохранение файла шрифта должно работать, но сохраняя текст может оказаться проблемой, потому что вы видите, глифы не персонажи. Отказ Возможно, вы могли бы выяснить персонаж, изучав файл шрифта, который является частью данного глифа, но это будет включать в себя расстановку файла шрифта. Если вы не повезете, ваш преобразователь PDF к XPS даже не содержит достаточно информации в файлах подмножества шрифтов, чтобы выяснить символ данный глиф (очень скорее всего).

Например: если я преобразую файл PDF в XPS с помощью Microsoft XPS-документа, а затем попробуйте выбрать текст из этого документа XPS, я могу (только видимо) скопируйте его в буфер обмена. Однако, если я тогда вставлю его обратно в слово документ, я получаю мусор. Тогда как если я выберу это такой же Кусок текста в оригинальном документе PDF и вставьте его в одно и то же документ Word, я получаю достаточно значимый текст. Таким образом, писатель документов Microsoft XPS, по-видимому, не заботится о интерпретации «глифа» в виде текста, и, таким образом, вроде бы мне очень вероятно, что связь между индексами глифа, которую можно найти в сгенерированном XPS и символам, которые они предназначены представлять уже сломан в этот момент. (Но, по общему признанию, это просто предположение.)

Представление текст (в отличие от бега глифов) будет элемент TextBlock в XAML, я полагаю. Тем не менее, я предполагаю, что типичный преобразователь PDF к XPS вряд ли генерирует элементы TextBlock. XPS в основном предназначен для отображения - на экране или на бумаге - он не предлагает себе как формат файла, который особенно подходит для обмена данными (обмен текстом в вашем случае).