cerhu > comp.* > comp.text.tex

michel (10/12/2018, 14h24)
Bonjour,

Je viens de faire quelles constatations.
La compilation avec dvi+ghostscript donne un fichier de 15520 octets
et avec pdftex 139876 octets.

Quelles conclusions?

cordialement
Olivier V (13/12/2018, 20h47)
Le 10/12/2018 à 13:24, michel a écrit :
> Bonjour,
> Je viens de faire quelles constatations.
> La compilation avec dvi+ghostscript donne un fichier de 15520 octets
> et avec pdftex 139876 octets.
> Quelles conclusions?


En voici une : sur cet exemple (qui n'est pas joint...), le taille du
pdf est plus importante avec pdflatex qu'avec dvi+gs ...

Olivier V
GL (16/12/2018, 17h29)
Le 10/12/2018 à 13:24, michel a écrit :
> Bonjour,
> Je viens de faire quelles constatations.
> La compilation avec dvi+ghostscript donne un fichier de 15520 octets
> et avec pdftex 139876 octets.
> Quelles conclusions?
> cordialement


Avec dvi+gs vous devez perdre les hyper liens non ?

Codialement.
Jean-Côme Charpentier (17/12/2018, 04h05)
Le 16/12/2018 à 16:29, GL a écrit :
> Le 10/12/2018 à 13:24, michel a écrit :
> Avec dvi+gs vous devez perdre les hyper liens non ?


Je ne compile quasiment qu'avec la chaîne latex+dvips(+ps2pdf) et,
heureusement, je peux avoir des hyperliens.

Je reviens sur le message d'origine avec la question « Quelles
conclusions ? ». C'est quand même bizarre comme question. Le fait
d'utiliser deux outils radicalement différents pour créer un document
vont donner deux pdf de tailles différentes. Personnellement, la
première conclusion qui me vient à l'esprit est : « c'est normal ! »

Bon. On peut essayer d'en dire un peu plus mais là, je ne suis
vraiment pas certain de répondre à l'interrogation initiale. En plus il
ne dit strictement rien de son document source. Si une compilation
dvi+gs (donc un document final en PostScript, c'est ça ???) donne un
fichier de 15520 octets c'est qu'il y a un truc bizarre quelque part
parce que moi avec le source :

-----%<----------%<----------%<----------%<----------%<-----
\documentclass{minimal}
\begin{document}
coucou
\end{document}
-----%<----------%<----------%<----------%<----------%<-----

J'obtiens un dvi de 204 octets mais un ps (avec dvips) de 23215
octets. Donc ma première question serait de savoir comment une
compilation peut donner un PostScript aussi léger. Cela dit le terme «
gs » utilisé peut aussi vouloir dire une traduction du dvi en pdf de
façon directe. Là encore les renseignements donnés sont un poil incomplets.

D'habitude, c'est plutôt l'inverse : les fichiers PostScript obtenus
sont beaucoup plus gros que les pdf. La réponse essentielle est que le
format pdf est systématiquement compressé alors que la chaîne
latex-dvips donne un PostScript non compressé. Et selon l'algorithme de
compression utilisé, la taille finale va évidemment varier du tout au tout.

Une deuxième source de variation importante est le fait que certaine
fonte dite « standard » peuvent être ou non incluse dans les pdf.
Typiquement Times par exemple. Le fait de ne pas inclure la fonte va
alléger considérablement le pdf final, surtout si c'est la seule fonte
utilisée. Cela dit c'est *mal* le concept de « standard » est totalement
fumeux et il *faut* embarquer les fontes dans un pdf.

Enfin, potentiellement, un PostScript peut être considérablement plus
léger qu'un pdf (à compression égale) parce que PostScript est un vrai
langage de programmation (Turing complet toussa) alors que le format pdf
n'est qu'un langage de description de page. Donc certain « programme »
qu'on peut écrire avec peu d'instructions en PostScript peuvent avoir
une traduction gargantuesque en pdf.

Il y a certainement d'autres points auxquels je n'ai pas pensé mais
il faudrait vraiment préciser la question et les informations initiales.

Jean-Côme Charpentier
michel (17/12/2018, 10h26)
Le 10/12/2018 à 13:24, michel a écrit :
> Bonjour,
> Je viens de faire quelles constatations.
> La compilation avec dvi+ghostscript donne un fichier de 15520 octets
> et avec pdftex 139876 octets.
> Quelles conclusions?
> cordialement

Bonjour,
Ma question n'en était pas vraiment une.
Je constatais que les moyens 'modernes' n'étaient pas toujours les
meilleurs.
certaines réponses m'ont fait réfléchir.
J'ai perdues les sources, mais élles étaient toutes petites.

Je vous remercie beaucoup de vos réponses qui m'ont fait réfléchir. j'en
attendais pas autant.

Bonne journée.
Olivier V (21/12/2018, 20h04)
Le 17/12/2018 à 03:05, Jean-Côme Charpentier a écrit :
>   Une deuxième source de variation importante est le fait que certaine
> fonte dite « standard » peuvent être ou non incluse dans les pdf.
> Typiquement Times par exemple. Le fait de ne pas inclure la fonte va
> alléger considérablement le pdf final, surtout si c'est la seule fonte
> utilisée. Cela dit c'est *mal* le concept de « standard » est totalement
> fumeux et il *faut* embarquer les fontes dans un pdf.


Je ne me suis jamais vraiment soucié de problème.
Comment forcer un embarquement des fontes ?
(Je compile uniquement avec xelatex ou, plus rarement maintenant, avec
pdflatex).

Merci.

Olivier V
vincent.belaiche (22/12/2018, 22h16)
michel <m.romeNON> writes:

> Le 10/12/2018 à 13:24, michel a écrit :
> Bonjour,
> Ma question n'en était pas vraiment une.
> Je constatais que les moyens 'modernes' n'étaient pas toujours les
> meilleurs.
> certaines réponses m'ont fait réfléchir.
> J'ai perdues les sources, mais élles étaient toutes petites.
> Je vous remercie beaucoup de vos réponses qui m'ont fait réfléchir. j'en
> attendais pas autant.
> Bonne journée.


Bonjour,

Il y a plein d'autres explications possibles de la différence de
taille. En voici une de plus : au bureau j'utilise une classe que j'ai
faite pour la boîte où je travaille. En LaTeX ? DVI ? PS ? PDF le logo est
en vectoriel, alors qu'en LaTeX ? PDF c'est un PNG (ou un PDF, je ne me
souviens plus). Et au final la seconde option fait des fichiers PDF plus
gros.

La raison de la différence de format des logos c'est qu'en faisant la
classe j'ai utilisé deux fichiers différents pour le logo parce que je
ne suis pas arrivé à faire marcher le convertisseur MPS ?PDF embarqué
dans pdflatex (ou bien je ne suis pas parvenu à convertir le logo en
MPS, peu importe), bon en vérité je n'ai pas passé beaucoup de temps à
fignoler cette classe, je me suis contenté de faire rapidos qq chose de
fonctionnel qui reproduise fidèlement les modèles de document quenous
employons.

PS : d'ailleurs à dire vrai je ne sais pas vraiment ce que c'est que le
format MPS, j'ai toujours supposé que c'était un sous-ensemble du
postscript qui permet au convertisseur vers PDF d'être plus simple. Mais
bon, y a-t-il un pogramme qui convertisse du PS en MPS, ou du moins qui
vérifie si un Postscript est un MPS valide ?
vincent.belaiche (24/12/2018, 23h36)
vincent.belaiche writes:

> michel <m.romeNON> writes:
>> Le 10/12/2018 à 13:24, michel a écrit :


[...]

>> PS : d'ailleurs à dire vrai je ne sais pas vraiment ce que c'est que le

> format MPS, j'ai toujours supposé que c'était un sous-ensemble du
> postscript qui permet au convertisseur vers PDF d'être plus simple. Mais
> bon, y a-t-il un pogramme qui convertisse du PS en MPS, ou du moins qui
> vérifie si un Postscript est un MPS valide ?


Juste pour préciser, après une petite recherche les .mps sont les
fichiers PostScript produit par le programme Metapost. J'avais mon logo
au format PDF, je l'ai converti en PostScript avec Inkscape, et j'ai
juste renommé le .ps en .mps, mais apparemment ce n'était pas suffisant
pour l'interpréteur MPS intégré à pdflatex.

M'enfin bon, on diverge un peu de la question initiale sur la taille des
fichier PDF?
Jean-Yves Baudais (07/01/2019, 12h05)
Bonjour,

Le 21/12/2018 à 19:04, Olivier V a écrit :
> Je ne me suis jamais vraiment soucié de problème.
> Comment forcer un embarquement des fontes ?
> (Je compile uniquement avec xelatex ou, plus rarement maintenant, avec
> pdflatex).


Elles ne le sont pas par défaut ! Que donne la sortie de la commande
pdffonts ?

Jean-Yves
Olivier V (07/01/2019, 17h11)
Le 07/01/2019 à 11:05, Jean-Yves Baudais a écrit :
> Bonjour,
> Le 21/12/2018 à 19:04, Olivier V a écrit :
> pdffonts ?


Voici ce que ça donne sur un document pris au hasard compilé hier :

eloli@fixe:~/scolaire_lycee/2nde/105_systeme_equations$ pdffonts
cours_systemes2018.pdf
name type encoding
emb sub uni object ID
------------------------------------ ----------------- ----------------
--- --- --- ---------
SUHPYM+CMUSerif-Bold-Identity-H CID Type 0C Identity-H
yes yes yes 40 0
INHZWD+CMUSerif-Roman-Identity-H CID Type 0C Identity-H
yes yes yes 42 0
GPYCJE+LatinModernMath-Regular-Identity-H CID Type 0C Identity-H
yes yes yes 44 0
QXKXCC+LMRoman10-Regular-Identity-H CID Type 0C Identity-H
yes yes yes 46 0
XCHYRA+CMUTypewriter-Bold-Identity-H CID Type 0C Identity-H
yes yes yes 48 0
GLUNDT+CMUSansSerif-Identity-H CID Type 0C Identity-H
yes yes yes 50 0
LUVLWG+CMMI10 Type 1C Builtin
yes yes no 55 0
ZLIGMG+CMUTypewriter-Regular-Identity-H CID Type 0C Identity-H
yes yes yes 57 0

Qu'en est-il ?

Merci.
Jean-Yves Baudais (07/01/2019, 18h01)
Le 07/01/2019 à 16:11, Olivier V a écrit :
[..]
> XCHYRA+CMUTypewriter-Bold-Identity-H CID Type 0C       Identity-H yes
> yes yes     48  0
> GLUNDT+CMUSansSerif-Identity-H       CID Type 0C       Identity-H yes
> yes yes     50  0
> LUVLWG+CMMI10                        Type 1C           Builtin yes yes
> no      55  0
> ZLIGMG+CMUTypewriter-Regular-Identity-H CID Type 0C       Identity-H
> yes yes yes     57  0
> Qu'en est-il ?


Et bien que tout est embarqué car il n'y a que des "yes" dans la 4e
colonne et comme le dit la page d'aide de la commande

DESCRIPTION
[...]
emb "yes" if the font is embedded in the PDF file

Jean-Yves
Olivier V (09/01/2019, 21h02)
Le 07/01/2019 à 17:01, Jean-Yves Baudais a écrit :
> Le 07/01/2019 à 16:11, Olivier V a écrit :
>> Et bien que tout est embarqué car il n'y a que des "yes" dans la 4e

> colonne et comme le dit la page d'aide de la commande
> DESCRIPTION
> [...]
>    emb    "yes" if the font is embedded in the PDF file


Je compile avec la commande suivante :
xelatex -synctex=1 -shell-escape -interaction=nonstopmode '%source'

Donc par défaut ça embarque toujours toutes les polices ?
Est-ce une spécificité de xelatex de tout embarquer ?

J'avais posé la question car ça ne semblait pas être le cas.

Merci.

Olivier V
Jean-Côme Charpentier (09/01/2019, 22h21)
Le 09/01/2019 à 20:02, Olivier V a écrit :
> Je compile avec la commande suivante :
>    xelatex -synctex=1 -shell-escape -interaction=nonstopmode '%source'
> Donc par défaut ça embarque toujours toutes les polices ?
> Est-ce une spécificité de xelatex de tout embarquer ?


Non. Le principe est le même pour tous les pdftruc (pdftex, pdfetex,
luatex, ...)
Attention, le pdf n'embarque pas toute la police, il embarque un
"subset" (le SUB est à yes) ce qui est le comportement par défaut et qui
fait que seuls les caractères réellement présents dans le document sont
embarqués.

> J'avais posé la question car ça ne semblait pas être le cas.


En fait, il y a deux solutions.
* Si la fonte n'est pas une « fonte standard » alors elle sera
embarquée (modulo l'aspect SUB) quoi qu'il arrive
* Si la fonte est une « fonte standard » alors il y a deux solutions
- soit on a dit d'embarquer et ça embarque
- soit on a dit de ne pas embarquer et ça n'embarque pas.
La demande d'embarcation se fait au niveau d'un fichier de
configuration. Je pensais que c'était texmf.cnf mais je viens de le
parcourir dans tous les sens et je ne vois pas l'information relative à
l'embarquement ou non des fontes standards. Soit j'ai mauvaise mémoire,
soir j'ai une mauvaise vue.
Quoiqu'il en soit, je sais qu'il y a quelques (beaucoup ?) années, le
comportement par défaut était de ne pas embarquer et il me semble bien
que maintenant, le comportement par défaut est d'embarquer.
Ne pas embarquer fait gagner une misère en place sur le disque dur et
expose le fichier pdf à ne pas être visualiser ou imprimer correctement.
Par exemple un imprimeur un tant soit peu sérieux doit refuser un tel pdf

Jean-Côme Charpentier
Olivier V (10/01/2019, 08h57)
Le 09/01/2019 à 21:21, Jean-Côme Charpentier a écrit :

[..]
>   Quoiqu'il en soit, je sais qu'il y a quelques (beaucoup ?) années, le
> comportement par défaut était de ne pas embarquer et il me semble bien
> que maintenant, le comportement par défaut est d'embarquer.


Donc je ne touche à rien puisque tout se passe maintenant pour le mieux
par défaut... Mais ce paramètre doit bien être quelque part, ou est mis
par défaut dans le compilateur directement donc ?

>   Ne pas embarquer fait gagner une misère en place sur le disque dur et
> expose le fichier pdf à ne pas être visualiser ou imprimer correctement.
> Par exemple un imprimeur un tant soit peu sérieux doit refuser un tel pdf


J'ai aussi déjà téléchargé des pdf faisant apparaître des caractères
étranges.
Ça devait être ce problème alors.

Merci des précisions.

Olivier
Jean-Yves Baudais (10/01/2019, 10h12)
Le 09/01/2019 à 21:21, Jean-Côme Charpentier a écrit :
[..]
>   Quoiqu'il en soit, je sais qu'il y a quelques (beaucoup ?) années, le
> comportement par défaut était de ne pas embarquer et il me semble bien
> que maintenant, le comportement par défaut est d'embarquer.


Il me semble que ce soit le cas maintenant, en tout les cas je n'ai
plus les problèmes que j'avais à une certaine époque. À l'époque où ce
n'était pas le cas, il fallait, pour pdftex, récupérer le bon fichier
pdftex_dl14.map qui embarquait les polices standards. Si je comprends ma
distribution (qui utilise un texmf.cnf qui n'est même pas vu par
kpsewhich... ah si mais avec l'option --all !), texmf.cnf précise le
répertoire TEXFONTMAPS où trouver les .map et c'est updmap qui, comme
son nom l'indique, gère les tables.
Bref, ne connaissant pas le nommage des fontes, la lecture de
pdftex_dl14.map ne me permet pas de confirmer ma première phrase...

Jean-Yves

Discussions similaires
Adapter taille formulaires à taille et résolution de l'écran

Taille de l'image inférieure a la taille de l'écran (XP-SHARP)

Différence entre Taille et Taille sur le disque, et effet de la compression/extraction

courier new taille 6 ou taille 4 en grisé au lieu de l'encre noire?


Fuseau horaire GMT +2. Il est actuellement 18h51. | Privacy Policy