Journal typst est le nouveau LaTeX

Posté par  . Licence CC By‑SA.
Étiquettes :
30
26
mar.
2023

Allô,

Je viens de découvrir typst, un tout nouveau format de document à balise (je veux dire "markup language") pour la production de textes scientifiques. Il se place donc directement en concurrent de Tex/LaTeX. Pour résumer rapidement ce que j'ai lu sur le sujet :

  • Une syntaxe (probablement) plus claire et intuitive, incluant bien sur un mode mathématiques
  • Un langage de script complet intégré pour remplacer de manière plus puissante et plus simple les macros par des fonctions
  • un moteur de rendu incrémental et performant
  • Écrit en Rust
  • Open source (Apache License), mais ils proposent aussi une application web sytle Overleaf qui est propriétaire.

Pour le peu que j'en ai vu ca à l'air assez convaincant et ça a le potentiel pour vraiment remplacer LateX…. vous connaissez ? avez d'autres avis ?

Juste un exemple de syntaxe :

#set text(
  font: "New Computer Modern",
  size: 10pt
)
#set page(
  paper: "a6",
  margin: (x: 1.8cm, y: 1.5cm),
)
#set par(
  justify: true,
  leading: 0.52em,
)

= Introduction
In this report, we will explore the
various factors that influence fluid
dynamics in glaciers and how they
contribute to the formation and
behavior of these natural structures.

...

#align(center + bottom)[
  #image("glacier.jpg", width: 70%)

  *Glaciers form an important
  part of the earth's climate
  system.*
]

