Un éditeur XML Wysiwyg passe au libre

Posté par (page perso) . Modéré par Mouns.
24
4
juil.
2009
Bureautique
Séparer le fond de la forme, tel est le Graal de la rédaction technique, voire de la rédaction tout court. Si les formats XML tels que DocBook ou Dita répondent parfaitement à ce besoin, ils étaient encore réservés à ceux qui sont prêts à mettre les mains dans le cambouis et à manipuler des balises XML sous des éditeurs tels que vim ou Emacs.

Des solutions WYSIWYG plus simples de prime abord existaient, mais elles étaient - pour le moment - toutes propriétaires.

La libération par Syntex de son produit phare sous licence libre GPL v3 pourrait bouleverser le paysage de la création de documents dans les prochaines années et, peut-on rêver, pousser à l'abandon de cette hérésie qu'est le traitement de texte.

Si la version libre du produit souffre encore de quelques bugs, il est déjà tout à fait utilisable pour créer du contenu XML. Pour la génération au format HTML, PDF ou autre, en revanche, il faut toujours faire appel à des solutions telles que DITA Open Toolkit.
  • # WYDSIWYGBYMDIFTSIIN

    Posté par (page perso) . Évalué à 9.

    What you don't see is what you get but you must download it fist to see it, in fact.

    Pour moi, vim est le wysiwyg idéal pour du XML.
    C'est un format de description de données à qui aucune sémantique d'interprétatio n'est attachée, donc "voir du xml", pour moi, c'est bien voir des tags imbriqués et indentés, avec des jolies couleurs.

    J'ai du chercher pour trouver une capture d'écran, et j'ai eu du mal. Enfin, en voilà une ]http://www.syntext.com/images/screenshots/serna-on-vista.png] et une autre [http://www.syntext.com/images/screenshots/custom-content.png].

    En revanche, ça me fait effectivement penser que ça serait bien si je savais, avec mon éditeur de texte, paramétrer une sémantique pour avoir des commandes "met le curseur sur le prochain chapitre" ou "update moi automatiquement l'index quand je rajoute une balise TOTO" quand j'édite un fichier basé sur XML qui représente tel ou tel format bien documenté *et avec une interprétation*.
    • [^] # Re: WYDSIWYGBYMDIFTSIIN

      Posté par . Évalué à 10.

      Pour moi, vim est le wysiwyg idéal pour du XML.

      Tu n'es pas le seul. Mais pour avoir utilisé xmlspy lors d'un stage, j'avoue bien volontiers que le monde du libre a quelques longueurs de retard sur ce soft proprio, payant et cher. Oui, je sais, on va encore me répondre : ben code un équivalent. C'est toujours facile à dire quand on est développeur, mais je doute qu'un éditeur de cette qualité puisse se coder tout seul au fond de son garage.

      Bref, tout ça pour dire que c'est effectivement une niche à prendre, que ce commentaire n'est pas une publicité pour xmlspy, mais une indication de ce qui se fait, et de ce qu'il serait agréable (à mon avis) d'avoir sous linux.
      • [^] # Re: WYDSIWYGBYMDIFTSIIN

        Posté par . Évalué à 6.

        C'est toujours facile à dire quand on est développeur, mais je doute qu'un éditeur de cette qualité puisse se coder tout seul au fond de son garage.

        Y'en a bien qui codent pour le fun un noyau dans leur chambre d'étudiant, ça n'empêche pas que ce noyau se retrouve par la suite sur la majorité des 500 machines les plus puissantes du monde ;-)

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: WYDSIWYGBYMDIFTSIIN

          Posté par . Évalué à 3.

          C'était juste une façon (maladroite peut-être) de dire que même si l'envie était là, je n'avais ni les connaissances, ni les compétences, ni le temps de me lancer dans une telle tâche.
          J'aimerai bien en effet soit pouvoir être l'instigateur d'un tel projet, soit pouvoir y contribuer selon mes moyens (par exemple essayer le-dit logiciel et remonter les bugs ou demandes d'amélioration, aider à la traduction, etc). Pour ce qui est de l'écriture de code, il est parfaitement clair pour moi que c'est hors de question. Il ne me reste que la seconde. Et je suis surpris que des équipes comme (on ne parle que de ce qu'on connaît, hein, il n'est pas question ici de critiquer les autres) ceux qui développent tout ou partie de KDE, ceux qui développent et utilise toute la partie développement de kde (quanta, kdeveloper, etc) n'aient pas eu l'idée de développer un outil dans la même veine que celui que je citais dans mon message précédent.
          La libération du soft dont il est question dans cette news fera peut-être des émules, ou lancera la communauté dans cette direction.
          C'est ce que j'espère en tout cas.
        • [^] # Re: WYDSIWYGBYMDIFTSIIN

          Posté par . Évalué à 7.

          'Y'en a bien qui codent pour le fun un noyau dans leur chambre d'étudiant, ça n'empêche pas que ce noyau se retrouve par la suite sur la majorité des 500 machines les plus puissantes du monde ;-)'

          sisi ca empeche, car finalement il a fallu que ca sorte du garage, qu'il y ait des centaines de gens qui code dessus, et enfin que des entreprises le financent avant que ce soir réellement viable....

          sinon question appli dans un garage c'est plutot hurd l'analogie.
          • [^] # Re: WYDSIWYGBYMDIFTSIIN

            Posté par (page perso) . Évalué à 1.

            C'était fonctionnel avant ce soir ;-) Je travaille depuis 1996 a 95% sur du Linux (le restant étant lorsque je dépanne ;-)) et en 1996, il n'y avait pas encore de boite derrière. Linux était déjà parfaitement fonctionnel pour un tas de chose. Lorsque je vois les problèmes actuels sur ma lenny parce que ldap merdouille au démarrage (il y a une solution), les clefs USB merde à cause qu'udev et hal ne tienne pas compte de pam_group... Bref, on a compliqué la partie logiciel a parfois en perdre de la simplicité d'UNIX !

            A l'époque, je préférais mon bureau fvwm à un Windows 95 !
      • [^] # Re: WYDSIWYGBYMDIFTSIIN

        Posté par . Évalué à 2.

        Héhé, faire un truc comme ça ça doit se faire en ayant quelques conaissances en ingenierie des modèles je pense. Modèle, meta-modèle, représentation graphique des modèles et des métas modèles, édition des représentations des modèles, transformation de modèles ...
        c'est typiquement des trucs qu'ils font en ingénierie des modèles, avec les langages qui vont bien et tout.


        En fait je pense que ça peut se faire tout seul dans son garage SI tu as les compétences en ingénierie des modèles ...

        Enfin en y consacrant pas mal de temps quand même pour les fonctionalité basiques.

        Pour atteindre la couverture fonctionnelle d'un xmlspy (j'ai vu que le site web) c'est une autre histoire.
    • [^] # Re: WYDSIWYGBYMDIFTSIIN

      Posté par . Évalué à 6.

      Ce que tu décris là, c'est exactement ce que fais l'IDM (ingénierie dirigée par les modèles) pour des mecs qui codent (ou pas justement).

      Je ne vois pas pourquoi on se limiterait à manipuler des modèles qui ont comme but de faire du code, on pourrait très bien (techniquement il y a tout ce qu'il faut) faire des modèles représentant des documents, et avoir différents éditeurs associés (correspondant à plusieurs "vues" sur le document) ainsi que des transformation vers les modèles classiques HTML, PDF, etc ...

      L'IDM est juste une généralisation de tout ces petits trucs que font chaque jour nos traitement de texte, éditeur latex, interpréteur latex, etc...
    • [^] # Re: WYDSIWYGBYMDIFTSIIN

      Posté par (page perso) . Évalué à 10.

      What you see Is what you mean avec vim :) nuance

      On est plus dans l'esprit Tex que dans l'esprit office : pour séparer le contenu de la présentation encore faut-il éduquer l'utilisateur à penser à ce qu'il veut dire et à non à ce qu'il voudrait voir autrement : WYSYWIG sux :)

      XML encore plus le rapport signal bruit est impressionnant :)

      (je vous laisse faire la translation)

      [example style='toto' annonced_encoding='utf8' real_encoding='iso8859-1']
      [bullshit level='high' /]
      [content]Hello world[/content]
      [/example]


      Rapport signal bruit 2/1 : probabilité d'introduire des bugs = énorme.

      Le XML est génial pour les programmes et pour l'attitude pro, par contre c'est nul pour les humains :P
      • [^] # Re: WYDSIWYGBYMDIFTSIIN

        Posté par (page perso) . Évalué à 3.

        Ce qui est dommage, c'est que quitte a faire un format pour la machine, autant faire un format binaire plus performant a tout les égards et qui ferait la même chose. HDF par exemple ou un équivalent.

        Bref, on a mis des millions d'heure de travail humaine pour un truc qui finalement est surtout utilisable par la machine mais celle-ci travaille bien mieux en binaire qu'en ASCII... On aurait mis cette énergie sur HDF (ou équivalent) qu'on aurait des programmes bien plus performant de nos jours.
        • [^] # Re: WYDSIWYGBYMDIFTSIIN

          Posté par (page perso) . Évalué à 6.

          Que ceux qui mon moissé explique leur position !

          Le XML n'est qu'une manière d'écrire un arbre. Si sa principale utilisation est dans le dialogue inter-machine, autant avoir un format binaire NORMALISE. Ensuite, avec un petit utilitaire, tu peux transformer cet arbre binaire en arbre XML et réciproquement.

          Bref, je ne vois pas ou l'idée d'avoir un XML binaire est une mauvaise idée. Au contraire. A partir du moment ou on manipule l'arbre XML via des API normalisé, il suffit d'utiliser les mêmes API sur le format binaire. En plus, avec un format binaire, on est obligé de passer par les API et c'en est finit du XML non valide (type XHTML).
          • [^] # Re: WYDSIWYGBYMDIFTSIIN

            Posté par (page perso) . Évalué à 3.

            le code n'est pas écrit pour les machines mais pour les humains : un code passe la moitié de sa vie à être débuguée.

            Je t'accorde que convertir binaire -> texte n'est pas compliqué, pas plus que les encodages, pas plus que la compression, pas plus que la correction syntaxique.

            C'est juste que l'on vas pas passer notre temps à nous compliquer la vie à chaque étape simple alors qu'en plus on peut compresser au dernier moment à la demande de manière transparente (mod gzip de apache par exemple si on fait du SOAP)

            Donc oui ton idée est bête.
            • [^] # Re: WYDSIWYGBYMDIFTSIIN

              Posté par . Évalué à 5.

              Donc oui ton idée est bête.

              Pas si bête que ça, non. Il "suffirait" de remplacer la compression gzip par une compression plus adaptée aux arbres (qui, par exemple, permettrait de conserver certaines propriétés de l'arbre complet dans la forme compressée, histoire d'accélérer le parcours).

              Une compression dédiée est souvent (toujours?) plus intéressant qu'une compression générique. Et c'est précisément ce que serait son "XML binaire".
              • [^] # Re: WYDSIWYGBYMDIFTSIIN

                Posté par (page perso) . Évalué à 4.

                Merci.

                Je me rappelle que Keith Packard annonçant après plusieurs mois de boulot qu'on ne pouvait pas améliorer la latence et le traffic d'X-Windows. Que tout ce que son équipe avait réussi en optimisant ici ou la le code était du même ordre de grandeur que la compression gzip réalisée par ssh avec l'opion -C. Bref, il concluait que le protocole X n'avait pas été conçu pour les faibles bandes passantes et qu'il n'y avait pas grand chose à y faire...

                Puis, peu de temps après, No-Machine sortait NX qui permettait de faire du X sur des liaisons ADSL ! Personne n'y a cru mais on avait tous tords... NX marche super bien.

                Bref, tout cela pour dire que bouffer du CPU pour compresser par gzip les fichiers XML tout cela parce qu'on pense que le XML ASCII, c'est génial et qu'on fera pas mieux, comme toi, je ne suis pas d'accord.

                Il est bien plus rentable de passer des tableaux de nombres réels via HDF5 ou NetCDF qu'en XML ou il faut les écrire avec la quinzième décimale et ou cela prend un place folle et n'est pas du tout optimale pour le transfert.

                Contrairement à NetCDF très orienté tableau, le format HDF5 permet de stocker une structure arborescente. C'est pour cela que j'ai parlé de lui. Ce serait intéressant d'avoir sur ce genre d'outil un portage de l'API XML, rien que pour voir.
              • [^] # Re: WYDSIWYGBYMDIFTSIIN

                Posté par (page perso) . Évalué à 3.

                Reprenons (convention fortran)

                [matrix]
                [line x=1]
                [col y=2]0.707 [/col]
                [/line]
                [line x=2]
                [col x=1] 0.707 [/col]
                [/line]
                [/matrix]

                qui représente en language structuré habituel :
                {
                { 0 , .707 },
                { .707, 0 }
                }
                (matrice rotation 45° en cartésien)

                J'ai été gentil j'ai utilisé une représentation matrice creuse afin de ne pas ridiculiser le XML. Mais même dans ce cas le rapport info utile (chiffre + place) / info totale est faible ça s'appelle du bruit.

                Pour du texte le taux de compression habituel est de 10. Il y a pas un truc qui vous saute aux yeux avec le XML ? C'est tellement bruité que l'on gagne difficilement même en comprimant, dans mon cas, compresser me permet juste de retrouver la taille des mêmes données en JSON et de plus je dois décompresser.

                En plus à moins d'être malhonnête, je XML dans ce cas est illisible : je ne devine pas la matrice en regardardant le code.

                L'hyper verbosité du XML est un frein à sa lisibilité et donc pourri l'attention du lecteur. Le XML est un bon outil, mais pas dans tous les contexte. Pour les cas standard (tableau multidimensions, tableaux associatifs, sets, fichiers de config sutrcuturé ....) le XML est juste un choix excessif (sauf si la validation des données est bien gérée or la plupart des casses couilles du XML que j'ai rencontré n'écrivent jamais de DTD).

                Bref XML je l'admet peut être une bonne solution, mais pas à tous les problèmes.
                • [^] # Re: WYDSIWYGBYMDIFTSIIN

                  Posté par (page perso) . Évalué à 3.

                  Je viens d'aider un copain qui avait un problème sur pam_mount suite a un upgrade du système. Et bien le format XML de ce truc est une horreur (erreur serait plutôt le mot). On se demande si les mecs qui ont pondu ce code sont administrateurs systèmes ou si ce ne sont que des développeurs qui 'pissent' du code au kilomètre !

                  Pour ceux qui ne voit pas de quoi je parle, sur une debian, le fichier en question est :


                  /etc/security/pam_mount.conf.xml
                • [^] # Re: WYDSIWYGBYMDIFTSIIN

                  Posté par (page perso) . Évalué à 1.

                  Mais même dans ce cas le rapport info utile (chiffre + place) / info totale est faible ça s'appelle du bruit.

                  J'aurais tendance à distinguer les notions de "bruit" et de "redondance d'information" et je m'apprêtais à lancer une discussion sur ce sujet.

                  Mais l'article Wikipedia (http://fr.wikipedia.org/wiki/Redondance ) parle également de rapport signal/bruit pour quantifier l'information utile relativement aux informations redondantes.
    • [^] # Re: WYDSIWYGBYMDIFTSIIN

      Posté par (page perso) . Évalué à 2.

      Merci pour les captures d'écran ;-)

      Si Vim et Emacs sont des outils formidables, ce ne sont cependant pas des outils Wysiwyg. Je ne pourrais plus me passer de Emacs + nxml pour faire du DocBook ou du Dita, mais ce n'est pas une solution à la portée de Mme Michu (surtout que j'ai dû bidouiller pour avoir le support Dita avec nxml).

      Or, lorsque je dois échanger des documents avec Mme Michu, ou pire, collaborer avec elle sur un même document, je peste que nous ne puissions trouver un dénominateur commun, c'est à dire un format commun que nous puissions échanger sans conversion. Cet outil vient à point nommé pour répondre - partiellement - à ce problème. Partiellement, car reste le problème de la génération des documents finals, qui n'est pas trivial.
  • # Le traitement de texte, une hérésie ?

    Posté par . Évalué à 7.

    pousser à l'abandon de cette hérésie qu'est le traitement de texte.

    Je ne pense pas que le traitement de texte soit, en lui même, une hérésie.Un traitement de texte n'est rie d'autre qu'un éditeur wysiwyg de xml. L'hérésie c'est la façon dont les traitements de texte sont utilisés : à savoir sans aucune séparation du fond et de la forme.

    Il est possible de faire un document open office avec une séparation stricte du fond et de la forme en utilisant les feuilles de style. C'est juste super pas optimisé côté ergonomie. De ce point de vue là, et ça me fait assez mal de le dire, office 2007 s'en sort franchement bien : en rendant les styles plus visible que les gras, italiques, soulignés et compagnie, le traitement de texte de microsoft est susceptible de faire changer, dans le bon sens, la façon dont on utilise un traitement de texte.

    D'une certaine façon, dommage qu'on est eu besoin d'attendre microsoft pour que l'interface des traitements de texte bouge mais maintenant j'espère qu'on va se diriger vers des traitements de texte libres qui réfléchissent à une interface optimisée plutôt que d'imiter le même schéma depuis 20 ans.
    • [^] # Re: Le traitement de texte, une hérésie ?

      Posté par (page perso) . Évalué à 3.

      L'hérésie c'est la façon dont les traitements de texte sont utilisés : à savoir sans aucune séparation du fond et de la forme.

      Tu parles de latex là, non ?
    • [^] # Re: Le traitement de texte, une hérésie ?

      Posté par (page perso) . Évalué à 7.

      Je l'ai déjà dit ici, mais quand on a testé iWork d'apple, que ce soit open office ou microsoft office, on voit que leur ergonomie est à des années lumières de ce qu'à fait apple.

      C'est pas libre et ça ne fait pas de l'odf par contre. C'est bien dommage, apple aurait pu imposer sa suite sur mac en gérant autre chose que leur format propriétaire.

      Envoyé depuis mon lapin.

    • [^] # Re: Le traitement de texte, une hérésie ?

      Posté par . Évalué à 7.

      Tout à fait d'accord. Ça fait vraiment peur de voir la façon dont les gens se servent de MS Word !

      LE truc agaçant c'est les paragraphes vides pour séparer les paragraphes ! Personne ne sait se servir des styles, les entêtes et pieds de pages sont fait à l'arrache etc ...Et je ne parle pas de la numérotation des titres faite à la main !

      Avec un peu de rigueur on peu faire de très belles choses.
      • [^] # Re: Le traitement de texte, une hérésie ?

        Posté par . Évalué à 3.

        Le truc c'est que même avec open office ou abiword, les fonctions de styles sont difficile d'accès et difficile à appréhender.

        Dans Word 2007, les styles sont dans la première barre d'outils, c'est ce qu'il y a de plus gros et ils sont prévisualisés dès que l'utilisateur passe la souris dessus. Du coup on voit tout de suite plus de quoi il s'agit et on les utilise.

        Je ne connais pas iWork. Mais du peu que j'ai vu ça a l'air de faire aussi la part belle aux styles.

        Quand il deviendra plus facile de faire un document avec une structure sémantique que de faire du gras/italique/souligné, les traitements de textes seront de très bons outils qui sépareront le fond et la forme. On aura alors plus de paragraphe vide pour sauter une ligne, les titres seront numérotés automatiquement tout le temps et les petits chiens auront le poil brillant.
        • [^] # Re: Le traitement de texte, une hérésie ?

          Posté par . Évalué à 3.

          Le truc c'est que même avec open office ou abiword, les fonctions de styles sont difficile d'accès et difficile à appréhender.

          Je ne connais pas iWork. Mais du peu que j'ai vu ça a l'air de faire aussi la part belle aux styles.

          Ouais, et moi, je connais un peu KOffice (c'est KWord le traitement de texte, non ?), et c'est le traitement de texte libre qui m'avait laissé la meilleure impression, d'un point de vue d'un informaticien sensible à la qualité du formatage sémantique dans Word. J'en avait formé le sentiment que la grosse bande de gros geeks derrière ça (je veux dire, c'est pas une mégacorporation type Sun) avait vraiment mené une grosse réflexion pour aboutir à une "métaphore" d'interface graphique permettant à l'éternelle Mme Michu de faire du propre.

          Ou peut-être était-ce simplement moi, qui était au point de conclure que pour mon usage, j'avais là sous les yeux une alternative à Latex un peu moins hardcore, ou en tout cas, joliment Wysiwyg.

          Al.
      • [^] # Re: Le traitement de texte, une hérésie ?

        Posté par . Évalué à 8.

        Ouais mais c'est chiant à utiliser et par défaut tu as un truc pas bien !
        Ce n'est pas simplement une histoire d'utilisation, l'outil te pousse à faire les choses comme ça (ou t'empêche de les faire autrement :)

        Avec latex par exemple, par défaut, on a un truc bien, et en plus on a pas besoin de se poser de questions !
        • [^] # Re: Le traitement de texte, une hérésie ?

          Posté par . Évalué à 3.

          Pas la peine de me convaincre que latex c'est bien : j'en suis convaincu et c'est globalement ce que j'utilise dès que le txt ne fait plus l'affaire.

          Ce n'est pas simplement une histoire d'utilisation, l'outil te pousse à faire les choses comme ça (ou t'empêche de les faire autrement :)

          Tu dis exactement ce que je viens de dire :) L'interface des traitements de textes actuels est très mal pensée et elle pousse à des ignominies mais ce n'est pas le concept de traitement de texte qui est mauvais.

          Avec office 2007 j'ai vu les usages s'améliorer. Maintenant, ma copine dit que son titre est un titre et pas que c'est du texte en caractères 14 et soulignés. Du coup j'ai même arrêter d'essayer de la convaincre d'utiliser open office parce qu'avec OOo c'est moins évident à faire.

          Avec un outil bien conçu on peut, j'en suis sûr, pousser l'utilisateur à avoir de bonnes pratiques et avoir des documents qui séparent parfaitement le fond et la forme.

          Oui oui je sais, il ne me reste plus qu'à coder. Je deviens compétent et je m'en occupe :)
          • [^] # Re: Le traitement de texte, une hérésie ?

            Posté par (page perso) . Évalué à 10.

            Du coup j'ai même arrêter d'essayer de la convaincre d'utiliser open office parce qu'avec OOo c'est moins évident à faire.

            Hum, personnellement je mets les styles dans la barre latérale [http://moipetit.free.fr/bepo/ooo.png]. j'ai tous les styles bien visibles et les noms choisis par défaut sont très explicites. Je ne vois pas en quoi ce n'est pas évident à utiliser.

            Bon, Je te l'accorde, il est dommage que OpenOffice ne se présente pas de cette manière dès le premier lancement…
            • [^] # Re: Le traitement de texte, une hérésie ?

              Posté par . Évalué à 2.

              Bonne idée, je n'avais jamais pensé à faire ça.

              Sinon c'est vrai que les styles par défaut ne sont pas terribles. En plus c'est vraiment quelque chose de facile à corriger. Tout comme la palette de couleurs par défaut vraiment affreuse.
            • [^] # Re: Le traitement de texte, une hérésie ?

              Posté par . Évalué à 3.

              Je n'avais effectivement pas pensé à mettre la fenêtre du styliste en barre latérale. J'avais une petite fenêtre moche du plus mauvais effet. Bientôt tu vas me dire que ooo est livré avec plusieurs feuilles de styles toute jolies en standard et je vais envisager de changer d'avis.

              Reste que ooo par défaut conserve cette interface antédiluvienne qui pousse à utiliser du formatage direct.

              Il va falloir que je teste ça avec en supprimant la barre de formatage et en mettant le styliste en avant.

              Puisque je suis un peu à la masse sur le sujet, ooo a-t-il la possibilité d'annoter des morceaux d'un document ?
              • [^] # Re: Le traitement de texte, une hérésie ?

                Posté par (page perso) . Évalué à 4.

                La fenêtre du styliste s'ouvrait systématiquement dans les premières versions de OOo (et elle est bien plus intuitive que les Word < 2007), permettant de gérer paragraphes et pages aussi (ainsi que caractères, cadres, listes...). Je ne sais plus depuis quelle version de OOo elle ne s'affiche plus par défaut ('fin F11 la fait réapparaître sinon Format / style et formatage iirc).
                Pour le formatage direct, sans passé par les styles, ça a été réclamé par les utilisateurs je crois :/

                Et oui, les annotations de documents sont possibles : Menu Insertion Notes (ou Ctrl-Alt-N sur OOo 3.0.1). La documentation est particulièrement bien faîte sur OOo, ne pas hésiter à l'installer sur sa distrib' (elle ne l'est pas par défaut iirc, par manque de place a priori sur les liveCD mais bon....).
                • [^] # Re: Le traitement de texte, une hérésie ?

                  Posté par . Évalué à 2.

                  Le formatage direct à aussi son interet. Il ne doit pas être utiliser comme outil principal c'est tout.
                  • [^] # Re: Le traitement de texte, une hérésie ?

                    Posté par . Évalué à 2.

                    J'aimerais un exemple.
                    • [^] # Re: Le traitement de texte, une hérésie ?

                      Posté par (page perso) . Évalué à 2.

                      Quand tu tapes une (courte) lettre d'une page au format A4 et que tu as juste à faire un ctrl+i pour mettre en italique, un ctrl+g pour mettre en gras, un ctrl+u pour souligner.
                      • [^] # Re: Le traitement de texte, une hérésie ?

                        Posté par . Évalué à 2.

                        Avec une interface adaptée on pourrait mettre un raccourcis clavier sur les style qu'on utilise souvent comme emphase, titre ou ce qu'on veux. Un raccourcis clavier et pouf c'est un titre ! Pas besoin de le mettre en gras, caractère 14, de changer l'interligne et que sais-je encore.

                        Les mauvais usages avec un traitement de texte sont directement liés aux l'interfaces et aux mauvaises habitudes qu'elles ont fait prendre.
    • [^] # Re: Le traitement de texte, une hérésie ?

      Posté par (page perso) . Évalué à 2.

      Pourquoi dis-je que le traitement de texte est une hérésie? Parce que concrètement, il y a toujours un moment où un document long te pète à la gueule. Genre, tu peux plus l'ouvrir ou la table des matière a explosé (c'est du vécu). Puisque cela m'est arrivé aussi bien avec OpenOffice qu'avec des produits proprio, j'en ai conclu que ce devait être pourri à la base.

      Comme tu dis, il est possible de séparer le fond de la forme sous un traitement de texte. Mais pas obligatoire. Tous les problèmes concrets de l'utilisation de ces outils viennent de là, et tu te retrouves avec un mélange de feuille de style et de formatage à la gruik. Une bonne solution est à mon avis contraignante.

      Il suffit de lire le XML odt pour comprendre que c'est trop complexe. En fait, je rêve d'une solution qui permettrait l'édition Wysiwig des feuilles de style appliquées à des documents en XML reposant sur une DTD bien conçue, telle que celle de DocBook ou de DITA.

      Ceci pour les documents longs ou structurés sur un modèle, genre lettre commerciale. Pour les documents plus fancy, il faut avoir recours à Scribus ou autre.
      • [^] # Re: Le traitement de texte, une hérésie ?

        Posté par . Évalué à 3.

        Cf mon message un peu au dessus : le soucis viens des interfaces (et peut-être du format mais je n'ai pas étudié la question).
        • [^] # Re: Le traitement de texte, une hérésie ?

          Posté par (page perso) . Évalué à 2.

          Je ne crois pas que ça vienne seulement des interfaces. Il faut un système idiot proof. Si un document doit être modifié par mettons 10 personnes, il y en aura toujours une qui voudra créer un titre en augmentant la taille de la police ou qui créera une liste numérotée en mettant les numéros à la mano.

          Je ne dis pas que même avec la meilleure DTD du monde cela ne pourra pas se produire (DocBook et Dita ne sont pas 100% sémantiques et ont une notion d'italique ou de gras, par exemple, et il sera toujours possible de numéroter une liste manuellement), mais cela limite énormément les dégâts. Ces dégâts peuvent facilement être réparés par un script pour la plupart. Réparer de l'odt, c'est déjà plus complexe...
          • [^] # Re: Le traitement de texte, une hérésie ?

            Posté par . Évalué à 2.

            Si on vire les boutons de mise de forme directe, monsieur Gruik pourra toujours vouloir mettre son titre sans passer par le style ad-hoc, il n'aura pas tellement le choix.

            Après, si monsieur Gruik veux vraiment faire son sale, il pourra toujours tenter de mettre son texte en gras en le faisant passer pour un titre de 36ème niveau dont le style par défaut ressemble à ce qu'il voulait faire. Il trouvera en plus le moyen de dire que c'est pas pratique.
    • [^] # Re: Le traitement de texte, une hérésie ?

      Posté par (page perso) . Évalué à 2.

      De ce point de vue là, et ça me fait assez mal de le dire, office 2007 s'en sort franchement bien : en rendant les styles plus visible que les gras, italiques, soulignés et compagnie
      […]
      D'une certaine façon, dommage qu'on est eu besoin d'attendre microsoft pour que l'interface des traitements de texte bouge

      Hmmm, de mémoire Kword avait proposé ce principe dans une ancienne version. Mais bon, apparemment, ils en sont revenus. Ils n'avaient peut-être pas une grosse notoriété pour encaisser les grincheux …
      • [^] # Re: Le traitement de texte, une hérésie ?

        Posté par . Évalué à 2.

        Je n'avais pas regarder vraiment Kword jusqu'ici. Je l'ai installé mais l'interface me semble assez traditionnelle.

        C'est vrai que les utilisateurs de traitement de texte sont tellement habitués à leurs interfaces et à leurs usages que les changer est dur. Mais tandis qu'on se rend compte combien le monde est beau quand il est sémantique, ça serait dommage de laisser le traitement de texte faire tache dans le paysage.
    • [^] # Re: Le traitement de texte, une hérésie ?

      Posté par . Évalué à 3.

      Moi je trouve pourtant qu'OpenOffice Writer s'en sort beaucoup mieux pour la gestion des styles que Word (au moins 2003).

      A la condition toutefois d'ouvrir la fenêtre de gestion des styles (bouton "style et formatage"). Cette fenêtre est soit volante, soit peut être fixée sur un côté de la fenêtre.
      Depuis cette fenêtre tu as accès à tous les styles selon plusieurs critères. En particulier il est possible de limiter la liste aux seuls styles utilisés, ce qui est pratique une fois que l'on a tous bien définis.

      Pour avoir utilisé Office 2003, je trouve que ce logiciel est justement une véritable bouse pour ce qui de la gestion des styles. Définir tous les éléments d'un style est compliqué (plusieurs fenêtres à ouvrir) et il est souvent difficile de retrouver un style particulier.

      J'ai découvert la puissance des styles avec OpenOffice.
      On pourrait reprocher par contre à OpenOffice que cette gestion des styles ne soit pas mise plus en avant.

      Je n'ai jamais essayé Office 2007 plus de 5 minutes, donc ne peux pas me prononcer dessus (à part que les bandeaux (ou rouleaux?) c'est plutôt déroutant, au moins au début...).
      • [^] # Re: Le traitement de texte, une hérésie ?

        Posté par (page perso) . Évalué à 2.

        On pourrait reprocher par contre à OpenOffice que cette gestion des styles ne soit pas mise plus en avant.

        comme je l'indiquais, le styliste était systématiquement mis en avant dans OOo à une époque, jusqu'à ce que des utilisateurs excédés réussissent à faire reproduire les mauvaises habitudes prises avec un éditeur de texte (l'exemple classique pris étant grand-mère qui veut écrire une lettre à ses petits enfants... et que la fenêtre en trop dérange :/).
        Sans aller jusqu'à ce que faisait Framemaker (traitement de texte SGML) pour qui point de salut sorti des styles, remettre en avant les bonnes pratiques en fonction des types de document (lettre, rapport, thèse, article, spécifications...) et afficher systématiquement le styliste pour certains modèles de document ferait prendre de bonnes habitudes (j'ai déjà vu un ingénieur faire la table des matières de son rapport à la main et émerveillé quand je lui ai montré la fonction "insérer table des matières/Index" alors qu'il avait passé plus d'une heure à repérer les n° de page et moi 10 mn à remettre ses titres avec un style...).
  • # Petite remarque

    Posté par . Évalué à 9.

    Bonsoir.

    Cette dépêche est intéressante, mais dire le nom du logiciel concerné aurait été bienvenu. J'ai dû aller dans les liens pour savoir le nom du logiciel concerné: "Serna Free".

    Merci tout de même pour cette dépêche intéressante, ce message est juste une petite remarque sur sa rédaction.
  • # Après un test de 5 minutes

    Posté par . Évalué à 1.

    Je pensais découvrir l'intérêt de la chose en testant le logiciel. Mais rien... Mais si des entreprises payent $749 la licence, ça doit avoir son utilité. Allez, 10 minutes de plus au cas où.

    Mais comme toute libération, c'est une excellente nouvelle qu'il convient de saluer.
  • # Prudence avec l'emploie du mot WYSIWYG

    Posté par . Évalué à 6.

    Je ne suis pas sûr que l'on puisse parler de WYSIWYG pour un éditeur XML générique, étant que le XML tout seul, ce n'est pas un format destiné a afficher ou imprimer quelque chose...

    J'ai toujours pensé que l'on n'utilisait cette acronyme lorsque le résultat est visuellement identique a ce que l'on imprime ou ce qui est affiché une fois l'édition des données terminées, par exemple un traitement de texte.

    Par exemple imaginez que l'on tape une équation MathML, une page web XHTML, ou un fichier SVG avec cet éditeur (tous des formats XML), voit-on le résultat en temps réel au cours de l'édition tel qu'il va être imprimé ? certainement pas !

    Vos avis ?
    • [^] # Re: Prudence avec l'emploie du mot WYSIWYG

      Posté par . Évalué à 2.

      En realité on devrait parles de WYSIWYWTG : What you see is what you want to get. L'impression étant dans tout les cas différente de ce qu'il y a l'écran. Ne serait-ce qu'en terme de colorimétrie.

      Et puis il ne faudrait pas parler de l'impression, mais des impressions, car chaque imprimante donnera un résultat différent
      • [^] # Re: Prudence avec l'emploie du mot WYSIWYG

        Posté par . Évalué à 2.

        Oui mais pour le coup, on en est même pas a ce stade, j'imagine que l'on parles de WYSIWYTG quand le résultat est proche modulo des écarts liés a des imperfections de publication.

        Par exemple si je fait une impression à partir d'OpenOffice, comme tu dis il y aura des écarts de colorimétrie, éventuellement des remplacements automatiques de police si j'envoie le document électroniquement mais a la base l'éditeur est fait au moins avec cette intention d'une reproduction fidèle lorsqu'il est publié.

        Si j'écris un document OpenOffice avec un éditeur XML (il faut être bien geek pour faire un truc pareil...) la dernière chose que j'ai envie de voir sortir sur mon imprimante est une liste des propriétés de chaque partie de texte sous forme d'arborescence :) Dans ce cas cela remettrais en question aussi le fait qu'il soit WYSIWYM.

        On pourrait me répondre "un éditeur XML n'est pas fait pour éditer ce genre de fichier". Mais même pour des formats XML moins orienté "formatage" et plus orienté données, on est jamais sûr de comment l'utilisateur va vouloir exploiter le résultat : on voudra au minimum appliquer une feuille de style a une page XHTML, qui va peut être modifier complètement les positions de ce que nous avons écrits (un morceau de contenu tout a la fin du XHTML peu se retrouver tout en haut en position absolue par ex). Donc on est toujours certainement pas WYSIWYG, mais on tends vers le WYSIWYM lorsque la DTD n'est pas orienté mise en forme / style / layout... (comme dans le cas des chaînes éditoriales)
    • [^] # Re: Prudence avec l'emploie du mot WYSIWYG

      Posté par (page perso) . Évalué à 3.

      Le vrai acronyme est wysiwym http://fr.wikipedia.org/wiki/What_You_See_Is_What_You_Mean mais personne ne le comprend...
      • [^] # Re: Prudence avec l'emploie du mot WYSIWYG

        Posté par (page perso) . Évalué à 2.

        je peux encore le rajouter dans la dépêche (comme j'avais complété wysiwyg dans le texte qui n'apparaissait initialement que dans le titre), profites-en pour indiquer les autres ajouts à faire ;-) (outre le nom du logiciel).
  • # ./serna.bin: error while loading shared libraries: libqtpropertybrowser.

    Posté par . Évalué à 0.

    J'ai voulu tester sur ma debian testing et y me dit ça :

    ./serna.bin: error while loading shared libraries: libqtpropertybrowser.so.1: cannot open shared object file: No such file or directory

    pas trés concluant!
  • # Amusant

    Posté par (page perso) . Évalué à 4.

    Amusant, comme concept, le DocBook graphique. Mais ce n'est pas demain que j'utiliserai autre chose que Vim pour éditer la formation Debian, franchement. Je trouve qu'on s'y perd un peu, avec un clicodrome qui ne rend pas les balises plus apparentes.

    Je m'attendais à un genre d'EDI pour DocBook, comme KILE pour LaTeX.
  • # Non, je n'ai pas tout dit !

    Posté par (page perso) . Évalué à 3.

    Mais c'est pas drôle si on dit tout d'un coup :-)

    L'interview du COO de syntext est très intéressante, notamment parce qu'il cite la crise comme facteur majeur de sa décision de libérer le code:

    La crise financière mondiale, qui a fortement touché le marché informatique (avec un chiffre d'affaires en baisse de 50 à 60 %), nous a amené à envisager une approche très différente de notre activité.

    (The world financial crisis situation, which the IT market has clearly felt (with a revenue drop of 50%-60%), has made us think that we have to approach very differently our business.)


    Est-ce que dans un monde que les plus pessimistes disent en train de s'effondrer, le libre offrirait un modèle alternatif crédible?

    À verser en tout cas au dossier Impact de la crise sur le logiciel libre.
    • [^] # Re: Non, je n'ai pas tout dit !

      Posté par . Évalué à 2.

      Il y en a qui ont déjà essayé (sans succès) :

      https://linuxfr.org//2005/11/01/19835.html

      Dans le cas de Xara, ils avaient ouverts tout le code sauf le moteur 2D ! Pendant un moment, certains ont pensé pouvoir utiliser Cairo mais finalement, la communauté a préféré passer du temps sur Inkscape (et le Xara Linux a été abandonné depuis).

      Les ouvertures de code cachent bien souvent d'autres objectifs que la pure philanthropie : se faire de la pub facilement auprès d'une cible bien particulière et attentive ou trouver des développeurs compétents pour pas cher.
      Même s'ils ouvrent le code, la version Free est-elle vraiment utilisable (en comparaison de la version Pro, la version Free devenant un produit d'accroche) ?

      Combien y a t-il eu de produits propriétaires à passer en développement purement communautaire avec succès (ce qui n'est pas le cas d'OpenOffice, ni de Firefox mais ce qui est le cas de Blender) ? Les succès ne sont pas si nombreux à ma connaissance.
      • [^] # Re: Non, je n'ai pas tout dit !

        Posté par . Évalué à 2.

        Succès, succès, cela dépend de ce que tu entends par succès: certes le développement communautaire de Blender fonctionne bien, mais l'entreprise qui était derrière avant n'existe plus!
        Donc Blender ne peut pas être vraiment considérer comme un succès pour le mélange propriétaire / communautaire..
  • # Etna

    Posté par (page perso) . Évalué à 10.

    >Des solutions WYSIWYG plus simples de prime abord existaient, mais elles étaient - pour le moment - toutes propriétaires.

    Non, pas toutes, il y avait le projet Etna, que j'ai commencé à développer il y a presque 5 ans. Entièrement libre, basé sur Mozilla (qui possède un bon moteur de rendu, et des fonctions d'éditions mais que j'ai du quand même hacker). http://etna.disruptive-innovations.com

    Malheureusement, faute de temps, il n'est pas encore prêt pour une utilisation en production, et je peine à trouver du temps (surtout depuis que je ne suis plus chez disruptive innovations) pour finaliser une nouvelle version qui contient un nouveau validateur RelaxNG temps réèl plus costaud, et basé sur un gecko plus récent...

    Sinon, pour répondre à certaines questions, faire du XML wysiwyg (ou plutôt de l'édition "visuel" d'un document XML, sans que l'utilisateur ait à écrire/à voir du XML), c'est plutôt compliqué, voir plus compliqué que de faire un éditeur HTML wysiwyg.

    Quand l'éditeur connait en natif le format XML, (genre Kompozer pour (x)html, ou OpenOffice pour odf), on peut "cabler" en dur des comportements pour tel ou tel balise, voir même à la limite transformer le document XML en un truc binaire qui serait plus facilement exploitable par le moteur de rendu et d'édition.

    Mais quand il s'agit d'un éditeur générique, c'est à dire qu'il puisse éditer visuellement n'importe quel type de document XML, ça se complique. Il faut d'abord fournir à l'éditeur un schéma pour qu'il puisse faire de la validation, qu'il sache quel element on peut créer et où, et vérifier le contenu textuel que l'on insère dans ces éléments... Mais ce n'est pas suffisant, car l'éditeur doit pouvoir savoir comment afficher ces balises, si par exemple ce sont des balises qui représente des blocks, ou si ce sont des élements "inlines" (comme le strong en XHTML par exemple.) Malheureusement, il n'est pas possible de fournir ce genre d'informations dans les formats de schemas existants (XMLSchema ou RelaxNG, et puis DTD, on oublie hein).

    Il n'est pas possible non plus d'indiquer quel est le contenu par défaut quand on crée tel élément. L'éditeur peut éventuellement le deviner à partir du schema, mais quand il y a plusieurs choix possibles, ben il prend le premier, qui n'est pas forcément celui que veut l'utilisateur...

    Manque aussi tout ce qui est descriptif. Un éditeur XML générique, il ne sait pas ce qu'est la balise P en XHTML. Et indiquer "inserer un P" à l'utilisateur, ça va pas beaucoup aider ce dernier. Il faut donc un moyen de dire à l'éditeur que P, c'est un "paragraphe", afin que l'interface soit intuitive. Il faut aussi apporter des descriptions pour que l'utilisateur puisse faire son choix quand, lorsque pour créer un élément, il y a plusieurs choix autorisés par le schema.

    Bref, il n'y a rien de prévu dans XMLSchema et RelaxNG pour les éditeurs. Il faut donc fournir ces informations, en plus du schema.

    Dans Etna, ça passe par des balises supplémentaire dans RelaxNG (c'est autorisé par la spec RelaxNG) pour tout ce qui est nécessaire à l'édition proprement dite. Et pour ce qui est de l'affichage, il faut fournir une feuille CSS.

    Il y a aussi des problèmes d'interfaces utilisateurs. Même dans un document XML orienté textuel, il y a des éléments contenant des informations "techniques" (des metas datas, ou le titre du document par exemple). Là encore, l'éditeur wysiwyg ne peut pas deviner la nature de ces éléments. Et il est préférable que ces informations soient édités avec une interface dédiés. Il faut donc que l'éditeur fournisse des "hooks" pour pouvoir lancer par exemple une boite de dialogues pour éditer ces choses (genre dans open office, la boite de propriété du document). Bref, il faut fournir des éléments d'interface graphique à l'éditeur. Dans Etna, ça passe donc par la réalisation d'une extension (à la firefox) (et la feuille de styles CSS cache les éléments qu'il faut pas éditer via la zone d'édition) .


    Enfin, pour les questions à propos de l'utilité d'un editeur XML "wysiwyg", posez vous alors la question : préféreriez vous éditer un document open-office "à la main" avec VI ? Pensez vous que cette méthode d'édition serait plus pratique pour madame michu pour écrire son courrier ? Pour ma part, je dis non. L'utilisateur en à la limite rien à foutre du format. Ce qu'il veut, c'est écrire son document le plus simplement du monde, et que ce document puisse être ensuite utilisé correctement par d'autres outils éventuels (l'éditeur doit produire du XML valide etc.)

    Mais maintenant, un éditeur XML wysiywg n'est pas fait non plus pour éditer n'importe quel type de fichier XML. Ca reste bien entendu utile que pour les formats XML orienté documents textuels (docbook, xhtml, odf et j'en passe). Ça n'a bien entendu aucun sens d'éditer par exemple un fichier de configuration XML avec ce genre d'outils. Pour ce genre de document, c'est plus une interface utilisateur graphique qu'il faut, pas une surface de rendu/d'édition textuelle.

    Enfin il faut savoir qu'il y a pas mal de domaines et d'industries, où des documents textuels sont stockés en XML, et dans un format XML qui leur ait propre parce que mieux adapté à leurs besoins et parce que leur système d'information a été conçu avec ce format.

    J'ai l'exemple d'ailleurs de Rice University (qui commanda le projet Etna), qui stockent leurs cours dans leur propre format XML, et qu'ils publient ensuite sur le web (après transformation via XSLT). Et les gens qui éditent ce genre de document avaient voulu une sorte de traitement de texte, plutôt que d'apprendre le markup du format, ou d'utiliser ces éditeurs XML arborescents et peu pratique finalement pour ce genre de documents... (et malheureusement, suite à l'ouragan catherina, leur budget a été restreint, et n'ont pas pu continuer à financer le projet Etna...)


    Enfin pour conclure, les éditeurs XML wyiwyg, c'est comme pour les browsers ou les éditeurs HTML wysiwyg : y en a très peu en open source, parce que ça demande des compétences spécifiques, ça demande de la recherche (donc du temps, donc des sous) parce que c'est un domaine complexe (tant au niveau technique qu'au niveau interface utilisateur), et qu'il y a peu d'expériences "publiques", de feedback, pour aider à leur réalisation.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.