Sygne a écrit 629 commentaires

En visitant le site exovis, où l'on découvre la forme des systèmes solaires, je me suis pris à imaginer à quoi pouvait ressembler les planètes, puis j'ai été pris de vertige face à l'immensité de certains systèmes, et au final, c'est comme si j'avais lu un bon roman de science fiction. C'est un beau site (si ce n'est qu'il ne manque de faire exploser mon ordinateur).

Mais que c'est pauvre en information. Il n'y a vraiment rien sur les dites planètes, ni d'ailleurs sur les étoiles autour desquelles elles tournent. J'imagine que des suppositions sur leurs masses, voire leurs structures font l'objet d'articles et de batailles scientifiques, et qu'en cherchant bien dans le net, je finirais par trouver quelques petites informations plus précises, mais je regrette que le site ne soit pas plus bavard.

C'est justement pour ça qu'ils sont « de plus en plus persuadés ».

C'est beau la science quand on y pense. :/

C'est parce que le moteur de linuxfr ne parvient pas à afficher correctement le script xslt, et duplique une partie du script. Comme indiqué ci-dessus « il faut couper au premier /xsl:stylesheet », c'est à dire supprimer tout ce qui n'est pas coloré par le moteur de linuxfr, de sorte que le script ne comporte que 34 lignes.

Je viens de ré-essayer, ça marche très bien.

Ah, et j'oubliais: il faut rajouter un nœud racine au fichier, comme dit ci-dessous.

C'est parce que le fichier xml donné en exemple est mal construit: il n'a pas de nœud racine, de sorte que le parseur y trouve deux nœuds racines (les deux <Host name="...">). Il faut y rajouter un nœud racine qui encadre tout le fichier (du genre <xml>...</xml>).

xslt c'est le mal absolu, mais pour parser du xml, ça reste pratique. Pour éviter xslt, je crois qu'il n'y a pas d'autres choix que d'éviter xml…

Ce script xslt fait le travail. Il s'utilise avec xsltproc (généralement installé par défaut) ainsi:
xsltproc script.xslt fichier.xml

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">


<xsl:output method="text"
  encoding="UTF-8"
  indent="no"/>

<xsl:strip-space elements="*"/>

<xsl:template match="title">
  
  <xsl:value-of select="../../@name"/>
  <xsl:text>;</xsl:text>
  
  <xsl:value-of select="../@ID"/>
  <xsl:text>;</xsl:text>
  
  <xsl:value-of select="../@niveau"/>
  <xsl:text>;</xsl:text>
  
  <xsl:apply-templates/>
  
  <xsl:text>&#xa;</xsl:text>
</xsl:template>



<xsl:template match="plugin"/>
<xsl:template match="text"/>
<xsl:template match="factor"/>

</xsl:stylesheet>
  <xsl:value-of select="../../@name"/>
  <xsl:text>;</xsl:text>
  
  <xsl:value-of select="../@ID"/>
  <xsl:text>;</xsl:text>
  
  <xsl:value-of select="../@niveau"/>
  <xsl:text>;</xsl:text>
  
  <xsl:apply-templates/>
  
  <xsl:text>&#xa;</xsl:text>
</xsl:template>



<xsl:template match="plugin"/>
<xsl:template match="text"/>
<xsl:template match="factor"/>

</xsl:stylesheet>

PS: Visiblement, linuxfr n'aime pas xml non plus… Il faut couper au premier /xsl:stylesheet, et peut-être qu'il est possible de retrouver les commentaires dans les sources de la page web…

Tu veux dire hash( nouveau mot de passe + nom du site), c'est ça ?

Oui, c'est ça.

Pour le sel, je vois moins l'intérêt, la probabilité d'une attaque par rainbow table étant faible :)

Quant à moi, je ne vois ni l'intérêt du sel, ni l'intérêt d'utiliser deux mots de passe, ni l'intérêt du pré-hash. D'où ma question.

Pourquoi un sel sur le hash et pas sur le tout (hash + nom du site) ? il y a une raison à cela ?

J'avoue pour ma part ne même pas comprendre pourquoi ne pas se contenter d'un hash du nouveau mot de passe + nom du site…

Est-ce que quelqu'un aurait la gentillesse d'éclairer ma lanterne?

Pour le pdf je ne sais pas, mais pour le postscript, c'est à vue de nez de l'ordre d'une vingtaine de lignes par page. Il est vrai que ces vingt lignes deviennent significatives s'il s'agit d'afficher vingt lignes de texte à chaque fois…

