Интерпретация греческих символов по FOP - PullRequest
1 голос
/ 14 декабря 2010

Не могли бы вы помочь мне интерпретировать греческие символы с отображением HTML как HTML = & # 8062;и шестнадцатеричное значение 01F7E

Подробную информацию об этих символах можно найти по нижеуказанному URL

http://www.isthisthingon.org/unicode/index.php?page=01&subpage=F&hilite=01F7E

Когда я запускаю этот символ в Apache FOP, они даютисключение ArrayIndexOut of Bounds

Вызывается: java.lang.ArrayIndexOutOfBoundsException: -1 в org.apache.fop.text.linebreak.LineBreakUtils.getLineBreakPairProperty (LineBreakUtils.java:668) в org.apache.text.linebreak.LineBreakStatus.nextChar (LineBreakStatus.java:117)

Когда я посмотрел код FOP, я не смог понять необходимость массива lineBreakProperties [] [] в LineBreakUtils.java.

Я также заметил, что FOP не работает для всех греческих символов, упомянутых на приведенной выше странице, которые невозможно отобразить с похожей ошибкой.

Что это за специальные символы?
Почему они не отображаютсядля этих символов это переносы строк или табуляция?
Кто-нибудь решал подобную проблему с FOP?

Ответы [ 3 ]

0 голосов
/ 01 января 2011

Я запустил файл FO, который включал следующие <fo:block> через FOP 0,95 и FOP 1.0:

<fo:block>Unassigned code point: &#x1F7E;</fo:block>

Я получил то же исключение java.lang.ArrayIndexOutOfBoundsException, которое вы видите.

При использовании смежного «реального» символа ошибки не было:

<fo:block>Assigned code point: &#x1F7D;</fo:block>

Поэтому кажется, что вы должны убедиться, что ваш поток данных не содержит не-символов, таких как U + 1F7E.

0 голосов
/ 07 января 2011

Ответ от Apache

На первый взгляд, это похоже на незначительный недосмотр в реализации переноса строки Unicode в FOP. Это не принимает во внимание возможность того, что данной кодовой точке не присвоен «класс» в контексте переноса строки. знак равно U + 1F7E не появляется в файле http://www.unicode.org/Public/UNIDATA/LineBreak.txt,, который используется в качестве основы для генерации этих массивов в LineBreakUtils.java)

С другой стороны, очевидно, можно было бы поставить вопрос, почему вам так отчаянно нужно иметь неназначенную кодовую точку в выходных данных. Вы абсолютно уверены, что вам это нужно? Если да, то можете ли вы уточнить точную причину? (т.е. для чего именно используется эта неназначенная кодовая точка?)

Самое простое «исправление» выглядит примерно так:

Индекс: src / java / org / apache / fop / text / linebreak / LineBreakStatus.java

--- src / java / org / apache / fop / text / linebreak / LineBreakStatus.java (редакция 1054383) +++ src / java / org / apache / fop / text / linebreak / LineBreakStatus.java (работает копия) @@ -87,6 +87,7 @@

     /* Initial conversions */
     switch (currentClass) {

+ case 0: // Неназначенная кодовая точка: считать AL? case LineBreakUtils.LINE_BREAK_PROPERTY_AI: case LineBreakUtils.LINE_BREAK_PROPERTY_SG: case LineBreakUtils.LINE_BREAK_PROPERTY_XX:

Для этого нужно назначить класс 'AL' или 'Alphabetic' любой кодовой точке, которой Unicode не присвоен класс. Это означает, что оно будет рассматриваться как обычное письмо. Причина, по которой я задаю вопрос, уверены ли вы, что знаете, что делаете, заключается в том, что это может оказаться нежелательным. Возможно, рассматриваемый персонаж нужно рассматривать как пробел, а не как букву. Unicode не определяет U + 1F7E, кроме как «зарезервированный» символ, поэтому имеет смысл, что Unicode не может сказать, что должно произойти с этим символом в контексте переноса строки ...

Тем не менее, в этом случае сбой FOP также является ошибкой, поэтому ошибка определенно подлинная.

0 голосов
/ 23 декабря 2010

Кодовая точка U + 1F7E является частью блока расширенного греческого Unicode.Но это не представляет какой-либо фактический характер;это зарезервированный, но неназначенный код.Вот диаграмма из Unicode 6.0: http://www.unicode.org/charts/PDF/U1F00.pdf.

Так что ошибки, которые вы получаете, возможно, не столь удивительны.

...