Intégrité des fichiers pdf

Bonjour,

J'ai créé un gros document (près de 400 pages) avec pdflatex et qui
intègre plusieurs graphiques produit avec Pstricks puis convertis en
pdf. Le document semble correct à l'écran et l'impression sur une
imprimante Laser postscript grand public est impeccable. La belle vie
quoi :-)

Malheureusement, l'imprimante (la flasheuse (?)) de mon imprimeur
n'accepte pas le document. Police manquante qu'elle nous sort, sans
précisions supplémentaires.

Même pas le nom de la police ?
Un flasheuse ne connais pas la notion de police par défaut chère à
Adobe et à un grand nombre d'imprimantes. S'il n'y a pas de fonte, elle
gueule... et à mon avis elle a bien raison.
Bref, lorsqu'on compile un document, il faut demander d'intégrer
*toutes* les fontes, y compris les « standard » PS et PDF. Cela se régle
dans les fichiers de configuration des map

Chez l'imprimeur ils ont pu contourner le problème (ils ont extrait une
à une les pages du document avec inDesign) mais je voudrais éviter que
cela se reproduise à nouveau.

Je ne vois pas en quoi le fait d'extraire les pages peut permettre de
résoudre le problème. La seule chose que cela permettrait, c'est de
localiser le problème à la limite. Mais si c'est vraiment un problème de
police manquante, le problème risque d'arriver sur toutes les pages :-)
Bref, je n'ai pas bien compris ce passage par InDesign.

Y a-t-il un outil -- sous Mac OS X -- permettant de vérifier l'intégrité
d'un pdf?

Acrobat Reader permet de voir qu'elles sont les fontes intégrés au
document me semble-t-il. Pour le reste, c'est un question trop pdfesque
pour que je puisse être vraiment utile.

Merci d'avance pour votre aide
Daniel

Notes:

1- Il y a 5-6 pages éparpillées dans le document qui n'ont pas pu être
récupérées avec inDesign. Y a-t-il quelque chose que je peux regarder
dans le code pdf de celles-ci (que «j'imprimerais» dans des fichiers pdf
séparés), pour tenter d'identifier le problème?

Ben, voilà ! Le problème est localisé. Il doit y avoir un petit bout
de quelque chose en courier, times ou autres joyeusetés.

2 - Souvent, avant le passage par inDesign, en tentant d'imprimer
certains lots de pages ne contenant pas les 5-6 pages fautives,
l'impression refusait quand même de se lancer.

Avec la flasheuse ? C'est normal.

3 - Avec Acrobat, dans la liste des propriétés, je vois toute une liste
de polices (du genre CRMI10 Jeux partiels incorporés, type 1, encodage
ANSI). Y a-t-il quelque chose que je peux chercher là?

Oui ! Voir si *toutes* les polices utilisées sont bien incorporées.

Suivi sur FCOMOSX

À part pour cette histoire de réglage de fichier map qui peut être
spécifique au Mac, le problème n'est pas lié à une machine ou à un
système d'exploitation. Enfin, il me semble.

Jean-Côme Charpentier

--
Ce n'est pas du machisme caractérisé de dire que Mlle Henry est une
geekette que j'imagine fort bien passer par des phases d'action
coercitive (musclée) vis à vis des bécanes (spécifiquement celles qui
ne tournent pas sous NetBSD).
-+- JKr in fr.comp.text.tex -+-

J'ai créé un gros document (près de 400 pages) avec pdflatex et qui
intègre plusieurs graphiques produit avec Pstricks puis convertis en
pdf. Le document semble correct à l'écran et l'impression sur une
imprimante Laser postscript grand public est impeccable. La belle vie
quoi :-)

Malheureusement, l'imprimante (la flasheuse (?)) de mon imprimeur
n'accepte pas le document. Police manquante qu'elle nous sort, sans
précisions supplémentaires.

