Sommaire
Après les navigateurs comme systeme d'exploitation, voici les navigateurs comme traitement de texte. Promis, au prochain journal on montre comment utiliser Firefox comme grille-pain.
C'est quoi cette hérésie ?
Il peut sembler stupide de comparer le HTML5 (+CSS3+javascript) qui sert désormais à faire des webapp, avec le vénérable latex. Mais pas tant que ça finalement.
Après tous, le HTML a été fait à la base pour baliser des documents texte. Il possède l'ensemble des balises nécessaires pour écrire un texte un peu complexe (h1, cite, def, figure,…).
Je vais ici essayer de donner qq arguments en faveur du HTML et pourquoi il a la possibilité de devenir un standard dans l'écriture scientifique, surtout à l'époque des MOOC (par contre je ne sais pas si c'est une bonne ou mauvaise chose, personnellement je ne connais que latex donc si je pouvais me tromper, ça m'arrangerait fortement)
Contexte
Dans mon travail, j'ai souvent à faire des présentations pour décrire mes travaux, or afin de pouvoir être le plus pédagogique possible, il peut être intéressant d'utiliser des animations voir des petites vidéos.
Or pour cela, il existe pour le moment trois logiciels principaux :
Microsoft Powerpoint, que je ne connais absolument pas qui a l'avantage d'être présent sur tous les ordinateurs utilisés pour les présentations. Donc à priori la compatibilité est maximale (modulo la version installée), il est possible d'en utiliser toutes les facettes.
Libreoffice impress, celui que j'utilise le plus souvent. Malheureusement pas toujours présent sur les ordinateurs de présentation, ce qui m'oblige à avoir un pdf en fallback donc sans animation ni vidéo.
Latex beamer, qui permet d'inclure vidéo et animation via les packages animte et media9.
Et le HTML dans tous cela ?
Or si on y réfléchit, il existe un logiciel présent sur 99% des machines, un navigateur internet.
De plus la concurrence entre les différents navigateurs (firefox, chrome et IE principalement) les poussent à un respect des standards de plus en plus complet.
Il est donc possible de s'appuier sur lui pour créer des présentations lisible partout, respectant un format ouvert et lisible par un humain (le HTML, je ne l'apprend à personne, c'est du texte).
D'ailleurs, plusieurs frameworks expoitent cette idée, le plus en vogue semble être reveal.js.
De plus, la 5ème itération du HTML permet qq nouveautés intéressantes:
Inclusion facile de vidéo
Accès à un language de script (javascript pour ce qui ne suivent pas) qui permet par exemple de prendre un xml de données en entrée et de sortir un graph. Exemple highcharts ou gRaphaël
Utilisation d'un format d'image vectoriel favorisé, le SVG qui peut être utilisé pour faire des animations.
Certains me diront que latex fait déja tout cela, ce que je nie absolument pas mais (car il y a toujours un mais) :
L'inclusion de la vidéo nécessite un paquet supplémentaire (media9), et le support des PDF avec vidéo n'est pas toujours bien répandu (adobe reader est à privilégier)
Lualatex arrive, donc la possibilité de scripter du latex existe, mais c'est encore très récent, la doc sur lualatex est rare comparer au couple HTML/CSS/Javascript
-
Pour faire des images vectorielles (graphique par exemple), il existe des alternatives tel que pstrick ou asymptote qui donne de magnifique résultat. C'est vrai, mais un des grands avantages que je trouve au HTML par rapport à latex, c'est que dans le cas de latex, on n'a souvent que le pdf et non les sources, donc finalement si on veut réutiliser les images ou extraire les données d'un graph, soit on envoi un mail à la personne qui l'a créé, soit on fait un copier/coller tout moche et on extrait les données via des soft tel que Graph Data Extractor.
Dans le cas du HTML, on a les sources (le svg) donc les valeurs nécessaires pour refaire le graph. Dois je rappeller ici l'interet d'avoir les sources !?Néanmoins, pour être objectif, je suis obligé de mentionner qq points
noirs du HTML.
Le positionnement des objets peut être assez ardu à prévoir. (exemple, je crée ma présentation HTML sur un écran 16/9, 1920x1080, mais le rétroprojecteur est en 4/3, 800x600, comment prévoir ce qui va se passer).
La syntaxe du HTML est ultra méga giga verbeuse par rapport au latex. Et je dois encore oublier plein d'aspect.
Ok pour remplacer Beamer, mais pour le texte, pour ecrire des publications !?
Pour le texte, je concède que latex est achment mieux fait, on peut facilement
écrire un texte via son balisage léger de plus le combo \ref \label est très pratique pour ne pas avoir à ce soucier des numérotations. Alors que de son coté, comme déjà dit, le HTML est bien trop verbeux.
Néanmoins, il existe déjà un ensemble de techno pour faciliter l'écriture :
Markdown, textile et autres pour le texte
Mathjax pour les équations scientifiques.
De plus, si on regarde comment fonctionnent des cms statiques tel que Jekyll, on s'aperçoit que créer un cms integrant un ensemble de bibliothèque javascript dédié aux sciences + un support de mathjax + une sortie en epub au lieu du HTML (ce qui ne doit pas être très dur étant donné que epub = HTML zippé), le tous permetant une écriture rapide et efficace, ce ne doit pas être très compliquer à faire.
Dernier point à double tranchant, le fond est vraiment séparé de la forme, le css est bien à part. Il est d'ailleur plus facile de créer des feuilles de style. Avec bien sur la possibilité de faire qq chose d'absolument horrible.
D'ailleur des éditeurs tels que sciencedirect proposent de télécharger les publications en ePub.
Conclusion
Il me semble que si un cms dédié à la création d'epub, incorporant qq bibliothèques dédiées aux sciences était créé, on aurait là un bon prétendant à latex. D'ailleurs, un outil tel que Pandoc permet déja de réaliser une conversion Markdown -> epub3 avec formule mathématique mais pas de javascript me semble il ?
Peut-être que je me trompe et que je me suis fait avoir par tous les buzz word actuel (markdown, jekyll, haml,… ) et que Latex restera LE traitement de texte des scientifiques mais avec l'arrivée des tablettes et des liseuses, j'ai des doutes. De plus à l'origine, le HTML, c'est fait pour ça, non ? Une cohabitation sera elle possible avec chacun son domaine de prédilection l'un pour les pdf à imprimer et l'autre pour le numérique?
Y a-il dans l'assemblée une âme généreuse pour me fabriquer ce petit cms statique ?
PS : Un petit coup de gueule envers ScienceDirect qui propose certe un export epub, mais d'une qualité catastrophique. Non, convertir un HTML en epub via Calibre n'est pas professionel (surtout à 30 € la publi). Avoir la balise<h1>Introduction</h1>
qui devient<p class="calibre27"><span class="calibre20"><span class="calibre6">Introduction</span></span></p>
c'est très moche, on perd toute la sémantique des balises.
# Question intéressante
Posté par Perthmâd (site web personnel) . Évalué à 2. Dernière modification le 21 octobre 2013 à 23:42.
Je songeais moi aussi à utiliser HTML comme backend pour faire des présentations, parce que j'ai beau aimer le rendu de LaTeX, Beamer, c'est quand même assez arcanesque. Je précise quand même que je fais assez régulièrement des présentations en Beamer (je dois en faire une demain, d'ailleurs).
Le problème principal, commun à (La)TeX et HTML/Javascript, c'est leur langage de programmation, insupportable dans les deux cas. Javascript peut-être un peu plus expressif que TeX, il n'en reste pas moins que je préférerais un langage vraiment moins crade.
Je pense explorer deux pistes. D'une part, j'ai entendu du bien de quelques gusses de ma connaissance qui développent le langage de mise en forme du futur, j'ai nommé Patoline. Ils ont même un backend OpenGL pour faire des diagrammes 2-catégoriques en 3D qui tournent tous seuls, c'est dire.
L'autre méthode serait d'utiliser l'artillerie lourde à base d'Ocsigen pour générer du HTML à partir de code OCaml, et plus précisément js_of_ocaml, qui est un compilateur OCaml vers Javascript.
Oui, je précise aussi qu'OCaml est mon langage de préférence, qu'il se prête très bien au scripting, et que ces deux solutions utilisent précisément OCaml en interne. Je suis cependant preneur de n'importe quelle solution qui utiliserait un langage décent (exit JS donc).
[^] # Re: Question intéressante
Posté par akimatsumoto . Évalué à 2.
Peut-être trouveras tu ton bonheur avec Lualatex. Mais c'est encore très dur de trouver des exemples simple.
Malheureusement pour Patoline, j'ai du mal a y croire. Non pas que ce ne soit pas bien, mais latex a fonctionné car à l'époque je ne suis pas sur qu'il y avait beaucoup de concurrence sur ce créneau. Alors que maintenant, avec l'omniprésence du html, et l'arrivé de l'epub, même des grand comme adobe adaptent leurs soft pour en générer.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2. Dernière modification le 22 octobre 2013 à 11:38.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Question intéressante
Posté par barmic . Évalué à 4.
Je suis surpris que tu cherche principalement un langage pour faire du comportement plutôt que de la présentation. Personnellement pour moi une présentation c'est du texte/des images/des vidéos/du son éventuellement quelques animations, mais c'est tout.
Qu'est ce que ocaml ou js apporten à tes présentations ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Question intéressante
Posté par Perthmâd (site web personnel) . Évalué à 1.
Le fait de pouvoir créer des DSL de manière locale avec un métalangage, typiquement. J'ai souvent envie de parser puis manipuler des ASTs dans une présentation pour les enrichir à loisir et les afficher selon mon bon vouloir. Chose assez difficile à faire dans un langage comme TeX ou JS…
[^] # Re: Question intéressante
Posté par ZankFrappa . Évalué à 3.
OCaml (qui est fortement impliqué dans la chaîne de compilation d'un document Patoline) permet un certain nombre de choses : d'une part il est très adapté à l'écriture de parsers (l'équipe de Patoline a par exemple un parser pour les maths, qui parse tes expressions pour calculer l'espacement à rendre — bien sûr c'est facile à personnaliser, et vu le nombre de DSL qui existent déjà en LaTeX et qui produisent des messages d'erreur absolument imbitables on voit bien le bénéfice potentiel), d'autre part il est relativement rapide (les rares utilisateurs de Patoline ont l'air très satisfaits des performances, qui semblent meilleures que celles de LaTeX pour des documents plein de macros), et enfin il est statiquement typé — oui, dans un document LaTeX complet, tu as tellement de programmes qui interagissent que ça peut avoir de l'importance. Mais ça c'est surtout la rédaction.
Le côté JavaScript permet de générer des présentations qui sont plus interactives que des PDF « beamer » classiques. Par exemple, certains auteurs (et utilisateurs) de Patoline travaillent avec une tablette qui leur permet de passer les transparents à distance ou de pointer directement sur la tablette ce dont ils parlent (une utilisation très classique je te l'accorde), mais aussi de pointer des zones de texte qui peuvent être mises en valeur pendant la présentation. Imagine un transparent un peu chargé avec différentes informations importantes, sur lesquelles tu as des zones que tu veux mettre tour à tour en relief. Plutôt que de les désigner avec ton pointeur laser et de faire tourner très vite ce dernier pour entourer la zone en question, tu appuies une fois sur la zone sur ta tablette, et elle est mise en relief sur l'écran. C'est pas magique ?
Plus généralement, c'est peut-être l'occasion d'apporter quelques améliorations dans l'interactivité des transparents. Comme ils ont l'habitude de travailler avec des projecteurs pourris, ils réfléchissent aussi à la possibilité d'utiliser la webcam, en début de présentation, pour calibrer un peu les couleurs utilisées dans les transparents (et éviter les « ah là ça aurait du être en rouge »). Mais je suis sûr qu'en cherchant un peu tu peux trouver des fonctionnalités à leur proposer.
[^] # Re: Question intéressante
Posté par barmic . Évalué à 2.
Je comprends bien l'intérêt d'avoir un parseur de données externe. Je pense par exemple à la génération d'un graphique à partir d'un csv au moment de la compilation (il me semble important d'avoir une phase de compilation pour figer la version, mais c'est un détail). Mais c'est un besoin qui me semble assez rare. L'écriture de vrai DSL me parait encore plus rare sachant qu'il faut rentabiliser le temps de la création de ce dernier (écrire un DSL pour un écran me paraît pas pertinent).
Ce que tu décris avec js, c'est ce que fait impressive avec les PDF :)
Ça me paraît être une excellente idée, mais il faut que la webcam en question soit elle-même calibrée.
Mais du coup il s'agit de logiciels type impress/powerpoint qui font à la fois l'édition et la publication ? Personnellement j'aime beaucoup l'idée de sortir un PDF ou du HTML pour ne pas être dépendant de mon ordinateur. Le cas normal pour moi c'est d'avoir tout sur mon ordi, le fichier sur ma clef et sur internet, si pour une raison ou un autre mon PC ne fonctionne pas, je peux toujours faire la présentation.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Question intéressante
Posté par Maclag . Évalué à 5.
J'imagine très bien, et ma conclusion est que c'est un transparent de merde. Un bon transparent envoie un élément clé et un seul. Cet élément est présenté de façon la plus claire et la plus concise possible, le discours du présentateur étant censé apporter la "charge".
Un transparent chargé, c'est un transparent mal fait!
Si le transparent n'a pas vocation à être présenté par un présentateur, alors il ne devrait pas exister sous forme de transparent mais de rapport.
(on peut imaginer transformer le rapport en site web interactif également…)
[^] # Re: Question intéressante
Posté par barmic . Évalué à 2.
Sans parler de diapo chargée, c'est une fonctionnalité qui peut être utile. Par exemple si tu présente un tableau, tu veux pouvoir rapidement montrer la direction du regard de chaque personnage sans faire de multiple zoom-in zoom-out. Tu peut aussi dans le cas d'un schéma le présenter initialement étape par étape slide par slide (avec un affichage au fur et à mesure), mais quand arrive le moment des questions, tu peut vouloir garder l'ensemble du schemas tout en pointant diverses parties de celui-ci.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Question intéressante
Posté par vlamy (site web personnel) . Évalué à 1. Dernière modification le 22 octobre 2013 à 10:04.
Je ne cherche pas à te convertir, mais connais tu coffeeScript? C'est plus proche de Ruby que d'Ocaml, mais c'est aussi plus populaire il me semble, et avec une sacrée communauté.
My 2 cents !
PS : je vais regarder patoline quand même :)
[^] # Re: Question intéressante
Posté par SigNix . Évalué à 1.
Si docbook est encore bien vivant il pourrait répondre à ces différents besoins.
Il est possible de générer des documents pdf ou html assez simplement et avec différentes options (un page par section en html). L'export epub peut être pratique pour suivi sur des tablettes ou notebook.
Je ne sais par contre pas si c'est encore très actif par contre. Il y a 5 ans j'avais préparer des présentations et repris un journal de bord, incluant des médias, avec succès en utilisant les exports HTML (pour publications web) et PDF (image à la place des vidéos).
Si quelqu'un s'en sert je serais curieux de savoir si cette option est toujours viable.
[^] # Re: Question intéressante
Posté par anaseto (site web personnel) . Évalué à 3.
Je connaissais pas et ça a l'air vachement bien de pouvoir insérer des macros en OCaml à coup d'un simple
\Caml(...)! Je vais regarder ça plus en détail. Je me souviens avoir regretté aussi que LaTeX ne soit pas scriptable avec un langage plus sympa quand j'ai regardé il y a quelques temps BystroTeX qui permet de faire des slides avec des formules mathématiques en utilisant Scribble, le langage de documentation de Racket, qui est lui-même un dialecte de Racket (ça c'est la magie des dialectes de Scheme!), et j'avais trouvé sympa le fait d'utiliser le même langage pour des slides, de la doc ou du code.# SVG et fig dans un .tex
Posté par flan (site web personnel) . Évalué à 5. Dernière modification le 22 octobre 2013 à 07:11.
Personnellement, j'utilise des .fig et des .svg directement dans mes .tex, et cela permet d'utiliser du LaTeX (y compris les macro) dans les légendes. D'ailleurs, le HTML ne permet pas les macros, c'est éliminatoire pour moi.
[^] # Re: SVG et fig dans un .tex
Posté par lolop (site web personnel) . Évalué à 3.
HTML est un langage de description, pas un langage exécutable. C'est normal qu'il n'y ait pas de macros.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: SVG et fig dans un .tex
Posté par jyes . Évalué à 2.
Si tu es prêt à accepter une phase de "compilation" entre ton code source et le document final (comme avec TeX), tu peux utiliser XSLT pour écrire des "macros" XML. On n'y retrouve pas tout à fait le confort des macros LaTeX car le langage est trop verbeux, mais pas plus verbeux que le HTML (comparé à LaTeX !). Du coup, tu peux définir tes macros en XSL, écrire ton code en XHTML-étendu et compiler vers du pur XHTML.
Cette approche a le mérite de bien séparer les couches (c'est mon gros soucis avec TeX, il est trop facile et tentant de tout mélanger):
Pour le moment, j'utilise toujours LaTeX par inertie maintenant que je connais bien cet outil, mais je me dis régulièrement que je devrais basculer vers un outils utilisant HTML. Le plus problématique reste à mon avis l'écriture de formules mathématiques, car MathML n'est pas fait être écrit directement par un humain, donc les formules nécessitent toujours une étape de compilation pour produire le document final… et leur rendu dans les navigateurs actuels ne tient pas la comparaison avec ce que produit TeX.
# Un jour peut-être
Posté par 태 (site web personnel) . Évalué à 7.
J'ai décidé d'abandonner latex pour mes cours au profit de txt2tags au début et de markdown maintenant. Ma conclusion est qu'il manque encore pas mal de choses à markdown pour concurrencer latex. Certes, on peut faire un peu de maths en markdown mais ça ne passe pas simplement dans la conversion vers epub (les liseuses ne comprennent pas le mathml, le svg n'est pas non plus parfaitement supporté (j'ai fait un script pour que pandoc incluent les formules en svg quand il convertit en epub et certaines formules passent sur ma liseuse, mais celles qui sont complexes non)), les références bibliographiques manquent et surtout les crossrefs, genre "on verra ça dans le chapitre 3". Mais peut-être que ça viendra.
Par contre, ce qui ne viendra jamais j'en ai peur, c'est la typographie et tout ce qui tourne autour genre les césures.
En conclusion, pour rédiger des énoncés de TP et des supports de cours de quelques pages, le passage à markdown+pandoc est possible, pour la recherche, et les documents un peu conséquents, c'est hors de question d'abandonner latex. En passant, je continue de faire mes figures en latex (avec tikz) et je les compile vers svg pour les inclure dans mes documents markdown.
[^] # Re: Un jour peut-être
Posté par chimrod (site web personnel) . Évalué à 5.
C'est amusant, je fais l'inverse : j'écris mes cours (en tant qu'étudiant hein, le sens est polysémique) en restructuredText, et les converti en pdf via pdflatex.
Avantages :
c'est du texte balisé, donc c'est rapide à écrire et je n'ai pas à travailler la mise en page pendant le cours,
Le format rst gère nativement les les formules de math en syntaxe latex, donc je ne perd pas la qualité du rendu.
Je peux également sortir mon cours en html (c'est plus rapide que de générer du latex et je m'en sers pour contrôler la sortie).
[^] # Re: Un jour peut-être
Posté par 태 (site web personnel) . Évalué à 3.
Techniquement, j'utilise aussi le passage par latex avec pandoc pour produire des pdf. Mais j'ai définitivement abandonné latex comme format source parce que les exports en html ou epub depuis latex sont assez hasardeux (et que le source markdown est nettement plus lisible que du latex).
[^] # Re: Un jour peut-être
Posté par chimrod (site web personnel) . Évalué à 2.
Tout à fait, pour rester dans la comparaison avec le html, je pense que le html comme le latex sont des formats finaux et non pas des formats sources avec lesquels travailler.
Pour un cours, l'argument de la lisibilité est le plus important : je veux pouvoir lire mon cours directement dans mon éditeur de texte.
Ça rend bien sûr les choses moins souples puisque l'on à moins de contrôle sur la sortie, mais le temps gagné à côté compense largement la perte.
# Aide du présentateur
Posté par claudex . Évalué à 3.
Ce que je trouve qui manque avec Beamer, ce sont les notes pour le présentateur. Alors qu'avec Reveal.js, c'est assez facile (même si c'est encore un peu buggé).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Aide du présentateur
Posté par gouttegd (site web personnel) . Évalué à 7.
Afficher des notes sur l’écran du présentateur est tout-à-fait possible avec Beamer:
Après, il faut « juste » convaincre le lecteur PDF et/ou le gestionnaire de fenêtre d’afficher correctement le PDF généré, en envoyant la partie gauche (les notes) sur l’écran du portable et la partie droite (les diapositives) sur le vidéo-projecteur. Chez moi, je fais ça avec Xrandr :
ou encore, en tirant profit du fait que l’écran de mon portable a une résolution de 1600x900 :
pour afficher les notes et la diapositive en cours sur l’écran interne, et la diapositive sur l’écran externe.
[^] # Re: Aide du présentateur
Posté par Alexandre . Évalué à 9.
J'ai réalisé un outil pour faciliter ce cas d'utilisation, http://sourceforge.net/projects/qpdfpresenter/, si ça intéresse des gens :)
[^] # Re: Aide du présentateur
Posté par gouttegd (site web personnel) . Évalué à 3.
Je teste ça dès ce soir avec un deuxième écran, mais ça m’a tout l’air d’être exactement ce que je cherchais depuis longtemps.
Merci !
[^] # Re: Aide du présentateur
Posté par Alexandre . Évalué à 3.
C'est exactement pour cette raison que j'ai codé ça. Notamment pour les cours que je donnait. Mes collègues doctorants du labo étaient ravis. À noter que c'est du C++/Qt4, pas mal crade, mais que ça fonctionne normalement bien.
Il y a également la prise en charge des vidéos (grâce à libvlc) embarquées par le paquet movie15. Il y a d'autres paquets, mais ils produisent dans le PDF du code qui n'est (était en tout cas) pas encore pris en charge par Poppler quand je travaillais dessus.
[^] # Re: Aide du présentateur
Posté par gouttegd (site web personnel) . Évalué à 3.
Ça marche très bien chez moi, et après avoir testé sur deux écrans, je confirme : c’est bien exactement ce que je voulais. Du coup je te pardonne volontiers pour le code « pas mal crade ». ;)
En ce qui me concerne, movie15 fait l’affaire. Il est supposé être obsolète et remplacé par media9, mais ce dernier cible explicitement et exclusivement Adobe Reader, alors ce sera sans moi.
En tout cas, merci encore pour ce logiciel dont je vais faire un usage intensif.
[^] # Re: Aide du présentateur
Posté par Alexandre . Évalué à 2.
N'hésite pas à faire des retours en cas de besoins. Un jour il faudrait que je me remotive pour l'envoyer dans Debian …
# Langage
Posté par arnaudus . Évalué à 5.
J'ai aussi l'impression que Latex perd peu à peu du terrain à cause de l'archaïsme de son langage. Latex 3 n'en finit pas de se préparer, et d'après ce que j'ai cru comprendre, ça ne va pas être une grosse révolution non plus (l'équipe parle de "small bang", ça veut tout dire). Latex reste un langage très complexe, certaines parties sont très bien pensées (les équations par exemple, que je trouve extrêmement puissantes), mais l'ensemble du truc fait son âge, et accumule les atrocités : entre les \makeatletter, les sauts de lignes à commenter dans les macros, le langage des styles bibtex, ça ne respire pas non plus le truc pensé pour l'utilisateur occasionnel. Ça n'est pas étonnant non plus que les gens cherchent des alternatives plus utilisables. C'est bien dommage, car le rendu reste inégalable.
[^] # Re: Langage
Posté par akimatsumoto . Évalué à 4.
Je crois que le truc qui m'a donner le plus envie de partir du monde Latex, c'est quand j'ai ouvert les fichier qui définissent les class article et autre. C'est incroyablement complexe. Si on veut juste modifier un petit détail, on est parti pour tous comprendre.
Cela me rassure de me dire que je ne suis pas le seul à avoir du malavec sa complexité.
[^] # Re: Langage
Posté par arnaudus . Évalué à 10.
C'est aussi la limite de la philosophie de certains logiciels libres, qui sont pensés par leurs concepteurs pour subvenir à leurs besoins (des concepteurs, elle me fait chier cette phrase). J'imagine bien que quelqu'un qui est "fluent" en Tex et Latex puisse maitriser une telle complexité. Mais Latex n'est pas fait pour être utilisé par des programmeurs, c'est un logiciel de traitement de texte, et il offre bien peu de prises à des débutants. Ce qu'il est possible de faire, c'est d'être un utilisateur passif : on prend un style de classe, on l'applique, point barre. Mais dès qu'on veut modifier le moindre détail, le moindre espacement, la moindre numérotation, on se trouve face à un manuel d'alchimie ésotérique : rien ne correspond vraiment aux langages modernes, il n'y a quasiment pas d'opérations arithmétiques possibles, les concepts sont profonds et potentiellement foireux (typiquement, la dualité entre les environnements et les commandes (\begin{centrer} vs \centering)), il ne semble pas possible de modifier un paramètre dans les objets complexes sans tout redéfinir (pour mettre les titres de sous-section en italique, il faut redéfinir toutes les caractéristiques des titres de sous-section)…
À mon avis, ce qu'il faudrait à Latex, ce n'est pas un "small bang" : c'est la création d'une nouvelle surcouche au Tex pensée pour l'utilisateur, et pas pour le professionnel de l'édition. Avec Latex, on gagne du temps, c'est indéniable. Mais on en perd aussi tellement pour comprendre toutes ces c***ries liées à une interface utilisateur mal pensée et mal réalisés qu'il reste assez difficile de le prendre pour un exemple de ce qui se fait de mieux dans le libre, et c'est bien dommage.
[^] # Re: Langage
Posté par fravashyo (site web personnel) . Évalué à 5.
je suis 100 % d'accord. J'abhorre la syntaxe de LaTeX et toutes ses complexités. Les anti-slash \ qui me rappellent les chemins dans windows, les styles peu facilement éditables, les paquets qui sont un peu comme les distributions Linux, chacun est mieux que l'autre en théorie, mais la profusion rend difficile de savoir ce qui me conviendra le mieux : par exemple pour faire des boîtes, il vaut mieux prendre framed, mdframed ou tcolorbox ? (je me moque de la réponse, c'est juste un exemple, perso j'utilise mdframed).
Si je veux avoir certains titres numérotés, et pas d'autres (de façon globale, en fonction de la hiérarchie, pas au cas par cas), c'est aussi la galère, il faudra fouiller dans les cours en ligne pour trouver la bonne option.
En gros dès qu'on veut sortir un peu des sentiers battus, il faut faire beaucoup de tests de rendus pour trouver les options qui conviendront. LaTeX ce n'est pas du wysiwyg, c'est du wysiwyhtst : "What you see is what you have tested several times".
De façon générale, on présente souvent LaTeX comme séparant le contenu de la forme, mais en réalité ce n'est pas toujours ce qui se passe, et la forme est souvent bien présente dans le fichier .tex
C'est d'ailleurs le même problème avec le HTML, et en particulier dans les epub. C'est dommage d'avoir choisi ce format pour l'epub, une syntaxe légère aurait été plus adaptée. Quand on analyse certains ebooks, c'est une horreur, avec une redéfinition de police (la même) à chaque paragraphe etc.
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: Langage
Posté par hervé Couvelard . Évalué à 10.
Tu n'a pas tout a fait tort, mais tu tombes dans le classique.. c'est compliqué.
Si c'est vraiment compliqué pour toi et que tu cherches un traitement de texte, il y a pléthore d'outils en commençant par word et writter. Latex n'est pas cela, c'est un langage de description de contenu (par macro) qui permet de créer des documents.
Je ne crois pas que les concepts soient foireux, ils sont comme ils sont à cause de la philosophie de latex : tout est boite, même à l'intérieur d'un mot chaque lettre est une boite. Parce que l'objectif final n'est pas de rendre comment tu as envie de le voir rendu, mais de rendre pour que ce soit le plus agréable possible à lire avec comme premier impératif la gestion des blancs, la position des flottants l'espaces entre les mots, entre les paragraphes…
Oui c'est compliqué pour faire des modifications, mais n'est-ce pas compliqué d'écrire une routine d'allumage de diodes en c ? Et je parle même pas du truc si simple de prendre un nombre au hasard. Est-ce pour cela que les gens demandent que l'on modifie le c ? pour le rendre plus simple ? Pour avoir un alea() véritable et imprédictible ?
Oui il y a des macros empilées sur des macros empilées sur des macros…Tu n'es pas obligé de les utiliser, tu peux tout a fait les faire toi même simplement.
Ensuite on retombe dans le classique faut simplifier… comme gnome, ou pas…
Oui le langage est complexe parce que les possibilités sont énormes et parce que par dessus ces possibilités on continue à gérer les blancs, les espacements, la positions des flottants…
Alors oui html c'est vraiment plus simple. Tu devrais essayer d'écrire un rapport de 400 pages avec html puis en faire un pdf propre et imprimable. Lorsque tu auras fait, reviens et discutons ensemble.
Ce qui me hérisse (si on met de coté le fait que chacun puisse avoir ses opinions) c'est qu'il y a toujours un râleur qui vient expliquer que tel ou tel truc est compliqué et qu'il aimerait ceci ou cela (en donnant un exemple qui n'est pas comparable puisqu'il présente juste un microscopique sous ensemble d'un truc qui peut faire plus ou moins la même chose si on regarde de loin et qu'on accepte de ne pas utiliser grand chose) MAIS sans avoir besoin d'apprendre ni de passer trop de temps.
Latex a été fait pour imprimer sur les premières imprimantes laser. Avant ceux qui composaient calculaient le nombre de caractère pour tomber sur un nombre de pages déterminée (à cause des empagements), puis respectaient parfaitement les règles typographiques et se débrouillaient pour que ce soit agréable à lire (il y a 3 espaces différents en largeur). Aujourd'hui on retrouve des fautes partout, les règles typo disparaissent, des logiciels merdiques comme in design permettent de faire merdiquement les magazines A5 (essayez un A4 et un A5, du même.. et pleurez) , les relecteurs disparaissent et on veut même supprimer la complexité (qui gère la complexité des taches à accomplir) des logiciels. Ensuite il ne restera qu'un demi logiciel merdique que tout le monde comprendra et qui fabriquera des documents merdiques en distribuant au hasard les espaces blancs entre les mots et les paragraphes.
Tout fout le camp…. mais sérieux, j'ai les boules. Il ne faut pas croire lorsque les gens n'acceptent plus de passer du temps à apprendre des trucs, ils deviennent incapable d'acquérir des compétences. Il ne faut pas réver : soit tu sais comment faire, soit tu es tributaire de quelqu'un pour le faire et qui a décidé que tu avais le droit de le faire. Je préfère de loin la complexité d'un latex qui me permet _ si je veux y passer du temps_ de jouer sur l'espacement des lettres dans les mots plutôt que la simplicité d'un wordpad qui, il y a encore quelque temps, était incapable de lire un simple document texte en utf8, parce que ça servait à rien !!!
[^] # Re: Langage
Posté par jbbourgoin (site web personnel) . Évalué à 3.
Tout à fait d'accord.
LaTeX est un logiciel complexe car il fait des choses complexes, et ce depuis longtemps (donc beaucoup de paquets redondants etc.).
C'est assez facile de dire : il faut faire un truc plus simple qui fait la même chose.
Généralement ça se traduit par :
1) On fait un logiciel certes plus simple, mais qui ne fait qu'une toute partie de LaTeX (la seule qui nous intéressait).
2) Généralement, le logiciel grossit à mesure que les complexités, les bugs, les envies et les demandes grandissent.
3) Au final, on aboutit à un logiciel qui n'est plus très simple, potentiellement bugué, et qui reste infiniment inférieur en tout point à l'original.
4) Si on persévère, on atteint le stade de la grosses machine (à la LaTeX) qui fait (si on a de la chance, et la compétence), un aussi bon travail, et qui est aussi à peu près aussi complexe (peut-être un peu moins si on a de la chance).
Pour se rendre compte qu'il manque encore de la documentation et des utilisateurs (pour les paquets additionnels) qui sont pour la plupart … encore sous LaTeX, qui leur permet de faire ce qu'ils veulent en 10 minutes en cherchant un tuto et un paquet tout prêts.
Au final, beaucoup de temps perdu.
Car franchement, LaTeX est un outil puissant et génial, dans sa catégorie. On perdra moins de temps à essayer de le comprendre qu'à chercher désespérément son remplaçant, et à l'apprendre quand on l'aura trouvé.
Alors, après, il y a toujours le plaisir d'écrire un nouveau logiciel. Mais ça c'est autre chose.
[^] # Re: Langage
Posté par Perthmâd (site web personnel) . Évalué à 8.
Avec de tels principes, les langages de programmation en seraient restés au COBOL…
Non, je suis désolé, mais TeX est un logiciel des années 70, et on le sent bien. Depuis on a fait des progrès dans la conception des langages de programmation, et des limitations arbitraires comme le fait de ne pouvoir avoir qu'au plus 256 variables font franchement préhistoriques.
[^] # Re: Langage
Posté par Maclag . Évalué à 7.
Moi ce que je reprocherais à LaTeX, c'est son manque de gouvernance globale.
Il existe une chiadée d'extensions pour faire tout et n'importe quoi, beaucoup sont redondantes, beaucoup sont incompatibles les-unes avec les-autres, le seul moyen de s'en rendre compte, c'est parfois de s'escrimer avec pendant des heures/des jours à se demander si on a les bonnes versions de tout ce bordel avant de tomber sur une réponse miraculeuse d'un mec qui a trouvé que mettre le module 14 et le module 26 ensemble, ben ça marche pas.
J'aimerais voir un truc un peu organisé et évolutif:
Pour chaque fonction supplémentaire, un comité choisit une extension officielle, et elle devient extension officielle de LaTeX. Le comité s'assure que les extensions officielles sont maintenues et ne fournissent pas de fonctions inutilement redondantes ni incompatibles les-unes avec les-autres.
Ceci permettrait également d'avoir une documentation plus cohérente, au lieu de chercher une liste de solutions pour faire certaines choses, se retrouver avec 3 ou 4 propositions, et les tester une à la fois:
On pourrait enfin avoir un vrai dépôt central qui inclura une documentation prenant en compte une liste définie d'extensions (les extensions officielles).
Je suis personnellement utilisateur occasionnel de LaTeX. Je ne l'utilise que pour les gros documents. Pour les petits, j'ai abandonné depuis longtemps: je passe bien trop de temps à bidouiller au milieu de la foire d'extensions et de fonctions que je ne passe à faire la même chose avec un éditeur WYSIWIG.
De fait, je n'ai jamais utilisé LaTeX pour une présentation. Dans mon secteur, il y a beaucoup de schémas, d'import de photos, et/ou de petites animations. Pas le temps de comprendre à chaque fois quel module rajouter pour faire "ça" en plus sans péter le reste. (C'est peut-être pas comme ça pour les présentations, mais ça l'est pour les rapports, alors je ne m'y suis pas aventuré).
[^] # Re: Langage
Posté par Anonyme . Évalué à -1.
C'est un avantage, il ne faut rien modifier car le rendu est toujours excellent. Et si tu veux modifier un petit detail c'est que tu n'as pas besoin de le modifier.
regarde sous word, tu peux tous changer, meme les petit details :)
Dans un rapport avec plein d'image de 100 pages, latex ne voulait jamais mettre les images ou je voulais qu'elle soient, et c'est très difficile a faire pour les flottant :). A force j'ai accepter que latex me mette les image ou il veut, finalement c'est vraiment mieux structuré ainsi. Et plus agréable a lire.
pour les truc cosmétique c'est mieux de ne rien faire, Je reconnais que si le style est imposé par une université c'est impossible a suivre avec latex a cause de son langage de prog, c'est le seul cas bloquant.
[^] # Re: Langage
Posté par Maclag . Évalué à 4.
Je tempérerais ça un peu: j'ai souvent eu à "forcer" le placement d'images (on ne peut pas l'imposer, mais seulement pousser très fort) parce que j'ai personnellement toujours détesté lire un document où "cf figure 12" te demande de tourner 3 pages en avant pour voir la figure.
C'est même un de mes critères de choix pour les lecteurs PDF: pouvoir ouvrir deux fois le même document dans 2 instances avec deux pages différentes en vis-à-vis, pour avoir la figure référencée sous le nez pendant que je lis le texte associé.
(Tiens, ça me fait penser que je devrais suggérer ça en nouvelle fonctionnalité: une fenêtre ou un encart avec la/les dernières figures référencées)
Acrobat Reader ne m'a jamais laissé faire ça!
[^] # Re: Langage
Posté par arnaudus . Évalué à 10.
C'est faux, et c'est même un problème. Par exemple, le traitement par défaut des overfull box est catastrophique : Latex ne fait rien, ce qui génère un rendu dégueu. Certes, avec des Warnings, mais ce n'est pas ce que j'attends d'un traitement de texte : je veux les warnings ET le meilleur rendu possible étant donné la situation.
Concrètement, quand Latex n'arrive pas à faire une césure, il fait dépasser le texte dans la marge de droite, ce qui est la pire des solutions : le rendu avec l'option \sloppy est bien moins désagraéable.
Un autre exemple évident est l'alignement des figures à gauche. Pourquoi pas, mais quand la figure est plus large que la zone de texte, Latex la fait dépasser sur la marge de droite, voire tronque la figure quand elle est trop large pour la page, ce qui encore est visuellement choquant. Il faut manuellement inclure les figures et tableaux dans des mbox centrées pour obtenir un rendu acceptable (figure centrée par rapport à la zone de texte).
Par défaut, Latex n'évite pas les veuves et les orphelines, ce qui est aussi considéré comme une bonne pratique en typographie.
Par défaut, la taille et la police des légendes des figures est identique au texte, ce qui pose des problèmes de lecture quand les figures sont insérées en haut de page, ou quand les légendes sont importantes.
Par défaut, avec l'option frencb, Latex insère des espaces insécables avant les doubles ponctuations, mais ces espaces ne sont pas fines.
J'aurais plein d'exemples comme ça : Latex a une certaine flexibilité, mais les options par défaut ne sont pas nécessairement bien choisies, et certains comportements sont extrêmement déroutants. Le terminal est floodé par des underful et des overful boxes, et Latex choisit parfois la pire des options quand il n'arrive pas à rendre les choses correctement. Bref, c'est faux de dire que le rendu par défaut est parfait : pour avoir un rendu typographiquement très bon, il faut régler un grand nombre de détails à la main.
Ouais, tu sais mieux que l'utilisateur ce qu'il souhaite. "It's not a bug, it's a feature".
Si tu dois te corformer à un style particulier (soumission à une revue scientifique, typiquement), alors tu dois gérer tout plein de petits détails idiots : changer la numérotation, mettre des titres en italique, etc.
Si tu dois fournir un nombre de pages précis, tu vas devoir gérer la taille des marges, des interlignes, etc.
Si tu dois produire un document professionnel, tu peux vouloir coller au style de document que tes collègues créent à partir de Word, quitte à reproduire des petites imperfections typographiques.
Pas d'accord, Latex insiste souvent pour privilégier le rendu (équilibre texte/figures) au confort de lecture. En pratique, Latex n'anticipe jamais l'insertion des figures, alors que la logique veut dans beaucoup de cas que la figure soit affichée sur la même page (ou la même double page dans un livre) que le texte où elle est appelée, afin de ne pas devoir feuilleter le document pour comparer cette figure au texte correspondant. Latex ne sait pas prendre ça en compte, et je trouve ça super lourd.
En bref, tu sembles croire que les règles typographiques sont uniques, universelles, et fixes. Tu sembles aussi croire que les règles implémentées dans Latex sont consensuelles. Les deux idées sont fausses.
[^] # Re: Langage
Posté par gouttegd (site web personnel) . Évalué à 3.
Je suis d’accord, mais au moins il est possible de les régler à la main, ce qui n’est pas le cas en HTML5 où l’auteur n’a aucun contrôle fin sur le rendu (comment le pourrait-il, vu que le rendu est effectué sur des machines dont il ignore tout ?).
L’EPUB est une catastrophe typographique : je vois des monstruosités (genre une ligne ne contenant que deux mots aux extrêmités, séparés par un énorme blanc au milieu…) sur quasiment toutes les pages que je lis. Il arrive à LaTeX de produire des horreurs, mais au moins on peut agir au cas par cas pour les corriger.
On a d’un côté un système où le rendu est fait une fois pour toutes sur la machine de l’auteur (qui peut éventuellement le perfectionner autant qu’il le souhaite), de l’autre un système où tout le rendu est fait à chaque lecture sur la machine du lecteur, dans des conditions potentiellement très différentes (écran de 22”, tablette de 10”, smartphone de 5”, liseuse numérique…) et sans possibilité de correction.
En gros, on a soit un rendu de qualité dans un format figé, soit un rendu médiocre dans un format flexible. Du coup je ne suis pas sûr que comparer les deux, en voulant faire sortir l’un comme « supérieur » à l’autre, soit pertinent.
[^] # Re: Langage
Posté par arnaudus . Évalué à 6.
Mais oui, je suis personnellement convaincu que Latex est le meilleur logiciel de traitement de texte disponible pour le public! Seulement, je trouve qu'il est engoncé dans des archaïsmes techniques et qu'il souffre de nombreux problèmes. En gros, c'est un logiciel qui est (à peine) maintenu au lieu d'être activement développé autour de concepts de programmation et d'interface modernes : les seules évolutions de Latex depuis des décennies (en exagérant à peine) sont la publication de nouveaux paquets indépendants.
On peut avoir deux réactions : se voiler la face et dire 1) qu'avec un peu d'efforts et en RTFM, on peut apprendre les bugs du langage pour pouvoir l'exploiter (ce qui est toujours vrai), que 2) de toutes manières, il n'existe pas de logiciels équivalents et que Latex n'a pas besoin s'évoluer, et que 3) ce n'est pas des bugs, c'est des fonctionnalités.
Y'a pas à dire, les fichiers graphiques qui n'ont pas le droit de contenir de points dans leurs noms, c'est de la fonctionnalité. Les paramètres optionnels entre crochets et les paramètres obligatoires entre accolades, c'est de l'interface ergonomique. L'existence de multiples extensions, parfois maintenues, parfois non, qui font la même chose indispensable avec des interfaces indépendantes, c'est un service rendu aux utilisateurs.
Mais personnellement, ça me gonfle de voir tant de gens a priori raisonnables devenir complètement aveugles et obtus quand on leur parle des défauts d'un logiciel libre. Ça peut aller jusqu'à balancer des mensonges grossiers, tels que "le rendu est parfait par défaut". Je ne vois pas l'intérêt de se voiler la face : Latex est un logiciel qui fait très bien ce qu'il fait depuis 30 ans ; et la version actuelle fait très bien ses 19 ans. 19 ans! Même des langages comme C ou C++ évoluent un ordre de grandeur plus vite que Latex!
Si l'objectif est de se palucher entre geeks autour d'une sorte de Brainfuck ésotérique, alors oui, Latex c'est super. Mais croire que pour avoir un rendu de qualité, il est nécessaire de pleurer sa mère pendant des jours entiers pour éditer un fichier de style, c'est de la superstition.
[^] # Re: Langage
Posté par gouttegd (site web personnel) . Évalué à 4.
Bah moi, ma réaction c’est plutôt : OK, ce n’est pas parfait et ça accuse son âge, mais pour l’instant c’est ce que j’ai de mieux et ça marche (encore ?), donc je m’en contente, et je ne vais surtout pas me jeter sur la dernière technologie à la mode (hier XML, aujourd’hui les « langages de balisage léger » comme Markdown ou reStructuredText, demain ce sera quoi ?) qui ne fait pas le dixième de ce dont j’ai besoin.
[^] # Re: Langage
Posté par Diagonale de Cantor (site web personnel) . Évalué à 4.
Tu n'as pas compris le but de l'EPUB. L'EPUB n'est pas censé s'occuper de typographie ; la liseuse par contre oui.
Si les liseuses propose une typographie moins bonne que celle offerte pas TeX, c'est un problème de liseuse pas d'EPUB. Le problème de TeX, c'est que ça mélange le fond et la forme. Si on écrit en TeX, on ne peut générer qu'un pdf (par défaut). Or ce qu'il faut c'est un langage pour décrire le contenu du fichier (et epub n'est pas trop mal) et après on peut visualiser le résultat, soit en passant par un pdf via TeX, soit par une liseuse, etc. Docbook doit correspondre à cela si je ne dit pas de bêtise.
La description du fichier et la mise en page sont deux problèmes distincts et même si TeX et génial, la séparation fond/forme n'est pas parfaite. Le problème de TeX, c'est qu'on y fait des maths, des figures ou des macros (et il déchire dans les trois) on ne plus plus convertir le ficher proprement dans d'autre format.
Pour quelqu'un qui ne fait pas de math ni de figures, TeX, c'est le mal. Il vaut mieux utiliser un autre format plus simple (markdown, orgmode, html) et à la rigueur le convertir après en PDF via TeX (et faire les fignolages typographiques à la main).
Tu va me dire que EPUB ce n'est pas non plus parfait, et effectivement je conchie tout ces abrutis qui se disent « tiens, ça pourrait être sympa de mettre une css à notre EPUB* » ou pire du javascript. Mais tant que c'est une simple description du contenu, c'est génial. Et j'abandonne avec joie la typographie de TeX, pour le plaisir de zoomer (les gros caractères, quand tu fatigues c'est génial), on peut pas zoomer facilement un pdf (ou a lors la navigation devient horrible sur liseuse).
(*) j'en ai pas vu beaucoup qui était réussie, et les rares qui était pas mal était totalement inutile (un titre encadré, wahou…).
[^] # Re: Langage
Posté par lasher . Évalué à 2.
Tu veux dire, comme le format DVI (Device Independent), qui en fait est le vrai format par défaut de (La)TeX ?
[^] # Re: Langage
Posté par Diagonale de Cantor (site web personnel) . Évalué à 4.
J'ai pas voulu jouer au puriste, j'aurais pu dire dvi, ps et pdf et avec pandoc on peut aussi générer du html, de l'epub. Sauf qu'en fait on s'en fout. Tex est pensé pour définir l'affichage eu pixel prêt et à cause de ça, le fond et la forme ne seront jamais vraiment séparé en TeX. Quiconque à écrit un article en TeX qui doit tenir en X pages, sait que l'on joue avec les \vspace{-0.5cm} et \hspace{-0.5cm} pour que ça tienne. C'est vrai que par rapport à Word, le fond et la forme sont beaucoup plus séparé (d'un côté cela aurait été un exploit de faire pire) et qu'en général on ne se soucie de la forme que dans le fignolage final. N'empêche que l'on est obligé de s'en soucier !
Par défaut les gens devrait écrire dans des formats comme html ou epub sans se soucier de la mise en page. On échange des documents pour échanger du contenu, pas des œuvres d'arts typographiques. Après c'est au lecteur (liseuse, firefox ou autre) de s'occuper de typo.
[^] # Re: Langage
Posté par lasher . Évalué à 4.
Oui. Maintenant, explique-moi comment tu fais avec un quelconque autre outil (y compris word/writer) pour faire tenir ton document en x pages sans passer par des « artifices » équivalents — et donc de façon automatique, je suppose. Ça m'intéresse.
[^] # Re: Langage
Posté par Diagonale de Cantor (site web personnel) . Évalué à 5.
Soyons clair : TeX est un logiciel de mise en page qui est génial et qui est le meilleur que je connaisse. J'adore TeX, mais depuis que j'ai une liseuse j'ai compris que TeX à un problème. C'est un logiciel de mise en page et la question est « est-ce vraiment nécessaire de faire de la mise en page » ? Moi je pense qu'on devrait s'en foutre.
Pour écrire un document, on écrit du contenu. La mise en page on la laisse au logiciel de lecture. Et si on veut quand même limiter la page des papiers, il suffit de demander de ne pas dépasser 10 000 caractères par exemple. Ça évite de rendre les figures toutes petites, les algo avec des polices riquiquis et de jouer avec les « vspace » et de ne concentrer que sur le contenu.
Aujourd'hui à l'heure des liseuses, tablette, et ordiphone, à l'heure de wikipedia et du web est-ce vraiment pertinant de penser « format a4 » ?
[^] # Re: Langage
Posté par lasher . Évalué à 1.
Je suis biaisé, mais dans mon domaine (recherche en info), oui. L'exercice qui consiste a expliquer sa recherche en 4, 8, 10, 12, ou 25 pages (ou 6000 mots, etc.) est important, car il force le ou les auteurs à rester suffisamment concis. Ensuite en tant que reviewer, je suis plutôt content lorsque les papiers que je relis font (en moyenne) 10-12 pages : c'est déjà parfois assez compliqué, si en plus tu laisses les auteurs décider de la longueur de leur bidule, je vais passer mon temps à relire les articles des autres…
[^] # Re: Langage
Posté par Diagonale de Cantor (site web personnel) . Évalué à 4.
Je suis aussi dans la recherche en info :)
Je suis d'accord avec toi sur l'importance de limiter la taille. C'est le fait de penser en nombre de page que je trouve stupide. Si tu relis mon message, je propose de limiter le nombre de caractères (le nombre de mot serait peut-être effectivement plus pertinent).
De toute façons, TeX étant un standard de facto dons notre discipline, autant penser en nombre de page comme TeX l'encourage (vu que TeX crée explicitement des pages). Mais le jour où on aura un langage de description aussi puissant que TeX qui permettra de ne pas se soucier de la mise en page, alors ce jours là il faudra abandonner TeX pour ce nouveau langage.
[^] # Re: Langage
Posté par lasher . Évalué à 1.
Boarf, tu peux toujours donner des dimensions « infinies » de la page à TeX non ? :-P Du coup TOUT tiendrait sur la même page virtuelle (certes, les marges gauche-droite seraient toujours à redéfinir, mais c'est un moindre mal).
[^] # Re: Langage
Posté par Diagonale de Cantor (site web personnel) . Évalué à 5.
Le problème n'est justement pas la longeur mais la largeur.
Par exemple j'avais générer des pdf pour ma liseuse, avec la bonne taille de police, des lettrines, une jolie police, les ligatures jolie comme tout (ff, st…).
Mais il y a deux problèmes.
— Ça donne des fichiers affreusement lourd à charger et une liseuse c'est par un supercalculateur. En terme de légéreté, l'epub est bien mieux que le pdf. De plus une liseuse c'est un petit écran où il faut des gros caractère: donc une page a4 avec police taille 10, ça devient rapidement 10 pages en formats liseuse. Un simple livre papier de 120 pages (un petit roman) ça va donner facilement 300 pages pour être adapté à la liseuse. Et un fichier pdf de 300 pages c'est affreusement lourds !
— Si tu veux zommer tu as les marges plus grosse que l'écran et ça devient une horreur à lire. Et quand tu as les yeux qui fatigue, zoomer, c'est vraiment génial. D'ailleurs les beau livres ont souvent des grosses polices parce que typographiquement c'est beaucoup plus agrèable à lire.
Le pdf (et donc TeX) n'est pas adpaté à partir du moment où tu ne connait pas la taille de l'écran pas défaut ou à partir du moment où tu veux zommer (bon tu vas dire que j'ai vu des chercheur imprimer sur A5, ça marche aussi ). C'est un problème fondamentale de TeX, parce que c'est un logiciel de mise en page et non pas un format d'échange de document.
[^] # Re: Langage
Posté par fmaz fmaz . Évalué à 0.
Quand j'écris un article, je ne joue JAMAIS avec les \vspace et autre \kern.
D'ailleurs, pour soumettre un article à un conf, je pense que la bonne démarche est de fournir une classe bien faite et d'interdire
\usepackage
\def
\newcommand
\renewcommand
\hspace
\vspace
\kern
\enlargethispage
et autre joyeusetée de ce genre.
En plus, c'est super facile. Un bête grep et on refuse la soumission.
[^] # Re: Langage
Posté par Diagonale de Cantor (site web personnel) . Évalué à 6.
Comme ça tu ne peux pas utiliser pgf/tkz algorithmicx subfigure
De plus pour éviter de polluer mon .tex, tous les classes que j'utilise et mes macros sont dans un style.sty que j'utilise avec \usepackage{style}
La force de TeX ces tous ces packages. Si tu commence à tous supprimer, tu enlèves une des raisons du succès et de l'intérêt de TeX.
À partir du moment où \usepackage est indispensable, il te suffit d'écrire ton propre paquet (trivial).
Euh, toutes les soumissions que j'ai faîtes consistais a simplement donner le pdf. De plus avant de poser plein de règles qui font chier le monde il faut se poser la question ; est-ce qu'il y a de l'abus ? Un document qui est dégueulasse de fera de toutes façons jeter par le relecteur. Tant que c'est fait avec parcimonie il n'y a pas de soucis.
LaTeX fait un bon document par défaut, mais de toutes façons t'es obligé de repasser derrière pour avoir un document vraiment propre. Par exemple lorsque la dernière ligne d'une section se trouve orpheline page suivante. C'est typographiquement une hérésie et tu perds beaucoup de place (car la nouvelle section rajoute un espace entre elle et le paragraphe précédent). Si faire un vspace{-1pt} permet de résoudre le problème tu n'a aucune raison de t'en priver et ce serai moche de ne pas le faire. C'est à faire au cas par cas et faut juste vérifier que le résultat reste propre.
[^] # Re: Langage
Posté par fmaz fmaz . Évalué à 1.
Quand je dis que la classe doit être bien faite, je dis que c'est à elle d'inclure les paquets utiles. Donc si la conf ne veut pas de figure, ben non, pas de pfg. Si elle ne veut pas d'algorithmes, pas de paquets pour ça…
Au hasard, un 'grep RequirePackage' sur le style d'une conf me donne:
La force de LaTeX, c'est la cohérence visuelle. Donc pour les proceedings, il FAUT que tous les papiers utilisent les même réglages. De mon côté, justement pour les proceedings, j'ai toujours aussi envoyé les sources. Et les journaux, notamment Elsevier (et arxiv qui n'est pas vraiment un journal), il faut aussi les sources.
Après, les histoires d'orphelines, ce n'est pas TON boulot, c'est celui de l'éditeur. Après, si pour la soumission, ça te fait perdre une ligne bêtement, ben reformule ta phrase.
[^] # Re: Langage
Posté par Diagonale de Cantor (site web personnel) . Évalué à 5.
Et voilà ! Il manque pgf/tikz qui est la référence pour faire des figures… Donc avec cet approche tu ennuies le monde pour résoudre un problème qui n'existe pas.
Sérieusement l'éditeur modifie ton .tex ? On parle bien du monde de l'édition scientifique ? Ceux qui ne serve à rien ? Ceux te laisse faire l'écriture, la mise en page, les reviews et qui te font payer deux fois : lors de la publication et pour ensuite récupérer ton fichier sur lequelle tu n'as plus aucun droit ?
En fait pour certains journaux ils servirait à quelque-chose ? Si c'est le cas tu me l'apprend :)
[^] # Re: Langage
Posté par nonas . Évalué à 2.
Dans ce cas là, je compile mes figures en local et je leur envoie un pdf ou un eps par figure. Ça soulage aussi à la compilation pour de gros documents de ne pas avoir à réinterpréter une figure ou un schéma qui ne change pas souvent.
Certains éditeurs font les choses assez bien (par exemple AIP avec le paquet RevTEX).
[^] # Re: Langage
Posté par gouttegd (site web personnel) . Évalué à 3.
Je suis d’accord. Mais j’attends toujours de voir une liseuse ou un navigateur web avec un rendu typographique correct, donc pour l’instant le rendu médiocre est pour moi inhérent à HTML/EPUB.
Ah, l’arlésienne du format d’entrée unique pour de multiples formats de sortie ! J’y ai cru, à une époque. J’en suis revenu. Pour moi c’est une illusion. Avec un format d’entrée unique totalement indépendant de la sortie, on ne peut pas tenir compte des spécificités de chaque type de sortie (on ne lit pas un document sur une page HTML comme on lit un document imprimé), et le résultat est au mieux passable (surtout pour la sortie imprimée).
En théorie seulement. En pratique… J’ai essayé d’écrire ma thèse en DocBook. Outre le fait que les outils sont, à mon sens, loin derrière les outils disponibles pour LaTeX, DocBook lui-même souffre de plusieurs défauts rédhibitoires. La gestion des références bibliographiques, notamment, met justement à mal le principe de séparation du fond et de la forme supposé être le point fort de DocBook, vu que le seul moyen d’obtenir le formatage souhaité des références en sortie est de… formater directement les référence dans la base de données bibliographiques au départ (ce que DocBook appelle des « références cuites »).
C’est justement DocBook qui a enterré mes illusions d’un format source unique pour des formats de sortie multiples.
[^] # Re: Langage
Posté par Diagonale de Cantor (site web personnel) . Évalué à 3.
Ayant une liseuse, je dois reconnaître que je trouve bien plus agréable de lire sur liseuse que sur papier. La typographie n'est pas un but, mais un outils pour rendre la lecture plus confortable, moins fatigante et plus rapide. Et entre un document TeX lu sur papier et le même texte lu sur liseuse, y'a pas photo, le rendu de la liseuse est parfait 95% du temps, et les 5% restant ne suffisent pas à annuler les bénéfice que l'on a grâce au gros caractère. J'imprime parfois des texte fait avec latex pour les lire et le confort (qui est l'objectif de la typo) ne vaut pas celui de la liseuse (ou au pire est comparable).
Par contre, les navigateur c'est de la merde, et je trouve les logiciels de lecture epub sur ordi vraiment moche ! Là on est d'accords.
Ça marche tant que tu ne cherche pas à imprimer et que tu n'utilises rien de compliquer (du texte avec des titres). Si tu veux faire de la mise en page il faut un logiciel de mise en page (bonjour TeX), mais la mise en page n'est pas nécessaire la majorité du temps. Par exemple pour les journaux, les blogs, la documentation, les courriers…
C'est ça l'erreur. Tu d'occupes de la forme ! Ce qui est pour l'instant nécessaire dans une thèse, je te l'accorde : donc docbook est pourri pour rédiger sa thèse.
En fait soit tu as un truc non portable et super bien présenté : TeX, soit tu as quelque chose de portable mais moins bien affiché (car il y aura plusieurs périphériques d'affichage différent). Tu ne peux pas avoir les deux et je pense que la probabilité est plus importante que la perfection typographique.
[^] # Re: Langage
Posté par gouttegd (site web personnel) . Évalué à 1. Dernière modification le 23 octobre 2013 à 20:05.
Ayant une liseuse, j’ai une opinion radicalement opposée. J’apprécie ma liseuse pour le fait de pouvoir transporter une bibliothèque dans 500 grammes, mais niveau confort de lecture, je pleure, et pas seulement à cause de la typographie.
Ah ouais, je vois. Pas étonnant que ça ne marche pas pour moi, alors.
Excuse-moi d’avoir envie que mes références ressemblent à autre chose qu’à ça :
et de préférer quelque chose comme ça :
LaTeX me permet précisément de ne pas me soucier du formatage des références au moment où je remplis ma base de données bibliographiques, DocBook me contraint à le faire si je veux que la référence soit un minimum lisible.
Je n’ai pas dit autre chose (sauf que je n’ai pas parlé de « portabilité » qui n’est à mon sens pas approprié ici — un PDF est en principe portable, sauf si on utilise les conneries propres à Adobe Reader —, mais plutôt de « flexibilité »).
Je ne réclame pas la perfection typographique, mais quelque chose de correct et agréable à lire, ce que je n’ai pas avec de l’HTML5 ou de l’EPUB.
Mais je pense que nous n’écrivons pas les mêmes documents et que nous n’avons pas les mêmes besoins. Si un rendu HTML5 (écrit à la main ou généré à partir de markdown ou assimilé) te suffit, je n’ai rien à y redire. Merci seulement de ne pas généraliser ou pensant que ça doit suffire à tout le monde — de mon côté je m’efforcerai de ne pas généraliser en pensant que tout le monde a besoin de ce qu’offre LaTeX. ;)
[^] # Re: Langage
Posté par Diagonale de Cantor (site web personnel) . Évalué à 3.
Je suis un utilisateur régulier de LaTeX. Mais si je veux pouvoir lire un texte de manière flexible, force est de constaté que LaTeX c'est tout pourrie (et on ne pourra jamais résoudre ce problème), alors que l'epub ou l'html marche bien et pourront être amélioré. Maintenant je parle de document que je lis sur liseuse ou navigateur. Quand mes documents doivent être imprimés sur des pages, alors là, oui, il faut une mise en page soignée et là j'utilise LaTeX. Ma question est-ce important d'avoir des documents mise en pages en générale ?
J'aime lire mon journal sur ma liseuse, des romans, à la rigueur des long post de blog et je ne sent pas un manque typographique qui me forcerait à passer à papier+TeX.
Avec les journaux et les romans ça fait pas mal de lecture déjà. Pour la doc et les encyclopédies l'html marche bien. Donc à part ceux qui à vocation d'être imprimé je ne vois pas l'intérêt de TeX. Surtout que le html simplifie tout : vue que tu n'a pas de page le placement des figures devient trivials. Ma question est « est-ce que ce sera longtemps pertinent de faire des articles scientifique et des thèses pour les imprimer ?»
Tu as quoi comme modèle si ce n'est pas indiscret ? J'ai une Bookeen Odyssey HD frontlight et je n'ai pas à m'en plaindre (du moment que je lis des romans ou des document dont la navigation consiste à tourner la page). Le fait de pouvoir l'allumer (lumière indirect) compense le faible contraste (qui supporte mal un faible éclairage). Et la typographie est très potable (c'est largement mieux qu'un document word ou qu'une page web). Il y a une jolie police, des césure et des ligutures et le rendu me semble bien.
Si docbook ne permet pas d'afficher une bibliographie correctement c'est un bug de docbook, mais à priori ce n'est pas un problème fondamentale de l'approche.
J'ai jamais dis ça ! Je pense juste que vue qu'on lit de plus en plus sur écran, TeX aura de moins en moins d'importance et je recevrai de pouvoir lire des article avec formule de math sur liseuse. À l'origine le débat c'était "Tex bien et epub pas bien" ce à quoi je répondais que
1. epub est un format d'échange et ne se soucie pas de l'affichage (donc la comparaison est foireuse)
2. Les logicels d'affichages ne peuvent que s’améliorer (et sont suffisant aujourd'hui pour des textes simples) alors que la flexibilité futur de TeX est illusoire.
3. Utiliser un logiciel de mise en page (TeX) pour quelque chose qui n'a pas besoin de mise en pages est inutilement contraignant et est une mauvaise pratique àmho (même si c'est plus beau à l'impression)
4 Maintenant si t'a besoin d'une mise en page soigné, LaTeX roxe du Poney !
[^] # Re: Langage
Posté par gouttegd (site web personnel) . Évalué à 1. Dernière modification le 23 octobre 2013 à 22:35.
Oui. Nul besoin de « perfection typographique », mais une mise en page « correcte » est très importante pour moi, a fortiori pour des romans que je lis pour le plaisir (à la limite, pour un document technique que je lis dans le cadre de mon travail, je veux bien faire un effort, après tout je suis payé).
Mais même pour des romans les ebooks ne me conviennent pas. J’ai au moins trois problèmes avec eux :
① La mauvaise typographie à la source : j’entends par là, les erreurs de typographie qui ne dépendent pas de l’appareil (ou du logiciel) de lecture mais qui ont été faite directement dans le code source même du livre. Par exemple : utilisation de pseudo-guillemets droits ("), dialogues marqués par des traits d’union (-), deux points au lieu d’un seul à la fin d’une phrase (devinette pour le lecteur : y a-t-il un point en trop ou un point en moins), absence d’espace entre un point et la phrase suivante… Rien de bien dramatique certes, mais ça me fait tiquer, d’une part parce que je suis un typonazi, d’autre part parce que cela révèle le peu d’attention que l’éditeur a accordé à la version électronique (un éditeur digne de ce nom de laisserait jamais passer ce genre de choses pour une édition imprimée).
② La mauvaise typographie au rendu : les erreurs de typographie ou mise en page inputables à la liseuse ou au logiciel de lecture. Par exemple : énormes blancs inter-mots, titre de chapitre sur deux « pages », lignes veuves, etc.
③ Ma liseuse n’est pas pratique. Je n’ai rien à redire sur le confort visuel (c’était au départ le point sur lequel j’étais le plus sceptique, et j’ai été agréablement surpris de ce côté-là : une page d’encre électronique est aussi agréable à lire à mes yeux qu’une page imprimée), mais la seule « navigation » supportée est de tourner une page à la fois, dans un sens ou dans l’autre. Or même pour un roman, j’aime bien pouvoir faire plus : par exemple, retourner trente pages avant pour revérifier un truc (« attends une seconde, il avait pas dit qu’il était avec sa maîtresse, le soir du meurtre ? »), reprendre les cinq dernières pages parce que j’ai été distrait au cours des deux dernières minutes, feuilleter quelques pages en avant pour voir où se trouve la fin du chapitre et décider si j’arrête maintenant ou si je termine le chapitre, etc. Autant de choses qui sont parfaitement naturelles et évidentes avec un livre papier, et chiantes au possible avec ma liseuse (j’espère sincèrement qu’il y en a de meilleures sur ce point).
Alors, certes, le premier problème est de la faute de l’éditeur, le second et le troisième la faute de l’appareil de lecture, aucun de ces problèmes n’est imputable au format EPUB lui-même (encore que le choix de HTML5 est à mon sens directement responsable du second problème) et aucun de ces problèmes n’est insoluble (encore que j’ai des doutes sur la volonté des éditeurs et des constructeurs de liseuses d’améliorer les choses, surtout si tout le monde se contente de peu).
Il n’empêche, le résultat pour moi est que je conchie EPUB et les livres électroniques (romans ou techniques — c’est encore pire pour les documents techniques, même si comme dit plus haut je suis moins exigeant dans ce cas-là), et le fait qu’EPUB n’y soit pour rien me fait une belle jambe. J’apprécie le côté « votre bibliothèque dans votre poche », mais c’est bien le seul avantage que je peux leur trouver par rapport à des livres imprimés.
Une Kobo. À éviter.
Donc elle ne fait pas mieux que la mienne, apparemment.
En effet, et j’espère d’ailleurs que les outils associés à DocBook se sont améliorés depuis. Mais tu comprendras que je préfère de vieux outils qui marchent avec une approche des années 80 à de nouveaux outils modernes qui ne marchent pas ou ne font pas ce dont j’ai besoin (parmi les langages de balisage léger à la mode, combien prennent en charge la gestion des références ?).
Mais l’approche du document source unique a d’autres problèmes. Que fait-on des notes de bas de page, par exemple ? Rien que le fait de parler de « notes de bas de page » trahit le fait qu’on ne s’affranchit pas totalement du format de sortie, puisque la notion de « note de bas de page » n’a rien à faire dans un document électronique ! La plupart du temps, les notes de bas de page sont traduites, dans une version électronique, par des notes de fin d’ouvrage (ou, dans le meilleur des cas, des notes de fin de chapitre). C’est la pire solution, vu qu’elle oblige à se déplacer à la fin du livre (ou du chapitre) pour lire la note, puis à revenir au point d’appel. C’est à la limite tolérable sur un navigateur web, où il y a en général des liens cliquables pour se déplacer aisément, mais sur une liseuse où la navigation est merdique™, c’est horrible. Une meilleure approche serait d’afficher les notes au bord de l’écran (nos écrans sont assez larges aujourd’hui…), au survol du pointeur (on sait faire suffisamment de trucs inutiles en Javascript, pour une fois qu’on ferait quelque chose de pratique…), ou, sur une liseuse, dans un cadre en bas de la « page » courante. Bref, il y a moyen de faire des choses plus intelligentes que de transposer bêtement les notions du format papier au format électronique, à condition d’accepter que le format imprimé et le format électronique sont différents et que vouloir les traiter de la même façon conduit à nier les spécificités de chacun.
Ah ben oui, vu qu’on ne se casse plus la tête : on met la figure n’importe où, au lecteur de se débrouiller avec. Pour lui, ce n’est ni mieux ni pire que les articles figés au format PDF ou imprimés. Sur un papier PDF, si une figure en page 2 est citée en page 4, je dois retourner à la page 2 pour la voir. Sur un article électronique, si une figure au début du papier est citée à la fin, je dois remonter pour la voir. Grande différence. Certes, avec un navigateur, je peux ouvrir la figure dans une autre fenêtre et revenir au texte, et ainsi avoir la figure en face du texte, mais je peux faire la même chose dans mon lecteur PDF (ou même avec une version imprimée, il me suffit de placer la page 2 à côté de la page 4 sur mon bureau). L’électronique ne change rien du tout ici, ses possibilités ne sont pas du tout exploitées.
Tant que les versions électroniques seront aussi peu pratiques (parce qu’elles ne seront que des versions électronalisées du papier), oui.
Moi je pense que l’EPUB est un format final dédié à l’affichage sur média électronique, de même que le PDF est un format final pour l’impression (même si dans les faits il est de plus en plus rare qu’on imprime du PDF, on les lit aussi sur média électronique).
Pour moi, un format d’échange, c’est plutôt le format à partir duquel on a généré le EPUB, que ce soit du DocBook ou un autre type de balisage sémantique dans lequel la forme est vraiment complètement absente (on notera qu’un code source LaTeX ne répond pas mieux à cette définition qu’un EPUB).
Nos avis divergent sur le besoin de mise en page. Pour moi il y a une règle simple : s’il y a une chance que ça soit imprimé, ça doit être mis en page — correctement. Après si ça doit rester purement électronique, à voir en fonction de la taille du document, de sa complexité, de son importance, etc.
Non. Il fait son job, c’est tout.
[^] # Re: Langage
Posté par fravashyo (site web personnel) . Évalué à 2.
C'est sûr que si on doit imprimer un document, ça vaut le coup d'imprimer sur 30 % de papier en plus parce que LaTeX fait des marges monstrueuses par défaut.
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: Langage
Posté par lasher . Évalué à 2.
Si tu prends les réglages par défaut, alors tu auras aussi un police assez petite (10pt ?). Donc au final, tu auras pris autant de pages qu'avec Word ou Writer (je sais, j'ai fait le test pour du texte pur à l'époque où justement on se posait la question avec des potes). Ensuite, c'est si difficile d'ajouter le package
geometry? Genre\usepackage[left=2cm,right=2cm,top=2cm,bottom=2cm]{geometry}et ça y est. Ou bien tout bêtement\usepackage{fullpage}?[^] # Re: Langage
Posté par fravashyo (site web personnel) . Évalué à 3.
on est d'accord. Je réagissais juste au "il ne faut rien modifier".
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: Langage
Posté par fmaz fmaz . Évalué à 1.
Pour le coup, ces réglages me semblent très bon. Le principe est que, pour avoir un confort de lecture optimal, il faut éviter les lignes de plus de 50/60 caractères.
D'ailleurs, puisqu'il y a certains scientifiques par ici, Elsevier joue à mettre des lignes super longues pour avoir moins de papier à imprimer. Et je n'arrive pas à bosser avec les rendu finaux. Soit je bosse avec les versions arxiv, soit j'écris à l'auteur pour qu'il m'envoie une version compilée avec LaTeX.
[^] # Re: Langage
Posté par François (site web personnel) . Évalué à 3.
Ce point est généralement due au fait que les classes par défaut (genre article) sont conçu pour le papier format letter. L'option a4 ne fait que changer des paramètres basiques. Je te conseil donc d'utiliser komascript, largement disponible, avec sa classe 'scrartcl' par exemple. Ca change la vie.
[^] # Re: Langage
Posté par gouttegd (site web personnel) . Évalué à 3.
Rien à redire sur le diagnostic dans son ensemble, que je partage.
Mais concernant « le langage des styles Bibtex », je recommande vivement de passer à Biblatex, qui permet de mettre en forme les références bibliographiques en utilisant le langage LaTeX lui-même plutôt que le langage spécialisé (et, à ma connaissance, très peu documenté) de Bibtex.
[^] # Re: Langage
Posté par arnaudus . Évalué à 4.
Tu as certainement raison pour biblatex, mais ça illustre bien les problèmes liés à l'évolution de Latex : Latex ne s'améliore pas, il faut pallier aux défauts du système en utilisant des paquets indépendants bien conçus : incluegraphicx , geometry, ou biblatex. Mais tu perds toute la compatibilité avec l'existant ; tu peux te faire ton propre écosystème avec tes propres outils, mais comment font tes collègues? Comment tu fais quand l'éditeur fournit son style tout pourri? Tu dois faire avec les moyens du bord, dans un environnement hétérogène, avec des outils de qualité, des trucs construits sur des bases un peu foireuses, et tout un tas d'incompatbilités dans tous les sens : des surcouches sur des surcouches, des projets persos sur des paquets indispensables mais plus maintenus, des trucs redondants (french et frenchb)… Le mode bazar a ses limites, parfois il faut quand même un minimum d'organisation pour faire évoluer les choses et les rendre compétitives avec les solutions concurrentes.
[^] # Re: Langage
Posté par hervé Couvelard . Évalué à 6.
latex ne cherche pas à être compétitif avec les concurrents. Il cherche à faire ce qu'on lui demande.
Et compétitif avec quoi/qui/comment ?
Trouve moi, par exemple, un logiciel windows qui est capable de sortir un rapport de 500 pages,
- avec un sommaire automatique , ou tu choisis la profondeur de numérotation, différente dans le corps et dans le sommaire,
- avec la gestion des images différentes pour l'impression et l'écran (pdi)
- avec une listes des images automatique, une liste des tableaux automatiques
- avec une vraie césure
- avec une vraie gestion des blancs et du positionnement des images pour que cela reste jolie.
rien que cela, rien de bien compliqué en somme.
Ensuite la même chose sous mac.
Et pour être "compétitif" qui le fait nativement et intuitivement, sans avoir à chercher sur internet une manière de faire.
Je t'assure si tu en trouves un.. tu intéresseras tout plein de monde.
[^] # Re: Langage
Posté par Albert_ . Évalué à 9.
Avec un format qui change pas tous les ans mais qui reste stable depuis sa creation (un simple fichier texte a la con c'est pratique tout de meme) et avant que l'on me dise que le fichier source c'est bien mais ca sert a rien sans le ps ou pdf, je repond que les documents que j'ai ecris il y a plus de 10 ans n'ont toujours aucun probleme pour etre compiler et obtenir un rendus parfait. Tentais donc de faire la meme chose avec n'importe quel document genere par un wysiwyg.
[^] # Re: Langage
Posté par Anonyme . Évalué à 1.
dans mes bras !
# Moi c'est ce que j'utilise
Posté par hervé Couvelard . Évalué à 5.
… et ce que je propose à mes étudiants.
Pour quelques raisons simples :
1 - Il y a très peu de choses à connaître pour faire un rapport clair et structuré.
2 - il faut connaître énormément de choses pour faire un truc moche
3 - il oblige à structurer sémantiquement son écrit
4 - Il a une gestion très fine des zones blanches (ce qui rend les document joli à regarder)
5 - il fait les césures.
6 - le rendu des polices est incomparable.
Maintenant il a des inconvénients que j'accepte sans trop sourciller au vu de ses avantages.
[^] # Re: Moi c'est ce que j'utilise
Posté par Victor . Évalué à 4.
Tu parles de Latex ou de HTML là ? ;)
[^] # Re: Moi c'est ce que j'utilise
Posté par hervé Couvelard . Évalué à 2.
tu as vu html gérer automatiquement les blancs et faire les césures des mots ? Tu connais un peu html ?
[^] # Re: Moi c'est ce que j'utilise
Posté par Inigo Montoya . Évalué à 3.
Boh ce n'est pas la peine de répondre de façon aussi abrupte : )
J'imagine que son message visait justement à dire que pour quelqu'un qui connaissait peu LaTeX ou HTML ton commentaire pouvait sembler ambigu tout simplement.
[^] # Re: Moi c'est ce que j'utilise
Posté par hervé Couvelard . Évalué à 0.
pour quelqu'un qui ne connaît ni html ni latex, cherchez à faire des rapports sans se renseignez un peu sur ce que fait l'un ou l'autre c'est juste suicidaire.
J'avais bien senti le coté humoristique, mais parler de gestion des blancs avec html est comment dire…. un ressort comique ?
Ceux qui on bouffé de l'html à faire du rendu web pour des trucs simplistes juste avec un petit peu d'élaboration et un rendu un tant soit peu acceptable savent qu'il est in inenvisageable de l'utiliser pour autre chose que du web.
On peut écrire un livre avec que des p, mais le rendu est …. rèche.
Oui on peut faire des documents avec du html… et un tableur peut aussi servir de base de donnée.
Et pour ceux qui seraient enduit d'erreurs avec ce commentaires, il y a plein de gens qui décrivent assez bien qui fait quoi dans les commentaires pour qu'ils puissent se rendre compte eux même.
[^] # Re: Moi c'est ce que j'utilise
Posté par lasher . Évalué à 2.
Oui enfin à ce moment-là, tu pourrais faire comme Larry Wall et ses potes, et écrire tes rapports/bouquins/bla en Perl POD (Plain Old Documentation). C'est exactement ce qu'ils ont fait pour Programming Perl. Ça marche plutôt bien.
# Dans le milieu fashion des librairies JS ça se fait ...
Posté par MrBidon . Évalué à 1.
Je m'étais intéressé à la librairie suivante :
http://lab.hakim.se/reveal-js
Elle semble bien promettre du rêve, mais comme je n'ai pas trouvé comment faire des tableaux, j'avais abandonné… allez je profite de ce journal pour voir si il y a moyen.
[^] # Re: Dans le milieu fashion des librairies JS ça se fait ...
Posté par claudex . Évalué à 4.
Je viens de faire un test rapide et je ne vois pas le problème d'insérer la balise html
<table>.« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Dans le milieu fashion des librairies JS ça se fait ...
Posté par MrBidon . Évalué à 1.
Et bin merci du tuyau, je n'avais pas implémenté le truc et je n'avais pas vu un seul tableau dans les démos…
[^] # Re: Dans le milieu fashion des librairies JS ça se fait ...
Posté par barmic . Évalué à 5.
Ce qui m'a l'air pas mal pour générer du reveal http://orgmode.org/worg/org-tutorials/non-beamer-presentations.html#sec-6 :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Markdown(.mobi), c'est le contraire d'un buzzword...
Posté par jean-michel.bertrou.eu . Évalué à 2. Dernière modification le 22 octobre 2013 à 11:12.
Super journal qui m'oblige à commenter ailleurs que chez moi, en espérant qu'on m'autorise à m'intéresser à ça.
Je ne pense pas du tout que Markdown soit un buzzword sinon je ne me serais pas lancé depuis début août dans un projet de propagande libre en sa faveur.
Mais techniquement ça stagne, vu que j'ai réservé un DNS chez GANDI (markdown.mobi) mais ne m'y conaissant pas beaucoup en la matière, je patauge pas mal dans la configuration debian/nginx/php5/fastcgi/dokuwiki/…
Reste des trucs à rédiger en français, du contenu à traduire, …
Un point essentiel : Markdown c'est en fait le format ouvert qu'il manquait pour que partout où peut taper du texte brut (pas ASCII évidemment, UTF), on puisse également taper facilement quelquechose qui se convertit naturellement dans les standards les plus importants du moment que sont HTML et CSS
Quand on sait l'importance des formats ouverts et à quel point les standards texte brut utf-8, html, css sont ultradominants, mais pas simples à utiliser en pratique, on ne peut que comprendre que Markdown est quelque-chose de très très important.
Une banalité évidente et qui pourtant mérite d'être dite clairement, c'est que écrire pour le web et écrire pour que ce soit imprimé est tellement fondamentalement différent que ça nécessite des outils totalement différents. Donc non, je pense que latex garde tout son intérêt pour l'imprimé.
Ce que je dit dans l'article
write-better.md, c'est que Microsoft Word est un dinosaure de l'époque où le Personal Computer était une machine à écrire de luxe pas vraiment connectée… ou plutôt connectée avant tout à l'imprimante.Car si on y regarde bien, 90% des fonctionnalités de Word ne sont absolument pas nécessaires sur le Web et sur l'informatique mobile, et donc nuisibles puisque c'est du clutter qui fait que les gens n'utilisent pas en pratique les fonctionnalités qui elles sont réellement pratiques. (les tables de matières automatiques sont l'exception, les styles utilisés à bon escient idem, les liens n'en parlons pas, …)
Donc markdown me semble une rupture utile pour beaucoup du monde avec la vision du traitement de texte à la Word.
Je dis aussi dans
write-better.mdque avoir des formats ouverts concurrents qui font plus ou moins la même chose, ça tue tout l'intérêt des formats ouverts.Le contenu est temporairement là https://github.com/internaciulo/markdown.mobi
# Mélange des genres
Posté par Bruno Michel (site web personnel) . Évalué à 5.
On peut également se servir de LaTeX pour générer du HTML5 : http://latex2html5.com/
# portable Libreoffice (ou openoffice, peu importe)
Posté par freem . Évalué à 3.
A moins que tu ne fasses tout via le réseau et n'aie pas le droit d'exécuter des binaires non validés sur la machine qui t'intéresse, tu as oublié une solution simple: la framakey.
Je sais pas si c'est encore maintenu, mais ça semble régler ton problème de base, à savoir la portabilité de tes documents.
Pour le reste, le HTML vs LaTeX, je me suis fait mon opinion. Je n'ai jamais vraiment supporté les suites offices: ces outils sont trop lourds, trop complexes, bref, peu adaptés à mes besoins personnels.
Donc, à une époque, j'utilisais HTML pour faire des documents texte avec un minimum de présentation, grâce à amaya (et un peu notepad++). La syntaxe est XML-based, donc lourde comme tu l'as dis, ça demande un apprentissage conséquent ou du boulot pour faire un sommaire ( apprentissage conséquent pour avoir des trucs automatiques, que je n'ai pour être franc jamais été motivé pour faire) et c'est, au final, loin d'être proprement portable ( en fonction du navigateur ou de la taille d'écran, le rendu est différent, ce qui n'est pas forcément souhaitable, et ce, surtout pour une impression! )
J'ai toujours lorgné sur LaTeX, mais j'étais limité par windows… ben oui, télécharger 700MiO pour faire du traitement de texte, en sachant qu'il faudrait en plus apprendre un langage… flemme quoi. Surtout que, c'est quoi cette "pléthore" de distributions ( du point de vue du windowsien que j'étais, je parle hein )? Que choisir?
Cependant, j'ai fini par franchir le pas, de même que j'ai fini par passer à Debian. Conséquence, installation 'achement moins casse couille ( aptitude install textlive-recommended et zou, roulez jeunesse ), chopage d'un exemple qui trainasse sur le net, et en 10 min j'avais compris comment ça marche.
Le résultat: des documents écrits bien plus vite, LaTeX n'ayant pas cette cochonnerie de syntaxe icsémélienne, plus maintenable, pour la même raison, et qui m'affranchit définitivement d'avoir à choisir mes couleurs quand j'écris un rapport ( ça tombe bien, j'ai jamais aimé l'art plastique ), après compilation on à du pdf, qui s'affiche partout pareil, et comble de bonheur, pas de logiciels hyper lourds!
Que demande le peuple? Du HTML? Bah, il suffit de générer du HTML dans ce cas… je sais que c'est faisable, même si j'ai jamais testé.
Pour moi, LaTeX est ce qui se fait de mieux, même si je ne le maîtrise pas (mais je maîtrise pas plus HTML ou word de toute façon). Le document est vraiment portable, parce qu'on peut le modifier sur n'importe quelle machine ( un simple éditeur de texte fait l'affaire ) et supporte une tonne de formats différents en sortie.
Ah, mon canard me chuchote d'ailleurs qu'on peut générer des odt à partir de latex… mais idem, je n'ai jamais testé.
# Questions
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
Y'a des macros en HTML?
Y'a des outils aussi avancés que PGF/tikz pour faire des graphes et schémas ?
Je passe sur la gestion de l'espacement et des césures qui ont déjà été cités…
[^] # Re: Questions
Posté par 태 (site web personnel) . Évalué à 2.
Oui, il y a tikz/pgf ! Il y a un driver pgf pour produire du svg !
Pour les césures, il existe des bibliothèques javascript comme hyphenator.js qui « relies on Franklin M. Liangs hyphenation algorithm commonly known from LaTeX ». Mais il reste que la typographie dans les navigateurs n'est pas au niveau de ce que peut faire latex.
[^] # Re: Questions
Posté par Juke (site web personnel) . Évalué à 2.
Interessant mais ça risque d'etre penible d'embarquer du JS dans les liseuses EPUB.
[^] # Re: Questions
Posté par 태 (site web personnel) . Évalué à 4.
Les bonnes liseuses (lire celle que j'ai, de marque bookeen) ont implémenté un algorithme de césure dans le système. Donc même si le document ne le propose pas, le rendu sur liseuse peut être typographiquement agréable.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.