Lettura file PDF

Non è immediato rispondere, ignorando su che sistema operativo lavori,
come compili e che visualizzatore usi (o meglio il tuo relatore).
E poi se i font sono incorporati o meno nel .pdf.
Acrobat Reader ha dei dispositivi per usare dei font “similari”.
Ad esempio, se tu usi un font di cui hai solo la versione “roman”, ma poi usi anche il corsivo,
Acrobat Reader rende su schermo il font con un font simile (un “bastone viene reso con Arial,
in genere…), ma questa sostituzione non vale per la stampa.
Ciò è dovuto al linguaggio di stampa PostScript.
Tuttavia, come già detto, dovresti fornire più dettagliate informazioni

m

prova a fare anche tu una stampa, mi sembra un passaggi opportuno.
per vedere se i font sono standard, incorporati ecc
col lettore .pdf che usi vai nel menu su qualcosa come “Proprietà — Font”

m

Se il tuo relatore usa Ghostscript nele sue varianti gs (quelo che fa il lavoro) e gv, quello che permette di vdere/leggere, è il menoche gli possa capitare. I file PDF prodotti dai programmi del sistema TeX hanno tutti i loro font incorporati.

A meno che…

A meno che tu non abbia ottenuto il tuo PDF attraverso la successione .tex. -> latex.exe -> .dvi -> dvips .ps -> ps2odf -> .pdf
Questa è la vecchia maniera di quando non esisteva il programma pdflatex; alcuni shell editor, cliccando l’icona “componi”, seguono ancora questa vecchia strada.

Prova a compilare direttamente con pdflatex: .tex ->pdflatex.exe -> .pdf

pincopallino” post=117583P.s. per generare il file PDF uso pdflatex

Ciao.
Posta il preambolo del documento.
Potremo valutare eventuali problemi derivanti da pacchetti per font.
Sapevo che la produzione del file PDF può oppure no includere i glifi stessi dei font in modo che il visualizzatore lo possa ricostruire in “originale” anche se sulla macchina ospite mancano i font.
Quindi potrebbe essere a volte che nel pDF non vengano inclusi alcuni glifi.

Tuttavia so che non può essere il caso di pdflatex. Mi piuacerebbe approfondire la questione. OldClaudio penso che possa delucidarci in merito.
Nella mia esperienza da parecchio tempo non ho problemi di questo tipo pur lavorando tra Windows e Linux (con differenti distro).

Aspetto il preambolo.
Grazie.
A presto.
R.

Se può aiutar,e problemi simili li avevo avuti anch’io con i plugin (non Adobe) per leggere i pdf nei browser Firefox e Chrome, e ciò anche con pdf non creati con pdflatex. Con Adobe Reader (e con okular ed evince su Linux) era tutto ok.

Ciao.

Claudio

Mi sa che c’è un po’ di disordine nel tuo preambolo. Come in parte ho già scritto in un tuo precedente tread.
Per impostare la codifica è meglio caricare i pacchetti nel seguente ordine:
`\documentclass[a4paper,12pt,titlepage]{book}
\usepackage[T1]{fontenc}
\usepackage{textcomp}
\usepackage[utf8]{inputenc}
\usepackage[italian]{babel}
\usepackage{lmodern}
\usepackage{microtype}`
Textcomp introduce anche la codifica di output TS1, per cui dovrebbe stare prima di inputenc.
Se imposti oneside non serve openright perché tutte le pagine sono considerate destre.
Frontmatter non ha nessun senso dove lo metti tu. Va messo dove inizia \frontmatter,
seguito da \mainmatter e infine da \backmatter. Sempre se li usi…
Carichi due volte textcomp.
Carichi titlesec, ma poi non te ne fai nulla perché non ne imposti le opzioni. E allora perché lo carichi?
Idem per footmisc.
Bookmarks carica hyperref; puoi chiamarli separatamente se devi gestire determinate opzioni, il che però tu non fai.
Mathtools carica di suo amsmath.
Meglio il pacchetto xcolor di color.
Conti di comporre in una tesi indici particolari, visto che carichi imakeidx ?
Riconsidera un po’ il tutto….

`I file PDF prodotti dai programmi del sistema TeX hanno tutti i loro font incorporati.`

Per quello che riguarda i font, a me risulta che attualmente i vari strumenti di composizione
(pdflatex, xelatex, lualatex) incorporano il font non per intero, ma semplicemente
comprendendo i glifi effettivamente usati. A meno di non fornire specifiche ed esplicite istruzioni.
Ad es. usando su Linux l’utilità pdffonts su un mio pdf ottengo:

`samiel@darkstar:~/SimonciniGaramondPro/regular$ pdffonts test_roman.pdf
name type encoding emb sub uni object ID
———————————— —————– —————- — — — ———
QGSWWZ+SimonciniGaramondPro CID Type 0C Identity-H yes yes yes 8 0
PNXHUF+SimonciniGaramondPro-Bd CID Type 0C Identity-H yes yes yes 40 0
BBAQQF+SimonciniGaramondPro-It CID Type 0C Identity-H yes yes yes 95 0
NYDCFW+SimonciniGaramondPro-BdIt CID Type 0C Identity-H yes yes yes 126 0
ETYOCZ+LMMono12-Regular CID Type 0C Identity-H yes yes yes 127 0
FOCRQR+CMR12 Type 1 Builtin yes yes no 854 0`

dove emb “yes” significa che il font è incorporato (embedded) nel .pdf
e sub “yes” che si tratta in effetti non del font intero, ma di un suo sottoinsieme (subset)

PS
Per incorporare il font per intero si può ricorrere al luacode,
ma non ho sperimentato bene. Qui @robitex potrebbe darci informazioni
molto competenti…:

`\usepackage{luacode}
\begin{luacode}
local function embedfull(tfmdata)
tfmdata.embedding = “full”
end

luatexbase.add_to_callback(“luaotfload.patch_font”, embedfull, “embedfull”)
\end{luacode}`

m

PdfLaTeX ha bisogno di avere una lista di font con le cratterisitche di ciascuno (nome del file tfm, nome del file pfb, trancodifica, particolari impostaioni per l’inclinazione, eccetera); queste informazioni non sono contenute dentro i file come per gli OpenType, che si pososno usare solo con XeLaTeX e LuaLatex (e altri programmi di composizione non collegati a LaTeX), quindi bisogna fornirgliele; Bella Guida GuIT c’è scritto come fare per costruire i file di mappa (quelli che contengono le suddette informazioni) e poi ul programma di installazione che in TeXLive si chiama updmap-sys provvede a raccogliere le informazioni contenute i diversi file di mappa, e cucirle assieme in un unico file .pdftex.map, che al momento buono pdfLaTeX legge e ne estrae le informazioni per inserire nel file .pdf di uscita tutti glifi usati nel documento con le proprietà di ciascuno. Ma tutte el informazioni necessarie sono controllate da un file di configurazione che si trova in …/texmd-dist/web2c/updfmap.cfg.

Questo file indica tante cose, comprese le mappe dei font di sistema; ma può essere integrato da altri file file che l’utente ha acquistato, o a scaricato dalla rete, o si è creato, insomma i suoi file personali; per usarli deve scriversi anche un file di mappa messo in una apposita certella personale, e poi updmap-sys la trova e la aggiunge alle altre.

Bene, tutto ciò spiega in parole povere, saltando innumerevoli dettagli, come funziona la gestione dei file e la loro incorporazione nei file pdf creati dall’utente.

Ma veniamo alla questione dei font incorporato o non incorporati; Il file updmap.cfg per la configurazione del particolare pacchetto pdftex.map che usa pdfLaTeX, contiene la riga [tt]pdftexDownloadBase14 true[/tt] che dice: nel creare il file pdftex.map incorpora anche i 14 file che si danno già presenti nelle stampanti (nei driver per le periferiche di uscia) predisposte per mostrare il contenuto dei file pdf.

Per il driver dvips, che trasforma un file DVI in file PDF, la riga corrispondente per la creazione del suo file di mappa dvips.map, contiene la riga [tt]dvipsDownloadBase35 false[/tt] o almeno era cosi fino a pochi anni fa; ora [tt]false[/tt] dovrebbe già essere sostituito con [tt]true[/tt], ma all’occorrenza questa riga con [tt]true[/tt] può essere messa nella mappa personale.