Les utilitaires pdflatex et autres ghostscript produisent, s'ils sont
mal paramétrés, des fichiers PDF souvent inexploitables chez
l'imprimeur, tant sur la gestion des polices que sur celle des couleurs.
Lorsque vous lancez une impression sur votre imprimante Laser, vous
chargez dans le PostScript les polices présentes et actives sur l'OS,
d'où un résultat satisfaisant. L'imprimeur, lui, ne dispose pas
forcément des polices que vous avez utilisées sur votre propre système.
En PAO, c'est une hérésie de se fier à ce que l'on voit à l'écran, cela
ne renseigne en rien sur la structure même du fichier, à savoir, dans
votre cas, si les polices sont oui ou non incorporées au PDF.

Bref, lorsqu'on compile un document, il faut demander d'intégrer
*toutes* les fontes, y compris les « standard » PS et PDF.

Les polices "standard" ne sont pas indispensables dans tous les cas.

Je ne vois pas en quoi le fait d'extraire les pages peut permettre de
résoudre le problème. La seule chose que cela permettrait, c'est de
localiser le problème à la limite. Mais si c'est vraiment un problème de
police manquante, le problème risque d'arriver sur toutes les pages :-)
Bref, je n'ai pas bien compris ce passage par InDesign.

Il ne s'agit pas d'extraire mais d'importer le PDF dans un fichier
InDesign. C'est une astuce qui permet ensuite de générer et de
réencoder, depuis InDesign, un PostScript et/ou un PDF en incorporant
correctement les polices, à condition que ces dernières soient présentes
et actives sur le système sur lequel tourne InDesign.

Y a-t-il un outil -- sous Mac OS X -- permettant de vérifier
l'intégrité d'un pdf?

Oui, le plus connu est PitStop Pro (Enfocus). C'est un plug-in pour
Acrobat. Il existe également une version pour Windows.

Acrobat Reader permet de voir qu'elles sont les fontes intégrés au
document me semble-t-il.

Non, Acrobat Reader donne seulement la liste des polices utilisées. Cela
ne prouve pas que les polices sont bien incorporées au fichier.

3 - Avec Acrobat, dans la liste des propriétés, je vois toute une
liste de polices (du genre CRMI10 Jeux partiels incorporés, type 1,
encodage ANSI). Y a-t-il quelque chose que je peux chercher là?

Oui ! Voir si *toutes* les polices utilisées sont bien incorporées.

Non, encore une fois, les propriétés du fichier ne permettent pas de
savoir si les polices sont bien incorporées.

Pour être sûr de fournir un fichier exploitable chez l'imprimeur, il
faut avoir recours à une application capable de confronter le fichier à
un cahier des charges, c'est-à-dire une norme, dans l'idéal, celle de
l'imprimeur (sous PitStop, il s'agit d'un Profil de Certification). On
parle de procédure de preflight ou de contrôle en amont. Si la structure
du fichier est conforme au cahier des charges, alors on est assuré de
faciliter le traitement du fichier par l'imprimeur.

Le post initial aurait dû être adressé à fr.comp.graphisme.pao.
Cependant, je doute que l'on puisse y trouver, jusqu'à preuve du
contraire, beaucoup d'aide car les opérateurs PAO, malgré leur culture
Mac, ne sont pas, en général, familiers des utilitaires Unix (LaTeX,
pdflatex), d'où la difficulté de pouvoir donner une procédure précise et
fiable au sujet de l'incorporation des polices lors de la compilation du
PDF. A propos, "compiler", dans l'oreille d'un opérateur PAO, est un
terme quelque peu abusif, même si c'est l'usage avec LaTeX, on préfère
plutôt le terme "convertir". Quoi qu'il en soit, qu'il s'agisse de
conversion ou de compilation, le fichier n'est pas "normalisé" tant
qu'il n'a pas été confronté à un cahier des charges. En PAO, on
travaille surtout avec QuarkXpress, InDesign, Illustrator,
Photoshop,Acrobat et Distiller pour exécuter des maquettes, tous ces
logiciels pouvant être assistés de divers plug-in et d'utilitaires de
normalisation ; en prépresse, on aura en plus accès à des flux de
production et autres RIPs dédiés, les flux étant capables de normaliser
les fichiers.

Cordialement,
Christophe

[En-tête "Followup-To:" positionné à fr.comp.text.tex.]
Le 10-08-2006, chris <cfarouault@no-spam.free.fr> a écrit :

