La police utilisée sur mon impression n'est pas bonne

==Introduction==
Il se peut parfois et notamment avec des versions antérieures à la 10.1 d'avoir des problème de tailles de polices sur les impressions. Cela est dû à des problèmes de ressources liés à une mauvaise utilisation du fichier ressource lstobj.txt 
Cette documentation explique comment diagnostiquer ce problème et y remédier.

==Gestion des polices au sein du fichier PCL==

La structure générale d'un fichier PCL est comme ceci :
*Définition des ressources utilisées par le flux (Fond de page et polices)
*Appel de ces ressources au niveau page <br/>


Dans ce chapitre nous allons voir comment lire le flux PCL pour repérer ces 2 étapes.

===Fonctionnement Unicode===

*Fond de page :
**Définition de la police dans le flux PCL :
***1er Police fond de page : ESC*c1D
***2ième Police fond de page : ESC*c2D
***etc
**Appel de la police dans le flux PCL :
***1er Police fond de page : ESC(1X
***2ième Police fond de page : ESC(2X
***Etc

**Définition du fond de page dans le flux PCL :
***&f00001y8x0X (avec 00001 correspond au numéro de police dans le lstobj)
**Appel du fond de page dans le flux PCL :
***&f00001y2X  (défini au niveau page)

*Partie dynamique MAP :
**Définition de la police dans le flux PCL :
***1er Police partie MAP : ESCc15000D  (peu importe le numéro de la police dans le lstobj)
***2ième Police partie MAP : ESCc15001D  (peu importe le numéro de la police dans le lstobj)
***3ième Police partie MAP : ESCc15002D  (peu importe le numéro de la police dans le lstobj)

**Appel de la police dans le flux PCL :
***1er Police partie MAP : ESC(15000X (peu importe le numéro de la police dans le lstobj)
***2ième Police partie MAP  : ESC(15001X (peu importe le numéro de la police dans le lstobj)
***3ième Police partie MAP  : ESC(15002X (peu importe le numéro de la police dans le lstobj)
***etc

===Fonctionnement non Unicode===

*Fond de page :
**Définition de la police dans le flux PCL :
***1er Police fond de page : ESC*c30000D
***2ième Police fond de page : ESC*c30001D
***etc
**Appel de la police dans le flux PCL :
***1er Police fond de page : ESC(30000X
***2ième Police fond de page : ESC(30001X
***Etc

**Définition du fond de page dans le flux PCL :
***&f00001y8x0X (avec 00001 correspond au numéro de police dans le lstobj)
***Appel du fond de page dans le flux PCL :
***&f00001y2X  (défini au niveau page)

*Partie dynamique MAP :
**Définition de la police dans le flux PCL :
***1er Police partie MAP : ESC*c00001D  (avec 00001 correspond au numéro de police dans le lstobj)
***2ième Police partie MAP : ESC*c00002D  (avec 00002 correspond au numéro de police dans le lstobj)

**Appel de la police dans le flux PCL :
***1er Police partie MAP : ESC(00001X (avec 00001 correspond au numéro de police dans le lstobj)
***2ième Police partie MAP  : ESC(00002X (avec 00002 correspond au numéro de police dans le lstobj)
***etc

==Explication du problème==

===Cause===
Dans le flux PCL généré, nous avons un appel de police pour laquelle aucun définition n’a été faite. Soit en d’autres termes, nous avons par exemple un ESC(15000X (appel de la police 15000) qui n’a pas son pendant ESCc15000D (définition de la police 15000).

===Raison technique===
Lors de la création du fichier PCL par notre moteur de composition de document (MAP_815), nous lisons la table MAPLNK (ou le fichier spt sur WIN/LIN). A l’intérieur de celui-ci nous avons une liste de ressources (police et fond de page associé à la maquette). Pour chacune de ces ressources nous récupérons le numéro de ressources associé à son type. Nous récupérons les enregistrements ayant ce même numéro et type de ressource dans la table MAPOBJ . Nous prenons le numéro et son contenu et nous le plaçons dans le flux PCL pour la partie définition. <br/>
'''Or dans le cas où aucune correspondance n’est trouvé entre numéro de ressource / Type de ressource du MAPLNK et MAPOBJ, alors aucune définition ne sera insérée dans le flux PCL.''' <br/>
Par conséquence, on se retrouve bien avec l’appel <u>sans</u> la définition.<br/> 

Ceci est dût à un conflit de ressource générée à cause d’une mauvaise utilisation du lstobj.txt

===Solution===
Exécuter la requete suivante : 

 SELECT mapnam,mapseq
 FROM maplnk l
 INNER JOIN mapobj o 
 ON   l.objtyp=o.objtyp 
 AND  (   
        (l.objnam=o.objnam and l.objnum<>o.objnum) 
     OR (l.objnam<>o.objnam and l.objnum=o.objnum)
     ) 
 WHERE l.objtyp<>’XPS’ 
 GROUP BY l.mapnam, l.mapseq 
 ORDER BY l.mapnam, l.mapseq


Supprimer tous les formats listés par celle-ci, regénérer le lstobj par un CALL MAP823, regénéré toutes les maquettes supprimer en s’assurant de bien utiliser ce nouveau lstobj.

===Commentaire===
Depuis la version 10.1 de MAPPING IBM-i, une vérification est faite dans le programme d'importation de maquette pour être sur que l'utilisateur n'est pas sur le point d'importer un format qui va comprendre les ressources du serveur.

==Lien utile==
Pour vérifier votre environnement, vous pouvez vous référez à la documentation suivant : <br/>
[[OPALE:10.1:Controle intégrité des ressources IBM-i|Controle de l'intégrité des ressources IBM i]]