In realtà esistevano davvero una volta le stampanti che potevano ricevere direttamente i file PostScript e stamprli senza bosogno che i 35 font di default facessero parte della mappa. Ma la mancata incorporazione di font nei file PDF distruggerebbe la loro caratteristica di essere “portable” ciò usabile su qualunque macchina indipendentemente dal sistema operativo. In passato,quando era necessario in documento in formato pdf e se ne disponeva solo della versione in formato PostScript, si usavano programmi comps2pdf o pstopdf che eseguivnano la trasformazione. ma evidentemente non potevano incorporarvi i font che non erano contenuti nel documento PstScript.

Non so dire esattamente che cosa avvenga con MikTeX, perché non ne dispongo più da più di 10 anni. Ma le cos non sono molto diverse da qunto ho descritto pe l’installazione TeX Live.

Che cosa succede con gli utenti di Linux di vecchia data e poco attenti all’evoluzione del softeware? Talvolta non installano Adobe Reader; o Okular o Evince, quindi non dispongono di un programma ad hoc per visualizzare, stampare e leggere i file PDF. Spessocostoro usano gv (alia gview, alias ghostview) che sono programmi eccellenti ma che partono ancora dal presupposto che non hanno bisogno di sare i font che devono essere installati di default. Qindi sostituiscono i font che non conoscono con altri font, facendo un miscuglio forse leggibile ma talvolta indecente; e mancano di glifi necessari o con disposizioni dei caratteri che non corrispondono a quelle usate nel font originali; ecco quindi che la lettera \Phi mancante vien sostituita con una O, e via di questo passo.

Ora, @pincopallino, se vuoi che il tuo relatore, che evidentemente non usa software aggiornato e adeguato, possa leggere i tuoi scritti devi dargleli stampati, non sotto forma di file pdf.

Scusatemi per la lunga spiegazione; spero che siate riusciti ad arrivare a leggere fino a qui.

ma mi confermi il fatto che, lasciando stare la gestione degli OpenType da parte di Xetex / Luatex,
in ogni caso i font incorporati sono un sottoinsieme del font e non il font intero?
Es. da un file compilato con pdflatex:
`samiel@darkstar:~$ pdffonts fichte.pdf
name type encoding emb sub uni object ID
———————————— —————– —————- — — — ———
UPLZVJ+TeXGyrePagella-Regular Type 1 Custom yes yes no 4 0
MJMMVT+TeXGyrePagella-Bold Type 1 Custom yes yes no 5 0
AJISEW+TeXGyrePagella-Italic Type 1 Custom yes yes no 6 0
TAGUNQ+TeXGyreAdventor-Regular Type 1 Custom yes yes no 7 0
UPLZVJ+TeXGyrePagella-Regular Type 1 Custom yes yes no 13 0
ZAYPYF+TeXGyreAdventor-Bold Type 1 Custom yes yes no 14 0
WJPUZS+TeXGyreAdventor-Italic Type 1 Custom yes yes no 18 0`
Qui è esplicito che si tratta di sottoinsiemi!

m

Non usando il plugin di Firefox, ma quello offerto da Adobe.

Non l’ho detto nel mio precedente messaggi, ma si tratta sempre di sotto insiemi: solo i glifi effettivamente usati nel documento; sia con i type 1 sia con gli opentype è quasi sempre un sotto insieme di parecchie decine di caratteri. Nel tuo esempio ne sono stati caricati pochi perché si tratta di un esmpio con poco testo. Nel tuo esempio non hai usato la matematica quindi non si sa se il problema di @pincopallino dipenda dai font matematici incorporati. Ma come dicevo nel mio ultimo messaggio, anch’io in passato ho avuto grossi problemi quando usavo una versione di Linux essenziale con l’installazione tetex; secoli fa… e i nimbus sostituiti da gv/gs al posto dei font mancanti davano schermate e stampe assolutamente inguardabili, spesso incomprensibili. Poi sono passato al Mac e ho tutti i vantaggi di un sistema UNIX e dell’installazione completa di MacTeX senza gli svantaggi delle infinite incarnazioni di Linux. Costa, d’accordo, e non poco. MA da quando uso il Mac faccio tutto quel che mi serve, senza problemi; questo lo sottolineo non per reclamizzare una macchina e un sistema operativo particolari, ma per spiegare perché non posso fare esperimenti su una piattaforma Linux; tra l’altro non voglio sprecare 50 GiB per installare un virtualizzatore su cui installare una versione di Linux.

