[spip-dev] Structuration des textes?

63438612493668b99328 · Mai 14, 2002, 6:32

ARNO* wrote:

Est-ce qu'il serait intéressant de permettre une telle indication structurelle du contenu des articles dans SPIP? Est-ce que ce serait simple à implémenter? Gains et inconvénients...

Juste un truc, pour l'implémentation : il faut que le code de fin soit
spécifique lui aussi.

Ainsi : {{{** Intertitre de niveau 2 **}}}
et non : {{{** Intertitre de niveau 2}}}

Obligatoire afin de faire comme actuellement, i.e. simplement remplacer
respectivement "}}}" et "**}}}" par le code HTML correspondant, sans
tester la présence du code de début.

Sinon, sur le fond : en tant qu'utilisateur occasionel et brouillon,
et donc représentatif de l'utilisateur moyen, de traitement de texte
(en clair, Word), je ne cherche jamais à respecter une structuration
en appliquant les styles. Je ne travaille pas non plus en mode "outline"
(structure), mais directement en mode wysiwyg. Je pense que c'est aussi
ce que fait le rédacteur moyen (pas le féru de mise en page), donc
les raccourcis de structuration sont absolument inutiles dans ce cadre.

Enfin, ça risquerait de rendre la fonction traiter_raccourcis bcp
plus lourde à l'exécution, mais pour ça il faut tester.

Gilles_Perez-Lambert · Mai 15, 2002, 7:32

Bonjour à tous,

Sinon, sur le fond : en tant qu'utilisateur occasionel et brouillon,
et donc représentatif de l'utilisateur moyen, de traitement de texte
(en clair, Word), je ne cherche jamais à respecter une structuration
en appliquant les styles. Je ne travaille pas non plus en mode "outline"
(structure), mais directement en mode wysiwyg. Je pense que c'est aussi
ce que fait le rédacteur moyen (pas le féru de mise en page), donc
les raccourcis de structuration sont absolument inutiles dans ce cadre.

C'est vrai que ça peut être inutile mais pour présenter un article assez structuré, ce serait très pratique des les avoir; Surtout que ça pourrait mener à la génération automatique du contenu de l'article au début de l'affichage. J'ai commencé à traiter via mes_fonctions.php3 ce genre de problèmes mais l'inconvénient est de ne pas apparaître dans l'espace privé.
..

À ce propos, serait-il possible/souhaitable de décider que les fonctions commençant par traitement_txt_ (par exemple) dans mes_fonctions.php3 soient automatiquement appliqués à la prévisualisation de l'article dans l'espace privé. J'ai rajouté un raccourci pour générer <BLOCKQUOTE /> mais le raccourci apparaît tel quel dans l'espace privé : pas glop. Si c'est complètement c.. comme idée, laissez tomber.

À bientôt,

Gilles.

Guillaume · Mai 15, 2002, 7:48

