Catégorie : PDF

DeepPDF URL

Encore à propos des PDFs. Besoin d’ouvrir dans un browser avec des fonctions en plus. Il y a le basique pour les destinations données "url/fichier.pdf#nom", et aussi le « url/fichier.pdf#page=21 » qui sont assez standards. (A noter que pdfinfo -dests fichier.pdf permet d’automatiser la recherche des destinations nommées dans un PDF.

Dans le contexte d’un moteur de recherche, je voulais aller plus loin avec « url/fichier.pdf#search=emprise » et cela fonctionne bien avec Firefox et mais pas sur chrome et ses dérivés. J’ai fini par comprendre que c’était lié au composant utilisé par ces browsers. Ouf, il suffit d’installer un add-on qui se base sur PDF.js, comme nativement avec Firefox, comme PDF Viewer. Pas encore trouvé de solution pour Safari

Youpi : https://codes.droit.org/PDF/Code%20civil.pdf#search=emprise

A noter que PDF.js tel que dans Firefox (ou DiversChromes avec le viewer en question) permet des choses interdites par d’autres contextes. Ainsi, car PDF.js est un citoyen libre, il me sert à redistiller des fichiers en contournant les blocages tels que l’interdiction d’imprimer: Au lieu de faire des screenshots (ou des copier/coller avec Word !!!) pour pouvoir distribuer un fichier librement, il suffit de l’ouvrir dans un lecteur basé sur PDF.js puis de l’imprimer aux format PDF pour le redistiller de manière libérale.Et hop.

UniteThePages

Besoin de réunir des PDFs en un seul, pas vraiment compliqué avec pdfunite. Excellent. Dans mon cas, besoin un peu plus sophistiqué car besoin d’introduire des signets afin d’avoir un document plus agréable à consulter, d’où ce script.

Script en perl mais dépendances pour manipuler les fichiers PDF, à savoir pdfinfo, pdfunite (brew install Doppler sur Mac et apt install poppler-utils sur linux) et enfin ghostscript. Pas besoin de modules perl spécifiques.

#/usr/bin/perl
open(STRU,'>','merger.txt');
$cursor = 1;
foreach $af (@ARGV) {
if(-e $af) {
$ninfo = pdfinfo "$af";
my %inf;
foreach $lee (split(/\n/g,$ninfo)) {
if($lee =~ /^(.?)\:[\s\t]+(\w.)/) {
$inf{$1} = $2;
}
}
$tito = $inf{'Title'};
$tito = $af unless($tito);
if($inf{'Pages'} =~ /\d+/) {
print STRU "[/Page $cursor /Title ($tito) /OUT pdfmark\n";
$cursor += $inf{'Pages'};
}
}
}
close(STRU);
$units = join(' ',map { "\"$_\"" } @ARGV);
pdfunite $units merger.pdf;
print gs -sDEVICE=pdfwrite -q -dBATCH -dNOPAUSE -sOutputFile=Merged.pdf -dPDFSETTINGS=/prepress merger.txt -f merger.pdf;
unlink('merger.txt');
unlink('merger.pdf');

Simple et efficace. Peace.

Perl Image::ExifTool

Je le mets ici car j’ai un peu trimé pour trouver les infos nécessaires.

ExifTool marche parfaitement mais ne pas oublier d’aller voir sur https://metacpan.org/pod/Image::ExifTool#DESCRIPTION que le type d’accès qu’offre le module en fonction du type fichier que vous visez (par example MP3 en lecture, PDF en compl<et).

#!/usr/bin/perl 
use Image::ExifTool;
$exifTool = new Image::ExifTool;
$exifTool->ExtractInfo($ARGV[0]);
if ($ARGV[2]) {
 $val = $exifTool->GetValue($ARGV[1],'ValueConv');
   if (ref $val eq 'ARRAY') {
     @values = split(/,\s*/g,$ARGV[2]);
     $exifTool->SetNewValue($ARGV[1] => \@values, { Replace=>1, AddValue => 2 });
   } else {
     $exifTool->SetNewValue($ARGV[1],[$ARGV[2]]);
   }
   $exifTool->WriteInfo($ARGV[0]);
 }
$exifTool->ExtractInfo($ARGV[0]);
 foreach $tag (grep { !($_ =~ /\s(1)$/) } sort $exifTool->GetFoundTags()) {
   $tt = $tag;
   $tt .= ' (1)' if (grep { $_ eq $tt.' (1)'} $exifTool->GetFoundTags());
   printf("%-21s : %s\n",$tag,$exifTool->GetValue($tt));
 }

Notes: https://exiftool.org/ExifTool.html

Adobe 0 – ExifTool 1 – Habett II

Pas mal de prises de tête au final pour injecter des méta-données dans des PDFs.

Surtout sur le champ du milieu.