Mais j'aurais tendance à croire que ce sont surtout les fontes incluses et les images qui pèsent lourd dans un pdf, et pour le coup, la taille des pages n'y changera rien.

Il y a aussi la plupart des articles de sciences humaines produits par l'université française qui finissent par être publiés sur http://revues.org, dont l'html et très structuré et facilement filtrable, qui propose l'accès au format pdf, et qui propose sous conditions l'accès aux sources xml-tei.

• Au début était RunOff, sur multics (son créateur disait: « I'll run off a copy »).
• Il a été porté sur unix, et renommé Roff.
• Puis Kernighan l'a ré-écrit en C, et pour lui permettre de produire des textes destinés tant aux écrans qu'aux imprimantes, et l'a divisé en deux: Nroff (New Roff, pour les terminaux), et Troff (Typesetter Roff, pour les formats d'impression).
• Avec l'éclatement d'unix dans les années 80, diverses versions de [N|T]roff circulent, basées sur la version de Kernighan.
• Puis Gnu est arrivé, et James Clark lui a écrit une version libre de Nroff et Troff: Groff.
• Puis plan9 est arrivé, et Kernighan a modifié sinon ré-écrit [N|T]roff pour plan9.
• Vers 2005, Solaris est libéré, et avec lui sa version de [N|T]roff héritée d'Unix.
• Gunnar Ritter forke cette version pour créer Heirloom [N|T]roff. Il y ajoute les algorithmes typographiques qui manquent aujourd'hui à Groff.
• Utroff dépend de Heirloom Troff. Il ne touche pas à [N|T]roff même, mais aux logiciels et aux macros qui tournent autour, d'abord et avant tout pour utiliser ses fonctionnalités typographiques.

La question est donc: pourquoi Gunnar Ritter a forké le Troff de Solaris plutôt qu'il n'a amélioré Groff ? Je suppose que c'est parce qu'il a été un utilisateur sinon développeur d'unix propriétaire pendant un temps, et qu'il a voulu se plonger dans le code des outils Unix.

Pour ma part, j'ai rencontré Troff via le projet Heirloom, et comme c'était un peu compliqué pour moi au début, j'ai d'abord utilisé Groff. Mais mon cœur penchait pour Heirloom Troff. J'ai vite compris que Werner Lemberg ne donnerait pas à Groff les fonctions typographiques d'Heirloom Troff, aussi, lorsque je me suis senti assez solide techniquement, j'ai fait le saut vers Heirloom Troff.

Il manque à Groff ce soin du détail en typographie, mais il a plein d'avantages sur Heirloom Troff, en particulier sa facilité d'usage, mais aussi une bien meilleure gestion des dessins et de la couleur, et le fait que tous les pré-processeurs (pic, eqn, tbl) sachent produire de l'xml. Il est aussi mieux documenté, et il a une communauté vivante et très expérimentée. Enfin, il y a fort à parier que son code source soit bien plus lisible.

Et d'une manière générale, vous en pensez quoi de ces unix propriétaires ?

à vous écouter tous les trois (Thierry Thomas, Ecran Plat, Michaël), il y avait de l'unix partout, et il y en a encore. Je dois donc être aveugle pour n'en avoir jamais vu. Et je dois être sourd pour n'en avoir jamais entendu parler.

Venons-en aux faits s'il vous plaît: Si demain je veux voir un (vieil) unix propriétaire toujours en service, je vais où ? À la sncf ? À la poste ? À la caisse de carrefour ?

Ceci dit, OSEF, on avait toujours de l’UNIX sur nos serveurs.

Quel unix ? Pour servir quoi ? Chez qui ?

Je me suis toujours demandé quelles boites avaient utilisé des unix propriétaires en france et pour quoi faire.

Et c’est sans doute la fin des UNIX propriétaires : qui irait déployer de l’AIX, du Solaris ou de l’HP-UX ? (sauf raison de compatibilité / historique)

Pareil, je suis toujours en train de me demander s'il y a encore en france des boites qui utilisent des unix propriétaires et pour quoi faire.

