Par exemple: le jour ou DejaVu couvrira la totalité des 10000+ Kanjis (Japonais)
J'espère que pas mal des problèmes des bibliothèques sous-jacentes seront résolus à ce moment là. :)
Par exemple: le jour ou DejaVu couvrira la totalité des 10000+ Kanjis (Japonais), un utilisateur arabophone aura le dilemne entre choisir DV LG + une autre police pour l'Arabe, ou DejaVu normal et une grosse utilisation de ressources ; réciproquement pour un utilisateur Japonophone. Une famille de polices façon "DejaVU LG", "DejaVu Arabic", "DejaVu Kanjis", "DejaVu Kanas", ... leur permetrai de choisir les composants qui les intéressse, non ?
Ça peut être intéressant mais pénalisant niveau temps (voir ci-dessous). Ça pose aussi un problème au niveau des références (des caractères visuellement identiques ne sont pas dessinés plusieurs fois). C'est bien évidemment soluble, mais il faut que quelqu'un écrive un Makefile assez rusé pour ça.
D'autre part, le calcul du rendu des chaines ne risque-t-il pas d'être ralenti si Pango & co ont besoin de parcourir, à chaque caractère, un grand nombre de glyphes pour trouver celui qu'il doit afficher ?
On m'a dit (c'est à vérifier donc), que le plus pénalisant est de procéder à des substitutions. Donc a priori il est plus rapide d'avoir une fonte contenant beaucoup de caractères que beaucoup de fontes qui contiennent peu de caractères. Il serait intéressant de voir comment évolue le temps d'accès à un caractère suivant la taille de la fonte. J'ose espérer que c'est plutôt constant en temps. :)
J'y pense, j'ai cru entendre dire que fontconfig est (sera ?) capable de gérer les priorités des différentes fontes suivant la langue. Dans ce cas ce serait vraiment idéal. Plus besoin de s'arracher les cheveux à faire différentes version de DejaVu. L'utilisateur n'a qu'à choisir sa fonte préférée suivant la langue.
[^] # Re: Et l'occupation mémoire dans tout ça ?
Posté par med . En réponse à la dépêche DejaVu, la famille de fontes libres de référence. Évalué à 2.
J'espère que pas mal des problèmes des bibliothèques sous-jacentes seront résolus à ce moment là. :)
Ça peut être intéressant mais pénalisant niveau temps (voir ci-dessous). Ça pose aussi un problème au niveau des références (des caractères visuellement identiques ne sont pas dessinés plusieurs fois). C'est bien évidemment soluble, mais il faut que quelqu'un écrive un Makefile assez rusé pour ça.
On m'a dit (c'est à vérifier donc), que le plus pénalisant est de procéder à des substitutions. Donc a priori il est plus rapide d'avoir une fonte contenant beaucoup de caractères que beaucoup de fontes qui contiennent peu de caractères. Il serait intéressant de voir comment évolue le temps d'accès à un caractère suivant la taille de la fonte. J'ose espérer que c'est plutôt constant en temps. :)
J'y pense, j'ai cru entendre dire que fontconfig est (sera ?) capable de gérer les priorités des différentes fontes suivant la langue. Dans ce cas ce serait vraiment idéal. Plus besoin de s'arracher les cheveux à faire différentes version de DejaVu. L'utilisateur n'a qu'à choisir sa fonte préférée suivant la langue.