2015-01-15 2 views
0

Я пытаюсь создать арабские pdf-документы с помощью iText 4.2.1. Документы основаны на шаблонах, представленных в формате Word xml. Я просто там, но попал в ловушку.iText & Arabic pdfs часто отсутствующие символы

В исходных документах используется шрифт Упрощенный арабский и отображается в порядке, поэтому я использовал то же самое в PDF. По большей части все прекрасно, но иногда оно «капли» персонажа.

Я прорисовал источник iText и вижу, где он преобразуется из базового кода 0x06xx в код представления 0xFExx в зависимости от правил формирования. После того, как он перевел код презентации, он затем ищет метрики каждого символа, в свою очередь, из файла шрифта, перед записью в поток вывода документа. Именно здесь иногда не удается найти нужный код в шрифте, поэтому просто опускает символ вместе.

В качестве примера, символ 0x0645 переводится 0xFEE2 используя эту строку из таблицы CharMap

{0x0645, 0xFEE1, 0xFEE2, 0xFEE3, 0xFEE4}, /* MEEM */ 

... и 0xFEE2 не в Упрощенном арабском шрифте.

Учитывая, что документы хорошо отображаются в Word с использованием того же шрифта, должен ли iText вернуться к использованию базового кода 0x6xx для презентации? Если это так, то это разрешено в коммерческой версии библиотек (для чего я рад, если нужно, платить).

С другой стороны, это проблема с шрифтом, который другие библиотеки должны работать вокруг

Кто-нибудь еще ударил эту корягу или подобное, и если да, то что вы сделали, чтобы решить ее?

+1

У меня была аналогичная проблема с лакокрасочными буквами - есть статья, которая мне помогла. Я боюсь, что это на польском языке, но google.translate должно быть достаточно, чтобы понять суть этого;) http://soft-java.net/solutions/iText-poskie-znaki-tworzenie-PDF#pr1 Главная дело в том, чтобы изменить кодировку в классе iText 'com.lowagie.text.pdf.BaseFont' в методе' createFont'. – rzysia

+0

Спасибо rzysia. Использование Arial вместо упрощенного арабского языка и установка правильной кодировки работали для меня. – Vicki

+0

Не только '4.2.1 - очень старая версия, как пишет Пауло, это даже версия, которая не была выпущена iText Software, а кем-то другим. iText перешел от «2.1.7» к «5.0.0». В старом репозитории SVN был тег '4.2.0', но он никогда не использовался для создания сборки релиза. Он использовался только для синхронизации с портом .NET. Кто-то другой взял этот тег, внес некоторые изменения и выпустил его как «4.2.1», но не под своим именем, как и следовало бы сделать. –

ответ

2

арабские имеет логическое текстовое представление в диапазоне 0x6xx и визуальное представление в двух других диапазонах: FB50 - FDFF арабских вариантов буквы-A FE70 - FEFF арабских вариантов буквы-B

Диапазоны представления должны быть используется для каждого персонажа, у вас может быть четыре представления в зависимости от местоположения слова: начальное, медиальное, конечное и изолированное. Возможны другие лигатуры.

Отказ от использования мощной старой версии iText, если символ не в шрифте, он не может быть представлен. Word будет использовать другие шрифты, если шрифт имеет отсутствующий символ или он может использовать альтернативный символ. Попробуйте использовать Arial, чтобы убедиться, что лигатуры правильные.

+0

Спасибо за ответ Пауло. Я подозреваю, что Word применяет некоторую коррекцию для отсутствующих глифов внутри шрифта, возможно, возвращаясь к представлению 0x6xx, если он не существует в представлении. Тем не менее, я принял ваш совет относительно Arial, и это, похоже, сделало трюк. Ранее я избегал использования Arial для нелатинского текста, поскольку нам не удалось отобразить ничего, кроме основных латинских символов. Я только что понял, что мы используем неправильную кодировку! Doh. – Vicki

0

Недавно мы столкнулись с той же ситуацией, и мы представляем, что мы сделали для этого вопроса:

  1. В нашем случае - документ был автор в MS Word на арабском языке. Когда вы выбираете один символ и Alt + x, в MS Word - вы можете видеть Юникод символа. Юникод лгал в нормальном Unicode Range (0600-06FF, 255 символов).
  2. Когда указанный документ был преобразован в PDF-файл: «Сохранить как PDF» в MS Word или «Adobe Acrobat Professional», «Обычный арабский Unicode» был заменен на арабскую презентационную форму A [611 символов, в зависимости от того, находится в изоляции или в начале или в середине или в конце слова] и B [143 символа], связанных с символами.
  3. Согласно блоге кто-то из Adobe - «PDF определяет текстовое содержимое страниц, как глифы не символы» - ссылка: http://blogs.adobe.com/insidepdf/2008/07/text_content_in_pdf_files.html
  4. Несмотря на то, - где каждый в Интернете - это написано «не рекомендуется, чтобы не использовать форматы презентации «преобразование в PDF» привели к изменению обычного арабского символа юникода, установленного в форме презентации A & B набор символов.
  5. Когда мы извлекли текст - используя PDFBox - мы получили символы в Unicode в форме презентации A и B. Интересно, что, поскольку мы не можем читать арабский язык - когда мы копировали и вставляли текст в google translate - мы получили тот же результат, однако, когда мы сделали разницу, вычислив diff - мы получили, что между двумя строками нет ничего общего. [До этого момента мы не знали о нормальном юникодном арабском языке, представляющем форму арабика, который также является частью юникода и т. Д.)

  6. У нас было деловое требование для извлечения исходного набора символов из PDF. Это было сложно - Форма презентации A & B имеет около 4 форм - для каждого символа [в зависимости от его местоположения в слове].

Мы активно смотрели в Интернете - если бы была какая-либо библиотека, которая может установить связь между ними.

К счастью - Unicode имеет замену Characterset - который определяет, как мы можем вернуться назад из формы презентации A & B символ [Замена символа задним числом] - установить в обычный набор символов Unicode.

http://www.unicode.org/cldr/charts/29/supplemental/character_fallback_substitutions.html

Используя вышеупомянутый источник данных - мы смогли получить определение перевода обратно в обычный арабский набор символов из 591/611 символов в арабской Форме представления Юникода набор и 139/143 символов в арабской форме презентации B набор символов Unicode.

Adobe - также имеет спецификацию списка Adobe Glyph - [доступно на github] - которая также определяет взаимосвязь между символами и их юникодом, - но является неполной для арабского, поскольку она определяет 257 символов, которые также попадают в основном в арабскую форму представления Серия.

Далее - в нашем случае - отсутствовали символы. Символы были переведены только с нашего обычного арабского Unicode на формы презентации.

В нашем оригинальном документе MS Word - были таблицы - внутри которых было содержимое. В переведенном арабском языке мы получили символ юникода FFFD [вопросительный знак, в котором указывалось, что некоторые символы не могут быть переведены, когда они были изменены в unicode.] IF удалил все такие символы FFFD - оставшийся текст - хотя и преобразован в форму представления. Unicode set - имел такое же значение, как и оригинальное.

Мы потратили значительное время на решение этой проблемы изменения в Юникоде при преобразовании в PDF и надеемся, что наш опыт будет полезен и для кого-то другого.

Смежные вопросы