[XSL-FO] Erreur FOP

Bonjour,
je me trouve bloqué sur un problème de mémoire FOP.

Pour planter le décors j'ai un Fichier XML qui contient un tableau avec (Ligne+)
et mon XSL qui affiche chaque ligne sur 2 pages dépendantes.

La première m'affiche certains critères, la suivante les mêmes lignes avec d'autres critères.

Pour ce faire j'ai créé deux template PageImpaire et PagesPaire pour afficher l'ensemble de mon tableau , sachant que chacune des lignes visuelles aura sa taille propre (donc impossible de savoir combien de lignes seront affichées par page à l'avance)

En simplifiant l'algo ça donne

PageImpaire(0,0) [->CallTemplate] PagePaire(position_init,position_fin)
[-> CallTemplate] PageImpaire(position_fin+1,nbLigneTotal)
[->CallTemplate] PagePaire(position_fin+1,nbLigneTot)
... en récursif jusqu'a la fin du tableau.

Pour une quinzaine de page ça passe, mais après plantage ...
Le message est :

Code:

---

1 2 3 4 5

org.apache.fop.fo.FOTreeBuilder$MainFOHandler endElement WARNING : Mismatch : page-sequence (http://www.w3.org/1999/XSL/Format) vs. root(http://www.w3.org/1999/XSL/Format) java.lang.OutOfMemoryError Exception in thread "main"

---

Je comprends bien qu'il y a une surcharge de mémoire quelque part... mais je n'arrive pas à la faire disparaitre, le Xprof ne m'indique pas grand chose, le nombre de thread est stable... mais focément à chaque appel récursif j'augmente significativement les ressources utilisées par XPATH sans jamais les libérer...

Auriez vous une idée pour supprimer ce problème ou du moins une piste qui m'aiderai à avancer? (sachant qu'en plus j'épluche depuis 2-3 jours les ressources de fop)

Merci d'avance.

Cdt.

Alex.

Bonjour,

comme tu t'en doutes, ton souci vient de la profondeur de récursion. Ce n'est pas tant XPath (il n'y a pas d'effet de bord avec XPath donc pas de débordement de mémoire) que les appels imbriqués de tes templates nommés avec à chaque fois la sauvegarde du contexte qui posent problème...

Il va falloir revoir ton algorithme et adopter quelque chose de plus itératif.

Merci pour votre réponse.

Le problème c'est que :
1/ Ce n'est pas moi qui ait étudié l'algo
2/ Compte tenu de la portée des variables en XSLT faire une boucle itérative resterai très compliquée. En effet comme je l'expliquais précédement nous ne connaissons pas le nombre de ligne par page, il faudrait donc pouvoir le récupérer à la sortie du template, mais dans le peu de connaisance que j'ai en XSLT les variables sont locales et il n'existe aucun pointeur dessus.
La solution de facilité serai de dire j'affiche quoi qu'il arrive 20 lignes par exemple mais celà limiterai fortement l'affichage des pages car elles pourraient se retrouver remplie à 100% ou à 10% suivant le type de données :/

Du coup je me pose une question simple mais qui conceptuellement me dérange fortement ...
C'est une appli Java qui génère le XML qui pour l'instant à une forme (pour la partie concenant ce problème)

Code:

---

1 2 3

<tableau +> <ligne *>

---

ne serait ce pas interessant du coup lors de la génération passer par une structure intermédiaire du style :

Code:

---

1 2 3 4

<tableau +> <page +> <ligne *>

---

Et du coup transvaser le calcul du nombre de ligne dans une page de mon template à mon code java. Ce n'est pas propre du tout au niveau métier car nous déleguerions à Java une tâche propre au XSLT, mais celà permettrait à coup sur de pouvoir itérer sans soucis.

Cdt.

Bon et bien j'ai supprimé la récursivité en utilisant la structure décrite précédemment

Code:

---

1 2 3 4

<tableau +> <page +> <ligne *>

---

et avec un algo proche de celui-ci

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

<xsl:template name="corps"> <xsl:apply-templates select="//tableau/page" /> </xsl:template>   <xsl:template name="Page_XML" match="page"> <xsl:apply-templates select="." mode="impaire" /> <xsl:apply-templates select="." mode="paire" /> </xsl:template>   <xsl:template name="lignesPagePaire" match="ligne" mode="paire"> <!-- Mes traitements --> <fo:block break-after="page" /> </xsl:template>     <xsl:template name="lignesPageImpaire" match="ligne" mode="Impaire"> <!-- Mes traitements --> <fo:block break-after="page" /> </xsl:template>

---

Mon problème subsiste, mais l'erreur à légèrement changée... à savoir un

Code:

---

1 2 3

java.lang.OutOfMemoryError Exception in thread "main

---

J'ai beau augmenter la quantité de mémoire lors de l'exécution de java avec un -Xms et Xmx il "plante" toujours au même nombre de page.
En étudiant la quantité de mémoire allouée j'ai pu constater que celle-ci augmente sans cesse...
Comment ce fait il qu'elle ne soit jamais désalouée ?
Mon algorithme serait-il à revoir ?

Cdt.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

<xsl:template name="corps"> <xsl:apply-templates select="//tableau/page" /> </xsl:template>   <xsl:template match="page"> <xsl:apply-templates select="ligne" mode="impaire" /> <xsl:apply-templates select="ligne" mode="paire" /> </xsl:template>   <xsl:template match="ligne" mode="paire"> <!-- Mes traitements --> <fo:block break-after="page" /> </xsl:template>     <xsl:template match="ligne" mode="Impaire"> <!-- Mes traitements --> <fo:block break-after="page" /> </xsl:template>

---

Si ça ressemblait + à ça ce serait mieux

J'ai fait cette modification,
il y a du progrès, je n'ai plus de OutOfMemory, par contre visiblement je boucle sans fin. Je suis actuellement à près de 10 minutes de génération et toujours aucun résultat.

Le principe de la boucle sans fin me plairait bien, seulement pour un nombre de page moins élévé j'arrive à terme de la génération et la boucle est la même.
J'avoue avoir un peu de difficulté sur la compréhension de cette "histoire"

-------------
Trouvé pourquoi ça ne s'arretait pas.
En fait le <xsl:apply-templates select="ligne" mode="paire" /> n'arrive pas à trouver le <xsl:template match="ligne" mode="paire" /> (respectivement avec impaire)

si par contre je remet <xsl:apply-templates select="." mode="paire" /> dans ce cas il trouve bien la concordance...

Mais si je remet avec un select="." il me remange toute la mémoire.
Je deviens chèvre...

Je n'arrive pas à comprendre comment est exactement constitué ton document, notamment selon quelles conditions est inséré ton saut de page. Pourrais-tu donner un exemple ?

Un exemple concret malheureusement je ne peux pas, je vais donc tenter d'en inventer un ayant le même schéma.

Prenons une personne vendant des clous. Ses clous sont classée par taille et par fournisseurs. Il veut faire un inventaire de son stock mais les informations qu'ils veut ne tienne pas dans un tableau d'une page de large (même en mode paysage), ce qu'il décide donc est de faire un tableau sur N pages jumelles

Ainsi nous avons :
Page N ==> contient L lignes avec certaines informations
Page N+1 ==> contient les même L lignes avec d'autres informations
Page N+2 ==> contient L' lignes avec certaines informations
Page N+3 ==> contient les même L' lignes avec d'autres informations
(etc...)


La partie du fichier XML concernée est :

Code:

---

1 2 3

<tableau+> <ligne+>

---

A ce moment là rien de plus naturel que de ce dire "facile, on va faire 2 templates un pour afficher la 1ère page avec L ligne, un second affichant la seconde page, puis une itération va permettre de construire l'ensemble des pages".
Trop facile... Le vendeur ne veux pas un tableau basique mais un tableau dont les clous sont triés par fournisseurs (facile !!!) et surtout qu'a chaque nouveau fournisseur une ligne soit sautée et le nom du fournisseur rappelé et ceci sans aller à la page suivante. De plus il faut que ce soit harmonieux donc pas question qu'une page soit au 3/4 pleine et la suivante complètement pleine : le tableau doit avoir la même hauteur.
Ceci pose un problème : combien de lignes sont affichées par page? impossible à déterminer à l'avance.

L'algorithme ayant été choisi à été grosso-modo le suivant :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

TEMPLATE 1 <xsl:for-each select="//tableau"> <xsl:call-template name="TableauPart1"> <xsl:with-param name="pos_courante" select="0" /> <xsl:with-param name="nbLigneTot" select="$nbLigneTot" /> </xsl:call-template> </xsl:for-each> ...   TEMPLATE 2 <xsl:template name="TableauPart1"> <!-- ... --> <!-- on sait quelle hauteur fait chaque type de ligne (clou, saut, fournisseur) donc tant que nous ne somme pas à un certain seuil ou à la dernière ligne on affiche la ligne et on ajoute sa hauteur à la hauteur totale affichée et $pos_finale++ Une fois ce seuil (ou la dernière ligne) atteind --> <xsl:call-template name="TableauPart2"> <xsl:with-param name="positionDeb" select="$pos_courante" /> <xsl:with-param name="positionFinale" select="$pos_finale" /> </xsl:call-template>   TEMPLATE 3 <xsl:template name="TableauPart1"> <!-- ... --> <!-- on sait quelle hauteur fait chaque type de ligne (clou, saut, fournisseur) donc tant que nous ne somme pas à un certain seuil on affiche la ligne et on ajoute sa hauteur à la hauteur totale affichée Une fois ce seuil (ou la dernière ligne) atteind --> <xsl:if test="not($derniereLigne)" > <xsl:call-template name="TableauPart1"> <xsl:with-param name="positionDeb" select="$pos_finale" /> </xsl:call-template> </xsl:if>

---

Ceci ayant pour inconvéniant une forte profondeur de récursivité... avec en plus un grand nombre de for-each présent dans le code.

Le programme codé retourne pour un petit nombre de page le pdf convenablement formé, dès que l'on arrive à une quinzaine de page un OutOfMemory...
Le problème est que le document à faire peut contenir environ 300pages donc 15 est largement en dessous de ce qui est à fournir !

Reprennant cette partie du projet et en accord avec le responsable j'ai changé la structure du XML pour obenir

Code:

---

1 2 3 4

<tableau +> <page +> <ligne *>

---

Le java qui génère ce XML connait le type de ligne donc même si ce n'est pas propre c'est lui qui calcul les hauteurs de tableau dans les page et arrivé à cette hauteur il encapsule les <ligne> par un <page> . (Oui je sais BEURKK)

Du coup j'ai pu retirer la récursivité du programme et remplacer les for-each par des apply-templates (m'avait on dit moins gourmant en ressource)
Mon algo est donc devenu globalement le suivant :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

<xsl:template name="corps"> <xsl:apply-templates select="//tableau/page" /> </xsl:template>   <xsl:template name="Page_XML" match="page"> <xsl:apply-templates select="." mode="impaire" /> <xsl:apply-templates select="." mode="paire" /> <fo:block break-after="page" /> </xsl:template>   <xsl:template name="lignesPagePaire" match="ligne" mode="paire"> <!-- Mes traitements --> <fo:block break-after="page" /> </xsl:template>     <xsl:template name="lignesPageImpaire" match="ligne" mode="Impaire"> <!-- Mes traitements --> </xsl:template>

---

Notez que comme proposé j'ai tenté de remplacer

Code:

---

1 2 3 4 5 6

<xsl:apply-templates select="." mode="impaire" /> <xsl:apply-templates select="." mode="paire" /> <!-- avec --> <xsl:apply-templates select="ligne" mode="impaire" /> <xsl:apply-templates select="ligne" mode="paire" />

---

Mais ça ne match pas convenablement les lignes.

Mon problème est que j'arrive toujours pour un certain nombre de page à un OutOfMemory.

En reprenant le premier algo et améliorant les utilisations XPATH uniquement j'ai pu monter à 120 pages générées.
Avec le second algo je n'arrive qu'a 100 environ ... alors que j'ai supprimé la récursivité, et optimisé les utilisations XPATH.

Donc honnêtement je vous avouerai devenir chèvre :aie:

Auriez vous des idées de traitements? Je suis prenneur de toute proposition.

Cdt

Citation:

---

Envoyé par AlexisB

Mais ça ne match pas convenablement les lignes.

---

Eliminons de suite une hypothèse absurde : dans ton code réel, pour les modes, tu n'écris pas "impaire" d'un côté et "Impaire" de l'autre, n'est-ce pas ? Parce que la syntaxe des modes (et pratiquement tout XML, d'ailleurs) est sensible à la casse...

Citation:

---

Envoyé par AlexisB

Du coup j'ai pu retirer la récursivité du programme et remplacer les for-each par des apply-templates (m'avait on dit moins gourmant en ressource)

---

C'est l'inverse, les templates sont plus gourmands en ressources que les boucles for-each du fait du rapprochement qu'est obligé de faire le processeur XSLT entre chaque noeud sélectionné par l'apply-templates et la l'attribut select de chaque template (matching, un peu sur le principe des expresssions régulières).

Citation:

---

Eliminons de suite une hypothèse absurde : dans ton code réel, pour les modes, tu n'écris pas "impaire" d'un côté et "Impaire" de l'autre, n'est-ce pas ?

---

Effectivement je fait attention à la casse dans mon programme, c'est une erreur en retappant. (Je développe sur un poste distinct n'étant pas sur le même réseau donc je retappe tout avec mimine et hier soir j'était un peu fatigué).

Citation:

---

C'est l'inverse, les templates sont plus gourmands en ressources que les boucles for-each du fait du rapprochement qu'est obligé de faire le processeur XSLT entre chaque noeud sélectionné par l'apply-templates et la l'attribut select de chaque template

---

Snif si je puis dire... J'ai passé 3 jours à essayé de comprendre l'algo qui avait été fait et donc ... pour peu de chose ?
L'avantage est que je l'ai un peu commenté, mais donc la solution du for-each vous me la conseillé plutot que le apply-templates si je comprend bien ?

Je me pose sinon une autre question :
J'utilise un seul fo:page-sequence pour l'ensemble de mes page, ne serait-ce pas moins couteux que d'en déclarer un pour chaque paire de page (puisque je travaille en jumelage de page) voire même pour chaque page?

-------
Edit 10:19 :
J'ai remplacé les apply-templates par des for-each / call-template , mais avec cette structure aussi je tombe sur un OutOfMemory.

De plus j'ai lu que l'utilisation du XPath relatif est moins coûteux que d'utiliser un absolu. Mais jusqu'a quel niveau veaut il mieux utiliser un relatif? Parceque je suppose tout de même que si on arrive à faire ../../../toto/untoto ça doit commencer à être aussi coûteux qu'un //toto/untoto, non ?
Cdt.