Exporter synthèse en txt/csv

[olivir]

Bonjour,

Merci pour cette nouvelle fonctionnalité (je me sens un peu responsable ) qui permet de récupérer des données brutes, avec un gain de poids conséquent également.

Je rencontre un petit souci tout de même : mon OS étant en version "fr", mon tableur s'attend à un "," plutôt qu'un "." comme séparateur décimal et par conséquent je ne peux échapper à un "Remplacer par" avant de pouvoir faire quelque calcul.

Malheureusement, c'est le problème du csv qui n'a pas de norme internationale

Ce n'est pas bien grave mais si vous pouvez y jeter un oeil...

ps : tant que j'y pense, les tableurs gère le HTML maintenant, c'est aussi une piste de format "universel", très lisible pour un humain qui plus est, mais ça ne résout pas le problème du séparateur

[Jean-Louis]

Bonjour,
dans tous les affichages on retrouve le point comme séparateur décimal, ce qui est une convention dans Pleiades.

Le problème de CSV me semble insoluble, la virgule étant à la fois le séparateur décimal et le séparateur de champ. Les fichiers avec séparateur tabulation seront les plus adaptés ; mais on ne peut pas échapper à l'opération de remplacement des points par des virgules.

Dans les exports au format Excel, le séparateur décimal est bien celui de la langue utilisée pour Windows (hormis pour les pourcentages, ce qui sera corrigé dans la prochaine version) ; il est vrai que ces fichiers sont beaucoup plus volumineux (ils peuvent cependant être compressés avec un bon ratio) mais ce sont les plus pratiques à utiliser, des copier/coller peuvent facilement être faits entre pages et fichiers différents et lisibles par tous les tableurs du marché.

Concernant les exports au format html, il ne sont pas prévus, mais les choses peuvent évoluer car effectivement, ils sont facilement lisibles et peuvent être importés dans la plupart des suites de bureautique.

[olivir]

Bonjour,

Dans les exports au format Excel, le séparateur décimal est bien celui de la langue utilisée pour Windows (hormis pour les pourcentages, ce qui sera corrigé dans la prochaine version) ; il est vrai que ces fichiers sont beaucoup plus volumineux (ils peuvent cependant être compressés avec un bon ratio) mais ce sont les plus pratiques à utiliser, des copier/coller peuvent facilement être faits entre pages et fichiers différents et lisibles par tous les tableurs du marché.

Oui, effectivement, dans ce cas les formats bruts sont assez peu utiles.

La taille des fichiers Excel vient surtout du format, assez ancien, utilisé.

Concernant les exports au format html, il ne sont pas prévus, mais les choses peuvent évoluer car effectivement, ils sont facilement lisibles et peuvent être importés dans la plupart des suites de bureautique.

C'est peut être le format le plus "universel"...

[Jean-Louis]

Bonjour, pour reprendre la liste des formats d'export disponibles maintenant dans Pleiades et leurs caractéristiques je vais faire une petite synthèse :

• Fichier texte séparateur virgule (CSV) : fichier brut pour lequel chaque chaque ligne représente un élément et chaque valeur de l'élément est séparée de la suivante par une virgule. Inconvénient : une valeur ne peut pas contenir de virgule (c'est pourquoi le séparateur de décimale est un point).
• Fichier texte séparateur tabulation : fichier brut pour lequel chaque chaque ligne représente un élément et chaque valeur de l'élément est séparée de la suivante par une tabulation. Inconvénient : une valeur ne peut pas contenir de tabulation, c'est assez rare heureusement (ici, le séparateur de décimale est encore un point).

Lors de l'import des fichiers bruts dans un tableur, on est la plupart du temps obligé de préciser le séparateur de décimale comme le point et non la virgule.

• Fichier Excel (BIFF 5) : c'est un format Excel plutôt ancien avec des possibilités de formatage assez limitées. Cependant, les valeurs numériques sont acceptées comme telles et peuvent être exploitées au travers de formules. Inconvénient : la version 2010 d'Office n'arrive plus à les lire, la compatibilité ayant été interrompue avec cette version, le format SYLK.
• Fichier SYLK : SYLK est l'acronyme de SYmbolic LinK, c'est un format de tableur développé par Microsoft et dont le rôle est équivalent à celui du RTF pour les fichiers textes et il est accepté par la plupart des tableurs du marché . Les possibilités de formatage sont plus grandes qu'avec le BIFF5.
• Fichier HTML : c'est le format des pages que l'on consulte avec son navigateur internet ; les possibilités de mise en page sont très grandes mais on été limitées pour faciliter l'import dans les tableurs. Ce format d'export est consultable sur tout ordinateur avec un navigateur internet (c'est l'intérêt) sans avoir besoin de tableur pour la visualisation. La plupart des tableurs actuels sont toutefois capables d'importer ce format de fichier.

