« Scénario » étant entré dans le vocabulaire français — j’en veux pour preuve son accent aigu, absent de son parent italien —, son pluriel est tout naturellement « scénarios » et non « scenarii », cette dernière forme ayant la double tare d’être incorrecte en français et obsolète en italien.
Et au cas où ce ne serait pas assez clair, Torvalds précise explicitement qu’un programme tournant sur un noyau Linux (donc utilisant ses appels systèmes) n’est pas un « travail dérivé du noyau » et n’est donc pas concerné par les conditions de la GPL :
NOTE! This copyright does not cover user programs that use kernel
services by normal system calls - this is merely considered normal use
of the kernel, and does not fall under the heading of "derived work".
Eh oui. Le contribuable paye pour financer le travail de recherche, il paye pour que celui-ci soit publié, et il paye pour que les laboratoires et les bibliothèques universitaires aient un accès à la revue dans laquelle le travail est publié.
Mais le contribuable a tout-à-fait accès à ces travaux, hein : s’il n’a pas accès à une bibliothèque universitaire, il lui suffit de payer (une quatrième fois, où est le problème ?) pour acheter les articles qui l’intéressent directement auprès de l’éditeur…
Je n'ai pas parlé d'un domaine scientifique en particulier. Mais il est vrai que je m'intéresse principalement aux sciences de l'information.
Je posais la question parce que dans mon domaine (biologie), si les articles en libre accès sont de moins en moins rares, ils sont encore loin de représenter une majorité.
Le epub gère très bien les gros volumes. Il est tout à fait possible de faire un epub par site avec un document xhtml par article ou par groupe d'articles.
J'ignorais. Ça marche bien sur les différentes liseuses ?
Sur les différentes liseuses, je ne sais pas, mais sur le Kobo, ça marche mieux en divisant le contenu en plusieurs documents XHTML de taille « raisonnable » qu’en regroupant tout dans un seul gros document.
Avec un seul fichier XHTML, au-delà de quelques centaines de pages, le Kobo « rame » — c’est-à-dire que tourner une page prend alors une dizaine de secondes, et ça empire à mesure qu’on approche de la fin. Comme si la liseuse devait re-parcourir tout le document depuis le début à chaque changement de page.
Pour une diapositive, il est recommandé d'avoir un message clair et court à lire. Sinon les gens lisent la diapositive au lieu de t'écouter. Du coup, il doit normalement rester beaucoup de place pour faire rentrer les quelques pixels de différence du texte.
C’est beaucoup plus que « quelques pixels », ça peut faire une ligne entière de différence, comme ici-même sur LinuxFR.org
Proposer un contenu
ou
Proposer un
contenu
Sur une diapositive, ça peut faire la différence par exemple entre un titre de diapo qui s’affiche sur une ligne sur le poste où tu prépares la présentation, et sur deux lignes sur le poste où tu la présentes, ce qui décale tout le reste de la diapo vers le bas.¹
C’est sûr que si tu ne mets qu’un slogan d’une ligne par diapo comme dans la présentation de reveal.js cité plus haut, ça ne posera guère de problèmes (et encore… sur un écran à 1920×1080, ça passe, mais sur un écran à 1024×768, il n’y a plus beaucoup de marge). Mais sur une diapo avec du vrai contenu (qui n’est pas nécessairement un gros pavé de texte comme tu le sous-entends), c’est très gênant et en aucun cas « mineur ».
¹ Oh ben ça alors, c’est le même genre de problèmes qu’on rencontrait avec une présentation préparée avec PowerPoint sous Windows et affichée avec PowerPoint sous Mac OS ou inversement… Où est le progrès ?
Mais en général ce qui change, c'est la police d'écriture.
Tu sembles dire ça comme si ce n’était qu'un détail mineur. Mais une différence de police suffit amplement à flinguer une mise en page. Ça suffit par exemple pour que le texte « Proposer un contenu » (en haut à gauche, sous le logo) s’affiche sur deux lignes au lieu d’une seule, avec la seconde ligne qui déborde du cadre.
Certes, sur une page web, ce n’est pas forcément très important (d’ailleurs je m’en fiche). Mais sur l’espace limitée d’une diapositive, ça l’est.
Bah, on a ce genre de problème (mais dans une moindre mesure, je te l'accorde) avec les PDF qui ne sont lisible qu'avec le reader d'Adobe (ça m'est déjà arrivé …).
Je sais, ça m’est arrivé aussi. Mais c’est causé par l’utilisation de fonctionnalités à la fois avancées et non-standards des dernières versions du format (introduites après la normalisation de PDF 1.7).
Pour HTML, rien que le rendu d’éléments simples et complètement standardisés est déjà variable d’un navigateur à l’autre. Même LinuxFR.org s’affiche différemment entre Firefox et un navigateur basé sur WebKit.
Et on a la garantie que le rendu sera identique d’un lecteur pdf à l’autre. Ou pas.
Je te l’accorde, avec HTML et PDF on a en théorie les mêmes garanties — après tout dans les deux cas on a une norme décrivant comment rendre le document. Sauf qu’en pratique, l’expérience est plutôt en faveur du PDF. Je n’ai jamais vu d’écarts de rendu d’un visionneur à l’autre comme ceux qu’on peut voir pour une page HTML d’un navigateur à l’autre.
Je ne vois pas trop ce qui empêche d'avoir un autre document avec ses notes sur une autre fenêtre.
Rien, en effet. Tout comme rien ne m’empêche, après tout, de faire mes présentations au format PNG avec une visionneuse d’images sur un écran, et mes notes au format texte dans un xmessage sur un autre écran. Je n’ai qu’à bidouiller quelque chose pour que l’affichage des deux soit synchronisé (passer à l’image suivante fait défiler le texte dans xmessage).
Sinon, pour répondre à ta question, ce format existe déjà : c'est le HTML. Pas besoin d'un lecteur spécifiue, les navigateurs sont intégrés dans les OS de nos jours.
Et on a la garantie que le rendu sera identique d’un navigateur à l’autre. Ou pas.
Par ailleurs, quel navigateur offre des fonctionnalités proche d’un « Pdf Presenter » ? Peut-on écrire une page HTML de telle sorte qu’une partie de la page soit affichée sur un écran et une autre partie sur un autre écran ? De façon portable, bien sûr ?
J'ai une petite idée de coment ça pourrait se faire(par contre ça prendrait beaucoup de temps …).
Je copie-colle ce que je viens d’écrire dans un autre commentaire : « je préfère utiliser un format standard qui existe maintenant qu’un hypothétique format spécialisé qui reste à inventer et qui sera éventuellement standardisé dans quinze ans ».
mais à un moment il faut s'arrêter de rendre ce format incompatible avec tout ce qui n'est pas adobe.
En l’occurence, et malgré tout le plaisir que j’ai à cracher sur Adobe, les deux premières méthodes d’intégration sont standards (et étaient déjà parfaitement documentées avant d’être normalisées), donc si ça marche mal avec autre chose que Adobe Reader, ce n’est pas à Adobe qu’il faut s’en prendre.
Si j’ai une chose à reprocher à Adobe, c’est plutôt d’avoir ajouté une troisième méthode (à base de Flash qui plus est, argh), dont l’intérêt est plus que contestable.
Pour les méthodes standards, la bibliothèque Poppler supporte sans problèmes les annotations concernées, il appartient ensuite aux développeurs des visionneurs d’en tirer profit. Certains le font, d’autres non.
Je préfère utiliser un format standard qui existe maintenant qu’un hypothétique format spécialisé qui reste à inventer et qui sera standardisé (s’il l’est un jour) dans quinze ans.
C'est grave …. Personnellement ça me choque d'intégrer un truc animé dans un format prévu pour l'impression.
À mon avis ce n’est pas l’intégration de vidéo le pire, c’est plutôt l’intégration de code Javascript ou, pire encore (depuis Adobe Reader 9) de code Flash. Un lecteur PDF devient quasiment aussi complexe qu’un navigateur web. Et d’ailleurs, les documents PDF malicieux sont devenus un vecteur majeur d’attaque, exploitant les failles desdits lecteurs.
N'aurait-il pas mieux vallu un format dédié pour ce genre d'utilisation ?
Pourquoi pas, mais en attendant que quelqu’un s’y colle (toi ?), je préfèrerai toujours utiliser un PDF qu’un PowerPoint ou un Impress — d’expérience, l’intégration de vidéo dans un PowerPoint fonctionne encore plus mal que dans un PDF.
Non, mais vu que la page d’accueil annonce que le rendu est fait avec Xpdf ou Ghostscript, il est quasi-certain je pense que les vidéos ne sont pas supportées : Xpdf ne les gère pas et j’imagine mal Ghostscript (qui est un interpréteur de langage PostScript) le faire. Et si les développeurs avaient ajouté eux-mêmes le support des vidéos, ils en feraient certainement état parmi les features de leur logiciel.
Par ailleurs, quand je lis ça dans la FAQ, ça ne m’impress!onne pas beaucoup :
Unfortunately PyGame, the windowing API currently used by Impressive, does not contain any support for multi-monitor setups whatsoever. This means that you can't really tell Impressive on with monitor it shall run. On Linux, you can try to run it in windowed mode, move the window to the proper monitor and enable fullscreen mode there, but it isn't guaranteed that this works either.
Apple utiliser le conteneur MP4 comme format standard, il ne reconnait pas les AVI de base.
Pourtant du MJPEG dans du AVI ne lui pose aucun problème. Ce format me conviendrait d’ailleurs très bien (c’est le format généré en sortie par ImageJ, l’outil que j’utilise pour créer mes vidéos), s’il n’y avait le fait que celui-là c’est Windows qui ne le lit pas. >_<
Je te conseille de sortir un .mp4 de ta vidéo MPEG4, elle sera reconnue sur toutes les plateformes !
Effectivement, le même codec (MPEG4 Part 2) dans du MP4, ça marche sous GNU/Linux, Mac OS X, et Windows. Bon, avec une taille d’échantillon de n=1 pour chaque cas, donc je m’attends quand même à tomber un jour sur une machine sur laquelle ça ne passera pas, mais pour l’instant, je vais retenir ça. Merci pour l’info. :)
Et c'est plutôt pervers de mettre du MPEG4 dans du AVI, sachant que le conteneur officiel du MPEG4 est le … MP4 …
Bah vu que QuickTime supporte à la fois le conteneur AVI avec un autre codec (puisqu’il est capable de lire du AVI contenant du MJPEG) et le codec MPEG4 Part 2 dans un autre conteneur (puisqu’il lit du MP4 contenant du MPEG4 Part 2), je ne trouve pas déraisonnable de croire qu’il aurait pu lire du MPEG4 Part 2 dans un conteneur AVI… d’autant que VLC, MPlayer (sous GNU/Linux) et Windows Media Player y arrivent.
Quel intérêt d’avoir des formats de conteneur distincts des formats d’encodage si un format d’encodage ne fonctionne que dans son conteneur « officiel » ?
Et avec "Aperçu", quelles sont les balises reconnues ?
QPdfPresenterConsole est inspiré (entre autres) de PdfPresenterConsole, mais c’est un tout autre programme, pas seulement un port Qt de PdfPresenterConsole.
Je n’ai pas testé ce dernier, mais si tu le fais, n’hésite pas à rapporter ici s’il est capable de lire des vidéos.
Pour ton problème de dépendance, as-tu essayé d’installer simplement le paquet manquant (libpoppler-qt4-3) ?
-Relever le courrier : vaut mieux leur configurer leur compte…
Leur montrer le client mail et les laisser faire.
Non parce qu’à un moment il faut arrêter l’assistanat (à prononcer sur le ton d’un salaud de droite). Configurer un client mail n’est plus une tâche difficile aujourd’hui.
L’utilisateur n’a que deux choses à connaître : son adresse e-mail et son mot de passe ; avec ça, Thunderbird par exemple fait tout le boulot (trouver le nom des serveurs d’envoi et de réception, les ports, les méthodes d’authentification, etc.). Bon, ça ne marche qu’avec les fournisseurs de messagerie connus, mais comme il y a peu de chance que l’utilisateur dont on parle utilise un fournisseur exotique, ça ne sera pas un problème.
À la limite, le faire devant lui, mais alors en insistant bien sur le fait que c’est tout con et que la prochaine fois il pourra (devra) le faire tout seul.
Ma question est-ce important d'avoir des documents mise en pages en générale ?
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é).
Avec les journaux et les romans ça fait pas mal de lecture déjà.
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.
Tu as quoi comme modèle si ce n'est pas indiscret ?
Une Kobo. À éviter.
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)
Donc elle ne fait pas mieux que la mienne, apparemment.
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.
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.
Surtout que le html simplifie tout : vue que tu n'a pas de page le placement des figures devient trivials.
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.
Ma question est « est-ce que ce sera longtemps pertinent de faire des articles scientifique et des thèses pour les imprimer ?»
Tant que les versions électroniques seront aussi peu pratiques (parce qu’elles ne seront que des versions électronalisées du papier), oui.
epub est un format d'échange et ne se soucie pas de l'affichage
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).
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)
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.
4 Maintenant si t'a besoin d'une mise en page soigné, LaTeX roxe du Poney !
Ayant une liseuse, je dois reconnaître que je trouve bien plus agréable de lire sur liseuse que sur papier.
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.
Ça marche tant que tu ne cherche pas à imprimer et que tu n'utilises rien de compliquer (du texte avec des titres) […] mais la mise en page n'est pas nécessaire la majorité du temps.
Ah ouais, je vois. Pas étonnant que ça ne marche pas pour moi, alors.
C'est ça l'erreur. Tu d'occupes de la forme !
Excuse-moi d’avoir envie que mes références ressemblent à autre chose qu’à ça :
W Arap R Nishikawa F Furnari W Cavanee H Huang Replacement of p16/CDKN2 gene suppresses human glioma cell growth 1351 1354 Cancer Res 1995 55
et de préférer quelque chose comme ça :
W. Arap, R. Nishikawa, F. Furnari, W. Cavanee, H. Huang (1995). Replacement of p16/CDKN2 gene suppresses human glioma cell growth. Cancer Res., 55:1351–1354.
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.
E n 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
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é »).
et je pense que la probabilité flexibilité est plus importante que la perfection typographique.
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. ;)
Si les liseuses propose une typographie moins bonne que celle offerte pas TeX, c'est un problème de liseuse pas d'EPUB.
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.
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.
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).
Docbook doit correspondre à cela si je ne dit pas de bêtise.
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.
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.
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.
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.
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.
# Scénarios
Posté par gouttegd . En réponse au journal Le moment crucial. Évalué à 10.
« Scénario » étant entré dans le vocabulaire français — j’en veux pour preuve son accent aigu, absent de son parent italien —, son pluriel est tout naturellement « scénarios » et non « scenarii », cette dernière forme ayant la double tare d’être incorrecte en français et obsolète en italien.
Ceci était un message de la Cadémie française.
[^] # Re: Licence GPL
Posté par gouttegd . En réponse au message Embarquer/utiliser Linux dans un projet commercial ?. Évalué à 4.
Et au cas où ce ne serait pas assez clair, Torvalds précise explicitement qu’un programme tournant sur un noyau Linux (donc utilisant ses appels systèmes) n’est pas un « travail dérivé du noyau » et n’est donc pas concerné par les conditions de la GPL :
[^] # Re: comprendre le format epub et le format pdf ?
Posté par gouttegd . En réponse au journal contenus epub. Évalué à 5.
Eh oui. Le contribuable paye pour financer le travail de recherche, il paye pour que celui-ci soit publié, et il paye pour que les laboratoires et les bibliothèques universitaires aient un accès à la revue dans laquelle le travail est publié.
Mais le contribuable a tout-à-fait accès à ces travaux, hein : s’il n’a pas accès à une bibliothèque universitaire, il lui suffit de payer (une quatrième fois, où est le problème ?) pour acheter les articles qui l’intéressent directement auprès de l’éditeur…
[^] # Re: comprendre le format epub et le format pdf ?
Posté par gouttegd . En réponse au journal contenus epub. Évalué à 4.
Je posais la question parce que dans mon domaine (biologie), si les articles en libre accès sont de moins en moins rares, ils sont encore loin de représenter une majorité.
[^] # Re: Automatiser avec Weboob
Posté par gouttegd . En réponse au journal contenus epub. Évalué à 3.
Sur les différentes liseuses, je ne sais pas, mais sur le Kobo, ça marche mieux en divisant le contenu en plusieurs documents XHTML de taille « raisonnable » qu’en regroupant tout dans un seul gros document.
Avec un seul fichier XHTML, au-delà de quelques centaines de pages, le Kobo « rame » — c’est-à-dire que tourner une page prend alors une dizaine de secondes, et ça empire à mesure qu’on approche de la fin. Comme si la liseuse devait re-parcourir tout le document depuis le début à chaque changement de page.
[^] # Re: comprendre le format epub et le format pdf ?
Posté par gouttegd . En réponse au journal contenus epub. Évalué à 4.
Par curiosité, de quel domaine scientifique parles-tu ?
Certains éditeurs (notamment Public Library of Science) fournissent les articles dans un dialecte XML spécialisé, le Journal Publishing Tag Set.
[^] # Re: Impression
Posté par gouttegd . En réponse au journal Intégrer des vidéos dans des fichiers PDF. Évalué à 2. Dernière modification le 16 novembre 2013 à 01:48.
C’est beaucoup plus que « quelques pixels », ça peut faire une ligne entière de différence, comme ici-même sur LinuxFR.org
ou
Sur une diapositive, ça peut faire la différence par exemple entre un titre de diapo qui s’affiche sur une ligne sur le poste où tu prépares la présentation, et sur deux lignes sur le poste où tu la présentes, ce qui décale tout le reste de la diapo vers le bas.¹
C’est sûr que si tu ne mets qu’un slogan d’une ligne par diapo comme dans la présentation de reveal.js cité plus haut, ça ne posera guère de problèmes (et encore… sur un écran à 1920×1080, ça passe, mais sur un écran à 1024×768, il n’y a plus beaucoup de marge). Mais sur une diapo avec du vrai contenu (qui n’est pas nécessairement un gros pavé de texte comme tu le sous-entends), c’est très gênant et en aucun cas « mineur ».
¹ Oh ben ça alors, c’est le même genre de problèmes qu’on rencontrait avec une présentation préparée avec PowerPoint sous Windows et affichée avec PowerPoint sous Mac OS ou inversement… Où est le progrès ?
[^] # Re: Impression
Posté par gouttegd . En réponse au journal Intégrer des vidéos dans des fichiers PDF. Évalué à 2.
Tu sembles dire ça comme si ce n’était qu'un détail mineur. Mais une différence de police suffit amplement à flinguer une mise en page. Ça suffit par exemple pour que le texte « Proposer un contenu » (en haut à gauche, sous le logo) s’affiche sur deux lignes au lieu d’une seule, avec la seconde ligne qui déborde du cadre.
Certes, sur une page web, ce n’est pas forcément très important (d’ailleurs je m’en fiche). Mais sur l’espace limitée d’une diapositive, ça l’est.
[^] # Re: Impression
Posté par gouttegd . En réponse au journal Intégrer des vidéos dans des fichiers PDF. Évalué à 2.
Je sais, ça m’est arrivé aussi. Mais c’est causé par l’utilisation de fonctionnalités à la fois avancées et non-standards des dernières versions du format (introduites après la normalisation de PDF 1.7).
Pour HTML, rien que le rendu d’éléments simples et complètement standardisés est déjà variable d’un navigateur à l’autre. Même LinuxFR.org s’affiche différemment entre Firefox et un navigateur basé sur WebKit.
[^] # Re: Impression
Posté par gouttegd . En réponse au journal Intégrer des vidéos dans des fichiers PDF. Évalué à 3. Dernière modification le 13 novembre 2013 à 14:25.
Je te l’accorde, avec HTML et PDF on a en théorie les mêmes garanties — après tout dans les deux cas on a une norme décrivant comment rendre le document. Sauf qu’en pratique, l’expérience est plutôt en faveur du PDF. Je n’ai jamais vu d’écarts de rendu d’un visionneur à l’autre comme ceux qu’on peut voir pour une page HTML d’un navigateur à l’autre.
Rien, en effet. Tout comme rien ne m’empêche, après tout, de faire mes présentations au format PNG avec une visionneuse d’images sur un écran, et mes notes au format texte dans un xmessage sur un autre écran. Je n’ai qu’à bidouiller quelque chose pour que l’affichage des deux soit synchronisé (passer à l’image suivante fait défiler le texte dans xmessage).
[^] # Re: Impression
Posté par gouttegd . En réponse au journal Intégrer des vidéos dans des fichiers PDF. Évalué à 2.
Et on a la garantie que le rendu sera identique d’un navigateur à l’autre. Ou pas.
Par ailleurs, quel navigateur offre des fonctionnalités proche d’un « Pdf Presenter » ? Peut-on écrire une page HTML de telle sorte qu’une partie de la page soit affichée sur un écran et une autre partie sur un autre écran ? De façon portable, bien sûr ?
[^] # Re: Impression
Posté par gouttegd . En réponse au journal Intégrer des vidéos dans des fichiers PDF. Évalué à 3.
Je copie-colle ce que je viens d’écrire dans un autre commentaire : « je préfère utiliser un format standard qui existe maintenant qu’un hypothétique format spécialisé qui reste à inventer et qui sera éventuellement standardisé dans quinze ans ».
[^] # Re: bref
Posté par gouttegd . En réponse à la dépêche Intégrer des vidéos dans des fichiers PDF. Évalué à 7.
En l’occurence, et malgré tout le plaisir que j’ai à cracher sur Adobe, les deux premières méthodes d’intégration sont standards (et étaient déjà parfaitement documentées avant d’être normalisées), donc si ça marche mal avec autre chose que Adobe Reader, ce n’est pas à Adobe qu’il faut s’en prendre.
Si j’ai une chose à reprocher à Adobe, c’est plutôt d’avoir ajouté une troisième méthode (à base de Flash qui plus est, argh), dont l’intérêt est plus que contestable.
Pour les méthodes standards, la bibliothèque Poppler supporte sans problèmes les annotations concernées, il appartient ensuite aux développeurs des visionneurs d’en tirer profit. Certains le font, d’autres non.
Je préfère utiliser un format standard qui existe maintenant qu’un hypothétique format spécialisé qui reste à inventer et qui sera standardisé (s’il l’est un jour) dans quinze ans.
[^] # Re: Impression
Posté par gouttegd . En réponse au journal Intégrer des vidéos dans des fichiers PDF. Évalué à 2.
À mon avis ce n’est pas l’intégration de vidéo le pire, c’est plutôt l’intégration de code Javascript ou, pire encore (depuis Adobe Reader 9) de code Flash. Un lecteur PDF devient quasiment aussi complexe qu’un navigateur web. Et d’ailleurs, les documents PDF malicieux sont devenus un vecteur majeur d’attaque, exploitant les failles desdits lecteurs.
Pourquoi pas, mais en attendant que quelqu’un s’y colle (toi ?), je préfèrerai toujours utiliser un PDF qu’un PowerPoint ou un Impress — d’expérience, l’intégration de vidéo dans un PowerPoint fonctionne encore plus mal que dans un PDF.
[^] # Re: Et Impress!ve ?
Posté par gouttegd . En réponse à la dépêche Intégrer des vidéos dans des fichiers PDF. Évalué à 7.
Non, mais vu que la page d’accueil annonce que le rendu est fait avec Xpdf ou Ghostscript, il est quasi-certain je pense que les vidéos ne sont pas supportées : Xpdf ne les gère pas et j’imagine mal Ghostscript (qui est un interpréteur de langage PostScript) le faire. Et si les développeurs avaient ajouté eux-mêmes le support des vidéos, ils en feraient certainement état parmi les features de leur logiciel.
Par ailleurs, quand je lis ça dans la FAQ, ça ne m’impress!onne pas beaucoup :
[^] # Re: Mac OS
Posté par gouttegd . En réponse au journal Intégrer des vidéos dans des fichiers PDF. Évalué à 5.
Pourtant du MJPEG dans du AVI ne lui pose aucun problème. Ce format me conviendrait d’ailleurs très bien (c’est le format généré en sortie par ImageJ, l’outil que j’utilise pour créer mes vidéos), s’il n’y avait le fait que celui-là c’est Windows qui ne le lit pas. >_<
Effectivement, le même codec (MPEG4 Part 2) dans du MP4, ça marche sous GNU/Linux, Mac OS X, et Windows. Bon, avec une taille d’échantillon de n=1 pour chaque cas, donc je m’attends quand même à tomber un jour sur une machine sur laquelle ça ne passera pas, mais pour l’instant, je vais retenir ça. Merci pour l’info. :)
Bah vu que QuickTime supporte à la fois le conteneur AVI avec un autre codec (puisqu’il est capable de lire du AVI contenant du MJPEG) et le codec MPEG4 Part 2 dans un autre conteneur (puisqu’il lit du MP4 contenant du MPEG4 Part 2), je ne trouve pas déraisonnable de croire qu’il aurait pu lire du MPEG4 Part 2 dans un conteneur AVI… d’autant que VLC, MPlayer (sous GNU/Linux) et Windows Media Player y arrivent.
Quel intérêt d’avoir des formats de conteneur distincts des formats d’encodage si un format d’encodage ne fonctionne que dans son conteneur « officiel » ?
Aucune.
[^] # Re: Evince et QPdfPresenterConsole
Posté par gouttegd . En réponse au journal Intégrer des vidéos dans des fichiers PDF. Évalué à 5.
QPdfPresenterConsole est inspiré (entre autres) de PdfPresenterConsole, mais c’est un tout autre programme, pas seulement un port Qt de PdfPresenterConsole.
Je n’ai pas testé ce dernier, mais si tu le fais, n’hésite pas à rapporter ici s’il est capable de lire des vidéos.
Pour ton problème de dépendance, as-tu essayé d’installer simplement le paquet manquant (libpoppler-qt4-3) ?
[^] # Re: Et du vrai mutualisé ?
Posté par gouttegd . En réponse au journal Auto-hébergement et sécurisation des accès via HTTPS. Évalué à 3.
Je crois que c’est l’idée derrière monkeysphere.
[^] # Re: lire ton cours
Posté par gouttegd . En réponse au message Explication d'un Script Shell. Évalué à 2.
S’il veut juste une référence rapide, il peut aussi utiliser
help for,help if, etc, plutôt que de consulter la page d’info complète.[^] # Re: Exemples d'usages domestiques
Posté par gouttegd . En réponse au journal Comment apprend-on Linux à des néophytes.. Évalué à 3.
Leur montrer le client mail et les laisser faire.
Non parce qu’à un moment il faut arrêter l’assistanat (à prononcer sur le ton d’un salaud de droite). Configurer un client mail n’est plus une tâche difficile aujourd’hui.
L’utilisateur n’a que deux choses à connaître : son adresse e-mail et son mot de passe ; avec ça, Thunderbird par exemple fait tout le boulot (trouver le nom des serveurs d’envoi et de réception, les ports, les méthodes d’authentification, etc.). Bon, ça ne marche qu’avec les fournisseurs de messagerie connus, mais comme il y a peu de chance que l’utilisateur dont on parle utilise un fournisseur exotique, ça ne sera pas un problème.
À la limite, le faire devant lui, mais alors en insistant bien sur le fait que c’est tout con et que la prochaine fois il pourra (devra) le faire tout seul.
[^] # Re: Langage
Posté par gouttegd . En réponse au journal Le HTML (epub3) peut il détrôner latex (surtout beamer) ?. É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 gouttegd . En réponse au journal Le HTML (epub3) peut il détrôner latex (surtout beamer) ?. É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 gouttegd . En réponse au journal Le HTML (epub3) peut il détrôner latex (surtout beamer) ?. É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 gouttegd . En réponse au journal Le HTML (epub3) peut il détrôner latex (surtout beamer) ?. É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 gouttegd . En réponse au journal Le HTML (epub3) peut il détrôner latex (surtout beamer) ?. É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.