Un débat intéressant et sans doute récurant que l'on voit apparaître
régulièrement sur les forums, et relatif quant au choix de la
distribution...
Linux pour quoi faire ? Tout d'abord clarifions la chose pour dire que
"linux" est le nom du kernel et non du system d'exploitation lui-même...
Petite précision pour les débutants linux. Il faut alors parler de
distribution GNU Linux...
Donc qu'attendez-vous d'un OS libre (par opposition à Windows) ?
Nous savons que Linux est une bonne solution s'il on veut faire un réseau ;
aussi peut-il est aussi une solution en terme de bureautique pure (Office) ?
La partie jeu reste une ombre pour ma part... peut-il concurrencer les
jeux sous Windows ?
Le choix de la distrib reste aussi, difficile dans la perspective des
mises à jour ? Je pense que c'est la que réside la difficulté. RPMS,
PKG, DEB, Yum, ou encore version type gentoo... , installation depuis les
sources, etc. Facilité, Rapidité ou encore prise de caféine, tels sont
les choix qui sont offerts. Un point important réside aussi dans la
sécurité...
Ayant tester une multitude de distrib (redhat, fedora, gentoo, mdk7.0 !,
archlinux, freebsd, solaris, etc), je ne sais sur quoi me baser afin de
trouver un bon compromis. L'on pourra consulter un site tel que
http://www.distrowatch.com afin d'y trouver un bref exposer des distribs
linux, avec les différents liens qui s'y rattachent.
Vos commentaires, et autres suggestions pour extrapoler ces propos seront
les bienvenus afin de clarifier certaines idées...
Pablo Saratxaga , dans le message <c4v7kp$, a écrit :
Sinon, le prochain LaTeX supportera *enfin* utf-8 en natif, avec usepackage[utf8]{inputenc} si j'ai bien compris.
Zut, moi qui l'utilise depuis six mois, il va falloir que j'attende la prochaine version pour compiler mes documents ?
george
Michel Talon, dans le message <c50blp$194r$, a écrit :
Et bien sur la machine de mon collègue voisin qui a la Mandrake 9.2 et a installé tetex, il n'y a pas dvipdfm. Par contre sur ma FreeBSD, aprés avoir installé tetex il y a dvipdfm
Eh bien ça prouve juste que le découpage des paquets de FreeBSD est moins fin que celui de la Mandrake.
Si tu appelles ça un support! Les trucs à base de inputenc consistent en des macros qui se dépèchent par exemple de remplacer é par 'e automatiquement.
C'est quand même mieux que rien.
La modification existe, elle s'appelle omega.
Euh, franchement, bof pour omega : c'est l'exemple typique du deuxième jeu favori des informaticiens, à savoir remplacer des limitations arbitraires par d'autres limitations arbitraires à peine plus hautes. Et surtout ça garde le mécanisme merdique de polices de TeX.
ils sont grotesques maintenant.
Si tu as quelque chose qui fait mieux le boulot à exhiber, je pense que tu auras beaucoup de succès.
Michel Talon, dans le message <c50blp$194r$2@asmodee.lpthe.jussieu.fr>,
a écrit :
Et bien sur la machine de mon collègue voisin qui a la Mandrake 9.2
et a installé tetex, il n'y a pas dvipdfm. Par contre sur ma FreeBSD,
aprés avoir installé tetex il y a dvipdfm
Eh bien ça prouve juste que le découpage des paquets de FreeBSD est
moins fin que celui de la Mandrake.
Si tu appelles ça un support! Les trucs à base de inputenc consistent
en des macros qui se dépèchent par exemple de remplacer é par 'e
automatiquement.
C'est quand même mieux que rien.
La modification existe, elle s'appelle omega.
Euh, franchement, bof pour omega : c'est l'exemple typique du deuxième
jeu favori des informaticiens, à savoir remplacer des limitations
arbitraires par d'autres limitations arbitraires à peine plus hautes. Et
surtout ça garde le mécanisme merdique de polices de TeX.
ils sont grotesques maintenant.
Si tu as quelque chose qui fait mieux le boulot à exhiber, je pense que
tu auras beaucoup de succès.
Michel Talon, dans le message <c50blp$194r$, a écrit :
Et bien sur la machine de mon collègue voisin qui a la Mandrake 9.2 et a installé tetex, il n'y a pas dvipdfm. Par contre sur ma FreeBSD, aprés avoir installé tetex il y a dvipdfm
Eh bien ça prouve juste que le découpage des paquets de FreeBSD est moins fin que celui de la Mandrake.
Si tu appelles ça un support! Les trucs à base de inputenc consistent en des macros qui se dépèchent par exemple de remplacer é par 'e automatiquement.
C'est quand même mieux que rien.
La modification existe, elle s'appelle omega.
Euh, franchement, bof pour omega : c'est l'exemple typique du deuxième jeu favori des informaticiens, à savoir remplacer des limitations arbitraires par d'autres limitations arbitraires à peine plus hautes. Et surtout ça garde le mécanisme merdique de polices de TeX.
ils sont grotesques maintenant.
Si tu as quelque chose qui fait mieux le boulot à exhiber, je pense que tu auras beaucoup de succès.
Miod Vallat
Comme ça, on pourra légitimement dire que LaTeX, c'était mieux avant.
Mais ce serait juste une mesquinerie parce qu'OpenBSD n'est pas foutu de gérer les locales.
Quel est le rapport ? UTF-8 n'est une locale, mais un fléau.
Comme ça, on pourra légitimement dire que LaTeX, c'était mieux avant.
Mais ce serait juste une mesquinerie parce qu'OpenBSD n'est pas foutu de
gérer les locales.
Quel est le rapport ? UTF-8 n'est une locale, mais un fléau.
Miod Vallat , dans le message <4073f67d$0$19483$, a écrit :
Quel est le rapport ? UTF-8 n'est une locale, mais un fléau.
Tu préfères la limitation à 8 bits ?
talon
Nicolas George wrote:
Michel Talon, dans le message <c50blp$194r$, a écrit :
Et bien sur la machine de mon collègue voisin qui a la Mandrake 9.2 et a installé tetex, il n'y a pas dvipdfm. Par contre sur ma FreeBSD, aprés avoir installé tetex il y a dvipdfm
Eh bien ça prouve juste que le découpage des paquets de FreeBSD est moins fin que celui de la Mandrake.
Je suis d'accord avec toi pour ce point là. Aprés vérification (il y a un changelog dans texmf) il apparaît que les versions de tetex dans Mandrake et FreeBSD sont exactement les mêmes, et qu'il s'agit donc uniquement d'un problème de découpage. Tu sais ce que je pense du découpage qui est la plaie des distributions Linux, et particulièrement de Debian. C'est la plus grande stupidité que des esprits infiniment médiocres aient pu imaginer. Perdre son temps à découper des paquets quand la taille des disques double tous les ans, c'est déjà ridicule. Le faire perdre aux utilisateurs car il manque toujours un bout de ci de là pour faire ce qu'on veut, c'est incurablement stupide.
Si tu appelles ça un support! Les trucs à base de inputenc consistent en des macros qui se dépèchent par exemple de remplacer é par 'e automatiquement.
C'est quand même mieux que rien.
La modification existe, elle s'appelle omega.
Euh, franchement, bof pour omega : c'est l'exemple typique du deuxième jeu favori des informaticiens, à savoir remplacer des limitations arbitraires par d'autres limitations arbitraires à peine plus hautes. Et surtout ça garde le mécanisme merdique de polices de TeX.
Tout à fait, c'était juste pour opposer le hack consistant à cacher le fait que TeX travaille à l'ancienne mode, à un essai de solution consistant à modifier le code de TeX.
ils sont grotesques maintenant.
Si tu as quelque chose qui fait mieux le boulot à exhiber, je pense que tu auras beaucoup de succès.
Tu le sais trés bien, il n'y a rien qui fait mieux le boulot maintenant. Il y a des essais de systèmes complètement refaits à partir de zéro, par exemple texmacs. Je l'ai un peu essayé, mais pas assez pour savoir quels sont les points forts et les points faibles. Un point faible évident est qu'il vaut mieux avoir une machine à 3 Ghz. Mais ça c'est à mon avis un facteur négligeable, d'ici que le programme soit tout à fait au point les machines tourneront à 20 Ghz. Au moins ce programme attaque l'une des objections que beaucoup font à TeX, le fait qu'on ne voit pas le résultat en tapant son texte. A mon avis, une autre objection est la qualité imparfaite des algorithmes de coupure de ligne, etc. TeX gère la chose en ajustant uniquement la taille des espaces blancs mais ne modifie pas la taille des fontes. Il existe un système commercial, malheureusement breveté, du à H. Zapf qui permet de jouer sur de légères modifications de la largeur des fontes (assez petites pour ne pas se voir) et qui permet d'éviter le plus souvent la quantité de "badness" qu'on obtient immanquablement dés qu'on fait un document assez long. Il existe une variante de ce procédé qu'on peut utiliser avec pdftex, mais l'usage est trés complexe. Pour avoir écrit un gros bouquin avec beaucoup de formules, j'ai pu apprécier à quel point TeX est mauvais dans la coupure des formules. C'est pas mauvais qu'il faut dire, mais absolument inepte. Sur un bouquin c'est des centaines de formules débordant dans les marges qu'il faut régler une à une par des ajustements manuels, par exemple en changeant le texte pour que tout d'un coup ça rentre magiquement. Ca représente des jours pour le faire. Si aprés ça tu t'amuses à changer de fontes (par exemple l'éditeur voulait imprimer en times, et il y a renoncé à cause de ce problème), c'est tout à refaire, il te surgit de nouveau des centaines de formules à reprendre. Ne parlons pas de l'interprète de macros que Knuth aurait mieux fait de ne jamais introduire dans son programme, quand tu vois la plaie que sont devenus des usines à gaz tels que latex2e.
--
Michel TALON
Nicolas George <george@clipper.ens.fr> wrote:
Michel Talon, dans le message <c50blp$194r$2@asmodee.lpthe.jussieu.fr>,
a écrit :
Et bien sur la machine de mon collègue voisin qui a la Mandrake 9.2
et a installé tetex, il n'y a pas dvipdfm. Par contre sur ma FreeBSD,
aprés avoir installé tetex il y a dvipdfm
Eh bien ça prouve juste que le découpage des paquets de FreeBSD est
moins fin que celui de la Mandrake.
Je suis d'accord avec toi pour ce point là. Aprés vérification (il y a
un changelog dans texmf) il apparaît que les versions de tetex dans
Mandrake et FreeBSD sont exactement les mêmes, et qu'il s'agit donc
uniquement d'un problème de découpage. Tu sais ce que je pense du
découpage qui est la plaie des distributions Linux, et particulièrement
de Debian. C'est la plus grande stupidité que des esprits infiniment
médiocres aient pu imaginer. Perdre son temps à découper des paquets
quand la taille des disques double tous les ans, c'est déjà ridicule.
Le faire perdre aux utilisateurs car il manque toujours un bout de ci de
là pour faire ce qu'on veut, c'est incurablement stupide.
Si tu appelles ça un support! Les trucs à base de inputenc consistent
en des macros qui se dépèchent par exemple de remplacer é par 'e
automatiquement.
C'est quand même mieux que rien.
La modification existe, elle s'appelle omega.
Euh, franchement, bof pour omega : c'est l'exemple typique du deuxième
jeu favori des informaticiens, à savoir remplacer des limitations
arbitraires par d'autres limitations arbitraires à peine plus hautes. Et
surtout ça garde le mécanisme merdique de polices de TeX.
Tout à fait, c'était juste pour opposer le hack consistant à cacher le
fait que TeX travaille à l'ancienne mode, à un essai de solution
consistant à modifier le code de TeX.
ils sont grotesques maintenant.
Si tu as quelque chose qui fait mieux le boulot à exhiber, je pense que
tu auras beaucoup de succès.
Tu le sais trés bien, il n'y a rien qui fait mieux le boulot maintenant.
Il y a des essais de systèmes complètement refaits à partir de zéro, par
exemple texmacs. Je l'ai un peu essayé, mais pas assez pour savoir quels
sont les points forts et les points faibles. Un point faible évident est
qu'il vaut mieux avoir une machine à 3 Ghz. Mais ça c'est à mon avis un
facteur négligeable, d'ici que le programme soit tout à fait au point
les machines tourneront à 20 Ghz. Au moins ce programme attaque l'une
des objections que beaucoup font à TeX, le fait qu'on ne voit pas le
résultat en tapant son texte. A mon avis, une autre objection est la
qualité imparfaite des algorithmes de coupure de ligne, etc. TeX gère
la chose en ajustant uniquement la taille des espaces blancs mais ne
modifie pas la taille des fontes. Il existe un système commercial,
malheureusement breveté, du à H. Zapf qui permet de jouer sur de légères
modifications de la largeur des fontes (assez petites pour ne pas se
voir) et qui permet d'éviter le plus souvent la quantité de "badness" qu'on
obtient immanquablement dés qu'on fait un document assez long. Il
existe une variante de ce procédé qu'on peut utiliser avec pdftex, mais
l'usage est trés complexe. Pour avoir écrit un gros bouquin avec
beaucoup de formules, j'ai pu apprécier à quel point TeX est mauvais
dans la coupure des formules. C'est pas mauvais qu'il faut dire, mais
absolument inepte. Sur un bouquin c'est des centaines de formules
débordant dans les marges qu'il faut régler une à une par des
ajustements manuels, par exemple en changeant le texte pour que tout
d'un coup ça rentre magiquement. Ca représente des jours pour le faire.
Si aprés ça tu t'amuses à changer de fontes (par exemple l'éditeur
voulait imprimer en times, et il y a renoncé à cause de ce problème),
c'est tout à refaire, il te surgit de nouveau des centaines de formules
à reprendre. Ne parlons pas de l'interprète de macros que Knuth aurait
mieux fait de ne jamais introduire dans son programme, quand tu vois la
plaie que sont devenus des usines à gaz tels que latex2e.
Michel Talon, dans le message <c50blp$194r$, a écrit :
Et bien sur la machine de mon collègue voisin qui a la Mandrake 9.2 et a installé tetex, il n'y a pas dvipdfm. Par contre sur ma FreeBSD, aprés avoir installé tetex il y a dvipdfm
Eh bien ça prouve juste que le découpage des paquets de FreeBSD est moins fin que celui de la Mandrake.
Je suis d'accord avec toi pour ce point là. Aprés vérification (il y a un changelog dans texmf) il apparaît que les versions de tetex dans Mandrake et FreeBSD sont exactement les mêmes, et qu'il s'agit donc uniquement d'un problème de découpage. Tu sais ce que je pense du découpage qui est la plaie des distributions Linux, et particulièrement de Debian. C'est la plus grande stupidité que des esprits infiniment médiocres aient pu imaginer. Perdre son temps à découper des paquets quand la taille des disques double tous les ans, c'est déjà ridicule. Le faire perdre aux utilisateurs car il manque toujours un bout de ci de là pour faire ce qu'on veut, c'est incurablement stupide.
Si tu appelles ça un support! Les trucs à base de inputenc consistent en des macros qui se dépèchent par exemple de remplacer é par 'e automatiquement.
C'est quand même mieux que rien.
La modification existe, elle s'appelle omega.
Euh, franchement, bof pour omega : c'est l'exemple typique du deuxième jeu favori des informaticiens, à savoir remplacer des limitations arbitraires par d'autres limitations arbitraires à peine plus hautes. Et surtout ça garde le mécanisme merdique de polices de TeX.
Tout à fait, c'était juste pour opposer le hack consistant à cacher le fait que TeX travaille à l'ancienne mode, à un essai de solution consistant à modifier le code de TeX.
ils sont grotesques maintenant.
Si tu as quelque chose qui fait mieux le boulot à exhiber, je pense que tu auras beaucoup de succès.
Tu le sais trés bien, il n'y a rien qui fait mieux le boulot maintenant. Il y a des essais de systèmes complètement refaits à partir de zéro, par exemple texmacs. Je l'ai un peu essayé, mais pas assez pour savoir quels sont les points forts et les points faibles. Un point faible évident est qu'il vaut mieux avoir une machine à 3 Ghz. Mais ça c'est à mon avis un facteur négligeable, d'ici que le programme soit tout à fait au point les machines tourneront à 20 Ghz. Au moins ce programme attaque l'une des objections que beaucoup font à TeX, le fait qu'on ne voit pas le résultat en tapant son texte. A mon avis, une autre objection est la qualité imparfaite des algorithmes de coupure de ligne, etc. TeX gère la chose en ajustant uniquement la taille des espaces blancs mais ne modifie pas la taille des fontes. Il existe un système commercial, malheureusement breveté, du à H. Zapf qui permet de jouer sur de légères modifications de la largeur des fontes (assez petites pour ne pas se voir) et qui permet d'éviter le plus souvent la quantité de "badness" qu'on obtient immanquablement dés qu'on fait un document assez long. Il existe une variante de ce procédé qu'on peut utiliser avec pdftex, mais l'usage est trés complexe. Pour avoir écrit un gros bouquin avec beaucoup de formules, j'ai pu apprécier à quel point TeX est mauvais dans la coupure des formules. C'est pas mauvais qu'il faut dire, mais absolument inepte. Sur un bouquin c'est des centaines de formules débordant dans les marges qu'il faut régler une à une par des ajustements manuels, par exemple en changeant le texte pour que tout d'un coup ça rentre magiquement. Ca représente des jours pour le faire. Si aprés ça tu t'amuses à changer de fontes (par exemple l'éditeur voulait imprimer en times, et il y a renoncé à cause de ce problème), c'est tout à refaire, il te surgit de nouveau des centaines de formules à reprendre. Ne parlons pas de l'interprète de macros que Knuth aurait mieux fait de ne jamais introduire dans son programme, quand tu vois la plaie que sont devenus des usines à gaz tels que latex2e.
--
Michel TALON
Miod Vallat
Quel est le rapport ? UTF-8 n'est une locale, mais un fléau.
Tu préfères la limitation à 8 bits ?
Je préfère de très loin un encodage comme Unicode, qui a des inconvénients mais des avantages indéniables, à l'Universal Translation Fuckup qui n'a que des inconvénients.
Quel est le rapport ? UTF-8 n'est une locale, mais un fléau.
Tu préfères la limitation à 8 bits ?
Je préfère de très loin un encodage comme Unicode, qui a des
inconvénients mais des avantages indéniables, à l'Universal Translation
Fuckup qui n'a que des inconvénients.
Quel est le rapport ? UTF-8 n'est une locale, mais un fléau.
Tu préfères la limitation à 8 bits ?
Je préfère de très loin un encodage comme Unicode, qui a des inconvénients mais des avantages indéniables, à l'Universal Translation Fuckup qui n'a que des inconvénients.
Samuel Colin
Dans l'article <407402e3$0$22850$, Miod Vallat a tapoté :
Quel est le rapport ? UTF-8 n'est une locale, mais un fléau.
Tu préfères la limitation à 8 bits ?
Je préfère de très loin un encodage comme Unicode, qui a des inconvénients mais des avantages indéniables, à l'Universal Translation Fuckup qui n'a que des inconvénients.
UTF-8 est une façon de représenter l'Unicode... De même que UTF-16 et UTF-32 d'ailleurs. http://www.unicode.org/versions/Unicode4.0.0/ch02.pdf page 20.
-- - Tous les messages annulés ne sont pas nécéssairement à reposter... - Quitte à reposter, serait-il possible de corriger les fautes d'orthographe, par la même occasion ? -+- JL in <http://www.le-gnu.net> : Comme une lettre à la [Repost]
Dans l'article <407402e3$0$22850$626a14ce@news.free.fr>,
Miod Vallat a tapoté :
Quel est le rapport ? UTF-8 n'est une locale, mais un fléau.
Tu préfères la limitation à 8 bits ?
Je préfère de très loin un encodage comme Unicode, qui a des
inconvénients mais des avantages indéniables, à l'Universal Translation
Fuckup qui n'a que des inconvénients.
UTF-8 est une façon de représenter l'Unicode...
De même que UTF-16 et UTF-32 d'ailleurs.
http://www.unicode.org/versions/Unicode4.0.0/ch02.pdf
page 20.
--
- Tous les messages annulés ne sont pas nécéssairement à reposter...
- Quitte à reposter, serait-il possible de corriger les fautes
d'orthographe, par la même occasion ?
-+- JL in <http://www.le-gnu.net> : Comme une lettre à la [Repost]
Dans l'article <407402e3$0$22850$, Miod Vallat a tapoté :
Quel est le rapport ? UTF-8 n'est une locale, mais un fléau.
Tu préfères la limitation à 8 bits ?
Je préfère de très loin un encodage comme Unicode, qui a des inconvénients mais des avantages indéniables, à l'Universal Translation Fuckup qui n'a que des inconvénients.
UTF-8 est une façon de représenter l'Unicode... De même que UTF-16 et UTF-32 d'ailleurs. http://www.unicode.org/versions/Unicode4.0.0/ch02.pdf page 20.
-- - Tous les messages annulés ne sont pas nécéssairement à reposter... - Quitte à reposter, serait-il possible de corriger les fautes d'orthographe, par la même occasion ? -+- JL in <http://www.le-gnu.net> : Comme une lettre à la [Repost]
george
Michel Talon, dans le message <c50vau$1ech$, a écrit :
Tu sais ce que je pense du découpage qui est la plaie des distributions Linux, et particulièrement de Debian. C'est la plus grande stupidité que des esprits infiniment médiocres aient pu imaginer.
Moi je trouve ça utile. Donc je t'en prie, reste sous FreeBSD puisque tu préfères FreeBSD (que pour ma part je considère comme une sombre merde du point de vue technique) et n'essaie pas d'imposer tes vues à ceux qui n'en ont pas besoin.
quand la taille des disques double tous les ans, c'est déjà ridicule.
Ça, c'est un des arguments les plus cons qu'on puisse sortir !
d'ici que le programme soit tout à fait au point les machines tourneront à 20 Ghz.
Dommage pour ceux qui n'auraient pas prévu de renouveler leur matériel.
Au moins ce programme attaque l'une des objections que beaucoup font à TeX, le fait qu'on ne voit pas le résultat en tapant son texte.
En ce qui me concerne, je _préfère_ l'aspect non-interactif pour plusieurs raisons qui me sont personnelles. C'est de toutes façons très con de mélanger le moteur de saisie et le moteur de rendu. Permettre de les faire interagir finement, c'est parfait, mais si ça doit se faire au détriment des autres possibilités, c'est définitivement non.
C'est d'ailleurs un phénomène qui m'a l'air trop répandu dans le mode libre ces derniers temps. Prenons le cas de Gimp : une de ses grandes forces, c'est d'être scriptable, en scheme et en perl, possibilité qui à ce qu'on m'a dit est absente de son homologue propriétaire bien connu ; maintenant, regardons les débuts de projets équivalents en vectoriel, dia et sodipodi par exemple : pas de tel scriptage à ce que j'ai pu voir.
Les projets libres ont de plus en plus tendance à imiter les projets propriétaires dans leur aspect whizzbang au premier abord, et à en même temps perdre les fonctions avancées complexes qui faisaient leur force.
Pour avoir écrit un gros bouquin avec beaucoup de formules, j'ai pu apprécier à quel point TeX est mauvais dans la coupure des formules. C'est pas mauvais qu'il faut dire, mais absolument inepte. Sur un bouquin c'est des centaines de formules débordant dans les marges qu'il faut régler une à une par des ajustements manuels, par exemple en changeant le texte pour que tout d'un coup ça rentre magiquement.
Oui, enfin là le problème est intrinsèque : bien couper une formule est une opération difficile dans tous les cas, même à la main, et rarement souhaitable. J'ai envie de répondre : si tu as des grosses formules, mets-les en display, ce sera plus lisible et tu n'auras rien à remettre en page.
Michel Talon, dans le message <c50vau$1ech$1@asmodee.lpthe.jussieu.fr>,
a écrit :
Tu sais ce que je pense du
découpage qui est la plaie des distributions Linux, et particulièrement
de Debian. C'est la plus grande stupidité que des esprits infiniment
médiocres aient pu imaginer.
Moi je trouve ça utile. Donc je t'en prie, reste sous FreeBSD puisque tu
préfères FreeBSD (que pour ma part je considère comme une sombre merde
du point de vue technique) et n'essaie pas d'imposer tes vues à ceux qui
n'en ont pas besoin.
quand la taille des disques double tous les ans, c'est déjà ridicule.
Ça, c'est un des arguments les plus cons qu'on puisse sortir !
d'ici que le programme soit tout à fait au point
les machines tourneront à 20 Ghz.
Dommage pour ceux qui n'auraient pas prévu de renouveler leur matériel.
Au moins ce programme attaque l'une
des objections que beaucoup font à TeX, le fait qu'on ne voit pas le
résultat en tapant son texte.
En ce qui me concerne, je _préfère_ l'aspect non-interactif pour
plusieurs raisons qui me sont personnelles. C'est de toutes façons très
con de mélanger le moteur de saisie et le moteur de rendu. Permettre de
les faire interagir finement, c'est parfait, mais si ça doit se faire au
détriment des autres possibilités, c'est définitivement non.
C'est d'ailleurs un phénomène qui m'a l'air trop répandu dans le mode
libre ces derniers temps. Prenons le cas de Gimp : une de ses grandes
forces, c'est d'être scriptable, en scheme et en perl, possibilité qui à
ce qu'on m'a dit est absente de son homologue propriétaire bien connu ;
maintenant, regardons les débuts de projets équivalents en vectoriel,
dia et sodipodi par exemple : pas de tel scriptage à ce que j'ai pu
voir.
Les projets libres ont de plus en plus tendance à imiter les projets
propriétaires dans leur aspect whizzbang au premier abord, et à en même
temps perdre les fonctions avancées complexes qui faisaient leur force.
Pour avoir écrit un gros bouquin avec
beaucoup de formules, j'ai pu apprécier à quel point TeX est mauvais
dans la coupure des formules. C'est pas mauvais qu'il faut dire, mais
absolument inepte. Sur un bouquin c'est des centaines de formules
débordant dans les marges qu'il faut régler une à une par des
ajustements manuels, par exemple en changeant le texte pour que tout
d'un coup ça rentre magiquement.
Oui, enfin là le problème est intrinsèque : bien couper une formule est
une opération difficile dans tous les cas, même à la main, et rarement
souhaitable. J'ai envie de répondre : si tu as des grosses formules,
mets-les en display, ce sera plus lisible et tu n'auras rien à remettre
en page.
Michel Talon, dans le message <c50vau$1ech$, a écrit :
Tu sais ce que je pense du découpage qui est la plaie des distributions Linux, et particulièrement de Debian. C'est la plus grande stupidité que des esprits infiniment médiocres aient pu imaginer.
Moi je trouve ça utile. Donc je t'en prie, reste sous FreeBSD puisque tu préfères FreeBSD (que pour ma part je considère comme une sombre merde du point de vue technique) et n'essaie pas d'imposer tes vues à ceux qui n'en ont pas besoin.
quand la taille des disques double tous les ans, c'est déjà ridicule.
Ça, c'est un des arguments les plus cons qu'on puisse sortir !
d'ici que le programme soit tout à fait au point les machines tourneront à 20 Ghz.
Dommage pour ceux qui n'auraient pas prévu de renouveler leur matériel.
Au moins ce programme attaque l'une des objections que beaucoup font à TeX, le fait qu'on ne voit pas le résultat en tapant son texte.
En ce qui me concerne, je _préfère_ l'aspect non-interactif pour plusieurs raisons qui me sont personnelles. C'est de toutes façons très con de mélanger le moteur de saisie et le moteur de rendu. Permettre de les faire interagir finement, c'est parfait, mais si ça doit se faire au détriment des autres possibilités, c'est définitivement non.
C'est d'ailleurs un phénomène qui m'a l'air trop répandu dans le mode libre ces derniers temps. Prenons le cas de Gimp : une de ses grandes forces, c'est d'être scriptable, en scheme et en perl, possibilité qui à ce qu'on m'a dit est absente de son homologue propriétaire bien connu ; maintenant, regardons les débuts de projets équivalents en vectoriel, dia et sodipodi par exemple : pas de tel scriptage à ce que j'ai pu voir.
Les projets libres ont de plus en plus tendance à imiter les projets propriétaires dans leur aspect whizzbang au premier abord, et à en même temps perdre les fonctions avancées complexes qui faisaient leur force.
Pour avoir écrit un gros bouquin avec beaucoup de formules, j'ai pu apprécier à quel point TeX est mauvais dans la coupure des formules. C'est pas mauvais qu'il faut dire, mais absolument inepte. Sur un bouquin c'est des centaines de formules débordant dans les marges qu'il faut régler une à une par des ajustements manuels, par exemple en changeant le texte pour que tout d'un coup ça rentre magiquement.
Oui, enfin là le problème est intrinsèque : bien couper une formule est une opération difficile dans tous les cas, même à la main, et rarement souhaitable. J'ai envie de répondre : si tu as des grosses formules, mets-les en display, ce sera plus lisible et tu n'auras rien à remettre en page.
george
Miod Vallat , dans le message <407402e3$0$22850$, a écrit :
Je préfère de très loin un encodage comme Unicode
Unicode n'est pas une encodage, il ne décrit qu'une numérotation des caractères, pas leur représentation sous forme d'octets. Il y a plusieurs manières de représenter Unicode sous forme d'octets, les plus connues sont UCS-2 (deux octets par caractère, tout Unicode n'est donc pas représentable), UCS-4 (quatre octets par caractère), UTF-16 (deux octets par caractère en général, un hack pour représenter au delà, c'est une beurkerie pour contenter ceux qui avaient commencé à implémenter à base d'UCS-2), UTF-8 (de un à quatre octets par caractère).
Pour la manipulation de texte à l'intérieur de programmes, une représentation d'un int par caractère (ce qui va correspondre en général à UCS-4) est à mon avis souvent souhaitable.
En revanche, pour la représentation externe des textes, UTF-8 a plein d'avantages sur tous les autres :
- compatibilité avec l'ASCII : un texte UTF-8 contenant essentiellement des caractères latin sera à peu près lisible et manipulable par des outils ne connaissant que les encodages mono-octets, le tri lexicographique est préservé ;
- pas de problème d'endianness ;
- robustesse : en cas de perte d'un octet, en particulier, seul un caractère est affecté (alors que dans le cas d'UCS-2 ou -4, c'est la catastrophe) ;
- compacité : même sans compression, UTF-8 utilise la plupart du temps moins de place que les autres (exception : un texte chinois, japonais ou coréen en UCS-2).
J'ai l'impression que tu n'avais pas les idées très claires sur ces points. Qu'en penses-tu maintenant ?
Miod Vallat , dans le message <407402e3$0$22850$626a14ce@news.free.fr>,
a écrit :
Je préfère de très loin un encodage comme Unicode
Unicode n'est pas une encodage, il ne décrit qu'une numérotation des
caractères, pas leur représentation sous forme d'octets. Il y a
plusieurs manières de représenter Unicode sous forme d'octets, les plus
connues sont UCS-2 (deux octets par caractère, tout Unicode n'est donc
pas représentable), UCS-4 (quatre octets par caractère), UTF-16 (deux
octets par caractère en général, un hack pour représenter au delà, c'est
une beurkerie pour contenter ceux qui avaient commencé à implémenter à
base d'UCS-2), UTF-8 (de un à quatre octets par caractère).
Pour la manipulation de texte à l'intérieur de programmes, une
représentation d'un int par caractère (ce qui va correspondre en général
à UCS-4) est à mon avis souvent souhaitable.
En revanche, pour la représentation externe des textes, UTF-8 a plein
d'avantages sur tous les autres :
- compatibilité avec l'ASCII : un texte UTF-8 contenant essentiellement
des caractères latin sera à peu près lisible et manipulable par des
outils ne connaissant que les encodages mono-octets, le tri
lexicographique est préservé ;
- pas de problème d'endianness ;
- robustesse : en cas de perte d'un octet, en particulier, seul un
caractère est affecté (alors que dans le cas d'UCS-2 ou -4, c'est la
catastrophe) ;
- compacité : même sans compression, UTF-8 utilise la plupart du temps
moins de place que les autres (exception : un texte chinois, japonais
ou coréen en UCS-2).
J'ai l'impression que tu n'avais pas les idées très claires sur ces
points. Qu'en penses-tu maintenant ?
Miod Vallat , dans le message <407402e3$0$22850$, a écrit :
Je préfère de très loin un encodage comme Unicode
Unicode n'est pas une encodage, il ne décrit qu'une numérotation des caractères, pas leur représentation sous forme d'octets. Il y a plusieurs manières de représenter Unicode sous forme d'octets, les plus connues sont UCS-2 (deux octets par caractère, tout Unicode n'est donc pas représentable), UCS-4 (quatre octets par caractère), UTF-16 (deux octets par caractère en général, un hack pour représenter au delà, c'est une beurkerie pour contenter ceux qui avaient commencé à implémenter à base d'UCS-2), UTF-8 (de un à quatre octets par caractère).
Pour la manipulation de texte à l'intérieur de programmes, une représentation d'un int par caractère (ce qui va correspondre en général à UCS-4) est à mon avis souvent souhaitable.
En revanche, pour la représentation externe des textes, UTF-8 a plein d'avantages sur tous les autres :
- compatibilité avec l'ASCII : un texte UTF-8 contenant essentiellement des caractères latin sera à peu près lisible et manipulable par des outils ne connaissant que les encodages mono-octets, le tri lexicographique est préservé ;
- pas de problème d'endianness ;
- robustesse : en cas de perte d'un octet, en particulier, seul un caractère est affecté (alors que dans le cas d'UCS-2 ou -4, c'est la catastrophe) ;
- compacité : même sans compression, UTF-8 utilise la plupart du temps moins de place que les autres (exception : un texte chinois, japonais ou coréen en UCS-2).
J'ai l'impression que tu n'avais pas les idées très claires sur ces points. Qu'en penses-tu maintenant ?
