Afficher un document LaTex dans une page Web.

L'auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet

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 :D .

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 :

Est-ce que les positions des éléments dans un pdf sont absolues ? Ou alors dépendent-elles du logiciel qui fait le rendu ?

(É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 : pdf.js ne supporte pas plusieurs rendus ?

Ma dernière question est

Voyez-vous d'autres solutions à ce problème ?

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 :)

Édité par QuanticPotato

+0 -0
Auteur du sujet

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 : Image utilisateur (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 : Image utilisateur

Édité par QuanticPotato

+0 -0
Banni

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.

Intérêts : OS X, AppleScript, Swift, LaTeX

+0 -0
Auteur du sujet

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 :p

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

Édité par QuanticPotato

+0 -0
Banni

Cette réponse a aidé l'auteur du sujet

Je viens de faire quelques tests avec ta page. Outre l'affichage effectivement inconsistant à certains endroits, suite à plusieurs rafraichissements, j'ai eu droit à un petit plantage (mais le navigateur n'a pas quitté) :

1
2
3
4
5
6
7
Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x00007f0100000001

VM Regions Near 0x7f0100000001:
    JS JIT generated code  00002eba68401000-00002eba68402000 [    4K] ---/rwx SM=NUL  
--> 
    MALLOC_TINY            00007fb432c00000-00007fb433000000 [ 4096K] rw-/rwx SM=COW 

D'autre part, si j'essaye sur ma tablette, la page en question reste totalement blanche.

Concernant l'intégration directe d'un fichier pdf dans une page web, comme suggéré au début, j'ai regardé comment ça s'affiche dans Firefox avec la page mathweb indiquée. En effet, hélas, Firefox affiche une barre d'outils. Il y a peut-être moyen de la masquer ?

Dans le navigateur Safari, une zone d'outil minimaliste s'affiche en surimpression transparente lorsqu'on place le pointeur de la souris au bas de l'affichage du pdf. Cela permet d'accéder aux principales actions (agrandir, réduire, enregistrer, ouvrir dans l'app d'affichage de pdf livrée avec OS X) sans empiéter sur l'expérience utilisateur. Le menu contextuel apporte d'autres actions.

Affichage de pdf sans barre d'outil additionnelle

Mini outil de Safari pour pdf

À mon avis, à moins que tu parviennes à déboguer l'afficheur pdf.js, le mieux est d'en passer par l'affichage direct du fichier pdf dans la page web. Avec le package standalone que tu emploies, leur affichage ne devrait pas ajouter de barre de défilement dans le navigateur. Il reste à voir s'il est possible de demander (via le code web de la page) à Firefox de ne pas afficher sa barre d'outils. Selon un test ponctuel, Google Chrome (installé uniquement pour tests, lancé moins d'une fois par mois) affiche également nativement le pdf dans la page web, sans barre d'outil. Reste à voir le cas du cancre du web, mais je ne suis pas sous Windows, donc je ne saurais pas dire ce qu'il en est sous ce navigateur-là.

Peux-tu prendre tes quatre fichiers pdf et les afficher dans une seconde page de ton site avec la méthode employée par le site mathweb ?

Intérêts : OS X, AppleScript, Swift, LaTeX

+1 -0
Auteur du sujet

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 : Image utilisateur 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 ?

+0 -0
Banni

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").

QuanticPotato

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.

Édité par quark67

Intérêts : OS X, AppleScript, Swift, LaTeX

+0 -0
Banni

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.

Intérêts : OS X, AppleScript, Swift, LaTeX

+1 -0
Auteur du sujet

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).

+1 -0
Banni

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)

Intérêts : OS X, AppleScript, Swift, LaTeX

+1 -0

Cette réponse a aidé l'auteur du sujet

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.

Au temps pour moi, je n'ai pas tilté que LaTeX4ht convertissait les formules en images. A proscrire donc, effectivement; c'est définitivement moche. Par contre il existe d'autres logiciels similaires, dont un qui a été développé en Haskell par une université française mais dont j'ai complètement oublié le nom; il me semble que la démo était beaucoup mieux. IL y a aussi pandoc mais je ne l'ai pas mentionné puisqu'il utilise mathjax par défaut; peut-être qu'en bidouillant avec les options tu peux utiliser un autre système.

Pour revenir plus globalement à ton interrogation: c'est juste, on est très très loin du compte, encore plus pour les mathématiques, mais ça dépend toujours où on met le curseur. Le PDF c'est fait pour de l'impression papier, le HTML/CSS pour de l'affichage sur les écrans. ET les contraintes ne sont pas du tout les mêmes, d'un côté on a hérité de positionnements absolus et d'une riche expérience graphique/typographique éprouvée, de l'autre on se doit d'être flexible pour s'adapter aux différentes tailles d'écran et conditions de lecture qui se multiplient.

Le fait est qu'aujourd'hui, c'est indéniable, on est un peu entre deux mondes: On se retrouve le cul entre deux chaises et il faut choisir: la qualité de l'absolu et du papier, ou la flexibilité des écrans. En tant que représentans antagonistes de ces deux mondes, PDF et HTML/CSS ne sont pas faits pour cohabiter: tu l'as bien vu toi même, afficher du PDF dans un navigateur c'est la croix et la bannière; et tu n'as encore pas vu le bordel que ça fait sur mobile, si tant est que tu arrives à le faire sans app extérieure.

Tu as je pense bien compris que le web incarne par définition le monde du flexible, du mobile, partout, tout le temps. Dans ce contexte, PDF est d'un autre âge; et malheureusement, bien que sémantiquement et qualitativement beaucoup plus riche que HTML, à cause de la façon dont il a été conçu dans les annés 1970, LaTeX aussi.

Ce n'est pas facile mais il faut apprendre à lâcher prise sur le web. Qu'est-ce quie est le plus important, l'aspect purement visuel d'une oeuvre, ou les informations qu'elle apporte ? Mème si on est bien d'accord q'une information joliment présentée est toujours plus attrayante et plus retenue.

LE format epub3 devrait résoudre la situation en partie. Pour les mathématiques spécifiquement, il y aura MathML. On conserve malgré tout le clivage papier vs écran car un mode fixed layout radicalement différent du mode normal est prévu. Problème, vu l'enthousiasme qu'il y a derrière ce format, il va mettre encore longtemps à s'imposer. C'est bien dommage.

Ma plateforme avec 23 jeux de société classiques en 6 langues et 13000 joueurs: http://qcsalon.net/ | Apprenez à faire des sites web accessibles http://www.openweb.eu.org/

+1 -0
Banni

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).

Intérêts : OS X, AppleScript, Swift, LaTeX

+0 -0
Auteur du sujet

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.

+0 -0

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.

Ma plateforme avec 23 jeux de société classiques en 6 langues et 13000 joueurs: http://qcsalon.net/ | Apprenez à faire des sites web accessibles http://www.openweb.eu.org/

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte