Compatibilité Ooo/Libo Mac / Linux

fr-users
#1

Bonjour
Un collègue consciencieux veut faire un effort particulier pour suivre
les consignes données lors de formations que j'ai données pour
l'utilisation de Writer, sous Ooo puis sous LibO actuellement.
Il m'interpelle très régulièrement sur les difficultés qu'il rencontre
avec des textes dont la présentation et/ou la lisibilité posent
problème en fonction de l'ordinateur qu'il utilise.
À son domicile, un Mac sous Snow Leopard et LibreOffice.
Au boulot, des PC sous Linux Ubuntu 10.04 LTS avec LibO depuis le ppa.
Il m'envoie un fichier qui me semble presque parfait avec les
commentaires suivants:

[quote]
Je suis à nouveau occupé à m'arracher les cheveux pour des problèmes
de compatibilité entre libre office open office et les autres.
Le problème survient visiblement quand le texte est structuré avec
table de matières et gestion des titres et sous titres comme expliqué
au cours.
Quand le document a été modifié sur certaines machines de l'école,
quand je veux les ouvrir chez moi, il ne reste que la structure mais
plus rien n'est apparent.
Je n'ai pas le problème avec les rapport ***** qui eux ne sont pas
structurés comme il faudrait, j'y utilise seulement les puces et
numérotation.
[/quote]

Il ne me semble jamais avoir lu quoi que ce soit sur des problèmes de
ce type alors qu'il m'indique que de nombreux forums [références
nécessaires] pullulent de posts incendiaires sur LibO et son
traitement des .odt
Je me suis permis de mettre le fichier qui pose problème à disposition
sur un hébergement personnel, sans y apporter la moindre modification.
http://sapajou.be/test/
Merci de m'indiquer où j'aurais dû l'héberger...

Personnellement, je lis ce fichier rédigé sous LibO sans souci sur
plusieurs ordinateurs (tous sous Ubuntu 10.04)
Quelqu'un peut-il confirmer l'observation sous Snow Leopard?
Que dois-je conseiller à ce collègue qui m'indique par ailleurs

[quote]
Bref je suis vraiment désespéré, j'ai beau faire du mon mieux pour
utiliser ce qui est mis à notre disposition, c'est pire à chaque fois.
Je suis de moins en moins convaincu par la stratégie open source et
pourtant j'essaye vraiment.
Il s'agit certainement d'une bêtise, mais nous ne sommes absolument
plus autonomes face aux machines, on perd des heures pour rien et tu
es bien seul pour pouvoir nous aider.
[/quote]

Jusque là, je n'ai pu que lui conseiller de tenter de virer son profil
LibreOffice. Mais sous Ooo, ses problèmes étaient déjà récurrents.
J'attends d'apprendre si ce petit conseil aura pu l'aider.

Merci pour votre aide.

#2

Bonjour,

Cela ne va pas aider beaucoup, mais je dirai que d'après ma propre
expérience, votre collègue n'a pas complètement tort, surtout entre Mac et
PC (Linux/Windows), où la gestion des polices et l'affichage est différent,
ce qui provoque des affichages parfois étranges lorsqu'on regarde le même
document sur les différents OS.

Encore pire, c'est le fait que sur Mac, entre OOo/LibO/NeoOffice, on n'a
pas forcément le même affichage d'un seul document. Cela s'est avéré à
plusieurs reprises chez moi avec un document comportant des puces, que ce
soit avec le style par défaut, ou avec d'autres styles proposés au sein
même du logiciel. C'est assez pénible en effet.

Du côté de ApacheOOo, certaines personnes pensent que c'est le format ODF
qui est important, peu importe la manière dont le fichier est affiché. Dans
l'absolu, c'est vrai, mais quel bordel alors au niveau de
l'interopérabilité affichée, car mine de rien, un document mal affiché à
l'écran a bel et bien une influence sur la manière dont on travaille avec
ce même document, obligeant l'utilisateur à faire des pieds et des mains
pour obtenir à nouveau quelque chose avec laquelle il est satisfait, et en
passant, perdant pas mal de temps, alors que l'objectif d'un format
bureautique ouvert à mon sens c'est aussi de permettre à l'utilisateur de
gagner du temps. Dans les faits, actuellement, ce n'est pas le cas, mais
les raisons en sont multiples : origine du document (conversion de fichier
Office, version d'ODF utilisée et interpretée, et systèmes de gestion des
polices et du kerning de chaque OS). Il n'y a pas de solution simple.

Alex

#3

Bonjour,

J'ai pu lire sans inconvénient le document "Table de réunion" (9 pages).

Configuration : LinuxMint 12, LibreOffice 3.4.4

#4

Bonjour,
J'ai aussi pu lire, sans aucune difficulté, le document "Table de réunion" (9 pages).Avec sa table des matières placée en tête de doc. Et ceci sur mac book pro et léopard avec LBO 3.4.5 (qui me donne toute satisfaction jusqu'à présente, touchons du bois). Je n'ai pas osé passer à la 3.5 vue l'animation du forum à son sujet!!

Roche

#5

Bonjour
Merci pour ces réactions.
Un autre collègue sous Snow Leopard 10.6 (ai-je bien retenu le numéro
de version?) n'a pas de problème non plus. Il n'a d'ailleurs, dit-il,
jamais rencontré le moindre problème depuis qu'il utilise Ooo. (je ne
désespère pas de le convertir à LibO)
Mais l'auteur malheureux du document est, quant à lui, sous une
version inférieure de l'OS (10.4?). Ceci justifierait-il cela?

Suite aux indications données par Alexander Thurgood, il est confirmé
que les documents qui posent problème sont bien ceux qui sont issus
d'une conversion depuis un .doc
Si des archives sont disponibles, une re-conversion en .odt avec une
version récente de LibO peut-elle améliorer les choses? Les
algorithmes de conversion ont-ils été améliorés?
L'alternative étant de retourner à un texte plat à reformater
entièrement. Mais c'est lourd quand on a quelques années de documents
de travail sous le coude.

#6

Bonsoir,

Effectivement, si on sauve le document en .doc, à la réouverture il s'affiche avec 2 pages par écran dans l'ordre : 1,2 puis 3,4, etc... et non plus par pages successives.
Pour le reste, pas de perturbation.
En se rendant au Format page, il est, d'origine, prévu un affichage droite-gauche. Ceci explique peut-être cela !

Configuration : LinuxMint 12, LibreOffice 3.4.4

#7

Bonsoir,

Mac OS 10.6.8
LibreOffice 3.4.5
OOO340m1 (Build:502)
LibreOffice 3.5.0rc3
Version ID : 7e68ba2-a744ebf-1f241b7-c506db1-7d53735
aucun problème pour lire le document, tout y est dans le bon ordre.

À vous lire, je me demande si finalement, les problèmes récurrents de présentation des documents structurés ne trouvent pas le plus souvent, sinon tous, leur origine dans le format originel du fichier, en l'occurrence l'un des nombreux et facétieux avatars de MSWord.
Autrement dit, nous nous trouvons devoir régler des ennuis en cascade pour détordre des documents souvent congénitalement tordus.
Autant dire un tonneau des Danaïdes numérique !

<Discussion>
Il en a déjà été question sur les listes Ooo et Libo. La méthode la plus rentable, à défaut d'être économique dans l'absolu, ne serait-elle pas de repartir du contenu brut et de refaire la mise en forme native sous LibO, de la manière la plus correcte dès le départ ?
La cinématique "idéale" que j'imagine serait
- récupération du contenu brut (texte, images)
- réinjection dans une maquette vide définie par l'utilisateur ou disponible dans LibO
- application des styles existants dans la maquette cible
Pour rajeunir un stock de documents, des outils d'aide à cette conversion de masse seraient une réelle novation, à moins que cela n'existe déjà.
</Discussion>

Sont-ce de vaines élucubrations ?
Vos avis sauront me remettre dans le bon chemin, je n'en doute pas.

C_Lucien

#8

-----Message d'origine-----
De : lutch [mailto:lutch@free.fr]
Envoyé : mardi 6 mars 2012 20:09
À : users@fr.libreoffice.org
Objet : Re: [fr-users] Compatibilité Ooo/Libo Mac / Linux

Bonsoir,

[..]

Bonsoir,

Mac OS 10.6.8
LibreOffice 3.4.5
OOO340m1 (Build:502)
LibreOffice 3.5.0rc3
Version ID : 7e68ba2-a744ebf-1f241b7-c506db1-7d53735
aucun problème pour lire le document, tout y est dans
le bon ordre.

À vous lire, je me demande si finalement, les
problèmes récurrents de
présentation des documents structurés ne trouvent pas
le plus souvent,
sinon tous, leur origine dans le format originel du
fichier, en
l'occurrence l'un des nombreux et facétieux avatars de MSWord.
Autrement dit, nous nous trouvons devoir régler des
ennuis en cascade
pour détordre des documents souvent congénitalement tordus.
Autant dire un tonneau des Danaïdes numérique !

<Discussion>
Il en a déjà été question sur les listes Ooo et Libo.
La méthode la plus
rentable, à défaut d'être économique dans l'absolu, ne
serait-elle pas
de repartir du contenu brut et de refaire la mise en
forme native sous
LibO, de la manière la plus correcte dès le départ ?
La cinématique "idéale" que j'imagine serait
- récupération du contenu brut (texte, images)
- réinjection dans une maquette vide définie par
l'utilisateur ou
disponible dans LibO
- application des styles existants dans la maquette cible
Pour rajeunir un stock de documents, des outils d'aide à cette
conversion de masse seraient une réelle novation, à
moins que cela
n'existe déjà.
</Discussion>

