<foo>
simply produces <foo>in the text).
<URL: http://somewhere.tld/ >
,
and it will be automatically made into a link.
(Do not try any other way or it might count as an attempt to spam.)mailto:
URI,
e.g. mailto:my.email@somewhere.tld
,
if you do not have a genuine Web site).
Ruxor (2018-08-14T21:46:21Z)
@Damien: Merci beaucoup pour le brain dump ! J'étais au courant de quelques bouts, mais certainement pas du tableau d'ensemble.
Damien (2018-08-14T20:57:18Z)
Désolé pour le spam, petite typo, les polices AMS sont sorties en 1997.
Damien (2018-08-14T20:52:28Z)
Deux ou trois bricoles que j'ai oubliées :
- la date de 2000 approximative correspond au fait que les polices AMS (type1 en OT1) sont sorties en 1998 (même si elles existaient depuis plus longtemps de façon payante), donc le temps que cela se répande dans les distributions, on tombe à peu près là-dessus.
- je n'ai pas parlé de pdfTeX ; j'ai un peu de mal à retrouver des détails mais je crois qu'il a été rendu disponible à la fin des années 90, donc ça ne change rien fondamentalement sur les questions bitmap/type3 vs type1. J'ai quand même retrouvé ça https://www-fourier.ujf-grenoble.fr/~bouche/pdfTeX/ qui indique que le support du type3 bitmap a été ajouté postérieurement, donc je ne sais pas ce que faisaient les premières versions pour sortir du CM type1, peut être que ça a bien coïncidé avec la sortie des fontes AMS (dans ce doc on voit que c'est Bakoma qui est utilisé, ancêtre des AMS : https://www-fourier.ujf-grenoble.fr/~bouche/pdfTeX/manual.pdf ; intéressant pour le côté historique). Au début je me souviens que l'on parlait beaucoup des fonctions typo avancées (voir la thèse de Thanh) et de nombreux exemples utilisaient des polices payantes.
- je n'ai pas parlé de dvipdfm que je ne connais que de nom et qui a toujours été assez peu utilisé et "mainstream"
- on peut aussi se dire que ce sujet est complexe car en plus du monde TeX, il y a l'évolution de la norme PDF elle même et de tous les outils autour (y compris commerciaux d'Adobe) avec leur bugs et (mis)features. Les bidouilles de conversions empilées pdf/ps avec des options tordues de Ghostscript ne datent pas d'hier…
- pour le fameux problème des PDFs moches, en conclusion, il n'y a pas de miracle ; peut être que pkfix peut aider dans certains cas mais pour beaucoup d'anciens articles (avant 98), si on n'a pas le dvi ou de .tex, il n'y a pas de magie, le fichier PS ou PDF contient du bitmap et il faut faire avec. En général, la moins mauvaise solution pour lire l'article de façon confortable sera de l'imprimer. Même s'il est en 300 ou 600dpi, une imprimante moderne devrait quand même donner un résultat correct.
Ouf, je me sens mieux après ce brain dump, ça m'a pris un peu de temps mais c'était bien agréable de se replonger dans tout ça (j'ai commencé à faire du TeX en 1996 et j'ai notamment participé à la relecture de la thèse de Thanh) !
Damien (2018-08-14T18:47:27Z)
Je n'ai pas d'infos sur le problème du "Bad bounding box in Type 3 glyph", par contre, je peux faire des remarques générales de folklore TeX qui pourraient aider à mieux comprendre certains de tes ennuis.
Pour éviter le commentaire (trop) fleuve, je vais insister sur les points principaux et dropper pas mal de liens qui pourront être approfondis en fonction de l'intérêt et des connaissances en TeXeries.
Le point essentiel est que les fichiers PS ou PDF qui s'affichent mal contiennent (souvent uniquement) des polices bitmap, générées pour une résolution donnée (souvent 300 ou 600 dpi correspondant à pas mal d'imprimantes classiques dans les années 80/90). Et les lecteurs pour écran n'ont en général pas d'algorithmes d'anti-crénelage très sophistiqués (de toutes façons, en zoomant beaucoup, on va forcément voir des escacliers), donc c'est moche. Et comme le type3 (tu l'as indiqué) permet des choses plus complexes que le type1 (notamment les bitmaps !), c'est plus lourd à traiter donc ça peut mettre un temps notable à être traité (impression de lenteur d'affichage).
Les deux principales causes d'inclusion de polices bitmap dans des fichiers issus de TeX/LaTeX :
- création d'un document par une compilation qui a lieu avant l'an 2000 (à la louche et j'explique pourquoi plus loin), donc dvips inclut des polices bitmap soit parce que les type 1 correspondantes (de l'AMS) n'existent pas encore, soit parce que ce ne sont pas elles qui sont incluses par défaut (c'est le cas en OT1 maintenant mais je ne sais pas précisément depuis quand, cela doit dépendre des distributions de TeX)
- utilisation d'une vieille version de Ghostscript pour convertir de PS en PDF ; dans ce cas, même un fichier contenant du type 1 (donc vectoriel), par exemple les polices AMS, peut se retrouver avec du type 3 bitmap. La version de GS qui a amélioré ça est sortie à la fin de l'année 2000.
Pour le document que tu cites, on est dans le premier cas (un examen dans Adobe Reader ou avec pdffonts après conversion en PDF via un GS récent le montrent).
En passant, si on regarde quelques metadata de ce fichier :
Creator: dvips 5.58 Copyright 1986, 1994 Radical Eye Software
Producer: GPL Ghostscript SVN PRE-RELEASE 8.62
CreationDate: Fri Feb 1 04:06:00 2008 CET
ModDate: Fri Feb 1 04:06:00 2008 CET
donc ça rejoint un des commentaires qui explique qu'il faut souvent regénérer les PDF.
Dans le cas de ce doc, il semble avoir été uploadé en PS uniquement, du coup la page https://arxiv.org/format/math/9809211 n'aide pas (pas de PS avec type1 ni de dvi ni de sources).
Maintenant sur le "que peut-on faire", malheureusement, je dirais pas grand chose en pratique… Il y a bien quelques pistes :
- voir cet article de 2003 qui expose bien la problématique :
https://pdfs.semanticscholar.org/af06/7ad3d8c8b987a152c930bd6edc1e09a5b6ed.pdf
- il y a bien un outil dédié à ce problème, pkfix, mais il ne fonctionnera "bien" (en théorie, je n'ai jamais testé) si on a le PS et qu'il a été créé avec un dvips pas trop vieux (voir les liens pour les détails). Sinon, il y a un autre outil, pkfix-helper, qui essaie d'analyser le PS ; sur le document cité, il a généré un autre PS mais ensuite pkfix n'a pas réussi à le traiter. dvips 5.58 semble être la dernière version qui n'a pas les commentaires qui aident pkfix (donc pas de chance…)
- pstill (pas très connu, pas cité sur la page Wikipedia qui liste les principaux outils et moteurs PDF, voir les liens) est sensé être capable de convertir les type3 bitmap en type1 sur une machine où il y a les polices TeX mais un essai rapide n'a pas fonctionné chez moi, ça donne juste un "! Input is not accessable - skipping" (que je n'ai pas quand j'omets l'option -D)
Là j'ai parlé de l'OT1, c'est à dire en gros les documents en Anglais. Dès qu'on a besoin d'accents, pour que ça marche bien, on passe en T1 et là on n'a pas les fameuses polices AMS (historique de ces polices dans les liens) ; les deux solutions principales sont cm-super et Latin Modern (cette dernière est la plus courante actuellement), datant respectivement de 2001 et 2002 environ. Donc dans les années 90 il n'y avait pas de solution en Computer Modern.
Dernière remarque, les explications sur le PDF et type3/type1 chez archiv sont très vieillottes :
https://arxiv.org/help/pdf
https://arxiv.org/help/pscm
Voici les liens que j'ai utilisés et quelques autres plus détaillés, notamment sur les logiciels PDF ; il y a aussi mupdf qui est moins connu mais indépendant de GS et xpdf/poppler :
https://texfaq.org/FAQ-adobetypen
https://ctan.org/pkg/pkfix
https://ctan.org/pkg/pkfix-helper
https://texfaq.org/FAQ-pkfix
https://texfaq.org/FAQ-fuzzy-type3
https://texfaq.org/FAQ-dvips-pdf
https://texfaq.org/FAQ-fuzzy-T1
https://texfaq.org/FAQ-type1T1
https://texfaq.org/FAQ-fuzzy-gs
http://www.gust.org.pl/projects/e-foundry/latin-modern/index_html
http://www.ams.org/publications/type1-fonts
https://en.wikipedia.org/wiki/List_of_PDF_software#Linux_and_Unix
Ilia (2018-08-10T16:12:01Z)
L'imprimante que j'avais dans mon bureau à Yale, quand je lui donnais des PDFs à imprimer, produisait parfois un bug très mystérieux : certains symboles était systématiquement remplacés par un autre symbole (apparaissant ailleurs dans le document), mais seulement quand ils étaient en indice ou en exposant. (Par exemple, tous les "+" en exposant pouvaient être remplacés par des "Z", où "Z" se trouve être une notation qui apparaît ailleurs dans le document, dans un contexte complètement différent.)
Maintenant que j'ai quitté ce bureau, la question devient purement académique pour moi ^^ mais ça continue à picoter ma curiosité !
Prince H. (2018-08-09T18:51:30Z)
Je rencontre occasionnellement encore ce problème de pdf qui s'affiche correctement à l'écran, mais où il manque des tirets et autres signes moins à l'impression, ce dernier point pouvant varier selon que j'imprime depuis firefox, evince, etc.
La dernière variante qui m'est arrivée, c'était le rapporteur d'un de mes articles soumis à publications qui me reprochait d'avoir oublié les signes moins dans mon papier…
Une "solution" que j'avais trouvée pour "réparer" ces pdf était de leur faire subir deux ou trois allers-retours via pdf2ps/pdftops et ps2pdf/pstopdf (avec une meilleure efficacité en panachant les '2' et les 'to').
Xavier (2018-08-09T17:48:04Z)
@Karadoc: j'aime les gens qui ont décidé de faire ça ! Il est tres difficile de faire comprendre à bien des gens qu'il vaut mieux updater un système informatique disons tous les 2ans que d'appliquer le 'on ne touche pas un system qui marche'. Ça coûte bcp moins de réparer les pbs locaux à chaque update que d'avoir à tout changer une fois que tout est cassé. Merci donc pour cet exemple de bonne gestion que je donnerai aux glandus qui mettent machines et soft dans un container et qui pensent que 10ans après tout ira bien (on fait souvent cette idiotie dans le spatial)
immae (2018-08-09T05:52:46Z)
@Ruxor: tant que je zoome pas ça va, ensuite effectivement c’est pas très joli
Karadoc (2018-08-09T00:36:29Z)
Juste pour dire que c'est un souci qui est pris avec beaucoup de sérieux dans l'archivage à très long terme.
Dans HAL, par exemple (celui des thèses, pas celui de 2001 l'Odyssée de l'espace), l'intégralité des PDF stockés (déjà, les documents ne sont pas stockés que en PDF) sont ouverts puis réenregistrés tous les (de mémoire c'est) 2 ans. Le réenregistrement se fait dans la dernière version du format PDF au moment de l'opération supportant les options d'archivage pérenne, et il y a un contrôle strict de vérification de l'intégrité du fichier sorti par rapport au fichier entré (je ne suis pas au courant de l'ensemble du processus, qui est automatisé).
Benoit (2018-08-08T21:53:35Z)
Note que PDF et PostScript diffèrent fondamentalement:
- PDF est bien, essentiellement, un format graphique vectoriel *déclaratif* 2D comme ce à quoi on s'attend; PDF existe dans la même constellation de formats que, disons, le SVG;
- en revanche PostScript est plutôt un langage *impératif* de commandes de tracé 2D, à rapprocher de Cairo et du Canvas 2D du Web, que tu connais bien.
Bob (2018-08-08T18:05:17Z)
J'ouvre en général les pdf dans mon navigateur Firefox (sous Ubuntu), sans doute muni d'une extension ad hoc. En général (=toujours, jusqu'à présent) je ne vois pas d'erreurs. Le pdf arxiv que tu as donné en exemple s'affiche bien de cette façon.
Ruxor (2018-08-08T15:04:18Z)
@Cigaes: Effectivement, en utilisant un pdftocairo plus récent avec un cairo plus récent (je ne sais pas lequel des deux joue, en fait, j'ai recompilé la dernière version de chacun), ça semble résoudre le problème. C'est bien ma veine de tomber sur un bug vieux de vingt ans(?) et de découvrir qu'il est corrigé dans la version JUSTE APRÈS celle que j'ai sur mon PC…
@immae: Et l'affichage est comment ? Chez moi c'est super moche, ça fait aussi partie du problème.
immae (2018-08-08T14:12:14Z)
J’ai essayé tout ce que tu as dit, et:
- evince et xpdf sont parfaitement silencieux en ouvrant le pdf cité (ce qui est assez rare)
- par contre okular se plaint de plein de trucs manquant
- pdftocairo -pdf ressort bien les moins là où il faut
Cigaes (2018-08-08T13:25:34Z)
Tu as essayé le pdftocairo de Testing ? J'ai l'impression qu'il n'a pas le problème du moins.