Les utilitaires pdflatex et autres ghostscript produisent, s'ils sont
mal paramétrés, des fichiers PDF souvent inexploitables chez
l'imprimeur, tant sur la gestion des polices que sur celle des couleurs.

Je suis curieux d'en savoir davantage sur la bonne configuration de
pdflatex pour la gestion correcte des couleurs... vous avez des infos ?

Cordialement,
--
Sébastien

Jean-Côme Charpentier wrote:

Malheureusement, l'imprimante (la flasheuse (?)) de mon imprimeur
n'accepte pas le document. Police manquante qu'elle nous sort, sans
précisions supplémentaires.

Même pas le nom de la police ?

Non. Pas sur le «moniteur» branché à l'imprimante (au serveur?).
Cependant, lors des tentatives d'envoie du document via différents
logiciels, il y a eu un momment donné la mention de la police MSAM qui
était absente (or, elle semble avoir été intégrée selon Acrobat, mais
avec la mention Jeu partiel (même mention pour toutes les polices).

Bref, lorsqu'on compile un document, il faut demander d'intégrer
*toutes* les fontes, y compris les « standard » PS et PDF. Cela se régle
dans les fichiers de configuration des map

Là vous me perdez un peu :-)

Avec Google, "Configuration de map" me renvoie à 2 messages concernant
les polices: votre réponse et une autre réponse de vous dans les archive
de Gutenberg. :-)

Où dois-je regarder? Sous quel autre nom? «Configuration mappage
police» renvoie à des documents concernant le mappage des claviers.

Est-ce un paramètre qu'il faut fournir à Ghostscript au moment de la
compilation?

1- Il y a 5-6 pages éparpillées dans le document qui n'ont pas pu être
récupérées avec inDesign. Y a-t-il quelque chose que je peux regarder
dans le code pdf de celles-ci (que «j'imprimerais» dans des fichiers
pdf séparés), pour tenter d'identifier le problème?

Ben, voilà ! Le problème est localisé. Il doit y avoir un petit bout
de quelque chose en courier, times ou autres joyeusetés.

J'ai exporté l'une de ces pages avec Acrobat. La liste des polices pour
cette page contient des répétitions. Par exemple la ligne 1 et 3

CMMI10 Encodage personnalisé - jeux partiels incorporés
CMMI10 Encodage Romain - jeux partiels incorporésé
CMMI10 Encodage personnalisé - jeux partiels incorporés

mais ce doit être la façon dont Acrobat analyse la page qui amène cela
et non pas deux polices de même noms qui pourraient générer des conflits.

Les autres polices sont:

CMR7, 8, 10, 12
CMSY10
MSAM10
MSBM
SFBX1000
SFRM1000

dont certaines (la plupart) avec encodages Roman et personnalisés


Remarque: Toutes les pages (6) qui n'ont pas pu être récupérées avec
inDesign contiennent des figures réalisées avec PSTricks puis le fichier
.eps converti en .pdf pour être intégrés ensuite dans le document
principal avec includegraphics. Toutefois, j'ai fait un changement
d'échelle. Si la police utilisée pour le dessin est MSAM10 par exemple
et que je le comprime à 80% lors de l'import, ne faudrait-il pas qu'il y
ait une police MSAM8? Si la taille est absente, la police est-elle
interpollée à partir d'une autre de taille différente??


Cependant, la page qui précède et suit les 6 pages mentionnées dans le
paragraphe précédent contiennent aussi des figures qui ont été réalisées
de la même façon (et sont semblables).

Grrr... :-)

Suivi sur FCOMOSX

À part pour cette histoire de réglage de fichier map qui peut être
spécifique au Mac, le problème n'est pas lié à une machine ou à un
système d'exploitation. Enfin, il me semble.

Jean-Côme Charpentier

Comme je cherchais un logiciel sur MacOSX pour vérifier l'intégrité d'un
pdf, j'avais pensé qu'il était souhaitable de faire suivre là.


Merci pour votre temps.

Daniel

chris wrote:

