Gérer les métadonnées d'un fichier PDF

Pourquoi se préoccuper des métadonnées?

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.

De quoi s'agit-il, plus précisément ?

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.

L'info dico

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 :
excel1 excel2 excel3
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.
excel3

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 :
excel3
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).
excel3

L'eXtension pour les Métadonnées Partagées (XMP)

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.
document LibreOffice et propriétés

Production d'un fichier Postscript propre

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).
impression dans un fichier

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…
document Postscript et propriétés

Production d'un fichier PDF adéquat

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.
document PDF - propriétés document PDF - propriétés

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) :
validation du format PDF

Insertion des métadonnées XMP

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.

Test du logiciel exempi

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.

Test du logiciel exiftool (à la date du 19 septembre 2016 - Voir la mise à jour 2017 ci-dessous)

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.

Mise à jour 2017

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.
changement de titre

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 conclusion

Méthode

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.

Aide à l'édition des métadonnées XMP d'un fichier PDF/A en DC non qualifié

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

Nom obligatoire (sans chemin d'accès) du fichier PDF existant (au format PDF/A)
dont les métadonnées XMP/DC doivent être complétées ou modifiées :

NOTA 1 : dans les champs des éléments descriptifs suivants, le caractère apostrophe (') ne crée pas de problème. Le caractère guillemet double (") est également autorisé (il sera automatiquement préfixé d'un caractère d'échappement (\) mais exiftool le transcrit par &quot; dans la métadonnée XMP du fichier). Si aucun élément descriptif n'est fourni, le script fourni en bas de page ne fait qu'afficher les métadonnées XMP déjà présentes dans le fichier.

NOTA 2 : dans les descripteurs associés à un élément rdf:Seq ou rdf:Bag (cf. colonne "Contrainte" ci-dessous), plusieurs valeurs peuvent être saisies, en les séparant par un caractère "barre oblique" ("/" sans espace supplémentaire). Au lieu de créer plusieurs entrées dc (comme le voudrait la norme), la spécification XMP conduit à diviser une entrée dc en plusieurs entrées rdf…

NOTA 3 : le séparateur utilisé pour exiftool est le caractère ø, en raison de sa rareté (il peut être changé en modifiant le code source javascript de la présente page [function construitCommande()]).
touche ø

Élément Valeur Définition par le DCMI (en anglais) et autres remarques Pour information, contrainte du format appliquée par exiftool (notamment d'après The Adobe XMP) et autres commentaires
Contributor An entity responsible for making contributions to the resource.
Plusieurs valeurs possibles séparées par le caractère ø
Must contain an rdf:Bag list.
Coverage The spatial or temporal topic of the resource, the spatial applicability of the resource, or the jurisdiction under which the resource is relevant.  
Creator An entity primarily responsible for making the resource.
Plusieurs valeurs possibles séparées par le caractère ø
Must contain an rdf:Seq list.
Date A point or period of time associated with an event in the lifecycle of the resource.
Plusieurs valeurs possibles, de type "2015-06-10T13:00:00+02:00", séparées par le caractère ø
Must contain an rdf:Seq list.
Description An account of the resource. Must contain an rdf:Alt list, with each list item having an xml:lang attribute.
Format The file format, physical medium, or dimensions of the resource. Must contain a MIME type.
Identifier An unambiguous reference to the resource within a given context.  
Language A language of the resource (fr-FR, en-US, de-CH, …).
Plusieurs valeurs possibles séparées par le caractère ø
Must contain an rdf:Bag list. Must list languages using the language codes set out in RFC 3066.
Publisher An entity responsible for making the resource available.
Plusieurs valeurs possibles séparées par le caractère ø
Must contain an rdf:Bag list.
Relation A related resource.
Plusieurs valeurs possibles séparées par le caractère ø
Must contain an rdf:Bag list.
Rights Information about rights held in and over the resource. Must contain an rdf:Alt list, with each list item having an xml:lang attribute.
Source A related resource from which the described resource is derived.  
Subject The topic of the resource (keywords, key phrases or classification codes ; best practice = controlled vocabulary).
MOTBIS, Thésaurus de l'UNESCO.
Plusieurs valeurs possibles séparées par le caractère ø
Must contain an rdf:Bag list.
Title A name given to the resource. Must contain an rdf:Alt list, with each list item having an xml:lang attribute.
Type The nature or genre of the resource (DCMI Type vocabulary).
Plusieurs valeurs possibles séparées par le caractère ø
Must contain an rdf:Bag list.
Mode d'emploi
Remplir les champs voulus,
copier tout le contenu de la
boîte ci-contre (clic dedans
puis Ctrl-A, Ctrl-C),
ouvrir un terminal dans le dossier
contenant le fichier, coller dans
ce terminal le contenu copié,
vérifier le résultat.

Retour à l'accueil LINUX

logo html 5 Validé avec le vérificateur expérimental Nu Html Checker du W3C