Sujet.

Après avoir hésité sur la méthodologie je me suis rendu à l’évidence que le meilleur outil pour faire cela programmatiquement (par script) est bel et bien ExifTool. Le grand ExifTool, ce puissant et capricieux outil multi-platteforme. Mais à vrai dire, est-ce son caprice ou bien celui qui s’introduit malignement dans mon esprit à trop me demander pourquoi les turpides d’affichage de ces même méta-données dans Adobe Reader et Acrobat sont si perturbantes. Ou bien les méandres de l’histoire sont liées à l’age de cette technologie et à l’évolution des techniques disponibles.
Reste qu’Adobe nous fout un bon gros bordel en place. Je pourrais cracher mon venin sur ces bureaucrates et l’informatique et les maudire longtemps encore, et parfois même aller jusqu’à douter de la qualité du travail d’ExifTool mais non, voici donc ma solution en ligne de commande.

Je commence par faire le vide dans les métadonnées car l’empilement des différentes couches devient vite problématique. Je fais donc simplement:
exiftool -overwrite_original -all= monfichier.pdf

Ensuite j’injecte un fichier XMP que j’aurai rempli avec mes métadonnées selon la distribution suivante (je remplis le XML en DOM Javascript ou un LibXML Perl).

<?xpacket begin=’?’ id=’W5M0MpCehiHzreSzNTczkc9d’?>
<x:xmpmeta xmlns:x= »adobe:ns:meta/ »>
<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:creator>
<rdf:Seq>
<rdf:li>None</rdf:li>
</rdf:Seq>
</dc:creator>
<dc:description>
<rdf:Alt>
<rdf:li xml:lang= »x-default »>références</rdf:li>
</rdf:Alt>
</dc:description>
<dc:format>application/pdf</dc:format>
<dc:subject>
<rdf:Bag><rdf:li>baratin</rdf:li></rdf:Bag>
</dc:subject>
<dc:title>
<rdf:Alt>
<rdf:li xml:lang= »x-default »>circonscription électorale des Etats-Unis d’Amérique</rdf:li>
</rdf:Alt>
</dc:title>
</rdf:Description>
<rdf:Description rdf:about= » » xmlns:pdf= »http://ns.adobe.com/pdf/1.3/ »>
<pdf:Author>None</pdf:Author>
<pdf:Keywords>baratin</pdf:Keywords>
<pdf:PDFVersion>1.4</pdf:PDFVersion>
</rdf:Description>
<rdf:Description rdf:about= » » xmlns:xmp= »http://ns.adobe.com/xap/1.0/ »>
<xmp:CreateDate>Wed Jan 21 2015 16:43:41 GMT+0100</xmp:CreateDate>
<xmp:MetadataDate>Wed Jan 21 2015 16:43:41 GMT+0100</xmp:MetadataDate>
<xmp:ModifyDate>Wed Jan 21 2015 16:43:41 GMT+0100</xmp:ModifyDate>
</rdf:Description>
<rdf:Description rdf:about= » » xmlns:xmpRights= »http://ns.adobe.com/xap/1.0/rights/ »>
<xmpRights:WebStatement>http://www.legicrack.org</xmpRights:WebStatement>
</rdf:Description>
</rdf:RDF>
</x:xmpmeta>
<?xpacket end=’w’?>

Plusieurs notes à ce propos. Bien respecter les format de date et UUID, bien diviser la valeur du champ Mots-Clés selon les virgules et les points-vigules afin d’en répéter le contenu depuis <pdf:Keywords> pour sa totalité littérale vers <dc:subject>/<rdf:Bag> et autant de <rdf:li> que la division vous donnera. Cela semble nécessaire même si le paradoxe viendra plus loin.

Pour injecter cela, on utilisera la commande suivante:

exiftool -overwrite_orginal -tags_from_file monxmp.xmp monpdf.pdf

Reste le champ Subject ou Description ou Sujet, comme vous voulez, à force je l’appelle le champ du milieu. Comme vous le voyez dans le XML précédent il y a différents namespace dans les métadonnées donc il faut pas se rater.

Ma solution est la suivante, avec l’option -L en plus si vous êtes sous Windows et que vous voulez mettre une valeur avec accents:

exiftool -overwrite_orginal -pdf:subject= »Mon champ du milieu » -xmp:subject= » » monpdf.pdf

Ils ont le même nodename mais dans des espaces de noms différents et pourtant il faut les injecter avec des valeurs radicalement différentes.

Après ces trois étapes, j’arrive à mes fins, et mon résultat dans les produits Adobe est conforme, avec juste le petit itch qui est que la valeur des mots-clés est encadrée de quotes, ce qui peut arriver même quand on saisit à la main, à moins qu’un lecteur ou moi ne finisse par trouver une solution programmatique.