itextsharp, почему GetSingleSpaceWidth () возвращает 0, когда пробел визуально очевиден? - PullRequest
1 голос
/ 03 июля 2019

enter image description here

Привет всем,

Этот вопрос относится к itextsharp версии 5.5.13.1. Я использую пользовательскую реализацию LocationTextExtractionStrategy для извлечения разумных слов из документа PDF. Я вызываю метод GetSingleSpaceWidth из TextRenderInfo, чтобы определить, когда соединить два смежных блока символов в одно слово по ссылке SFO itext Java PDF для создания текста

Этот подход в целом работал хорошо. Однако, если вы посмотрите на приложенный документ, слова " Credit " и " Extended " вызывают у меня некоторые проблемы. Почему все символы, отображаемые в скриншоте, возвращают нулевое значение для GetSingleSpaceWidth ? Это вызывает проблему. Вместо двух отдельных слов моя логика возвращает мне одно слово " CreditExtended ".

Я понимаю, что itextsharp5 больше не поддерживается. Любые предложения будут высоко оценены?

Образец документа

https://drive.google.com/open?id=1pPyNRXvnUyIA2CeRrv05-H9q0sTUN97d

1 Ответ

1 голос
/ 04 июля 2019

Как уже предполагалось в комментарии, причина в том, что рассматриваемый шрифт не содержит обычный глиф или, точнее говоря, не отображает ни один из его глифов в значение Unicode U + 0020 в его ToUnicode map.

Если шрифт имеет карту ToUnicode , iText использует только информацию с этой карты.Таким образом, iText не идентифицирует глиф пробела в этом шрифте, поэтому он не может предоставить фактическое значение SingleSpaceWidth и возвращает вместо него 0.


Соответствующий шрифт называется F5 и имеет это ToUnicode map:

/CIDInit /ProcSet findresource begin
14 dict begin
begincmap
/CIDSystemInfo
<< /Registry (Adobe)
/Ordering (UCS)
/Supplement 0
>> def
/CMapName /Adobe-Identity-UCS def
/CMapType 2 def
1 begincodespacerange
<0000> <FFFF>
endcodespacerange
4 beginbfchar
<0004> <0041>
<0012> <0043>
<001C> <0045>
<002F> <0049>
endbfchar
1 beginbfrange
<0044> <0045> <004D>
endbfrange
13 beginbfchar
<0102> <0061>
<0110> <0063>
<011A> <0064>
<011E> <0065>
<0150> <0067>
<015D> <0069>
<016F> <006C>
<0176> <006E>
<017D> <006F>
<0189> <0070>
<018C> <0072>
<0190> <0073>
<019A> <0074>
endbfchar
5 beginbfrange
<01C0> <01C1> <0076>
<01C6> <01C7> <0078>
<0359> <0359> [<2026>]
<035A> <035B> <2018>
<035E> <035F> <201C>
endbfrange
1 beginbfchar
<0374> <2013>
endbfchar
endcmap
CMapName currentdict /CMap defineresource pop
end
end

Как вы можете видеть, здесь нет отображения на <0020>.


Использование шрифтов в этомКстати, страница PDF довольно забавная:

Ее тело (в основном) нарисовано с использованием Calibri, но для этого используются два различных шрифтовых объекта PDF, F4 , которые используют WinAnsiEncoding от символов 32 до 122, то есть , включая глиф и F5 , который использует Identity-H и предоставляет вышеприведенный ToUnicode карта без пробела .Каждая максимальная последовательность глифов без пробела рисуется отдельно;если вся эта последовательность может быть нарисована с использованием F4 , используется этот шрифт, в противном случае используется F5 .

Таким образом, CMI, (Credit и sub-indexes отрисовываются с использованием F4 , а I’ve, “Credit и Extended” отрисовываются с использованием F5 .

В вашей проблемной строке “Credit Extended”,поэтому мы видим две последовательные последовательности, нарисованные с использованием F5 .Таким образом, вы получите 0 SingleSpaceWidth как для “Credit t , так и для Extended” E .

На первый взгляд, это единственныедве последовательные последовательности, использующие F5 , так что у вас есть эта проблема только там.


Как следствие, вы должны разработать запасную стратегию для случая двух последовательных символов, каждый из которых идет с 0SingleSpaceWidth, например, используя что-то около трети размера шрифта.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...