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 🚲 Tanguy Ortolo (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 bubar🦥 (Mastodon) . Évalué à 5.
1F365
"fish cake with swirl design" ... pas mal comme texte explicatif pour celui-ci :p
[^] # Re: Justification
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 9.
Ah, ça, c'est un gâteau d'anniversaire pour Debian.
[^] # Re: Justification
Posté par JoeltheLion (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 lolop (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.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Justification
Posté par JGO . É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 matthieu bollot (site web personnel, Mastodon) . Évalué à 3.
Prière de ramasser les
[^] # Re: Justification
Posté par matthieu bollot (site web personnel, Mastodon) . Évalué à 4.
youps, bug spotted on dirait :-$
[^] # Re: Justification
Posté par tiot (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 Gniarf . É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 BFG . Évalué à 7.
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 monde_de_merde . É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 lolop (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.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Justification
Posté par Blackknight (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 JGO . É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 Julien Jorge (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 Antoine . Évalué à 3.
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 zebra3 . Évalué à 10.
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 Laurent J (site web personnel, Mastodon) . Évalué à 8.
c'est plus accessible dans le sens où :
[^] # Re: Utilité
Posté par BFG . É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 Antoine . Évalué à 7.
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.
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 Gniarf . Évalué à 10.
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 Zenitram (site web personnel) . Évalué à 10.
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 Gniarf . Évalué à 10.
AUCUN, EN EFFET. ET JE PENSE QU'ON PEUT EGALEMENT VIRER LES MINUSCULES
[^] # Re: Utilité
Posté par zebra3 . É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 lolop (site web personnel) . Évalué à 5.
Et on peut ne laisser que espace et tabulation, ça va être marrant à essayer de comprendre...
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Utilité
Posté par dormomuso . Évalué à 4.
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 Zenitram (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 Enzo Bricolo 🛠⚙🛠 . É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 Gniarf . É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 2PetitsVerres . É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 Michaël (site web personnel) . Évalué à 3.
Je crois que je vais revendre mon ordinateur et acheter un pot de peinture ...
[^] # Re: Utilité
Posté par psychoslave__ (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 Juke (site web personnel) . Évalué à 2.
quelle police utilise tu ? car à la place de తెలుగు j'ai des petits carrés.
[^] # Re: Utilité
Posté par psychoslave__ (site web personnel) . Évalué à 2.
Je sais pas, j'ai rien configuré de spécial, et je ne saurais trop où voir quel police est utilisée.
[^] # Re: Utilité
Posté par gouttegd . Évalué à 4.
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 dr_home . Évalué à 1.
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 Zenitram (site web personnel) . Évalué à 8.
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.
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 dr_home . Évalué à 2.
Comme la conclusion de mon message, tu veux dire (on n'a pas tous des super-machines de la mort) ?
Prends les scripts qui font du traitement de chaînes (ce qui est un peu la base du Shell) :
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
:[^] # Re: Utilité
Posté par Zenitram (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 dr_home . É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 troiscp
, ç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 gouttegd . Évalué à 3.
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 dr_home . É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 cargrep
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 Zenitram (site web personnel) . Évalué à 5.
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?
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 dr_home . Évalué à 2.
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.
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é !
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 gouttegd . Évalué à 8.
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).
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.
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 dr_home . Évalué à -1.
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).
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 gouttegd . Évalué à 4.
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 esten_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).
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 ?
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 « ë ».
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…
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 dr_home . Évalué à -1.
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.
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.
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 gouttegd . Évalué à 4.
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.
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.
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 :
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 dr_home . Évalué à -1.
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".
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.
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 psychoslave__ (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
Et non, le fichier tex d'origine je l'ai pas.
[^] # Re: Utilité
Posté par gouttegd . Évalué à 6.
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’avecLANG=C
(et non trois ordres de grandeur au-dessus comme avec grep 2.5.4).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 dr_home . Évalué à 1.
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):
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).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 Michaël (site web personnel) . Évalué à 3.
Quand on lance
au lieu de 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:
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.
à l'environnement.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
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 cdeblesson . Évalué à 8.
Comme le faisait remarquer Zenitram, à l'époque des vidéos HD, l'impact est négligeable.
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 gouttegd . Évalué à 3.
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.
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 dr_home . É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 Zenitram (site web personnel) . Évalué à 6.
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).
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 Gniarf . Évalué à 2.
comprends pas, moi j'ecris hopital.
[^] # Re: Utilité
Posté par calandoa . Évalué à 7.
Et dans ton hopital, quand il y a marqué « reserve aux internes » sur une porte, tu fais quoi? :)
[^] # Re: Utilité
Posté par dr_home . É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.
Ça tombe bien, je l'ai évoqué dans mon premier message.
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 vazco . É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 psychoslave__ (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 Zenitram (site web personnel) . Évalué à 2.
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 psychoslave__ (site web personnel) . Évalué à 8.
Oui mais :
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 Jerome Herman . É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 JGO . Évalué à 7.
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.
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 Jerome Herman . É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 Zenitram (site web personnel) . Évalué à 1.
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 Jerome Herman . É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 Zenitram (site web personnel) . Évalué à 4.
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.
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 Jerome Herman . É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 JGO . Évalué à 6.
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.
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 tu t'appelles Keith Packard tu résous le problème de façon élégante en écrivant Fontconfig.
[^] # Re: Utilité
Posté par Jerome Herman . É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 JGO . Évalué à 3.
Ç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).
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 Jerome Herman . É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 JGO . Évalué à 4.
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 Gniarf . Évalué à 2.
faut pas utiliser DOS alors, tête de bois...
[^] # Re: Utilité
Posté par JGO . É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 rewind (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 :
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 psychoslave__ (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 psychoslave__ (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 Antoine . Évalué à 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 Nopenope . Évalué à 4.
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 tiot (site web personnel) . Évalué à 3.
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 BFG . É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 Gniarf . Évalué à 1.
et si "les personnes" ne parlent pas anglais ? :)
[^] # Re: Utilité
Posté par BFG . Évalué à 6.
Justement, vous auriez dû lire le reste de mon message, ce que je vous encourage à faire maintenant.
[^] # Re: Utilité
Posté par claudex . É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 BFG . É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 BFG . É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 Zenitram (site web personnel) . Évalué à 2.
Pas le tiens. Ce n'est pas le cas pour d'autres.
[^] # Re: Utilité
Posté par BFG . Évalué à -1.
Je suis sûr que vous pouvez faire mieux que simplement dire "non", explicitez, donnez un exemple.
[^] # Re: Utilité
Posté par B16F4RV4RD1N . É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 BFG . É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 Zenitram (site web personnel) . Évalué à 2.
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 Antoine . Évalué à 1.
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 rewind (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 Antoine . Évalué à 2.
Je crois simplement qu'on utilise le mot "signification" dans un sens différent.
cf. http://fr.wikipedia.org/wiki/Signification#Linguistique et http://fr.wikipedia.org/wiki/Sens_%28linguistique%29
[^] # Re: Utilité
Posté par zebra3 . Évalué à 3.
Donc chacun a sa signification du mot « signification » ?
C'est ballot.
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 Zenitram (site web personnel) . Évalué à 1.
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 BFG . Évalué à 3.
Je me suis mal fait comprendre, prenons un exemple d'une phrase en français, avec deux façons de l'écrire :
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 Gniarf . É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 BFG . É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 vazco . É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 zebra3 . Évalué à 1.
Ç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 BFG . É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 zebra3 . É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 BFG . É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 Antoine . Évalué à 4.
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 tiot (site web personnel) . Évalué à 2.
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 Gniarf . Évalué à 8.
il faudrait proposer les totoz au consortium Unicode, c'est clair.
[^] # Re: Utilité
Posté par psychoslave__ (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 BFG . Évalué à 2.
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 BAud (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 Juke (site web personnel) . Évalué à 3.
derrière le canapé c'est pas forcement le plus adapté.
[^] # Re: Utilité
Posté par Julien Jorge (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 DLFP est mort . Évalué à 9.
☺
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Utilité
Posté par Zarmakuizz (site web personnel) . Évalué à 7.
Comment vont-ils faire pour ce smiley-là ?
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
# Super utile
Posté par blobmaster . Évalué à 4.
Si si.
comme tu peux le voir ici.
Par contre pour le clavier...
[^] # Re: Super utile
Posté par jiyuu . Évalué à 4.
C'est super, les utilisateurs d'Emacs ont enfin trouvé leurs claviers.
[^] # Re: Super utile
Posté par flagos . Évalué à 9.
Vu qu'on avait deja celui la pour vim, la boucle est bouclée...
[^] # Re: Super utile
Posté par boq . É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 jiyuu . É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 BFG . Évalué à 4.
Rappelons que "EMACS" est l'acronyme de "Escape-Meta-Alt-Control-Shift".
[^] # Re: Super utile
Posté par PachaFonk . Évalué à -1.
Ce n'est pas ce qui est dit là : emacs
[^] # Re: Super utile
Posté par boq . É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 Christophe B. (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 Michaël (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 Grunt . É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 DLFP est mort . É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 Sylvain Sauvage . É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 JoeltheLion (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 Grunt . É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 Sam Hocevar (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 imr . Évalué à 10.
C'est parce que l'un vient de l'autre.
[^] # Re: Et il en manque.
Posté par Olivier (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 Gniarf . Évalué à 10.
puisqu'on te dit qu'on a déjà ☭.
[^] # Re: Et il en manque.
Posté par dormomuso . Évalué à 0.
Y'a aussi un symbole pour les points godwin ?
[^] # Re: Et il en manque.
Posté par zebra3 . É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 tiot (site web personnel) . Évalué à 1.
Ils ont pensé à tout :
[^] # Re: Et il en manque.
Posté par fcartegnie . É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 Zenitram (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 Grunt . É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 Zenitram (site web personnel) . Évalué à 7.
Quelqu'un en a-t-il fait la demande officielle au consortium Unicode?
[^] # Re: Et il en manque.
Posté par psychoslave__ (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 weonbin . É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 psychoslave__ (site web personnel) . Évalué à 4.
Qui se dévoue pour faire une fonte qui comprends :
Parce que pour faire des arbres carrés, je sais faire :
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 ?
[^] # Re: Bon, si c'est comme ça
Posté par psychoslave__ (site web personnel) . Évalué à 5.
Ah oui, et aussi de quoi faire des machines de Turing aussi !
[^] # Re: Bon, si c'est comme ça
Posté par BAud (site web personnel) . Évalué à 3.
tant qu'on y est, c'est l'occasion de contribuer à
http://qelectrotech.org/showcategory.php?cat=collection_officielle (choisi au hasard)
histoire de couvrir pas mal de symbole même dans la mécaflu en y associant les outils pour le gérer.
# Goatsie ?
Posté par dinomasque . Évalué à 2.
C'est quoi le code Unicode du goatsie ?
BeOS le faisait il y a 20 ans !
[^] # Re: Goatsie ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
¤ ?
# Code
Posté par 2PetitsVerres . É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 psychoslave__ (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 2PetitsVerres . É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 Michaël (site web personnel) . Évalué à 1.
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.
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 psychoslave__ (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 Michaël (site web personnel) . Évalué à 2.
Ç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 psychoslave__ (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 Michaël (site web personnel) . Évalué à 4.
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).
Quelle pauvreté sémantique? C'est justement le contraire, puisque d'après notre ami:
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.
Ç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
Et oui i, j, k sont des entiers, etc.Dans ta source, la première citation est (c'est moi qui souligne):
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 psychoslave__ (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.
[^] # Re: Code
Posté par nicolas . É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 grondilu . É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.