Retour à la première page.
Très souvent, les calculs du programme ne sont que des résultats intermédaires et ne sont pas diffusés tels que. Donc il n'est à priori pas utile de peaufiner leur présentation, ils seront de toutes façons présentés dans un autre document : graphique, publication, note interne,...
Ce n'est pas une raison pour ne pas effectuer un minimum de travail de présentation. Cela facilite la compréhension des résultats, simplifie l'exploitation ultérieure, donne une impression de sérieux à vos utilisateurs.
En réalité c'est un état d'esprit similaire à l'ajout de commentaires dans le code. Cela fait perdre un peu de temps sur le moment, mais va en faire gagner plus tard.
Comme cela a été expliqué ici, la quantité d'information dans ce fichier de sortie est contrôlé par la variable debug
.
Le premier stade consiste à mettre le fichier en forme pour qu'il soit agréable à lire dans un éditeur de texte. Le programme model-ii est un exemple de ce premier stade.
C'est lisible, les différentes étapes ont séparées par des lignes de tirets. Il est normal pour un programme scientifique de manipuler des concepts difficiles, donc il ne faut pas se rebuter par l'aspect austère.
Certaines abréviations sont expliquées en fin de fichier (b0=ord. a l'origine, b1=pente
).
Il manque deux points importants:
Mais dans ce cas le nom du fichier est indiqué, ce qui est un moindre mal.
J'avais fait un effort plus important de présentation avec une entête encadrée, les titres sont soulignés les écritures sont alignées.
La date est inscrite, les données d'entrées sont reportées avec leur unité. Par contre il n'est pas fait mention ni de l'auteur (c'est moi) ni de référence à une note d'explication. Ce programme reste donc un peu mystérieux (que signifie ZLARG).
Sinon la mise en page reste rustique.
On aurait envie de pouvoir utiliser les enrichissements classiques : gras, italique, soulignement, taille du texte... Tout en gardant la facilité de génération des fichiers textes. Le format html est un des plus simple à apprendre, de plus il est universel et des lecteurs sont présents sur tous les systèmes.
Il est relativement facile de générer directement des fichiers PostScript ou html à partir du code source. Je n'ai toutefois pas encore trouvé de "library" en C "pur" qui soit pratique à utiliser pour le faire. La library "libharu" permet de créer directement du pdf.
La solution préférable à mon avis est de formater légèrement le fichier de sortie pour qu'il reste lisible par un éditeur de texte et d'utiliser un convertisseur pour générer du html bien formaté à la demande.
Il existe plusieurs outils Q-html, txttoWeb, txt2html (en perl), "Easy Text To HTML Converter (freeware)", AsctoHtml. Celui que je préfère est txt2tags, son principal défaut est d'être écrit en Python, et donc pas intégrable nativement dans l'interface.
Il semble maintenant qu'un standard se dégage. Il s'agit de Markdown, défini par John Gruber. Cet ensemble de balises a été créée exactement avec le même esprit. Une syntaxe de formattage simple qui n'empêche pas la lecture des fichiers non traduits. Il y a une extension "Markdown Extra" qui permet de faire facilement des tableaux. Reste à trouver un code en Tcl qui fasse la traduction en html. Pour l'instant je n'en ai pas. Mais il faut avouer que je n'en cherche pas, il y a des traducteurs "en ligne" qui font cela suffisament bien pour mon besoin actuel.
J'utilise un script Tcl/Tk fourni par un collègue qui n'est malheureusement plus posté sur le net. Il reconnaît la structure du texte en analysant les niveaux d'indentation. Il faut lui préciser par des balises courtes la présence de titre, de listes et de table.
Une autre possibilité est de détourner une partie du code de Wikitcl de J.C. Wippler, il permet de transformer un texte en langage de wiki soit en html soit en donnée pour le widget text
Par rapport au paragraphe précédent, on suppose que le résultat est maintenant définitif, les bons paramètres du calcul on été trouvés. A ce stade, on ne désire plus uniquement examiner facilement le bon déroulement du calcul. Mais de mettre en forme les résultats pour les diffuser ou les stocker (parfois il est nécssaire de la faire pour des raisons légales, si le calcul est utilisé dans le dimensionnement d'une machine).
Le document s'adresse à l'utilisateur final qui n'est pas forcement intéressé par les résultats des étapes intermédiaires. Mais il a besoin d'aller rapidement aux résultats qui doivent être présentés si possible sous forme de graphique et éventuellement annotés par un expert.
Mais assez de bla-bla, faisons une belle sortie pour le programme "model-ii" évoqué dans Un exemple plus complet ». Les outils utilisés sont :
des morceaux du script tkpaint retrouver le site pour mettre un lien
Le fichier de sortie n'a pas été conçu pour être analysé par un programme. Mais il n'est pas trop difficile d'y retrouver les bonnes informations par un petit script.
Ici les résultats sont assez simples : pentes et ordonnées à l'origine. Ces quelques valeurs sont directement mises dans des variables globales.
Cette étape est assez facile à réaliser, la façon de faire est expliquée dans le wiki tcl français.
Quelques points à noter:
La procédure retourne le n° du pipe ouvert. Ce qui permet d'une part de le fermer plus tard, mais surtout de créer un fichier image (png ou gif) si le résultat nous convient.
Dans windows, le fenêtre de commande de gnuplot et ouverte, ce qui permet d'enrichir le graphe (flèche, texte, ...) avant de créer le fichier image. Dans les dernière versions il est aussi possible de copier le graphe et de le coller sans perte de qualité dans un autre document.
Le plus pratique est de mettre le numéro de pipe dans une liste et de créer des boutons : un pour fermer gnuplot et un pour enregistrer une image.
button $bbas.dessin -text [msgcat::mc {Display graph}] -width 12 \ -command {lappend pglist [dessine]} button $bbas.clogr -text [msgcat::mc {Close graph}] -width 8 \ -command {close [lindex $pglist 0]; set pglist [lreplace $pglist 0 0]} button $bbas.mkgifr -text [msgcat::mc {Save gif file}] -width 8 \ -command {savegif [lindex $pglist end] $nomfichgif}
Voici la procédure pour créer un fichier gif
#==========================================# # save a gif file # #==========================================# # fichgif : name of file to create proc savegif fichgif { puts $gplot "set output \'$fichgif\'" puts $gplot {set term push} puts $gplot {set term gif} puts $gplot {replot} flush $gplot puts $gplot {set term pop} puts $gplot {set output} }
On peut remplacer gif par beaucoup de format d'image dont un TK qui crée un procédure pour le canvas.
J'ai déjà essayé plusieurs techniques pour produire facilement des résumés contenant des graphiques. Toutes fonctionnent, mais elles sont plus ou moins facile à utiliser :
Ici je vous présente la méthode la plus simple qui est également la plus rapide, mais aussi la moins souple. Le fichier obtenu est un document html qui sera affichable par tout navigateur. Ce fichier est obtenu à partir d'un maquette (template) dont certains éléments sont à remplacer en fonction des résultats du calcul ou par des graphiques issus de gnuplot qui doivent avoir été générés et enregistrés comme précédemment.
La maquette est en fait un fichier HTML normal, dans lequel certaines parties sont "à remplacer". Pour les repérer, elle commencent par le signe "&". Dans ce fichier exemple. il faut remplacer :
Et donne ce résultat.
Si on combine cela avec l'utilisation de Javascript, il est possible de réaliser des sorties élaborées assez facilement. Le stade ultérieur est de réaliser du HTML dynamique, mais ici on s'éloigne de l'écriture de programmes scientifiques.
Retour à la première page. Dernière révision le 22/Dec/2014