Petite remarque sur la non structuration des documents. on trouve les
situations suivantes:
- le lecteur (eh oui quelqu'un essayera le lire les textes) n'a pas de
repère de lecture, doit faire un grand effort, rate ou comprend mal le texte
(idées, informations). La lecture est difficile et l'appropriation des
informations délicate.

- La qualité de la rédaction devient aléatoire. Sans parler de la difficulté
de la réutilisation du contenu...

- l'application d'un rendu est fort délicat. Distinguer les introductions,
les remarques, les commentaires du corps du texte par exemple est alors un
travail long pénible et délicat si la personne (pas forcément l'auteur) ou
le logiciel qui réalise ce travail n'a pas d'éléments de choix pour ce
traitement.

- les traitements informatiques se trouvent limités:
    - création d'une table des matières, des tableaux des figures
    - amélioration de la recherche
    - etc.

Guillaume

Nicolas_Hoizey2 · Mai 15, 2002, 8:28

Hello,

À ce propos, serait-il possible/souhaitable de décider que les
fonctions commençant par traitement_txt_ (par exemple) dans
mes_fonctions.php3 soient automatiquement appliqués à la
prévisualisation de l'article dans l'espace privé.

Ce n'est pas possible, à moins que l'on copie 'mes_fonctions.php3'
dans 'ecrire/' (pb d'include sinon), et il reste de toute façon encore
à détecter des tags spéciaux et voir s'ils correspondent à une
fonction de ce 'mes_fonctions.php3', galère ...

Le mieux serait plutôt de pouvoir prévisualiser le rendu final en
ouvrant par exemple dans une autre fenêtre la page du site où
apparaîtrait l'article (resp. la brève, etc) s'il était en ligne, mais
il faut alors forcer le recalcul et ne pas sauver le résultat en
cache.

-Nicolas

63438612493668b99328 · Mai 15, 2002, 8:49

Salut,

- le lecteur (eh oui quelqu'un essayera le lire les textes) n'a pas de
repère de lecture, doit faire un grand effort, rate ou comprend mal le texte
(idées, informations). La lecture est difficile et l'appropriation des
informations délicate.

Heu... y a un truc qui m'échappe. Quand tu lis un article de journal, tu
as des infos de structuration ? Moi j'ai juste deux styles de mise en page
(intertitres + corps de texte), et ça ne m'empêche pas de comprendre
l'article.

- La qualité de la rédaction devient aléatoire. Sans parler de la difficulté
de la réutilisation du contenu...

??? La qualité rédactionnelle n'est pas déterminée par l'utilisation
d'infos de structuration…

- l'application d'un rendu est fort délicat. Distinguer les introductions,
les remarques, les commentaires du corps du texte par exemple est alors un
travail long pénible et délicat si la personne (pas forcément l'auteur) ou
le logiciel qui réalise ce travail n'a pas d'éléments de choix pour ce
traitement.

-> introduction : chapo
-> remarques : notes de bas de page

- les traitements informatiques se trouvent limités:
    - création d'une table des matières, des tableaux des figures
    - amélioration de la recherche
    - etc.

Pour moi, table des matières implique rubriquage et découpage en plusieurs articles.
A la base, c'est un peu la philosophie des articles sous SPIP : un article doit
pouvoir être rendu sur une seule page HTML (comme dans l'espace privé) sans que
sa lisibilité en pâtisse.

Surtout, avec des infos de structuration et donc des raccourcis supplémentaires,
le rédacteur lambda va se perdre dans les possibilités, et faire n'importe quoi
(comme sous Word : "tiens je prendrais bien le style titre 3 parce que la taille
de la fonte me plait, et puis là je veux un paragraphe justifié à droite donc
je prends le style signature"). Très peu de rédacteurs pensent leur texte en
termes de structuration, amha. En prévoyant le minimum minimorum, on force le
choix et les chances qu'il a d'être raisonnable. A contrario, avec beaucoup de
choix possibles, ça fait énormément plus de boulot pour les relecteurs/admins
(avec les malentendus subséquents : "pourquoi t'as mis ce truc en titre 2,
alors qu'en fait c'était juste une incise que je voulais mettre en valeur ?").

a+

Antoine.

Gilles_Perez-Lambert · Mai 15, 2002, 8:58

Bonjour,

Heu... y a un truc qui m'échappe. Quand tu lis un article de journal, tu
as des infos de structuration ? Moi j'ai juste deux styles de mise en page
(intertitres + corps de texte), et ça ne m'empêche pas de comprendre
l'article.

C'est vrai, mais quand on lit un journal, on a en général l'ensemble de l'
article sous les yeux, ce qui n'est pas le cas sur une page web.

choix et les chances qu'il a d'être raisonnable. A contrario, avec beaucoup de
choix possibles, ça fait énormément plus de boulot pour les relecteurs/admins
(avec les malentendus subséquents : "pourquoi t'as mis ce truc en titre 2,
alors qu'en fait c'était juste une incise que je voulais mettre en valeur ?").

D'accord. On pourrait alors proposer ça en contrib pour inclusion dans mes_fonctions.php3 ? Il faudrait alors prendre une syntaxe du type {{{1: ... :1}}} pour que ces titres de niveaux différents apparaissent au moins comme des intertitres dans l'interface privée.

À plus,

Gilles.

Yannick_Patois · Mai 15, 2002, 2:02

Salut,

D'accord. On pourrait alors proposer ça en contrib pour inclusion dans
mes_fonctions.php3 ? Il faudrait alors prendre une syntaxe du type
{{{1: ... :1}}} pour que ces titres de niveaux différents apparaissent au
moins comme des intertitres dans l'interface privée.

J'ai comme l'impression que cela pourrait aller de paire avec la gestion
d'articles "très long" que plusieurs personnes ont déjà demandées...

En plus de breve et article on aurait 'raport' ou qqch comme ca: un
article fait pour s'afficher avec un sommaire et plusieurs pages webs et
une structure formelle solide.

Malheureusement, je crains de ne pas avoir le temps de coder ca

Yannick

Gaetan_Ryckeboer · Mai 15, 2002, 2:04

C'est une idée, ça...

A mettre en relation avec les documents SGML (docbook), et prévoir un
import du fichier docbook vers spip ?

Malheureusement, je n'ai pas de connaissance de docbook, dans la mesure
où c'est pire que LaTeX, mais j'ai déjà eu plusieurs requêtes là,
dessus...

Gaetan_Ryckeboer · Mai 15, 2002, 2:11

Nan, pas tout... juste la hiérarchie, le reste, on ignore..

spipjbcombes · Mai 16, 2002, 8:55

Hi Gaetan!

> Non, c'est pas pire que latex
> Mais c'est inconcevable de supporter tout docbook, je pense, c'est trop
> ambitieux.
Nan, pas tout... juste la hiérarchie, le reste, on ignore..

Mais qui ecrit ses doc en docBook??? Et j'ai mal compris l'idéee:
- faire un docBook-like dans spip pour entrer des trucs longs?
- importer du docBook?

Dans le 1er cas, <section titre=" "> est bien suffisant, AMHA, et on
garde le reste tel quel. Ou si vous preferez les {{{** Titre **}}}...
Mais pitié, pas de
<author><adress><affiliation><email>...</></></></> pour une bete
adresse email (ni de<section><title>Titre</title><para>rr
</para></section>, d'ailleurs)

Dans le 2eme, on peut se ramener au premier cas sans trop de problème
avec une petite feuille de style.

Yannick_Patois · Mai 16, 2002, 9:57

Salut,

> > Non, c'est pas pire que latex
> > Mais c'est inconcevable de supporter tout docbook, je pense, c'est trop
> > ambitieux.
> Nan, pas tout... juste la hiérarchie, le reste, on ignore..
Mais qui ecrit ses doc en docBook???

Moi

- faire un docBook-like dans spip pour entrer des trucs longs?

Pas vraiment, mais c'est interessant aussi.

- importer du docBook?

Plutot ca.

Dans le 1er cas, <section titre=" "> est bien suffisant, AMHA, et on
garde le reste tel quel. Ou si vous preferez les {{{** Titre **}}}...
Mais pitié, pas de
<author><adress><affiliation><email>...</></></></> pour une bete
adresse email (ni de<section><title>Titre</title><para>rr
</para></section>, d'ailleurs)

Plutot 'ignorer' intelligement ces tags lors de la conversions pour avoir
un document dont seules les entités les plus fondamenbtales sont
traduites (un peu ce qui est fait avec les conversion de Word, si j'ai
bien compris).

Dans le 2eme, on peut se ramener au premier cas sans trop de problème
avec une petite feuille de style.

<question de néophyte>Une feuille de style peut définir un nouveau
tag?</>

Mais de fait, ceci n'a de sens que si une nouvelle entrée 'articles long'
est proposé dans spip permetant de tirer partie d'infos de structurations.

Contrairement à ce que semblait dire ARNO*, je me suis trouvé pour ma part
hiers soir très limité par la hiérarchie spip pour mettre en ligne un
texte un peu structuré (un programme politique). Je n'avais que {{{}}}
comme titre et après on se débrouille avec {{}} mais c'est quand meme pas
ca...

Un type de doc permetant d'entrer des articles sur plusieurs pages web
avec une notion de structures sur au moins 3 niveau, ca serait bien...

Mais bien sur, je ne rale pas Si je voulais faudrait que je le fasse,
déjà... Et après on verait si ca interesse les développeurs de spip...

Yannick

spipjbcombes · Mai 16, 2002, 10:05

Hi Yannick!

Salut,

> Mais qui ecrit ses doc en docBook???

Moi

Moi aussi, ca fait 2...

> - faire un docBook-like dans spip pour entrer des trucs longs?

Pas vraiment, mais c'est interessant aussi.

> - importer du docBook?

Plutot ca.

> Dans le 1er cas, <section titre=" "> est bien suffisant, AMHA, et on
> garde le reste tel quel. Ou si vous preferez les {{{** Titre **}}}...
> Mais pitié, pas de
> <author><adress><affiliation><email>...</></></></> pour une bete
> adresse email (ni de<section><title>Titre</title><para>rr
> </para></section>, d'ailleurs)

Plutot 'ignorer' intelligement ces tags lors de la conversions pour avoir
un document dont seules les entités les plus fondamenbtales sont
traduites (un peu ce qui est fait avec les conversion de Word, si j'ai
bien compris).

Ce que je voulais dire, c'est d'éviter l'extremisme dans la
structuration. DB est parfois abusif pour ça... Hors de question de
demander à un luser de taper tout le bordel. Plutot qu'un DB-like, ce
serait un "Structured HTML".

> Dans le 2eme, on peut se ramener au premier cas sans trop de problème
> avec une petite feuille de style.

<question de néophyte>Une feuille de style peut définir un nouveau
tag?</>

Nope: DSSSL: DocBook => mix HTML + balises spip de hierachie, on revient
donc bien au 1er cas. on transforme un sect1 en {{{*** Le titre ***}}},
et on garde le reste de la feuille de style HTML telle quelle. Ca doit
pas être la mer à boire.

M'enfin je ne sais pas avec quels outils tu travaille. Je me réfère à
Jade et DSSSL; mais ça doit être possible avec XSL. Pour le reste, sais
pas, connais pas.

Mais de fait, ceci n'a de sens que si une nouvelle entrée 'articles long'
est proposé dans spip permetant de tirer partie d'infos de structurations.

Vi... Et faut pas être trop limité en ressources...

Mais bien sur, je ne rale pas Si je voulais faudrait que je le fasse,
déjà... Et après on verait si ca interesse les développeurs de spip...

Allez, au codage