Référence FONTCHARACTER
Posté le 28/11/2016 01:53
Hello,
nouveau petit projet utile, Jules et moi faisons actuellement une référence de l'encodage de CASIO, que nous nommerons avec le petit nom qui lui est donné par le SDK : FONTCHARACTER (tout en majuscules, ça ne serait pas drôle sinon). Cette référence a pour but de répertorier tous les caractères existants sur les calculatrices CASIO, leur compatibilité, leur nom, leur apparence, leur équivalent Unicode (s'il existe), etc.
Pour le coup, on ne travaille pas exactement sur la même chose. Je m'occupe de la référence technique, en YAML, que n'importe quel projet peut inclure et utiliser directement :
https://forge.touhey.fr/casio/casiowin/fontcharacter_reference/
Jules, quant à lui, concocte un générateur de site statique qui, à partir de la référence technique, produira une version web de celle-ci :
http://git.planet-casio.com/CoiledSpring/FONTCHARACTER_Web_Reference
C'est un petit projet utile dès qu'on souhaite interagir avec du contenu produit par ou pour les calculatrices CASIO, qui a également pour but de centraliser les découvertes sur les caractères CASIO, de façon lisible par les humains (grâce à la référence web) et les programmes divers (afficher un programme sur un PC, ...).
Pour le moment, je travaille seul pour finir une première version de la référence (et je pense que Jules aussi), mais dès qu'elle sera terminée, n'hésitez pas à contribuer pour corriger les erreurs grotesques ou autres ! (voyez le
CONTRIBUTING.md)
Citer : Posté le 28/11/2016 07:32 | #
Hey, utile. Vous avez pensé à exploiter le pdf qui est dans l'archive du SDK, qui contient déjà la majorité des symboles ?
Citer : Posté le 28/11/2016 10:58 | #
Yep, ça constitue ma documentation avec ceci
Mon blog ⋅ Mes autres projets
Citer : Posté le 28/11/2016 16:22 | #
Y'en a-t-il d'autres, par ailleurs, que ceux listés dans les pdfs ? (J'aurais dû demander ça tout de suite)
Citer : Posté le 28/11/2016 16:27 | #
Pour ce que j'ai vu, il manque des caractères (genre nano, micro, etc), mais la majorité des caractères "blancs" présents dans le PDF sont en réalité des "multi-caractères" (e.g. "cos "), donc m'est avis qu'il n'en manque pas tant que ça. Mais je ne saurais pas te dire avec certitude tant que je n'ai pas fini de les répertorier (et il y en a un paquet).
Ajouté le 08/12/2016 à 01:10 :
Petit message pour dire que le fichier contenant les données de caractères a dépassé les 3350 lignes
Je suis encore loin d'avoir répertorié tous les caractères, et je n'ai même pas encore ajouté tout ce qui est compatibilité des caractères avec les différents modèles (j'ai tout juste commencé à ajouter de l'extension-specific, avec quelques extensions de C.Basic par exemple). Enfin, le principal est que ça avance, de plus en plus doucement, mais sûrement.
Ajouté le 09/01/2017 à 02:51 :
J'ai a priori fini mon catalogue. 5710 lignes pour les données des caractères, c'est pas si mal.
Il manque sans doute des caractères rajoutés pour la Prizm. J'aimerais bien que quelqu'un me les liste (dans le même format que celui de characters.yml, mais dans un fichier distinct). C'est chronophage, mais une fois que c'est fait, c'est fait, donc pensez un peu aux nouveaux projets !
Aussi, j'ai instauré un système de sets avec, comme objectif final (pour ce système uniquement), la gestion de la compatibilité des caractères. Le principe est simple : un set, c'est un pack de caractères apparus en même temps. Un set peut avoir un parent, c'est la "base" de caractères sur laquelle elle est construite (même si elle override certains caractères). Ce système de sets gèrerait autant les opcodes/caractères "natifs" que ceux ajoutés par des interpréteurs/autres alternatifs tels que C.Basic. L'objectif final est d'évaluer la compatibilité des programmes d'une archive avec les différentes calculatrices en évaluant celle de l'ensemble des caractères utilisés (en demandant tout de même à l'utilisateur quelle extension il utilise, s'il en utilise une).
Or, je ne connais pas vraiment l'histoire des caractères CASIO (quand ont-ils été ajoutés, etc). Du coup, je cherche quelqu'un qui sait, ou une documentation écrite (même des bribes, ce serait cool). Merci d'avance !
Mon blog ⋅ Mes autres projets
Citer : Posté le 09/01/2017 17:13 | #
Je me permets de signaler, vu que les caractères s'étendent pour former les opcodes, le coup de la compatibilité est plutôt intéressant. Sinon pour l'historique, tu peux chercher dans les tables de caractères des divers fichiers d'OS, quitte à désassembler un peu peut-être.
Citer : Posté le 09/01/2017 18:24 | #
Comme je profiterai de la RDP de demain pour faire un appel à l'aide vis-à-vis de ce projet, je prépare ici en faisant un petit howto.
Vous êtes motivé(s) pour aider à la réalisation de ce projet (parce que vous croyez en le libre, parce que vous souhaitez apporter votre patte au travail de libération du monde CASIO, ...), comment faire ?
Ce qui est requis :
- savoir lire/écrire un minimum anglais (puisque dans un premier temps, tout est en anglais) ;
- prendre connaissance du format utilisé par le projet ;
Ce qu'il reste à faire (cf. le guide de contribution) :
- gérer la compatibilité des caractères (si vous avez lu la description du format citée dans ce qui est requis, vous savez ce que c'est) ;
- investiguer sur les caractères inconnus ;
- voir s'il y a des erreurs.
Merci d'avance, et courage ! C'est pas facile, mais votre travail sur cette référence est bénéfique à tout le monde
Mon blog ⋅ Mes autres projets
Citer : Posté le 20/02/2017 00:40 | # |
Fichier joint
Bon, *évidemment*, l'appel précédent n'a pas trouvé d'oreille prête à participer. J'ai finalement eu le temps de terminer une version plutôt satisfaisante, gérant quatre sets "officiels" (OS_1.00, OS_1.05, OS_2.00, OS_2.04) et une extension (C.Basic). Je commence à me lancer sur la lib qui gérera tout ça. A la base, il était prévu qu'il s'agisse de la libg1m, mais finalement, ne serait-ce que pour commencer, j'en ai fait une lib à part, la libfontcharacter.
La hiérarchie actuelle des libs est donc la suivante : la libg1m dépend de la libfontcharacter, et la libp7 est indépendante. Afin d'assurer le support du transfert des fichiers de la mémoire principale (qui n'est actuellement aucunement supporté), la libg1m, lorsqu'elle sera suffisamment mature, sera une dépendance (optionnelle) de la libp7.
Je ne pense pas créer de topic supplémentaire, autant me servir de celui-ci. Aussi, je ne publierai pas de bulletin sur les autres topics (libp7, libg1m), je le ferai lorsque je ferai une avancée significative sur ces projets en particulier. De plus, je pense insérer, peu à peu, tous ces "petits projets" dans le projet P7, dont le but s'élargira par voie de conséquence pour devenir un but plus général de libération du logiciel autour des calculatrices CASIO.
Mon blog ⋅ Mes autres projets
Citer : Posté le 20/02/2017 11:24 | #
Je dois avouer que j'ai un peu du mal à suivre. (Alors bon, outre le fait que tu développes et releases plus vite que tout le reste de la communauté réuni.) Peut-être pourrais-tu expliquer plus en détail ce qu'on peut faire en pratique avec cette lib, et comment ses utilisateurs s'en serviront, montrer des exemples d'application ? J'ai un poil de mal à situer exactement tout ça, et je pense que je ne suis pas le seul.
Aussi, n'hésite pas à nous montrer directement sur le topic à quoi ressemble ton programme (ça vaut aussi pour la libg1m ou la libp7) : par exemple en montrant ce qui se passe sur une exécution typique quand tu fais des changements importants. Ce serait un moyen simple et explicite de nous montrer de quoi il s'agit.
Au fond, je suis persuadé que tu fais plein de trucs intéressants, mais je n'ai pas toujours le temps ou la motivation d'aller creuser en détail pour lire ton code ou tester tes binaires : du coup, je suis à moitié perdu, et je sais qu'on en discute pourtant régulièrement sur le chat. Imagine alors pour les autres membres...
Citer : Posté le 20/02/2017 12:01 | #
Autant pour moi, voici quelques exemples (une version avec coloration se situe ici) :
/* La première utilité de cette lib est de pouvoir passer de la forme
* multi-byte de l'encodage (e.g. "H\xE6\x0A") à la forme fixed-width
* (e.g. {'H', 0xE60A, 0}), et inversement.
*
* Pour passer de la forme fixed-width à la forme multi-byte, par exemple: */
FONTCHARACTER source[] = {'H', 0xE60A, 0};
char mbs[10];
if (fc_wcstombs(mbs, source, 10) == (size_t)-1)
return (1); /* erreur! */
/* La seconde utilité est de pouvoir convertir une chaîne d'opcodes
* FONTCHARACTER en une chaîne Unicode: */
wchar_t uni[10];
if (fc_tounicode(uni, source, 10) == (size_t)-1)
return (1); /* erreur! */
setlocale(LC_ALL, "");
printf("La chaîne est la suivante: %ls\n", uni);
/* Bien entendu, cet exemple n'est qu'un exemple avec des simples buffers.
* Il existe d'autres usages de ces fonctions qui ne font que compter le
* nombre d'éléments requis dans le buffer destination, pour pouvoir ensuite
* allouer de l'espace et convertir pour de vrai!
*
* Gardez aussi en tête que ces fonctions ne sont pas définitives. */
Aussi, la doc se situe très souvent dans les manpages. J'en copierai dans les topics quand je penserai avoir trouvé une forme définitive à ces libs (bon, ici, du coup, c'est une exception
Mon blog ⋅ Mes autres projets
Citer : Posté le 20/02/2017 12:07 | #
Ah ben voilà, c'est déjà plus explicite. Du coup dans les questions que je me pose vis-à-vis des applications ou fonctionnalités :
→ Affichage sur PC de programmes Basic ?
→ Conversion unicode → fontcharacter ?
→ Détection du format d'un chaîne donnée ?
Du coup, question pour moi et qu'on se mette d'accord : si je dois implémenter des sets étendus pour les fontes de gint, tu penses qu'il faudrait suivre quel encodage ?
Citer : Posté le 20/02/2017 12:32 | #
→ Affichage sur PC de programmes Basic ?
C'est le but. Après, je n'ai pas encore trouvé d'équivalent Unicode de pas mal de caractères FONTCHARACTER, donc c'est une conversion incomplète pour le moment...
→ Conversion unicode → fontcharacter ?
Je compte implémenter ça à un moment, mais rien de tel n'est là pour le moment.
→ Détection du format d'un chaîne donnée ?
Je compte faire ça à un moment, mais ça requiert d'intégrer les sets et tout, donc ça risque d'être bien galère
Du coup, question pour moi et qu'on se mette d'accord : si je dois implémenter des sets étendus pour les fontes de gint, tu penses qu'il faudrait suivre quel encodage ?
Tricky question. Julese50 m'a convaincu que si on faisait un OS alternatif, il faudrait utiliser l'Unicode (même partiellement implémenté). Sauf que gint permet de faire des add-ins pour CASIOWIN...
Je dirais bien Unicode, mais il faudra alors que tu fasses la conversion Unicode -> FONTCHARACTER pour tout ce qui est noms de fichiers. Donc up to you.
Mon blog ⋅ Mes autres projets
Citer : Posté le 20/02/2017 14:29 | #
C'est l'inverse, dans ce cas. Les fontes c'est pour l'affichage, donc ce serait FONTCHARACTER → Unicode pour pouvoir afficher des noms de fichiers.
Ça reste assez lourd de se trimballer toute la conversion. Je verrai quand même ce qu'il y a de récupérable dans l'Unicode (d'utile j'entends).