Ah ok, merci beaucoup pour l'explication poitue, je comprend (un peu) mieux.
En lisant ta réponse j'ai quand même gardé cette question en tête, en pensant (à tord ou à raison ?) que ce genre de « split » (comme LG, mais aussi pour les autres familles) serai une réponse pragmatique :
- Un contournement des bugs et limitations des logiciels dont tu parle (Pango, Qt, et peut-être d'autres ? - si on veut utiliser DejaVu sur d'autres OS, eg. en l'incluant dans un fichier ps, odf ou pdf ? et lorsque les bugs seront corrigés: la rétro-compatibilité avec les vieilles versions bugguées ?). Si j'ai compris ce que tu expliquais, le parti pris actuel semble être assez exigeant, et aurai tendance à butter sur les bugs des libs sous-jacentes (est-ce souhaitable ?)
- Une certaine souplesse pour l'utilisateur dans le choix de ses polices (même sans parler des « styles » comme ci-dessus). Comme DejaVu LG lui permet déjà de choisir la meilleure pour les scripts latins (et une autre pour des scripts différents où DV n'est pas la meilleure), on pourrai imaginer qu'un autre utilisateur souhaiterai utiliser DV pour afficher l'arabe et autre chose pour l'ASCII/latin, et encore autre chose pour ses formules mathématiques. De plus, lorsque la couverture d'une écriture par DV est légèrement incomplète, ce serait peut-être une solution temporaire pour qu'un utilisateur de cette écriture puisse basculer facilement vers un support complet mais moins beau, si cette incomplétude le gène trop ?
- La question du poid et de l'utilisation des ressources (à tout niveaux: poid en mémoire, sur le disque, téléchargements/updates, ...) qui reste effective, surtout si DejaVu est susceptible de progresser très vite et de couvrir de très nombreuses écritures, ou lorsqu'on veut l'utiliser pour de l'embarqué (PDA en Arabe, téléphone en Coréen, OLPC en Afrique ...), ou incluse dans des documents qu'on redistribue.
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 ? 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 ?
Est-ce que je me gourre / suis tout à fait à coté de la plaque ?
Et aussi, du coup, si la position des développeurs de DejaVu a été de proposer une version LG réduite aux caractères latins, est-ce que leur position sera aussi de proposer des versions réduites de ce type pour les caractères Arabes etc. ? Quels sont les avantages de distribuer, comme aujoud'hui, tout en un (avec seulement une possibilité de choix pour les caractères de DejaVu LG) ?
[^] # Re: Et l'occupation mémoire dans tout ça ?
Posté par herodiade . En réponse à la dépêche DejaVu, la famille de fontes libres de référence. Évalué à 2.
En lisant ta réponse j'ai quand même gardé cette question en tête, en pensant (à tord ou à raison ?) que ce genre de « split » (comme LG, mais aussi pour les autres familles) serai une réponse pragmatique :
- Un contournement des bugs et limitations des logiciels dont tu parle (Pango, Qt, et peut-être d'autres ? - si on veut utiliser DejaVu sur d'autres OS, eg. en l'incluant dans un fichier ps, odf ou pdf ? et lorsque les bugs seront corrigés: la rétro-compatibilité avec les vieilles versions bugguées ?). Si j'ai compris ce que tu expliquais, le parti pris actuel semble être assez exigeant, et aurai tendance à butter sur les bugs des libs sous-jacentes (est-ce souhaitable ?)
- Une certaine souplesse pour l'utilisateur dans le choix de ses polices (même sans parler des « styles » comme ci-dessus). Comme DejaVu LG lui permet déjà de choisir la meilleure pour les scripts latins (et une autre pour des scripts différents où DV n'est pas la meilleure), on pourrai imaginer qu'un autre utilisateur souhaiterai utiliser DV pour afficher l'arabe et autre chose pour l'ASCII/latin, et encore autre chose pour ses formules mathématiques. De plus, lorsque la couverture d'une écriture par DV est légèrement incomplète, ce serait peut-être une solution temporaire pour qu'un utilisateur de cette écriture puisse basculer facilement vers un support complet mais moins beau, si cette incomplétude le gène trop ?
- La question du poid et de l'utilisation des ressources (à tout niveaux: poid en mémoire, sur le disque, téléchargements/updates, ...) qui reste effective, surtout si DejaVu est susceptible de progresser très vite et de couvrir de très nombreuses écritures, ou lorsqu'on veut l'utiliser pour de l'embarqué (PDA en Arabe, téléphone en Coréen, OLPC en Afrique ...), ou incluse dans des documents qu'on redistribue.
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 ? 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 ?
Est-ce que je me gourre / suis tout à fait à coté de la plaque ?
Et aussi, du coup, si la position des développeurs de DejaVu a été de proposer une version LG réduite aux caractères latins, est-ce que leur position sera aussi de proposer des versions réduites de ce type pour les caractères Arabes etc. ? Quels sont les avantages de distribuer, comme aujoud'hui, tout en un (avec seulement une possibilité de choix pour les caractères de DejaVu LG) ?