L'éditeur HTML LOweb tué par les bugs =8{{{

Bonjour,

Après l'excellent StarOffice, j'ai utilisé pendant de nombreuses années
OpenOffice qui, à part la disparition regrettable de l'instrument de
peinture, fonctionnait très bien sous Window$ XP puis sous Ubuntu Jaunty et
Karmic. Travaillant désormais sur un netbook incompatible avec Karmic, j'ai
dû installer Precise, vite échangé contre Mint Maya Mate.

J'ai été très déçu par LibreOffice 3 qui remplace OpenOffice.

En effet, utilisateur intensif de l'éditeur html, j'ai constaté des bugs
nombreux, patents et parfois destructeurs qui rendent LOweb inutilisable:

- LOweb utilise les ascenseurs par défaut de l'OS sur lequel il tourne. Or,
les ascenseurs des distributions récentes de Linux sont incompatibles, ce
qui en rend l'utilisation complètement impossible avec un touchpad (sous
Mint Maya les ascenseurs de LOweb rament, se bloquent ou au contraire font
défiler tout le texte sans pouvoir être arrêtés, et sous Precise ils ne
fonctionnent pas). Il serait pourtant facile de faire en sorte que LO
utilise ses propres ascenseurs de modèle classique, où l'on retrouverait les
flèches lentes v ^ stupidement oubliées sous Mint. On ne peut pas utiliser
une souris partout, surtout avec un netbook.

- L'icône et la fonction "justify" sont désactivées, alors qu'elles
existaient sous OOweb. Ce "big bug" ridicule se voit dès l'ouverture de
l'application comme le nez au milieu du visage. Serait-ce un sabotage au
profit du grand méchant Bill ;-)))? Quoi qu'il en soit, il oblige à entrer
la balise justify à la main dans le code-source de chaque paragraphe; cette
correction est prohibitive pour un texte de quelque importance.

- A chaque réouverture du document, les tirets de conversation (U2014 et
U2015) en début de paragraphe sont mis d'autorité dans la fonte par défaut
et en 12 points, même quand le texte avait été écrit dans une fonte
différente et plus grande. La correction de ce bug est impossible car il
réapparaît à chaque ouverture. Plusieurs autres caractères absents du
clavier sont affectés du même défaut (par exemple la croix qui sert en
anglais pour renvoyer aux notes et en français pour mentionner une date de
décès).

- Dans les alphabets non latins s'écrivant de droite à gauche, un saut de
ligne fautif s'introduit assez souvent au milieu des mots. De même, il est
impossible d'y coller les signes de ponctuation qui se déplacent là où ils
veulent.

- Dans le tableau d'insertion des caractères spéciaux figure l'alphabet
africain tifinagh; cependant, il n'est pas répertorié dans la fenêtre
"sous-ensembles", ce qui rend sa recherche longue et difficile.

- Lors du remplissage des tableaux, une fenêtre avec toutes sortes d'icônes
apparaît en bas et masque une partie importante du travail. C'est très
pénible. Je n'ai pas encore trouvé de truc pour la désactiver.

- De même, une énorme barre de recherche s'affiche désormais au-dessus de la
barre d'état et ampute l'espace de travail; une fois qu'elle est apparue, il
est impossible de la fermer. Je ne comprends pas que l'on se soit ingénié à
dégrader l'ergonomie au lieu de l'améliorer. Il serait pourtant simple de
rendre les barres d'outil, d'état et autres escamotables, de manière à
dégager l'espace de travail pour permettre aux créateurs de se concentrer
sur la mise en page.

