Forum TI-Planet.org

Adriweb a écrit:

critor a écrit:Le formulaire actuel les néglige déjà.
L'ajout du 2ème lecteur a été fait/justifié pour de mauvaises raisons.

Je vois pas en quoi ils seraient négligés - ils l'étaient avant que je rajoute le 2ème viewer, oui.

Ils sont toujours négligés.
Le formulaire n'est pas en largeur fixe.
Donc la gestion du 2ème lecteur ne sert strictement à rien, à part à gâcher de la place.

Adriweb a écrit:La raison évoquée reste correcte, elle touche probablement juste une minorité.

Alors tu n'as rien voulu lire/comprendre, visiblement.
Les raisons pour lesquelles tu as annoncé l'intégration de ce 2ème lecteur sont mauvaises.
Et induisent donc les utilisateurs en erreur.
Je vois des milliers d'élèves rentrer et utiliser leurs notes depuis des années, je pense connaître leurs besoin et usages mieux que d'autres, même si visiblement on méprise mon expérience ici.

Pesonne n'a besoin de la grosse police énorme pour un service dont la mise en place cible / incite à la conversion de textes.
C'est un retour en arrière.

Sauf bien sûr :
- le développeur du lecteur en question (et c'est normal)
- ceux qui concevraient manuellement leurs textes en faisant attention à la fin de ligne, et/ou à l'alignement vertical (soyons réalistes - c'est pas 0.1% peut-êre 0.01% et encore...)

Et un lecteur universel n'est pas inenvisageabe.
Je te rappelle que la commande TI-Basic Texte() peut aussi bien afficher en petite qu'en grande police.

critor a écrit:Le formulaire n'est pas en largeur fixe.
Donc la gestion du 2ème lecteur ne sert strictement à rien, à part à gâcher de la place.

Encore faut-il attendre que je sois chez moi pour que j'ajoute ladite ligne du monospace Et d'ailleurs, j'en ai profité pour améliorer le centrage etc. en général.
Actuellement, c'est la bonne représentation : nombre de colonnes adéquat + monospace :

Ce qui fait donc :

critor a écrit:Pesonne n'a besoin de la grosse police énorme pour un service dont la mise en place cible / incite à la conversion de textes.
C'est un retour en arrière.

Apparemment, tu ne tiens donc pas compte de la minorité qui veut des gros caractères et/ou monospace. Et pour l'instant, le 2ème lecteur est le seul à proposer ceci. Je rebondis donc sur la quote suivante :

critor a écrit:Et un lecteur universel n'est pas inenvisageabe.
Je te rappelle que la commande TI-Basic Texte() peut aussi bien afficher en petite qu'en grande police.

Mais, donc, c'est très bien, et il faudrait peut-être "juste" adapter zText pour pouvoir avoir ce réglage la, si la minorité concernée le choisit. Ca ressemblerait peut-être au lecteur d'Anonyme0 mais via l'écran graphique, en fin de compte, je sais pas.

En tout cas, j'attends que l'on m'envoit des mises à jour, y'a aucun problème pour moi à ce niveau là.

Adriweb a écrit:Apparemment, tu ne tiens donc pas compte de la minorité qui veut des gros caractères et/ou monospace. Et pour l'instant, le 2ème lecteur est le seul à proposer ceci.

Je tiens compte du contexte : c'est annoncé+présenté comme un convertisseur de textes.

Et les problèmes de lisibilité dont tu parlais, dans ce contexte on les a paradoxalement avec la grande police.
A avoir des coupures plus fréquentes au milieu des mots, et la meme phrase qui se poursuit sur 4-5 (courtes) lignes.

Voici une comparaison des deux lecteurs avec le même texte (String Viewer en haut et ZText en bas) :

Il est à noter deux atouts importants de String Viewer : les textes générés sont beaucoup moins lourds que ceux de ZText, et on peut se balader de page en page comme on veut, c'est à dire qu'on peut retourner aussi à la page précédente.

Du point de vue lisibilité, il m'est plus agréable de lire sur String Viewer que sur ZText, je pense que c'est surtout à cause des espaces tout petits de ZText.

critor a écrit:Et les problèmes de lisibilité dont tu parlais, dans ce contexte on les a paradoxalement avec la grande police.
A avoir des coupures plus fréquentes au milieu des mots, et la meme phrase qui se poursuit sur 4-5 (courtes) lignes.

Avec ZText la même phrase se poursuit sur plusieurs lignes aussi, et on a les mêmes coupure de mots !

Bon, désolé de réagir que maintenant mais j'étais pris dans autre chose.

Critor, les bugs mentionnés sont-ils désormais corrigés? Je n'ai pas touché au code depuis quelques jours, il fonctionnait parfaitement.

L'ajout du texte en grosses lettres peut être une option envisageable, oui..

Adriweb: Merci pour l'ajout du String Viewer

Anonyme0 a écrit:

critor a écrit:Et les problèmes de lisibilité dont tu parlais, dans ce contexte on les a paradoxalement avec la grande police.
A avoir des coupures plus fréquentes au milieu des mots, et la meme phrase qui se poursuit sur 4-5 (courtes) lignes.

Avec ZText la même phrase se poursuit sur plusieurs lignes aussi, et on a les mêmes coupure de mots !

Bien sûr, mais ça prendra moins de lignes.

Quant à la lisibilité de zText, une autre couleur que le bleu serait peut-être préférable.

critor a écrit:

Anonyme0 a écrit:

critor a écrit:Et les problèmes de lisibilité dont tu parlais, dans ce contexte on les a paradoxalement avec la grande police.
A avoir des coupures plus fréquentes au milieu des mots, et la meme phrase qui se poursuit sur 4-5 (courtes) lignes.

Avec ZText la même phrase se poursuit sur plusieurs lignes aussi, et on a les mêmes coupure de mots !

Bien sûr, mais ça prendra moins de lignes.

Quant à la lisibilité de zText, une autre couleur que le bleu serait peut-être préférable.

Noir? Marron?

Je dirais noir.

Mise à jour, ajout du texte en noir sur les versions couleurs (merci critor) et correction du nombre de caractère par ligne sur les modèle monochromes.

Commit: https://github.com/TI-Planet/zText/comm ... 60705d0522


(Du coup faudrait changer la couleur du text sur les previews)

Bien plus agréable à lire le bloc de texte en noir qu'avec le bleu, je trouve