Sont-ce de vaines élucubrations ?
Vos avis sauront me remettre dans le bon chemin, je
n'en doute pas.

C_Lucien

Bonsoir,

Je ne pense pas que la bonne solution soit de tout remettre à
plat et de réappliquer les styles.

Au contraire, cet échange n'est-il pas encore une occasion de
montrer que la seule couche de compatibilité qui intéresse les
utilisateurs est celle des styles prédéfinis, dont la plupart
sont communs à tous les logiciels de rédaction à l'écran ?

Dans le document en question, les styles prédéfinis sont
correctement appliqués. Il n'y a qu'un style personnalisé et il
n'est pas employé (Corps de texte 2). Donc parfait de ce point de
vue.

Il y a quelques paragraphes vides inutiles et perturbateurs de la
mise en page lors d'application d'un autre modèle. Par ailleurs,
il ne faudrait jamais placer un saut de page manuel quand la page
est pleine, comme devant 3.2. La coupure devrait être correcte
automatiquement. La difficulté doit provenir du fait que les
veuves et orphelines ne sont pas activées dans le style "Corps de
texte" et la création du saut de page a ajouté un paragraphe vide
perturbateur.

Quand les règles du traitement de texte sont respectées, pour
résoudre les difficultés éventuelles, il suffit d'enlever toutes
les surcharges et, éventuellement, d'appliquer un modèle
approprié à la machine. J'ai appliqué plusieurs modèles sur le
document sans difficulté. J'ai une différence dans la gestion des
fins de ligne, dont il faut modifier le paramétrage de la
justification après application d'un autre modèle. Dommage que le
format des titres soit à appliquer en plus des styles...

Il faut aussi avoir à l'esprit que seuls des documents
modifiables doivent être transmis au format odf, les autres sont
à diffuser sous un format de publication, notamment, pdf, qui, en
embarquant les polices, évite bien des ennuis.

Ce document est suffisamment bien construit pour pouvoir voyager
sans trop de difficultés. Quelques petits détails restent à
soigner pour qu'il s'adapte facilement à des contextes variés.
C'est un très bon exercice...

Cordialement.

Jean-Yves ROYER

Libre en fête 2012 du 16 au 31 mars
Fête de l'Internet 2012 du 17 au 30 mars
Des dizaines de manifestations
en région lyonnaise.
http://libre-en-fete.net
http://www.netpublic.fr/2012/01/fete-de-linternet-2012/
Le 28 mars : Document Freedom Day (DFD)
Global day for document liberation
http://documentfreedom.org/2012/

#9

Encore un grand merci aux différents intervenants pour les éclairages
très intéressants qu'ils apportent. Y compris Jean-Yves ROYER pour son
exercice de style qui me permettra de confirmer à mon collègue que sa
démarche est de bon aloi.

Il semble donc bien que l'on puisse disculper complètement les
logiciels OpenSource et remettre le focus sur un souci plus en amont,
qu'il soit à trouver dans Word ou même peut-être dans l'OS même.
J'en viendrai donc à conseiller à mon collègue de réaliser la mise à
jour de son OS bien rapidement. À moins que l'opération soit très
onéreuse? Ou que ma conclusion soit un peu hâtive?

#10

Bonjour,

Je n'ai pas eu le temps de regarder le document, mais il ne faut pas
oublier qu'il existe un endroit dans le logiciel qui peut, peut-être,
expliquer des différences entre les affichages produits par deux
installations différentes :

Menu Outils > Options > LibreOffice Writer > Compatibilité

Je ne suis pas absolument sûr que ces options soient toutes enregistrées
dans le document et donc transmises avec lui.

Bonne journée
JBF

#11

bonjour

Archlinux xfce
LibreOffice 3.4.5
OOO340m1 (Build:502)

Le document s'ouvre et s'affiche correctement.

Néanmoins j'ai un problème avec le fait qu'il commence par un tableau.
Libo a-t-il un problème avec les documents commencent par un tableau ?

Si je fais un ctrl-a pour sélectionner tout le document, je ne
sélectionne que le contenu du tableau contenant le titre.
Maintenant si je supprime le tableau et je mets le titre avec une
bordure de paragraphe, visuellement c'est identique, ou si j’insère une
ligne vide avant le tableau, je peux maintenant sélectionner tout le
document.

version courte : quand le document commence par un tableau
"Éditer>Sélectionner tout" ne fonctionne pas.

bonne journée.

#12

Bonjour

zlurps wrote

version courte : quand le document commence par un tableau
"Éditer>Sélectionner tout" ne fonctionne pas.

Version courte : c'est un très vieux bug, repris ici :
https://bugs.freedesktop.org/show_bug.cgi?id=37606

Cordialement
Pierre-Yves