-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Bonjour, j'ai une question et peut-être une proposition et une demi à faire... (et un peu peur de l'annonce, moins de mes fautes dans mon français d'Outre-Rhin). Pardonnez aussi que mon message est parfois un peu technique. Mais c'est bien la liste «lima-users» à qui je veux l'adresser. Vu que le formatage des rapports n'est pas super et même défectueux en ce qui concerne au moins le «Grand Livre», j'ai élaboré ce dernier document à la main et peux constater que les manipulations nécessaire afin de rendre le code conforme au XHTML-1.0-stricte ne sont pas nombreuses. Ceci dit, la conversion d'un tel rapport en PDF au dehors du logiciel, c'est à dire après sa génération, ne pose aucun problème, une foi le code corrigé. La question ... Oops. Il y en a deux : 1. Est-ce que les utilisateurs qui, comme moi, déplore le fait qu'on ne puisse pas faire grande chose avec les rapports actuels, sont nombreux ? 2. Est-ce que la prochaine version «officielle» de lima va apporter des améliorations dans le formatage des rapports ? Proposition: Vu que, personnellement, j'ai besoin d'un Grand Livre plus agréable à lire, l'automatisation des nécessaires manipulations du code HTML est mon tout nouveau projet privé. N'ayant pas trouvé l'endroit dans le code Java qui est responsable pour le formatage du document, et parce que je n'aime plus installer un sacré environnement de développement pour la ridicule tache de corriger de HTML, je préfère un script Ruby, que je veux développer ces jours là. Le script va : - - corriger la structure du code HTML, là ou elle est défectueuse, - - transformer le code en XHTML 1.0 stricte et le valider moyennant d'un appel externe à HTML-Tidy, - - inclure un style-sheet CSS, que je vais initialement fournir mais qui permet l'ajustage rapide et simplifiée du format. Le document produit de ce manière est vite transformé en PDF ou d'autres formats avec XSL/FO. De plus, ce petit travail va me permettre d'évaluer l'énergie à investir dans les autres rapports. Demi proposition : *Si* mon script produit des résultats acceptables et *si* d'autres personnes expliquent leur intérêt dans la procédure, on peut discuter s'il vaut le cout d'être reprogrammé en C++ pour éviter l'obligation d'installer un interpréteur Ruby pour son exécution. Bien-sûr, tout va tout de suite dans la poubelle l'instant que Code Lutin déclarent leur intention de s'en charger. ;-) J'ai réfléchis mais suis assez décidé et vais rester ferme : Des années avec Java m'ont à la fin ennuyé tellement, que je suis en effet content d'avoir perdu des connaissances du développement en Java. Je *ne veux pas* fournir des solutions ou suggestions en code pour l'amélioration du logiciel. Cheerio, Michael www.uplawski.eu www.souris-libre.fr -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEAREIAAYFAlH4qLIACgkQoLWMmH15CJse1wCfQg7z+32Yi82QMvPD3Hur/ZAp LjAAn3cQgm+Y41mwtk/3mtWdduVUkMiQ =1xSw -----END PGP SIGNATURE-----