La dernière version du compilateur inform6 propose l’option -Cu pour compiler un fichier source en UTF-8, mais impossible de l’utiliser.
Le programme qui suit compile mais l’affichage n’est pas correct.
Si quelqu’un qui maîtrise l’anglais peut poser la question du bon usage de cette option et si elle est valide pour produire un fichier .z5 ou .z8
Merci.
!ReleaseNotes.html : A new command line switch -Cu can be used to specify that the source file character set is UTF-8, allowing source files to contain Unicode characters beyond those defined in ISO 8859-1 to 8859-9.
Zcharacter table + ‹ @{a9} › ‹ @{A2} › ‹ @{2022} ›;
! Le compilateur exige ‹ @{a9} › ‹ @{A2} › dans la ‹ Zcharacter table › alors qu’ils n’ont rien à y faire !?
De plus, en l’appelant dans mon projet I6, ça provoque des erreurs lors de l’appel des biblio francophones (que j’avais converties en utf8 pour l’occasion)
De toute façon je ne vais sans doute pas utiliser inform 6.33 pour mes projets I6, car il y a d’autres problèmes indépendamment de ça, notamment ils ont modifié parserm.h sans incrémenter la version ni la date du fichier, ce qui n’est pas très malin (peut-être ça sera corrigé dans la version finale), mais il y a d’importants ajouts de code et ça provoque des erreurs à la compilation :
"/usr/local/share/inform/6.33b1/module/parserm.h", line 5072: Error: No such constant as "Epilogue"
"/usr/local/share/inform/6.33b1/module/parserm.h", line 6600: Error: No such constant as "UpperCase"
"/usr/local/share/inform/6.33b1/module/parserm.h", line 6601: Error: No such constant as "LowerCase"
"/usr/local/share/inform/6.33b1/module/verblibm.h", line 1019: Error: No such constant as "non_floating"
"/usr/local/share/inform/6.33b1/module/verblibm.h", line 1587: Error: No such constant as "ObjectDoesNotFit"
Compiled with 5 errors and 4 warnings
la version résultant affiche ces erreurs en plus du jeu lui-même :
Quoi qu’il en soit il est bien précisé sur le site :
Donc il y a peut-être des effets de bord non prévu pour des jeux purement inform6.
Ouh là, je vais repasser à la version 6.31 en attendant moi. Merci pour le rapport de bugs Auraes.
Otto, en ce qui concerne les propriétés manquantes, je n’ai pas eu ces bugs-là en compilant Homeland Security, mais peut-être que mon code n’utilise pas les mêmes fonctions.
En tout cas, si le compilateur est officiellement incompatible avec les projets Inform 6, je ne suis pas content Idéalement il faudrait que quelqu’un fasse un fork purement I6, ou en tout cas qu’ils essaient de rendre le compilateur compatible avec I6 (ça doit être possible, avec des #IFDEF, non ?). J’ose espérer que c’est juste une erreur de leur part…
Ah, je comprends. C’est quand même embêtant, mais c’est moins grave.
J’ai vu que Andrew Plotkin t’avait répondu sur le forum, et il dit que normalement toute version du compilateur pourrait/pourra être utilisée pour des projets I6. Ca répond à ma question, et c’est donc rassurant.
Du coup, c’est pour les bibliothèques que c’est embêtant, vu que des nouvelles versions de celles-ci pourraient aussi être utiles (si jamais elles ont des bugs par exemple). On va voir ce que David Griffith dit j’imagine…
Moi aussi ça compile. C’est l’affichage qui pose problème avec effectivement un caractère excédentaire.
Le compilateur exige ‹ @{a9} › ‹ @{A2} › dans la ‹ Zcharacter table › alors qu’ils n’ont rien à y faire !?
Je pensais que pour inform6, les caractères UTF-8 du fichier source présents dans ISO-8859-1 seraient simplement convertis, à l’ouverture du fichier, dans ce format et pour les autres, on utiliserait la ‹ Zcharacter table ›.
Bon, c’est bizarre surtout pour les caractères accentués classiques.
Pour le mise en forme des textes Inform6 est une vraie galère (retour ligne, paragraphe, caratère gras…); un peu d’Unicode n’aurait pas fait de mal.
Andrew Plotkin a répondu que ça ne pose pas de problème avec glulx mais il a confirmé le problème avec zcode et il va regarder.
idem
De façon générale je préfère avoir tous mes fichiers textes dans un seul encodage, en l’occurrence en utf-8. D’ailleurs je crois que mes fichiers .inf sont les seuls qui sont encore en iso-machin chez moi. Mais d’un autre côté, les éditeurs de texte avancés permettent de détecter correctement l’encodage à l’ouverture, et quand j’utilise Geany ou Vim, ça ne pose pas vraiment de problème. Pour les caractères gras, les retour à la ligne, je ne vois pas en quoi cela a à voir avec l’unicode par contre.
Plotkin vient de régler le bug : il suffisait d’ajouter un « continue » quelque part apparemment. Ca sera sûrement inclus dans la prochaine version (pour l’instant c’est que sur son GitHub, github.com/erkyrath/inform6 , mais ils devraient sans doute propager la modif).
Quelle bonne nouvelle et qu’elle réactivité ! Ça fonctionne !
Donc, pour les caractères qui ne sont pas dans la Table ZSCII CHARACTER HIGHER (doc. page 520), il suffit de rajouter l’Unicode du caractère concerné dans la ‹ Zcharacter table ›. Le ‹ + › après ‹ table › signifie que l’on rajoute ces caractères à la table (HIGHER) existante. Sans le ‹ + ›, il est possible de remplacer ceux-ci.
Et il faut bien sûr que la police de caractère de l’interpréteur soit Unicode et qu’elle supporte ces caractères et ne pas oublier de compiler avec l’option -Cu.
Ce qui donne pour une simple ‹ puce › et un ‹ caractère de suspension › :
[code]!% -Cu
!% -v8
!Source encoding UTF-8 No Mark
Zcharacter table + ‹ @{2022} › ‹ @{2026} ›;
[ main key;
print "•…";
@read_char 1 ->key;
];[/code]
[code]!% -Cu
!% -v8
!Source encoding UTF-8 No Mark
Bon, apparemment c’est un problème sur les versions 6.32.1 et 6.33.
Sur la 6.32, j’obtiens :
Mais sur les deux autres, ça crash. En fait l’instruction ‹ pop › n’existe plus dans la version ‹ Z-Machine Standard 1.1 › .Mais cela ne devrait pas faire planter le système.
(Inform version 6.33, library version 6/12)
C’est vraiment bizare : c’est parser.h qui inclut linklpa.h qui contient la déclaration de l’attribut non_floating : linklpa.h :
[...]
Attribute non_floating alias absent;Mais il ne semble pas la considérer tant qu’elle est à l’intérieur de linklpa.h !? Par contre si je l’efface de linklpa.h et je la mets dans parser.h, juste après l’Include de linklpa, cela fonctionne !?parser.h :
[...]
Include "linklpa";
Attribute non_floating alias absent;Assurément il y a un problème. As-tu posé la question ?
non, par contre on verra ce que ça donnera quand tout ça sortira de la beta. Tu peux proposer tes services pour mettre ça en ordre si le sujet t’intéresses, vu que tu sembles assez bien le connaître.
J’ai passé mes librairies VERB+NOUN en lib 6/12 et en fait, les routines UpperCase et LowerCase se trouvent maintenant dans leur english.h : Tu les récupères dans leur fichier et tu les mets dans ton French.h. Pour les autres, c’est pareils : les déclarations se trouvent, en bas de leur fichier grammar.h : Tu les recopies dans ton FrenchG.h et cela fonctionne ! Je n’est pas eu de problème avec non_floating, je ne sais pas si tu en auras un.
Du coup, plus de problèmes avec un objet « orange » : l’apostrophe est bien collé au mot : http://auraes.free.fr/inform6/orange.z5[code]!% -Cu
!% +language_name=english
Include « Parser »; Include « VerbLib »;
Object room1;
!/* L’orange | l’orange | Une orange | une orange
Object orange « orange » room1
with
name ‹ orange ›,
article « une »,
articles « L’ » « l’ » "une "
has edible female
;
Object oeuf « œuf » room1
with
name ‹ oeuf ›,
article « un »,
articles « L’ » « l’ » "un "
has edible male
;
Object ile « Île » room1
with
name ‹ ile ›,
article « une »,
articles « L’ » « l’ » « une »
has
;
Object sucre « sucre » room1
with
name ‹ sucre ›,
article « du »,
articles "Le " "le " "du "
has edible male
;
Object confiture « confiture » room1
with
name ‹ confiture ›,
article « de la »,
articles "La " "la " "de la "
has edible female
;
[ Initialise i;
for (i = orange : i <= confiture : i++)
print « ^ », (The) i, " | ", (the) i, " | ", (A) i, " | ", (a) i, « ^ »;
new_line;
location = room1;
];
Include « grammar »;
[/code]