Errore dummy-space con pdfx

Se carichi pdfx NON devi caricare hyperref, perché lo fa pdfx e quindi ricevi dei conflitti.

Il link che hai segnalato non è necessario: quel file pdfx.pdf è il normale file di documentazione che è già presente nell’installazione completa di TeXLive e (probabilmente) di MiKTeX.

Lo leggi con il semplice texdoc pdfx Nella mia installazione (aggiornatissima) di MacTeX (TexLive) il file risulta essere la versione 1.5.4 datata 2015/02/28.

Mi fa piacere che il pacchetto sia stato aggiornato, perché l’ultima volta che l’ho usato risaliva al 2014 e il risultato non passava la verifica PDF/A di Adobe Acrobat Pro XI.

Ora ci riprovo, ma continuo ad essere pessimista. L’ultima volta che l’ho usato sperimentavo un file sedicente PDF/A compatibile che passava il contorollo di Adobe Acrobat Pro XI su una macchina Windows, mentre lo stesso file non al passava sul mio Mac, con la stessa versione di Adobe Acrobat Pro XI. Ho segnalto il problema alla Adobe, inviando il file di test, ma non ho avuto nessun feedback e nemmeno un cenno di aver ricevuto la segnalazione del bug.

Roby, stai attento che la maggior parte degli enti che pretende di ricevere documenti conformi alle noeme PDF/A non sanno di che cosa stiano parlando, anche perché nella maggior parte dei casi se va bene aprono il file con Adobe Reader, il quale riconosce se un file PDF dice/pretende di essere PDF/A conforme. Il Reader lo deduce dalla presenza dei metadati, ma non fa nessuna vera verifica.

I software che eseguono la verifica sono tutti a pagamento; il più economico sembra essere Adobe Acrobat Pro e dovrebbe essere abbastanza affidabile visto che i tecnici della Adobe fanno parte del Working Group che redige e aggiorna la norma ISO 19005.
Le verifiche on line gratuite ci sono, ma sono sempre negative; prova ad immaginare perché una azienda produttrice di una software da alcuni biglietti da mille dovrebbe offrire i suoi servizi gratis…

Robi, ho costruito il tuo file pari pari con un copia-incolla, e l’ho fatto girare con pdflatex; dopo un po’ di smarrimento, perché non mi ricordavo di avere una vecchia versione di pdfx.sty nel mio albero personale, e perché con la versione attuale bisogna inserire i metadati con un file di nome diverso dal passato, (ottima occasione, la mia, per testare la nuova versione di pdfx e per mettermi a giorno delle novità) la compilazione da me procede perfettamente, senza messaggi di dummy-space duplication. Forse succede anche a te, ma dal tuo ultimo messaggio avevo capito che l’RMC che hai allegato serviva per riprodurre l’errore.
A me non si riproduce. La mia versione di TeXLive )MacTeX) è aggiornata ad una settimana fa.

Nonostante questo, sarebbe importante (a parte l’EMC) non usare mai i font CM; sarebbe desiderabile usare solo i font OpenType, quindi a rigore, visto che xelatex non produce direttamente il file PDF compatibile ma bisogna trasformalo in ps e poi renderlo compatibile attraverso ghostscript, xelatex sarebbe da escludere; di conseguenza si potrebbe avere qualche chance solo con lualatex. Sono tutte prove che non ho fatto, anche perché ci vorrebbe non un EMC, ma un vero documento contente testo con diversi font, matematica, figure, tabelle, grafica in linguaggio PDF (pict2e, curve2e, TikZ, pgfplot, eccetera). Quindi sarebbe un test piuttosto pesante.

Alla riga 121 la nuova versione di pdfx contiene

