Interprétation des caractères grecs par FOP

Question

Pouvez-vous s'il vous plaît m'aider à interpréter les caractères grecs avec l'affichage HTML comme HTML = & # 8062; et Hex valeur 01F7E

Les détails de ces personnages se trouvent sur l'URL ci-dessous

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

Quand je lance ce personnage dans Apache FOP, ils me donnent une ArrayIndexOut de Bounds Exception

Causé par: java.lang.ArrayIndexOutOfBoundsException: -1 à org.apache.fop.text.linebreak.LineBreakUtils.getLineBreakPairProperty (LineBreakUtils.java:668) à org.apache.fop.text.linebreak.LineBreakStatus.nextChar (LineBreakStatus. java: 117)

Lorsque j'ai regardé dans le code FOP, je ne pouvais pas comprendre le besoin de lineBreakProperties [] [] Array dans LineBreakUtils.java.

J'ai également remarqué que FOP échoue pour tous les caractères grecs mentionnés sur la page ci-dessus qui ne sont pas affichables avec l'erreur similaire.

Quels sont ces caractères spéciaux?
Pourquoi leur non affichage pour ces caractères sont-ils des sauts de ligne ou des tabulations?
Est-ce que quelqu'un a résolu un problème similaire avec FOP?

Answer 1

Réponse de Apache

À première vue, cela semble être un oubli mineur dans la mise en œuvre d'Unicode dans FOP Sauts de ligne. Ceci ne prend pas en compte la possibilité qu'un code donné ne soit pas affecté à une 'classe' dans un contexte de rupture de ligne. (= U + 1F7E ne figure pas dans le fichier http://www.unicode.org/Public/UNIDATA/LineBreak.txt, qui est utilisé comme base pour générer ces tableaux dans LineBreakUtils.java)

D'autre part, on pourrait soulever évidemment la question de savoir pourquoi vous avez si désespérément besoin avoir un codepoint non affecté dans votre sortie. Êtes-vous absolument sûr de l'avoir besoin? Si oui, pouvez-vous préciser la raison exacte? (c'est-à-dire, à quoi sert exactement ce codepoint non affecté?)

La 'solution' la plus simple semble être à peu près comme suit:

Index: src/java/org/apache/FOP/text/linebreak/LineBreakStatus.java

--- src/java/org/apache/fop/texte/linebreak/LineBreakStatus.java (révision 1054383) +++ src/java/org/apache/fop/text/linebreak/LineBreakStatus.java (travail copie) @@ - 87,6 +87,7 @@

 /* Initial conversions */ 
    switch (currentClass) { 

+ case 0: // Codepoint non affecté: considérer comme AL? cas LineBreakUtils.LINE_BREAK_PROPERTY_AI: cas LineBreakUtils.LINE_BREAK_PROPERTY_SG: cas LineBreakUtils.LINE_BREAK_PROPERTY_XX:

Ce que cela fait, est assigner la classe « AL » ou « alphabétique » à tout point de code qui n'a pas été affecté par une classe Unicode. Cela signifie qu'il sera traité comme une lettre régulière. Maintenant, la raison pour laquelle je pose la question de savoir si vous êtes sûr de savoir ce que vous faites, c'est que cela peut s'avérer indésirable. Peut-être que le personnage en question doit être traité comme un espace plutôt que comme une lettre. Unicode ne définit pas U + 1F7E autrement que comme un caractère "réservé", donc il est logique qu'Unicode ne puisse pas dire ce qui devrait arriver avec ce personnage dans le contexte de la rupture de ligne ...

Cela dit, il est également faux de FOP de planter dans ce cas, donc le bug est définitivement authentique.

Answer 2

Le point de code U + 1F7E fait partie du bloc grec Extended Unicode. Mais cela ne représente aucun caractère réel; c'est un point de code réservé mais non affecté. Voici le tableau d'Unicode 6.0: http://www.unicode.org/charts/PDF/U1F00.pdf. Ainsi, les erreurs que vous obtenez ne sont peut-être pas si surprenantes.

Answer 3

j'ai couru un fichier FO qui comprenait l'<fo:block> suite à la fois FOP 0,95 et FOP 1.0:

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

J'ai eu la même java.lang.ArrayIndexOutOfBoundsException que vous voyez.

Lorsque vous utilisez un caractère « réel » à côté, il n'y avait pas d'erreur:

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

Il semble que vous devez vous assurer que votre flux de données ne contient pas non-caractères comme U + 1F7E.