-----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.euwww.souris-libre.fr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEAREIAAYFAlH4qLIACgkQoLWMmH15CJse1wCfQg7z+32Yi82QMvPD3Hur/ZAp
LjAAn3cQgm+Y41mwtk/3mtWdduVUkMiQ
=1xSw
-----END PGP SIGNATURE-----
