Journal Unicode

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
31
15
avr.
2011

Salut,

Je m'interroge depuis longtemps sur la présence de caractères assez "bizarres" dans unicode, par exemple le fameux bonhomme de neige , ou les fontes windings etc. J'avais crû comprendre que c'était pour des raisons historiques.

Je ne connais pas le fonctionnement du consortium unicode, ni la procédure de soumission et d'acceptation de nouveaux caractères mais je m'interroge sur leur motivation quand ils continuent à ajouter des caractères tels que:

WOMAN WITH BUNNY EARS

SMILING CAT FACE WITH HEART-SHAPED EYES

PILE OF POO

etc

http://unicode.org/charts/PDF/Unicode-6.0/U60-1F600.pdf

http://unicode.org/charts/PDF/Unicode-6.0/U60-1F300.pdf

Est-ce qu'à terme leur but est former une grande bibliothèque de cliparts moisis à l'instar de ceux qui accompagnaient microsoft word 7.0 ? Est-ce qu'une seule personne dans le monde à l'utilité des ces "caractères" ?

  • # Justification

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

    C'est vrai que ça vaudrait la peine que chaque caractère soit accompagné d'un texte justifiant son intérêt en tant que caractère, en quoi il est un symbole utile, et non un dessin qui n'a rien à faire dans Unicode.

    Par exemple, les signes du zodiaque et les symboles de produits chimiques ont à mon avis un réel sens en tant que symboles, ce ne sont pas de simples dessins. En revanche, la crotte de chien, franchement je ne vois pas non plus.

    • [^] # Re: Justification

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

      1F365
      "fish cake with swirl design" ... pas mal comme texte explicatif pour celui-ci :p

    • [^] # Re: Justification

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

      ça peut peut-être simplifier et uniformiser le développement des clients de messagerie instantanée?

      • [^] # Re: Justification

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

        Sauf qu'il faut que les polices de caractères utilisées contiennent ces caractères…

        AMA ça mange un peu trop sur le clipart.

        Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

        • [^] # Re: Justification

          Posté par  . Évalué à 5.

          L'avantage est de pouvoir tracer des caractères d'émoticônes ou divers dans une zone de texte (sans avoir recours à l'affichage d'images). Ça facilite grandement l'implémentation. Il « suffit » que le paquet logiciel contienne une des nombreuses polices unicode librement disponibles. Listes de polices, par bloc unicode: :en:Unicode typefaces (acheter un écran large avant de cliquer).

    • [^] # Re: Justification

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

      Prière de ramasser les

    • [^] # Re: Justification

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

      http://www.unicode.org/faq/basic_q.html Q: What is the scope of Unicode?

      A: Unicode covers all the characters for all the writing systems of the world, modern and ancient. It also includes technical symbols, punctuations, and many other characters used in writing text. The Unicode Standard is intended to support the needs of all types of users, whether in business or academia, using mainstream or minority scripts.

      Par exemple le journal parle des émoticônes emoji qui sont utilisés au Japon par plusieurs opérateurs et messagerie instantané. Ce ne sont pas juste des caractères pour rigoler mais ce sont des émoticônes utilisés pour communiquer et cela a un certain sens de les standardiser.

      Pour voir le travail de standardisation : https://sites.google.com/site/unicodesymbols/Home/emoji-symbols

      • [^] # Re: Justification

        Posté par  . Évalué à 2.

        je vais être très coquin, tiens :

        http://www.w3.org/TR/2011/WD-emotion-voc-20110407/

        à utiliser avec

        http://www.w3.org/TR/2011/WD-emotionml-20110407/

        • [^] # Re: Justification

          Posté par  . Évalué à 7.

          http://www.w3.org/TR/2011/WD-emotionml-20110407/#s2.2.2

          <emotion dimension-set="http://www.w3.org/TR/emotion-voc/xml#pad-dimensions">
    <dimension name="arousal" value="0.3"/><!-- lower-than-average arousal -->
    <dimension name="pleasure" value="0.9"/><!-- very high positive valence -->
    <dimension name="dominance" value="0.8"/><!-- relatively high potency    -->
