Intel One Mono est le nouveau GPU qu’Intel développait en secret. Une bête de course du futur, « One » c’est l’anneau qui va les remplacer tous, le sujet unique qui occupe les forums depuis 3 semaines. La particularité de ce processeur graphique est d’avoir des circuits programmables (en Mono justement), comme le CPU de Transmeta auquel Linus Torvalds, le seul, l'unique participait. Il pourrait ainsi émuler les circuits 2D ou 3D de Matrox, AMD, NVidia, … y compris les plus récents. Le monde tremble sur ses bases. Alléchant, non ?
Et là les développeurs s’exclament :
Malheureusement le premier avril est passé, le joli nom est celui d’une nouvelle police de caractère sous licence OFL (Open Font License)1. Une police à chasse fixe, vous l’aurez compris, conçue pour les besoins des développeurs.
Cette police ne contient que les caractères latins, en 4 graisses avec leurs italiques. Ça se comprend, puisqu’elle est conçue pour programmer. Sa conception vise à plus de clarté en lecture, afin d’éviter la fatigue des yeux et les fautes de frappe — on pourrait dire que ça rentabilise les développeurs, que le capitalisme a du bon, tout ça… D’accord, mais le travail est bien fait : pour la conception, un groupe de testeurs malvoyants a participé à toutes les étapes et l’équipe d’Intel s’est entourée de professionnels de la typographie, la police est fournie en différents formats, manuellement optimisés pour le grand écran, l’écran du mobile et l’utilisation dans les pages web.
Quelques caractéristiques OpenType sont présentes, notamment les optimisations d’affichage selon la langue. Je vous renvoie sur la description de la police pour les détails.
- Le dépôt du projet sur Github https://github.com/intel/intel-one-mono
- Télécharger la version 1.0 https://github.com/intel/intel-one-mono/releases/tag/V1.0.0
-
la license OFL est un compromis entre le libre et les graphistes, elle est moins permissive que la GPL ou la license BSD (évidemment !), mais elle est appouvée par la FSF et beaucoup de polices appelées libres l’utilisent. ↩
# JetBrains mono
Posté par ff9097 . Évalué à 4.
A comparer à JetBrains Mono
[^] # Re: JetBrains mono
Posté par barmic 🦦 . Évalué à 3.
Je n'ai pas trouvé de mention de gestion de ligatures.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: JetBrains mono
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 2.
Ce ne serait pas incohérent pour une police à chasse fixe ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: JetBrains mono
Posté par barmic 🦦 . Évalué à 3.
C'est vrai que ça aurait pu, mais ils le font sans changer la taille des caractères. Soit le signe de remplacement est aussi grand que ceux qu'il remplace, soit ils ajoutent de l'espace.
Ça peut être observé sur la page où ils décrivent la font : https://www.jetbrains.com/fr-fr/lp/mono/#ligatures
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# il y a quand même un inconvénient
Posté par totof2000 . Évalué à 10.
Je suis un programmeur dont la langue natale contient d'autres caractères, j'ai envie de programmer des interfaces pour des personnes qui utilisent un autre alphabet, ou de mettre des commentaires dans ma langue. Comment puis-je faire pour que mon code source soit affichable dans mon éditeur ? Je n'utilise pas cette police ? Pas très inclusif …
[^] # Re: il y a quand même un inconvénient
Posté par orfenor . Évalué à 6.
Ce n'est que la version 1.0, il faut bien commencer par quelque chose.
[^] # Re: il y a quand même un inconvénient
Posté par Glandos . Évalué à 5.
J'en rajoute une couche : en Java, les caractères Unicode peuvent être utilisés dans les noms de variables. Ce n'est pas très conseillé, mais c'est possible.
Et je pense que ce n'est pas le seul langage à le permettre.
[^] # Re: il y a quand même un inconvénient
Posté par vmagnin (site web personnel) . Évalué à 5.
En Python, ça marche aussi.
[^] # Re: il y a quand même un inconvénient
Posté par Gof (site web personnel) . Évalué à 4.
Tout les langues modernes permettent ça : JavaScript, Rust, C++, juste pour citer ceux que je connais.
[^] # Re: il y a quand même un inconvénient
Posté par ff9097 . Évalué à 5. Dernière modification le 20 mai 2023 à 16:05.
Allons Monsieur
[^] # Re: il y a quand même un inconvénient
Posté par barmic 🦦 . Évalué à 5.
Très concrètement je ne connais pas de font CJK qui aient des usages dédiées. La quantité de travail que représente d'ajouter litérallement des dizaines de miliers de signes en gardant le même soin du détail est tout simplement délirant. Donc dire ma langue n'est pas supportée, c'est un scandale me parait un peu léger. Il y a plusieurs systèmes d'écriture très largement utilisés qui ne peuvent pas être supportés. Toutes les fonts que je connais les supportants sont dédiés à ces systèmes d'écriture. Tu trouve même des fonts qui listent les sinogrammes, mais pas le hangeul de Coréen (qui n'a même pas 50 signes il me semble). Évidement tu as le problème avec l'arabe et le cyrillique sont bien plus petits, je sais pas si le fait d'écrire de droite à gauche ajoute de la complexité.
Mais du coup ils affirment gérer 200 langues. On est loin des 7000 parlées dansle monde, mais je trouve ça honnète je trouve (surtout dès la première version publique). Par contre ils ne les listent pas.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: il y a quand même un inconvénient
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 2.
Oh non, beaucoup plus que ça en réalité. En ne réalisant que les jamo isolés modernes et en n’utilisant que le système de normalisation pour re-créer les caractères composés, tu peux réduire à 67 symboles hors ponctuation, mais dans ce cas tu perds presque toute l’optimisation pour la lecture qui est le but de la police mentionnée ici.
La connaissance libre : https://zestedesavoir.com
[^] # Re: il y a quand même un inconvénient
Posté par barmic 🦦 . Évalué à 2.
J'avoue que je me suis appuyé sur la langue et de tête et j'ai pas regardé comment c'était encodé en unicode. Je pensais qu'unicode ne traitait que les signes isolés, mais ça ne change rien que la font aurait dû gérer toutes les combinaisons (que ce soit via des ligatures ou non).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# sources.zip
Posté par HL . Évalué à 4. Dernière modification le 20 mai 2023 à 16:06.
Héberger les polices dans un ZIP et mettre le ZIP dans un dépôt Git ça a quel utilité ?
[^] # Re: sources.zip
Posté par nlgranger . Évalué à 1.
De profiter du système de signature des commits de git pour les zips?
[^] # Re: sources.zip
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 21 mai 2023 à 00:37.
Surtout qu’après un regard rapide, ça a l’air d’être surtout du XML (donc un format très bien géré par Git) même s’il n’est pas destiné à être modifié à la main, camouflé sous diverses extensions.
La connaissance libre : https://zestedesavoir.com
# Le SIL ne se préoccupe pas des graphistes
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 24 mai 2023 à 12:44.
Les licences SIL OFL se fichent un peu des graphistes, ou, plus précisément, elles n’ont pas été conçues en pensant d’abord à cette catégorie de métier.
L’objectif du SIL (EN) est avant tout de lever, ou de minimiser, les barrières des langues entre les populations. La licence SIL OFL a pour objectif principal de permettre et faciliter le développement de polices de caractères pour les diverses langues. Le fait qu’elle interdise la vente d’une police seule sous cette licence permet, notamment, d’éviter une appropriation éventuelle et à but lucratif de la police qui la rendrait ainsi plus difficile d’accès aux locuteurs et locutrices de ladite langue.
Et la licence est une licence libre (EN) :
Et, en VF:
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.