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

> 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...

>
> - 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 :-(...

> 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.
>
>
>
>
> --
> View this message in context: http://nabble.documentfoundation.org/L-editeur-HTML-LOweb-tue-par-les-bugs-8-tp4007646.html
> Sent from the Users mailing list archive at Nabble.com.
>

> 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.
>
>
>
>
> --
> View this message in context: http://nabble.documentfoundation.org/L-editeur-HTML-LOweb-tue-par-les-bugs-8-tp4007646.html
> Sent from the Users mailing list archive at Nabble.com.
>

> 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.
>
> --
> Cordialement
>
>
>
>
> ________________________________
>   De : Audran <[hidden email]>
> À : [hidden email]
> Envoyé le : Dimanche 16 septembre 2012 19h22
> Objet : Re: [fr-users] L'éditeur HTML LOweb tué par les bugs =8{{{
>  
> 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.
>
>
> Le 15/09/2012 11:22, Cavalier12 a écrit :
>> 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.
>>
>>
>>
>>
>> --
>> View this message in context: http://nabble.documentfoundation.org/L-editeur-HTML-LOweb-tue-par-les-bugs-8-tp4007646.html
>> Sent from the Users mailing list archive at Nabble.com.
>>
>

> 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.
>
> --
> Cordialement
>
>
>
>
> ________________________________
>   De : Audran <[hidden email]>
> À : [hidden email]
> Envoyé le : Dimanche 16 septembre 2012 19h22
> Objet : Re: [fr-users] L'éditeur HTML LOweb tué par les bugs =8{{{
>  
> 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.
>
>
> Le 15/09/2012 11:22, Cavalier12 a écrit :
>> 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.
>>
>>
>>
>>
>> --
>> View this message in context: http://nabble.documentfoundation.org/L-editeur-HTML-LOweb-tue-par-les-bugs-8-tp4007646.html
>> Sent from the Users mailing list archive at Nabble.com.
>>
>

> Date: Wed, 19 Sep 2012 23:54:39 +0200
> From: [hidden email]
> To: [hidden email]
> Subject: Re: [fr-users] L'éditeur HTML LOweb tué par les bugs =8{{{
>
> 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
>
>
> Le 19/09/2012 15:19, BALOR Elie a écrit :
> > 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.
> >
> > --
> > Cordialement
> >
> >
> >
> >
> > ________________________________
> >   De : Audran <[hidden email]>
> > À : [hidden email]
> > Envoyé le : Dimanche 16 septembre 2012 19h22
> > Objet : Re: [fr-users] L'éditeur HTML LOweb tué par les bugs =8{{{
> >  
> > 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.
> >
> >
> > Le 15/09/2012 11:22, Cavalier12 a écrit :
> >> 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.
> >>
> >>
> >>
> >>
> >> --
> >> View this message in context: http://nabble.documentfoundation.org/L-editeur-HTML-LOweb-tue-par-les-bugs-8-tp4007646.html
> >> Sent from the Users mailing list archive at Nabble.com.
> >>
> >
>
>
> --
> Envoyez un mail à [hidden email] 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
>