Date: prev next · Thread: first prev next last
2016 Archives by date, by thread · List index


Bonjour

Sous Libo 5 Calc, j'observe une différence de comportement qui semble
montrer un dysfonctionnement du logiciel sur un OS Ubuntu 12.04 32 bits.

Le tableau de données suivant est généré dans un terminal par un petit
programme en langage Python. Il contient deux colonnes séparées par un
"espace". Dans la première colonne, une suite de nombres entre 0 et 9; dans
la deuxième colonne, des nombres avec des décimales (séparateur = point).

0 1000.0
1 995.095
2 980.38
3 955.855
4 921.52
5 877.375
6 823.42
7 759.655
8 686.0799999999999
9 602.6949999999999

L'idée est de coller ces informations dans une feuille de calculs puis de
remplacer les points par des virgules et, finalement, de tracer un
diagramme xy sous Calc.

Toute l'opération se déroule sans aucun souci sous Ubuntu 14.04 LTS 64 bits
et LibO 5.0.4.2
Je "copie/colle" ce tableau de deux colonnes dans une feuille de calculs,
une prévisualisation me demande d'indiquer que le séparateur est bien le
caractère "espace" et l'aperçu, au bas de la boîte de dialogue d'import de
texte indique que tout est parfait.
Les données apparaissent comme promis dans la feuille de calculs, y compris
le "." décimal. "Rechercher et remplacer" permet de le transformer en ","
(virgule) et le diagramme est tracé aussi sec. La vie est belle.

Par contre, sur une machine en Ubuntu 12.04 LTS 32 bits...
Lorsque je "copie/colle" ce tableau de deux colonnes dans une feuille de
calculs, tout se passe comme ci-dessus. Mais, lorsque je clique sur OK
après la prévisualisation -qui est correcte- j'obtiens, dans la feuille de
calculs, les données suivantes:

0 1000.0
1      995095
2 980.38
3      955855
4 921.52
5      877375
6 823.42
7      759655
8 686.0799999999999
9 602.6949999999999

où l'on voit que certaines des données de la deuxième colonne ont perdu le
"." décimal.

Le résultat final est le même si je copie ces informations dans un éditeur
de texte puis que je termine la manœuvre après avoir re-copié les données
depuis l'éditeur de texte. Le terminal est donc hors-cause.

Par contre, il est possible de lever le problème en diminuant le nombre de
décimales des nombres de la deuxième colonne. Tout se passe bien si l'on
réduit à 2 décimales maxi.

Testé sur plusieurs PC sous LibO 5.0.4.2 Build
1:5.0.4~RC2-0ubuntu1~precise2 (dysfonctionnement)
et plusieurs PC sous LibO 5.0.4.2 5.0.4.2 Build ID:
1:5.0.4~rc2-0ubuntu1~trusty1 (fonctionnement normal)

Pour information, la manœuvre que je décris (et qui se passe bien) est
visible là https://www.youtube.com/watch?v=CvJk8oSdFXQ à partir du temps 9
minutes.

Ferais-je une fausse manœuvre quelque part? S'agit-il d'un souci de
configuration? Si c'est bien le cas, c'est plutôt ennuyeux qu'il n'y ait
pas un avertissement au moment de la prévisualisation. Des informations
financières en milliers d'euro avec trois décimales deviendraient
instantanément des millions. Je tenterais bien le coup avec mon salaire ;o)

Merci pour toute réaction.

-- 
Yves Mairesse
---
Il y a 10 sortes de personnes dans le monde: celles qui savent compter en
binaire et les autres

-- 
Envoyez un mail à users+unsubscribe@fr.libreoffice.org pour savoir comment vous désinscrire
Les archives de la liste sont disponibles à http://listarchives.libreoffice.org/fr/users/
Tous les messages envoyés sur cette liste seront archivés publiquement et ne pourront pas être 
supprimés

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.