Le repo github
La doc
Le mode math

  • # Ce n'est pas une feature

    Posté par  (site web personnel) . Évalué à 10.

    "Écrit en Rust".

    Le projet est suffisamment intéressant et innovant pour qu'on puisse se passer de ça dans la description. D'ailleurs, le README du projet ne fait pas mention de Rust autre part que dans la section "Build from Source".

    Il faut arrêter de lister "écrit en $X" comme une fonctionnalité. "$X" ne rendra jamais un projet intrinsèquement meilleur.

    https://link-society.com - https://kubirds.com

    • [^] # Re: Ce n'est pas une feature

      Posté par  (site web personnel, Mastodon) . Évalué à 10. Dernière modification le 26 mars 2023 à 17:38.

      En général je suis d'accord avec ça. Mais ici, c'est une information réellement utile à avoir, parce que les langages de programmation utilisés sont un réel problème dans l'évolution de (La)TeX. Idem pour les performances : LaTeX est catastrophiquement lent pour ce qu'il fait, et les langages exotiques qu'il utilise n'aident pas à corriger le problème.

      Ici, le fait que projet soit écrit dans un langage bien connu, largement utilisé par ailleurs et qui permet de créer des programmes performants est donc, de mon point de vue, une information pertinente à donner.

      La connaissance libre : https://zestedesavoir.com

    • [^] # Re: Ce n'est pas une feature

      Posté par  . Évalué à 6.

      Ben alors… si on peut plus utiliser les buzz words !

      Sinon, je ne sais pas qui dit ou même sous-entend que "écrit en $X" est une fonctionnalité, mais pas moi.
      Il me semblait juste que c'était une info intéressante à donner sur ce site.

      • [^] # Re: Ce n'est pas une feature

        Posté par  (site web personnel) . Évalué à 8.

        T'inquiète, c'est juste moi qui fait mon rabat-joie parce qu'il y a une vrai hype autour de Rust, et que parfois, sur HackerNews, la seule différence entre un post qui fait la frontpage et un qui tombe dans l'oublie au bout de 3min c'est "in Rust" dans le titre.

        On a vu pas mal de projet de réécriture d'outils déjà existant dont le seul argument de vente était "c'est écrit en Rust", et bien souvent ils étaient plus pauvre en fonctionnalité, et plus riches en bugs.

        Comme je l'ai dit, typst est bien plus intéressant que son langage d'implémentation. Le fait qu'il propose un langage de scripting au sein du document a vraiment été le point qui a piqué mon intérêt en fait.

        https://link-society.com - https://kubirds.com

        • [^] # Re: Ce n'est pas une feature

          Posté par  (site web personnel, Mastodon) . Évalué à 9.

          Le fait qu'il propose un langage de scripting au sein du document a vraiment été le point qui a piqué mon intérêt en fait.

          Comme avec Lua\LaTeX depuis quelques années ? (le langage est Lua comme l'indique le nom)

          “It is seldom that liberty of any kind is lost all at once.” ― David Hume

          • [^] # Re: Ce n'est pas une feature

            Posté par  (site web personnel) . Évalué à 2. Dernière modification le 27 mars 2023 à 05:16.

            Je ne connaissais pas, merci !

            https://link-society.com - https://kubirds.com

            • [^] # Re: Ce n'est pas une feature

              Posté par  (site web personnel, Mastodon) . Évalué à 2.

              C'est un univers riche et toujours foisonnant ; du coup, certaines évolutions ne sont pas connues. Pour ne rien arranger, on a le foisonnement de documentations sur le legacy qui tend à masquer ces avancées sauf dans certains milieux…

              “It is seldom that liberty of any kind is lost all at once.” ― David Hume

    • [^] # Re: Ce n'est pas une feature

      Posté par  (site web personnel) . Évalué à 5.

      Il faut arrêter de lister "écrit en $X" comme une fonctionnalité. "$X" ne rendra jamais un projet intrinsèquement meilleur.

      Je suis pas d'accord. J'utilise plantuml au travail pour nos diagramme (non, faire ça en graphviz pur serait du pur masochisme) et je t'assure que ça m'embête bien d'avoir une dépendance à OpenJDK juste pour faire des diagrammes pendant la compilation de la documentation.

      git is great because linus did it, mercurial is better because he didn't

      • [^] # Re: Ce n'est pas une feature

        Posté par  (site web personnel) . Évalué à 6.

        J'ai aussi pas mal utilisé plantuml, au final c'est surtout ma CI/CD qui possède la dépendance, tu joins ça à la "preview" des pull requests sur netlify, ça donne un workflow assez sympa.

        Sinon, quid de mermaidjs ? Je l'utilise pas mal aussi, et j'ai pas vraiment eu besoin de plantuml depuis.

        Bon, au lieu d'avoir une dépendance à OpenJDK, tu as une dépendance à NodeJS. Ça pourrait valoir le coup d'avoir une alternative compilée en un simple exécutable. Mais après que cet exe soit en Rust, C, C++, Go, … Cela ne changerait rien pour moi.

        https://link-society.com - https://kubirds.com

    • [^] # Re: Ce n'est pas une feature

      Posté par  . Évalué à 3.

      "Écrit en Rust".

      https://garrit.xyz/posts/2023-03-26-software-is-not-defined-by-the-language-it%27s-written-in

      Un post qui a trusté qq places sur HN :p

    • [^] # Re: Ce n'est pas une feature

      Posté par  . Évalué à 6.

      Ben oui. Si encore ça avait été écrit en C, ça aurait pu être un plus.

      Titre de l'image

    • [^] # Re: Ce n'est pas une feature

      Posté par  . Évalué à 0.

      "Ecrit en JS avec électron" cela vend moins du rêve. Donc, oui, un peu quand même.

  • # Le problème des zillions de modules

    Posté par  (site web personnel, Mastodon) . Évalué à 10.

    L'un des gros problèmes avec LaTeX aujourd'hui, et qui rends difficile son remplacement, c'est la quantité astronomique de modules et extensions diverses qui sont à peu près indispensables pour gérer des documents un peu modernes (en particulier : sortir de l'anglais écrit dans des fichiers ASCII).

    Aujourd'hui c'est à la fois une des plus grosses faiblesse de LaTeX (la moindre installation fonctionnelle prends une place scandaleuse pour le service rendu, sans compter l'impact sur les performances) et l'une de ses plus grandes forces (taille de la communauté, workflows personnels ultra optimisés avec divers paquets tiers et custom).

    Je ne sais pas comment ce projet a prévu de s'attaquer à ce problème.

    La connaissance libre : https://zestedesavoir.com

    • [^] # Re: Le problème des zillions de modules

      Posté par  . Évalué à 3.

      Je ne sais pas comment ce projet a prévu de s'attaquer à ce problème.

      Je ne sais pas vraiment non plus, mais visiblement le système fournit de base l'utf-8, les figures, la couleur, les tableaux et la bibiliographie (mais je ne sais pas à quel niveau de sophistication…).
      Je crois comprendre que le système de script intégré devrait permettre le développement de templates et de packages similaires à ce qui existe pour LaTeX.

      • [^] # Re: Le problème des zillions de modules

        Posté par  . Évalué à 6.

        Il y a longtemps j'étais tombé sur ce programme (Ant is Not TeX :). J'ai l'impression que c'est abandonné mais ça m'avait semblé assez complet.

        (et il y a encore plus longtemps, j'étais tombé sur Lout qui semble être tombé dans l'oubli donc ce post est l'occasion d'en reparler :)

        • [^] # Re: Le problème des zillions de modules

          Posté par  (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 27 mars 2023 à 23:49.

          C'est marrant que ANT utilise kpathsea ;-) Bon, sa doc PDF dit que le but est de réimplémenter \TeX dans un autre langage et avec un langage de macros (nommé AL…) plus proche de Haskel. Cependant, ça ne s'arrête pas là et défini un un certain nombre de macros alternatives à \LaTeX qui ressemble (dans la philosophie et l'approche) à ce que fait Con\TeX t (un format qui semble s'établir durablement et est maintenu…)

          En regardant rapidement les sources des Typst, j'ai vu que ça fait appel à ReX qui est un peu l'équivalent de Katex et MathJax pour Rust : ça digère les formules TeX pour sortir du SVG …on peut le tester en ligne

          Par contre, Lout n'a aucun lien avec l'univers\TeX

          “It is seldom that liberty of any kind is lost all at once.” ― David Hume

    • [^] # Re: Le problème des zillions de modules

      Posté par  . Évalué à 8.

      Je séparerais le problème en deux :

      • La base de code "utile" existante ;
      • La base de "colle" et de code qui ne sert qu'à élever le niveau d'abstraction (pour me permettre, par exemple, de séparer mon texte sur 2 colonnes sans avoir à tout coder à la main. Pour un exemple particulièrement dans cette catégorie, voir Beamer)

      Je pense que tout le monde sera heureux de se débarrasser des milliers de fonctions qui ne servent que de colle si elles sont remplacées par des fonctions nouvelles et intuitives (ce dernier point est très important, car on peut faire tellement de choses en typographie qu'il y aura de toute façon des tas de choses à apprendre, il est donc nécessaire qu'elles soient intuitives et documentées).

      A l'inverse, on continuera peut-être à avoir du code legacy en \LaTeX. Pour prendre un exemple, je vois mal l'auteur du Frido tout réécrire en typst, si puissant que puisse être le langage. On risque donc de se retrouver dans la situation du Fortran : un vieux langage, plus du tout utilisé pour les nouveaux projets, mais néanmoins parfaitement fonctionnel à sa manière un peu datée, et dont la base de gens qui savent coder dedans s'émousse au fil du temps, poussant non seulement le langage, mais aussi les projets dans l'obsolescence.

      Je ne suis cependant pas sûr que ce soit un vrai souci. \LaTeX a deux particularités : il est majoritairement utilisé pour produire des documents finaux, et il est particulièrement inadapté au travail collaboratif (le maîtriser étant en soi une compétence). Les utilisateurs actuels de \LaTeX continueront à l'utiliser. Quand ils arrêteront de maintenir leurs documents, ils arrêteront de toute façon d'évoluer.

      Reste à voir ce qu'a Typst sous le pied. Parce qu'on a adorer détester \LaTeX, il reste vachement puissant.

      Ça, ce sont les sources. Le mouton que tu veux est dedans.

      • [^] # Re: Le problème des zillions de modules

        Posté par  (site web personnel) . Évalué à 10.

        A l'inverse, on continuera peut-être à avoir du code legacy en \LaTeX. Pour prendre un exemple, je vois mal l'auteur du Frido tout réécrire en typst, si puissant que puisse être le langage.

        L'auteur du Frido (c'est moi) ne retapera effectivement pas tout.
        Il n'a cependant rien contre se mettre à mieux que LaTeX. Il faut

        • Un convertisseur automatique qui fait le gros du boulot.
        • Quelques personnes sous la main chez qui je peux venir pleurnicher en termes de "comment je peux refaire tel environnement ?"

        Comment ça se passe pour les figures ? Elles sont toutes en tikz générées par yanntricks. Or yanntricks a une fonctionnalité géniale[1] qui est qu'en deux passes, il sait la taille des boites des objets LaTeX insérés dans les figures. Le placement est automatique.
        Est-ce que typst permet de savoir la taille de la boîte d'un bout de code ?

        Avec pdflatex, un double-clic dans le pdf m'ouvre le bon fichier à la bonne ligne. Cette fonctionnalité est obligatoire.

        Par contre, cette histoire d'environnement de travail collaboratif ne m'inspire pas tellement confiance. Il y a quand même moyen d'écrire des fichiers texte brut tout seul dans son coin en Vim ?

        Et puis, qu'est-ce qui me prouve que typst n'est pas n'est pas un standard de plus qui va disparaître ?

        Pour info, le Frido n'a effectivement que très peu de contributions sous forme de modifications du code LaTeX. La très grande majorité sont des mails perso de la forme "j'ai trouvé une erreur page 1238 : la continuité est uniforme et non normale".

        L'aspect «édition collaborative» n'est donc pas un critère.

        [1] Déclaration de conflit d'intérêt: je suis l'auteur.

        • [^] # Re: Le problème des zillions de modules

          Posté par  (site web personnel) . Évalué à 4.

          Avec pdflatex, un double-clic dans le pdf m'ouvre le bon fichier à la bonne ligne. Cette fonctionnalité est obligatoire.

          Cette fonctionnalité s'appelle SyncTeX.

        • [^] # Re: Le problème des zillions de modules

          Posté par  (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 28 mars 2023 à 20:15.

          Par contre, cette histoire d'environnement de travail collaboratif ne m'inspire pas tellement confiance. Il y a quand même moyen d'écrire des fichiers texte brut tout seul dans son coin en Vim ?

          J'ai eu aussi ce frein en voyant qu'il fallait passer par un service en ligne… Mais il semble qu'on peut avoir plus ou moins la même chose en local mais faut passer par l'éditeur maison qui est connecté au serveur local. quad< pointe, plus loin, une liste où sont mentionnés typst.vim et typst.nvim

          Et puis, qu'est-ce qui me prouve que typst n'est pas n'est pas un standard de plus qui va disparaître ?

          Ça va dépendre s'il y a l'engouement de Markdown (preuve que ça ne se joue pas à la qualité) sinon ça peut avoir le sort de Lout… comme le rappelle karteum59<

          “It is seldom that liberty of any kind is lost all at once.” ― David Hume

          • [^] # Re: Le problème des zillions de modules

            Posté par  . Évalué à 3.

            J'ai eu aussi ce frein en voyant qu'il fallait passer par un service en ligne… Mais il semble qu'on peut avoir plus ou moins la même chose en local mais faut passer par l'éditeur maison qui est connecté au serveur local

            Non, non on peut télécharger un compilateur en ligne de commande à partir de :
            https://github.com/typst/typst/releases

            chez moi ça marche !

        • [^] # Re: Le problème des zillions de modules

          Posté par  (site web personnel, Mastodon) . Évalué à 4.

          L'auteur du Frido (c'est moi) ne retapera effectivement pas tout.
          Il n'a cependant rien contre se mettre à mieux que LaTeX. Il faut

          • Un convertisseur automatique qui fait le gros du boulot.

          Il y en a déjà un ! Pandoc s'est doté d'un writer vers le format de Typst depuis la version 3.1.2 publiée le 26 mars. Et pandoc a déjà un reader et un writer pour LaTeX. Donc pour l'instant on peut convertir dans un seul sens (de LaTeX vers Typst), mais il finira sûrement par y avoir aussi un reader pour Typst (en général pandoc fait la plupart des conversions dans les deux sens, tant qu'il n'y a pas de difficulté technique qui l'empêche).

  • # structure et style

    Posté par  . Évalué à 3.

    Juste à première vue dans le même fichier source, il y a styles et structures de mélanger.
    Ce qui était la plaie pour traiter automatiquement du latex.

    • [^] # Re: structure et style

      Posté par  (site web personnel) . Évalué à 5. Dernière modification le 27 mars 2023 à 17:01.

      L'avantage avec un langage à macros, c'est qu'on peut librement séparer les deux. Il suffit de définir des macros avec un nom sémantique, qui sont remplacées par des macros plus bas niveau ou par des primitives.

      • [^] # Re: structure et style

        Posté par  (site web personnel) . Évalué à 4.

        En pratique, pour du LaTeX, cette séparation est complètement théorique.

        J'aurais bien vu un sous-ensemble de HTML+CSS (en supprimant les quelques balises historiques de forme) comme représentation intermédiaire, avec comme langage d'écriture ce même sous-ensemble avec des macros intégrées.

        On aurait donc [HTML/CSS + macros] -> [HTML/CSS pur] -> [PDF ou visualisation directe].
        L'avantage est qu'il n'y a pas plus répandu que le HTML, qu'il y a des centaines d'outils le prenant en compte, que c'est facile d'en faire du PDF, et qu'on peut ajouter des animations facilement.

        • [^] # Re: structure et style

          Posté par  (site web personnel, Mastodon) . Évalué à 2.

          Et que le Html et Xml sont des cousins et que l'Epub 3 est basé sur le Html, la version 2 l'étant sur le xml.

          « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

          • [^] # Re: structure et style

            Posté par  (site web personnel) . Évalué à 4.

            l'Epub 3 est basé sur le Html, la version 2 l'étant sur le xml.

            ???

            Désolé, mais un Epub 2, ça reste une archive Zip contenant surtout du HTML. Le sommaire et la colonne vertébrale sont en XML et non en HTML, certes, mais ça reste largement basé sur HTML.

            • [^] # Re: structure et style

              Posté par  (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 28 mars 2023 à 10:07.

              C'est ce que dit la page Wikipédia :

              Il est fondé sur le XML.

              C'est aussi ce qu'écrit le W3C:

              The EPUB format has gained some popularity as a vendor-independent XML-based e-book format.

              Après, je doute que ça ait une grande importance puisque les balises de base sont les mêmes.

              « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

              • [^] # Re: structure et style

                Posté par  (site web personnel) . Évalué à 4. Dernière modification le 28 mars 2023 à 10:16.

                Ok, je comprends. En revanche, je maintiens que :

                l'Epub 3 est basé sur le Html, la version 2 l'étant sur le xml

                C'est n'importe quoi. En fait, Epub tout court est basé sur XML et sur HTML. Une nouveauté d'Epub 3 est d'utiliser HTML5. C'est tout.

                L'idée qu'Epub serait passé d'HTML à XML est complètement fausse. Je t'invite à disséquer un bouquin en Epub 2 et un en Epub 3 si tu veux t'en rendre compte.

                • [^] # Re: structure et style

                  Posté par  (site web personnel, Mastodon) . Évalué à 3.

                  Merci. C'est le truc que je n'avais pas compris, cette histoire de passage du XML au HTML5, qui en fait n'existe pas.

                  Bref, toujours est-il qu'un remplaçant de LaTeX qui supporterait (ou quel que soit le mot adéquat) le HTML pourrait générer mieux des EPUB, notamment des EPUB 3 ce qui permettrait d'avoir des publications avec des formules de maths plus accessibles des dispositifs d'assistance.

                  Et il serait, de toute façon, plus interopérable.

                  « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

      • [^] # Re: structure et style

        Posté par  . Évalué à 2.

        Oui mais rien ne l'oblige et rien ne le standardise.

        Essaye de faire un latex vers odt/html pour voir.

        Il faudrait vraiment une séparation à la XML/CSS mais humainement écrivable pour la partie structure, pas forcément dans 2 fichiers mais dans 2 sections séparées, et qu'on ne puisse faire de modification de style via des tags.

        En effet, mise en gras c'est du style alors que mise en avant c'est de la structure.
        Dans l'exemple, on voit beaucoup de mise en gras et pas beaucoup de mise en avant

        • [^] # Re: structure et style

          Posté par  (site web personnel, Mastodon) . Évalué à 5. Dernière modification le 28 mars 2023 à 11:20.

          C'est toute la différence entre les balises <em> et <i>, et <strong> et <b>.

          « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

  • # AsciiDoc est le vrai nouveau LateX

    Posté par  . Évalué à 2.

    En vrai => pour de la documentation technique <= AsciiDoc est une panacée =D

    Même si ruby ne fait pas autant rêver que rust…

    Mais y a un support natif dans github/gitlab au même titre que markdown

    Ça génère du HTML proprement et puis aussi du PDF (et d'autres formats)
    Au besoin le thème peut être custom.

    Pour les notations STEM on peut choisir un moteur de rendu.

    (Full Disclosure : Mes collègues m’ont renommé capitaine adoc tellement je suis fan)

    • [^] # Re: AsciiDoc est le vrai nouveau LateX

      Posté par  (site web personnel) . Évalué à 3.

      Puis on veut des tableaux qu'on modifie régulièrement et avec un peu de couleur, et là c'est le drame :(

      • [^] # Re: AsciiDoc est le vrai nouveau LateX

        Posté par  (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 27 mars 2023 à 23:12.

        Là, y a pas tableau, AsciiDoc s'en sort bien mieux que Markdown et d'autres pourtant encensés…

        (pour info, tu gères tes tableaux sans te préoccuper de la forme si ce n'est d'indiquer le nom du style qui lui sera appliqué pour ton jeu de couleurs ; et tu modifies donc tes valeurs sans avoir à faire de drame)

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

    • [^] # Re: AsciiDoc est le vrai nouveau LateX

      Posté par  . Évalué à -1.

      s/AsciiDoc/Sphinx :-)

      </troll gentil>

      • [^] # Re: AsciiDoc est le vrai nouveau LateX

        Posté par  (site web personnel, Mastodon) . Évalué à 4.

        Attention que :

        • reStructuredText est le format pour lequel Sphinx (Python/Django) est son seul cadriciel connu disponible ;
        • AsciiDoc est le format pour lequel il y a les cadriciels Asciidoctor (Ruby) / AsciidoctorJ (JVM Jav) / Asciidoctor.js (Javascript) ; on peut aussi utiliser docToolchain (ensemble de scripts, avec jBake sous le capot pour le SSG) ou mieux le système Antora (la CLI et le SSG).

        Sphinx est un peu plus difficile à mettre en œuvre que Antora ou les Asciidoctor. Quand aux formats, adoc est quand même plus simple que et plus élégant que rst que j'aime beaucoup. Mais sur certains trucs/détails, c'est adoc qui est perturbant.

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

    • [^] # Re: AsciiDoc est le vrai nouveau LateX

      Posté par  (site web personnel) . Évalué à 4.

      AsciiDoc est le vrai nouveau LateX

      Mais bien sûr.

      En vrai => pour de la documentation technique <= AsciiDoc est une panacée =D

      Ça, sans doute. Mais remplacer LaTeX, faut pas rêver je crois. Ou alors il va falloir m'expliquer comment coder une extension d'AsciiDoc pour faire des présentations avec structure externe, dévoilement progressif des transparents, mise en forme des théorèmes, des exemples et compagnie, et allez, des parties en vers, tant qu'à faire.

  • # Intéressant

    Posté par  (site web personnel) . Évalué à 9. Dernière modification le 28 mars 2023 à 10:36.

    C'est très intéressant. Mais ça a l'air tellement différent de TeX que je ne comprends pas bien comment est censé fonctionner un module d'extension.

    Je suppose, ou en tout cas j'espère que les auteurs de Typst connaissent assez TeX et LaTeX pour avoir une idée de ce que les gens peuvent en attendre en matière d'extensibilité.

    Pour moi, un des trucs actuellement irremplaçables que j'utilise avec LaTeX, c'est Beamer. C'est à ma connaissance le seul outil de présentation qui permettent de définir :

    • évidemment, des maths, des vers, des tableaux, bref ce qu'on veut ;
    • des diapositives avec un dévoilement successif (ou alternatif) de choses à afficher ;
    • une structure, une hiérarchie de parties si vous voulez.

    Le dernier point me semble être une base pour pouvoir construire quoi que ce soit qui tienne la route, tant pour l'auteur que pour les auditeurs, et c'est pourtant absent de tout ce que j'ai vu d'autre comme logiciel de présentation.

    Comme Beamer est un truc assez conséquent construit sur LaTeX, je trouve que ça en fait un bon exemple pour voir si Typst a une chance de le concurrencer.

    • [^] # Re: Intéressant

      Posté par  . Évalué à 3.

      Il y a l'air d'avoir déjà une ébauche de template de présentation :
      https://github.com/andreasKroepelin/typst-slides

      L’exemple dans cet page contient :

      #import "slides.typ": *

      ce qui ressemble beaucoup à "importer une extension"

      • [^] # Re: Intéressant

        Posté par  (site web personnel, Mastodon) . Évalué à 2.

        C'est un bon début et il y a encore du chemin à faire (le read me dit qu'il manque les overlays mais pas que.)

        Au passage, je n'ai pas trouvé de gestion des extraits de code source…

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

        • [^] # Re: Intéressant

          Posté par  . Évalué à 5.

          Je suis d'accord, ce n'est pas encore comparable à ce qu'on peut trouver pour LaTeX.
          Ceci dit, je découvre cette liste d'extensions :

          https://github.com/qjcg/awesome-typst

          … pas mal étant donné la jeunesse du projet !

          • [^] # Re: Intéressant

            Posté par  (site web personnel, Mastodon) . Évalué à 3.

            Super, ce lien aurait mérité d'être listé dans le journal aussi. Ça répond à beaucoup de questions posés par ailleurs :)

            “It is seldom that liberty of any kind is lost all at once.” ― David Hume

            • [^] # Re: Intéressant

              Posté par  . Évalué à 1.

              Oui je ne l'avais pas encore trouvé lorsque j'ai posté le journal…

              Je crois qu'il faut demander à un gentil modérateur de l'ajouter au journal ?

          • [^] # Re: Intéressant

            Posté par  (site web personnel) . Évalué à 4.

            En attendant un CTyAN ?

  • # Babel

    Posté par  (site web personnel) . Évalué à 9.

    Visiblement, il manque aussi un bout, qui viendra sans doute, mais pour nous, c'est assez rédhibitoire pour le moment : une extension pour écrire en français, avec les règles de césure et les mots comme « chapitre » et « table des matières » en français.

    Babel ou Polyglossia, quoi.

  • # quelques questions

    Posté par  (site web personnel) . Évalué à 2. Dernière modification le 29 mars 2023 à 14:20.

    Pour mon usage, taper des cours et des évals niveau collège en maths.

    Je pense que ça commence à être difficile de m'imaginer que je vais me séparer de Latex.

    Mes besoins fondamentaux :

    • J'ai besoin de pouvoir taper à la main dans un éditeur de mon choix avec un fichier de type text qui se versionne bien.
    • J'ai besoin de pouvoir compiler à la main dans un terminal. parce que le To get started, you create a new project on the Typst app. Ça c'est un gros, gros non.

    Mes besoins spécifiques :

    • minipage : quand la mise en page en mode column ne suffit pas parce que les colonnes n'ont pas la même largeur.
    • dotfill : en gros d'avoir un vraie vision de sa fin de ligne… Notamment pour des pointillés.
    • images : les images en format pdf surtout.

    Dans les questionnements :

    • Les tables : https://typst.app/docs/reference/layout/table/ Pour le moment, sans trop chercher, je trouve ça compliqué, mais je pense que je pourrais m'y faire.

    • les caractères spéciaux en maths mais qui n'utilise aucun signe genre beta donne le symbole. genre sum_(i=0)nabla ; pas besoin de parenthèse ou d'accolade pour mettre en haut, le fait que nabla n'ai pas de symbole pour dire que nabla ne doit pas être écrit nabla mais avec le symbole…

    • Les listes : Mettre des plus pour faire une numération auto n'est clairement pas suffisante pour ce que j'aime. Pareil pour les titres. J'aime bien avoir la main sur ma numération. Notamment parce que souvent ça foire assez souvent les listes dès qu'on met des éléments genre des images dedans et qu'après ça repart de 1… (Je m'en sers comme questions d'exercices)

    • Le développement. Je veux surtout un truc qui tient dans le temps sans trop tout se péter et qui continue à s'installer sans me soûler.

    • Tous ces trucs dont je me sers une fois par an mais que je trouve quand même utile. Pour exemple ma classe de doc : https://github.com/homeostasie/2022-2023_artic/blob/master/src/doc-class-cours.tex

    Mais dans tous les cas, ça me semble une bonne idée et je suis curieux de voir comment ça évolue.

    Le genre de doc que j'écris : https://github.com/homeostasie/2022-2023_artic/tree/master/src

    La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick

    • [^] # Re: quelques questions

      Posté par  . Évalué à 2.

      Quelques réponses, d'après ce que j'ai lu/compris.

      J'ai besoin de pouvoir taper à la main dans un éditeur de mon choix avec un fichier de type text qui se versionne bien.
      J'ai besoin de pouvoir compiler à la main dans un terminal. parce que le To get started, you create a new project on the Typst app. Ça c'est un gros, gros non.

      Le compilateur en ligne de commande est open source et ils fournissent des binaires pour linux/max/windows sur leur page github

      images : les images en format pdf surtout.

      Dans les exemples que j'ai vu on peut inclure du png, jpeg et svg… ca me fait esperer qu'inclure du pdf est déjà possible.

      les caractères spéciaux en maths mais qui n'utilise aucun signe genre beta donne le symbole. genre sum_(i=0)nabla ; pas besoin de parenthèse ou d'accolade pour mettre en haut, le fait que nabla n'ai pas de symbole pour dire que nabla ne doit pas être écrit nabla mais avec le symbole…

      Pas sur de comprendre la question ou le pbm. Mais c'est vrai qu'il y'a une vrai différence avec LaTeX. Je crois que le truc à comprendre est que tout ce qui n'est pas 1 seul caractère va être interprété comme une fonction. Pour insérer un vrai mot dans un mode math il faut le mettre entre guillemets.

      Les listes : Mettre des plus pour faire une numération auto n'est clairement pas suffisante pour ce que j'aime. Pareil pour les titres. J'aime bien avoir la main sur ma numération. Notamment parce que souvent ça foire assez souvent les listes dès qu'on met des éléments genre des images dedans et qu'après ça repart de 1…

      Les points et les "=" pour les titres c'est leur sucre syntaxique pour être proche de markdown. En fait, == Mon titre est équivalent à #heading(..options..)[Mon titre] . Et visiblement y'a plein d'options possibles à la fonction heading. Même chose pour les listes.

      Pour le reste, je ne sais pas trop… comme tu dis ça devrait évoluer et s’étoffer si ca plait.

    • [^] # Re: quelques questions

      Posté par  (site web personnel, Mastodon) . Évalué à 3.

      Les fondamentaux (utiliser son éditeur, compiler dans le terminal, ne pas dépendre d'une appli ou service en ligne) ont été discuté dans un autre fil plus tôt :-)

      Pour les spécifiques…
      Le colonage en parts égales est prévu avec #colbreak() en prime ; mais ce qui se rapprocherait le plus des mini pages me semble être le bloc.
      Pour les espacements horizontaux élastiques, il semble qu'il faille jouer avec #box() auquel on donne une largeur élastique (par contre, je n'ai pas compris les 1fr et 2fr, et pas trouvé de réponse dans les unités absolues/proportionnelles/combinées…) et #repeat() ? L'exemple donné, #box(width: 1fr, repeat[.]), correspondrait donc à \dotfill ; et j'en déduis que \hrulefill et \hfill (qu'est-qu'ils sont mal nommés…) ont pour équivalents #box(width: 1fr, repeat[_]) et #box(width: 1fr, repeat[ ]) ou un truc du genre. C'est moins macro…
      Concernant les images, il est dit qu'il n'y a pour l'heure que le support de PNG/JPEG/GIF/SVG… Va falloir attendre pour le PDF.

      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

      • [^] # Re: quelques questions

        Posté par  (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 30 mars 2023 à 06:04.

        (par contre, je n'ai pas compris les 1fr et 2fr, et pas trouvé de réponse dans les unités absolues/proportionnelles/combinées…)

        Addendum : fr comme fraction en fait, mais ce n'est toujours pas clair pour moi.

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

        • [^] # Re: quelques questions

          Posté par  (site web personnel, Mastodon) . Évalué à 4.

          fr c’est une unité standard CSS, cf ici pour un exemple détaillé de son utilisation. C’est très pratique pour gérer les grilles, cf les grilles en CSS.

          La connaissance libre : https://zestedesavoir.com

          • [^] # Re: quelques questions

            Posté par  (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 31 mars 2023 à 01:31.

            Merci pour ces liens ; ne pratiquant pas les grilles CSS, j'avais pas fait gaffe à l'apparition de cette unité. À la lecture du premier lien ça reste un peu flou, mais probablement qu'avec plus de pratique l'illumination viendra ?
            En tout cas, Typst reprend le concept avec son #grid(), ce qui devrait faciliter la conversion/transposition dans un sens comme dans l'autre.


            La version longue…

            Pour commencer, l'exemple me parle et c'est probablement ce que j'aurais fait de prime abord (hormis le repeat dont je ne me souvenais pas.)

              display: grid;
              grid-template-columns: repeat(4, 25%);
              grid-column-gap: 10px;

            Ce qui est dénoncé comme premier souci n'en est pas pour moi qui calcule toujours précisément, mais poursuivons. Le second (moins) petit souci est celui de l'écartement :

            Because we’ve set each column to 25% and a grid-column-gap to 10px then that pushes grid element wider than 100%. […] What we’re really saying with the code above is “set each column to 25% the width of the viewport and have a 10px gap between them.” It’s a subtle difference,

            Là, soit j'aurais mis cet écartement à zéro et rajouté des marges internes (ce n'est pas exactement pareil, mais les boîtes peuvent s'en trouver mieux aérées et je trouve ça mieux…) ; soit j'aurais estimé le pourcentage max que devrait représenter la somme des écartements pour recalculer les pourcentages en conséquence (mais il est vrai que le premier souci de l'auteur est que les calculs lui filent la migraine…) Il donne la solution :

              display: grid;
              grid-template-columns: repeat(4, 1fr);
              grid-column-gap: 10px;

            La solution, un peu magique, est expliqué par

            There’s no overflow on the x-axis anymore because setting each column to 1fr takes that 10px into account automatically and subtracts it from the total width available for each column.

            So far, so good. Sauf que, pour l'instant, je comprends que 1fr = 25% no plus de la largeur totale mais de la largeur totale sans la somme des trois écartements. Le coup du disponible vs utilisable (Pour en revenir à du \LaTeX, c'est un peu comme \pagewidth —tout le papier— vs \textwidth —sans les marges— vs \linewidth —sans les indentations/espacements supplémentaires du contexte— ainsi que d'autres comme \hsine —pour le/la paragraphe/liste/boîte courant/e— et \columnwidth —pour la colonne ou figure courante— etc. Revenons à nos moutons.) Puis vient l'exemple suivant, dit plus complexe :

              display: grid;
              grid-template-columns: 250px repeat(12, 1fr);
              grid-column-gap: 10px;

            En regardant l'illustration, on voit que l'on passe de \frac{1}{4}=25\% à \frac{1}{12}=5\% pour 1fr ! Ouch. Et l'auteur assène :

            one “fraction of the free space” (literally how the spec phrases it). […] It’s super readable […]

            M'ouais, toujours pas clair pour moi ce 1fr ; ce qui est lisible ici c'est la construction repeat(x, 1fr) que je peux traduire par \frac{1}{x}.
            Ah si, une chose est plus claire : le passage, dans le premier exemple, de repeat(4, 25%) à repeat(4, 1fr) a bien illustré la spécification qui dit que « A flexible length or is a dimension with the fr unit, which represents a fraction of the leftover space in the grid container. » Par contre, pour quelle fraction j'arrive pas à savoir : ce fut tantôt 25% tantôt 8% magiquement. L'exemple suivant a ramené mes interrogations initiales

              grid-template-columns: 1fr 1fr 40px 2fr;

            …Si on retire les 40px le reste (le « leftover space » de la ligne) se réparti, en regardant l'image à 25%/25%/50%. Je devine que 2fr c'est le double de 1fr et que 3fr en serait le triple ? Si c'est le cas, c'est une avancée dans ma compréhension ; mais je bloque toujours sur le fait que l'unité de référence soit ¼ et que dans un autre contexte ça devient {}^1/{}_{12}
            Bon, vais lire MDN voir si ça m'avance plus (d'habitude ce site ne me déçoit pas mais il faut dans certains cas croiser plusieurs sites pour comprendre un concept.)

            “It is seldom that liberty of any kind is lost all at once.” ― David Hume

            • [^] # Re: quelques questions

              Posté par  (site web personnel, Mastodon) . Évalué à 2.

              Par contre, pour quelle fraction j'arrive pas à savoir : ce fut tantôt 25% tantôt 8% magiquement.

              C'est exactement l'intérêt. 1fr c'est "une partie de l'espace libre, les marges sont gérées". Sa taille est calculée automatiquement ("magique") et dépend donc :

              • Du nombre de fr dans le définition,
              • Du nombre d'espacement fixes de la définition,
              • Des marges etc.

              Ça implique aussi que 1fr d'une déclaration n'a aucun rapport avec 1fr d'une autre déclaration, même si les conteneurs ont la même taille.

              C'est extrêmement pratique dans le cadre de CSS où tu ne sais jamais quelle va être la langueur exacte de l'affichage, et où les pourcentages sont pénibles à cause de problèmes d'arrondis et de flexibilité. Dans le cadre d'un remplacement à LaTeX, ça me semble surtout utile pour les modèles, parce que sur un document final tu connais les dimensions du document.

              La connaissance libre : https://zestedesavoir.com

              • [^] # Re: quelques questions

                Posté par  (site web personnel, Mastodon) . Évalué à 3.

                • Du nombre de fr dans le définition,

                Oui, c'est la dernière pièce qu'il me manquait. Je l'ai trouvé ce matin chez MDN qui explique…

                  grid-template-columns: 2fr 1fr 1fr;

                …par « L'espace disponible est divisé en quatre. Les deux premières fractions sont allouées à la première colonne, et chacune des colonnes suivante dispose d'une fraction. » (sic) puis plus loin…

                  grid-template-columns: 500px 1fr 2fr;

                …par « L'espace restant est divisé en trois et alloué proportionnellement aux deux colonnes spécifiées avec l'unité relative fr. » (sic)

                Plus que le nombre de fr, on additionne tous les N de Nfr pour avoir le nombre de subdivisions total. 2+1+1=4\implies\mathrm{1fr}=1/4 et 1+2=3\implies\mathrm{1fr}=1/3

                Ça implique aussi que 1fr d'une déclaration n'a aucun rapport avec 1fr d'une autre déclaration, même si les conteneurs ont la même taille.

                C'est ça qui me perturbait vu que je ne comprenais pas comment la valeur était déterminée.
                Bon, maintenant reste à savoir (pour la complétude) si N est seulement entier (peut-on avoir officiellement 1.6fr par exemple ?) et le cas particulier du zéro… :-D

                “It is seldom that liberty of any kind is lost all at once.” ― David Hume

            • [^] # Re: quelques questions

              Posté par  . Évalué à 2.

              je bloque toujours sur le fait que l'unité de référence soit ¼ et que dans un autre contexte ça devient {}^1/{}_{12}

              Quand tu le répète 4 fois 1fr c'est un quart et quand tu le répète 12 c'est un douzième ?

              https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

              • [^] # Re: quelques questions

                Posté par  (site web personnel) . Évalué à 3.

                Il y a deux façons de comprendre cela :

                1. 1fr représente un n-ième de la place disponible, avec n égal au nombre de fr utilisés ;
                2. les spécifications en fr garantissent que leur rapport sera préservé, par exemple que 2fr sera deux fois plus grand que 1fr, et que toute la place disponible sera utilisée.
      • [^] # Re: quelques questions

        Posté par  (site web personnel) . Évalué à 3.

        Merci pour toutes les précisions.

        J'avoue que je suis toujours intéressé par un après Latex même si je commence à avoir du mal à l'imaginer. Mais ça reste une bonne idée, bien prometteur. J'espère qu'ils vont persévérer pour continuer à l'améliorer.

        Après, je ne suis pas vraiment informaticien, alors quand un outil me convient je l'utilise sans trop chercher si un autre pourrait faire le même taf encore mieux.

        La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick

  • # Alternatives à creuser

    Posté par  . Évalué à 3.

    Des alternatives à creuser (plus matures à mon humble avis): XeTeX et SILE avec des fonctionnalités mettant l'accent sur la mise en page pour les alphabets complexes.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.