Posté le 25/07/2022 16:16
.Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 163 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements
Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd
Citer : Posté le 25/07/2022 16:29 | #
Ah mais c'est parce que %c ne fait pas ce que tu veux. On balance pas juste des octets au hasard, c'est de l'UTF-8. Par exemple pour obtenir le caractère 0x81 :
>>> bytes(chr(0x81), "utf8")
b'\xc2\x81'
Il faut écrire les deux octets 0xc2 et 0x81. %c ne fait pas ça.
Je peux ajouter ça, mais entre temps tu es supposé saisir les caractères Unicode proprement, ie. taper "╬" dans ton programme après avoir dessiné ╬ à la position U+256C dans la police.
Citer : Posté le 25/07/2022 16:43 | #
Ok, je comprends mieux alors. Ca risque pas de fonctionner en effet.
Je pensais que pour les 256 premiers caractères en utf8 ça pouvait encore passer comme ça
Donc en fait mon besoin c'est juste d'avoir l'étendue d'un unsigned char dans la police et de pouvoir le sortir via un "%c", comme sur un PC par exemple avec la table ASCII complète et pas seulement les 128 premiers caractères).
L'unicode c'est le canon pour tuer la mouche, et surtout c'est pas trop adapté à ce que je voudrais en faire.
C'est un truc lourd à dev ?
Du coup pourquoi ca me sort les caractères 128 et 192 ? une "coincidence" ?
Citer : Posté le 25/07/2022 17:14 | #
Seuls les 128 premiers caractères sont accessibles "directement" en Unicode. La raison c'est que ça permet de garantir une propriété très utile de l'encodage : on est capables de se rendre compte quand tu coupes les caractères en deux.
Quand tu as un caractère multi-octet, les multi-octets sont tous supérieurs à 0x80. Par exemple le code point U+0081 c'est 0xc2 0x81 comme on vient de le voir. L'avantage de ça c'est que si tu sautes le premier octet pour une raison quelconque et que tu te retrouves avec 0x81, tu peux observer que c'est invalide et même déterminer combien d'octets il faut sauter pour atteindre le code point valide suivant. C'est un aspect important de l'encodage.
Le système de police de gint ne supporte que l'UTF-8 et je pense que ça devrait rester comme ça. Les encodages de texte c'est déjà franchement la merde dans le monde réel, alors autant ne pas en rajouter...
Générer une séquence UTF-8 à partir d'un code point n'est pas dur du tout ; d'ailleurs même la fonction qui décode ça dans gint en gérant les erreurs ne fait qu'une poignée de lignes.
Je peux l'ajouter à printf() (c'est supposé être supporté !), mais note que du coup le bon format c'est %lc. Je fais ça d'ici ce soir.
Citer : Posté le 01/08/2022 07:50 | #
Yo,
du coup Lephé, as tu eu le temps de jeter un oeil au support de l'extended ASCII (caractères 128-->255) dans gint ?
si oui, peux tu me dire comment inscrire le codage pour fxconv ? quel format faut il mettre (ascii ou autre chose) ?
si non, puis-je te demander cette évolution ?
Merci beaucoup
Citer : Posté le 01/08/2022 12:30 | #
Merci pour le rappel - et pour le projet reproductible !
J'ai poussé le support de %lc sur le dépôt fxlibc, que tu peux pour l'instant récupérer sur la branche dev.
Dans ton code, remplace juste u8"%c" par "%lc" (le u8 ne sert que pour le compilateur, quand tu as des caractères spéciaux dans ta chaîne ; cette information n'est pas transférée à printf()), recompile, et ça devrait aller tout seul. Rien d'autre à faire ailleurs.
Je ne suis pas opposé à supporter ce qu'il te faut si tu as des soucis, mais avec les éléments disponibles pour l'instant je préfère rester autant que possible sur UTF-8. Quand on commence à avoir plusieurs encodages c'est vite casse bonbon... x_x
Citer : Posté le 01/08/2022 13:28 | #
Non non t’inquiète pas. Le support de la table ascii dans toute sa gamme (255 caractères) est parfait. Je te remercie beaucoup.
J’avais vraiment pas en tête que gint gérait seulement les 128 premiers caractères.
Merci beaucoup.
Citer : Posté le 01/08/2022 14:53 | #
Lephé,
j'ai posté une PR dans fxsdk pour supporter le type "extascii" qui permet d'avoir les 256 caractères via un png.
Et ça fonctionne.
J'ai préféré ne pas modifier le type "ascii" pour ne rien casser et garder par défaut le type avec "seulement" les 128 premiers caractères. Passer sur la table 256 demande donc une modification explicite du type en "extascii".
Citer : Posté le 01/08/2022 15:01 | #
Cool. Je fusionne ça ce soir, encore que je le renommerai 8bit parce que l'appeler "ASCII" n'est jamais vraiment correct ; ASCII c'est 128 caractères, et "ASCII étendu" c'est un terme vague qui est utilisé par plein d'encodages différents dont aucun n'est supporté :P
Mais effectivement c'est plus pratique que d'avoir à créer un dossier.
Citer : Posté le 01/08/2022 16:25 | #
Oui bonne idée, en effet "extended ascii" n'a pas l'air d'être trop "consensuelle" comme appellation, 8bit ne prêtera pas à confusion.
Citer : Posté le 03/08/2022 22:55 | #
Désolé pour le délai, ça m'a échappé un moment. Après avoir hésité j'ai fini par l'appeler 256chars parce que 8bit suggère trop que ça implique un encodage du texte en 8-bit fixé, ce qui n'est pas le cas.
Citer : Posté le 04/08/2022 07:59 | #
Ok nickel pas de problème.
Merci beaucoup. Effectivement ça ne prête pas à confusion comme ça.