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.
Aller plus loin
- L'annonce sur le site de Syntext (480 clics)
- Interview de Syntext (43 clics)
- Téléchargement (544 clics)
- DITA Open Toolkit (98 clics)
- Une liste des libérations de logiciels (247 clics)
# WYDSIWYGBYMDIFTSIIN
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 9.
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 Gyro Gearllose . Évalué à 10.
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 zebra3 . Évalué à 6.
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 Gyro Gearllose . Évalué à 3.
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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 7.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: WYDSIWYGBYMDIFTSIIN
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
A l'époque, je préférais mon bureau fvwm à un Windows 95 !
[^] # Re: WYDSIWYGBYMDIFTSIIN
Posté par gallenza . Évalué à 2.
[^] # Re: WYDSIWYGBYMDIFTSIIN
Posté par Thomas Douillard . Évalué à 2.
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 Victor . Évalué à 6.
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 Jul (site web personnel) . Évalué à 10.
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 Sytoka Modon (site web personnel) . Évalué à 3.
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 Sytoka Modon (site web personnel) . Évalué à 6.
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 Jul (site web personnel) . Évalué à 3.
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 Larry Cow . Évalué à 5.
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 Sytoka Modon (site web personnel) . Évalué à 4.
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 Frédéric COIFFIER . Évalué à 2.
https://linuxfr.org//~Snarky/26911.html
[^] # Re: WYDSIWYGBYMDIFTSIIN
Posté par _alex . Évalué à 2.
- "Efficient XML Interchange Working Group" du W3C : http://www.w3.org/XML/EXI/
- Le format BiM : en général les documents XML échangés respectent un schéma (DTD, XMLSchema, RelaxNG...). Le format BiM tire profit quel le schéma est connu par celui qui génère le document et celui qui le lit. Cf : http://www.mitre.org/news/events/xml4bin/pdf/thienot_binary.(...)
[^] # Re: WYDSIWYGBYMDIFTSIIN
Posté par Jul (site web personnel) . Évalué à 3.
[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 Sytoka Modon (site web personnel) . Évalué à 3.
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 Jul (site web personnel) . Évalué à 2.
Le sysadmin qui mariait sa fille :
http://imagina.ti0n.net/ecrire/?exec=articles&id_article(...)
[^] # Re: WYDSIWYGBYMDIFTSIIN
Posté par Guillaume Savaton (site web personnel) . Évalué à 1.
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 Gohar . Évalué à 2.
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 pititjo . Évalué à 7.
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 Troy McClure (site web personnel) . Évalué à 3.
Tu parles de latex là, non ?
[^] # Re: Le traitement de texte, une hérésie ?
Posté par pititjo . Évalué à -1.
[^] # Re: Le traitement de texte, une hérésie ?
Posté par yellowiscool . Évalué à 7.
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 nicko . Évalué à 7.
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 pititjo . Évalué à 3.
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 alnicodon . Évalué à 3.
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 Victor . Évalué à 8.
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 pititjo . Évalué à 3.
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 tiot (site web personnel) . Évalué à 10.
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 nicko . Évalué à 2.
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 pititjo . Évalué à 3.
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 BAud (site web personnel) . Évalué à 4.
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 nicko . Évalué à 2.
[^] # Re: Le traitement de texte, une hérésie ?
Posté par pititjo . Évalué à 2.
[^] # Re: Le traitement de texte, une hérésie ?
Posté par goom . Évalué à 2.
[^] # Re: Le traitement de texte, une hérésie ?
Posté par pititjo . Évalué à 2.
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 Gohar . Évalué à 2.
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 pititjo . Évalué à 3.
[^] # Re: Le traitement de texte, une hérésie ?
Posté par Gohar . Évalué à 2.
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 pititjo . Évalué à 2.
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 Nicolas Dumoulin (site web personnel) . Évalué à 2.
[…]
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 pititjo . Évalué à 2.
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 ndesmoul . Évalué à 3.
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 BAud (site web personnel) . Évalué à 2.
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 obiyann . Évalué à 9.
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.
[^] # Re: Petite remarque
Posté par Gohar . Évalué à 1.
# Après un test de 5 minutes
Posté par LeJulien . Évalué à 1.
Mais comme toute libération, c'est une excellente nouvelle qu'il convient de saluer.
# Prudence avec l'emploie du mot WYSIWYG
Posté par Stéphane P. . Évalué à 6.
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 nicko . Évalué à 2.
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 Stéphane P. . Évalué à 2.
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 Gohar . Évalué à 3.
[^] # Re: Prudence avec l'emploie du mot WYSIWYG
Posté par BAud (site web personnel) . Évalué à 2.
# ./serna.bin: error while loading shared libraries: libqtpropertybrowser.
Posté par ctorah . Évalué à 0.
./serna.bin: error while loading shared libraries: libqtpropertybrowser.so.1: cannot open shared object file: No such file or directory
pas trés concluant!
[^] # Re: ./serna.bin: error while loading shared libraries: libqtpropertybrow
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
$ LD_LIBRARY_PATH=bin/ bin/serna.bin# Amusant
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Je m'attendais à un genre d'EDI pour DocBook, comme KILE pour LaTeX.
# Non, je n'ai pas tout dit !
Posté par Gohar . Évalué à 3.
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 Frédéric COIFFIER . Évalué à 2.
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 reno . Évalué à 2.
Donc Blender ne peut pas être vraiment considérer comme un succès pour le mélange propriétaire / communautaire..
[^] # Re: Non, je n'ai pas tout dit !
Posté par BAud (site web personnel) . Évalué à 2.
# Etna
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 10.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.