mViewer GX 1.3 pour Nspire-Lua, version hors-ligne améliorée

→ **MyCalcs** profile · by **critor** » 23 Oct 2014, 11:43

Actuellement, le mode le plus populaire de notre convertisseur de documents en ligne mViewer GX Creator est le mode Nspire-Lua, probablement parce que contrairement au mode Nspire-Ndless les documents ainsi créés peuvent être lus sur toute calculatrice TI-Nspire.

Toutefois, la version 1.1 du lecteur mViewer GX utilisée par le générateur ne gère que le format d'images Nspire-Lua introduit avec la version TI-Nspire 3.0. Cela signifie que les données images sont directement intégrées au code source sous forme ASCII, avec des inconvénients sur:

la taille des fichiers générés
la quantité de mémoire vive (RAM) nécessaire lors de l'ouverture du fichier, puisque les codes source Lua de chaque page sont chargés simultanéments en RAM - en plus du chargement sous forme affichable, chaque image est donc chargée une deuxième fois en RAM de façon supplémentaire et inutile sous une forme occupant en prime plus d'espace à l'intérieur du code source Lua...

En conséquence, le nombre de pages pouvant être regroupées dans un même fichier était rapidement limité, usuellement 3 dans la qualité maximale, ce qui veut dire davantage de fichiers pour un même document. Or, plus vous avez de fichiers dans la calculatrice TI-Nspire, plus cette dernière ralentit lors de l'accès à l'explorateur de documents via

...

Heureusement, nous vous sortons aujourd'hui une alternative avec le nouveau lecteur mViewer GX 1.3 !

Ce lecteur gère le nouveau format d'images Nspire-Lua introduit avec la version TI-Nspire 3.2, sous forme de ressources externalisées.

Les données images ne sont plus dans le code source Lua mais simplement dans l'arborescence XML du document TI-Nspire, ce qui permet:

de les stocker sous une forme optimale occupant moins de place et générant donc des fichiers plus petits et plus rapides à ouvrir
de supprimer le chargement supplémentaire inutile en RAM décrit ci-dessus et donc de repousser très loin la limite de mémoire
Nous ne savons pas quelle est la nouvelle limite, mais 10 pages A4 de 896px de hauteur passent désormais sans aucun problème comme vous constaterez ci-contre !

Malheureusement, nous ne connaissons à ce jour aucun moyen de générer de tels fichiers autrement qu'en utilisant le logiciel TI-Nspire. A la différence de la solution mViewer GX 1.1, la procédure pour intégrer vos propres données à mViewer GX 1.3 est donc pour le moment manuelle et hors-ligne, et nécessitera l'utilisation du logiciel TI-Nspire.

Liens :

mViewer GX 1.3 (pour TI-Nspire en version 3.6 ou ultérieure)
Tutoriel pour insérer vos propres images dans mViewer GX 1.3

→ **MyCalcs** profile · by **AlexRider38** » 23 Oct 2014, 17:42

Je comprends pas en quoi on est obligé de passer par le logiciel Ti-nspire (ça a rien de prétentieux, je veux juste comprendre ^^). C'est parce qu'on ne connait pas encore la méthode du logiciel pour faire ces ressources externalisées?

→ **MyCalcs** profile · by **critor** » 23 Oct 2014, 18:01

Personnellement, je ne connais pas le code XML permettant d'inclure des ressources externes.
La méthode de Levak 'clipboarddumper' ne remonte pas assez haut dans l'arborescence XML pour avoir les définitions de ressources.
Le 'tns2xml' de Excale quant à lui n'a jamais été mis à jour pour Ndless 3.6, et en version 3.1 il est impossible d'ouvrir des documents 3.2.

Mais même une fois que je connaîtrai le code XML, je crains que Luna, qui n'a pas été mis à jour depuis très longtemps, n'arrive pas à générer un .tns correct.

My calculator programs · by **Adriweb** » 23 Oct 2014, 18:17

A un moment, Jim Bauwens avait regardé pour essayer de mettre des ressources, mais sans succés. Je ne crois pas qu'il ait réessayé depuis.

Par ailleurs, @AlexRider38, la raison pour laquelle il n'existe pas déjà d'outil (genre Luna, justement) pour faire des choses "avancées" (certaines sont faisables et faites, d'autres non faisables, et d'autres entre les deus), c'est parce que les ressources ne sont plus dans le code Lua, quand on regarde le XML. Et donc la technique utilisée par Luna pour créer des .tns valides ne marche tout simplement pas pour faire ce qu'on veut ici.
La raison à ceci est que Luna est contraint à être programmé de telle sorte que ça ne viole pas le brevet de TI concernant leur compression XML dans les fichiers .tns (je cite Lionel sur ce qu'il y a autour : "XML compression + compressed with ZLIB + encrypted with triple-DES"). Bref, personne n'a donc passé de temps (et ça en demanderait beaucoup !) à travailler sur quelque chose qui serait illégal si rendu public.

Mais la solution proposée ici par Critor avec le tutorial reste valide pour une majorité écrasante d'utilisateurs (en gros, ceux qui sont sur Windows ou Mac, puisqu'il faut TINCS)