Je pense à ce genre d'outils, oui, bien que je ne connaisse ni rdoc, ni ruby. L'essentiel étant de pouvoir produire html et pages man.
Je reçois déjà beaucoup de mail avec beaucoup de SPAM … :(
Je t'avoue que pour l'instant, l'adresse publique de mon projet est épargnée, ce qui me laisse croire que les spammeurs ont des moyens plus efficaces de collecter des adresses courriels que d'aller les chercher dans les archives des projets logiciels. Au pire, tu peux utiliser un de ces filtres antispam qui s'intègrent aux lecteurs de mail. Au pire du pire, tu peux indiquer dans le readme qu'il faut insérer tel ou tel mot clé dans le sujet du mail, et filtrer tes mails ainsi.
Je sais, c'est pour ça que je me renseigne à l'avance, je préfère partir sur de bonnes bases plutot que de devoir me poser ces questions plus tard.
J'ai eu la même réaction que toi. On m'a proposé les mêmes logiciels qu'à toi. Mais au final, la bonne solution, fut celle que je me suis construite sur mesure. Tout cela, ce n'est pas seulement la vitrine de notre projet, c'est aussi et surtout notre environnement de travail. Il faut qu'on ait du plaisir à travailler avec ces outils, et qu'on les maîtrise suffisamment pour pouvoir travailler correctement. Architecturer l'environnement de travail de son projet, ça fait partie du projet. Et je crois que c'est aussi un acte d'invention et de création.
Pense par exemple que make (rake dans ton cas), peut servir à produire ton site, ta doc et tes archives, comme il sert à compiler les sources. Ah, et n'oublie pas de versionner la doc avec les sources.
Je me demande si ce que tu cherches est bien proportionnel à l'envergure de ton projet. Pour avoir bugtracker complet, site, wiki, et blog, il faut déjà avoir une bonne communauté autour du projet. S'il y a déjà une communauté, autant lui demander de l'aide pour mettre en place ces outils, qui demandent tous du temps à administrer.
Si ton projet est naissant, les outils les plus importants sont de loin le gestionnaire de version, et, àmha, le gestionnaire de documentation. Un gestionnaire de documentation bien fait devrait te permettre de créer des pages html statiques comme des pages de manuel: c'est suffisant pour faire un site. Ces outils sont finalement assez rares. Je te conseille d'utiliser en priorité l'outil écrit dans le langage de programmation de ton projet: ce sera mieux intégré, et tu sauras le modifier si besoin.
Pour la communauté, une adresse mail, indiquée dans le README, suffit largement au début, tant pour les rapports de bogues, les demandes d'informations, que les patchs. C'est en outre bien plus convivial qu'un bug tracker: tu recevras quelques mots d'encouragement en plus des contributions. Il faut juste prendre soin d'indiquer pour chaque commit qui est à l'origine du rapport de bogue, de la requête ou du patch, pour garder des traces claires et publiques des contributions.
À titre d'exemple, pour mon projet Utroff, j'utilise troff lui-même pour produire toute la documentation (documentation gérée par les outils appropriés au langage de programmation), mon gestionaire de version est local (RCS), il y a une adresse mail pour les discussions, et un compte twitter (mort) pour les nouvelles. Mettre en place tout cela, et faire des archives propres (avec readme, licence, changes, manuel) prend déjà beaucoup, beaucoup, beaucoup de temps.
quel bilan faites-vous de vos contributions au libre ? Où trouvez-vous votre satisfaction ?
Le libre, pour moi, c'est ce qui m'a appris à coder. J'ai été fasciné par un manuel distribué dans le live cd de knoppix, qui expliquait ce qu'était un fichier de configuration textuel. Du coup, j'ai appris à comprendre mon système en l'explorant via le navigateur de fichier, et petit à petit j'ai appris le bash, python, html et css, et un peu de sql. Et trouvant que j'apprenais beaucoup, j'ai eu envie de contribuer moi aussi. D'abord par des conseils sur le forum d'ubuntu, puis sur celui de la naissante slitaz, puis avec un peu de code à l'arrache pour slitaz.
Mon engagement était très instable à l'époque : je changeais souvent de projet, travaillais beaucoup sur des logiciels avec lesquels j'apprenais à coder et que je ne publiais jamais.
Et puis j'ai découvert troff. Autour de ce langage, s'articulent ma passion pour le texte et les livres, et celle découverte avec le libre pour l'algorythmie, l'architecture logicielle, et la philosophie Unix. M'y trouvant chez moi, je me suis d'abord dit que si je maintenais un jour un projet personnel, ce serait autour de troff. Et finalement, je me suis jeté à l'eau, et le résultat, en version bêta, est maintenant public : utroff.
Et c'est incroyable le plaisir que je prends à travailler sur ce projet. J'apprécie en particulier la liberté incroyable qu'offre un petit projet personnel. J'apprécie aussi la difficulté des énigmes qu'il me pose. J'apprécie en outre le fait qu'il m'oblige à me documenter sur nos vieux outils et usages hérités d'Unix.
Sinon, je m'étonne que ce journal soit passé en dépêche. Le journal en question est relativement bien noté, mais je trouve que l'auteur a une grosse part de parti pris […]
Franchement, attendre des dépêches de linuxfr qu'elles soient neutres, c'est comme attendre du canard enchainé qu'il se contente de relayer les annonces de l'afp.
Oui, Patrickg a son avis sur la question, et c'est tant mieux, car sans lui, 1) personne n'en saurait rien, 2) ça ouvre la discussion.
personnellement celui ci ne vaut qu'un envoi direct vers /dev/null
Comme dit ci-dessus, ce genre de scripts est fréquent sur les distributions: Il demande une intervention de l'utilisateur (qui doit le lancer), mais automatise tout le reste.
Et légalement, je trouve cette solution tout à fait satisfaisante. En gros, la documentation indique qu'en lançant ce script, l'utilisateur certifie avoir droit d'installer et d'utiliser les logiciels afférents. Généralement, une fois lancé, le script demande encore à l'utilisateur d'accepter la licence. Cela sert tant pour les bibliothèques soumises à droits dans certains pays que pour les logiciels non redistribuables et donc non empaquetables par la distribution, comme les firmwares de certaines cartes wifi.
Moi non plus je ne comprend pas que Debian relègue encore hors de la distribution toutes ces bibliothèques, indispensables aujourd'hui, et parfaitement légales dans beaucoup de pays.
Je ne comprends pas tous les tenants et aboutissants, de cette histoire, mais àmha, si Debian voulait véritablement régler le problème, il n'y aurait pas besoin d'aller chercher des bibliothèques chez Marillat. Àmha, si Marillat voulait vraiment aider les utilisateurs de Debian, il aurait depuis longtemps milité pour que Debian ait un dépôt officiel pour ces logiciels.
Ce qui fait mal au cœur n'est pas tant le risque de perdre les données accumulées sur le service que les entrelacs de relations que nous avons tissées à travers ces données.
Ne pas exposer ses relations sociales aux aléas des enjeux économiques est une des raisons évoquées par les défenseurs de l'auto-hébergement. Si les relations tissées sur les réseaux sociaux sont si importantes pour les individus, alors il est dans l'intérêt des individus d'avoir une certaine maîtrise de ces réseaux sociaux.
Les personnes, qui, comme toi, ont compris cet enjeu, explorent plusieurs réponses :
les chartes « négociées » par les utilisateurs,
la loi (droit à récupérer ou effacer ses données),
la concurrence,
les réseaux sociaux centralisés alternatifs (basés sur des logiciels libres, gérés par une association…),
les réseaux sociaux décentralisés.
Tu vois bien, j'imagine, comment chaque solution technique s'articule avec un modèle politique.
Les défenseurs des modèles décentralisés savent bien que c'est une solution technique complexe pour un individu, mais ils considèrent que 1) le jeu en vaut la chandelle, 2) ça ne peut que s'améliorer, 3) au pire les nœuds peuvent être gérés collectivement (associations, amis…).
Il faut vraiment un papier fin ou lire en transparence pour voir le décalage. Je pense que le désagrément est minime en comparaison du gain.
Pas seulement. Lorsque le document est relié il est plus élégant que les lignes soient alignées de la page gauche à la page droite. En outre, dans le cas d'une mise en page en colonnes (par exemple avec des notes marginales), le défaut d'alignement saute aux yeux.
Mais comme beaucoup de bonnes pratiques typographiques, allègrement oubliées durant quelques années, le défaut de celles-ci n'apparaît plus qu'aux yeux un minimum exercés.
Tu considères qu'il faut ajouter des espaces pour les (sous-)sections. Pourtant, ça participe aussi au décalage. Et puis augmenter la taille des polices pour mettre en valeur des titres décale aussi le texte.
En fait, non. Augmenter la taille des polices ne change rien si l'interligne reste le même (du moins avec troff). Quant à l'interligne, c'est l'unité de base du document, toutes les distances y sont proportionnelles, et je ne le modifie qu'en prenant soin de retomber sur mes pieds:
Par exemple, dans la macro uh, les notes marginales ont un interligne tel que trois lignes de notes correspondent à deux lignes de texte: l'alignement est respecté.
Quant aux titres, on peut utiliser des fractions d'interligne pour les séparer du texte, mais dans ce cas, on veille à ce que l'addition de l'espace avant le titre et après le titre forme un nombre entier d'interlignes. Par exemple 1.7 avant et 0.3 après, de sorte que l'alignement est respecté.
Mais tu as raison, pour les listes, cela peut-être problématique. Il faudrait que je me replonge dans mes manuels pour voir quelles solutions ils préconisent.
Encore merci, cela fait longtemps que j'ai les yeux plongés dans ces documents, et je finis par ne plus rien voir. Un regard extérieur est extrêmement bienvenue.
la marge intérieure doit être légèrement plus importante.
En vérité, cela dépend du type de reliure. C'est configurable dans les sources pour l'instant.
En LaTeX, je mettrais un \smallskip
C'est une solution courante, mais mauvaise, car elle contrevient à l'alignement des lignes sur une grille stricte, ce qui devient problématique pour du recto verso, car selon la transparence du papier, on peut voir les lignes du verso entre les lignes du recto.
Espaces verticales après les titres des (sous-)sections
Bien vu, c'était un bug, corrigé maintenant.
La première de couverture […] ne doit pas avoir de numéro de page.
Cf. macro .RP du manuel de utmac :) Pour l'instant, je laisse cela au choix de l'utilisateur, mais cette décision peut changer.
La première de couverture […] ne doit pas avoir […] d'entête et de pied de page. Il faut retirer les traits en bas de page.
Tout cela relève d'un choix esthétique. D'une part, j'avais envie d'une page généralement assez sombre et dense. En outre, comme les manuels sont des documents assez chaotiques, il fallait renforcer la structure de la page, et les lignes le font très bien. J'ai beaucoup tatonné pour la mise en page des documents techniques, et finalement, sans trop y croire, j'ai essayé les lignes épaisses, et j'ai été moi-même surpris que ça fonctionne. Je laisse donc les choses en l'état pour cette macro, quitte à faire mieux avec une autre macro.
C'est particulièrement moche avec les « petites fleurs » qui servent de séparateurs.
Pour le coup, c'est probable. Les fleurs sont la trace d'une ancienne version de la mise en page.
Les titres et sous-titres […] doivent être légèrement plus gros pour être plus mis en valeur.
Oui, cela fait partie de ma todo list.
Trop de choses sont graissées.
Cf. ci dessus. En outre, le gras est hérité des conventions des pages de manuel.
Le lien sur refer.pdf est cassé
Je n'ai pas trouvé de quel lien tu parles. Pourrais-tu préciser s'il te plaît?
PS: j'ai ajouté dans les logs « bug report by fmaz fmaz », est-ce que cette mention te convient ?
quand au moins l'un des items de la liste fait plus de 3em, je préfèrerais qu'ils passent tous à la ligne.
Cela semble idéal, d'autant plus que j'ai fait plusieurs essais comparatifs, et aucune solution ne convient pour l'instant à toutes les situations. Mais c'est en effet un algorythme plus complexe, qui n'a peut-être pas sa place dans cette macro us.
Je n'utilise pas troff, mais ça me fait plaisir de voir un concurrent à LaTeX. […] Je trouve super que tu prenne en compte une série de format de sorti (texte/man, html et pdf).
C'est peut-être la niche inexplorée de troff, qui sait faire de la typographie de détail tout en se rapprochant des générateurs de format comme txt2tag et markdown.
« lastname, firstname » est inliné avec le reste de la référence mais celle-ci est indentée après le passage à la ligne.
C'est une autre macro (**.PB**) qui fait cela. Les lignes suivantes, où, malgré le long tiret, le début des paragraphes est toujours aligné sont mises en forme par la macro .PI.
À ce problème des listes, j'entrevoie maintenant la solution suivante:
soit l'item n'est pas précisé, et dans ce cas un tiret est ajouté, non pas au début de la ligne comme c'est le cas pour l'instant (cf. paragraphe « DESCRIPTION » de ugrind.pdf), mais avec une indentation de 2em. Le texte commençant toujours à 3em.
soit l'item est précisé en argument par l'utilisateur, et dans ce cas il est ajouté en début de ligne (sans indentation, comme dans la liste des options de la même page). Il y a alors deux solutions:
soit l'item est inférieur à 3em, et dans ce cas le texte commence à 3em.
soit l'item est supérieur à 3em, et dans ce cas le texte commence à la ligne suivante.
Je préciserai dans la documentation que la macro .PB donnera de meilleurs résultats que la macro .PI pour les listes dont les items ont une taille oscillant autour de 3em (cf. liste des langages de programmation du manuel d'ugrind).
Encore merci, et si tu as un peu de temps, je lirai avec enthousiasme tes autres remarques.
Je trouve dommage que les sections « NAME », « SYNOPSIS »… soient entièrement en majuscule. Le cas échéant, elles auraient pu si être en petites majuscule.
Les majuscules sont une convention pour les titres des pages de manuel, et le pdf est composé à partir des sources du manuel, d'où les majuscules. Il y aurait plusieurs moyens de forcer l'usage des minuscules lors de la composition des pdf, mais j'hésite encore tant sur le bon moyen technique de faire cela, tant sur la nécessité de le faire (parce qu'il me semble cohérent que même sur le pdf la mise en page ressemble à une page de manuel).
Tes autres remarques concernent les listes. Dans la page que tu cites, c'est la même macro .PI qui gère les listes à tirets du paragraphe « DESCRIPTION », la liste des options dans le paragraphe qui leur est dédié, ainsi que la liste des différents langage de programmation, et, autre cas singulier, les listes bibliographiques, comme p. 9 de demo-us.pdf.
J'ai eu du mal à trouver une façon de faire qui convienne à cette variété de situations, et tu as raison, la solution n'est toujours pas optimale. J'avais essayé l'espace entre les paragraphes, mais ça ne donnait pas de bons résultats. Ne pas aligner les débuts de textes donne des résultats étranges dans certaines situations. En tout cas, tu m'as convaincu d'y réfléchir à nouveau.
J'arrête pour l'instant, je suis sûr que je pourrais trouver encore plein de trucs à critiquer.
Merci pour les louanges, qui sont toujours constructifs, quoi qu'on en dise, car ils donnent du cœur à l'ouvrage. :)
Au niveau rendu, troff c'est équivalent à LaTeX en qualité ?
Au point de vue typographique, à mon avis, oui, étant donné que la version heirloom de Troff reprend l'algorythme de création de paragraphe créé pour Tex par Knuth & Plass cf word wrap, ainsi que l'amélioration micro-typographique de ces algorythmes créée pour PdfTex par Hàn Thế Thành cf micro-typography.
Il y a aussi dans Tex une fonction pour placer les paragraphes dans la page (afin d'éviter veuves et orphelines), que Heirloom Troff ne reprend pas. Cette fonction est de toute manière problématique de mon point de vue, car elle peut conduire à créer des sauts de ligne non proportionnels à la taille de lignes, et du coup, on voit par transparence que les lignes ne se recouvrent pas du recto au verso. Utroff, se contente donc de les indiquer, et fournit des solutions pour les supprimer proprement, mais cela suppose une intervention manuelle.
Au fait, tu utilises toujours Archlinux malgré son tournant que tu regrettais dans un journal d'il y a quelques mois ?
Où je me demande s'il n'y a pas, avec ces questions, une tentative de donner à ce fil de discussion moribond la vivacité d'un bon troll comme on les aime ici…
J'aimerais faire le saut vers NetBSD, dont j'apprécie beaucoup l'esprit, mais comme je suis en train de finir ma thèse, ce n'est pas le bon moment pour chambouler mon espace de travail. Après plusieurs mois de résistance, j'ai donc fait la mise à jour vers systemd la semaine dernière. Le boot est un peu ralenti mais sans grandes conséquences, devenu très laid, mais je ferme les yeux, et /etc/ est bloated, mais il l'était déjà.
Je pensais aux dépêches pour annoncer une version un peu moins bêta. Pour l'instant, tout bouge tout le temps… J'apprécie la proposition, mais je trouve que c'est un peu prématuré.
Considère que si tu payes des impôts et que tu as les moyens de t'acheter un appartement, tu es riche, et tu n'essayes plus de t'en sortir.
C'est immonde de comparer des propriétaires-salariés-imposés qui planquent tout ce qu'ils reçoivent par d'autres voies que celle de leur employeur avec des pauvres qui essaient de s'en sortir.
Autour des questions portant sur livre numérique, à de nombreuses reprises, la bnf c'est illustrée par des positions qui restreignent l'accès du public au livre:
ici, les œuvres orphelines sont englobées dans le système des indisponibles, interdisant de fait leur diffusion hors commerce,
les bibliothèques (hors bnf) se voient obligées de louer l'accès aux indisponibles, ce qui fait que la bnf va à l'encontre de l'intérêt des bibliothèques régionales,
la numérisation des indisponibles (au profit des éditeurs) se fait sur les fonds dédiés à la numérisation des œuvres du domaine public,
ces œuvres du domaines public, lorsqu'elles sont numérisées, retombent sous le giron du droit restreint au nom d'une loi sur les bases de données et sur les archives administratives (et àmha, selon une interprétation de la loi violemment tirée par les cheveux),
la liste est longue, et mériterait une dépêche…
Tout cela est va tellement à l'encontre du projet de la bnf que c'est impossible à comprendre si l'on ne fait pas l'hypothèse d'une corruption de l'institution: plutôt que de travailler à la réalisation de son projet, elle travaille au maintient de ses intérêts propres, pour ne pas dire de ceux des éditeurs en place.
# NetBSD
Posté par Sygne (site web personnel) . En réponse au message Mettre Linux sur un ordinosaure IBM PS/2 modèle 70 - 386. Évalué à 9.
Me semble plus approprié que Linux pour le coup.
Dans la documentation sur i386, se trouve le lien vers la page dédiée à ton PS/2.
Amuses-toi bien !
[^] # Re: De la découverte au projet personnel
Posté par Sygne (site web personnel) . En réponse au journal Une rétrospective sur mes contributions au libre. Évalué à 2.
Merci !
[^] # Re: De la juste proportion
Posté par Sygne (site web personnel) . En réponse au message "Nécessaire" de démarrage pour développement d'un projet libre.. Évalué à 4.
Je pense à ce genre d'outils, oui, bien que je ne connaisse ni rdoc, ni ruby. L'essentiel étant de pouvoir produire html et pages man.
Je t'avoue que pour l'instant, l'adresse publique de mon projet est épargnée, ce qui me laisse croire que les spammeurs ont des moyens plus efficaces de collecter des adresses courriels que d'aller les chercher dans les archives des projets logiciels. Au pire, tu peux utiliser un de ces filtres antispam qui s'intègrent aux lecteurs de mail. Au pire du pire, tu peux indiquer dans le readme qu'il faut insérer tel ou tel mot clé dans le sujet du mail, et filtrer tes mails ainsi.
J'ai eu la même réaction que toi. On m'a proposé les mêmes logiciels qu'à toi. Mais au final, la bonne solution, fut celle que je me suis construite sur mesure. Tout cela, ce n'est pas seulement la vitrine de notre projet, c'est aussi et surtout notre environnement de travail. Il faut qu'on ait du plaisir à travailler avec ces outils, et qu'on les maîtrise suffisamment pour pouvoir travailler correctement. Architecturer l'environnement de travail de son projet, ça fait partie du projet. Et je crois que c'est aussi un acte d'invention et de création.
Pense par exemple que make (rake dans ton cas), peut servir à produire ton site, ta doc et tes archives, comme il sert à compiler les sources. Ah, et n'oublie pas de versionner la doc avec les sources.
Bon courage !
# De la juste proportion
Posté par Sygne (site web personnel) . En réponse au message "Nécessaire" de démarrage pour développement d'un projet libre.. Évalué à 2.
J'avais écrit un journal à ce sujet:
https://linuxfr.org/users/sygne/journaux/publication-de-petits-projets
Il y a plein de remarques intéressantes dans les commentaires.
Je me demande si ce que tu cherches est bien proportionnel à l'envergure de ton projet. Pour avoir bugtracker complet, site, wiki, et blog, il faut déjà avoir une bonne communauté autour du projet. S'il y a déjà une communauté, autant lui demander de l'aide pour mettre en place ces outils, qui demandent tous du temps à administrer.
Si ton projet est naissant, les outils les plus importants sont de loin le gestionnaire de version, et, àmha, le gestionnaire de documentation. Un gestionnaire de documentation bien fait devrait te permettre de créer des pages html statiques comme des pages de manuel: c'est suffisant pour faire un site. Ces outils sont finalement assez rares. Je te conseille d'utiliser en priorité l'outil écrit dans le langage de programmation de ton projet: ce sera mieux intégré, et tu sauras le modifier si besoin.
Pour la communauté, une adresse mail, indiquée dans le README, suffit largement au début, tant pour les rapports de bogues, les demandes d'informations, que les patchs. C'est en outre bien plus convivial qu'un bug tracker: tu recevras quelques mots d'encouragement en plus des contributions. Il faut juste prendre soin d'indiquer pour chaque commit qui est à l'origine du rapport de bogue, de la requête ou du patch, pour garder des traces claires et publiques des contributions.
À titre d'exemple, pour mon projet Utroff, j'utilise troff lui-même pour produire toute la documentation (documentation gérée par les outils appropriés au langage de programmation), mon gestionaire de version est local (RCS), il y a une adresse mail pour les discussions, et un compte twitter (mort) pour les nouvelles. Mettre en place tout cela, et faire des archives propres (avec readme, licence, changes, manuel) prend déjà beaucoup, beaucoup, beaucoup de temps.
# De la découverte au projet personnel
Posté par Sygne (site web personnel) . En réponse au journal Une rétrospective sur mes contributions au libre. Évalué à 5.
Le libre, pour moi, c'est ce qui m'a appris à coder. J'ai été fasciné par un manuel distribué dans le live cd de knoppix, qui expliquait ce qu'était un fichier de configuration textuel. Du coup, j'ai appris à comprendre mon système en l'explorant via le navigateur de fichier, et petit à petit j'ai appris le bash, python, html et css, et un peu de sql. Et trouvant que j'apprenais beaucoup, j'ai eu envie de contribuer moi aussi. D'abord par des conseils sur le forum d'ubuntu, puis sur celui de la naissante slitaz, puis avec un peu de code à l'arrache pour slitaz.
Mon engagement était très instable à l'époque : je changeais souvent de projet, travaillais beaucoup sur des logiciels avec lesquels j'apprenais à coder et que je ne publiais jamais.
Et puis j'ai découvert troff. Autour de ce langage, s'articulent ma passion pour le texte et les livres, et celle découverte avec le libre pour l'algorythmie, l'architecture logicielle, et la philosophie Unix. M'y trouvant chez moi, je me suis d'abord dit que si je maintenais un jour un projet personnel, ce serait autour de troff. Et finalement, je me suis jeté à l'eau, et le résultat, en version bêta, est maintenant public : utroff.
Et c'est incroyable le plaisir que je prends à travailler sur ce projet. J'apprécie en particulier la liberté incroyable qu'offre un petit projet personnel. J'apprécie aussi la difficulté des énigmes qu'il me pose. J'apprécie en outre le fait qu'il m'oblige à me documenter sur nos vieux outils et usages hérités d'Unix.
[^] # Re: Et encore merci pour les paquets !
Posté par Sygne (site web personnel) . En réponse à la dépêche Attention au dépôt debian-multimedia.org !. Évalué à 3.
Je n'en sais rien. Mais je ne peux pas croire que les erreurs ne sont pas partagées.
[^] # Re: Porter plainte contre l'ukrainien est-il envisageable ?
Posté par Sygne (site web personnel) . En réponse à la dépêche Attention au dépôt debian-multimedia.org !. Évalué à 8.
Franchement, attendre des dépêches de linuxfr qu'elles soient neutres, c'est comme attendre du canard enchainé qu'il se contente de relayer les annonces de l'afp.
Oui, Patrickg a son avis sur la question, et c'est tant mieux, car sans lui, 1) personne n'en saurait rien, 2) ça ouvre la discussion.
C'est triste ton avis sur l'avis d'autrui.
[^] # Re: Et encore merci pour les paquets !
Posté par Sygne (site web personnel) . En réponse à la dépêche Attention au dépôt debian-multimedia.org !. Évalué à 2.
Comme dit ci-dessus, ce genre de scripts est fréquent sur les distributions: Il demande une intervention de l'utilisateur (qui doit le lancer), mais automatise tout le reste.
Et légalement, je trouve cette solution tout à fait satisfaisante. En gros, la documentation indique qu'en lançant ce script, l'utilisateur certifie avoir droit d'installer et d'utiliser les logiciels afférents. Généralement, une fois lancé, le script demande encore à l'utilisateur d'accepter la licence. Cela sert tant pour les bibliothèques soumises à droits dans certains pays que pour les logiciels non redistribuables et donc non empaquetables par la distribution, comme les firmwares de certaines cartes wifi.
Moi non plus je ne comprend pas que Debian relègue encore hors de la distribution toutes ces bibliothèques, indispensables aujourd'hui, et parfaitement légales dans beaucoup de pays.
Je ne comprends pas tous les tenants et aboutissants, de cette histoire, mais àmha, si Debian voulait véritablement régler le problème, il n'y aurait pas besoin d'aller chercher des bibliothèques chez Marillat. Àmha, si Marillat voulait vraiment aider les utilisateurs de Debian, il aurait depuis longtemps milité pour que Debian ait un dépôt officiel pour ces logiciels.
# Les vrais enjeux
Posté par Sygne (site web personnel) . En réponse au journal Qui a vraiment besoin d'héberger soi-même ses données ?. Évalué à 3.
Ne pas exposer ses relations sociales aux aléas des enjeux économiques est une des raisons évoquées par les défenseurs de l'auto-hébergement. Si les relations tissées sur les réseaux sociaux sont si importantes pour les individus, alors il est dans l'intérêt des individus d'avoir une certaine maîtrise de ces réseaux sociaux.
Les personnes, qui, comme toi, ont compris cet enjeu, explorent plusieurs réponses :
Tu vois bien, j'imagine, comment chaque solution technique s'articule avec un modèle politique.
Les défenseurs des modèles décentralisés savent bien que c'est une solution technique complexe pour un individu, mais ils considèrent que 1) le jeu en vaut la chandelle, 2) ça ne peut que s'améliorer, 3) au pire les nœuds peuvent être gérés collectivement (associations, amis…).
[^] # Re: Ca commence à faire beaucoup...
Posté par Sygne (site web personnel) . En réponse à la dépêche Nouvelles autour de LaTeX. Évalué à 2.
Parfait, merci !
[^] # Re: Ca commence à faire beaucoup...
Posté par Sygne (site web personnel) . En réponse à la dépêche Nouvelles autour de LaTeX. Évalué à 4.
J'arrive un peu tardivement, mais sait-on jamais:
Qu'en est-il des algorithmes de micro-typographie intégrés à pdftex, sont-ils repris dans luatex?
[^] # Re: lapin compris
Posté par Sygne (site web personnel) . En réponse au journal La bonne surprise !!. Évalué à 3.
Ah oui, je comprends mieux maintenant.
# lapin compris
Posté par Sygne (site web personnel) . En réponse au journal La bonne surprise !!. Évalué à 10.
Le bouquin, tu l'as gagné, mais tu ne l'as pas su, donc pas commandé, mais tu l'as reçu quand même ?
Ou bien es-tu en train de nous dire que la règle selon laquelle il faut répondre sous tant de jours pour avoir droit à son bouquin ne vaut plus ?
[^] # Re: Quelques commentaires en passant.
Posté par Sygne (site web personnel) . En réponse au journal Utroff est publié. Évalué à 2.
J'ai poussé la version 0.6 de Utmac suite à tes remarques (changelog). Encore merci !
[^] # Re: Quelques commentaires en passant.
Posté par Sygne (site web personnel) . En réponse au journal Utroff est publié. Évalué à 3.
Merci pour le lien, c'est corrigé maintenant.
Pour les questions du détail en typographie:
Pas seulement. Lorsque le document est relié il est plus élégant que les lignes soient alignées de la page gauche à la page droite. En outre, dans le cas d'une mise en page en colonnes (par exemple avec des notes marginales), le défaut d'alignement saute aux yeux.
Mais comme beaucoup de bonnes pratiques typographiques, allègrement oubliées durant quelques années, le défaut de celles-ci n'apparaît plus qu'aux yeux un minimum exercés.
En fait, non. Augmenter la taille des polices ne change rien si l'interligne reste le même (du moins avec troff). Quant à l'interligne, c'est l'unité de base du document, toutes les distances y sont proportionnelles, et je ne le modifie qu'en prenant soin de retomber sur mes pieds:
Mais tu as raison, pour les listes, cela peut-être problématique. Il faudrait que je me replonge dans mes manuels pour voir quelles solutions ils préconisent.
Encore merci, cela fait longtemps que j'ai les yeux plongés dans ces documents, et je finis par ne plus rien voir. Un regard extérieur est extrêmement bienvenue.
[^] # Re: Quelques commentaires en passant.
Posté par Sygne (site web personnel) . En réponse au journal Utroff est publié. Évalué à 4.
Merci (bis) pour tes remarques !
Cf. macro .RV du manuel de utmac :)
En vérité, cela dépend du type de reliure. C'est configurable dans les sources pour l'instant.
C'est une solution courante, mais mauvaise, car elle contrevient à l'alignement des lignes sur une grille stricte, ce qui devient problématique pour du recto verso, car selon la transparence du papier, on peut voir les lignes du verso entre les lignes du recto.
Bien vu, c'était un bug, corrigé maintenant.
Cf. macro .RP du manuel de utmac :) Pour l'instant, je laisse cela au choix de l'utilisateur, mais cette décision peut changer.
Tout cela relève d'un choix esthétique. D'une part, j'avais envie d'une page généralement assez sombre et dense. En outre, comme les manuels sont des documents assez chaotiques, il fallait renforcer la structure de la page, et les lignes le font très bien. J'ai beaucoup tatonné pour la mise en page des documents techniques, et finalement, sans trop y croire, j'ai essayé les lignes épaisses, et j'ai été moi-même surpris que ça fonctionne. Je laisse donc les choses en l'état pour cette macro, quitte à faire mieux avec une autre macro.
Pour le coup, c'est probable. Les fleurs sont la trace d'une ancienne version de la mise en page.
Oui, cela fait partie de ma todo list.
Cf. ci dessus. En outre, le gras est hérité des conventions des pages de manuel.
Je n'ai pas trouvé de quel lien tu parles. Pourrais-tu préciser s'il te plaît?
PS: j'ai ajouté dans les logs « bug report by fmaz fmaz », est-ce que cette mention te convient ?
[^] # Re: Quelques commentaires en passant.
Posté par Sygne (site web personnel) . En réponse au journal Utroff est publié. Évalué à 2.
Cela semble idéal, d'autant plus que j'ai fait plusieurs essais comparatifs, et aucune solution ne convient pour l'instant à toutes les situations. Mais c'est en effet un algorythme plus complexe, qui n'a peut-être pas sa place dans cette macro us.
C'est peut-être la niche inexplorée de troff, qui sait faire de la typographie de détail tout en se rapprochant des générateurs de format comme txt2tag et markdown.
[^] # Re: Quelques commentaires en passant.
Posté par Sygne (site web personnel) . En réponse au journal Utroff est publié. Évalué à 2.
C'est une autre macro (**.PB**) qui fait cela. Les lignes suivantes, où, malgré le long tiret, le début des paragraphes est toujours aligné sont mises en forme par la macro .PI.
À ce problème des listes, j'entrevoie maintenant la solution suivante:
Encore merci, et si tu as un peu de temps, je lirai avec enthousiasme tes autres remarques.
[^] # Re: Quelques commentaires en passant.
Posté par Sygne (site web personnel) . En réponse au journal Utroff est publié. Évalué à 3. Dernière modification le 07 avril 2013 à 23:09.
Merci pour tes remarques :)
Les majuscules sont une convention pour les titres des pages de manuel, et le pdf est composé à partir des sources du manuel, d'où les majuscules. Il y aurait plusieurs moyens de forcer l'usage des minuscules lors de la composition des pdf, mais j'hésite encore tant sur le bon moyen technique de faire cela, tant sur la nécessité de le faire (parce qu'il me semble cohérent que même sur le pdf la mise en page ressemble à une page de manuel).
Tes autres remarques concernent les listes. Dans la page que tu cites, c'est la même macro .PI qui gère les listes à tirets du paragraphe « DESCRIPTION », la liste des options dans le paragraphe qui leur est dédié, ainsi que la liste des différents langage de programmation, et, autre cas singulier, les listes bibliographiques, comme p. 9 de demo-us.pdf.
J'ai eu du mal à trouver une façon de faire qui convienne à cette variété de situations, et tu as raison, la solution n'est toujours pas optimale. J'avais essayé l'espace entre les paragraphes, mais ça ne donnait pas de bons résultats. Ne pas aligner les débuts de textes donne des résultats étranges dans certaines situations. En tout cas, tu m'as convaincu d'y réfléchir à nouveau.
Pourquoi s'arrêter sur une si bonne lancée ?
[^] # Re: dépêche
Posté par Sygne (site web personnel) . En réponse au journal Utroff est publié. Évalué à 6.
Merci pour les louanges, qui sont toujours constructifs, quoi qu'on en dise, car ils donnent du cœur à l'ouvrage. :)
Au point de vue typographique, à mon avis, oui, étant donné que la version heirloom de Troff reprend l'algorythme de création de paragraphe créé pour Tex par Knuth & Plass cf word wrap, ainsi que l'amélioration micro-typographique de ces algorythmes créée pour PdfTex par Hàn Thế Thành cf micro-typography.
Il y a aussi dans Tex une fonction pour placer les paragraphes dans la page (afin d'éviter veuves et orphelines), que Heirloom Troff ne reprend pas. Cette fonction est de toute manière problématique de mon point de vue, car elle peut conduire à créer des sauts de ligne non proportionnels à la taille de lignes, et du coup, on voit par transparence que les lignes ne se recouvrent pas du recto au verso. Utroff, se contente donc de les indiquer, et fournit des solutions pour les supprimer proprement, mais cela suppose une intervention manuelle.
Où je me demande s'il n'y a pas, avec ces questions, une tentative de donner à ce fil de discussion moribond la vivacité d'un bon troll comme on les aime ici…
J'aimerais faire le saut vers NetBSD, dont j'apprécie beaucoup l'esprit, mais comme je suis en train de finir ma thèse, ce n'est pas le bon moment pour chambouler mon espace de travail. Après plusieurs mois de résistance, j'ai donc fait la mise à jour vers systemd la semaine dernière. Le boot est un peu ralenti mais sans grandes conséquences, devenu très laid, mais je ferme les yeux, et /etc/ est bloated, mais il l'était déjà.
[^] # Re: Association de fichiers
Posté par Sygne (site web personnel) . En réponse à la dépêche GNOME 3.8 : deux ans déjà !. Évalué à 3.
Àmha, c'est possible de faire ça en local et/ou via le logiciel qui va bien. Je chercherais du côté des fichiers:
et des commandes:
[^] # Re: dépêche
Posté par Sygne (site web personnel) . En réponse au journal Utroff est publié. Évalué à 3.
Je pensais aux dépêches pour annoncer une version un peu moins bêta. Pour l'instant, tout bouge tout le temps… J'apprécie la proposition, mais je trouve que c'est un peu prématuré.
[^] # Re: Bulle ou pas...
Posté par Sygne (site web personnel) . En réponse au journal Le Bitcoin est à 100€. Évalué à 10.
Considère que si tu payes des impôts et que tu as les moyens de t'acheter un appartement, tu es riche, et tu n'essayes plus de t'en sortir.
C'est immonde de comparer des propriétaires-salariés-imposés qui planquent tout ce qu'ils reçoivent par d'autres voies que celle de leur employeur avec des pauvres qui essaient de s'en sortir.
# Corruption des institutions
Posté par Sygne (site web personnel) . En réponse au journal De la finalité du droit d'auteur . Évalué à 7.
Je trouve très pertinent l'article de Philippe Aigrain sur la corruption des institutions.
Autour des questions portant sur livre numérique, à de nombreuses reprises, la bnf c'est illustrée par des positions qui restreignent l'accès du public au livre:
Tout cela est va tellement à l'encontre du projet de la bnf que c'est impossible à comprendre si l'on ne fait pas l'hypothèse d'une corruption de l'institution: plutôt que de travailler à la réalisation de son projet, elle travaille au maintient de ses intérêts propres, pour ne pas dire de ceux des éditeurs en place.
[^] # Re: 100 000$
Posté par Sygne (site web personnel) . En réponse à la dépêche Yorba organise une campagne de dons pour Geary. Évalué à 3.
Où je m'aperçois que j'ai converti les dollars en euro comme on convertissait des euros en francs…
Bon, je sors, vous pouvez moinsser.