Pour faire court, ces redacteurs ont l'habitude de travailler avec des logiciels bureautiques et publient déjà sur papier ce qui sera leurs articles. Donc l'idée est de leur proposer d'importer leurs documents issus de leur suite bureautique, d'en reprendre le contenu et la mise en forme pour le corps de l'article.
Est ce que ça peut intéresser du monde? quels fonctionalités ajouter (je pensais par exemple incorporer une version pdf de l'article)
Ou j'en suis : ça fonctionne mais :
-j'utilise un programme annexe côté serveur pour faire la transformation (OO.org mode serveur + jodconverter)- ligne de commande à fournir dans le code
-pas trouvé de fonctions d'épuration du code HTML qui me convienne du coup si on edite l'article on a le code HTML qui apparait.... pas génant pour mes redacteurs qui si ils ont une modification à faire pense la faire sur le document d'origine et le re-importer.
-gestion des images incluses dans les docs 'artisanale' et compliquée.
-code perso et pas vraiement souple
-code testé uniquement sur une 1.9.2c aucune idée si sa passe sur les autres
-pas de nom
Suite à un echange ici : doc2img - SPIP-Contrib
et à un besoin de mes rédacteurs, j'ai commencé à développer un petit plugin.
Pour faire court, ces redacteurs ont l'habitude de travailler avec des logiciels bureautiques et publient déjà sur papier ce qui sera leurs articles. Donc l'idée est de leur proposer d'importer leurs documents issus de leur suite bureautique, d'en reprendre le contenu et la mise en forme pour le corps de l'article.
C'est excellent de pouvoir importer des fichiers OOo ! Bravo.
Par contre, importer un code html n'est, à mon sens pas une bonne option. Il vaudrait mieux, amha, traduire le code OOo (ou html) en langage SPIP (raccourcis des textes d'articles), quitte à perdre la mise en page des auteurs.
Un code html n'est pas 'portable' si on fait une sauvegarde vers un autre site : la présentation ne va pas s'intégrer à la présentation du nouveau site par exemple.
C'est peut être simplement un jonglage à faire avec du xml ou du jquery sur le code xml généré par OOo (les titres deviennent {{{titre}}}, les listes - ..., etc.).
Pour les images, c'est effectivement plus délicat.
Un code html n'est pas 'portable' si on fait une sauvegarde vers un autre site : la présentation ne va pas s'intégrer à la présentation du nouveau site par exemple.
bzzzz erreur si le code généré est conforme XHTML 1.0 strict ou HTML 4.01 strict il est tout à fait portable puisqu'aucune mise en page n'est faite dans le code.
Mais Mathieu a raison, autant utiliser du code SPIP qui est plus facilement
manipulable par l'outil ensuite (et pas bcp plus compliqué à transcoder
depuis OO)
-----Message d'origine-----
De : spip-zone-bounces@rezo.net [mailto:spip-zone-bounces@rezo.net] De la
part de aurélien levy
Envoyé : samedi 1 décembre 2007 20:43
À : spip-zone@rezo.net
Objet : Re: [SPIP Zone] Proposition nouveau plugin
Un code html n'est pas 'portable' si on fait une sauvegarde vers un
autre site : la présentation ne va pas s'intégrer à la présentation du
nouveau site par exemple.
bzzzz erreur si le code généré est conforme XHTML 1.0 strict ou HTML
4.01 strict il est tout à fait portable puisqu'aucune mise en page n'est
faite dans le code.
_______________________________________________
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone
Bonne idée de poster ta proposition de plugin. Bien que je ne l'ai
peut être pas dit sur le forum de doc2img, je suis aussi intéressé par
ton travail
Tu peux peut être déjà faire un article sur contrib qui présente ton
travail. Ce qui permettra d'avoir un travail de documentation
préalable qui permet de clarifier les besoins et les évolutions à
venir.
Ensuite tu peux poser tes sources sur la zone pour permettre à chacun
de voir ce qui a été fait.
Si le plugin permet de convertir du doc/odt en html c'est un premier pas.
Rien n'empêche dans une seconde évolution d'exploiter un second plugin
dédié à la conversion html>xml comme le fait deja en partie migre
static (peut être encore incomplet comme tu le faisais remarquer sur
le forum) On peut penser que ce second travail pourrait évoluer en
xml>spip
Comme ça on peut etre avoir un outil générique se basant sur regexp
pour html/xml/wiki/....
Lodel (CMS orienté, si je puis dire, philosophie & lettres :
<Lodel – Logiciel d'édition d'électronique) propose déjà une telle fonctionnalité (mais
uniquement pour les formats doc, rtf et sxw, pas encore pour odt ni pour
pdf). Il serait sans doute intéressant de jeter un oeil à leur code (qui
est libre).
Et effectivement, ce serait vraiment génial de pouvoir disposer de cette
fonctionnalité dans SPIP (et idéalement de la fonction inverse de
génération propre de fichiers odt et pdf depuis des données contenues
dans spip).
Cependant, comme d'autres intervenants, il me semble qu'il est très
nettement préférable de stocker les données dans un format utilisant les
raccourcis de SPIP plutôt qu'en HTML.
Peut-être qu'il serait judicieux de (re)demander l'extension des
raccourcis SPIP à plusieurs niveaux de titres pour l'occasion.
++
François
Le samedi 01 décembre 2007 à 20:14 +0100, Edouard Ducray a écrit :
Bonjour,
Suite à un echange ici : doc2img - SPIP-Contrib
et à un besoin de mes rédacteurs, j'ai commencé à développer un petit
plugin.
Pour faire court, ces redacteurs ont l'habitude de travailler avec des
logiciels bureautiques et publient déjà sur papier ce qui sera leurs
articles. Donc l'idée est de leur proposer d'importer leurs documents
issus de leur suite bureautique, d'en reprendre le contenu et la mise en
forme pour le corps de l'article.
Est ce que ça peut intéresser du monde? quels fonctionalités ajouter (je
pensais par exemple incorporer une version pdf de l'article)
Ou j'en suis : ça fonctionne mais :
-j'utilise un programme annexe côté serveur pour faire la transformation
(OO.org mode serveur + jodconverter)- ligne de commande à fournir dans
le code
-pas trouvé de fonctions d'épuration du code HTML qui me convienne du
coup si on edite l'article on a le code HTML qui apparait.... pas génant
pour mes redacteurs qui si ils ont une modification à faire pense la
faire sur le document d'origine et le re-importer.
-gestion des images incluses dans les docs 'artisanale' et compliquée.
-code perso et pas vraiement souple
-code testé uniquement sur une 1.9.2c aucune idée si sa passe sur les autres
-pas de nom
Lodel (CMS orienté, si je puis dire, philosophie & lettres :
<Lodel – Logiciel d'édition d'électronique) propose déjà une telle fonctionnalité (mais
uniquement pour les formats doc, rtf et sxw, pas encore pour odt ni pour
pdf). Il serait sans doute intéressant de jeter un oeil à leur code (qui
est libre).
Et effectivement, ce serait vraiment génial de pouvoir disposer de cette
fonctionnalité dans SPIP (et idéalement de la fonction inverse de
génération propre de fichiers odt et pdf depuis des données contenues
dans spip).
En fait lors de la demande j'avais prévu l'evenualité de leur proposer du lodel. Et après avoir détaillé ce qu'ils faisaient et les outils utilisés, j'en était arrivé à la conclusion suivante : quitte à laisser la transformation .anything_ouvrable_dans_oOo -> html à un outil tiers côté serveur, autant continuer à utiliser mon CMS préféré et utiliser l'outil le plus performant/évolué du moment (jodconverter selon moi).
Pour le stockage en code spip, j'ai fait quelques essais avec certaines fonctions de migre-static, au final mes redacteurs étaient un peu déçus ... donc pour le moment un coup de tidy et zou. Il est bien evident que ce serait la meilleure solution. Reste le cas épineux des images.
++
Edouard
franz a écrit :
Bonsoir,
Lodel (CMS orienté, si je puis dire, philosophie & lettres :
<Lodel – Logiciel d'édition d'électronique) propose déjà une telle fonctionnalité (mais
uniquement pour les formats doc, rtf et sxw, pas encore pour odt ni pour
pdf). Il serait sans doute intéressant de jeter un oeil à leur code (qui
est libre).
Et effectivement, ce serait vraiment génial de pouvoir disposer de cette
fonctionnalité dans SPIP (et idéalement de la fonction inverse de
génération propre de fichiers odt et pdf depuis des données contenues
dans spip).
Cependant, comme d'autres intervenants, il me semble qu'il est très
nettement préférable de stocker les données dans un format utilisant les
raccourcis de SPIP plutôt qu'en HTML.
Peut-être qu'il serait judicieux de (re)demander l'extension des
raccourcis SPIP à plusieurs niveaux de titres pour l'occasion.
++
François
Le samedi 01 décembre 2007 à 20:14 +0100, Edouard Ducray a écrit :
Bonjour,
Suite à un echange ici : doc2img - SPIP-Contrib
et à un besoin de mes rédacteurs, j'ai commencé à développer un petit plugin.
Pour faire court, ces redacteurs ont l'habitude de travailler avec des logiciels bureautiques et publient déjà sur papier ce qui sera leurs articles. Donc l'idée est de leur proposer d'importer leurs documents issus de leur suite bureautique, d'en reprendre le contenu et la mise en forme pour le corps de l'article.
Est ce que ça peut intéresser du monde? quels fonctionalités ajouter (je pensais par exemple incorporer une version pdf de l'article)
Ou j'en suis : ça fonctionne mais :
-j'utilise un programme annexe côté serveur pour faire la transformation (OO.org mode serveur + jodconverter)- ligne de commande à fournir dans le code
-pas trouvé de fonctions d'épuration du code HTML qui me convienne du coup si on edite l'article on a le code HTML qui apparait.... pas génant pour mes redacteurs qui si ils ont une modification à faire pense la faire sur le document d'origine et le re-importer.
-gestion des images incluses dans les docs 'artisanale' et compliquée.
-code perso et pas vraiement souple
-code testé uniquement sur une 1.9.2c aucune idée si sa passe sur les autres
-pas de nom
En fait lors de la demande j'avais prévu l'evenualité de leur proposer du lodel. Et après avoir détaillé ce qu'ils faisaient et les outils utilisés, j'en était arrivé à la conclusion suivante : quitte à laisser la transformation .anything_ouvrable_dans_oOo -> html à un outil tiers côté serveur, autant continuer à utiliser mon CMS préféré et utiliser l'outil le plus performant/évolué du moment (jodconverter selon moi).
Pour le stockage en code spip, j'ai fait quelques essais avec certaines fonctions de migre-static, au final mes redacteurs étaient un peu déçus ... donc pour le moment un coup de tidy et zou. Il est bien evident que ce serait la meilleure solution. Reste le cas épineux des images.
Je trouve l'utilisation des * ou des # dans les raccourcis des niveaux
de titres plus pertinente car cohérente avec les puces hiérarchisées
de Spip que les {1{ et {2{, etc. des enluminures typo.
De plus les titres hiérarchisés sont remplacés par des <hx> où x commence à 3.
Actuellement c'est un plugin qui fonctionne (utilisé en production)
pour Spip 1.9.2c et qui se contente de rajouter les raccourcis et de
permettre l'affichage de la table des matières (avec liens bien sûr)
dans le squelette (balise) et non plus dans l'article.
Avant de publier je veux:
- faire une batterie de modèles pour:
-* afficher la table des matière,
-* faire des renvois vers une partie précise d'un article: avec
affichage automatique du titre de la partie, ex.
<renvoi1250|partie=2.1> qui renvoie un lien vers la partie 2.1 de
l'article 1250 avec son titre. ex.: [titre de la partie->1250#2.1]...
notez que la syntaxe du modèle n'est pas arrétée,
-* afficher des extraits (tout ou en morceau) de parties d'un
article: genre <extrait1250|partie=2.1> pour tout ou
<extrait1250|partie=2.1|debut=0|fin=20> pour les 20 premiers mots (ou
caractères ?... mêmes remarques pour la syntaxe non arrêtée) ex.:
<quote>{{{*titre de la partie}}} bla bla bla bla bla bla bla bla bla
bla bla bla bla bla bla bla bla bla bla bla (...)</quote>,
- Rajouter une extension pour la barre typo v2.
- Faire en sorte que ce soit pris en compte par les plugin de conversion en pdf.
- Faire en sorte que mes rajouts à la contrib' de Mortimer et Chtitux
soient un peu plus propre et un peu plus proche de ce qu'il faut faire
pour un plugin (genre utiliser des pipelines par ex, ce que je ne sais
pas trop bien faire actuellement).
Dites-moi ce que vous en pensez, y'en a-t-il d'autre que moi qui sont
intéressés par ça ? (notez l'incompatibilité avec les enluminures
typo)
Pour info, le format odt est une encapsulation zip de plusieurs fichiers.
Le contenu y est stocke en xml avec un balisage assez simple à convertir en html.
J'ai un plugin oasis sur la zone qui fait l'export spip -> odt qui n'est en fait qu'une conversion html -> xml apropriée
Cedric
cam.lafit@azerttyu.net a ecrit:
Bonjour
Bonne idée de poster ta proposition de plugin. Bien que je ne l'ai
peut être pas dit sur le forum de doc2img, je suis aussi intéressé par
ton travail
Tu peux peut être déjà faire un article sur contrib qui présente ton
travail. Ce qui permettra d'avoir un travail de documentation
préalable qui permet de clarifier les besoins et les évolutions à
venir.
Ensuite tu peux poser tes sources sur la zone pour permettre à chacun
de voir ce qui a été fait.
Si le plugin permet de convertir du doc/odt en html c'est un premier pas.
Rien n'empêche dans une seconde évolution d'exploiter un second plugin
dédié à la conversion html>xml comme le fait deja en partie migre
static (peut être encore incomplet comme tu le faisais remarquer sur
le forum) On peut penser que ce second travail pourrait évoluer en
xml>spip
Comme ça on peut etre avoir un outil générique se basant sur regexp
pour html/xml/wiki/....
Je trouve l’utilisation des * ou des # dans les raccourcis des niveaux
de titres plus pertinente car cohérente avec les puces hiérarchisées
de Spip que les {1{ et {2{, etc. des enluminures typo.
Sauf que ça fait 2 types de raccourcis différents pour faire la même chose , et qu’enluminure pemret de régler le niveau de hnn correspondant à {1{ {2{ {3{ …
De plus les titres{ { hiérarchisés sont remplacés par des où x commence à 3.
Le 02/12/07, Arnaud Ventre<ventrea@gmail.com> a écrit :
Sauf que ça fait 2 types de raccourcis différents pour faire la même chose ,
et qu'enluminure pemret de régler le niveau de hnn correspondant à {1{ {2{
{3{ ....
Eh oui... C'est un souci... D'ailleurs quand les enluminures (qui
s'appelaient différemment à l'époque il me semble...) sont apparues
sur Spip contrib', j'ai essayé d'attirer l'attention sur la contrib'
de Mortimer et Chtitux qui me paraissait plus pertinente au niveau de
la syntaxe des raccourcis, sans succès.
je persiste à penser que {1{ n'est pas une bonne idée. Les accolades
étaient sensées montrer à quel point quelque chose était important,
non ? Une accolade c'est important, deux très important, 3 vraiment
très important si bien que ce sont des intertitres... Je me trompe ?
Dans les intertitres des enluminures il n'y a plus que deux accolades.
> De plus les titres{ { hiérarchisés sont remplacés par des <hx> où x
commence à 3.
>
cf dessus
Un peu de cohérence ne nuirait pas
Ben oui, c'est exactement pour ça que je préfère {{{* qui est cohérent
avec -* et {{{# qui est cohérent avec -# plutôt que {1{...
Je trouve aussi que c'est pertinent de partir de hx avec x=3 comme
dans le raccourci normal de Spip et d'augmenter ensuite. Le fait que
les intertitres de base de spip commencent à h3 présuppose que h2 et
h1 sont utilisés dans les squelettes.
Suite à un echange ici : doc2img - SPIP-Contrib
et à un besoin de mes rédacteurs, j'ai commencé à développer un petit plugin.
Pour faire court, ces redacteurs ont l'habitude de travailler avec des logiciels bureautiques et publient déjà sur papier ce qui sera leurs articles. Donc l'idée est de leur proposer d'importer leurs documents issus de leur suite bureautique, d'en reprendre le contenu et la mise en forme pour le corps de l'article.
Est ce que ça peut intéresser du monde? quels fonctionalités ajouter (je pensais par exemple incorporer une version pdf de l'article)
Ou j'en suis : ça fonctionne mais :
-j'utilise un programme annexe côté serveur pour faire la transformation (OO.org mode serveur + jodconverter)- ligne de commande à fournir dans le code
-pas trouvé de fonctions d'épuration du code HTML qui me convienne du coup si on edite l'article on a le code HTML qui apparait.... pas génant pour mes redacteurs qui si ils ont une modification à faire pense la faire sur le document d'origine et le re-importer.
-gestion des images incluses dans les docs 'artisanale' et compliquée.
-code perso et pas vraiement souple
-code testé uniquement sur une 1.9.2c aucune idée si sa passe sur les autres
-pas de nom
Ben oui, c'est exactement pour ça que je préfère {{{* qui est cohérent
avec -* et {{{# qui est cohérent avec -# plutôt que {1{...
Juste pour ramener ma fraise, je suis aussi d'accord que cette écriture {{{** ou {{{# est
- plus cohérente vis à vis de -* ou -#
- plus simple à écrire au clavier.
- lève l'ambiguité des numéros dans les accolades {3{ qui ne sont je trouve pas trop explicites. Pour moi, si je ne me trompe pas, {{{ = {3{ mais alors que sont {1{ et {2{ dans ce cas là ?
Ca suppose que le raccourcis agit en plus sur la numérotation come pour les listes ? {{{# -> tout titre numéroté}}} et {{{* sous titre non numéroté}}}
Sauf que ça fait 2 types de raccourcis différents pour faire la même chose ,
et qu’enluminure pemret de régler le niveau de hnn correspondant à {1{ {2{
{3{ …
Eh oui… C’est un souci… …
???
…
Je trouve aussi que c’est pertinent de partir de hx avec x=3 comme
dans le raccourci normal de Spip et d’augmenter ensuite. Le fait que
les intertitres de base de spip commencent à h3 présuppose que h2 et
h1 sont utilisés dans les squelettes.
Là un débat débat sans fin a déjà eu lieu sur la liste et dans certains cas ça peut poser des pb d’accessibilité suivant la construction de ton squelette
Pour revenir sur la cohérence faudrait au moins que si pls syntaxe existe les différents plugin les prennent en compte non ?
Ben oui, c’est exactement pour ça que je préfère {{{* qui est cohérent
avec -* et {{{# qui est cohérent avec -# plutôt que {1{…
Juste pour ramener ma fraise, je suis aussi d’accord que cette écriture
{{{** ou {{{# est
plus cohérente vis à vis de -* ou -#
plus simple à écrire au clavier.
lève l’ambiguité des numéros dans les accolades {3{ qui ne sont je
trouve pas trop explicites. Pour moi, si je ne me trompe pas, {{{ = {3{
mais alors que sont {1{ et {2{ dans ce cas là ?
Ca suppose que le raccourcis agit en plus sur la numérotation come pour
les listes ? {{{# → tout titre numéroté}}} et {{{* sous titre non
numéroté}}}
La syntaxe je m’en moque un peu , car dans la mojorité des cas mes rédacteurs passent par les boutons de la barre d’outil, ce qui m’ennuie plus c’est qu’il y en ait pls.
Le 02/12/07, Arnaud Ventre<ventrea@gmail.com> a écrit :
Pour revenir sur la cohérence faudrait au moins que si pls syntaxe existe
les différents plugin les prennent en compte non ?
Je suis bien d'accord. Mais reprendre la syntaxe des enluminures est
un peu complexe vu comment est conçu le code de la contrib' de
Mortimer et Chtitux.
Par ailleurs, sans vouloir être un chipoteur au sujet des
antériorités, la publicité de la contrib' que je souhaite transformer
en plugin est bien antérieure à celle des enluminures. Même sous leur
ancienne appellation. Il aurait été souhaitable que RealET puisse
reprendre les raccourcis typo de Mortimer et Chtitux, mais il ne l'a
pas fait et avait sûrement de bonnes raisons (il semble d'ailleurs,
que sur son site, il utilise les raccourcis type {1{ depuis bien
longtemps).
Alors oui, plusieurs syntxes exsitent et c'est bien là le problème. Je
ne pense pas que "bloater" les plugins pour qu'ils accepetent toutes
les syntaxes soit la meilleure solution.
De mon coté, cela fait un bail (depuis 2005 ?) que j'utilise et mes
rédacteurs aussi les {{{* et {{{# parce que j'ai voulu qu'ils adhèrent
aux principes d'un enrichissement sémantique du texte. Voilà pourquoi
je continue à travailler sur cette contrib' que je trouve remarquable.
Si d'autres sont intéressés je serais heureux que nous puissions
l'améliorer... Et oui, j'aurais préféré que les enluminures suivent
les raccourcis que j'utilisais, mais comme ce ne fut pas le cas: tant
pis, je me débrouille pour que cela puisse quand même continuer à
fonctionner. Car comme il est dit à la fin de l'ancienne contrib' sur
la barre typo enluminée:
----------8<----------
Avertissement important : si vous utilisez les raccourcis
typographiques supplémentaires de ce plugin et que vous cessez
d'utiliser le plugin, ces raccourcis resteront dans votre texte et le
pollueront. Il n'y a pas de procédure de désinstallation.
L'essayer, c'est l'adopter à vie !
------------>8---------
Mais si quelqu'un veut m'aider à faire une contrib' mixte (les deux
types de raccourcis), pas trop lourde et maintenable: je suis preneur
!!!