- Enfin, un "big bug" destructeur de tableaux, récurrent mais
particulièrement dommageable, existe depuis l'apparition de LO. Si on a le
malheur d'avoir créé sous OOweb des tableaux avec des lignes et des bordures
horizontales de couleur, sans aucune ligne verticale, l'ouverture sous LOweb
les fait assez souvent disparaître et détruit du même coup tous les tableaux
du document! Les tableaux comportant à la fois des lignes et bordures
verticales et horizontales sont plus rarement affectés. On peut certes
recommencer les tableaux; mais à la réouverture suivante, même
destruction... Ce bug lamentable m'a ainsi fait perdre de longues journées
de travail :-(...

Je ne suis pas le seul à avoir constaté ces failles, puisque le responsable
d'un parc informatique d'entreprise qui souhaitait abandonner M$ au profit
de Linux y a renoncé pour cette raison. Depuis, il n'a pas de mots assez
durs pour LibreOffice et ses développeurs.

Il est vraiment dommage que ceux-ci n'attachent pas la moindre importance au
fonctionnement correct de LOweb.

Débarrassé de ces bugs récents, ce serait de très loin le meilleur éditeur
HTML actuel, car outre son excellente intuitivité, c'est le seul qui
permet(tait) d'utiliser sans trop de difficulté des alphabets non latins.

Pour conclure, un défaut qui n'est pas un bug mais qui empêche le grand
public de connaître cet diteur html: alors que Base, Calc, Draw et Impress
ont leur propre icône de lancement dans le menu de Mint/Ubuntu et dans le
panneau d'accueil de LO, il faut avoir la curiosité de cliquer sur une
minuscule petite flèche quasi-invisible dans la barre d'outils de Writer
pour trouver LOweb... bien caché parmi d'autres applications.

Question: pourquoi veut-on empêcher les amateurs de logiciels libres de se
servir de LOweb, un produit autrefois meilleur que Komposer et Dreamweaver?
Une fois réparé, il méritera largement son icône!

J'espère justement trouver sur ce forum quelqu'un de chez LO qui voudra bien
réparer ces bugs au moyen d'une mise à jour (ou m'expliquer comment faire
pour s'en débarrasser). Je me tiens à la disposition des développeurs pour
suggérer d'autres améliorations rendues souhaitables par l'évolution de
l'édition html.

Au nom de tous les (ex-)utilisateurs d'OOweb et de LOweb, merci d'avance.

Cordialement.

Cavalier12.

Bonjour,

..
J'ai été très déçu par LibreOffice 3 qui remplace OpenOffice.

En effet, utilisateur intensif de l'éditeur html, j'ai constaté des bugs
nombreux, patents et parfois destructeurs qui rendent LOweb inutilisable:
...

- L'icône et la fonction "justify" sont désactivées, alors qu'elles
existaient sous OOweb...

Bonjour,

Les fichiers CSS peuvent non seulement compenser, mais modifier la présentation ultérieurement. On peut largement se passer de toutes les mises en formes HTML en faisant faire le travail par les CSS.

- A chaque réouverture du document, les tirets de conversation (U2014 et
U2015) en début de paragraphe sont mis d'autorité dans la fonte par défaut
et en 12 points, même quand le texte avait été écrit dans une fonte
différente et plus grande. La correction de ce bug est impossible car il
réapparaît à chaque ouverture...

L'UTF8 est du pain béni pour ceux qui mettent les mains dans le cambouis. Les problèmes cités n'apparaissent pas.

...
- Lors du remplissage des tableaux, une fenêtre avec toutes sortes d'icônes
apparaît en bas et masque une partie importante du travail. C'est très
pénible. Je n'ai pas encore trouvé de truc pour la désactiver.

Normal. C'est une barre pour travailler dans les tableaux ! Mais si ça gène, on peut ancrer / désancrer, ou même désactiver cette barre d'outils.

- De même, une énorme barre de recherche s'affiche désormais au-dessus de la
barre d'état...

Une simple recherche dans Affichage, barres d'outils permet de choisir les barres à afficher ou non. Mais là aussi, les barres peuvent être flottantes ou non.

- Enfin, un "big bug" destructeur de tableaux, récurrent mais
particulièrement dommageable, existe depuis l'apparition de LO. Si on a le
malheur d'avoir créé sous OOweb des tableaux avec des lignes et des bordures
horizontales de couleur, sans aucune ligne verticale, l'ouverture sous LOweb
les fait assez souvent disparaître et détruit du même coup tous les tableaux
du document! Les tableaux comportant à la fois des lignes et bordures
verticales et horizontales sont plus rarement affectés. On peut certes
recommencer les tableaux; mais à la réouverture suivante, même
destruction... Ce bug lamentable m'a ainsi fait perdre de longues journées
de travail :-(...

Là, je n'ai pas testé, mais en ce qui me concerne, j'ai toujours créé mes tableaux avec... Calc. (C'est plus difficile avec les cellules fusionnées). Pour les bordures, c'est le fichier CSS qui intervient.
Encore une fois, il faut mettre les mains dans le cambouis. Il suffit de savoir manier un minimum de HTML (pour les balises) et manier les & dans Calc pour concaténer. Pas simple de débuter, mais on s'y retrouve vite.

Je ne suis pas le seul à avoir constaté ces failles, puisque le responsable
d'un parc informatique d'entreprise qui souhaitait abandonner M$ au profit
de Linux y a renoncé pour cette raison. Depuis, il n'a pas de mots assez
durs pour LibreOffice et ses développeurs.

Je n'aurai pas de mots assez durs...

Il est vraiment dommage que ceux-ci n'attachent pas la moindre importance au
fonctionnement correct de LOweb.

Il y a sans doute des améliorations plus utiles pour une entreprise, comme le module Base, par exemple.

Débarrassé de ces bugs récents, ce serait de très loin le meilleur éditeur
HTML actuel, car outre son excellente intuitivité, c'est le seul qui
permet(tait) d'utiliser sans trop de difficulté des alphabets non latins.

Ah ! A mon tour de critiquer : la page HTML générée par LibO fonctionne, mais est peu lisible à cause des CSS intégrés. C'est d'évidence plus difficile à gérer par les programmeurs de LibO, mais ce serait une véritable avancée.

...Question: pourquoi veut-on empêcher les amateurs de logiciels libres de se
servir de LOweb, un produit autrefois meilleur que Komposer et Dreamweaver?
Une fois réparé, il méritera largement son icône!

Comparer Komposer et Dreamweaver, c'est comparer un abribus gratuit et un château sans doute excellent, mais pas donné !

J'espère justement trouver sur ce forum quelqu'un de chez LO qui voudra bien
réparer ces bugs au moyen d'une mise à jour (ou m'expliquer comment faire
pour s'en débarrasser). Je me tiens à la disposition des développeurs pour
suggérer d'autres améliorations rendues souhaitables par l'évolution de
l'édition html.

L'éditeur HTML de LibO est loin d'être une merveille, c'est un fait. Toutefois les criques faites ici me semblent démesurées. Il existe d'autres freewares adaptées à la création de sites web, qui ont aussi quelques problèmes, et c'est pour ça que je ne vais pas les citer.

Au risque de surprendre, après avoir testé différents programmes libres, j'ai fait me sites perso avec l'excellent Notepad++, qui rebute au premier abord, mais permet à peu près tout, même avec du PHP. Ensuite, Wamp (ou Lamp sous Linux), Firefox avec quelques extensions (Web Developer, par exemple) permettent à peu près tout (même des crashs par mauvaise utilisation Html / Php).

Au nom de tous les (ex-)utilisateurs d'OOweb et de LOweb, merci d'avance.

Cordialement.

Cavalier12.

Bon surf,
Christian

Bonjour,

Utiliser BlueGriffon, c'est un éditeur WYSIWYG sous licence libre MPL et ça sort du code source XHTML (html+css) correct contrairement à OpenOffice ou LibreOffice dont ce n'est ni la fonction première, ni la fonction principale.

Cordialement.

Bonjour,
je suis surpris d'apprendre par ce post la dégradation de l'éditeur HTML de Libre Office par rapport à son antériorité sous OpenOffice. Depuis la sortie de Libre Office je n'ai pas eu l'occasion de l'utiliser mais juste avant le Fork j'ai été à deux doigts de lancer le développement d'un très gros projet basé sur ce module, et cela d'autant plus qu'il disposait d'un environnement de dévelopement. Ce projet a été abandonné par mon entreprise, mais je ne désespérais pas de proposer à la communauté l'idéee de ce développement permettant de conduire à un outil de création de docuents techniques intégrant des éléments de traçabilité lors de réalisations industrielles et assorti d'un mécanisme de gestion documentaire.
A travers la description de la dégradation intervenue depuis le Fork  je crois percevoir, mais ça mérite d'être confirmé, que les développeurs avancent et décident en fonction de leur propre perception du besoin des utilisateurs. Ayant une vision essentiellement informatique il leur est peut-être difficile d'entrevoir que des utilisateurs peuvent se servir de leur logiciel d'une façon tout à fait inattendue pour eux et qui justifie non seulement un bon fonctionnement, notamment sans régressions lors des montées de version, mais également de poursuivre l'innovation par l'ajout de fonctionnalités nouvelles.
Comme le démontre le commentaire du post d'Audran, cette attitude conduit les utilisateurs à se détourner vers d'autres produits. Pourtant il y avait là la possibilité de se démarquer plus que nettement par rapport à MS Office qui était loin de présenter le même potentiel. Dommage !!!
J'espère quand même que ceux qui sont proches des instances décisionnaires de LiBO seront suffisamment nombreux à se positionner sur cette ligne pour infléchir la direction prise.

Bonjour,

Il n'y aucune note de version qui parle de corrections ou d'ajouts de fonctionnalités. La seule amélioration, concerne l'export vers le format html (libo 3.4) mais pas l'éditeur lui-même.
En regardent les commits, on voit principalement des corrections au niveau de l'import, de l'export en html ou des corrections pour le copier/coller de pages web entre le navigateur et LibreOffice.
En faisant une recherche rapide dans bugzilla, je n'ai pas trouvé de demandes d'utilisateurs pour l'ajout ou l'amélioration de fonctionnalités pour l'éditeur html.
En ce qui concerne OpenOffice, en regardant les notes de versions, on ne trouve que des améliorations pour l'import ou l'export au format html mais rien sur l'éditeur lui-même.
Le sujet ne semble pas déplacer les foules.

Je ne me détourne pas vers d'autres produits, je ne me suis jamais intéresser à l'éditeur html d'OpenOffice ou de LibreOffice jusqu'à aujourd'hui. Lorsque j'avais à faire de l'édition xhtml, j'utilisais un éditeur de texte (avec coloration syntaxique, c'est plus sympa).
En faisant ces recherches, j'ai redécouvert des éditeurs libres comme Amaya ou SeaMonkey et j'en ai découvert un nouveau, OpenBexi.

C'est un projet communautaire, chacun peut apporter sa pierre à l'édifice, développeurs, décisionnaires et utilisateurs.

Cordialement.

P.S. pas la peine de mettre en copie du message, la liste de diffusion suffit pour la réponse

Bonjour,

Il n'y aucune note de version qui parle de corrections ou d'ajouts de fonctionnalités. La seule amélioration, concerne l'export vers le format html (libo 3.4) mais pas l'éditeur lui-même.
En regardent les commits, on voit principalement des corrections au niveau de l'import, de l'export en html ou des corrections pour le copier/coller de pages web entre le navigateur et LibreOffice.
En faisant une recherche rapide dans bugzilla, je n'ai pas trouvé de demandes d'utilisateurs pour l'ajout ou l'amélioration de fonctionnalités pour l'éditeur html.
En ce qui concerne OpenOffice, en regardant les notes de versions, on ne trouve que des améliorations pour l'import ou l'export au format html mais rien sur l'éditeur lui-même.
Le sujet ne semble pas déplacer les foules.

Je ne me détourne pas vers d'autres produits, je ne me suis jamais intéresser à l'éditeur html d'OpenOffice ou de LibreOffice jusqu'à aujourd'hui. Lorsque j'avais à faire de l'édition xhtml, j'utilisais un éditeur de texte (avec coloration syntaxique, c'est plus sympa).
En faisant ces recherches, j'ai redécouvert des éditeurs libres comme Amaya ou SeaMonkey et j'en ai découvert un nouveau, OpenBexi.

C'est un projet communautaire, chacun peut apporter sa pierre à l'édifice, développeurs, décisionnaires et utilisateurs.

Cordialement.

P.S. pas la peine de me mettre en copie du message, la liste de diffusion suffit

Bonsoir

Je ne me détourne pas vers d'autres produits,
Pourtant il y a gEdit et/ou Notepad++
Et quand ça foire, on sait d'où ça vient : de notre codage...
Pour contrôler, il y a Firebug. Et quand c'est bon, le validator du w3c.