puis l'exportation directe par LibreOffice produit le fichier : mon_excellent_document.pdf.
Les métadonnées (ces données relatives aux données) associées à un document, quel qu'il soit, fournissent des informations utiles à l'utilisateur (qui est l'auteur, quelles sont les limitations sur l'utilisation, la copie?) ou au traitement machine pour la gestion documentaire ou la recherche automatique (mots-clés, description, …).
Le format PDF d'Adobe, très utilisé pour transmettre ou conserver des documents sous une forme compacte, a recontré un succès tel qu'il est aujourd'hui lisible à peu près partout. De plus, nombreuses sont les applications qui savent exporter des données directement dans ce format. En outre, sous certaines conditions, un fichier PDF sait embarquer des métadonnées.
Si un fichier PDF est important et voué à quelque pérennité, il est donc important de le doter de métadonnées garantissant une exploitation optimale.
En fait, d'après l'aide d'Adobe, il existe deux façons de stocker des métadonnées dans un fichier PDF.
L'expérience montre qu'éditer les deux jeux de métadonnées dans un fichier produit une incohérence qui fait échouer le test de validation de pdf-tools. Selon son besoin, l'utilisateur devra donc choisir l'une des deux procédures décrites ci-dessous.
Le dictionnaire d'information comporte des clefs prédéfinies (title, author, subject, producer, keywords) mais peut être étendu
par les applications ou l'utilisateur. Par exemple, LibreOffice sait exporter un document en pdf. Par ailleurs, LibreOffice permet d'attribuer à
un document des propriétés prédéfinies ou personnalisées. Il est intéressant de se demander ce qui en est tranmis par LibreOffice au document
PDF exporté. Pour faire le test, un document d'exemple mon_excellent_document.odt est créé et ses principales propriétés sont
réglées dans LibreOffice comme montré par les captures suivantes :
puis l'exportation directe par LibreOffice produit le fichier :
mon_excellent_document.pdf.
Sous Linux (Ubuntu/MATE, pour être précis), la consultation des propriétés de ce fichier avec evince, par exemple, montre le résultat
suivant.
En ligne de commande, l'excellent utilitaire pdftk nous dit la même chose sous une forme qui montre la structure en triplets du dictionnaire
dans le fichier :
InfoBegin ← marqueur d'entrée dans le dictionnaire
InfoKey: ← nom de la clef
InfoValue: ← contenu de la clef
$ pdftk mon_excellent_document.pdf dump_data | grep Info
InfoBegin
InfoKey: Subject
InfoValue: exemple de texte exportable en PDF
InfoBegin
InfoKey: CreationDate
InfoValue: D:20150614194433+02'00'
InfoBegin
InfoKey: Keywords
InfoValue: texte, pdf, métadonnées, propriétés
InfoBegin
InfoKey: Title
InfoValue: Mon excellent document
InfoBegin
InfoKey: Creator
InfoValue: Writer
InfoBegin
InfoKey: Producer
InfoValue: LibreOffice 4.2
Ce résultat est intéressant mais en même temps frustrant. Quelques informations sont bien récupérées mais d'autres manquent cruellement (pas d'auteur, les "droits" insérés à la main dans LibreOffice n'apparaissent pas…). En revanche des informations secondaires sont incluses comme le producteur identifié comme LibreOffice et le Creator identifié comme Writer qui ne paraissent pas essentielles pour caractériser le document PDF en tant que support d'information et vecteur de connaissance. En outre, par comparaison, notamment, avec le jeu de descripteurs "minimal" du Dublin core (cf. la description par la BNF ou, pour une application pratique, le générateur de métadonnées éducaméta), les descripteurs paraissent insuffisants.
Qu'à cela ne tienne, il est facile de les compléter, car pdftk permet aussi d'écrire des métadonnées dans le fichier. Pour cela, il faut d'abord créer un simple fichier texte avec la structure en triplets idoine (en codage UTF-8, pour s'éviter les ennuis avec les caractères spéciaux).
Une première possibilité est de n'y mettre que les descripteurs prédéfinis par le format PDF. Cependant, il est possible d'en ajouter d'autres, comme dans l'exemple du fichier mes_metadata_ouida.txt.
Il faut remarquer que, dans la norme Dublin Core (abrégée en DC dans la suite), il n'y a pas d'éléments descriptifs "Auteur" car c'est
l'élément "Créateur" qui désigne le principal responsable de la création du contenu, qu'il s'agisse d'une personne physique ou d'une
organisation. Ceci amène à affecter la même valeur à ces deux clefs par souci de compatibilité d'où une redondance manquant d'élégance.
Par ailleurs, le DC inclut un élément décrivant le contenu intellectuel du document (à l'exclusion de la période ou de la zone géographique
couvertes, réservée à l'élément "couverture" (Coverage)) et qui peut être exprimé sous forme de mots clés préférablement choisis
dans un vocabulaire contrôlé. Au contraire, le dictionnaire d'information du PDF prévoit par défaut deux descripteurs distincts pour le sujet
et pour les mots-clés. Pour rendre ces deux approches compatibles, il est proposé de ranger dans le champ "mots-clés" du PDF les mots-clés
décrivant le contenu et dans "sujet" le descripteur "couverture" du DC précisant le sujet en termes spatio-temporels.
De même, par convention, il semble possible d'identifier le champ "Producteur" à l'élément "éditeur" du DC, quitte à le préciser en clair.
Au-delà, si d'autres éléments descriptifs sont nécessaires, il faut les inclure en sus. L'un d'eux en particulier semble requis, celui relatif
à la propriété intellectuelle, appelé "Gestion des droits" (Rights) dans le DC. Il est donc souhaitable d'ajouter cette entrée dans le
dictionnaire. Cependant, comme l'entrée personnalisée n'est pas montrée par les gestionnaires de fichiers courants, il semble intéressant, en plus,
de "tricher" un peu en utilisant l'entrée non DC "Auteur" pour y noter aussi le copyright. Au total, le fichier des métadonnées pourrait prendre
la forme suivante.
InfoBegin
InfoKey: Title
InfoValue: Mon excellent document
InfoBegin
InfoKey: Author
InfoValue: © 2015, Gilles DUPOND-DURAND, document sous CC-BY-NC 4.0
InfoBegin
InfoKey: Creator
InfoValue: Gilles DUPOND-DURAND
InfoBegin
InfoKey: Keywords
InfoValue: texte, pdf, métadonnées, propriétés
InfoBegin
InfoKey: Subject
InfoValue: bonnes pratiques d'indexation pour le ⅩⅪe siècle
InfoBegin
InfoKey: Producer
InfoValue: Éditeur Gilles DUPOND-DURAND
InfoBegin
InfoKey: CreationDate
InfoValue: D:20150610130000+02'00'
InfoBegin
InfoKey: ModDate
InfoValue: D:20150611130000+02'00'
InfoBegin
InfoKey: Rights
InfoValue: © 2015, Gilles DUPOND-DURAND, document sous CC-BY-NC 4.0
Évidemment, ceci n'est qu'un exemple que chacun adaptera.
Son embarquement dans le PDF se fait au terminal par la commande suivante qui produit un nouveau fichier complété mon_excellent_document+m1.pdf :
$ pdftk mon_excellent_document.pdf update_info_utf8 mes_metadata_ouida.txt output mon_excellent_document+m1.pdf
Cette méthode introduit dans la fichier de la redondance voulue pour éviter les risques de pertes en ligne… Les propriétés montrées par evince
prennent la forme suivante :
ce qui est déjà plus satisfaisant et, bien sûr, l'extraction des métadonnées par la commande :
$ pdftk mon_excellent_document+m1.pdf dump_data_utf8 | grep Info
redonne bien le résultat attendu, avec tous les descripteurs insérés (et un petit défaut d'affichage des chiffres romains en UTF8).
La solution précédente permet de faire quelque chose - c'est mieux que rien ! Il faut quand même reconnaître qu'elle tient du bricolage assez peu recommandable pour un usage professionnel sérieux. Maintenant que le XMP est devenu la norme ISO 16684-1:2012, Graphic technology – Extensible metadata platform (XMP) specification, il semble que l'on puisse espérer faire mieux - seulement c'est un peu plus compliqué. Ce paragraphe va tenter d'expliquer par l'exemple une méthode qui "marche" sans garantir que la méthode soit sans faille ni optimale. A partir de nombreux documents trouvés sur le web et pas forcément simples à exploiter, l'auteur a rebâti la démarche qui suit. L'usage prioritaire visé est la diffusion de documents PDF pour consultation électronique sur écran (d'où le choix d'un codage RVB dans le paramétrage de la production du PDF) mais en préservant la possibilité d'une impression correcte (avec notamment un embarquement des polices complet mais sans redondance pour éviter les salades de caractères).
Le point de départ est, disons, un document dans un format classique comme A4 ou A5, préparé dans un logiciel idoine, comme LibreOffice.
Le document qui va servir de support dans la suite de cette page est
mon_excellent_document.odt (151 ko, téléchargeable), montré par l'illustration
suivante.
La première étape est de suivre la
procédure pour faire un PDF propre
mais en allant seulement jusqu'à la production du fichier Postscript (en effet la dernière action produit un PDF seulement destiné à être fourni
à un imprimeur).
Cette procédure "d'impression" dans un fichier (ne pas oublier de cocher cette case dans les options d'impression) produit le fichier
Postcript mon_excellent_document.ps (2,4 Mo, non téléchargeable), qui
semble avoir perdu en route quelques propriétés spécifiées dans LibreOffice mais ce n'est pas grave…
En fait, il existe plusieurs formats PDF et tous ne savent pas embarquer des métadonnées XMP. Il faut donc maintenant transformer le fichier Postscript obtenu précédemment en un fichier PDF dans un format sachant héberger du XMP, tel que PDF/A. En fait, il y a plusieurs niveaux dans ce format mais le premier niveau (de plus large compatibilité) suffit. Cette conversion va être opérée à l'aide de l'utilitaire Ghostscript (disponible pour divers systèmes d'exploitation).
Les paramètres de la conversion sont passés à la commande ghostscript par deux moyens utilisés simultanément :
Le fichier de définition complémentaire utilisé par l'auteur est montré ci-dessous (À TITRE EXPÉRIMENTAL, SANS AUCUNE GARANTIE et SANS SUPPORT TECHNIQUE).
%!
% This is a sample prefix file for creating a PDF/A document.
% Feel free to modify entries marked with "Customize".
% Version avec corrections en date du 16 juin 2015 par gilles
% This assumes an ICC profile to reside in the file,
% unless the user modifies the corresponding line below.
% Define entries in the document Info dictionary :
/ICCProfile (/home/gilles/.color/icc/sRGB_IEC61966-2-1.icc) % Customize.
def
[ /Title (mon grand titre) % Customize.
/DOCINFO pdfmark
% Define an ICC profile :
[/_objdef {icc_PDFA} /type /stream /OBJ pdfmark
% [{icc_PDFA} <</N systemdict /ProcessColorModel get /DeviceGray eq {1} {4} ifelse >> /PUT pdfmark
[{icc_PDFA} <</N systemdict /ProcessColorModel get /DeviceGray eq {1} {systemdict /ProcessColorModel get /DeviceRGB eq {3} {4} ifelse}
ifelse >> /PUT pdfmark
[{icc_PDFA} ICCProfile (r) file /PUT pdfmark
% Define the output intent dictionary :
[/_objdef {OutputIntent_PDFA} /type /dict /OBJ pdfmark
[{OutputIntent_PDFA} <<
/Type /OutputIntent % Must be so (the standard requires).
/S /GTS_PDFA1 % Must be so (the standard requires).
/DestOutputProfile {icc_PDFA} % Must be so (see above).
/OutputConditionIdentifier (CGATS TR001) % Customize
/RegistryName (http://www.color.org) % Must be so (the standard requires).
currentdict /ICCProfile known {
/DestOutputProfile {icc_PDFA} % Must be so (see above).
} if
>> /PUT pdfmark
[{Catalog} <</OutputIntents [ {OutputIntent_PDFA} ]>> /PUT pdfmark
Au total, on a tout ce qui est nécessaire, il ne reste plus qu'à appliquer la commande :
$ gs -dPDFA -dBATCH -dNOPAUSE -sColorConversionStrategy=/UseDeviceIndependentColor -sProcessColorModel=DeviceRGB -dPDFACompatibilityPolicy=1 -sDEVICE=pdfwrite -sOutputFile=mon_excellent_document.pdf /home/gilles/.local/share/gs-convert/PDFA_gilles.ps mon_excellent_document.ps
qui produit, d'une part, la réponse :
GPL Ghostscript 9.10 (2013-08-30)
Copyright (C) 2013 Artifex Software, Inc. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
et, d'autre part, le fichier mon_excellent_document.pdf (207 ko,
téléchargeable), qui a bien embarqué le titre par défaut spécifié par le fichier de définition complémentaire et aussi les polices
nécessaires.
Confronté à l'outil de validation de pdf-tools,
le fichier passe la validation haut la main (il provoque un avertissement "Il est possible que ce document PDF ne s'affiche pas correctement"
dans Firefox 38 mais ce message ne se présente plus dans une version plus récente du navigateur) :
La façon dont les métadonnées XMP sont incluses dans le fichier PDF ne permet pas de les modifier à la main sans fort risque de corrompre le fichier.
Cependant, il existe des utilitaires qui permettent d'afficher et de manipuler ces métadonnées. Pour une utilisation sous linux, les deux programmes qui semblent les plus développpés répondent aux noms de exempi et de exiftool. Dans Ubuntu, leur installation s'effectue sans problème, avec Synaptic par exemple.
Une fois installé, ce programme permet d'abord de regarder ce que contient le fichier. Dans notre cas, voici ce que cela donne :
$ exempi -x mon_excellent_document.pdf
processing file mon_excellent_document.pdf
dump_xmp for file mon_excellent_document.pdf
<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Exempi + XMP Core 5.1.2">
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="" xmlns:pdf="http://ns.adobe.com/pdf/1.3/">
<pdf:Producer>GPL Ghostscript 9.10</pdf:Producer>
</rdf:Description>
<rdf:Description rdf:about="" xmlns:xmp="http://ns.adobe.com/xap/1.0/">
<xmp:ModifyDate>2015-06-16T11:20:17+02:00</xmp:ModifyDate>
<xmp:CreateDate>2015-06-16T11:20:17+02:00</xmp:CreateDate>
<xmp:CreatorTool>UnknownApplication</xmp:CreatorTool>
</rdf:Description>
<rdf:Description rdf:about="" xmlns:xmpMM="http://ns.adobe.com/xap/1.0/mm/">
<xmpMM:DocumentID>uuid:7388ff90-4c25-11f0-0000-3df60fc37aa8</xmpMM:DocumentID>
</rdf:Description>
<rdf:Description rdf:about="" xmlns:dc="http://purl.org/dc/elements/1.1/">
<dc:format>application/pdf</dc:format>
<dc:title>
<rdf:Alt>
<rdf:li xml:lang="x-default">mon grand titre</rdf:li>
</rdf:Alt>
</dc:title>
</rdf:Description>
<rdf:Description rdf:about="" xmlns:pdfaid="http://www.aiim.org/pdfa/ns/id/">
<pdfaid:part>1</pdfaid:part>
<pdfaid:conformance>B</pdfaid:conformance>
</rdf:Description>
</rdf:RDF>
</x:xmpmeta>
Il apparait que, de base, le fichier inclut une structure de métadonnées où le XMP est défini comme un sous ensemble de XML associé à un espace de nommage d'Adobe. L'emballage des métadonnées est assuré par le schéma RDF (Resource Description Framework). Il est possible d'y reconnaître des descripteurs définis par des balises propres au XMP (comme la date de création ou un identifiant affecté au document) et, caractéristique intéressante pour l'indexation à venir, deux descripteurs recourant à la norme Dublin Core (dc) : format et title (ce dernier transmis depuis le fichier de définition complémentaire et réemballé en rdf).
Dès lors, il semble naturel de compléter cette description en Dublin Core. Cependant, à en croire le document BRIEFING PAPER: THE ADOBE EXTENSIBLE METADATA PLATFORM (XMP), la flexibilité du dc est grandement bridée par la spécification XMP.
La page de manuel de exempi est succincte et comporte des erreurs. La traduction corrigée (au 16.6.15, version du 10.2.13) de ses trois premiers paragraphes est la suivante :
NOM
exempi - Outil en ligne de commande pour manipuler les métadonnées
SYNTAXE
exempi { -h | [ -R ] [ -x ] [ { -w | -o <file> } ] [-n <ns> <prefix>]
[ { -g <prop_name> | -s <prop_name> -v <value> } ] } <files>
OPTIONS
-h: affiche cette aide
-R: ne synchronise pas
-x: exprime toutes les métadonnées XML
-X: teste si les fichiers soumis contiennent des métadonnées XMP
-w: écrit dans le même fichier, s'applique seulement à l'option -s. Non compatible avec -o.
-o <file>: fichier à produire.
-n <ns> <prefix>: définit le préfice prefix pour un nouvel espace de nommage ns.
-g <prop_name>: lit la valeur de la métadonnées prop_name.
-s <prop_name> -v <value>: affecte la valeur value à la métadonnée prop_name.
<files> les fichiers soumis en entrée.
Cet utilitaire permet donc de définir une à une les métadonnées à écrire dans le fichier PDF. Cependant, deux particularités ont été constatées empiriquement (sous réserve d'analyses plus profondes) :
Ainsi, pour insérer la mention de l'auteur Sellig Zed dans une copie mon_excellent_document+md.pdf de notre fichier d'exemple mon_excellent_document.pdf, en appliquant la norme Dublin Core, déjà connue du fichier, une commande à appliquer serait :
exempi -w -s dc:Creator -v "Sellig Zed" mon_excellent_document+md.pdf
et cette syntaxe produit la réponse suivante.
processing file mon_excellent_document+md.pdf
Après cela, l'affichage des métadonnées de mon_excellent_document+md.pdf par exempi fait apparaître une nouvelle ligne :
<dc:Creator>Sellig Zed</dc:Creator>
À ce stade, il faut observer que le comportement de exempi dépend de la casse :
Ce comportement est illustré par la suite de commandes suivante :
exempi -w -s dc:Creator -v "Sellig Zed" mon_excellent_document+md.pdf
processing file mon_excellent_document+md.pdf
exempi -w -s dc:Creator -v "Autre auteur" mon_excellent_document+md.pdf
processing file mon_excellent_document+md.pdf
exempi -w -s dc:creator -v "Sellig Zed" mon_excellent_document+md.pdf
processing file mon_excellent_document+md.pdf
exempi -w -s dc:Subject -v banane mon_excellent_document+md.pdf
processing file mon_excellent_document+md.pdf
exempi -w -s dc:subject -v exemple mon_excellent_document+md.pdf
processing file mon_excellent_document+md.pdf
exempi -w -s dc:subject -v correction mon_excellent_document+md.pdf
processing file mon_excellent_document+md.pdf
Composite nodes can't have values
set error = -102
L'effet de cette séquence sur les métadonnées "dc:" manipulées est comparé dans la table suivante au fichier produit par l'éditeur de métadonnées de CANOPÉ.
| exempi -x mon_excellent_document+md.pdf | Fichier XML produit par éducaméta |
| processing file mon_excellent_document+md.pdf dump_xmp for file mon_excellent_document+md.pdf <x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Exempi + XMP Core 5.1.2"> […] <rdf:Description rdf:about="" xmlns:dc="http://purl.org/dc/elements/1.1/"> […] <dc:Creator>Autre auteur</dc:Creator> <dc:Subject>banane</dc:Subject> <dc:creator> <rdf:Seq> <rdf:li>Sellig Zed</rdf:li> </rdf:Seq> </dc:creator> <dc:subject> <rdf:Bag> <rdf:li>exemple</rdf:li> </rdf:Bag> </dc:subject> […] </rdf:RDF> </x:xmpmeta> |
<metadata xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://purl.org/dc/elements/1.1/ http://www.dublincore.org/schemas/xmls/qdc/2003/04/02/dc.xsd"
xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:dcterms="xmlns:dcterms=http://purl.org/dc/terms/"> <dc:subject xml:lang="fr">banane</dc:subject> <dc:subject>exemple</dc:subject> <dc:creator>Sellig Zed</dc:creator> <dc:creator>Autre auteur</dc:creator> </metadata> |
Cette solution n'est donc pas parfaite. Son manque de souplesse semblerait pouvoir être contourné partiellement en utilisant une majuscule pour les noms d'éléments descriptifs mais ceci introduit une non conformité à la spécification XMP qui fait échouer la validation de format du fichier PDF. Malgré des tentatives multiples, l'auteur de cette page n'a pas réussi à obtenir un résultat complètement satisfaisant avec exempi. Il signale cependant qu'il semble possible d'utiliser exempi sous python grâce au Python XMP Toolkit.
L'emploi de exiftool (du moins pour les pdf, car il sait manipuler de nombreux formats d'images) ressemble beaucoup à celui de exempi. L'affichage du contenu XMP d'un fichier est effectué par la commande :
$ exiftool -xmp -b "mon_excellent_document+md.pdf"
et l'édition d'une métadonnée dc se fait par une commande telle que la suivante.
$ exiftool -XMP-dc:creator="Sellig Zed" "mon_excellent_document+md.pdf"
A la différence de exempi, exiftool sait entrer plusieurs valeurs pour les descripteurs qui y sont autorisés par la spécification XMP. Il suffit de les séparer en spécifiant un séparateur (qui est ignoré s'il n'est pas applicable). Par exemple, cela donne :
$ exiftool -sep "/" -XMP-dc:contributor="Dupont, J./Durand, M." "mon_excellent_document+md.pdf"
et les commandes peuvent être enchaînées. Le formulaire de la section suivante engendre un script pour faire exactement cela. Voici un exemple de sortie résultant de son application.
$ exiftool -sep "/" -XMP-dc:type="Texte/Image" "mon_excellent_document+md.pdf" &&
> exiftool -sep "/" -XMP-dc:subject="métadonnées/banane" "mon_excellent_document+md.pdf" &&
> exiftool -sep "/" -XMP-dc:rights="Texte sous CC-BY, image sous CC-BY-NC" "mon_excellent_document+md.pdf" &&
> exiftool -sep "/" -XMP-dc:language="fr-FR" "mon_excellent_document+md.pdf" &&
> exiftool -sep "/" -XMP-dc:identifier="SZ212" "mon_excellent_document+md.pdf" &&
> exiftool -sep "/" -XMP-dc:description="Ce texte sans queue ni tête présente est illustré par une peau de banane." "mon_excellent_document+md.pdf" &&
> exiftool -sep "/" -XMP-dc:creator="Sellig Zed" "mon_excellent_document+md.pdf" &&
> exiftool -sep "/" -XMP-dc:coverage="Implémentation XMP du dc au XXIe siècle" "mon_excellent_document+md.pdf" &&
> exiftool -sep "/" -XMP-dc:contributor="Dupont, J./Durand, M." "mon_excellent_document+md.pdf" &&
> exiftool -xmp -b "mon_excellent_document+md.pdf"
1 image files updated
1 image files updated
1 image files updated
1 image files updated
1 image files updated
1 image files updated
1 image files updated
1 image files updated
1 image files updated
<?xpacket begin='' id='W5M0MpCehiHzreSzNTczkc9d'?>
<x:xmpmeta xmlns:x='adobe:ns:meta/' x:xmptk='Image::ExifTool 9.46'>
<rdf:RDF xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'>
<rdf:Description rdf:about=''
xmlns:dc='http://purl.org/dc/elements/1.1/'>
<dc:contributor>
<rdf:Bag>
<rdf:li>Dupont, J.</rdf:li>
<rdf:li>Durand, M.</rdf:li>
</rdf:Bag>
</dc:contributor>
<dc:coverage>Implémentation XMP du dc au XXIe siècle</dc:coverage>
<dc:creator>
<rdf:Seq>
<rdf:li>Sellig Zed</rdf:li>
</rdf:Seq>
</dc:creator>
<dc:description>
<rdf:Alt>
<rdf:li xml:lang='x-default'>Ce texte sans queue ni tête présente est illustré par une peau de banane.</rdf:li>
</rdf:Alt>
</dc:description>
<dc:format>application/pdf</dc:format>
<dc:identifier>SZ212</dc:identifier>
<dc:language>
<rdf:Bag>
<rdf:li>fr-FR</rdf:li>
</rdf:Bag>
</dc:language>
<dc:rights>
<rdf:Alt>
<rdf:li xml:lang='x-default'>Texte sous CC-BY, image sous CC-BY-NC</rdf:li>
</rdf:Alt>
</dc:rights>
<dc:subject>
<rdf:Bag>
<rdf:li>métadonnées</rdf:li>
<rdf:li>banane</rdf:li>
</rdf:Bag>
</dc:subject>
<dc:title>
<rdf:Alt>
<rdf:li xml:lang='x-default'>Contenu pour diffusion en ligne</rdf:li>
</rdf:Alt>
</dc:title>
<dc:type>
<rdf:Bag>
<rdf:li>Texte</rdf:li>
<rdf:li>Image</rdf:li>
</rdf:Bag>
</dc:type>
</rdf:Description>
<rdf:Description rdf:about=''
xmlns:pdf='http://ns.adobe.com/pdf/1.3/'>
<pdf:Producer>GPL Ghostscript 9.10</pdf:Producer>
</rdf:Description>
<rdf:Description rdf:about=''
xmlns:pdfaid='http://www.aiim.org/pdfa/ns/id/'>
<pdfaid:conformance>B</pdfaid:conformance>
<pdfaid:part>1</pdfaid:part>
</rdf:Description>
<rdf:Description rdf:about=''
xmlns:xapMM='http://ns.adobe.com/xap/1.0/mm/'>
<xapMM:DocumentID>uuid:2787ae1b-4d52-11f0-0000-3bb90b760ff4</xapMM:DocumentID>
</rdf:Description>
<rdf:Description rdf:about=''
xmlns:xmp='http://ns.adobe.com/xap/1.0/'>
<xmp:CreateDate>2015-06-17T23:12:48+02:00</xmp:CreateDate>
<xmp:CreatorTool>UnknownApplication</xmp:CreatorTool>
<xmp:ModifyDate>2015-06-17T23:12:48+02:00</xmp:ModifyDate>
</rdf:Description>
</rdf:RDF>
</x:xmpmeta>
<?xpacket end='w'?>
Cette méthode a été appliquée au fichier mon_excellent_document+md.pdf copié de mon_excellent_document.pdf.
Mi-juin 2017, l'auteur de cette page constate que les comportements des utilitaires ont évolué, sans doute en raison de mises à jour logicielles.
Par exemple, pour une utilisation réelle, un fichier 170528_livre_photo_V08.ps a été produit par une impression sur Acrobat-distiller. Ensuite, en utilisant la méthode décrite plus haut, ghostscript a été utilisé pour produire le fichier 170620_approfondissements_photographiques_ed_01.pdf
Malheureusement, l'extraction des métadonnées de ce dernier avec exiftool montre que le titre n'a pas été changé, il est resté égal au nom du fichier Postscript au lieu de prendre la valeur inscrite dans le fichier de définition complémentaire.
Cependant, il est possible de changer le titre dans les métadonnées XMP en utilisant exiftool, comme indiqué dans la partie supérieure de
l'illustration suivante (marquée "Terminal"). Toutefois, les visionneurs de documents, qu'il s'agisse de Evince (à gauche) ou de Atril (à droite),
affichent toujours le titre initial (nom du fichier ps) qui a été stocké dans l'info dico.
Au total, avec les nouvelles versions logicielles, il n'est pas nécessaire de se préoccuper d'adapter le fichier de définition complémentaire. Il suffit de mettre dedans, une fois pour toutes, un titre passe-partout qui sera remplacé à l'aide d'exiftool. Qui plus est, il n'est pas obligatoire de passer par ghostscript, même s'il est préférable d'appliquer une procédure produisant un fichier pdf de qualité, comme celle permettant de produire un PDF propre pour lulu.com.
Par ailleurs, pour maîtriser les métadonnées incluses dans le fichier pdf, il est souhaitable de commencer par retirer toutes celles qui ont pu être incluses silencieusement par les étapes de production. L'utilitaire exiftool fournit une commande à cet effet :
exiftool -all= nom_du_fichier.pdf
Ainsi, il est sûr que les métadonnées ajoutées seront les seules présentes.
Le script d'aide à l'édition des métadonnées XMP fournit ci-dessous a été modifié en juin 2017 pour inclure l'écriture du titre et du format du fichier. Le titre est celui voulu par l'auteur du traitement documentaire et, pour un fichier pdf, le format est : "application/pdf" (sans les guillemets).
En résumé, si l'on n'a qu'un petit nombre de fichiers à traiter, un résultat convenable est obtenu en :
Cette méthode artisanale ne convient pas au cas d'un grand nombre de fichiers à traiter, pour lequel il faudra réaliser des scripts plus sophistiqués ou acquérir une application spécifique.
Pour l'application commode à un seul fichier, le formulaire suivant permet d'abord d'effectuer le traitement documentaire du fichier sous les contraintes dues à la spécification XMP puis, par un simple copier-coller du script automatiquement engendré en bas de page, d'appliquer toutes les métadonnées au fichier et de vérifier le résultat.
RAPPEL : ce script ne fonctionne que s'il est appliqué à un fichier déjà existant. Si le fichier original doit être protégé, il faut en créer une copie et donner le nom de cette copie dans le formulaire pour lui appliquer le script. En effet, exiftool a le bon goût de créer une copie de sauvegarde de l'original mais si l'on enchaîne les commandes, il y a un risque de pertes de données.
REMARQUE : ce formulaire ne fait rien d'autre qu'engendrer le script bash affiché dans sa dernière boîte en bas de page.
Début du formulaire
Validé avec le vérificateur expérimental Nu Html Checker du W3C