Les utilitaires pdflatex et autres ghostscript produisent, s'ils sont
mal paramétrés, des fichiers PDF souvent inexploitables chez
l'imprimeur, tant sur la gestion des polices que sur celle des couleurs.
Lorsque vous lancez une impression sur votre imprimante Laser, vous
chargez dans le PostScript les polices présentes et actives sur l'OS,
d'où un résultat satisfaisant. L'imprimeur, lui, ne dispose pas
forcément des polices que vous avez utilisées sur votre propre système.

1) Suffit-il alors de fournir les polices référencées? Comment puis-je
distinguer les polices qui sont incluses dans le document et celles qui
sont référencées? (oups, je *pense* avoir trouvé... voir 6 paragraphes
plus bas)

2) Avec Acrobat, je peux exporter en fichier .eps avec l'option
d'intégrer les polices référencées. Serait-ce une façon de contourner le
problème (quitte à reconvertir en .pdf le fichier .eps)? Est-ce que je
risque de générer d'autres types de problèmes?

Y a-t-il un outil -- sous Mac OS X -- permettant de vérifier
l'intégrité d'un pdf?

Oui, le plus connu est PitStop Pro (Enfocus). C'est un plug-in pour
Acrobat.

Oups, PitStop Pro 7 : 556,99$US.
Je télécharge la démo de 30 jours de la version 6.

Pour être sûr de fournir un fichier exploitable chez l'imprimeur, il
faut avoir recours à une application capable de confronter le fichier à
un cahier des charges, c'est-à-dire une norme, dans l'idéal, celle de
l'imprimeur (sous PitStop, il s'agit d'un Profil de Certification). On
parle de procédure de preflight ou de contrôle en amont. Si la structure
du fichier est conforme au cahier des charges, alors on est assuré de
faciliter le traitement du fichier par l'imprimeur.

Sans avoir installé PitStop, je vois que dans Acrobat 7 il y a l'article
«Contrôle en amont» avec plusieurs profils. Est-ce que le rôle de
PitStop est d'ajouter des profils?


Je viens de lancer le Contrôle en amont avec le profil «List text using
non-embedded fonts» (bon, on dirait que je viens de trouver une réponse
à l'une de mes questions). Mais est-ce un outil fiable? L'imprimeur
avait détecté l'absence d'une police MSAM que n'a pas détecté Acrobat.

Toutefois, il a trouvé:

Page 15: Times-Roman 8.407 pt Type 1 non incorporé(e) Noir (1.0)
surimpression: désactivé

Page 16: Times-Roman 3.905 pt Type 1 non incorporé(e) Noir (1.0)
surimpression: désactivé

Page 16: Times-Roman 7.0287 pt Type 1 non incorporé(e) Noir (1.0)
surimpression: désactivé


C'est du texte - à l'origine en 10 et 18 points) qui se trouve dans 2
figures produites avec Canvas, enregistrées en .eps, converties en .pdf

Pourtant, dans ce même Acrobat 7, dans les Propriétés du document,
onglet Polices, elle semble y être:

Times-Roman
Type : Type 1
Encodage : Standard
Police réelle : Times-Roman
Type de police réelle : TrueType


De plus, ces 2 pages ont pu être imprimées directement sans passer par
l'astuce d'utiliser inDesign. Le problème est arrivé une dizaine de
pages plus loin.

<...> A propos, "compiler", dans l'oreille d'un opérateur PAO, est un
terme quelque peu abusif, même si c'est l'usage avec LaTeX, on préfère
plutôt le terme "convertir".

Composer serait-il un compromis acceptable? :-)


Quoi qu'il en soit, qu'il s'agisse de

conversion ou de compilation, le fichier n'est pas "normalisé" tant
qu'il n'a pas été confronté à un cahier des charges. En PAO, on
travaille surtout avec QuarkXpress, InDesign, Illustrator,
Photoshop,Acrobat et Distiller pour exécuter des maquettes, tous ces
logiciels pouvant être assistés de divers plug-in et d'utilitaires de
normalisation ; en prépresse, on aura en plus accès à des flux de
production et autres RIPs dédiés, les flux étant capables de normaliser
les fichiers.

Merci pour votre réponse.

Daniel