> -----Message d'origine----- > De : Cedric Bosdonnat [mailto:[email protected]] > Envoyé : vendredi 12 août 2011 09:24 > À : [email protected] > Objet : Re: [fr-discuss] RE: [IHM] Nouveau design pour le styliste > > > Bonjour Jean-Yves, Olivier,
Bonjour à tous, > > On Thu, 2011-08-11 at 13:08 -0700, Olivier R. wrote: > > royerjy wrote: > > > > > > On ne code pas un document en fonction de l'aspect mais > en fonction de la structure, […] > > > > > > > Peut-être, mais les styles servent quand même à définir un > > aspect. C’est mieux de voir à quoi ça ressemble. > > Tu fais probablement partie d'une elite qui savent structurer un > document... mais je suis certain qu'il ne s'agit pas de la > majorite des utilisateurs. > > Voir a quoi ressemblent les styles doit aider les utilisateurs a les > reutiliser un max... d'ailleurs pourquoi MSO 2007+ ont fait ca sinon > pour faire utiliser les styles? Peut-être. Si ce n'est pas gênant, pourquoi pas ! Mais quand on n'est pas dictateur (comme les publicitaires qui ont dévoyé le Web) on doit permettre au lecteur de choisir sa vision du document. Ceci n'est autorisé que par des styles aux noms normalisés mais aux propriétés aux goûts de chacun. Entre ceux qui ne savent écrire qu'en LaTex avec un éditeur de texte sans contrôle avant la compilation et ceux qui veulent voir avant de choisir le style, il faut trouver des compromis. Récemment, sur les listes LibO, un contributeur demandait le mode affichage "Normal" de MS WW, dans lequel le nom du style s'affiche en marge. C'est effectivement très pratique pour un contrôle de qualité de la structure du document. > > > royerjy wrote: > > > > > >> > En ce qui concerne les styles : > > >> > — il y a trop de styles de puces (20 !), quelques-uns > > >> devraient suffire ; > > >> > — il y a trop de styles de numérotation (20 !) ; > > > > > > Ce n'est pas le nombre qui compte, c'est leur structure à > repenser. Il > > > faudrait avoir une idée des intentions de ceux qui ont > inventé ce truc > > > pour tenter de bien exploiter. > > Il me semble t'avoir deja dit qu'on se fout completement des > intentions de celui qui a pondu ca, parce que: > * il n'est probablement plus la > * ca semble completement contre-intuitif Sauf s'il avait eu un trait de génie et que nous passions à côté... > > > L’idée, c’est de rendre la gestion des styles abordable > pour le néophyte, > > pas de le noyer sous un déluge de choses. Du reste, il sera toujours > > possible de définir ce dont on aura besoin. Enfin, dans un > document, il vaut > > quand même mieux éviter de multiplier les styles à l’envi. > Un certaine > > cohérence graphique rend la lecture plus claire. > > +1 Oui, mais ce n'est pas en montrant l'image du style avant de le choisir que l'on obtient ce résultat. Cela peut parfois être une cause d'erreur, car des styles aux fonctions différentes peuvent avoir, à un moment donné, le même aspect visuel ou des aspects voisins (par exemple : "Corps de texte" et "En-tête de liste" ont exactement le même aspect, mais jouent des rôles différents). Seul le nom du style est donc important, puisque le reste se modifie facilement à tous les stades de l'exploitation du document. Si la mise en forme aide à trouver le bon nom et non la bonne image, ce serait un plus. Je prêche pour que le rédacteur n'ait, à une position donnée, que la liste des styles pertinents à cet endroit, donc le moins de styles possible mais tous les styles utiles. En plus de masquer les styles inutiles pour le rédacteur, il serait encore mieux que cette liste soit dynamique en fonction de la position du point d'insertion dans le document. Avec nos processeurs actuels cela devrait être possible... pour la 4.0 ? > > > royerjy wrote: > > > En fait, ne s'agit-il pas de proposer un modèle par > défaut bien structuré > > > et d'aspect agréable ? Ce n'est pas du code... > > > > > > > Oui, c’est bien ce dont il s’agit. Il faut dire que les > modèles par défaut > > sont plutôt rebutants. L’apparence, ça compte, ne serait-ce que pour > > susciter l’intérêt. > > Je n'ai pas dit qu'il s'agissait que de code... et c'est pour > ca que je vous demande un coup de main. Bien compris... > > > royerjy wrote: > > > > > > Que ce soit par défaut pour donner l'exemple, pourquoi > pas, mais ce n'est > > > pas obligatoire. C'est un détail qui doit être facile à > régler à condition > > > que ce ne soit qu'une valeur par défaut. > > > > > > > C’est déjà le cas : il est possible de modifier la > > hiérarchie des styles par défaut. > > Oui mais si elle pouvait etre logique sans rien changer ca > serait plutot pas mal, non ? Absolument ! > > > royerjy wrote: > > > > > >> > — «En-tête de liste», c’est plutôt un titre, me semble-t-il ; > > >> > > >> bah... il est utile celui-la? > > > > > > Absolument, *c'est un point fort de LibreOffice* d'avoir > un tel style > > > prédéfini qu'il fallait créer dans MS WW, au moins > jusqu'à la version > > > 2000. > > > > > Il va falloir me dire a quoi il sert celui-la ;) > > > royerjy wrote: > > > > > > Cet objet doit exister dans un certain nombre de DTD. En > effet, une liste > > > comporte souvent un paragraphe d'ouverture et des > articles (items). > > Cette specificite n'existe ni dans la DTD HTML, ni dans les > schemas ODF > ou OOXML... est-ce si important que ca d'avoir un style predefini pour > ca ? Peut-on parler de DTD pour la HTML ? Très permissive ! L'équivalent existe sous des formes variées, par exemple dans la DTD Docbook : <http://www.oasis-open.org/docbook/xml/5.0b5/dtd/docbook.dtd> Extraits : <!ELEMENT itemizedlist (((title|titleabbrev)*, info?), (itemizedlist|orderedlist|...|annotation)*, (listitem)+)> (((title|titleabbrev)*, info?) sont optionnels et sont analogues au paragraphe d'ouverture de liste, qui est toujours optionnel, mais dans cette DTD on peut en mettre plusieurs. Passons sur tous les types de listes que l'on trouve à l'intérieur d'une liste de manière optionnelle, pour terminer par (listitem)+ qui, dans d'autres DTD si j'ai bonne mémoire, est demandé au moins 2 fois (ce qui semble logique) et non une seule comme ici (mais je n'ai jamais été très familier de cette syntaxe). Mais ceci n'est pas suffisant pour montrer l'intérêt d'un paragraphe distinct pour ouvrir une liste. Sauf pour des documents qui doivent faire l'objet d'un traitement automatique, ce qui n'est pas à prendre en compte dans les spécifications de base de LibreOffice, l'intérêt réside dans le confort de rédaction et dans l'automatisme de la coupure des pages tant que l'on produit des pages (sur papier ou sur écran). De même que pour un titre, "il ne se fait pas" de couper une page entre le paragraphe d'introduction d'une liste et le premier article de la liste. En ajoutant un paragraphe différent on obtient cet automatisme tout en ne demandant pas plus d'actions de la part du rédacteur. Après, il reste la question de savoir si on se permet de couper la liste ou pas ? Pour des documents de bureautique à petit tirage et de moins en moins imprimés, je privilégie la facilité de lecture et l'automatisme pour le rédacteur par rapport aux économies de surface, voire en transigeant sur les règles typographiques. Il en est différemment pour des ouvrages à fort tirage et de qualité, ce qui explique que les logiciels de PAO ou de rédaction technique offrent des fonctions supplémentaires. Le passage automatique d'un logiciel de rédaction à un logiciel de mise en page est automatique quand les styles sont cohérents. En concevant bien la feuille de styles, on gagne à tous les coups : à court terme en rédigeant rapidement et en laissant la machine se débrouiller avec les coupures de page sans avoir à s'en inquiéter et à contrôler, très éventuellement à long terme, en permettant des conversions automatiques et en donnant de bons réflexes aux rédacteurs. Désolé d'être si long, mais il faut parfois entrer dans le détail pour expliquer. Bon week-end. Jean-Yves ROYER -- Envoyez un mail à [email protected] pour savoir comment vous désinscrire Les archives de la liste sont disponibles à http://listarchives.libreoffice.org/fr/discuss/ Tous les messages envoyés sur cette liste seront archivés publiquement et ne pourront pas être supprimés
