Afficher un document LaTex dans une page Web.

Bonjour à tous, je vous expose ma problématique :

Je suis en train de créer un site web qui permettra de consulter un certain nombre de mini documents LaTex. Pour l'instant je convertis ces documents en pdf à l'aide du package standalone (Le pdf généré ne contient donc qu'une seule page, d'où l'appellation "mini").

Bien entendu j'aurais pu utiliser MathJax qui fait de très beau rendus, mais les documents que je veux afficher ne sont pas de simples formules, ils contiennent - Une quantité non négligeable de texte formaté en latex. Je pourrais certes convertir ce formatage en balises HTML mais ça me demanderait un temps que je n'ai pas :/ (Il y a beaucoup de documents) - Pas mal (ça dépend de chaque document) de paquets LaTex qui ne sont (du moins j'imagine) pas supporté par MathJax/ - Des tableaux, schémas (Tikz ..) et je n'ai pas envie de faire un mixte Formules Latex + Images pour les contenus non supportés.

Une autre raison qui me repousse à utiliser MathJax est (c'est un avis personnel ^^) la différence trop marquée entre le contenu mathématique et le reste (dans une preuve par exemple, ou il y a pas de mal de texte).

Bref, dans l'idéal j'aimerais vraiment pouvoir afficher le rendu de pdflatex .

J'ai notamment tenté de recoder un programme similaire à https://www.idrsolutions.com/online-pdf-to-html5-converter/ (Qui produit de très bon résultats). L'idée est d'affichée une image svg (générée à partir de pdflatex puis avec pdf2svg par exemple) en fond, et d'apposer une balise HTML (span par exemple) par élément de texte au dessus de l'image. De cette manière, on peut sélectionner le contenu comme si c'était du HTML classique. (Les span sont positionnés parfaitement au dessus de l'image)
(Le tool que j'ai fais : https://github.com/QuanticPotato/pdf2html)

Mon programme fonctionne presque correctement (J'arrive à extraire les polices, positions des éléments texte), mais ces positions que j'extraie ne correspondent pas exactement aux positions réelles des éléments sur l'image

J'en viens donc à ma première question :

(Étant donné que je génère l'image avec pdf2svg et que je récupère les positions des éléments avec l'utilitaire pdf2json (qui utilise pdf.js). Étant donné que les éléments sont décalés de quelques pixels, je me disais que ça pouvait peut être venir de là ..)

Une autre solution (qui reprend presque le même principe) est celle ci : http://jsfiddle.net/vivin/rjquf/. À la place d'utiliser une image SVG en fond, on fait directement un rendu avec pdf.js (Qui rend le pdf dans un canva).

Avec cette solution, le texte juxtaposé sur l'image correspond à peu près (la longueur des mots n'est pas exactement la même mais ça ne gène pas). J'imagine qu'il n'y a pas de décalage puisque c'est le même "moteur de rendu" qui est utilisé pour l'arrière plan et le texte (pdf.js) ..

Le problème de cette solution est que j'ai l'impression que quand j'affiche plusieurs documents sur une même page, pdf.js n'a pas l'air de supporter et me sors des polices horribles :

Ma dernière question est

Rappel :

• Afficher le document avec un rendu similaire à pdflatex
• Afficher une contenu vectorialisé (pas de pixelisation ..)
• Optionnel : Pouvoir sélectionner le texte

Merci de m'avoir lu

Hummm… Pourquoi ne pas afficher directement le pdf généré par LaTeX dans la page web ? Prenons un exemple tiers concret : http://www.mathweb.fr/mathematiques-documents-mathematiques--articles--Aire-entre-trois-cercles-tangents.html

Comment cela s'affiche-t-il chez toi ? Chez moi, avec Safari, parfaitement.

Oui j'y ai pensé (J'ai essayé avec pdf.js, qui permet d'intégrer très facilement le pdf dans le reste du site (sans la barre de status ..)).

Mais le problème c'est qu'une page peut contenir plusieurs (jusqu'à 10) petits documents, et quand j'en mets plus que deux j'obtiens des bugs d'affichage : (J'avais mis cette image dans mon premier post, mais elle ne s'était pas affichée … j'ai édité le message )

EDIT : Voici le "vrai" rendu attendu :

Pourquoi passer par pdf.js ? Comment s'affiche dans ton navigateur le pdf de la page dont j'ai donné le lien ? Mon navigateur affiche les pdf nativement, peut-être n'est-ce pas le cas avec ton navigateur habituel, ce qui serait dommage. Ou bien (ce n'est pas clair dans ta réponse), quand tu intègres plusieurs pdf sur une même page web avec la méthode suivie par le site mathweb, ton navigateur perd la boule et affiche un peu n'importe quoi ? Dans ce cas, si tu peux donner une page d'exemple afin que ça soit testé avec différents navigateurs, ça pourrait permettre d'avancer.

Je passe par pdf.js pour avoir un contrôle complet sur le widget qui affiche le pdf (Je ne veux pas que le document prenne toute la largeur de la page, et j'aimerai bien ne pas afficher la barre d'outils). De plus l'affichage natif de pdf requiert très souvent Flash, ou un plugin externe, ce que je veux absolument éviter

Mon navigateur affiche les pdf nativement (Firefox), et il utilise justement pdf.js

J'ai fais une page d'exemple : http://hx2-chato.fr/pdf/
(Le bug arrive chez moi quand j'actualise plusieurs fois la page d'affilé)

J'utilise la deuxième méthode que j'ai décrite : rendu du pdf avec pdf.js dans un canvas, et superposition d'un "textLayer" pour pouvoir sélectionner le texte. Chez moi quand je rafraîchis plusieurs fois la page, l'affichage perd la boule de façon aléatoire …

On ne dirait peut être pas, mais il y a 4 pdf d'affichés sur cette page. C'est aussi une raison pour ne pas utiliser l'affichage natif : comme ce sont de petits document, il faut que l'affichage soit le plus discret possible (ie pas de grosse barre d'outils / bordures ..)

Merci de tes réponses

Bon alors concernant la méthode utilisée par mathweb (Les PDF sont tout simplement affichés dans des iframes), ça ne marche pas avec mes PDFs … firefox ne veut pas les afficher directement, il ne peut que les télécharger oO (C'est probablement du au package standalone (qui ne produit pas des PDFs au "format standard").

Sinon concernant ma toute première question, j'ai trouvé la cause (Le problème d'alignement du texte sur le fond). Les positions que je récupère "collent" à la lettre en question : La position $y$ dépend donc de la lettre (minuscule/majuscule, voyelle/consone ..) …
Or quand je place mes éléments avec du CSS, je place un "bloque" de texte. Il me faudrait donc un moyen pour calculer la taille de la lettre en question, et ajouter un décalage au placement. C'est possible ?

Je ne pense pas que le format non-A4 du package 'standalone' soit le problème, un PDF pouvant avoir légitimement n'importe quelle dimension. Peut-être que Firefox n'accepte pas plusieurs PDFs par page web. Je ferais des essais ce dimanche.

Pour ta question sur le calcul de la taille de lettres, il me semble que c'est possible par Javascript. J'essaye de retrouver le lien et j'édite le cas échéant.

Voilà : http://www.developpez.net/forums/d261673/webmasters-developpement-web/general-conception-web/contribuez/faq-determiner-longueur-d-texte/

À adapter, puisque c'est pas la longueur d'un texte (ou largeur d'une lettre) mais la hauteur d'une lettre que tu cherches à obtenir. J'espère que le lien donné te permettra cela.

Question sans doute conne et un peu HS, mais est-ce que tu as essayé de voir ce que donnaient les packages de conversion directe de LaTeX vers HTML ? Par exemple TeX4ht.

Non, je n'ai pas testé. Toutefois, la page http://pages.uoregon.edu/noeckel/tex4ht.html donne un exemple concret. La sortie pdf est ici : http://pages.uoregon.edu/noeckel/computernotes/latex/tex4htExample.pdf tandis que la sortie html correspondante est là : http://pages.uoregon.edu/noeckel/computernotes/latex/tex4htexample.html (les formules mathématiques sont rendus sous forme d'image) et enfin la sortie xml est celle-ci : http://pages.uoregon.edu/noeckel/computernotes/latex/tex4htexample.xml .

On est loin du compte, ne trouves-tu pas ? Le HTML n'est pas prévu pour un beau rendu typographique. Pour un beau rendu typographique, il faut des dimensions de pages fixes (pour par exemple calculer le gris typographique). Or une fenêtre de navigateur est redimensionnable, en largeur notamment. À ma connaissance, rien ne permet encore de d'obtenir quelque chose de satisfaisant.

Oui, le rendu des formules en image est à proscrire ;).

Sinon concernant la taille des lettres, j'ai réussi à tirer quelque chose :

J'utilise directement la définition des glyphs du svg (ce sont des balises <path> http://www.w3schools.com/svg/svg_path.asp). J'utilise ensuite la bibliothèque http://raphaeljs.com/ pour calculer la taille du caratère.

Après conversion en pixel (je sais pas pourquoi les <svg> fonctionnent en pt ?), j'arrive à placer correctement le texte sur le svg en fond (En appliquant un letter-spacing approximati)

Il ne me reste plus qu'à gérer les caractères spéciaux et ce sera fini. Je posterai le code et une démo pour que vous me donniez votre avis sur le rendu (SVG en fond + le texte dans des <span> pour pouvoir le sélectionner).

Ah, tant mieux, car mes essais avec divers navigateurs d'affichage de pdf intégrés dans une page web tournent au carnage. Tel navigateur ne tient pas compte du paramètre de zoom, tel autre ajoute une bordure dans une version plus récente, et Firefox conserve l'affichage de sa barre d'outils même dans un code du genre :

1
2
3

<object data="test1.pdf#zoom=400&scrollbar=0&toolbar=0" width="316px" height="120px" type="application/pdf">
<p>Votre navigateur ne parvient pas à afficher les PDFs !</p>
</object>

(voir ici : http://pdfobject.com/markup/index.php pour voir plus d'infos)

Je ne suis pas d'accord avec cette démolition en règle du format PDF. Le manuel de Tikz, avec son millier de pages, richement illustré, ne pèse que quelques Mo. Converti en HTML ou en ePub, je serais curieux du résultat en terme de Mo. Sans compter le résultat typographique affreux.

Concernant la flexibilité de l'affichage pour pallier aux problèmes visuels de certaines personnes, un OS bien pensé peut déjà y remédier en grande partie.

Pour ce qui serait du fait que le PDF serait uniquement destiné à l'impression sur papier, ce qui déjà est bizarre par la présence du mot Portable dans l'acronyme, il faudra expliquer pourquoi les ingénieurs d'Apple ont choisi le PDF comme base du moteur d'affichage de Mac OS X : https://fr.wikipedia.org/wiki/Quartz_2D (en fait, OS X a pour ancêtre NeXTStep, dont l'affichage est basé sur Display PostScript ; NeXTStep a été créé sous l'impulsion de Steve Jobs après son départ forcé d'Apple en 1985, puis ce système a été racheté en 1996 par Apple pour servir de base au futur de Mac OS. Les difficultés financières d'Apple à l'époque ont poussé le PDG (CEO aux USA) d'alors à la démission en 1997, et Steve Jobs a été nommé PDG par intérim, ce qui a donné le mot iCEO dans la presse à l'époque de la sortie de l'iMac en 1998 ; la suite prestigieuse, on la connaît tous).

Voilà, j'ai à peu près terminé mon outils de conversion
Voila une page de test : http://hx2-chato.fr/pdf/out.html (La page peut prendre quelques secondes à charger, puisque le rendu est en partie fait dans le navigateur). Voici le pdf original : http://hx2-chato.fr/pdf/energies.pdf

Je suis entièrement d'accord sur le fait que le PDF n'est plus trop dans les tendances actuelles (Responsive ..).
Mais je suis aussi (encore plus d'accord) que le LaTex (Donc le PDF indirectement, même s'il sert à beaucoup d'autres choses) est un moyen beaucoup plus riche d'afficher un contenu de façon vraiment bien … C'est notamment pour ça que je souhaitais vraiment obtenir un rendu similaire à pdflatex.

Du coup je pense effectuer plusieurs générations de PDF (pour plusieurs tailles d'affichages), et de les afficher de la même façon que sur le lien que je viens de poster. Je vais cependant essayer de placer toute le processus de rendu (calcul des positions des textes ..) niveau serveur (En amont, avant l'affichage dans le navigateur)

Après (on part dans un autre débat là ), je ne sais pas si MathJax va 100% dans la direction des tendances actuelles (Je penses notamment au Web Assembly ..), bien que le contenu soit responsive au moins.

Le manuel de Tikz, avec son millier de pages, richement illustré, ne pèse que quelques Mo. Converti en HTML ou en ePub, je serais curieux du résultat en terme de Mo. Sans compter le résultat typographique affreux.

Je ne connais pas le manuel dont tu parles mais pour la taille, probablement peu ou prou pareille je pense.

• Si le PDF est suffisament bien fait (c'est-à-dire pas d'images scannée ou je ne sais quelle connerie du genre), le texte reste fondamentalement du texte, avec çà et là des commandes de mise en forme (à remplacer par des informations sémantiques en HTML). En principe c'est de l'UTF-8 partout.
• En PDF on fait du layout à niveau microscopique (on place quasiment le texte lettre par lettre) tandis qu'en CSS on a des règles de placement beaucoup plus macroscopique, je ne crois pas qu'on y perde en taille (au contraire même je dirais).
• Autant en HTML qu'en PDF on peut faire du vectoriel ou du bitmap pour les illustrations (SVG vs PNG/JPG).
• Tu peux ou pas incorporer les polices dans les deux.
• Autant le PDF que le epub sont compressés, avec des algorithmes similaires (la compression est optionnelle pour PDF mais en gros c'est voisin du gzip/deflate, comme le format zip d'epub)

Par contre pour la typographie tu as sans doute raison aujourd'hui. Ou du moins il faut beaucoup plus travailler son CSS pour arriver à un résultat aussi bon. Mais c'est en train de changer avec CSS3 et les specs qui continuent d'évoluer.

En tout cas la demande pour une typographie plus riche et un meilleur contrôle du flux de texte sur le web existe. Ce n'est qu'une question de temps.

Concernant la flexibilité de l'affichage pour pallier aux problèmes visuels de certaines personnes, un OS bien pensé peut déjà y remédier en grande partie.

Oui et non. Sauf si le PDF est taggé correctement, ce qui est très très rare même si le standard existe et est ouvert depuis 2008, le contenu est positionné très précisément sur une page à taille fixe. Les lecteurs de PDF pour malvoyants doivent décupler d'ingéniosité pour arranger le contenu autrement que ce qui est prévu dans la grille pour le rendre plus agréable, et souvent ils n'y arrivent pas très bien. Simplement parce que celui qui a enregistré le PDF ne l'a pas fait bien, ou plutôt, l'outil qu'il a utilisé pour enregistrer son PDF persiste dans le déni et l'obsolescence (pour le coup, l'outil est nettement plus à reprocher que l'utilisateur, qui ne devrait même pas avoir à se soucier des détails techniques). Je suis non-voyant moi-même, je suis bien placé pour le savoir.

Pour ce qui serait du fait que le PDF serait uniquement destiné à l'impression sur papier, ce qui déjà est bizarre par la présence du mot Portable dans l'acronyme,

Je ne suis de loin pas le seul à critiquer la signification de l'acronyme et dire que c'est (ou c'était initialement) juste un argument de vente.

il faudra expliquer pourquoi les ingénieurs d'Apple ont choisi le PDF comme base du moteur d'affichage de Mac OS X

Par commodité parce que rien ne sert de réinventer la roue (sauf si on pense pouvoir faire mieux), et parce qu'Apple et Adobe ont toujours été très proches jusqu'à leurs différends concernant Flash. Je l'ignorais complètement mais ça ne me surprend pas, c'est un choix tout à fait logique. Tant que le PDF est roi, c'est même un très bon choix: ça permet probablement d'afficher un PDF avec des performances supérieures aux autres OS.

De toute façon au moment où on affiche du contenu dans une zone bien définie, il faut bien convertir les données flexibles et relatives en positions absolues. Fondamentalement, le GDI et le DirectX de windows font la même chose. Donc plutôt que de refaire un truc à leur façon, c'était quand même plus simple de reprendre le travail déjà fait par d'autres.

Se baser sur un moteur HTML/CSS aurait été totalement inimaginable à l'époque des premiers OS X. Tout le monde était sur IE et les standards web à peine nés déjà en hibernation. Alors une interface graphique d'OS entière, la blague ! On verra ce que vont donner Firefox OS et Chrome OS mais ils ont fait un pari intéressant.