\pdfmapline{+dummy-space

Giusto; la documentazione di pdfx al paragrafo 3.1 dice:

3.1. Limitations and dependencies
pdfx.sty works only with PDFTEX. It further depends on the following packages:
1. xmpincl for insertion of metadata into PDF.
2. hyperref for hyperlinking, bookmarks, etc.
3. glyphtounicode.tex maps glyph names to corresponding Unicode.

I pacchetti che gli servono sono già inclusi, ma la prima frase è esplicita: funziona solo con pdftex usato come motore di composizione, non con luatex usato come motore. Quindi con pdfLaTeX funziona; con LuaLaTeX non funziona.

Ne deduco che l’unico modo di avere un PDF/A conforme usando XeLaTeX o LuaLaTeX è quello di produrre un file PDF e di convertirlo in PDF/A mediante ghostscript. Non ho controllato se il gostscript installato con TeXLive è sufficientemente aggiornato per poter eseguire questa conversione.

Caro Roberto,
negli ultimi giorni mi sono dedicato ad approfondire i cambiamenti che sono avvenuti in TeXLive, GostScript e in pdfLaTeX, XeLaTeX e LuaLaTeX.

Ecco quanto ho scoperto:
0) PreliminarNon ci osno o non ci dovrebero essere problemi con i font di LaTeX; anche se ci sono due file cmsym e un altro font matematico che sono incompatibili per qualche glifo di larghezza nulla; con il pacchetto TOPteso ho rideifnit i comandi che usano quel paio di glifi sbagliati, per l’altro font il problema non mi si è mai presentato, quindi mi sono dimenticato di quale/i glifo/i si tratti. I problemi veri nascono dal profilo di colore e dai file importati; per il profilo di colore pdfx fa tutto da solo ed è meglio non metterci el mani dentro. Per i file importati, se sono file PDF o EPS generati “in casa” bisogna rigenerali in modo che essi stessi siano PDF/A compatibili, perché di solito i metadati relativi ai font e al profilo di colore non sono presenti; altrimenti bisogna convertirli in file raster PBG se sono al tratto o JPG se sono fotografie cuarndo che siano RGB e non CMYK come talvolta succede.

1) pdfLaTeX
il pacchetto pdfx, al contrario di quello che faceva prima, va caricato dopo il pacchetto inputnec e prima del pacchetto hyperref; quest’ultimo deve venire chiamato senza opzioni e le impostazioni vanno fatte successivamnte mediante \hypersetup. ovviamante ci vule il file .xmpdata con il nome uguale a quello del main file.
Le compilazione procede senza errori, lerrore dummy-space non si mainfaesta più, ec’è la possibilità che il file sia PDF/A compatibile, se sono soddisfatte altre circostanze. (vedi punto 0 )

2) XeLaTeX
Non può produrre da solo file PDF/A perché la sua composzione passa attraverso unfiel DVI esteso, che viene convertito in PPDF mediante una versione speciale ed estesa di dvipdfm. Invece il formato PDF/A necessita di primitive che ha solo il motore pdftex. Quindi bisogna passare attravero Ghostscript, am è difficle configurare il file dei metadati *_def.ps che potrebbe mantenere il nome originale del modello PDFA_def.ps, ma è meglio usare un file col nome del file principale del file PDF generato da XeLaTeX. Un altro metodo più semplice consiste nel creare un semplice file di poche righe che usi il pacchetto pdfpages, ceare il file di metadati .xmodata col nome di questo piccolo file, e usare questo piccolo file per importare il file PDF generato da XeLaTeX. Entrambi i metodi perdono la funzionalità dei collegamenti ipertestuali eventualmente presenti ne file da convertire.

3) LuaLaTeX
La documentazione di pdfx dice che esso è compatibile solo con pdfLaTeX, come ti ho già scritto, ma bisogna avere fiducia. Se il file da comporre con LuaLaTeX non usa profili di colore strambi, né importa file PDF con contenuti non compatibili, allora vale la pena di caricare pdfx prima di hyperef (senza opzioni, ma configurato dopo mediante \hypersetup) e lanciare la compilazione LuaLaTeX; siccome questo è incompatibile con pdfx,a un cero punto si ferma dicendo che una certa primitiva (di pdftex) è una control sequence ignota. In errorstopmode il programma si ferma in attesa di istruzioni da parte dell’utente; si preme il taso S + invio, e la compilazione riparte. Miracolo! il file PDF ottenuto è PDF/A compatibile e passa l’analisi di Preflight di Adobe Acrobat Pro XI; ne non la passa è perché il fiel da compilare manca di qualche dato o importa qualche file non PDF/A compatibile. Ovviamante, anche con LuaLaTeX bisogno predisporre il solito file di metadati .xmpdata come si fa per la compilazione mediante pdfLATeX.

Ho faticato molto a trovare questi risultati e devo ringraziare Luigi S. che mi ha aiutato con la riga di comando di ghostscript.

Quanto è scritto in questo messaggio funziona, ma non si trova scritto da nessu’altra parte. Per cui ora mi accingo ad aggiornare i documenti per il Forum, e altri documenti in giro dove ho scritto del formato PDF/A. In modo che anche qui dal forum possiamo indirizzare gli OP verso una documentazione non così succinta come questo breve ( 😉 😎 😯 😀 ) messaggio.

Attento che le norme PDF/A vietano i collegamenti ipertestuali con destinazioni esterne al file archiviabile.
Devi trovare una altro modo, per esempio citazioni bibliografiche.

Claudio

Che io sappia non ci sono metodi per disabilitare \href impliciti anche attraverso \url, a documenti o siti esterni. però non ricordo la documentazione di hyperref a memoria.