Questo è l’output di un documento più ampio che contiene anche un po’ di matematica:
`samiel@darkstar:~$ pdffonts 15maggio.pdf
name type encoding emb sub uni object ID
———————————— —————– —————- — — — ———
NFFBKL+NewG8-Bol Type 1 Custom yes yes no 10 0
NFFBKL+NewG8-Bol Type 1 Custom yes yes no 11 0
DQXDFK+NewG8-Reg Type 1 Custom yes yes no 12 0
ULJAPN+newG8-Osf-reg Type 1 Custom yes yes no 13 0
DQXDFK+NewG8-Reg Type 1 Custom yes yes no 14 0
QKUQCP+NewG8-Reg-SC Type 1 Custom yes yes no 15 0
UHWCQM+newG8-Osf-bol Type 1 Custom yes yes no 87 0
MGJWIQ+NewG8-Ita Type 1 Custom yes yes no 93 0
MGJWIQ+NewG8-Ita Type 1 Custom yes yes no 118 0
DQXDFK+NewG8-Reg Type 1 Custom yes yes no 143 0
NJEEPW+MathDesign-GM-Regular-Symbol-10 Type 1 Builtin yes yes no 144 0
ECYGJP+NewG8-BolIta Type 1 Custom yes yes no 207 0
YPHOPW+newG8-Osf-ita Type 1 Custom yes yes no 233 0
TSMFSV+grmn1000 Type 1 Builtin yes yes no 303 0
EBHBSN+SFSX0800 Type 1 Custom yes yes no 371 0
EKKBZD+SFSS0800 Type 1 Custom yes yes no 372 0
GDUXMT+GaramondNo8-Reg Type 1 Custom yes yes no 449 0
YEPOMH+MathDesign-GM-Regular-Extension-10 Type 1 Builtin yes yes no 450 0
OYGQGL+MathDesign-GM-Regular-Italic-MathItalic-10 Type 1 Builtin yes yes no 451 0
PRUIGJ+MathDesign-GM-Regular-OT1-10 Type 1 Builtin yes yes no 452 0
JJPVUK+GaramondNo8-Ita Type 1 Custom yes yes no 453 0
KRVGBE+SFSS0900 Type 1 Custom yes yes no 476 0
RYWHYV+MathDesign-GM-Regular-MathItalic-10 Type 1 Builtin yes yes no 481 0`
L’ho prodotto sulla mia macchina Linux (io non inseguo le infinite distro che nascono e muoiono senza lasciare traccia,
adotto Debian e basta…) e poi l’ho distribuito ai colleghi, che hanno tutti Windows,
peraltro in varie versioni. Mi risulta che tutti l’abbiano potuto visualizzare correttamente

m

@samile, non sto dicendo che il file PDF prodotto con uno qualunque dei programmi di composizione diretta (pdfLaTeX, XeLaTeX, LuaLaTeX) eseguiti con una installazione di TeX Live aggiornata, non funzioni; sto dicendo che chi usa Linux con una installazione vecchia (per esempeio tetex) e non aggiornata, magari legge un file pdf prodotto da altri con gv e si ritrova nello schermo i font sostituiti con altri font che spesso e volentieri sono dei nimbus. Non è il tuo caso; lo sappiamo entrambi benissimo; è forse, sottolineo forse, il caso del relatore di @pincopallino.

già, scusa… mi son sentito in dovere di fare una difesa d’ufficio di Linux.
Chiaro che se uno ha una installazione vecchia di anni o una Slackware Stable
(in attesa da anni che esca la nuova versione)…
Cmq, per tornare a @pincopallino, potrebbe chiedere al suo relatore
con cosa mai legge i .pdf e questo potrebbe essere risolutivo

m