🚀 go-pugleaf

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