Merci, mais je ne vois pas bien comment faire… Le seul lien qui me semble pertinent me demande de créer un compte gmail, et je n'ai pas l'impression que le dépôt svn soit ouvert en écriture (et si c'est le cas, ce ne serait pas du luxe de m'indiquer la commande qui va bien, car je n'ai jamais utilisé svn).

Sinon je n'ai pas trouvé de formulaire de contact sur ton site.

Je suis un peu old school, et j'ai indiqué une adresse mail dans les readme et les manuels: help, chez utroff (.org).

J'ai fini la première version du filtre d'export de txt2tag vers le format utmac. Où puis-je la publier?

J'ai du faire plusieurs choix d'implémentation, dont je crois qu'il faudrait discuter.

La voilà (version non modérée par l'équipe de DLFP) :

.H1 Utroff: la renaissance de Troff
.PP
Troff est un vénérable logiciel de formatage de texte hérité
d'Unix. Plusieurs versions de Troff coexistent aujourd'hui,
dont celle du
.LP "projet Heirloom" ,
.LU http://heirloom.sourceforge.net
qui a ajouté à Troff des fonctionnalités typographiques
modernes. Dans l'esprit du projet Heirloom,
.LP Utroff
.LU http://utroff.org
retravaille l'ensemble des logiciels qui accompagnent Troff
pour nous permettre d'utiliser efficacement celui-ci
aujourd'hui.
.PP
Pour la sortie de la première version publique d'Utroff,
cette dépêche propose une réponse aux deux questions que
vous ne manquerez pas de vous poser: «pourquoi utiliser
Troff aujourd'hui?», et «pourquoi choisir Utroff?».
.PP
.LP "Le site d'Utroff"
.LU http://utroff.org
.br
.LP Utroff-0.1.tar.gz
.LU http://download.tuxfamily.org/utroff/pub/utroff-0.1.tar.gz
.br
.LP "Journal annonçant la beta d'Utroff"
.LU https://linuxfr.org/users/sygne/journaux/utroff-est-publie
.br
.LP "Dépêche sur l'histoire de Troff"
.LU https://linuxfr.org/news/a-la-recherche-des-sources-de-troff
.
.
.
.
.H1 Pourquoi utiliser Troff aujourd'hui?
.H2 Le logiciel libre et le projet Heirloom
.PP
Alors que logiciel libre est généralement plébiscité pour des
raisons techniques ou éthiques, le
.LP "projet Heirloom" ,
.LU http://heirloom.sourceforge.net
dont Utroff est largement inspiré, a ceci de singulier qu'il
utilise les libertés offertes par les licences libres pour
des raisons esthétiques et nostalgiques. Le but du projet
Heirloom n'est pas tant de donner à l'utilisateur plus de
libertés ou de meilleurs outils que de lui offrir un petit
moment de nostalgie en lui permettant d'utiliser les bons
vieux outils d'Unix. Ce n'est pourtant pas un musée du
logiciel, mais une mise à jour des outils d'antan:
.PQ
«The Heirloom Project is not a software museum\|; it does not
attempt to preserve utilities unmodified. Rather, it keeps
stylistic, algorithmic, and interface aspects intact while
modernizing the framework as appropriate.»
.PP
Ainsi, par delà cette nostalgie, le projet Heirloom montre que
ces antiques outils conservent des qualités non négligeables
aujourd'hui, de sorte que ce projet nous invite à
reconsidérer notre point de vue sur le progrès en matière
informatique.
.
.
.H2 L'ergonomie d'Unix et le langage
.PP
L'ergonomie d'Unix consiste, selon certains, à utiliser le
.LP "langage comme interface" ,
.LU http://theody.net/elements.html
et Troff exploite mieux que tout autre logiciel cette
ergonomie: à chaque format de données (équation, diagramme,
table, référence...) correspond un
.LP mini-langage .
.LU http://www.faqs.org/docs/artu/ch08s02.html#id2934197
Ainsi Troff s'utilise en passant le fichier source à travers
de multiples filtres qui interprètent chacun de ces
mini-langages.
.PP
À l'usage, il apparaît que l'interface langagière qui est
celle d'Unix est particulièrement adaptée au travail des
textes. En effet, outre qu'elle nous donne accès à des
possibilités technologiques, cette ergonomie structure la
pensée. En apprenant à utiliser l'outil, on apprend quelque
chose sur la structure des données qu'on manipule, et
corrélativement, la pensée découvre de nouvelles façons de
se structurer en découvrant de nouvelles structures
symboliques. La pratique d'une interface texte aiguise ainsi
le regard analytique que l'on doit porter sur le texte. Il y
a donc un plaisir et un intérêt, pour qui aime l'analyse des
textes, à travailler avec ces vieux outils pensés pour la
ligne de commande.
.
.
.H2 La philosophie Unix et la question de la maîtrise
.PP
Le logiciel libre se donne pour objectif d'offrir à
l'utilisateur la possibilité de maîtriser son outil
informatique. Mais dans les faits, la complexité des
logiciels d'aujourd'hui fait qu'il est difficile de mettre
en pratique ces libertés de droit. Il se trouve que les
vieux outils Unix souffrent moins de cette difficulté:
marqués par l'idée «un programme, une tâche», ils sont
construits à la manière d'un ensemble de multiples petits
logiciels, aux dépendances minimales, et sont pour cela bien
plus faciles à modifier que leurs équivalents contemporains.
Ainsi, Troff est le seul logiciel de formatage de texte que
je sois capable de maîtriser parfaitement.
.PP
Si Troff est susceptible d'être maîtrisé, ce n'est pas
seulement parce qu'il est accompagné d'un ensemble d'outils
hackables, c'est aussi parce que c'est un langage simple et
bien documenté. La
.LP "documentation exhaustive de Troff"
.LU http://heirloom.sourceforge.net/doctools/troff.pdf
est claire et ne dépasse pas les soixante pages, quant au
langage, quoi que sa syntaxe puisse paraître étrange, il est
tout à fait accessible, même aux débutants en programmation.
.
.
.
.H1 Pourquoi choisir Utroff?
.H2 Le détail en typographie avec Heirloom Troff
.PP
Deux algorithmes permettent de composer des textes avec un
rendu typographique de qualité: l'ajustement paragraphe par
paragraphe, qui calcule l'espace inter-mots sur l'ensemble
du paragraphe plutôt que ligne après ligne, et la
micro-typographie, qui modifie d'un ou deux pour cent la
taille des glyphes pour uniformiser visuellement l'espace
inter-mots. Ces algorithmes ont été créés pour Tex et PdfTex,
puis repris par les logiciels de PAO du marché, mais aussi
par
.LP "Heirloom Troff" .
.LU http://heirloom.sourceforge.net/doctools.html
C'est bien parce que Heirloom Troff incorpore ces
algorithmes qu'il produit des textes dont la qualité
typographique est, potentiellement, équivalente à celle de
LaTex.
.PP
Cependant, Heirloom Troff ne fournit aucune macro qui
permette d'utiliser ces algorithmes simplement. C'est
d'abord pour combler ce manque que Utroff a été
créé.
.
.
.H2 La simplicité des macros Utmac
.PP
S'il est possible de composer un document en Troff pur, il
est bien plus simple d'utiliser des macros qui définissent
le format des éléments les plus fréquents et s'occupent de
la mise en page.
.LP Utmac ,
.LU htpp://utroff.org/tmac.html
l'ensemble de macros créées pour Utroff, suit quelques
principes ergonomiques:
.PI
Toutes les macros utilisent le même langage, de sorte qu'un
même document peut être exporté en plusieurs formats et
selon plusieurs mises en page, sans qu'il soit nécessaire
d'en modifier les sources. Les formats d'export sont:
postscript (donc pdf), README, man, xml, html, fodt,
markdown et tty (en cours). Deux mises en page sont
actuellement disponibles: l'une est dédiée aux textes
littéraires longs (les thèses), et l'autre à la
documentation technique. Une macro dédiée aux lettres et aux
CV est en cours de création.
.PI
Les macros gèrent d'office les besoins les plus fréquents:
sommaire, table des matières, liens internes, index,
références, coloration syntaxique, recto-verso.
.PI
Outre qu'elles utilisent les algorithmes d'Heirloom Troff
dédiés à la typographie, elles respectent les bonnes
pratiques en matière de mise en page: principe de grille,
principe de ligne, et ortho-typographie. Elles repèrent et
mentionnent veuves et orphelines et fournissent des outils
pour les faire disparaître.
.PI
Elles n'ont que peu d'options de configuration. D'une part
parce que leur mise en page est censée être adaptée au
besoin, et d'autre part parce parce qu'il est considéré que
pour un besoin spécifique, la bonne pratique consiste à
créer une macro spécifique, généralement en adaptant une
macro existante.
.PP
Le format des macros est documenté dans le
.LP "manuel d'Utmac" .
.LU http://utroff.org/man/utmac.html
.
.
.H2 Le formatage des références bibliographiques avec Refer
.PP
Il existe une norme internationale définissant la structure
que doivent avoir les références bibliographiques, qu'elles
soient indiquées en bas de page ou en fin d'ouvrage: la
norme
.LP ISO-690 ,
.LU http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=43320
dont Rositza Kyheng propose un
.LP résumé .
.LU http://www.revue-texto.net/Reperes/Themes/Kyheng_References.html
Largement ignorée, souvent confondue par les
universitaires avec une norme réservée aux bibliothèques,
cette norme est néanmoins la seule qu'éditeurs et
universitaires devraient respecter. Refer, le logiciel
dédié au formatage des références bibliographiques,
a été modifié pour qu'il puisse respecter cette norme. En
particulier, puisque la norme ne fait que définir l'ordre
des champs, c'est l'algorithme de tri des références qui a
été adapté.
.PP
À ces modifications s'ajoutent une macro (u-ref), incluse dans les
macros Utmac, offrant la possibilité d'utiliser proprement
une police contenant de vraies petites capitales, la gestion
des champs dédiés aux références électroniques (url, format,
date de consultation...), le remplacement par «idem» ou «op.
cit. p.\~xx», et la distinction entre notes de bas de pages
et liste bibliographique de fin d'ouvrage.
.PP
Consulter le
.LP "manuel de refer" 
.LU http://utroff.org/man/refer.html
et celui de la macro
.LP u-ref .
.LU http://utroff.org/man/u-ref.html
.
.
.H2 Le grec polytonique avec Tchars, inspiré de Dchars
.PP
Les plus assidus d'entre-vous auront suivi
.LP "le développement de Dchars" ,
.LU https://linuxfr.org/news/dchars-pour-lire-ecrire-et-modifier-des-caracteres-unicodes-complexes
de notre ami
.LP "Xavier Faure" ,
.LU https://linuxfr.org/users/suizokukan
qui interprète du code ascii pour produire des caractères
utf8 complexes. Utroff méritait d'avoir un tel interpréteur,
mais ne pouvait se permettre d'ajouter python à ses
dépendances. J'ai donc écrit un tout petit interpréteur en
C, et l'ai nommé Tchars (Troff|Translate Characters) en
référence à Dchars.
.PP
Un récent
.LP journal
.LU https://linuxfr.org/users/sygne/journaux/jouons-avec-unicode-tchars-un-dchars-pour-troff
explique les détails de cette implémentation, quant à
son utilisation elle est documentée dans le
.LP "manuel de Tchars" .
.LU http://utroff.org/man/tchars.html
.
.
.H2 Les index avec Idx
.PP
Le travail d'indexation ne se limite pas à l'indexation du
document en cours d'écriture, il concerne aussi l'indexation
d'ouvrages de référence, dont bien souvent aucune version
électronique n'est disponible. Idx est un script awk
encapsulé dans du shell facilitant grandement l'indexation
de textes papiers, et réalisant l'indexation des documents
Troff.
.PP
Un journal propose
.LP "exemple d'utilisation d'idx" 
.LU https://linuxfr.org/users/sygne/journaux/exemple-d-interface-en-ligne-de-commande
(attention, l'interface a évolué depuis),
et son utilisation est documentée dans le
.LP "manuel d'idx" .
.LU http://utroff.org/man/idx.html
.
.
.H2 La coloration syntaxique avec Ugrind
.PP
Voici le genre le commentaires que l'on trouve dans les
sources des logiciels qui accompagnent Troff:
.vS C
/*
 * Vfontedpr.
 *
 * Dave Presotto 1/12/81 (adapted from an earlier version by
 * Bill Joy)
 *
 */
.vE
.PP
Au début des années 80, alors qu'il travaillait encore à
l'université de Berkeley,
.LP "Bill Joy"
.LU http://fr.wikipedia.org/wiki/Bill_Joy
a donc trouvé nécessaire d'ajouter un colorateur syntaxique
à Troff. Il a pour cela créé Vfontedpr, que les
membres de la liste de discussion de Groff comprennent comme
signifiant «Visual Font Edit Print», un outil en C appelé
par le bien nommé script Vgrind (la moulinette qui grince).
Après bien des péripéties, Vgrind s'est retrouvé dans
l'archive d'Heirloom Doctools, de sorte que, Vfontedpr,
renommé Ugrind pour le projet Utroff, continue à colorer le
code source pour Troff depuis plus de 30 ans.
.PP
Signe de son age avancé la syntaxe de son fichier de
configuration (vgrindefs, renommé ugrindefs pour Utroff) où
sont définies la structure des langages à colorer, est celle
de Termcap:
.vS C
/*
 * grindcap - routines for dealing with the language
 * definitions data base
 * (code stolen almost totally from termcap)
 */
.vE
.PP
Puisque qu'il fallait à tout le moins qu'Ugrind puisse
colorer le sources en Troff, et puisque la syntaxe de Troff
est difficilement interprétable dans le langage de Termcap,
Ugrind contient, entre autres modifications de Vfontedpr, un
parseur codé en dur du langage Troff.
.PP
Le
.LP "manuel d'ugrind"
.LU http://utroff.org/man/ugrind.html
décrit son utilisation.
.
.
.H2 L'export vers l'xml
.PP
Troff a commencé à péricliter au moment ou apparaissait le
web, l'html et l'xml. Il y a probablement là un lien causal:
de nombreux scripts ont été créés pour produire de l'html à
partir de Troff, mais aucune solution universelle n'a jamais
été trouvée. En effet, seules les macros créées en langage
Troff peuvent être interprétées en tant que c'est en leur
sein qu'est définie la sémantique du texte. De fait, il y a
autant d'interpréteur que de macros, et chaque interpréteur
doit pouvoir en outre comprendre quelques fonction Troff
susceptibles d'être utilisées dans les fichiers sources.
.PP
Finalement,
.LP "Eric.\~S. Raymond"
.LU http://fr.wikipedia.org/wiki/Eric_Raymond
a su imposer
.LP doclifter ,
.LU http://www.catb.org/~esr/doclifter
un interpréteur en python, qui reste néanmoins réservé aux
macros historiques.
.PP
Une solution n'a pas été explorée jusqu'alors: si Troff
produit des fichiers postscripts, son grand frère, Nroff
produit des fichiers textes, de sorte qu'il peut produire
des fichiers xml sans en passer par un interpréteur. De fait
l'une des macros Utmac a été écrite pour gérer l'export vers
l'xml avec Nroff. Toutes les fonctions du langage Troff sont
ainsi gérées nativement, et, si cette solution ne répond pas
à tous les besoins, elle a l'avantage d'être très simple à
mettre en œuvre.
.PP
Le site d'Utroff explique cette
.LP "conversion vers l'xml" .
.LU http://utroff.org/xml.html
.
.
.H1 Remerciements
.PP
Utroff est hébergé par
.LP Tuxfamily ,
.LU http://tuxfamily.org
et son développement a bénéficié de l'aide de quelques
LinuxFr-iens:
.LP MrSpackMan , 
.LU https://linuxfr.org/users/mrspackman
.LP "fmaz fmaz" ,
.LU https://linuxfr.org/users/fmaz
et
.LP "Xavier Faure" ,
.LU https://linuxfr.org/users/suizokukan
déjà cité. Qu'ils soient tous remerciés.
.H2 Post Scriptum
.PP
Dépêche rédigée avec Utroff:
.vS sh
ugrind utroff-0.1.tr | nroff -muw > utroff-0.1.mkd
.vE

:)

Heureusement que tu es là, et que, contrairement à moi, tu lis autrement qu'en diagonale.

Je regarde tout ça, et je reviens vers toi. Il va me falloir un peu de temps…

La gestion fine des polices va être un peu compliquée. J'ai regardé vite fait comment l'export vers mom gère ça, et il me semble qu'il ne gère pas l'emboitement…

underline et strike: on peut bricoler quelque chose, mais je crais que ça ne fonctionne pas bien si un saut de ligne survient au milieu. L'idéal serait que ça ne dépasse pas un mot, ou alors faire en sorte que txt2tag le gère lettre après lettre. Plus fondamentalement, on touche là à une différence de philosophie: j'ai tendance à croire que plutôt que la forme graphique, c'est la sémantique qu'il faudrait traduire. En gros, on pourrait dire italique et teletype, ou bleu et rouge.

C'est pas vraiment évident dans (t)roff de savoir quel est le socle commun entre différentes macros, et voir ce qui diffère.

Historiquement, les commandes troff sont composées de deux lettres minuscules, et par convention, les majuscules sont réservées aux macros. Mais il y a plein de nuances.

Je m'y perd un peu entre les déclarations avec un point et les autres avec un anti-slash.

Les séquences d'échappement s'utilisent en milieu de ligne. Ce sont soit des raccourcis commodes pour des commandes, soit des fonctions de dessin.

bah …

Heureux de te revoir !

Mille merci ! Et je suis très heureux de voir que ça fonctionne.

export TROFFFONTS='/usr/share/fonts/opentype/linux-libertine/'

J'ai trouvé le problème: j'ai mis un F de trop, il faut écrire TROFFONTS. [edit: grilled]

Suite à tes remarques, je vais effectivement ajouter un script shell qui initialise les variables d'environnement, et qui va chercher les exécutables dans le bon répertoire, pour que ça puisse fonctionner sans configuration.

Quant à Heirloom doctools, je préfère me contenter de distribuer un fichier de configuration adapté à utroff, et un guide d'installation. J'ai beaucoup de respect pour le projet Heirloom.

Je vais aussi modifier la gestion des polices, pour éviter le bug que tu as rencontré.

Dis moi, puis-je mentionner ton pseudo « Fravashyo » dans les logs, ou préfères tu que je mentionne un autre pseudo ou ton vrai nom ?

PS: Textallion, mais oui bien sur ! J'ai vu les dépêches, mais sans grand amour pour Latex, je ne me suis jamais vraiment penché dessus… Mais où est passé f*******n ?

Il me semble qu'il manque aussi de quoi obtenir les licenses. En tout cas ni make pub, ni cd share; make ne fonctionnent chez moi.

Les licences sont présentes dans chacun des sous-répertoires (idx/bsd2-LICENSE par ex.), ce qui me semble plus simple pour s'y retrouver. Quant à la commande make pub, elle ne fait sens que pour l'archive de développement (utroff.tar.gz). Le README n'est probablement pas assez clair sur ce point.

S'il s'avère que tu doives reconstruire l'archive – s'il te plait – incrémente son numéro de version.

Je ne suis, décidément, pas familier avec les usages en matière de versionnement, et j'étais loin d'imaginer qu'une modification de la seule archive méritait d'être versionnée. Mais il est vrai que ça fait sens. Je vais pousser une nouvelle version bientôt, avec un README plus clair, un tutoriel d'installation, et une gestion moins sujette à erreur des macros de polices.

Je vous remercie tous pour vos tests, car c'est très difficile pour moi de faire comme si je découvrais l'archive et l'installais naïvement. Vous mettez en évidence tout un ensemble de petites choses que je ne voyais pas, et qui méritent d'être corrigées.

La réponse est dans la faq de Haiku:

Linux-based distributions stack up software […]. This lack of consistency and overall vision manifests itself in increased complexity, insufficient integration, and inefficient solutions, making the use of your computer more complicated than it should actually be.

Instead, Haiku has a single focus on personal computing and is driven by a unified vision for the whole OS. That, we believe, enables Haiku to provide a leaner, cleaner and more efficient system capable of providing a better user experience that is simple and uniform throughout.

Toute l'intérêt de Haiku réside donc dans la façon dont il assemble Gnu coreutils, python, la pile wifi de Free BSD, et puis aussi les ports de gnome, QT et X11 : c'est un beau bazar, mais il faut voir que, à la différence de linux, c'est un beau bazar avec une vision unifiée de l'os tout entier.

Voilà, il suffisait de demander.

=>[]

/opt/hlm/bin/troff: font:text: no such request;

Ah, là, l'erreur est de mon fait: si la variable d'environnement UTMAC est définie, les macros uh et us ne chargent aucune police, considérant qu'il revient à la macro locale de le faire. C'est là la solution que j'ai trouvée pour permettre à tout un chacun de choisir des polices particulières.

Il faut donc que tu charges la macro u-libertine dans le fichier ~/.utmac:

.so \V[TROFFMACS]/u-fr
.so \V[TROFFMACS]/u-libertine

Quant à moi, il faut à tout le moins que je documente ce comportement, ou que je m'arrange pour que ça fonctionne quand bien même l'utilisateur final ne charge aucune police.

can't open file ~/.utmac;

Je me souviens maintenant avoir rencontré ça moi aussi. Bug ou feature, je n'en sais rien, il est fort possible que le raccourci ~ soit plus récent que Troff… Il faudrait là aussi que je le documente, et que j'en parle upstream.

Enfin, suite à ton précédent commentaire, j'ai reconstruit l'archive d'utroff-0.1, car les sources du fichier de démonstration avaient été oubliées. Plus généralement, je crois qu'un tutoriel d'installation un peu détaillé serait bienvenue…

C'est chouette d'avoir un beta-testeur si patient que toi !

troff: fatal error: can't find macro file uh

Aah, on entre dans le vif du sujet !

Tu n'as probablement pas défini la variable d'environnement TROFFMACS, nécessaire à heirloom troff: export TROFFMACS='/usr/local/share/utroff/tmac/

Il te faut aussi définir la variable d'environnement TROFFFONTS, pour y mettre le chemin vers la police libertine opentype (que tu auras préalablement installé): export TROFFFONTS='/path/to/libertine/dir/'

Tu devrais aussi définir la variable UTMAC, pour charger une macro locale définissant ta langue:

echo "so \\V[TROFFMACS]/u-fr" > ~/.utmac
export UTMAC='~/.utmac'

La macro u-locale distribuée avec les macros utmac est un exemple un poil plus complexe de macro locale.

Te disant cela, je m'aperçois que ces informations importantes mériteraient de remonter en haut du README, car il est vrai que si je les laisse en bas, tout le monde va passer à côté.

less demo.tr | ugrind | refer | troff -muh …

Attention, car selon ce qu'il y a dans ton path, cette commande utiliseras gnu refer et gnu troff, et ça ne marchera pas. Indique les chemins absolus si tu as un doute, simplifie toi la vie en enlevant less, et n'oublie pas les options de la commande refer (ou définit la variable d'environnement REFER):

/usr/local/bin/ugrind demo.tr \
| /usr/local/bin/refer -p biblio.ref \
| /opt/hlm/bin/troff -muh \
| /opt/hlm/bin/dpost \
| ps2pdf - > demo.pdf

À l'avenir, tu pourras configurer ton installation aux petits oignons pour ne plus galérer avec le path.

Jusqu'ici je m'en sors bien, mais je ne serais pas étonné qu'au prochain coup ce soit moi qui doive travailler ;)

heirloom pose des problèmes

Quelle distribution utilises-tu qui n'empaquette pas la suite Heirloom ? Elle est dans debian, archlinux (aur), et NetBSD. J'ai du mal à croire qu'elle ne soit pas présente à peu près partout.

La dépendance de compilation avec heirloom-devtools n'est pas stricte: chez moi heirloom doctools compile très bien avec les outils Gnu de ma distribution. Je viens de réessayer par trois fois.

Je le configure, compile, et installe (dans /tmp/, pour le test) ainsi:

mv mk.config mk.config.bak
echo "
PREFIX=/tmp/hlm/
BINDIR=\$(PREFIX)/bin
LIBDIR=\$(PREFIX)/lib
PUBDIR=\$(PREFIX)/pub
MANDIR=\$(PREFIX)/man
MACDIR=\$(LIBDIR)/doctools/tmac
FNTDIR=\$(LIBDIR)/doctools/font
PSTDIR=\$(FNTDIR)/devpost/postscript
TABDIR=\$(LIBDIR)/doctools/nterm
HYPDIR=\$(LIBDIR)/doctools/hyphen
REFDIR=\$(LIBDIR)/reftools
INSTALL=/bin/install
EUC=-DEUC
STRIP=strip -s -R .comment -R .note
CC=cc
CCC=c++
CFLAGS=-O
CPPFLAGS=-D_GNU_SOURCE
LDFLAGS=
LIBS=
SHELL=/bin/sh
RANLIB=(hash ranlib) >/dev/null 2>&1 || exit 0; ranlib
" >> mk.config

make
make install
# pour créer un paquet:
# make ROOT="/tmp/paquet/" install

Si tu veux faire simple, tu configures Utroff de la même façon. Lors de l'installation, Utroff écrasera heirloom refer et heirloom soelim, mais normalement, tu gagnes au change :).
Pour utiliser les outils d'heirloom et d'utroff sans ruiner ton path, utilises ce petit script, nommé h:

#! /bin/sh

# h: run heirloom binaries.
# usage:
# h troff f.tr | h dpost | ps2pdf - > f.pdf

HLM=/tmp/hlm/bin/

$HLM/$@

Si tu es content, tu recompiles et installes tout avec, plutôt que /tmp/hlm/ comme prefixe, /opt/hlm/ ou n'importe quel autre répertoire de ton choix.