[olivir]

Merci beaucoup pour ces précisions et ces nouvelles implémentations (surtout pour le sylk quasiment pas documenté).

Cependant, en ce qui concerne le format HTML, j'ai quelques remarques :
- le code gagnerait en légèreté (-65% sur un projet à 5 zones) et facilité de rendu en supprimant tous les styles qui sont affectés, un à un (?!), à chaque balise,
- vous pouvez embarquer une feuille de style plutôt (séparation fond/forme),
- trois tableaux plutôt qu'un seul serait plus logique,
- il existe une balise pour les titres de tableaux <th>, capable de s'étendre sur plusieurs colonnes.

Je vous joins une version de code nettoyée avec une mise en forme qui tient sur 15 lignes et n'alourdit pas le fichier. Elle reprend ce que je viens de vous indiquer mais je me suis permis de "raccourcir" le 3ème tableau. Pour un cas réel, on divise en gros par trois la taille du fichier... et le temps de chargement est réduit d'autant.

export_HTML.zip

Export HTML performante et valide W3C

(3.04 Kio) Téléchargé 534 fois

ps : j'en ai profité pour écrire kWh/m³ au lieu de kWh/m3

[Jean-Louis]

Vos remarques sont très pertinentes, une optimisation des sorties fichiers des résultats permettrait effectivement d'alléger les fichiers, mais l'objectif était de fournir des formats de fichiers plus variés et "portables" afin d'augmenter les possibilités de traitement par les utilisateurs.

Dans l'avenir, la procédure d'export HTML sera retravaillée pour y inclure certaines des idées que vous avez indiquées mais nous sommes pour l'instant limités par les caractéristiques des autres formats.

[olivir]

Les modifications que je vous suggère ne modifie pas la portabilité du HTML, cela le rend juste valide (respect des standards) et plus performant (moins gourmand en ressources, quelles qu'elles soient).

Laquelle de mes remarques ne vous semble pas implémentable et pour quelle raison ?

[Jean-Louis]

Quand je parlais de portabilité, je faisais référence aux autres formats d'export qui sont disponibles, en terme de programmation aucune adaptation particulière n'est pour l'instant prévue, pour les points d'amélioration, je reprend la liste :

- le code gagnerait en légèreté (-65% sur un projet à 5 zones) et facilité de rendu en supprimant tous les styles qui sont affectés, un à un (?!), à chaque balise,
- vous pouvez embarquer une feuille de style plutôt (séparation fond/forme),

Intégrer une feuille de style et affecter le style à chaque case pour réduire le volume est une bonne idée, je pense l'intégrer assez rapidement.

- trois tableaux plutôt qu'un seul serait plus logique,

C'est une grille complète (comme une feuille excel en somme) qui est exportée, elle ne peut pas, pour l'instant être partagée en plusieurs parties.

- il existe une balise pour les titres de tableaux <th>, capable de s'étendre sur plusieurs colonnes.

Aucune notion de titre n'est présente dans la grille d'export, l'utilisation des <th> n'est pas possible, une cellule contient une valeur d'un certain type, et certaines informations de format assez basiques (que l'on retrouve dans le BIFF5) ; un style pourrait cependant remplacer cette balise.
Pour utiliser le colspan ou rowspan, il faudrait parcourir toutes les cases de la grille et en fonction des bordures de chaque case, de la présence ou non de valeur agrandir ou pas la case, ce n'est pas encore faisable.

Ajouter les tags nécessaires pour le respect du standard W3C semble nécessaire et sera fait.

[olivir]

Intégrer une feuille de style et affecter le style à chaque case pour réduire le volume est une bonne idée, je pense l'intégrer assez rapidement.

Ok merci bien

1- C'est une grille complète (comme une feuille excel en somme) qui est exportée, elle ne peut pas, pour l'instant être partagée en plusieurs parties.
2- Aucune notion de titre n'est présente dans la grille d'export, l'utilisation des <th> n'est pas possible, une cellule contient une valeur d'un certain type, et certaines informations de format assez basiques (que l'on retrouve dans le BIFF5) ; un style pourrait cependant remplacer cette balise.
3- Pour utiliser le colspan ou rowspan, il faudrait parcourir toutes les cases de la grille et en fonction des bordures de chaque case, de la présence ou non de valeur agrandir ou pas la case, ce n'est pas encore faisable.

Pourquoi ne pas faire un post-traitement de votre HTML après export, si ce dernier ne peut gérer tout cela ?!

Si vous préférez, je suis prêt à réaliser une telle application de post-traitement et la mettre ensuite à la disposition de tous.

[Jean-Louis]

Il vaut peut être mieux attendre la prochaine version et voir ce qu'on peut en faire