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.*
]
# Ce n'est pas une feature
Posté par David Delassus (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 - https://github.com/link-society/flowg
[^] # Re: Ce n'est pas une feature
Posté par SpaceFox (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 qpad . É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 David Delassus (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 - https://github.com/link-society/flowg
[^] # Re: Ce n'est pas une feature
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 9.
Comme avec 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 David Delassus (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 - https://github.com/link-society/flowg
[^] # Re: Ce n'est pas une feature
Posté par Gil Cot ✔ (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 David Demelier (site web personnel) . Évalué à 5.
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 David Delassus (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 - https://github.com/link-society/flowg
[^] # Re: Ce n'est pas une feature
Posté par stopspam . Évalué à 3.
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 harlock974 . Évalué à 6.
Ben oui. Si encore ça avait été écrit en C, ça aurait pu être un plus.
[^] # Re: Ce n'est pas une feature
Posté par Guillawme (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 29 mars 2023 à 18:45.
Je croyais que c’était Perl.
[^] # Re: Ce n'est pas une feature
Posté par fabricius . Évalué à 3.
ah bon? On m'a toujours dit que c'était le lisp.
[^] # Re: Ce n'est pas une feature
Posté par alberic89 🐧 . Évalué à 5.
Je confirme, c'est bien lui.
Voir ici pour l'histoire.
L'informatique n'est pas une science exacte, on n'est jamais à l'abri d'un succès
[^] # Re: Ce n'est pas une feature
Posté par khertan . É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 SpaceFox (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 qpad . Évalué à 3.
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 karteum59 . É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 Gil Cot ✔ (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 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 à qui ressemble (dans la philosophie et l'approche) à ce que fait (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'
“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 Liorel . Évalué à 8.
Je séparerais le problème en deux :
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 . 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. 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 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 , 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 LaurentClaessens (site web personnel) . Évalué à 10.
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
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Cette fonctionnalité s'appelle SyncTeX.
[^] # Re: Le problème des zillions de modules
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 28 mars 2023 à 20:15.
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
Ç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 qpad . Évalué à 3.
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 Guillawme (site web personnel, Mastodon) . Évalué à 4.
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 pepie34 . É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 🚲 Tanguy Ortolo (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 flan (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 Ysabeau 🧶 (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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
???
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 Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 28 mars 2023 à 10:07.
C'est ce que dit la page Wikipédia :
C'est aussi ce qu'écrit le W3C:
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4. Dernière modification le 28 mars 2023 à 10:16.
Ok, je comprends. En revanche, je maintiens que :
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 Ysabeau 🧶 (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 pepie34 . É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 Ysabeau 🧶 (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 minch . É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 flan (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 Gil Cot ✔ (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 flan (site web personnel) . Évalué à 2.
Sauf si tu veux un dégradé de couleur (en fonction d’une valeur). Et comment rajoutes-tu facilement une colonne ?
[^] # Re: AsciiDoc est le vrai nouveau LateX
Posté par jeanas (site web personnel, Mastodon) . Évalué à -1.
s/AsciiDoc/Sphinx :-)
</troll gentil>
[^] # Re: AsciiDoc est le vrai nouveau LateX
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
Attention que :
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Mais bien sûr.
Ç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 🚲 Tanguy Ortolo (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 :
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 qpad . É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 :
ce qui ressemble beaucoup à "importer une extension"
[^] # Re: Intéressant
Posté par Gil Cot ✔ (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 qpad . É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 Gil Cot ✔ (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 qpad . É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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
En attendant un CTyAN ?
# Babel
Posté par 🚲 Tanguy Ortolo (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 Thom (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 :
Mes besoins spécifiques :
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 qpad . Évalué à 2.
Quelques réponses, d'après ce que j'ai lu/compris.
Le compilateur en ligne de commande est open source et ils fournissent des binaires pour linux/max/windows sur leur page github
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.
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 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 fonctionheading
. 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 Gil Cot ✔ (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 les1fr
et2fr
, 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 Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 30 mars 2023 à 06:04.
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 SpaceFox (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 Gil Cot ✔ (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.)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 :
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 :
La solution, un peu magique, est expliqué par
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 , 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 :En regardant l'illustration, on voit que l'on passe de à pour
1fr
! Ouch. Et l'auteur assène :M'ouais, toujours pas clair pour moi ce
1fr
; ce qui est lisible ici c'est la constructionrepeat(x, 1fr)
que je peux traduire par .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…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 que2fr
c'est le double de1fr
et que3fr
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 devientBon, 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 SpaceFox (site web personnel, Mastodon) . Évalué à 2.
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 :fr
dans le définition,Ça implique aussi que
1fr
d'une déclaration n'a aucun rapport avec1fr
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 Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Oui, c'est la dernière pièce qu'il me manquait. Je l'ai trouvé ce matin chez MDN qui explique…
…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…
…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 lesN
deNfr
pour avoir le nombre de subdivisions total. etC'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 barmic 🦦 . Évalué à 2.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Il y a deux façons de comprendre cela :
1fr
représente un n-ième de la place disponible, avec n égal au nombre defr
utilisés ;fr
garantissent que leur rapport sera préservé, par exemple que2fr
sera deux fois plus grand que1fr
, et que toute la place disponible sera utilisée.[^] # Re: quelques questions
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
En tout cas, il me manquait la première au moment où j'avais posté. C'est plus clair maintenant. Merci tout le monde.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: quelques questions
Posté par Thom (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 yosch . É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.
[^] # Re: Alternatives à creuser
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
XeTeX n'est pas vraiment une alternative à LaTeX, c'est une implémentation spécifique de TeX.
[^] # Re: Alternatives à creuser
Posté par yosch . Évalué à 0.
C'est pas la même chose mais c'est différent? 🤔
La != Xe
Un remplacement avec plus de fonctionnalités, ça te va ?
[^] # Re: Alternatives à creuser
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 5.
Non, c'est bien « une implémentation spécifique de TeX » ; tout comme LuaTeX évoqué plus haut. Dans l'univers TeXnique, on parle de « moteur » (c'est ce que Tanguy appelle « implémentation spécifique » ici) alternatif. Tu peux compiler ton document LaTeX avec XeTeX ou d'autres moteurs. LaTeX c'est un format de macros au dessus. Ce sont deux choses orthogonales en fait.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Alternatives à creuser
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Je ne connaissais pas SILE, ça a l'air intéressant aussi.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.