</emotion>

          Et bien dites donc... certaines personnes sont très précises dans la description de leurs émotions. Mais sont-elles bien humaines ?
          D'ailleurs, a-t-on tant besoin que ça de langages informatiques (EmotionML), de caractères unicode, pour décrire des émotions, des objets comme des déjections ?

          • [^] # Re: Justification

            Posté par  . Évalué à 5.

            Si même quand on developpe des standars on peut plus rigoler, où va le monde ma bonne dame...

          • [^] # Re: Justification

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

            FYI, Il y a des chercheurs qui bossent sur les émotions, et eux ont besoin de formaliser ce genre de chose.

            Par exemple, là où je bosse, ce genre de paramètres peut être utilisé pour piloter l'attitude d'un personnage virtuel et faire des expériences sur la façon dont cette attitude est perçue par un humain.

            Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

    • [^] # Re: Justification

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

      C'est comme pour les adresses IPv4.
      Au début, on croit qu'on en a tellement qu'on peut s'éclater comme des bètes, réserver des pans entiers d'adressage pour expérimenter.
      Alors là, tu penses avec Unicode, on peut encoder les langages passés, présents à venir, les hiéroglyphes, les symboles Klingon, mon écriture à moi que j'ai...

      • [^] # Re: Justification

        Posté par  . Évalué à 7.

        Unicode prévoit 1 114 111 caractères (110 000 en base 16), répartis en 16 plans. Seuls 3 plans sont réellement utilisés (0, 1, 2) et toutes les langues connues sont déjà presque intégralement couvertes. Pour ton écriture à toi, tu disposes des plans privés 15 et 16, totalisant 131 072 places libres (20 000 en base 16). Amuse-toi bien.

        (+ d'infos :en:Mapping of Unicode characters.)

  • # Utilité

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

    Ça pourrait remplacer les smileys actuellement affichés comme images ou ascii-art. Avec ces symboles on a un dessin accessible qui reflète l'expression et qui est copie-collable aisément.

    Après pour ce qui sort des bonhommes, j'ai du mal. Peut-être qu'ils veulent faire des interfaces user-friendly en mode texte ? Il y a des types de ncurses dans le consortium ?

    • [^] # Re: Utilité

      Posté par  . Évalué à 3.

      Avec ces symboles on a un dessin accessible

      En quoi est-ce plus accessible qu'une image avec le texte "alt" correspondant ?? (question subsidiaire : comment un aveugle s'imagine-t-il la forme d'une crotte de chien ?)

      • [^] # Re: Utilité

        Posté par  . Évalué à 10.

        comment un aveugle s'imagine-t-il la forme d'une crotte de chien ?)

        Avec l'odeur ?

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: Utilité

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

        c'est plus accessible dans le sens où :

        • il n'y a pas besoin de fournir un alt.
        • ça prend 2 à 4 octets, là où pour l'image + code html, ça en prend des dizaines (oui, le volume d'un fichier, ça fait parti de l'accessibilité)
        • il n'y a pas que le HTML dans la vie, tout les formats de documents n'acceptent pas forcément l'incrustation d'images. Cela peut donc être utile "d'illustrer" des formats de fichiers purement textuel par exemple.

        • [^] # Re: Utilité

          Posté par  . Évalué à 2.

          Les caractères unicode en question ont la taille du texte environnant. Cela peut-être gênant si la taille visible du texte n'est pas très grande. Par exemple, si je lis un commentaire avec un de ces caractères, sur mon écran le caractère ne fait pas plus de 2 millimètres de hauteur, et il est donc parfaitement illisible.

        • [^] # Re: Utilité

          Posté par  . Évalué à 7.

          oui, le volume d'un fichier, ça fait parti de l'accessibilité

          Si c'était le cas, il vaudrait mieux remplacer tous les protocoles texte de l'IETF et du W3C par des codages binaires plus efficaces, plutôt que définir des raccourcis pour une poignée d'emoticones et de crottes de chien.

          Cela peut donc être utile "d'illustrer" des formats de fichiers purement textuel par exemple

          Oui enfin pourquoi un bonhomme de neige ou une crotte de chien ? Quel est le besoin spécifique lié à cela ? Y a un boulot sérieux de sélection des concepts derrière ou c'est juste pour faire chier les implémenteurs du standard ? (pour répondre à une objection plus haut : les blagues c'est sympa, mais ça l'est moins quand d'autres sont censés en subir les conséquences)

          • [^] # Re: Utilité

            Posté par  . Évalué à 10.

            Oui enfin pourquoi un bonhomme de neige

            il fait partie d'un ensemble de symboles consacrés à la météo ☀☁☂☃. pas très loin on a ☉☼☽ et un zoli flocon

            on remarquera d'ailleurs qu'on a un visage blanc souriant, un visage blanc grimaçant, un visage noir souriant, mais pas de visage noir grimaçant : ☹ ☺ ☻ . je suppose que c'est parce que les nègres se marrent tout le temps comme des cons ou qu'ils n'ont pas le droit de se plaindre.

            plus sérieusement ça fait des polices de caractères qui pèsent lourd, toutes ces conneries. les polices contenant les derniers zigouigouis à la mode vont contenir des milliers de Kanji et autres caractères Hangul dont je n'ai strictement rien à foutre.

            • [^] # Re: Utilité

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

              les polices contenant les derniers zigouigouis à la mode vont contenir des milliers de Kanji et autres caractères Hangul dont je n'ai strictement rien à foutre.

              C'est ce que disent beaucoup d'anglophones à la vue d'autre chose que 26 caractères de l'alphabet sans accent : pourquoi est-ce qu'on n'est pas resté à l'ASCII 7-bit? Tu ne verras donc aucun inconvénient à ce qu'on supprime de la police de caractère, au même moment que les Kanji, tous ces caractères accentués qui pèsent lourd et dont une bonne majorité des gens n'ont strictement rien à foutre...

              Note : ce n'est pas parce que c'est normé Unicode que ton fournisseur de police de caractère doit les intégrer, il a le choix, donc tu as le choix.

              • [^] # Re: Utilité

                Posté par  . Évalué à 10.

                Tu ne verras donc aucun inconvénient à ce qu'on supprime de la police de caractère, au même moment que les Kanji, tous ces caractères accentués qui pèsent lourd et dont une bonne majorité des gens n'ont strictement rien à foutre...

                AUCUN, EN EFFET. ET JE PENSE QU'ON PEUT EGALEMENT VIRER LES MINUSCULES

                • [^] # Re: Utilité

                  Posté par  . Évalué à 8.

                  ON PEUT AUSSI VIRER LES MAJUSCULES. FINI LE CLAVIER QUI SE BLO

                  Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                  • [^] # Re: Utilité

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

                    Et on peut ne laisser que espace et tabulation, ça va être marrant à essayer de comprendre...

                    Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

              • [^] # Re: Utilité

                Posté par  . Évalué à 4.

                C'est ce que disent beaucoup d'anglophones à la vue d'autre chose que 26 caractères de l'alphabet sans accent : pourquoi est-ce qu'on n'est pas resté à l'ASCII 7-bit ?

                Je me demande si l'on va passer un jour complètement à l'UTF, et si oui auquel (16,32,64?)
                Ou si l'on va garder encore pendant des siècles l'ASCII 7 bit dans tout un tas de situation (un peu comme les fax aujourd'hui). Auquel cas il s'agirait d'un avantage concurrentiel tout à fait déloyal en faveur de la langue anglaise et de son alphabet sans accent :-(

                • [^] # Re: Utilité

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

                  Le codage qui a pris de l'ampleur (HTML, XML, distro Linux...) est quand même bien UTF-8. Même les entreprises américaines y passent, et en plus l'avantage est que c'est bien compatible au niveau transport avec l'ASCII "de base" donc pas de désavantages. UTF-8, c'est bien, mangez-en!

                  Pour les autres, c'est plutôt une représentation interne (UTF-16 pour Windows, UTF-32 pour Linux) dont on ne se soucis pas tant que les documents sont UTF-8.

                  Surtout, vivement qu'on se débarrasse une bonne fois pour toute de tous les autres encodages!

                  • [^] # Re: Utilité

                    Posté par  . Évalué à 1.

                    Attention aux champions du monde de l'"administration" qui paramètrent leurs serveurs SFTP sur windows avec l'encodage des noms de fichiers en UTF-16 ... ou qui envoient des messages XML encodés en UTF-16 avec écrit 'encoding="utf-8"' dans l'entête ...

                • [^] # Re: Utilité

                  Posté par  . Évalué à 5.

                  ah ben vu qu'il y a des gros malins qui ont mis des ĉ, ĝ, ĥ, ĵ, ŝ, ŭ en espéranto...

                  dès le départ (il y a plus de 100 ans, donc) se posaient des problèmes d'imprimerie avec ces nouveaux caractères à la con

                  • [^] # Re: Utilité

                    Posté par  . Évalué à 6.

                    Ce sont des gens qui ont compris que l'imagination ne devait pas être bridée par des contraintes techniques idiotes.

                    Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

                    • [^] # Re: Utilité

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

                      Je crois que je vais revendre mon ordinateur et acheter un pot de peinture ...

                    • [^] # Re: Utilité

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

                      Mof, si c'est ça, moi j'aurais carrément créé de nouveaux glyphes, je trouve les caractères latins assez vilains en comparaison de ce qui existe par ailleurs :

                      • العربية
                      • مصرى
                      • فارسی
                      • ગુજરાતી
                      • ქართული
                      • தமிழ்
                      • తెలుగు

                      Après, on va dire que c'est une question de goût et couleur, certes, mais n'empêche que je trouve les formes arrondies plus agréables à l'œil, là où l'alphabet latin est truffé de segments de droites.

                      Mais l'alphabet de l'espéranto à certainement fait le choix des caractères latin par commodité, ce qui ne me paraît pas idiot. Bref, même si je suis d'accord avec l'argument que tu avances de façon général, il ne me semble pas s'appliquer ici.

                • [^] # Re: Utilité

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

                  Auquel cas il s'agirait d'un avantage concurrentiel tout à fait déloyal en faveur de la langue anglaise et de son alphabet sans accent :-(

                  L’ASCII, un avantage en faveur de la langue anglaise ? Alors que l’ASCII n’a jamais permis d’écrire correctement en anglais (pas plus que que l’ISO-8859-1 n’a permis d’écrire correctement en français) ?

                  Je prends n’importe quel ouvrage en anglais sur mes étagères, n’importe quelle page et n’importe quel paragraphe, je tombe instantanément sur plusieurs caractères ne figurant pas dans une table ASCII. Les plus fréquents étant notamment les « guillemets anglais », simples ou doubles (U2018, U2019, U201C, U201D), et le tiret cadratin (U2014).

                  Sans compter l’utilisation pas si rare de mots étrangers (dont beaucoup de français), que l’usage commande d’écrire avec leurs diacritiques d’origine.

                  • [^] # Re: Utilité

                    Posté par  . Évalué à 1.

                    Je prends n’importe quel ouvrage en anglais sur mes étagères, n’importe quelle page et n’importe quel paragraphe, je tombe instantanément sur plusieurs caractères ne figurant pas dans une table ASCII.

                    En « texte brut », oui, mais en général les ouvrages ne peuvent se permettre d'être écrits en "texte brut". Ils ont besoin de mises en forme beaucoup plus élaborées qui supposent des outils auxquels les caractères "spéciaux" (disons "précis") ne posent aucun problème.

                    Je trouve de plus qu'en ISO-8859-15 (fr_FR@euro), on arrive quand même à écrire très correctement le français. Suffisamment, en tous les cas, pour se demander s'il est souhaitable de passer en UTF-8. Car UTF-8 a un coût au niveau des performances générales, n'importe quel script shell allant plus vite avec une locale forcée à "C" (ASCII). C'est certes vivable au quotidien, mais quand même sensible (enfin, sur mon vieux P.IV, avec un dual ou quadri-Grouik, je ne sais pas). Bref, il n'y a pas àmha de bonne solution dans l'absolu, juste un équilibre à faire entre les besoins réels de précision et les désagréments qu'on est prêt à supporter (commandes plus lentes ou qui ne marchent tout simplement pas).

                    • [^] # Re: Utilité

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

                      Car UTF-8 a un coût au niveau des performances générales,

                      Oui. Comme la mise en forme. Supprimons tout! Restons en binaire! Faut arrêter le délire, UTF-8 a un impact très très minime à l'époque des vidéos HD.

                      n'importe quel script shell allant plus vite avec une locale forcée à "C" (ASCII).

                      Je sais pas ce que tu fais de tes scripts, mais au pif je dirai que 99% des scripts se contrefoutent de la locale.

                      • [^] # Re: Utilité

                        Posté par  . Évalué à 2.

                        Oui. Comme la mise en forme. Supprimons tout!

                        Comme la conclusion de mon message, tu veux dire (on n'a pas tous des super-machines de la mort) ?

                        Je sais pas ce que tu fais de tes scripts, mais au pif je dirai que 99% des scripts se contrefoutent de la locale.

                        Prends les scripts qui font du traitement de chaînes (ce qui est un peu la base du Shell) :

                        $ seq 10000 >/tmp/out
$ time grep 7 /tmp/out >/dev/null

real    0m3.196s
user    0m3.190s
sys     0m0.002s

$ time LANG=C grep 7 /tmp/out >/dev/null 

real    0m0.003s
user    0m0.001s
sys     0m0.001s

$ time sed /7/p -n /tmp/out >/dev/null 

real    0m0.015s
user    0m0.011s
sys     0m0.003s

$ time LANG=C sed /7/p -n /tmp/out >/dev/null 

real    0m0.010s
user    0m0.008s
sys     0m0.001s`

$  time  awk '{print length($0)}' /tmp/out >/dev/null

real    0m0.020s
user    0m0.018s
sys     0m0.002s

$ time  LANG=C awk '{print length($0)}' /tmp/out >/dev/null

real    0m0.012s
user    0m0.008s
sys     0m0.002s

                        Tous les utilitaires sont plus ou moins ralentis. Et là dans ces tests, je suis mignon parce que ce sont de toutes petites chaînes, mais plus les chaînes traitées vont être longues (genre quand tu traites un fichier comme une seule chaîne), plus ça va se sentir (il m'arrive de compter la différence en minutes lorsque ça se couple avec de la recherche intensive de fichiers). Or, on a rarement besoin de s'appuyer sur une représentation correcte des caractères qui ne sont pas dans l'ASCII.

                        Note également que je ne suis pas le seul à mentionner le coût d'UTF-8, Perl, dont c'est pourtant la grande spécialité, le documente même dans perlunicode :

                        Speed
   Some functions are slower when working on UTF-8 encoded strings than on byte encoded strings.  All
   functions that need to hop over characters such as length(), substr() or index(), or matching regular
   expressions can work much faster when the underlying data are byte-encoded.

   In Perl 5.8.0 the slowness was often quite spectacular; in Perl 5.8.1 a caching scheme was introduced
   which will hopefully make the slowness somewhat less spectacular, at least for some operations.  In
   general, operations with UTF-8 encoded strings are still slower. As an example, the Unicode properties
   (character classes) like "\p{Nd}" are known to be quite a bit slower (5-20 times) than their simpler
   counterparts like "\d" (then again, there 268 Unicode characters matching "Nd" compared with the 10
   ASCII characters matching "d").

                        • [^] # Re: Utilité

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

                          Super capitaine Obvious : tu prends exemple sur des commandes (et pas des scripts) qui manipulent des chaines de caractères, forcément ça va impacter (puisque du coup il faut faire attention au multi-octet).

                          Je n'ai pas dit qu'aucun script n'était impacté, ni qu'aucune commande n'était impactée, juste que c'est pas la majorité. Dit-moi si un script de backup (genre du sftp hop) est impacté. Dit moi si un script complet, et pas qu'une commande, est impacté de beaucoup. Combien "coûte" UTF-8 sur l'ensemble des scripts d'une Distro? Combien de temps en plus pour l'ensemble du travail d'un serveur?

                          Tu prend des exemples spécifiques, très spécifiques, pour te conforter, mais tu ne prends pas la vie réelle avec des scripts qui ne font pas que des grep/awk/length/substr. Pour info, les scripts et PERL ont plein d'autres fonctions que la manipulation de chaines de caractère.

                          UTF-8 est peanuts en perte de performances, si il faut démontrer regarde juste toutes les distros, elles sont en UTF-8 par défaut et pas foule pour crier qu'il faut changer ça pour optimiser une machine.

                          • [^] # Re: Utilité

                            Posté par  . Évalué à 5.

                            La base de la programmation Shell, jusqu'à preuve du contraire, consiste à récupérer la sortie d'une commande -- une sortie texte, donc -- pour la traiter avec une autre commande (c'est pour ça qu'on a inventé le tube). Ce que je montre touche donc le cœur de la programmation Shell, et tous les scripts seront donc plus ou moins touchés. Évidemment, si pour toi un script Shell, c'est deux mv et trois cp, ça pas changer grand chose, mais ça, ce n'est pas de la programmation Shell.

                            Concernant Perl, j'ai écrit que c'était sa grande spécialité, pas sa spécialité exclusive. Être agressif est une chose, mais ce serait sympa de lire les messages en entier au préalable.

                            Concernant les distros UTF-8, ça ne ce voit pas pour la bonne raison que la locale est généralement positionnée en toute fin d'init et qu'au fond il y a peu d'outils Shell dont on se sert intensivement et quotidiennement*, sauf à les programmer soi-même. Par ailleurs, la plupart des utilisateurs emploient des interfaces graphiques, où évidemment ça ne se sent peu ou pas (tu n'attends pas de retour de prompt, et beaucoup de chose sont montées et gardées en mémoire avec la première exécution).

                            * un contre-exemple, si tu veux : Slackware, dont les outils de gestion sont en Shell et qui du coup force certaines opération à être en locale C.

                        • [^] # Re: Utilité

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

                          Tous les utilitaires sont plus ou moins ralentis.

                          Autant le faible écart pour sed et awk ne me choque pas (d’autant moins que je ne le reproduis pas fidèlement ici), autant l’écart avec grep, parfaitement reproductible, est énorme.

                          Une telle différence n’est pas normale, à mon avis ça traduit plus un bug de grep qu’un problème général posé par UTF-8.

                          • [^] # Re: Utilité

                            Posté par  . Évalué à 2.

                            Oui, le problème de grep est connu depuis longtemps, mais doit être lié à la manière dont la commande est codée, de telle sorte qu'il n'est pas simple de le résoudre. C'est néanmoins un cas intéressant car grep reste une commande très utilisée malgré ça.

                            Pour les autres benchs, c'est sûr que sur une machine "normale", ça n'a pas d'impact sensible hormis quand on fait des scripts élaborés. Et encore, une fois qu'on a pris le coup de systématiquement forcer la locale à C (ce qui est malheureusement impossible avec AWK), on résout pas mal de soucis ; ce sont juste des petits trucs à savoir.

                            En fait, ma position ici vient du fait que je suis passé de Latin9 à UTF-8 et que, rétrospectivement, je trouve que ça m'a apporté (relativement) plus de complications que d'avantages concrets. C'est très vivable au quotidien -- à part mes scripts et des trucs comme xdvi et xmessage, pas de ralentissement majeur à déplorer -- mais si c'était à refaire aujourd'hui, ça me paraîtrait tout aussi sensé de rester en Latin9. C'est pourquoi je pense que c'est une option d'autant plus à étudier si on a une machine un peu vieille avec un petit processeur et un espace disque limité (un fichier encodé en UTF-8 prend plus de place que sa contre-partie ISO, la faute aux caractères non-ASCII codés sur deux octets au lieu d'un).

                            • [^] # Re: Utilité

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

                              si on a une machine un peu vieille avec un petit processeur

                              Tu n'as toujours pas démontré que dans l'ensemble, ça a un impact significatif sur les perfs globales de la machine. Ta machine fait en permanence des grep sur 50% du CPU pour que ça ai un impact pour toi?

                              et un espace disque limité

                              Ton dernier commentaire: 1323 octets en Latin-9, 1367 octets en UTF8. "Perte" de 3%. Quelle misère!

                              C'est exactement le genre d'optimisation comme ceux qui compilent pour un CPU super-précis par rapport au défaut "c'est pour optimiser, c'est démontré", juste que c'est pas du tout rentable et il reste juste quelques rares masochistes à le faire, pareil pour garder Latin-9 : tout va bien, jusqu'au jour où tu devras partager le fichier avec un gus qui n'a pas cette locale (si si, ça arrive, on vit dans un monde qui s'afranchit des frontières), alors qu'avoir UTF-8 simplifie grandement la vie au prix d'un pauvre 3% de plus en espace disque et à peine plus de CPU. Heureusement qu'il y en a qui regardent l’intérêt réel, maintenant à a toutes nos distros en UTF-8.

                              • [^] # Re: Utilité

                                Posté par  . Évalué à 2.

                                Tu n'as toujours pas démontré que dans l'ensemble, ça a un impact significatif sur les perfs globales de la machine

                                Je sèche, homme admirable, as-tu une idée de comment mesurer une telle chose ? si je te disais démontre-moi qu'UTF-8 n'a aucun impact global, que pourrais-tu répondre à part que ça paraît globalement fluide ?

                                Or globalement, ça signifie en mode graphique et en console. En mode graphique, c'est impossible à quantifier pour des raisons déjà évoquées. Par exemple, si sur un même navigateur tu charges la même page en laissant un écran blanc jusqu'à ce que la page soit entièrement calculée ou en affichant progressivement d'abord les cadres les uns au dessous des autres, puis les cadres positionnés, puis les images, le deuxième rendu va te paraître aller plus vite que le premier.

                                Pour ce qui est de la console, c'est très différent car on n'est pas dans quelque chose de continu. On admet en général qu'on perd l'impression de fluidité aux alentours d'une demi-seconde de traitement. Donc, UTF-8 va avoir beaucoup plus d'impact sur le ressenti en console, d'autant que la machine est faible. Moi qui utilise la console intensivement (le nombre d'applications graphiques que j'utilise régulièrement se compte sur les doigts d'une main) et scripte énormément je le constate très fréquemment. C'est pourquoi si j'avais une petite/vieille machine, j'étudierais sérieusement l'option 8bits pour en tirer le meilleur parti.

                                Ton dernier commentaire: 1323 octets en Latin-9, 1367 octets en UTF8. "Perte" de 3%. Quelle misère!

                                Sur un disque de moins d1Go où tu dois précautionneusement arbitrer entre le système et les données, ça peut être non négligeable. Et puis je pourrais faire comme toi: démontre-moi que mon commentaire est représentatif de ce qu'on écrit globalement en français. Peut-être que ce n'est pas 3 mais 10 ou 15% de pénalité dans la réalité !

                                C'est exactement le genre d'optimisation comme ceux qui compilent pour un CPU super-précis par rapport au défaut "c'est pour optimiser, c'est démontré", juste que c'est pas du tout rentable et il reste juste quelques rares masochistes à le faire, pareil pour garder Latin-9 : tout va bien, jusqu'au jour où tu devras partager le fichier avec un gus qui n'a pas cette locale (si si, ça arrive, on vit dans un monde qui s'afranchit des frontières), alors qu'avoir UTF-8 simplifie grandement la vie au prix d'un pauvre 3% de plus en espace disque et à peine plus de CPU. Heureusement qu'il y en a qui regardent l’intérêt réel, maintenant à a toutes nos distros en UTF-8.

                                Sauf que dans la vie réelle, ma glibc me permet de décoder/encoder les fichiers comme je veux (fais un iconv -l, pour t'en convaincre) et donc de partager avec n'importe qui.

                                Sauf que dans la vie réelle, j'en n'aurai même pas besoin parce que vim me permet d'éditer avec l'encodage de mon choix.

                                Sauf que dans la vie réelle, la seule langue que je baragouine à part le Français c'est l'Anglais, donc afficher le Cyrillique, les Kanjis ou l'Arabe, ça ne m'avance pas beaucoup par rapport à une pâtée 8bits.

                                Sauf que dans la vie réelle, les distros pour vieilles machines balancent les locales à part POSIX/en_US pour gagner de la place.

                                Sauf que dans la vie réelle, j'ai passé des années en Latin9 sans en souffrir plus que ça.

                                Est-ce qu'au moins, dans la vie réelle, tu te rends compte que tu en es à prétendre connaître mieux que moi mes besoins et l'usage que j'ai de ma machine ?

                                • [^] # Re: Utilité

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

                                  Sauf que dans la vie réelle, ma glibc me permet de décoder/encoder les fichiers comme je veux (fais un iconv -l, pour t'en convaincre) et donc de partager avec n'importe qui.

                                  Sauf que dans la vie réelle, j'en n'aurai même pas besoin parce que vim me permet d'éditer avec l'encodage de mon choix.

                                  Personnellement, je préfère accepter de perdre un chouia de performances pour ne pas avoir à me poser la question de l’encodage. L’ordinateur n’est-il pas là pour me simplifier la vie ? Quand j’écris avec un stylo sur du papier, je n’ai pas à me demander quel encodage je dois utiliser pour tracer tel caractère…

                                  Gérer de façon transparente ce genre de détails est quand même, selon moi, la moindre des choses que l’on est en droit de demander à une puce qui renferme dans quelques millimètres carrés plus de puissance de calcul qu’il n’en a fallu pour concevoir la bombe atomique ou envoyer un homme sur la lune (et je ne parle pas forcément d’un octo-cœur à 4 GHz, hein).

                                  Sauf que dans la vie réelle, la seule langue que je baragouine à part le Français c'est l'Anglais, donc afficher le Cyrillique, les Kanjis ou l'Arabe, ça ne m'avance pas beaucoup par rapport à une pâtée 8bits.

                                  Je ne parle pas un mot de serbe, de suédois ou de polonais, ce qui n’empêche pas ma bibliographie de comporter des travaux de dénommés Radosavljević, Čuboňová, Meşe, Kågedal, Macůrek ou Chełstowska. Autant de noms que je peux avoir avois besoin de citer dans un document bien franco-français destinés à des seuls francophones de France. Quel encodage 8 bits me permet d’écrire en français sans écorcher les noms du reste du monde ? C’est un problème insurmontable par définition avec les encodages régionaux.

                                  Sauf que dans la vie réelle, j'ai passé des années en Latin9 sans en souffrir plus que ça.

                                  Tant mieux pour toi. Tu es libre de rester en Latin-9 si ça te convient. Mais ne t’étonne pas si le reste du monde pousse vers l’UTF-8 (enfin, j’espère).

                                  • [^] # Re: Utilité

                                    Posté par  . Évalué à -1.

                                    Personnellement, je préfère accepter de perdre un chouia de performances pour ne pas avoir à me poser la question de l’encodage. L’ordinateur n’est-il pas là pour me simplifier la vie ? Quand j’écris avec un stylo sur du papier, je n’ai pas à me demander quel encodage je dois utiliser pour tracer tel caractère…

                                    Tu n'auras pas le choix, tu te poseras toujours la question de l'encodage. Un fichier texte, tant que tu n'en connais pas l'encodage, c'est juste du binaire. UTF-8 n'y change rien. C'est pas pour rien que sur une page HTML bien formée, tu as une déclaration de l'encodage qui doit arriver le plus tôt possible... Quand des applications doivent manipuler des documents extérieures, UTF-8 ou pas, il est essentiel de déclarer les encodage de ceux-ci (qui après peut être latin1, UTF-16, UTF-32 ou ce que tu veux).

                                    Je ne parle pas un mot de serbe, de suédois ou de polonais, ce qui n’empêche pas ma bibliographie de comporter des travaux de dénommés Radosavljević, Čuboňová, Meşe, Kågedal, Macůrek ou Chełstowska. Autant de noms que je peux avoir avois besoin de citer dans un document bien franco-français destinés à des seuls francophones de France.

                                    Biographie que tu publies en texte brut ? non, tu le feras en PDF ou en HTML, langages dans lesquels tu n'auras aucun soucis et qui n'impliquent aucune locale spécifique.

                                    De plus, combien de gens vont connaître la différence de prononciation entre Macůrek et Macurek ? est-ce un crime impardonnable décrire « Dostoïevski » au lieu de «Достоевский» ? la latinisation des noms a-t-elle jamais été un frein aux échanges culturels ? un bonne partie du français lui-même, pour pousser encore plus loin, n'est-elle pas juste une latinisation du grec ?

                                    Enfin, n'oublie pas également que des générations d'écrivains ont employé des machines à écrire à disposition azerty, puis des traitements de texte avec des encodages limités (pas de cadratin &cie.). Ça ne les a pas empêché d'écrire du français correct, ni de faire évoluer la littérature. Le double-guillemet droit en lieu et place du chevron fait sûrement s'étrangler les vieilles barbes de l'Académie Française, il n'empêche pas le français d'être du français.

                                    Je ne parle pas spécialement pour toi, mais les VRP du progrès ne laisseront de me fasciner : à les entendre, aujourd'hui est déjà hier et hier est juste impossible. :)

                                    • [^] # Re: Utilité

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

                                      Tu n'auras pas le choix, tu te poseras toujours la question de l'encodage.

                                      Bah ça fait pourtant des années que je ne me la suis pas posée. Tant que je reste chez moi, la question ne ne pose pas parce que tout est en UTF-8. Je n’ai pas besoin de me demander, au moment de sauver un fichier, « quels caractères contient-il et quel encodage devrais-je utiliser ? »

                                      Lorsque le fichier sort de chez moi, pareil : je l’envoie sans me soucier de son encodage. Mon client mail ajoute automatiquement un en-tête Content-Type: text/plain; charset=UTF-8. Comment mon client mail sait-il que le fichier est en UTF-8 ? Je n’ai pas regardé, mais je suppose sur un système dont la locale est en_US.UTF-8, il considère que les pièces jointes sont en UTF-8 par défaut, ce qui est exactement ce que je veux (si je me mettais à utiliser un autre encodage, là je serais sans doute obligé de le spécifier manuellement — c’est exactement ce que je ne veux pas).

                                      Lorsque le fichier vient de l’extérieur (reçu par e-mail, téléchargé depuis la toile, etc.), la question de l’encodage ne se posera que si « l’émetteur » du fichier n’a pas précisé l’encodage (serveur web mal configuré, balise « META » absente, client mail n’envoyant pas d’en-tête MIME…). Ça arrive encore quelque fois, mais je constate que ça devient très rare. Des collègues ou amis qui ne savent probablement même pas ce qu’est un « encodage de caractères » parviennent à m’envoyer des fichiers que mon éditeur n’a aucune peine à afficher correctement. Ou bien je les sous-estime et ils savent en réalité tout de cette problématique, ou bien leurs systèmes et leurs logiciels arrivent très bien à gérer cette épineuse question de façon transparente (ce qui, je le répète, est pour moi la moindre des choses).

                                      Biographie que tu publies en texte brut ? non, tu le feras en PDF ou en HTML, langages dans lesquels tu n'auras aucun soucis et qui n'impliquent aucune locale spécifique.

                                      Encore une fois, non, je ne vais pas systématiquement utiliser LaTeX pour le moindre petit bout de document que je peux avoir besoin d’écrire. LaTeX (ou tout autre système de traitement de texte) répond à un besoin bien précis, pas à tous.

                                      Je ne comprends pas. Tu te plains de l’augmentation de complexité induite par UTF-8, mais tu pousses à l’utilisation d’usines à gaz à la place ?

                                      De plus, combien de gens vont connaître la différence de prononciation entre Macůrek et Macurek ?

                                      Je ne la connais pas, personnellement. Est-ce une raison pour écorcher le nom ?

                                      Certes, la francisation des noms est tout-à-fait acceptable quand on ne peux pas faire autrement (Angström voire Angstrœm au lieu de Ångström, Ceausescu au lieu de Ceauşescu, Sarkozy au lieu de Sarközy…). Mais justement, avec UTF-8 il est possible de faire autrement, et ce en toutes circonstances (et non pas uniquement quand on prépare un document destiné à la publication avec LaTeX). Pourquoi faudrait-il s’en priver ? Parce que des informaticiens à l’esprit étroit ne voyant pas plus loin que le bout de leurs frontières ont décidé que 256 caractères suffiraient bien pour tout le monde (sont-ce les mêmes informaticiens que ceux qui ont dit que personne n’aurait jamais besoin de plus de 640 ko de mémoire ?), et que pour les « exotiques » (comprendre, les non-occidentaux), bah tant pis mais ça ne va pas être possible ?

                                      Granted, si j’écris « Macurek et al. (2008) » au lieu de « Macůrek et al. (2008) », je ne connais personne qui m’en tiendra rigueur (surtout pas mon chef, pourtant d’originaire d’Europe orientale, qui n’en aura rien à cirer). Mais moi, ça me dérangera. Mon troisième prénom est Jean-Noël, et en bon vieux con briseur de noix qui se respecte, je n’aimerais pas le voir écrit Jean-Noel par un étranger au motif fallacieux que son encodage régional ne contient pas de « ë ».

                                      Enfin, n'oublie pas également que des générations d'écrivains ont employé des machines à écrire à disposition azerty, puis des traitements de texte avec des encodages limités (pas de cadratin &cie.).

                                      Et des générations de typographes ont utilisé tout l’éventail des caractères disponibles, n’hésitant pas à en inventer quand il le fallait. Et des générations d’écrivains ont écrit à la main sans jamais être freiné par la moindre limitation technique. Le caron (le diacritique ˇ) utilisé pour transcrire certains phonèmes des langues slaves a été inventé au quinzième siècle, et a longtemps été utilisé sans problèmes par ceux qui en avaient besoin. Il n’y avait pas d’informaticiens ou de constructeur de machines à écrire en ce temps-là pour dire « arrêtez d’avoir des idées, on n’a pas de place pour les encoder. »

                                      Ce n’est pas parce qu’on a connu au vingtième siècle une période où les limitations techniques étaient fortes qu’il faudrait considérer lesdites limites comme allant de soi sans jamais chercher à les dépasser.

                                      Avec un raisonnement comme le tien, Donald Knuth se serait contenté du rendu médiocre de son livre The Art of Computer Programming que lui proposaient les logiciels de composition des années 70, et il n’aurait jamais écrit TeX…

                                      Le double-guillemet droit en lieu et place du chevron fait sûrement s'étrangler les vieilles barbes de l'Académie Française, il n'empêche pas le français d'être du français.

                                      Pour autant que je sache, l’Académie française (pas de majuscule à « française » ici) ne se préoccupe pas des questions de typographie. Mais il y a d’autres vieux cons (et des moins vieux, merci) que le guillemet droit fait s’étrangler.

                                      Encore une fois, tu es parfaitement libre de continuer à utiliser un encodage européen occidental si tes besoins ne vont pas au-delà. Mais dans la vie réelle (© 2011 dr_home), tes besoins et tes attentes ne sont pas ceux de tout le monde.

                                      • [^] # Re: Utilité

                                        Posté par  . Évalué à -1.

                                        je n’ai pas regardé, mais je suppose sur un système dont la locale est en_US.UTF-8, il considère que les pièces jointes sont en UTF-8 par défaut, ce qui est exactement ce que je veux (si je me mettais à utiliser un autre encodage, là je serais sans doute obligé de le spécifier manuellement — c’est exactement ce que je ne veux pas).

                                        Pas du tout, une locale fr_FR est Latin1, une locale fr_FR@euro est Latin9. Les langues ont un encodage par défaut, ISO-8859-1 pour le français, mais POSIX prévoit qu'on peut spécifier un encodage à la fin de la locale, ce que tu fais quand tu choisis fr_FR@euro ou fr_FR.utf8.

                                        Mon client envoie par ailleurs les mails dans l'encodage qu'il juge le plus approprié : ASCII quand j'écris en anglais, ISO-8859-1 si aucun caractère Unicode n'est requis.

                                        Avec un raisonnement comme le tien, Donald Knuth se serait contenté du rendu médiocre de son livre The Art of Computer Programming que lui proposaient les logiciels de composition des années 70, et il n’aurait jamais écrit TeX…

                                        Et qu'était-ce alors TeX, si ce n'est un moyen d'avoir une typo de qualité à partir de l'ASCII ? Relativement à l'histoire de TeX, ça ne fait pas si longtemps qu'on peut mettre de l'UTF-8 dans les codes sources au lieu d'écrire \moncaracterespecial, qui reste la solution la plus portable (mais la moins pratique, j'en conviens).

                                        TeX vise à produire des documents imprimés de qualité, c'est tout autre chose que le texte brut qui ne sera jamais optimal (n'es-tu pas sensible aux ligatures, aux indentations, et à la justification des paragraphes ? )

                                        À chaque sortie ses exigences, que les écrivains rendent un tapuscrit non typographiquement soigné n'implique pas que l'édition finale le sera. Ça n'empêche juste pas de produire des choses intéressantes.

                                        Mais dans la vie réelle (© 2011 dr_home), tes besoins et tes attentes ne sont pas ceux de tout le monde.

                                        Ai-je jamais soutenu autre chose ? ai-je même contesté que tu puisses arbitrer qu'écrire le Tchèque en texte brut est une raison suffisante pour passer à l'UTF-8 ? c'est vous qui depuis le départ contestez que Latin9 est un choix aussi rationnel et valable qu'UTF-8...

                                        • [^] # Re: Utilité

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

                                          Relativement à l'histoire de TeX, ça ne fait pas si longtemps qu'on peut mettre de l'UTF-8 dans les codes sources au lieu d'écrire \moncaracterespecial, qui reste la solution la plus portable (mais la moins pratique, j'en conviens).

                                          Portable ? C’est totalement spécifique à TeX. UTF-8 a pour lui d’être utilisable en toutes circonstances (comme sur ce site web, par exemple).

                                          En quoi est-ce gênant ? Et bien pour mon fichier de bibliographie, par exemple. Je ne l’utilise pas qu’avec LaTeX, je m’en sers aussi pour gérer (consulter, chercher, etc.) ma bibliographie même lorsque je n’ai pas de document à écrire. Si le fichier était encodé en ASCII avec des séquences d’échappement à-la-TeX, mon gestionnaire de bibliographie devrait soit interpréter lesdites séquences d’échappement soit m’afficher « Mac\r{u}rek » (ce que je n’aimerais pas du tout voir). Heureusement, mon fichier est encodé en UTF-8, ce qu’aussi bien TeX que mon gestionnaire de bibliographie savent gérer aujourd’hui, du coup tout le monde est content.

                                          TeX vise à produire des documents imprimés de qualité, c'est tout autre chose que le texte brut qui ne sera jamais optimal (n'es-tu pas sensible aux ligatures, aux indentations, et à la justification des paragraphes ? )

                                          Je ne suis pas insensible aux autres subtilités de l’orthotypographie, mais pouvoir représenter toutes sortes de caractères et composer un texte sont deux choses différentes. UTF-8 rend la première chose possible indépendamment de la seconde. Encore une fois, comme sur ce site par exemple, où nous n‘avons pas besoin d’un système de composition pour afficher les caractères que nous avons — c’est-à-dire, que j’ai ;) — envie d’afficher.

                                          Ai-je jamais soutenu autre chose ? ai-je même contesté que tu puisses arbitrer qu'écrire le Tchèque en texte brut est une raison suffisante pour passer à l'UTF-8 ? c'est vous qui depuis le départ contestez que Latin9 est un choix aussi rationnel et valable qu'UTF-8...

                                          Tu dois me confondre avec Zenitram. Comme je l’ai dit à deux reprises déjà, je n’ai aucun problème avec le fait que tu choisisses d’utiliser un encodage régional — tant que ton client mail est configuré pour me dire quel est l’encodage en question, si jamais tu dois m’envoyer un message.

                                          Je réagissais simplement pour dire qu’il y avait d’autres raisons justifiant pour certains le choix d’UTF-8 que le seul plaisir de la complexité ou la volonté machiavélique de pourrir la vie des programmeurs et des utilisateurs de vieilles machines.

                                          For the record, je suis entièrement d’accord avec la conclusion d’un de tes précédents messages :

                                          c'est une question d'équilibre entre besoins et désagréments

                                          Là où je ne suis absolument pas d’accord avec toi, c’est quand tu sembles dire que des contraintes techniques (ici, l’encodage des caractères) doivent dicter les comportements de l’utilisateur (ici, la façon d’écrire). Moi, je veux que ma machine s’adapte à mes lubies et non l’inverse, d’où mon choix de l’UTF-8 et de ses désagréments.

                                          • [^] # Re: Utilité

                                            Posté par  . Évalué à -1.

                                            Portable ? C’est totalement spécifique à TeX. UTF-8 a pour lui d’être utilisable en toutes circonstances (comme sur ce site web, par exemple).

                                            Je veux dire que c'est de l'ASCII, supporté par la totalité des systèmes au monde ou probablement pas très loin.

                                            Ton "œ", même en UTF-8, il faut que le destinataire utilise une police qui le contienne pour le voir, contrairement à "\oe".

                                            Encore une fois, comme sur ce site par exemple, où nous n‘avons pas besoin d’un système de composition pour afficher les caractères que nous avons — c’est-à-dire, que j’ai ;) — envie d’afficher.

                                            Mais la manière dont ce site web va s'afficher n'a rien à voir avec la locale. Firefox en locale C est capable de t'afficher de l'UTF-8...

                                            Au fond ta locale va affecter le rendu de très peu de choses ; dès que tu vas sortir du texte brut, il y a de grandes chances que tu ne t'en aperçoives pas.

                                            De plus, ce n'est pas UTF-8/Unicode en lui-même que je mets en cause, je trouve ça très bien, moi, UTF-8 ! ce que je mets en cause c'est le fait qu'on dise que c'est automatiquement meilleur que Latin9 et qu'en dehors de lui point de salut.

                                            Sur un P.II avec moins de 100Mo de RAM, la question peut se poser, je trouve. D'autant si pour l'utilisateur le texte brut qu'il tape est du source (ex. LaTeX, Groff, HTML, etc. ) ou du README (contenu purement informationnel). Personnellement, je trouve que la mise en forme en texte brut est une plaie (quand il faut insérer un item dans une liste ordonnée, quand il faut se taper la re-justification des paragraphes -- avec qui plus est l'absence d'insécable qui génère d'horrible lignes commençant par un chevron ou deux points -- quand il faut insérer des notes en bas de pages, etc. ) qui selon moi ne donne que des résultats de qualité médiocre. C'est pourquoi, quand je veux une sortie léchée, je préfère prendre les outils faits pour ça.

                                            Du coup, écrire un tchèque parfait en texte brut me paraît une lubie pas plus ni moins censée que pour d'autres vouloir économiser une poignée de secondes d'exécution sur un script.

                                            Là où je ne suis absolument pas d’accord avec toi, c’est quand tu sembles dire que des contraintes techniques (ici, l’encodage des caractères) doivent dicter les comportements de l’utilisateur (ici, la façon d’écrire). Moi, je veux que ma machine s’adapte à mes lubies et non l’inverse, d’où mon choix de l’UTF-8 et de ses désagréments.

                                            Non, le sens de mon message c'est que l'absence de contrainte ne fait pas des choses automatiquement meilleures et qu'on peut faire beaucoup avec peu, ce principalement parce que la technologie est secondaire par rapport à l'intelligence.

                                            Tu n'as qu'à penser à l'anglais "international", par exemple, c'est plutôt approximatif du point de vue grammatical et formel, mais ça marche quand même bien quand on voit le nombre de gens qui arrivent à communiquer grâce à lui. Ce qui -- pour poursuivre l'analogie et être totalement clair, même si sur le fond je crois qu'on est d'accord -- ne veut évidemment pas dire que je considère à l'inverse les parfaits anglophones comme des pédants nuisibles.

                                        • [^] # Re: Utilité

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

                                          Non, tex c'est pas portable.

                                          Exemple concret de qui viens de m'arriver à l'instant : je sélectionne un texte dans un pdf généré avec latex, et en le collant cela donne

                                          D ́finir un pr ́dicat consequence_l qui prend en argument un contexte Γ et une e e formule F et indique si F est cons ́quence s ́mantique de Γ.

                                          Et non, le fichier tex d'origine je l'ai pas.

                            • [^] # Re: Utilité

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

                              Oui, le problème de grep est connu depuis longtemps, mais doit être lié à la manière dont la commande est codée, de telle sorte qu'il n'est pas simple de le résoudre.

                              Apparemment, il est résolu. Je viens de compiler grep 2.7 et de refaire les tests, j’obtiens peu ou prou la même chose qu’avec sed : le temps d’exécution est plus long avec LANG=en_US.UTF-8 mais reste dans le même ordre de grandeur qu’avec LANG=C (et non trois ordres de grandeur au-dessus comme avec grep 2.5.4).

                              En fait, ma position ici vient du fait que je suis passé de Latin9 à UTF-8 et que, rétrospectivement, je trouve que ça m'a apporté (relativement) plus de complications que d'avantages concrets.

                              Après être passé de latin-1 à UTF-8, je pense exactement le contraire. :)

                              J’admets volontiers que la période de transition, quand on a des trucs déjà en UTF-8 d’un côté et d’autres trucs encore en latin-1 de l’autre, est délicate, surtout quand le support d’UTF-8 par les logiciels est encore fragmentaire (de mémoire, c’est LaTeX et surtout BibTeX qui m’avait posé le plus de problèmes). Mais après, quand tout est en UTF-8, depuis les noms de fichiers jusqu’aux contenus des documents en passant par les tags des fichiers Vorbis, et qu’on n’a plus à se poser la question de l’encodage… je ne le regrette pas.

                              • [^] # Re: Utilité

                                Posté par  . Évalué à 1.

                                Apparemment, il est résolu.

                                Tant mieux, ça faisait un bout de temps que ça traînait. Bon après, il faudrait voir en usage réel. Si tu veux t'amuser, tu peux essayer ce petit bout de AWK, qui simule ce que les perleux connaissent bien sous le nom de "slurp" (le fichier est traité comme une chaîne):

                                BEGIN { RS="\033"}
{BUFFER = BUFFER $0}
END{
  while(match(BUFFER, /e/)) {
    sub(/e/, "", BUFFER)
  }
}

time awk -f funny.awk /etc/services 

real    0m36.394s
user    0m34.407s
sys     0m0.019s

time LC_ALL=C awk -f funny.awk /etc/services 

real    0m0.910s
user    0m0.905s
sys     0m0.002s

time LC_ALL=C oawk -f funny.awk /etc/services 

real    0m3.633s
user    0m3.619s
sys     0m0.004s

                                L'implémentation GNU awk a en général une très bonne tenue, on voit même ici que dans un environnement 8bits, elle se comporte mieux que celle de Kernighan (AWK = "Aho Weinberger Kernighan", ses fondateurs), qui n'a pas de support pour les caractères multi-octets.

                                La nette dégradation des performances vient du fait que pour positionner la variable implicite RSTART (le début dans la chaîne principale de la sous-chaîne décrite par la regex), awk est obligé de savoir ce qu'est un caractère et donc de sortir du confortable "1 octet = 1 caractère". Bref, dès qu'on a vraiment besoin (c'est une longue chaîne) de s'appuyer sur une représentation UTF-8, on paye le prix (par bonheur, on peut souvent se contenter d'une représentation 8bits).

                                J’admets volontiers que la période de transition, quand on a des trucs déjà en UTF-8 d’un côté et d’autres trucs encore en latin-1 de l’autre, est délicate, surtout quand le support d’UTF-8 par les logiciels est encore fragmentaire

                                Disons qu'une fois que c'est fait, on n'a plus vraiment envie de se retaper tout dans le sens inverse. :)

                        • [^] # Re: Utilité

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

                          Quand on lance

                          LANG=C grep 7 /tmp/out >/dev/null

                          au lieu de 
                          grep 7 /tmp/out >/dev/null
                          on fait deux choses qui influent sur les performances du programme: on change la LOCALE, c'est l'effet le plus visible, et on change l'alignement mémoire du programme, c'est l'effet le moins visible mais il est loin d'être anodin. Dans cet article on peut lire:

                          We see that something external and orthogonal to the program, i.e., changing the size (in bytes) of an unused environment variable, can dramatically (frequently by about 33% and once by almost 300%) change the performance of our program.

                          C'est à dire que l'importante différence de temps d'éxécution est peut-être en partie due à la différence de taille de l'environnement (qui change l'alignement des données du programme). Pour une mesure plus fiable, il faudrait ajouter une variable de padding.
                          Avec LANG=C on ajoute 6+1 octets à l'environnement, la sensibilité à l'alignement est probablement liée à l'orgine du bloc de données modulo 32 ou 64 (la taille du bus mémoire). Pour pallier cet effet, on pourrait ajouter 57 octets à l'environnement en ajoutant la liaison

                          X=123456789012345678901234567890123456789012345678901234
                          à l'environnement.

                          Autre chose: après l'éxécution de la première ligne de commande le programme grep, ses bibliothèques et le fichier de données sont sûrement en mémoire dans l'ordinateur en le temps que passe l'OS à les chercher n'intervient pas dans la mesure du second temps.

                          J'ai testé ton exemple grep chez moi, avec plusieurs tailles de fichier out et les trois dispositions d'environnement discutées, dans observer de tendance favorisant l'une des trois formes d'appel.

                        • [^] # Re: Utilité

                          Posté par  . Évalué à 8.

                          Comme le faisait remarquer Zenitram, à l'époque des vidéos HD, l'impact est négligeable.

                          $ seq 10000 >/tmp/out
$ time grep 7 /tmp/out >/dev/null

real	0m0.004s
user	0m0.000s
sys	0m0.000s

$ time LANG=C grep 7 /tmp/out >/dev/null 
real	0m0.003s
user	0m0.000s
sys	0m0.000s

$ seq 1000000 > /tmp/out
$ time grep 7 /tmp/out > /dev/null 

real	0m0.084s
user	0m0.080s
sys	0m0.000s

$ time LANG=C grep 7 /tmp/out >/dev/null

real	0m0.057s
user	0m0.050s
sys	0m0.000s

                          Et je n'ai pas une machine de guerre.

                          Vu ce que l'UTF-8 apporte pour son coût, vous m'en mettrez deux.

                    • [^] # Re: Utilité

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

                      En « texte brut », oui, mais en général les ouvrages ne peuvent se permettre d'être écrits en "texte brut". Ils ont besoin de mises en forme beaucoup plus élaborées qui supposent des outils auxquels les caractères "spéciaux" (disons "précis") ne posent aucun problème.

                      Et lorsqu’on n’a pas de gros besoins de mise en forme, mais qu’on veut quand même écrire correctement, il faudrait obligatoirement utiliser ces « outils » dédiés sensiblement complexes ? J’aime beaucoup LaTeX, mais de là à le sortir pour le moindre bout de document…

                      La disponibilité d’UTF-8 me permet de me contenter d’un banal fichier en « texte brut » sans pour autant devoir faire l’impasse sur les « caractères spéciaux » (qui n’on en fait rien de spéciaux) lorsqu’ils sont nécessaires. Surtout quand on ajoute la facilité avec laquelle on peut saisir toutes sortes de caractères sous X.11.

                      Je trouve de plus qu'en ISO-8859-15 (fr_FR@euro), on arrive quand même à écrire très correctement le français.

                      Mouais, on peut parler d’argent en euros et écrire une recette de cuisine à base d’œufs. Mais on n’a toujours pas de tiret cadratin — donc pas d’incise —, pas de véritable apostrophe (la courbe), pas de trois points… Et absolument aucune possibilité d’insérer ponctuellement un caractère non-français (ce qui peut être nécessaire même en écrivant exclusivement en français, par exemple lorsque je veux parler d’intégrine α5β1), à moins d’utiliser un traitement de texte et de changer de police (adieu le texte brut).

                      Et il y a toujours le risque, lorsque le texte est destiné à être transmis (par e-mail par exemple), que l’encodage ne soit pas compris à l’autre bout du fil (en UTF-8 aussi, certes, mais je pense que le risque est plus élevé avec la multitude des encodages 8-bits régionaux qu’avec l’UTF-8 qui a vocation à être utilisé partout).

                      • [^] # Re: Utilité

                        Posté par  . Évalué à 0.

                        Comme je le dis, c'est une question d'équilibre entre besoins et désagréments (je ne suis pas en train de crier « vive l'ISO ! » ). Moi ça ne me gène pas d'écrire "--", "...", et "ss" au lieu de cadratin, trois petits points et Etset. De toute manière mon clavier ou/et ma police ne me permettront pas de couvrir tout Unicode (je ne sais même pas faire un cadratin sur le mien), donc j'aurais besoin tôt ou tard d'un outil (autre que vim) pour abstraire tout ça. À chaque fin le bon moyen, c'est tout ce que je soutiens ici, en fait.

                        • [^] # Re: Utilité

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

                          c'est une question d'équilibre entre besoins et désagréments

                          Le problème est que tu n'arrives pas à préciser de vrais désagréments.
                          (alors qu'il y en a, par exemple la compatibilité avec les programmes ne supportant pas UTF-8).

                          Moi ça ne me gène pas d'écrire "--", "...", et "ss" au lieu de cadratin, trois petits points et Etset

                          Gloups sur Eszett (il te manque quelques lettres). ß et "ss" sont différents en prononciation (l'un est plus court que l'autre), et c'est vraiment par défaut sur Internet que les germanophones utilisent "ss" à la place de ß quand ils n'ont pas le choix. Ca gène d'autres personnes qu'on écrive "ss" à la place de ß. Et toi, tu es prêt à écrire hospital à la place d'hôpital car on aurait la flemme de mettre le o avec accent circonflexe dans Unicode et dans ton clavier?

                          • [^] # Re: Utilité

                            Posté par  . Évalué à 2.

                            comprends pas, moi j'ecris hopital.

                            • [^] # Re: Utilité

                              Posté par  . Évalué à 7.

                              Et dans ton hopital, quand il y a marqué « reserve aux internes » sur une porte, tu fais quoi? :)

                          • [^] # Re: Utilité

                            Posté par  . Évalué à 0.

                            Encore une fois, merci de bien vouloir lire (ie. essayer de comprendre le sens et les nuances de ce que l'autre a voulu faire passer) avant de critiquer.

                            (alors qu'il y en a, par exemple la compatibilité avec les programmes ne supportant pas UTF-8).

                            Ça tombe bien, je l'ai évoqué dans mon premier message.

                            Ca gène d'autres personnes qu'on écrive "ss" à la place de ß. Et toi, tu es prêt à écrire hospital à la place d'hôpital car on aurait la flemme de mettre le o avec accent circonflexe dans Unicode et dans ton clavier?

                            Il se trouve que l'ISO-8859-15 permet d'écrire un français que je juge très correct (et même de l'allemand, si tu veux, il y a le estzett -- dont les les Suisses se passent visiblement très bien), ce n'est pas une supposition, c'est un fait. Donc, la question de rester ou non en ISO-8859-15 pourrait se poser (par rapport à l'usage du système, à la configuration matérielle, etc. )

                            Je rappelle de plus qu'on parle ici de la locale, qui n'affecte en rien le support d'Unicode par les applications qui en on vraiment besoin (navigateurs, clients mail, etc. )

                            • [^] # Re: Utilité

                              Posté par  . Évalué à 1.

                              Oui oui, on peut écrire très correctement le français en latin9, pas de problème. Mais il y a des gens qui peuvent écrire à la fois en français et en arabe, en allemand et en russe, tu sais.

                              On peut même, chose incroyable, trouver plusieurs langues dans un même document. C'est qu'il y en a des pervers, en ce bas monde !

                              On peut savoir comment elle est supposée être gérée, la locale, pour que n'importe quel outil puisse traiter tous ces cas de figures ? De n'importe quel poste à n'importe quel autre ? Même en sortant de mon petit monde ?

                        • [^] # Re: Utilité

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

                          Notons qu'unicode est également ISO puisque ISO/CEI 10646 est son frère jumeaux.

                          Pour écrire le français convenablement sans passer par vim, je te conseil le bépo. Il permet aussi de faire des « ß », pour nos amis germanophones, bien qu'il me semble que la nouvelle orthographe permet l'emploi de deux s, non ?

                          • [^] # Re: Utilité

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

                            aussi de faire des « ß », pour nos amis germanophones, bien qu'il me semble que la nouvelle orthographe permet l'emploi de deux s, non ?

                            Ce sont deux choses différentes. Non interchangeables (la prononciation est différente).
                            LA nouvelle orthographe précise les choses. par exemple "daß" n’existe plus, remplacé par par "dass" (s plus alongé). Et autres... Bon, après, j'en suis qu'au début de l'apprentissage, d'autres sauraient donner plus d'exemples!

            • [^] # Re: Utilité

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

              Oui mais :

              1. une police est pas obligé de gérer tous les caractères unicode ;
              2. la police tu la télécharges qu'une fois sur ton système ;
              3. même quand tu embarques la police dans le document (pdf) tu n'embarques généralement que les glyphes utilisés.

              Donc non, tes polices de caractères ne pèseront pas plus lourd à mesure qu'unicode grandira. À la limite, tu peux dire que l'ASCII est moins lourd que l'UTF-8, qui est lui même moins lourd que l'UTF-16.

              Maintenant personne t'obliges à utiliser une police qui t'affiche quelque chose de significatif pour tous les caractères unicode. Si ASCII te suffit, tu peux virer les autres polices de ton système.

              • [^] # Re: Utilité

                Posté par  . Évalué à 5.

                Donc non, tes polices de caractères ne pèseront pas plus lourd à mesure qu'unicode grandira.

                Sans vouloir être méchant, Le but d'unicode est quand même de fournir un minimum d'interoperabilité et de lisibilité pour le lecteur final.

                Aucune police saine d'esprit ne va s'amuser à implémenter des 42 gazillions de signes actuellement inclus dans unicode. On se retrouve donc à devoir installer sur son ordi une floppée de police pour couvrir les caractères qui nous interressent. Avec 42 gazillions de signe disponibles, on risque d'avoir des polices différentes pour chaque pays/corps de métier.

                Si demain je reçois un document écrit avec (entre autres) trois polices que je ne possède pas, qui sont utilisés pour afficher des caractères rigolos, comment va faire mon ordi pour m'afficher des caractères au moins pseudo-corrects ?

                a) Il va scanner toutes les polices installées à la recherche d'une d'entre elle qui possèderait les caractères voulus.
                b) Il va afficher des gros rectangles baveux et laisser l'utilisateur rechercher parmis les 850 polices qu'il possède laquelle affiche ce #@!* de caractère.
                c) On s'arrange pour que le poste du créateur du doc ajoute des infos sur les caractères de la police de façon à accélerer la recherche (par exemple indication : ISO8859-15 pour le caractère € - Solution qui ferait bien rire tout le monde) d) Il demande votre numéro de carte de crédit pour acheter les polices qui vous manquent directement chez les fabriquants.

                J'ai de plus en plus l'impression qu'unicode est en train de renforcer les problèmes qu'il est supposé résoudre....

                • [^] # Re: Utilité

                  Posté par  . Évalué à 7.

                  On se retrouve donc à devoir installer sur son ordi une floppée de police pour couvrir les caractères qui nous interressent.

                  Exactement comme avant. Si tu veux lire des documents en coréen, vaut mieux que tu aies une police qui affiche le coréen... La différence, c'est qu'avant, le logiciel ne pouvait pas deviner quelle langue était utilisée. As-tu tapé des formules de math dans les années 90, quand la seule solution était la police Symbol ? En lieu et place du caractère habituellement dessiné « a », le caractère avait la forme alpha α. Mais c'était un a, et si tu changeais tout en Times, tes alphas redevenaient des a latins. Aujourd'hui, tu peux mélanger toutes les écritures sans changer de police, et c'est le logiciel qui trouve quelle police sait afficher quel caractère.

                  Si demain je reçois un document écrit avec (entre autres) trois polices que je ne possède pas, qui sont utilisés pour afficher des caractères rigolos, comment va faire mon ordi pour m'afficher des caractères au moins pseudo-corrects ?

                  Tu mets à jour ta machine. Il y a des polices unicode libres et elles sont livrées par les distros. J'ai rien fait de particulier et mes logiciels de base (éditeur de texte kwrite, navigateur firefox) savent afficher une floppée de langues de wikipédia. Je saurais pas dire quelle police code quel caractère, mais en tant que simple utilisateur final qui écrit des documents texte et web dans plusieurs langues (plus symboles mathématiques et rigolos), c'est pas mon problème.

                  • [^] # Re: Utilité

                    Posté par  . Évalué à 3.

                    Exactement comme avant. Si tu veux lire des documents en coréen, vaut mieux que tu aies une police qui affiche le coréen... La différence, c'est qu'avant, le logiciel ne pouvait pas deviner quelle langue était utilisée.

                    On disposait quand même d'un système qui permettait de savoir quelle type de police pouvait répondre au problème. Par exemple en ISO 8859-15 défini un nombre finalement assez limité de caractères, de fait deux personnes en ISO peuvent échanger de smessages assez simplement.

                    As-tu tapé des formules de math dans les années 90, quand la seule solution était la police Symbol ?.

                    Oui. C'était d'ailleurs à l'époque ce qui m'a fait passer à Latex. Ceci étant la frappe de formules entières n'est pas frnachement résolu par Unicode non plus. Les caractères unicodes sont des entités indépendante, et à ma connaissance les interdépendances de caractères doivent être gérées séparément (par exemple la barre de la racine carré ou la hauteur du symbole d'intégration)

                    Aujourd'hui, tu peux mélanger toutes les écritures sans changer de police, et c'est le logiciel qui trouve quelle police sait afficher quel caractère.

                    Généralement le logiciel choisi parmis les quelques polices Universelle/unicode/multiglyphes qu'il possède celle qui pourrait convenir. Maintenant je rapelle que le sujet du débat ici présent est :
                    42 gazillions de caractères rigolos est-ce que ca sert à quelque chose ?
                    Je sais bien que ce n'est pas très difficile d'afficher du sanskrit, du japonais et du tibétain dans la même page, mais si on commence à mettre les émoticones, les glyphes égyptiennes, les symboles graphset, les repérages sécurité/incendie etc. comment fait-on. Je ne vois pas une seule police contenir tous ces glyphes, je ne vois pas non plus les applis se farcir le scan de 300 polices spécialisées pour trouver le caractère qui va bien.

                    Grosso-modo plus on rajoute de caractères qui n'ont rien à voir avec des caractères alphabétiques, plus on prend le risque de se retrouver avec des problèmes de lisibilité des documents.

                    Quand un correspondant coréen m'écrit, je peux m'attendre à devoir installer une police qui prend en charge les caractères coréens si je n'en ai pas déjà une.
                    Quand un architecte m'écrit je ne veux pas chercher dans toutes les polices existante laquelle me permet de voir le caractères en position 6 de la ligne 22.

                    Pour éviter que l'on se retrouve coincés il vaut mieux laisser unicode tel qu'il est en minimisant les caratères admis le plus possible.

                    • [^] # Re: Utilité

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

                      de fait deux personnes en ISO peuvent échanger de smessages assez simplement.

                      Non. Il peuvent dans un cas exceptionnel : que tous les caractères du message soient dans la même locale (on s'en fou de la police de caractère, tu mélanges, la police de caractère c'est pour la présentation, si tu n'as pas la même c'est pas grave), et tu as vite fait de pas avoir un caractère. Ca marche donc dans certains cas, mais pas tous, loin de la, avant on faisait comme on pouvait avec des bidouilles monstres d'informaticien. Voir les exemple tout bêtes qui ont été cité ici-même (lettre alpha, qu'on qu'utilisent même des gamins de 3ème et pas dans ISO 8859-15)

                      • [^] # Re: Utilité

                        Posté par  . Évalué à 0.

                        Non. Il peuvent dans un cas exceptionnel : que tous les caractères du message soient dans la même locale

                        C'est marrant j'ai une pile de documments ISO qui précisent les changement de locales et qui sont lisibles par toutes les personnes qui en ont besoin - Des docs SGML par exemple.

                        (on s'en fou de la police de caractère, tu mélanges, la police de caractère c'est pour la présentation, si tu n'as pas la même c'est pas grave)

                        On est en train de parler de la lisibilité pour des utilisateurs dans un monde ou tout est en dans un standard qui comporte 42 gazillions de signes. Donc aucune police ne représentera tous les signes. Donc on force l'installation de polices spécifiques pour pouvoir lire un texte. Donc la police, si tu n'as pas la même tu ne peux pas comprendre le document est c'est grave.

                        En ISO je sais comment faire pour dire "cette parte de texte utilise telle locale, si tu n'as pas la police "machin" prend au moins une police compatible". Et ce même si le type décide d'écrire en Klingon et en Quenya.
                        En UTF-X je ne sais pas faire. C'est au logiciel de se démerder pour trouver dans toutes les polices installées lesquelles peuvent convenir.

                        Si il y a trente polices installées ca va, si il y en a 300 c'est le bazar.

                        • [^] # Re: Utilité

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

                          C'est marrant j'ai une pile de documments ISO qui précisent les changement de locales et qui sont lisibles par toutes les personnes qui en ont besoin - Des docs SGML par exemple.

                          Donc en gros, à la place d'UTF-8 il faut se farcir des gros hacks. Beurk! Désolé, mais entre des gros hacks degeux et UTF-8 / Unicode, je choisi vite, je laisse les merdes de changement de locale à l’intérieur d'un texte aux masochistes.

                          En UTF-X je ne sais pas faire. C'est au logiciel de se démerder pour trouver dans toutes les polices installées lesquelles peuvent convenir.

                          Et c'est tant mieux! C'est au logiciel de se débrouiller, pas à toi! C'est de la bidouille.

                          Bref, tu mélanges le codage d'un signe avec l'affichage d'un signe, tu mélanges le "savoir ce que c'est" avec le "comment on l'affiche", à partir de la il est impossible de discuter.

                          • [^] # Re: Utilité

                            Posté par  . Évalué à -2.

                            Donc en gros, à la place d'UTF-8 il faut se farcir des gros hacks.
                            Si c'est prévu dans la norme/le format je ne vois pas en quoi c'est un hack.

                            Et c'est tant mieux! C'est au logiciel de se débrouiller, pas à toi! C'est de la bidouille.
                            Dans un cas c'est au logiciel de l'auteur et dans l'autre cas c'est au logiciel du lecteur. Le truc est que si l'auteur est supposé savoir ce qu'il a voulu dire - le lecteur n'a pas forcément cette connaissance.

                            Bref, tu mélanges le codage d'un signe avec l'affichage d'un signe, tu mélanges le "savoir ce que c'est" avec le "comment on l'affiche", à partir de la il est impossible de discuter.

                            Non je ne mélange pas. L'utilisateur lambda il va être vachement content de savoir que le rectangle bordée de noir qu'il voit est en fait le caractère U+2868FFAE.

                        • [^] # Re: Utilité

                          Posté par  . Évalué à 6.

                          Donc on force l'installation de polices spécifiques pour pouvoir lire un texte.

                          Non. Tu installes les mêmes polices qu'avant, mais dans les polices que tu as souhaité installer pour les langues que tu souhaites lire, les numéros de point de code (dont l'utilisateur final n'a pas conscience) ne se chevauchent pas.

                          Donc aucune police ne représentera tous les signes.

                          Pour les documents du monde réel (càd tous sauf les .po), il suffit d'un nombre très limité de signes pour représenter le document. Par exemple, le logiciel devra trouver une police pour les langues latines, la police pour le coréen et celle pour les symboles rigolos. Si tu écris le document maitre d'une notice d'utilisation en plusieurs langues en SGML/XML dans un éditeur de texte (mettons gedit ou kwrite), comment ferais-tu pour indiquer à kwrite les nombreux changements de codage à l'intérieur d'un .txt ? Unicode résout le problème, en attribuant des numéros différents aux alphabets.

                          Si il y a trente polices installées ca va, si il y en a 300 c'est le bazar.

                          Si tu t'appelles Keith Packard tu résous le problème de façon élégante en écrivant Fontconfig.

                          • [^] # Re: Utilité

                            Posté par  . Évalué à 0.

                            Non. Tu installes les mêmes polices qu'avant

                            Rappel : On parle de points unicode qui codent des emoticones rigolotes comme "woman with bunny ears". Je te jure que je n'ai jamais installé de polices de caractères qui contiennent cette glyphe.

                            Pour les documents du monde réel (càd tous sauf les .po), il suffit d'un nombre très limité de signes pour représenter le document.

                            Rappel : On parle de points unicode qui codent des emoticones rigolotes comme "woman with bunny ears", et de la pertinence qu'il y a à mettre ce type de caractères dans unicode au risque de faire exploser le nombre de caractères utilisés dans les documents du monde réel.

                            Si tu t'appelles Keith Packard tu résous le problème de façon élégante en écrivant Fontconfig.

                            Font config ne résout pas le problème, il permet juste une classification hiérarchique des fontes. Pour que ce soit utile il faut que le logiciel sache utiliser cette classification (ca va c'est pas trop dur) et que le document possède des métas qui vont lui indiquer dans quelle hiérarchie aller taper si il n'a pas la police exacte. Sans ses deux éléments le logiciel est obligé de recourir à la force brute pour associer le glyphe U+XXXXXXXX avec le caractère "woman with bunny ears".

                            • [^] # Re: Utilité

                              Posté par  . Évalué à 3.

                              je te jure que je n'ai jamais installé de polices de caractères qui contiennent cette glyphe.

                              Ça viendra un jour ou l'autre dans la mise à jour de ta distro, pour peu que tu aies installé des polices unicode. P.ex. GNU Unifont (63 446 caractères) a pour objectif d'être complète (police bitmap, intéressant pour le rendu écran des logiciels de discussion qui ont besoin de « woman with bunny ears »), sinon Bitstream Cyberbit (32 910 caractères) utilisée pour les tests du consortium Unicode lui-même (non libre, gratuit pour usage personnel).

                              au risque de faire exploser le nombre de caractères utilisés dans les documents du monde réel.

                              On s'en fiche. Les documents comportent souvent des millions de caractères (en tout) et parfois des milliers de caractères distincts (CJK). Ça marche dans la vie réelle.

                              • [^] # Re: Utilité

                                Posté par  . Évalué à 3.

                                et parfois des milliers de caractères distincts (CJK). Ça marche dans la vie réelle.

                                Ca marche tellement bien que dans la vie réelle le gouvernement chinois a été obligé d'adjoindre à unicode des metas supplémentaires et de créer son propre système d'encoding qui incorpore ces métas.

                                Et là on parle de 120 000 signes d'une vraie langue d'un vrai pays, pas des émoticones rigolotes qu'on pourrait rajouter en plus.

                                Et on parle du chinois moderne aussi, pas du chinois classique ni des différents patois (parlés par plusieurs millions de personnes à chaque fois) et de leurs accentuations spécifique.

                                Mais bon c'est surement que les Chinois s'y sont mal pris, et qu'il n'y aura aucun problème quand on aura des documents qui peuvent potentiellement recouvrir 20 ou 30 millions de signes.

                                Sur ce je vous laisse, restez bien sur vos position de "ca marche parceque ca marche parceque ca marchera" et ne vous confrontez pas au monde du dehors.

                                • [^] # Re: Utilité

                                  Posté par  . Évalué à 4.

                                  le gouvernement chinois a été obligé d'adjoindre à unicode des metas supplémentaires et de créer son propre système d'encoding qui incorpore ces métas.

                                  Je lis la page Codage des caractères chinois. J'y découvre que le principal problème est de ne pas pouvoir déterminer simplement dans quelle langue ou dialecte est écrit un texte comportant des « caractères chinois », exactement comme l'utilisation de la plage « latin 1 » ne permet pas en soi de déterminer quelle langue européenne est utilisée. Leurs métas sont utiles puisque chaque dialecte peut avoir des règles de présentation différentes, je ne vois pas le rapport avec les problèmes que tu soulevais (nécessité d'installer ou de scanner des polices).

                                  En tous cas je ne suis pas nostalgique du temps où il fallait régler sa page de code 437 ou 850 pour avoir les caractères attendus. J'utilise DOSbox et c'est toujours la même prise de tête (je pourrais lire le manuel, mais je ne suis pas vraiment intéressé par les détails du DOS, je suis un utilisateur final qui veut que ça juste-marche).

                                  • [^] # Re: Utilité

                                    Posté par  . Évalué à 2.

                                    faut pas utiliser DOS alors, tête de bois...

                                    • [^] # Re: Utilité

                                      Posté par  . Évalué à 2.

                                      J'ai rien trouvé de mieux que le workflow de Derive 2. L'interface (édition de formules, application d'opération) est d'une rare efficacité.

                • [^] # Re: Utilité

                  Posté par  (Mastodon) . Évalué à 10.

                  Tu confonds plein de choses... Unicode a travaillé pendant des années pour que des concepts auparavant fortement liés soient maintenant indépendants. Ces concepts (que tu mélanges), c'est :

                  • Un caractère : pour Unicode, un caractère, c'est un point de code (pour faire très simple). Ils ont recensé tous les caractères au monde, en se posant des vrais questions (genre 'A' et 'a', c'est deux caractères différents ? 'A' (latin) et 'A' (alpha majuscule grec), c'est deux caractères différents ?) et ont attribué un numéro et une description à chaque caractère. Les fameux U+0000, ce sont les points de code, ça désigne un caractère de manière unique.
                  • Un encodage : c'est la manière de représenter informatiquement un caractère. Par exemple, UTF-8 est un encodage. Latin1 aussi mais il ne permet pas de coder tous les caractères Unicode (donc c'est moisi, il faut s'en débarrasser).
                  • Une police : c'est la manière d'afficher à l'écran un caractère, peu importe son encodage. Avec des variantes du genre gras, italique, etc pour chaque caractère.

                  Auparavant, tout était mélangé, comme le montre la fameuse police Symbol évoqué plus haut. Maintenant, c'est beaucoup plus clair et c'est tant mieux. Donc le problème de comment afficher un caractère unicode ne dépend ni du caractère, ni de l'encodage, mais uniquement du système de polices de caractère.

                • [^] # Re: Utilité

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

                  Je te conseil la lecture du livre suivant : Unicode 5.0 en pratique - Codage des caractères et internationalisation des logiciels et des documents

                  Je l'ai trouvé à la médiathèque de ma ville, peut être auras-tu cette même chance.

                  Ça te permettra de mieux comprendre ce qu'est unicode, les problèmes qu'il se fixe comme objectif à résoudre, et aussi ce que n'est pas unicode.

                  À ta lecture j'ai l'impression que tu t’emmêles les pinceaux.

                • [^] # Re: Utilité

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

                  Tu peux également lire la page suivante : http://www.gnu.org/software/freefont/articles/Why_Unicode_fonts.html

              • [^] # Re: Utilité

                Posté par  . Évalué à 8.

                tu peux dire que l'ASCII est moins lourd que l'UTF-8

                L'ASCII est exactement aussi lourd que l'UTF-8 : si tu recodes un texte tout ASCII en UTF-8, le poids reste le même.

      • [^] # Re: Utilité

        Posté par  . Évalué à 4.

        (question subsidiaire : comment un aveugle s'imagine-t-il la forme d'une crotte de chien ?)

        C'est une jolie problématique ça, comment les aveugles vont ils-faire pour comprendre le sens d'un tel caractère qui est ultra visuel et qui n'a pas de message alternatif expliquant sa fonction ?

        • [^] # Re: Utilité

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

          C'est une jolie problématique ça, comment les aveugles vont ils-faire pour comprendre le sens d'un tel caractère qui est ultra visuel et qui n'a pas de message alternatif expliquant sa fonction ?

          Bah justement comme c'est standard l'aveugle peut savoir que le caractère représente tel ou tel truc. Par exemple un logiciel peut facilement traduire U+1F4A9 en « pile of poo ».

          • [^] # Re: Utilité

            Posté par  . Évalué à 1.

            Il existe encore plus simple que de transformer U+1F4A9 en "pile of poo" : ne pas utiliser U+1F4A9 mais écrire littéralement les mots "pile of poo". Les personnes sont-elles tant déficientes de l'écriture ou la lecture que 3 mots sont plus compliqués qu'un pictogramme ?
            Un autre avantage notable serait que le logiciel qui devrait transformer tous ces caractères unicodes farfelus n'aurait pas besoin de connaitre la langue du texte environnant pour donner un ensemble cohérent.

            • [^] # Re: Utilité

              Posté par  . Évalué à 1.

              Il existe encore plus simple que de transformer U+1F4A9 en "pile of poo" : ne pas utiliser U+1F4A9 mais écrire littéralement les mots "pile of poo".

              et si "les personnes" ne parlent pas anglais ? :)

              • [^] # Re: Utilité

                Posté par  . Évalué à 6.

                Justement, vous auriez dû lire le reste de mon message, ce que je vous encourage à faire maintenant.

                • [^] # Re: Utilité

                  Posté par  . Évalué à 2.

                  Le logiciel a de toute façon besoin de connaître la langue environnante pour avoir une prononciation correcte et que le texte soit compréhensible. Si en plus, il ne doit pas interpréter les smileys qui, statistiquement, se retrouveront de toute façon dans un texte qui sera lu par le logiciel, c'est quand même plus simple.

                  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

              • [^] # Re: Utilité

                Posté par  . Évalué à 0.

                Il ne fallait pas prendre "littéralement" à la lettre, c'était évidemment d'utiliser les mots correspondants dans la langue originale, bref, faire une vraie phrase qu'on puisse lire et non pas un assemblage douteux de mots et de dessins.

            • [^] # Re: Utilité

              Posté par  . Évalué à 4.

              Pour les émoticones comme ":-)", je peux comprendre qu'ils puissent avoir une place, car ils font partie de la communication non-verbale : les expressions physiques et les gestes. Mais un pictogramme "pile of poo" ne rentre pas dans ce cadre.

              De toute manière, par nature, le texte est un moyen de communication différent de la conversation face-à-face, et tenter de reproduire des schémas d'un autre moyen est à mon sens une erreur. Les anciens supports (papier-stylo) étaient moins limités que le support informatique textuel (jeux de caractères), et pourtant personne ne parsemait ses lettres de petits dessins (équivalent des ":-)" voire des "pile of poo").

              • [^] # Re: Utilité

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

                Mais un pictogramme "pile of poo" ne rentre pas dans ce cadre.

                Pas le tiens. Ce n'est pas le cas pour d'autres.

                • [^] # Re: Utilité

                  Posté par  . Évalué à -1.

                  Je suis sûr que vous pouvez faire mieux que simplement dire "non", explicitez, donnez un exemple.

                  • [^] # Re: Utilité

                    Posté par  . Évalué à 2.

                    Je ne sais pas si vous avez remarqués, cela concerne des renseignements que l'on peut trouver sur des cartes, des plans (OSM).
                    BREAD
                    FRENCH FRIES

                    Ce pictogramme pourrait symboliser des WC pour chiens sur les cartes :)

                    D'avoir cela en unicode, cela permet d'unifier les pictogrammes et est plus simple à manipuler que des images.

                    Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

                    • [^] # Re: Utilité

                      Posté par  . Évalué à 0.

                      Où est l'unification des pictogrammes puisque leur apparence est choisie par les éditeurs de polices, et non par le consortium ? Le consortium accepte-t-il tout pictogramme du moment qu'il lui reste de la place ? Unicode propose déjà une zone libre où chacun peut définir ses symboles, mais où l'on n'empiète pas sur l'espace commun.

                      • [^] # Re: Utilité

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

                        Où est l'unification des pictogrammes puisque leur apparence (...)

                        Gni???
                        L'unification est dans la signification (c'est le but d'Unicode : un caractère = une signification).
                        Unicode n'a absolument rien à voir avec l'apparence (c'est une exemple qui est donné, rien de plus). Le consortium n'accepte aucun pictogramme, il accepte une signification.

                        Bref, tu ne comprends pas Unicode, mais te permet de décider à la place des autres de ce qui est utile. Les autres ont fait une demande et passé le filtre de sélection, ce n'est pas pour le plaisir...

                        • [^] # Re: Utilité

                          Posté par  . Évalué à 1.

                          c'est le but d'Unicode : un caractère = une signification

                          Mais non ! Un caractère ne signifie rien. "A", "B", "C", etc. (je ne vais pas tous les mettre :-)) ne signifient rien. C'est bien le principe d'un alphabet : les symboles en soi ne veulent rien dire, c'est leur combinaison selon un système particulier (il y en a plusieurs : l'anglais, le français, etc. - je ne vais pas tous les mettre :-)) qui leur donne une signification.

                          (ok, pour les idéogrammes, la situation est différente : mais ce n'est pas la peine de construire un système idéogrammatique supplémentaire - à base de bonhommes de neige et de crottes de chien - pour promouvoir une improbable langue graphique universelle)

                          • [^] # Re: Utilité

                            Posté par  (Mastodon) . Évalué à 4.

                            Mais si ! Les caractère Unicode ne porte aucune information de comment les afficher, ça c'est le but des polices de caractères. Ton caractère 'A', je peux l'afficher 'A' ou 'A', c'est toujours le même caractère et pourtant, il n'a pas la même allure. Pour les pictogrammes, c'est la même chose, ils ont un sens, et on peut changer leur allure sans changer leur signification.

            • [^] # Re: Utilité

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

              ne pas utiliser U+1F4A9 mais écrire littéralement les mots "pile of poo"

              Pourquoi t'arrêter de remplacer un caractère par 9 caractères? trop de lettres, je propose des 0 et des 1 comme élément de base 01101010101101001100101100110101010110, hop c'est réglé, et toi tu te fais la traduction dans la tête (et au passage, l'anglais n'est pas une langue comprise par tout le monde).

              • [^] # Re: Utilité

                Posté par  . Évalué à 3.

                Je me suis mal fait comprendre, prenons un exemple d'une phrase en français, avec deux façons de l'écrire :

                Une personne sur dix a glissé sur des <U+1F4A9> de chien dans la ville de Paris.

                Une personne sur dix a glissé sur des déjections canines dans la ville de Paris.

                Quelle version préférez-vous ? D'ailleurs, le caractère unicode est bien plus limité, il n'a pas plusieurs registres de langages, etc.

                • [^] # Re: Utilité

                  Posté par  . Évalué à 6.

                  oui, on n'a pas les cacas de chats, de chevaux, de poneys ou de CRS.

                  on n'a aucune information sur sa consistance, sur ce que toutou a mangé, si elle est écrasée ou pas...

                  • [^] # Re: Utilité

                    Posté par  . Évalué à 1.

                    La langue a pourtant bien toutes ces richesses, et le niveau de détail est optionnel. Ici, le message transmis n'a pas besoin de préciser la nourriture des chiens parisiens. Par contre, il est utile de préciser que ce ne sont pas des fientes de pigeons qui sont à l'origine d'accidents, mais de chiens, donc dûs à la négligence des propriétaires.

                    Ces caractères unicode n'apportent rien, ils sont pauvres, moins accessibles, tout à fait dispensables, rendent la lecture pénible. Je ne vois vraiment pas leur intérêt.

                    • [^] # Re: Utilité

                      Posté par  . Évalué à 1.

                      Personne n'a dit que tu devais t'interdire d'utiliser les locutions « déjections canines » ou « merdes de cleb's » dans la langue de ton choix pour les remplacer par le pictogramme standard, hein.

                • [^] # Re: Utilité

                  Posté par  . Évalué à 1.

                  D'ailleurs, le caractère unicode est bien plus limité, il n'a pas plusieurs registres de langages, etc.

                  Ça dépend de l'outil de lecture. Il est parfaitement possible de combiner un caractère avec plusieurs expressions dont l'une sera affichée en fonction du mode choisi par l'utilisateur.

                  Après tout, on peut parfaitement imaginer celui-ci paramétrer son navigateur en registre familier ou alors en registre soutenu.

                  Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                  • [^] # Re: Utilité

                    Posté par  . Évalué à 4.

                    C'est insensé, le but est de servir à la communication, qui se fait en passant un message. Si le navigateur modifie le message, cela altère ce que la personne émettrice du message a voulu dire...

                    • [^] # Re: Utilité

                      Posté par  . Évalué à 1.

                      Rien n'empêche l'émetteur d'utiliser ses propres mots, le choix est toujours là.

                      L'avantage ici, c'est qu'on peut imaginer plein de choses, comme par exemple communiquer avec une machine : celle-ci n'a qu'une chose à interpréter, au lieu de devoir connaître tous les synonymes.

                      (l'exemple de la crotte de chien n'est peut-être pas pertinent, mais il doit y en avoir d'autres)

                      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                      • [^] # Re: Utilité

                        Posté par  . Évalué à 2.

                        Je pense que la difficulté de communiquer avec la machine ne vient certainement pas de la taille du vocabulaire (ce serait plutôt l'un des points forts de la machine de pouvoir stocker des masses d'informations sans les oublier ou les mélanger). Il me semble que l'ambigüité de la tournure des phrases, et de l'utilisation du contexte est bien plus gênante.

                      • [^] # Re: Utilité

                        Posté par  . Évalué à 4.

                        L'avantage ici, c'est qu'on peut imaginer plein de choses, comme par exemple communiquer avec une machine : celle-ci n'a qu'une chose à interpréter, au lieu de devoir connaître tous les synonymes.

                        Si pour communiquer avec une machine il suffisait de remplacer le langage naturel par de petits dessins, ça se saurait... (et Perl 6 utiliserait déjà tout le registre unicode pour nommer ses pléthoriques concepts :-))

                • [^] # Re: Utilité

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

                  Quelle version préférez-vous ? D'ailleurs, le caractère unicode est bien plus limité, il n'a pas plusieurs registres de langages, etc.

                  Ouais enfin les émoticônes sont censés représenter une émotion. Par exemple tu verrais jamais dans un forum. « je suis :) ». Une utilisation du pile of poo pourrait être : « ma grand mère s'est abonnée à orange<U+1F4A9> ».

                  • [^] # Re: Utilité

                    Posté par  . Évalué à 8.

                    il faudrait proposer les totoz au consortium Unicode, c'est clair.

            • [^] # Re: Utilité

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

              Non, si on te dit goat.cx et si on te balance l'image de goat.cx, ça te fait pas le même effet. Le signifiant à bien plus d'influence que le signifié sur la signification.

              Je ne dit pas qu'inclure tout et n'importe quoi dans unicode c'est bien, mais il faut pas raconter n'importe quoi pour autant.

              Un texte dont les glyphes permettent de retrouver le son qu'on rattache à un concept, c'est fort différent d'un symbole qui représente directement le concept.

              • [^] # Re: Utilité

                Posté par  . Évalué à 2.

                Non, si on te dit goat.cx et si on te balance l'image de goat.cx, ça te fait pas le même effet.

                Un texte dont les glyphes permettent de retrouver le son qu'on rattache à un concept, c'est fort différent d'un symbole qui représente directement le concept.

                La langue est le niveau le plus abstrait, car ce que l'on attache aux mots ne leur ressemble pas du tout. Plus on s'approche du concret, plus la représentation est détaillée, et moins elle est générique. Alors, plus on s'éloigne du concept, et l'on se rapproche d'un exemple particulier du concept. Il suffit de voir sur cette page comme un des caractères a été interprété par certains en "crotte de chien" alors que rien (pas même le nom du caractère) n'implique qu'il s'agit d'un chien.

                • [^] # Re: Utilité

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

                  En même temps, les moto-crottes de chichi, sbien des crottes de cleps qu'ils ramassent hein (que ce soit à Paris, Toulouse ou Lyon), au moins les chats vont là où il faut

                  • [^] # Re: Utilité

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

                    au moins les chats vont là où il faut

                    derrière le canapé c'est pas forcement le plus adapté.

      • [^] # Re: Utilité

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

        Je reformule. Je dis qu'on peut mettre un texte alt plus fidèle à l'image. Entre « visage qui sourit », « :-) » et « ☺ » il me semble que le dernier est le plus fidèle.

        Je pensais plus à la fidélité qu'à l'accessibilité aux handicapés. C'est sûr que ce n'est pas le meilleur pour l'aveugle.

    • [^] # Re: Utilité

      Posté par  . Évalué à 9.

      ☺

      DLFP >> PCInpact > Numerama >> LinuxFr.org

    • [^] # Re: Utilité

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

      Comment vont-ils faire pour ce smiley-là ? :noel:

      Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

  • # Super utile

    Posté par  . Évalué à 4.

    Si si.

    comme tu peux le voir ici.

    Par contre pour le clavier...

    • [^] # Re: Super utile

      Posté par  . Évalué à 4.

      C'est super, les utilisateurs d'Emacs ont enfin trouvé leurs claviers.

      • [^] # Re: Super utile

        Posté par  . Évalué à 9.

        Vu qu'on avait deja celui la pour vim, la boucle est bouclée...

      • [^] # Re: Super utile

        Posté par  . Évalué à 4.

        Les vrais claviers lisp sont beaucoup plus impressionnants
        http://deskthority.net/viewtopic.php?f=2&t=98&ok

        • [^] # Re: Super utile

          Posté par  . Évalué à 1.

          Oui mais là, les raccourcis Emacs auraient été encore plus bordélique.
          T'imagines le truc:
          «Alors pour ouvrir un fichier, c'est: <Control-Super-Meta-Alt-Shift-o>. Pour le fermer, c'est: <Control-Super-Hyper-x><Control-Hyper-Super-Meta-Shift-c>»

          --> []

          • [^] # Re: Super utile

            Posté par  . Évalué à 4.

            Rappelons que "EMACS" est l'acronyme de "Escape-Meta-Alt-Control-Shift".

          • [^] # Re: Super utile

            Posté par  . Évalué à 5.

            Ah mais justement, emacs a été développé sur le clavier space-cadet (le premier donné dans le lien).
            Vi a été créé en utilisant un terminal en:ADM3A, beaucoup plus spartiate.

            On voit vite que l'environnement dans lequel ils ont été créés a complètement influencé leur conception.

            L'histoire elle-même confirme que vi est plus efficace dans son utilisation des touches clavier et que emacs n'est qu'un joujou d'informaticien gâté qui a eu trop de touches clavier à sa disposition durant sa jeunesse.

            • [^] # Re: Super utile

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

              Tout a fait d'accord :)

              d'ailleurs les utilisateurs de vi on peut facilement leur couper le petit doigt, alors que j'ai entendu dire qu'au bout de quelques années d'emacs un 6eme doigt poussait ...

            • [^] # Re: Super utile

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

              On voit aussi que la touche `Esc' était beaucoup plus proche des doigts sur le ADm3A que sur un clavier contemporain. Bien qu'utilisant principalement Emacs j'utilise très régulièrement vi (en fait nvi) et très franchement, utiliser une touche comme alt ou ctrl pour changer de mode dans vi serait plus pratique que la touche escape, dont la manipulation nécessite que la main effectue un grand déplacement sur le clavier.

  • # Et il en manque.

    Posté par  . Évalué à 10.

    C'est vrai que les priorités sont bizarres: on a d'un côté des caractères anodins, et de l'autre, il manque des symboles comme le "copyleft", qui aurait pourtant son intérêt à côté du "copyright".

    THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

    • [^] # Re: Et il en manque.

      Posté par  . Évalué à 5.

      Alors qu'il y a bien le symbole ☭ (accessible avec compose+CCCP par ailleurs !), pourtant plus sujet à controverse ☹.

      DLFP >> PCInpact > Numerama >> LinuxFr.org

      • [^] # Re: Et il en manque.

        Posté par  . Évalué à 3.

        Mais il y a une erreur : c’est pas CCCP que ☭ représente, c’est СССР (SSSR en cyrillique)…

    • [^] # Re: Et il en manque.

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

      Il y a pas un caractère qui permet de retourner le caractère suivant?

      • [^] # Re: Et il en manque.

        Posté par  . Évalué à 4.

        Si on s'appuie sur cet argument, alors comment justifier la présence simultanée de ⇉ et ⇇ ?

        THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

      • [^] # Re: Et il en manque.

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

        Si on s'appuie sur cet argument, alors comment justifier la présence simultanée de p et q ?

    • [^] # Re: Et il en manque.

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

      C’est la question que j’allais poser… Toujours pas prévu d’ajouter le copyleft ?? Ça paraît assez dingue…

      • [^] # Re: Et il en manque.

        Posté par  . Évalué à 10.

        puisqu'on te dit qu'on a déjà ☭.

        • [^] # Re: Et il en manque.

          Posté par  . Évalué à 0.

          Y'a aussi un symbole pour les points godwin ?

          • [^] # Re: Et il en manque.

            Posté par  . Évalué à 1.

            Pour l'instant non, mais je suppose que n'importe qui peut proposer…

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

            • [^] # Re: Et il en manque.

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

              Ils ont pensé à tout : godwin

              • [^] # Re: Et il en manque.

                Posté par  . Évalué à 7.

                Ils ont pensé à rien, c'est un idéogramme vieux de plus de 3000 ans.
                http://fr.wikipedia.org/wiki/Svastika C'est pas parce qu'il a été mal utilisé dans l'histoire récente qu'il ne doit pas y figurer.

                • [^] # Re: Et il en manque.

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

                  Mal utilisé, et qu'en occident. Unicode s’adresse à la planète entière, et il est parfois oublié qu'un signe à tel endroit de la planète n'a pas la même signification à un autre endroit...

                  Difficile de faire des normes internationales!

                  • [^] # Re: Et il en manque.

                    Posté par  . Évalué à 2.

                    Justement, je trouve que les caractères Unicode sur-représentent la culture occidentale: les smileys (chat, femme-avec-des-oreilles-de-lapin.. :P), les symboles techniques, font avant tout référence à notre culture.

                    Si chaque civilisation obtient la même quantité de symboles liés à sa culture, ça va faire beaucoup de caractères.

                    THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

    • [^] # Re: Et il en manque.

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

      C'est vrai que les priorités sont bizarres: on a d'un côté des caractères anodins, et de l'autre, il manque des symboles comme le "copyleft", qui aurait pourtant son intérêt à côté du "copyright".

      Quelqu'un en a-t-il fait la demande officielle au consortium Unicode?

    • [^] # Re: Et il en manque.

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

      Il n'a pas l'air d'avoir été proposé :
      http://www.unicode.org/alloc/Pipeline.html

      Hop, hop, pushons : http://www.unicode.org/pending/proposals.html

  • # But d'Unicode

    Posté par  . Évalué à 10.

    Ces caractères sont surement apparus dans un charset exotique, par exemple sur les téléphones japonais, on peut insérer des smileys ("emoji") qui sont encodés dans une extension de SJIS (surement pour économiser de la bande passante), cf :
    http://en.wikipedia.org/wiki/Emoji

    Voila une explication plus complete sur le site d'Unicode :
    http://unicode.org/faq/emoji_dingbats.html

    Quand tu as des donnes contenant ces caractères non standards, c'est quand meme sympa de pouvoir les convertir en Unicode sans parsemer le texte de "?"

  • # Bon, si c'est comme ça

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

    Qui se dévoue pour faire une fonte qui comprends :

    • les symboles nécessaires pour faire des graphes d'automates
    • les symboles pour faire des arbres en V ( branches /\ et \/)

    Parce que pour faire des arbres carrés, je sais faire :

     ( id + id ) * id 
 │  │ │  │ │ │ │
 │  F │  F │ │ F 
 │  │ │  │ │ │ │
 │  T │  T │ │ │
 │  │ │  │ │ │ │
 │  E │  │ │ │ │    
 │  └─┼──┘ │ │ │
 │    │    │ │ │
 │    E    │ │ │
 └────┼────┘ │ │
      │      │ │
      F      │ │ 
      │      │ │
      T      │ │
      └──────┼─┘
             │
             T
             │
             E

    Bon pour l'accessibilité c'est pas génial, mais d'un autre coté, je ne sais pas comment on fait un graphe d'arbre accessible à des personnes aveugles, même avec une image, je met quoi dans le alt ?

  • # Goatsie ?

    Posté par  . Évalué à 2.

    C'est quoi le code Unicode du goatsie ?

    BeOS le faisait il y a 20 ans !

  • # Code

    Posté par  . Évalué à 4.

    Va falloir que je milite pour la suppression de la règle de codage du boulot qui nous restreint au sous ensemble de l'ASCII… J'ai pas réussi à les convaincre que α était plus clair que alpha dans une formule, mais je pense que qu'avec la possibilité d'insérer ces caractères sympathiques je vais pouvoir y arriver !

    Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

    • [^] # Re: Code

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

      Dans du code je vois pas l'intérêt. Il vaut mieux, amha, nommer ses variables avec des noms explicite. Mais assez brèves quand même, surtout quand il s'agit d'indice, genre vitesse_maximum[vehicule_courant] n'est pas franchement génial. Et si une formule est vraiment trop longue, il y a toujours moyen de la diviser en plusieurs fonctions.

      Je comprends que dans un paplar on puisse utiliser des lettres pour faire une formule qui tiens dans 3cm². Et encore, même là, la plupart du temps, l'usage de lettres grecques est totalement inutile, et semble plus résulter d'un besoin d'étaler sa culture. :)

      • [^] # Re: Code

        Posté par  . Évalué à 7.

        Ce n'est pas pour étaler sa culture, c'est parce que 100% des gens qui échangent des informations à propose de ce paramètre l'appellent "alpha". C'est comme en français, parler de "table" au lieu de "l'objet composé de pieds et d'un plateau horizontal sur lequel on pose les assiettes et les couverts" ce n'est pas étaler son vocabulaire, c'est utiliser le bon mot. En même temps, ça rejoint ce que tu dis dans "utiliser le nom explicite". Sauf que le nom explicite est α dans certains cas.

        Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

      • [^] # Re: Code

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

        Je comprends que dans un paplar on puisse utiliser des lettres pour faire une formule qui tiens dans 3cm². Et encore, même là, la plupart du temps, l'usage de lettres grecques est totalement inutile, et semble plus résulter d'un besoin d'étaler sa culture. :)

        Je me joins à toi: ont peut très bien appeler ses variables a, aa, aaa, etc. tous ceux qui font autrement sont des snobs péteux.

        s/inutile/inutile à mes yeux/

        On oublie facilement qu'on a parfois mauvaise vue.

        et semble plus résulter d'un besoin d'étaler sa culture.

        C'est vrai que c'est quand même sacrément élitiste d'utiliser des notations qu'on trouve dans des livres de physique de 3ème. Y'a des jours ...

        • [^] # Re: Code

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

          Parce que l'emploi de lettre grecques ça ne sort pas tout droit des académies élitistes des siècles passés, pour sûr.

          Est-ce bien pertinent de faire apprendre par cœur à des millions (milliards ?) l'emploi de la lettre π, sans expliquer pourquoi on emploi cette lettre ? Dire qu'on appel π (pi), comme périmètre, le nombre qui est rapport constant entre le périmètre et le diamètre d'un cercle, ça ne coûte pas grand chose.

          Utiliser des notations devenu complétement abscons sans le contexte qui leur donne un sens, furent-elles enseignés en école primaire, je ne trouve pas que ça relève de la plus haute ingéniosité en terme de transmission de savoir.

          • [^] # Re: Code

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

            Est-ce bien pertinent de faire apprendre par cœur à des millions (milliards ?) l'emploi de la lettre π, sans expliquer pourquoi on emploi cette lettre ? Dire qu'on appel π (pi), comme périmètre, le nombre qui est rapport constant entre le périmètre et le diamètre d'un cercle, ça ne coûte pas grand chose.

            Utiliser des notations devenu complétement abscons sans le contexte qui leur donne un sens, furent-elles enseignés en école primaire, je ne trouve pas que ça relève de la plus haute ingéniosité en terme de transmission de savoir.

            Ça me semble plutôt hors sujet ... qu'est-ce que tu racontes? Où veux-tu en venir? Ça me fait plaisir que tu en saches autant sur le nombre pi mais quel rapport avec le débat?

            Je te rappelle que ta remarque initiale consiste à reprocher à notre camarade de forum d'étaler sa culture en proposant d'écrire α (la lettre alpha) au lieu de alpha (le nom de la lettre alpha): qu'il existe un alphabet grec et qu'alpha est le nom d'une lettre dans cet alphabet n'a pas du surprendre beaucoup de lecteurs de ce forum, accuser l'auteur de cette proposition d'étaler ici sa culture me paraît donc, au minimum, déplacé.

            • [^] # Re: Code

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

              Tu as bien mal compris ma critique, ou je l'ai bien mal formulé.

              D'abord je n'ai pas porté de critique personnelle.

              J'ai bien précisé que dans un papier l'usage de lettres grecques est la plupart du temps totalement inutile (et même amha contribue à rendre le dit papier plus abscons).

              On me répond que la variable en question est nommé alpha par ceux qui l'utilisent. Oui pourquoi pas, mais àmha, on est là dans le même cas que π, à savoir qu'en amont quelqu'un à choisi une lettre grecque (et c'est là que ce situe ma critique). Peut être est-ce aussi une apocope mnémotechnique, mais on a pas moyen le savoir sans plus de précision.

              La preuve que ce nom de variable laisse à désirer est justement sa pauvreté sémantique. On pourrait la nommer angle si c'est un angle, polar s'il s'agit de la polarisabilité, etc.

              http://www.literateprogramming.com/lpquotes.html

              • [^] # Re: Code

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

                J'ai bien précisé que dans un papier l'usage de lettres grecques est la plupart du temps totalement inutile (et même amha contribue à rendre le dit papier plus abscons)

                D'ailleurs on pourrait très bien remplacer les signes somme (un SIGMA majuscule) et les signes produit (un PI majuscule) etc. par des notations de type tableur genre SOMME(...) et PRODUIT(...)? Quand il y a une convention bien établie sur une façon d'écrire les choses, la suivre facilite la lecture de son texte par les autres. Les notations bien établies souffrent parfois (toujours?) de défauts, mais elles ont un gros avantage: elles sont établies. Quand on programme, l'indice qui énumère les entrées d'un tableau dans une boucle for s'appelle i, j ou k parceque sinon plus personne comprend rien, en physique la vitesse de la lumière c'est c (comme dans E=mc2) et pas d ni e, et en math le nombre d'Archimède c'est pi et pas qi ni ri, et à la fin d'une phrase on met un point, au début une majuscule, amha signifie à mon humble avis, etc. Adhérer à cet usage, c'est faciliter la lecture du texte par la majeure partie du public auquel il est destiné, et amha ne contribue pas à rendre le papier abscons, bien au contraire.

                Les variables longues n'améliorent pas toujours la lisibilité: si tu as une longueur d'onde et une longueur de tube, les nommer lambda et l permet aux lecteurs de les distinguer plus rapidement que si on les nomme longueur_d_onde et longueur_de_tube.

                En shell, en Make et en Perl, il y en a une belle palanquée de variables souvent utilisées dont les noms sont courts.

                Les noms longs de variables ou de fonctions permettent (peut-être?) de faciliter la mémorisation d'un grand nombre de noms en favorisant l'apparition de motif répétitifs, et encore il faut quand-même que les gens qui décident de ces noms fassent des efforts (pas bon: NumberMultiply et AddNumber).

                La preuve que ce nom de variable laisse à désirer est justement sa pauvreté sémantique.

                Quelle pauvreté sémantique? C'est justement le contraire, puisque d'après notre ami:

                Ce n'est pas pour étaler sa culture, c'est parce que 100% des gens qui échangent des informations à propos de ce paramètre l'appellent "alpha".

                C'est bien que ce alpha, à la différence de beta, à une valeur sémantique, non?

                Si les gens ont recours à l'alphabet grec et à d'autres c'est à cause de la richesse sémantique des lettres: les coordonnées réelles d'un point dans l'espace sont x, y, z, le temps c'est t, les nombres complexes s'appellent z, w, v ou u ou s; a, b, c et d servent à tout et n'importe quoi, e c'est le nombre de Néper, f, g et h sont des fonctions, i, j, k, l des indices pour dedans les sommes, m et n sont des entiers, o n'est pas utilisé car il ressemble à 0 (ou plutôt, est justement utilisé pour sa ressemblance avec zéro) p est un nombre entier, sûrement premier d'ailleurs, q aussi à moins que ce ne soit le quotient d'une division et dans ce cas r et le reste ... toutes les lettres minuscules ont des rôles plus ou moins assignés en maths, même en restant au niveau du lycée. Après ça s'aggrave, cela dépend des spécialités, et c'est franchement tout le contraire d'une pauvreté sémantique.

                http://www.literateprogramming.com/lpquotes.html

                Ça s'appelle literate programming et pas obnoxiously verbose programming et si dans TeX the program de Knuth on trouve certes des noms longs mais aussi des choses comme 

                var i, j, k: integer ; { all-purpose integers }
p, q, r: pointer ; { all-purpose pointers }
                Et oui i, j, k sont des entiers, etc.

                Dans ta source, la première citation est (c'est moi qui souligne):

                The practitioner of literate programming can be regarded as an essayist, whose main concern is with exposition and excellence of style. Such an author, with thesaurus in hand, chooses the names of variables carefully and explains what each variable means.

                Il n'y a pas écrit que le nom de la variable doit expliquer ce que la variable signifie, ou bien?

                • [^] # Re: Code

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

                  Je ne parviens visiblement pas à te communiquer ce que je pense, car je suis tout à fait d'accord avec nombre d'arguments que tu sembles considérer comme contre-argument à ce que je te dis.

                  J'adore Perl, mais il faut reconnaître que sa réputation de langage « en écriture seule » n'est pas toujours surfaite.

                  Il est évident que des noms courts peuvent améliorer la lisibilité, je n'ai pas dit le contraire, surtout pour des indices.

                  recette[ingrédient][quantité] /* non */
recette[i][j] /* mieux */
recette[i][q] /* pourquoi pas */

              • [^] # Re: Code

                Posté par  . Évalué à 1.

                Toi, t’es pas mathématicien mais informaticien, de toute évidence.

                Alors permet moi de te rappeler ceci : alpha = a×l×p×h×a ≠ α. Rigole, mais perso. j’ai dans mes formules des mu et des µ…

                Maintenant, pourquoi utiliser les lettres grecques ? L’histoire, en règle général elles ont un usage attribué, la plus connue et π pour 3,14…, mais perso. j’ai aussi α pour les coefficients de proportionnalité (et C pour les constantes additives), là je suis en train de lire un papier dans lequel on utilise β, il a systématiquement la même signification d’un papier à l’autre dans ce domaine précis, pour un autre domaine ça changera. Pour les fréquences on peut utiliser ν, λ pour la longueur d’onde. Bien souvent les lettres grecques ont une sémantique forte (variable suivant le domaine) et consacrée avec l’usage. La lecture d’une formule mathématique est facilitée si on retrouve une certaine constance dans l’usage des symboles sans avoir à se refarcir systématiquement les définitions. Pourquoi utiliser ces lettres ? Parce que les lettres du français ne sont pas suffisantes (certaines ont aussi des significations particulière d’ailleurs, T pour la température par exemple, k pour la constante de Boltzman). Ensuite parce que ces lettres sont facilement reconnaissable et on peut ainsi plus facilement, dans un texte, identifier lorsqu’on parle d’une variable mathématique.

  • # A propos d'Unicode...

    Posté par  . Évalué à 4.

    Aviez-vous vu cette vidéo montrant les 49571 caractères à la suite ?

    http://www.youtube.com/watch?v=Z_sl99D2a18

    Moi je trouve ça plutôt cool.

Suivre le flux des commentaires

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