Journal Outils pour écrire un livre

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
22
5
mai
2021

Bonjour-nal,
Dans un passé un peu lointain, j'ai écrit deux livres : "Atelier Drupal 6" et "Atelier Drupal 7". Je les ai écrit avec In-Design car une personne qui connaît très bien cet outil m'a aidé.
Je me suis mis dans la tête d'écrire "Atelier Drupal 9" avec un outil libre et open source. Ces deux derniers jours, j'ai exploré plusieurs solutions, j'aimerais vous les exposer.

Tout d'abord, pour ce livre, voici mes exigences :
- J'ai une quantité phénoménale de copie d'écrans :), plus de une par page en moyenne (cela peut-être des petites zones de l'écran), donc, il faut que ça soit très rapide à insérer. Un simple Copier/Coller serait parfait.
- Je privilégie le rendu PDF/EPUB. Il faut pouvoir gérer les coupures de pages : si je mets un explication sur une image, il ne faut pas que l'image soit sur la page suivante. Tant mieux si je peux générer du HTML, mais ce n'est pas ma priorité.
- Pour le style, je voudrais quelque chose de moderne et épuré. J'aimerais pouvoir me baser sur un modèle existant qui me convient. Je ne suis pas graphiste, je ne veux pas passer trop de temps là-dessus et pouvoir utiliser quelque chose de déjà fait.
- Sinon, il me faut les trucs classiques pour un bouquin, table des matières, éventuellement index, haut de page avec numéro et chapitre, etc.
- Enfin, je ne veux pas trop me prendre la tête avec l'outil. Écrire un livre est déjà très long, alors, j'aimerais ne pas passer trop de temps à apprendre à utiliser le logiciel.

Les pistes que j'ai exploré :
Scribus
Ayant utilisé InDesign, je me suis naturellement tourné vers Scribus. C'est un très bon logiciel, je l'ai vraiment trouvé agréable et il est très facile de gérer les images.
Ce qui m'a ennuyé, c'est la gestion des styles, et l’enchaînement Texte/Images. Mais c'est la solution que je privilégie aujourd'hui.

Libre Office Writer
Et oui ! Après tout j'y suis très habitué et c'est assez facile de gérer les styles et d'insérer les images.
En fait, j'ai fait un essai et le plus gros problème que j'ai est que le rendu des polices a un crénelage, cela n'est vraiment pas terrible. En plus, sur le même système, j'ai beaucoup moins de polices disponibles sur Writer que sur Scribus !!
Je ne jette pas la solution, ce n'est peut-être que de la configuration. Je la garde sous le coude.

Sphinx/Readthedocs
Ici, il s'agit d'écrire sa documentation et, ensuite, tout est généré automatiquement selon un modèle. J'ai particulièrement aimé celui-là. Cependant, je n'ai pas trouvé de solution simple pour ajouter des images par Copier/Coller, je dois d'abord les enregistrer sur le disque et écrire le nom du fichier ensuite dans le code.
Je n'y ai passé que 2 ou 3 heures, peut-être que je dois aller plus loin, mais j'ai l'impression que ça va pas être facile de générer un PDF comme il faut avec les bonnes coupures de pages.
Il y a aussi d'autres outils du même type, comme Asciidoctor ou Gitbook, peut-être sont-ils plus adaptés.

Lyx/Latex
Lyx est un GUI pour Latex. Je l'avais déjà essayé il y a quelques années et il n'a pas beaucoup changé. L'insertion d'images est très simple.
Après, je ne connais pas du tout Latex, je ne sais pas si c'est le bon outil pour moi, si on peut vraiment gérer facilement la mise en page, si l'export PDF est simple.
J'ai un peu peur de mettre le doigt dans un truc qui me prend plus de temps à configurer/apprendre que d'écrire le livre !

Voilà ! Si vous avez un avis,une expérience ou des ressources (modèles/solutions) à partager avec moi, ça serait top !
Je ne manquerais pas de vous faire un retour d'expérience quand le livre sera écrit :)

  • # Avec Drupal !

    Posté par  . Évalué à 6.

    Sur la couverture, « écrit avec Drupal », ça en jetterait !

    https://www.drupal.org/docs/8/core/modules/book/overview

    Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr

    • [^] # Re: Avec Drupal !

      Posté par  (site web personnel) . Évalué à 3.

      Je connais trop bien le module pour savoir que ça n'est pas adapté pour moi :)
      Mais bon, toute la doc Drupal est écrite avec !!

  • # Emacs drag n drop

    Posté par  . Évalué à 5.

    Salut, pour la solution Sphinx, avec Emacs, il existe des plugins pour pouvoir glisser-déposer une image dans le document et écrire la balise correspondante. Pour org-mode: https://github.com/abo-abo/org-download et pour markdown j'ai trouvé: https://github.com/mooreryan/markdown-dnd-images (peut-être y en a-t-il d'autres).

    Je me vois mal rédiger un long document sans Emacs :)

    J'ai aussi vu passer cet article qui parle de comment améliorer le rendu de PDF et ePub avec Pandoc (et du Latex): https://learnbyexample.github.io/customizing-pandoc/

  • # Latex

    Posté par  (site web personnel, Mastodon) . Évalué à 8. Dernière modification le 05 mai 2021 à 10:41.

    Petit retour d'expérience sur Latex, que j'utilise avec un mélange de Kile et Vim :

    • ça demande un apprentissage, et il y a parfois voire souvent besoin de chercher sur le net, donc ça peut être exclus d'après tes critères
    • il y a des erreurs de compilations, ça peut taper sur les nerfs quand on ne sait pas d'où ça vient, mais si tu sauvegardes/compile régulièrement, tu devrais les voir suffisamment tôt pour trouver le problème.
    • il accuse son age, et n'est pas toujours très intuitif (les erreurs peuvent être cryptiques, il faut activer Unicode et les paquets qui correspondent à ce que tu veux avant que ça soit agréable à utiliser),

    Ça c'est pour les mauvais côtés maintenant les bons :

    • le résultat est souvent très (très très) bien, et correspond aux normes typographiques
    • c'est du texte, ça se sauvegarde facilement et tu peux versionner sans problème
    • c'est du texte, tu peux utiliser tous les outils standards pour faire des modifications, tu peux faire un script qui t'importe automatiquement toutes les images d'un répertoire si ça t'arrange pas exemple.
    • ça s'exporte dans n'importe quoi (PDF, ePub, HTML, etc.). Avec Pandoc tu peux très certainement en faire du RST voire du ODT, donc possibilité de changer de train si tu changes d'idée.
    • une fois que t'as compris le truc, ça te fait une grosse partie du boulot (tout ce qui est références, figures, table des matières, numérotation, etc. est fait automatiquement et dans les règles de l'art, et ça s'adapte relativement facilement à tes besoins)
    • une fois que t'as compris le truc, tu te concentres sur le contenu, la mise en page est gérée en grande partie automatiquement, et tu ajustes comme tu l'entends vraiment à la fin
    • il y a une grosse communauté et beaucoup de ressources/paquets/thèmes
    • c'est utile à connaître, ça peut servir pour faire des présentations, pour écrire des formules mathématiques, d'autres livres à l'avenir

    Sphinx est super pour de la doc (je l'utilise) mais ça ne serait pas mon outil de choix pour un livre. Scribus j'avais utilisé à ses début, c'était déjà bien et je pense que c'est super aujourd'hui, mais je l'utiliserais plutôt pour un dépliant ou un magazine.

    Bref, pour un livre je choisirais très probablement Latex, mais c'est un choix qui demande un certain investissement (qui vaut le coup sur le long terme à mon avis), il n'est pas forcément le bon pour tout le monde (et puis je suis développeur).

    • [^] # Re: Latex

      Posté par  . Évalué à 3. Dernière modification le 05 mai 2021 à 11:00.

      il faut activer Unicode

      Ou utiliser un moteur plus récent comme XeLaTeX. La déclaration de l'encodage du fichier source n'est plus nécessaire. L'utf-8 est généré nativement. Ça simplifie le préambule d'autres directives dont on ne comprend plus bien le concept de nos jours comme \usepackage[T1]{fontenc}

      il accuse son age, et n'est pas toujours très intuitif

      Oui, surtout quand on commence à écrire en TeX. Ce qui arrive forcément quand on progresse dans la personnalisation des modèles.

      Bref, pour un livre je choisirais très probablement Latex, mais c'est un choix qui demande un certain investissement (qui vaut le coup sur le long terme à mon avis), il n'est pas forcément le bon pour tout le monde (et puis je suis développeur).

      De même, surtout quand on a déjà fourni cet investissement une première fois ;-) Aumoins, la sauvegarde des sources ne plante jamais et est très rapide, contrairement aux wysiwyg et la compilation avec l'option draft est rapide et très pratique.

    • [^] # Re: Latex

      Posté par  (site web personnel) . Évalué à 2. Dernière modification le 05 mai 2021 à 11:13.

      Je recommande LyX comme frontend à Latex. Ça permet de bénéficier de tous les avantages de Latex avec beaucoup moins de verbosité (pas de "\itemize", "\tabular", etc.), moins de risque de typo et des fonctionnalités utiles (aperçu des images, table des matières, etc.).

    • [^] # Re: Latex

      Posté par  (site web personnel) . Évalué à 2.

      J'en reves de me lancer dans Latex mais je manque de temps

      A une époque j'avais commencé à apprendre et avec quelques scripts tu pouvais même générer un index automatique car il est facile d'extraire une liste de mots de la corriger manuellement puis de modifier les sources pour qu'après il te génére l'index en fin de document.

      J'en suis au 3eme ouvrage au moins sur Latex mais comme tout les jours je bosse avec LibreOffice …le passage est difficile

      Sinon fait gaffe dans tes recherches Google sur Latex … ça dérape très vite :)

    • [^] # Re: Latex

      Posté par  . Évalué à 5.

      J'ai appris LaTeX il y a 15 ans, et je ne regrette absolument pas. J'ai même développé un certain éditeur LaTeX.

      Par contre maintenant je recommande plutôt ConTeXt, un cousin (avec la même base TeX). C'est plus simple à apprendre, et plus flexible. Pour un livre ou pour un CV, c'est ce que je recommande en tout cas.

      Voir le site http://tug.org/ pour tout ce qui concerne l'univers TeX.

  • # txt2tags

    Posté par  . Évalué à 5.

    Ça ne sera peut-être pas adapté pour ton usage, mais moi j'utilise ça, qui est plus expressif que markdown, qui est facilement customisable pour créer ses propres balises, mais qui ne fera pas forcément tout ce dont tu auras besoin :

    https://textallion.sourceforge.io/

    C'est un préprocesseur pour LaTeX et du HTML, donc une fois que c'est dedans, on peut toujours s'en sortir et on n'est pas bloqué dans un format illisible ou ingérable. Mais si tu as beaucoup d'images, à coller, retailler, modifier en temps réel, un outil graphique tel que LibreOffice sera probablement plus adapté (sinon ça va faire des coupures d'images et / ou des espaces vides).

    Avec peu d'images à gérer (dont on peut définir la taille avec une balise, au coup par coup), ça passe et c'est très pratique au final d'avoir le bouquin sous forme de balises.

    « Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher

  • # Polices disponibles

    Posté par  . Évalué à 5.

    Si tu as beaucoup plus de polices disponibles pour Scribus que pour LibreOffice, c'est que Scribus utilise des polices qui ne sont pas rangées dans les endroits standard.

    Pour l'affichage des polices, je ne vois de crénelage chez moi. Sur quelle police vois-tu ça et avec quelle version de LibreOffice ? Dans LibreOffice même ou bien sur l'export PDF ?

    Writer peut utiliser des polices TrueTpye, OpenType et Graphite.

    • [^] # Re: Polices disponibles

      Posté par  (site web personnel) . Évalué à 2.

      La police, c'était Roboto et je suis sous LibreOffice 7.1.2.
      Après, je voulais te faire une copie d'écran pour comparer à Scribus mais je me suis rendu compte que Scribus faisait la même chose :)
      Donc, je retire mes critiques !

  • # Scribus et Libre Office

    Posté par  (Mastodon) . Évalué à 7.

    Cela fait très longtemps que je n'ai plus utilisé Scribus mais de mémoire, ce que j'avais retenu, c'est qu'idéalement, il faut dans un premier temps travailler son texte dans Libre Office y compris sur les styles.

    Une fois que la relecture (fautes d'orthographe et cie) est faite, on passe à la mise en page avec Scribus qui permet d'importer des textes odt avec leur mise en forme.

    Sinon, de mémoire, je pense que Kiki Novak aka Microlinux utilise Libre Office pour mettre en page ses livres qui comportent pas mal d'images. Donc, j'imagine que c'est une solution parfaitement viable.

    Surtout, ne pas tout prendre au sérieux !

    • [^] # Re: Scribus et Libre Office

      Posté par  . Évalué à 3.

      Please ! LibreOffice ça s'écrit en un seul mot. :-)

    • [^] # Re: Scribus et Libre Office

      Posté par  (site web personnel) . Évalué à 2.

      Tu penses que cela est écrit avec LibreOffice ?

      • [^] # Re: Scribus et Libre Office

        Posté par  (site web personnel, Mastodon) . Évalué à 1.

        Selon toute probabilité oui. Après je ne sais pas quel outil Eyrolles utilise pour ses bouquins.

        Mais les tapuscrits sont soumis dans un format traitement de texte.

        « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

      • [^] # Re: Scribus et Libre Office

        Posté par  (Mastodon) . Évalué à 3.

        Tu penses que cela est écrit avec LibreOffice ?

        Je viens de vérifier ce que Kiki Novak écrivait dans ceci.

        Et voici ce que je trouve:

        Le livre que vous tenez entre les mains a été rédigé à l'aide du traitement de texte LibreOffice Writer.

        Je vous laisse faire l'exégèse (mais si je devais donner mon avis, je dirais que cela tend à penser que la mise en page du livre n'a pas été fait avec LibreOffice).

        Surtout, ne pas tout prendre au sérieux !

    • [^] # Re: Scribus et Libre Office

      Posté par  . Évalué à 2.

      Bémol : Si le nombre d'images augmente, il faut une bonne machine,mais ça doit être vrai pour d'autres traitements de texte

      • [^] # Re: Scribus et Libre Office

        Posté par  (site web personnel, Mastodon) . Évalué à 1.

        C'est valable pour tous les traitements de texte en effet :-) Mais bon. De toute manière, il est essentiel d'avoir les images à la bonne taille par rapport à leur emplacement (donc pas d'image d'appareil photo sans redimensionnement par exemple).

        Après il faut voir sous quelle forme le bouquin est publié.

        « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

        • [^] # Re: Scribus et Libre Office

          Posté par  (site web personnel) . Évalué à 3.

          Dire que j'ai souvenir de pagemakers (?), un traitement de texte qui ressemblait un peu à de la PAO. J'avais fait un document vers ~2000, le truc avec une ou 2 photos scanné par page. word devenait fou (les images sautant de page seule prennaient 3 plombes). Pagemakers jouait avec des image réduite de 64 Ko et c'était hyper efficace. Tu jouais avec ton ruban de texte qui faisait des colonnes ou passaient autour des images. Je trouve cela toujours plus efficace que les images plus ou moins flottantes au milieu du texte.

          "La première sécurité est la liberté"

    • [^] # Re: Scribus et Libre Office

      Posté par  (site web personnel, Mastodon) . Évalué à 1.

      C'est tout à fait ça.

      Cela dit, on peut tout à fait, ce que je fais, écrire un livre et le mettre en page avec Writer, c'est très très performant.

      De toute façon, dans l'optique d'être édité, c'est l'outil de la maison d'édition qui s'occupe de la mise en page et ça dépend des éditeurs.

      « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

      • [^] # Re: Scribus et Libre Office

        Posté par  (site web personnel) . Évalué à 2.

        Je vais m'auto-éditer :) et je vais diffuser en PDF.

        • [^] # Re: Scribus et Libre Office

          Posté par  (site web personnel, Mastodon) . Évalué à 9.

          Pense à l’accessibilité et donc pas de Scribus pour le texte et une version epub, plus accessible que le pdf.

          Ce que je ferais, je commencerais d'abord à écrire le bouquin avec Writer et surtout en utilisant les styles par défaut au maximum afin de pouvoir au besoin y adapter ceux d'un modèle qui te fait de l'œil (ne mets en forme qu'en passant par la volet latéral, perso j'ai viré la ridicule barre d'outils Formatage qui ne sert à rien). Ne perds pas de temps à configurer la position du texte (espacement, etc.) cela va dépendre de la mise en forme finale et de la police définitive et, bien sûr du format de diffusion.

          Si tu estimes nécessaire d'avoir les chapitres qui commencent sur une page, de paramétrer le style Première page, d'insérer un saut de page Avant avec le style de page Première page.

          Après tu pourras toujours modifier les styles.

          Je te suggère la lecture du bouquin LibreOffice c'est stylé au besoin. Je ne le trouve pas très bon, il est très (trop ?) axé sur l'impression et la traduction est faite par des gens qui ne connaissent pas grand chose à la typographie, mais il y a tout de même des tas de choses intéressantes sur la typographie.

          Cela dit, si le livre ne doit pas être imprimé, pense à une version pdf qui tient compte de ce facteur, notamment avec la numérotation des pages et pas de pages blanches.

          Et, pour la version epub, ne te préoccupe pas trop des coupures de mots et des espace inter-lettre et inter-mots, voire, pas du tout.

          Une autre ressource sur le savoir typographique, c’est le site d'Alain Hurtig, l'Outil typographique. Le site est moche et, visuellement n'a pas bougé depuis le début ou presque (il a plus de vingt ans, le site). Mais les contenu est hyper intéressant.

          Bref, en gros commence par écrire avec l'outil d'écriture à ta main en tenant compte du fait que l'écriture numérique n'est nullement figée. Le reste viendra plus tard.

          « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

  • # LibreOffice c'est bien

    Posté par  (site web personnel) . Évalué à 10. Dernière modification le 05 mai 2021 à 11:14.

    Bonjour,

    J'ai écrit le livre "Scripting Python sous linux" ( Editions ENI)

    Avec libreoffice version 6.x, le PDF fait 448 pages A4 et 6,3 mo je n'ai pas énormément d'images écrans il y a 80 illustrations (en N&B), par exemple une annexe décrit pas à pas la création d'une machine virtuelle debian en 32 images.

    La version papier fait 763 pages format Livre Broché 17x21 ( Message : j'envoie une dédicace manuscrite a tout les lecteurs qui en feront la demande …)

    Si cela peut t'aider voici comment j'ai procédé :

    Les styles LibreOffice étaient imposés par l'éditeur, par cohérence avec l'équipe chargé de la photocompo (des vrais pros).

    Mais ces styles je les ais un peu adaptés et modifiés en fonction de mes besoins.

    Pour cela j'ai créé un modèle avec ces styles et notamment pour avoir par défaut l'ancrage des images "Comme un caractère", c'est plus facile pour moi.

    Ensuite un document odt par chapitre, soit 19 docs dans mon cas plus quelques autres …
    Et un "document maître" (suffixe .odm)

    J'ai du apprendre ce qu'était un document maître sous LibreOffice mais la communauté et les infos ne manquent pas

    A vérifier mais ce document doit partir d'un modèle ensuite il faut prévoir quelques pages pour le titre, la table des matières, l'index des figures/illustrations etc …
    Ensuite tu lies les documents dans l'ordre des chapitres.

    C'est une opération pas facile mais une fois terminée, tu peu travailler sur chaque chapitre sans problème, et de temps en temps tu édites ton document maître (DM) ce qui te permet de faire les mises à jours de la table des matière et des illustrations.

    Ce DM permet aussi d'imprimer la totalité, de générer un PDF, faire des recherches etc … comme sur un document unique.

    En fonction de la puissance de ta machine la mise à jour de ce DM peut prendre un peu de temps (des secondes …)

    Pour la gestion des figures et illustrations je te conseille d'être très rigoureux sur le nommage des figures, dans mon cas c'était imposé car même si les images étaient dans les documents de chapitres, je devait aussi les fournir dans un répertoire à part.

    le nommage était de la forme : CHAPITRE EI No_Ordre_dans_le_chapitre Légende

    Exemple :
    Légende = 03EI02 Bloc de code
    Fichier = 03EI02_bloc_de_code4.png

    J'ai du modifié le formattage par défaut de l'index des illustrations pour obtenir qq chose comme

    03EI02 Bloc_de_code …………Chapitre : 3.2 Page : 19

    Cela permet de voir les images qui ne sont pas correctes en légende et de les retrouver facilement

    Tu peu aussi avoir des stats sur le document final (nombre de mots, de caractères etc …)
    Une fois par mois je devais fournir des informations de ce style à mon éditeur, et j'ai fini par écrire un script python qui me génére un tableau (1 ligne = 1 chapitre) qu'il suffit de copier dans une feuille de tableur et de modifier manuellement les %ages de complétions.
    Car de plus il y a une limite technique sur le nombre de pages et de caractères maximale sur la version papier et dans mon cas je devais fournir un manuscrit de 250 000 caractères minimum.
    Au début j'avais peur du minimum, mais très vite j'ai eu peur du maximum :) j'ai du faire des choix …

    Un truc quand tu dois gérer beaucoup d'images écrans, je te conseille de créer un tableau avec une seule colonne, comme cela tu peu plus facilement gérer les espacements les centrages et aussi les légendes en dessous de chaque image.

    je ne sais pas si c'est une bonne pratique par contre …

    Petit truc aussi pour les portions de codes : je mettais en commentaire le fichier correspondant, cela m'a permis de faire un recensement des sources présents dans les documents et de les extraire … et il faut penser aux lecteurs qui veulent retrouver le fichier correspondant.

    Ex : 

    #fichier : f_spe/with1.py

import math
import time

class timing():
...

    En fonction du document final (papier, PDF etc …) pas la peine de garder des images de 4k, avec image magick + quelques scripts il est facile d'unformiser tout cela

    Et aussi je te conseille de gérer les sources (1,2 Go tout de même) avec git qui est incroyable car tu peu même voir les différences entres documents odt entre 2 commits, cela nécessite un petit peu de paramètrage mais c'est possible.

    Après pour ton problème de police, il faut peut être faire un peu de recherche pour voir quelles polices posent problèmes, mais les PDF que je générait n'avait pas de problème, j'ai du aussi l'éditer 2 ou 3 fois sur des imprimantes laser, sans soucis.

    Bref si tu as des questions n'hésite pas à me contacter.

    • [^] # Re: LibreOffice c'est bien

      Posté par  . Évalué à 1.

      Est-ce que tu n'aurais pas pu tout avoir dans le même document plutôt que d'avoir une doc par chapitre plus le document maître ? Ce n'aurait pas été plus simple à gérer ?
      Vu que tu dis que tu n'as pas beaucoup d'images et que le pdf fait que 6 Mo, j'imagine que travailler sur le doc entier n'aurait pas poser de problème particulier (mais je me trompe surement).

      • [^] # Re: LibreOffice c'est bien

        Posté par  (site web personnel) . Évalué à 5.

        je pensais la même chose au début, mais ne fait j'ai découvert la puissance du document maître. C'est vraiment top

        J'ai mis un peu de temps pour certaines choses, comme insérer un titre avant pour la génération papier ou PDF, qui en fait sont très simple a faire une fois que tu as compris.

        Coté boulot j'ai déjà fait des documents de plus de 100 pages, libreoffice tient le choc sans problème.

        Mais comme je le disais les éditeurs ont des contraintes liées à l'impression papier, comme je connais un peu le métier d'imprimeur cela me surprend pas.

    • [^] # Re: LibreOffice c'est bien

      Posté par  (site web personnel) . Évalué à 2.

      Merci beaucoup pour tout ces bons conseils ! Et aussi pour la proposition d'aide :) J'espère que pour toi, la rédaction et la vente de ce livre sont une réussite !
      Juste une petite question, tu dis :
      le PDF fait 448 pages A4
      et
      La version papier fait 763 pages 17x21
      Du coup, tu passes d'un format à l'autre sans problème ? Tu n'as pas des coupures dont tu ne veux pas ?

      • [^] # Re: LibreOffice c'est bien

        Posté par  (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 05 mai 2021 à 18:13.

        Si tu conçois correctement tes documents (donc les styles, on y revient toujours), surtout si tu saisis sans mettre des lignes blanches comme l'a fait remarquer Jean-Baptiste ni de sauts de page forcés juste parce que c'est plus-mieux-bien comme ça, tu ne dois pas avoir ce genre de problème.

        « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

      • [^] # Re: LibreOffice c'est bien

        Posté par  (site web personnel) . Évalué à 8.

        Le public visé est assez restreint : les sysadmin qui veulent se mettre à python
        Mais cela peut convenir a tout geek qui connait un petit linux, n'a pas peur de la ligne de commande et qui veut se mettre a python.

        C'est mon premier livre et je l'ai écrit comme le livre que j'aurais aimé lire à une époque :)

        A l'heure actuelle il s'est vendu 330 exemplaires papier et j'estimes à 250 versions electronique, je me bases sur mes relevés des ventes.

        La rédaction et l'équipe que te fourni ENI c'est génial, tu es entouré de pro, on ne s'est jamais vu, et c'est dommage, mais j'ai vraiment été surpris par tout le monde.

        les relecteurs a mon avis connaissant l'informatique et même plutot bien le sujet, peut être à force de relire des ouvrages :) d'ailleurs

        Sinon pour le passage de format, c'est le boulot de l'équipe de photocompo et honnêtement c'est bluffant, normalement il te présente un exemplaire papier que tu dois corriger.

        Mais A cause du COVID, le livre est sorti Juin 2020, j'ai du faire les corrections sur PDF et à part le temps un peu court, tu as une semaine pour relire …

        Et je n'ai eu que quelques remarques à faire sur des coupure de fins de pages car je voulais conserver la logique de certains scripts, en évitant de couper une fonction en 2 par exemple.

        Pour moi cela a été une aventure formidable, et je me suis eclaté à faire cet ouvrage, même si à la fin la phase de production est assez intense car tu as peu de temps et c'est pas la partie la plus sympa (surtout la relecture).

        Sinon quel plaisir de recevoir un carton avec 5 exemplaires papier … et de voir son livre en vrai :)

        • [^] # Re: LibreOffice c'est bien

          Posté par  (site web personnel) . Évalué à 2.

          Je suis très content pour toi pour cette expérience qui semble avoir été positive.
          J'ai ressenti le même plaisir quand j'ai reçu mon stock de livres sur Drupal 6, sauf que c'était une palette avec 200 livres dans des cartons :)

          • [^] # Re: LibreOffice c'est bien

            Posté par  (site web personnel) . Évalué à 2.

            Ah OK :)

            C'est toi qui t'es chargé de les vendre ?

            Sinon j'ai vu tes livres sur Framabook, la typo le format c'est nickel

            En fait tu cherches a basculer la totale en libre …

            Comment cela se passe avec Framabook tu dois produire le contenu jusqu'au PDF ?

            • [^] # Re: LibreOffice c'est bien

              Posté par  (site web personnel) . Évalué à 3.

              Oui, je faisais mes petits paquets et j'allais à la poste :) J'ai adoré le faire ! En plus, quand les clients voyaient qu'ils avaient à faire directement à l'auteur, me faisaient beaucoup de retours, voir me donnaient du boulot…

              Pour Drupal 7, lorsque j'ai décidé de passer au Framabook, j'avais déjà écrit une bonne partie du livre sur In-Design… Donc, on a décidé de ne pas revenir en arrière et c'est moi qui ai fait la mise en page. Après, ils m'ont fait la correction, ce qui est un gros travail…

              • [^] # Re: LibreOffice c'est bien

                Posté par  (site web personnel) . Évalué à 3.

                Courageux … pour la livraison

                Par contre c'est top d'avoir eu du retour en direct live …

                C'est un peu le truc que je regrette, c'est de ne pas avoir eu beaucoup de retour.

                Mais bon, on est dans une période "bizarre"

    • [^] # Re: LibreOffice c'est bien

      Posté par  (site web personnel, Mastodon) . Évalué à 5.

      LibreOffice permet une réelle écriture au fil de l'eau en structurant le texte en cours de route et c'est extrêmement précieux. Et quelle liberté pour écrire ! On peut réorganiser le texte comme on veut avec la navigateur et avoir des styles d'images et de cadre pour les placer automatiquement au bon endroit sans qu'ils ne bougent.

      Je me suis essayée à Latex mais bon, soit on utilise un éditeur Lyx et c'est, ben assez moche et pas très personnalisable, soit on se coltine les champs à taper. Autant je le fais en Markdown dans LibreOffice pour des textes courts, autant je ne me vois pas le faire avec un document en Latex dans un éditeur de texte.

      « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

      • [^] # Re: LibreOffice c'est bien

        Posté par  (site web personnel) . Évalué à 3.

        Merci pour tout tes messages Ysabeau, je ne répond pas à chacun d'entre eux mais j'ai téléchargé les modèles et documents que tu as mis à ma disposition…

  • # Lyx en un clic

    Posté par  . Évalué à 3. Dernière modification le 05 mai 2021 à 11:21.

    J'utilise de temps en temps Lyx, sans jamais avoir a taper du Latex. À moins d'avoir des trucs très compliqués à mettre en page ou à taper, tu ne devrais pas non plus avoir à taper de Latex.
    Tous les avantages sont ceux de Latex, la courbe d'apprentissage en moins.
    L'export PDF est très simple, en un clic.
    La mise en page se gère avec des modèles, il y en a beaucoup, mais tu devras peut-être en adapter un (j'en sais rien, tout dépend de ce que tu veux), ce qui n'est pas forcément simple (j'en sais rien, tout dépend de ce que tu veux — bis). Si un modèle existant te convient, Lyx sera parfait.
    La meilleure réponse concernant Lyx viendra de ses utilisateurs-développeurs sur les forums Lyx.org (il y a des listes en français, les archives sont sur GMANE). Quelques copies des pages de tes livres précédents devraient leur permettre de t'indiquer le modèle qu'il te faut.

    • [^] # Re: Lyx en un clic

      Posté par  (site web personnel) . Évalué à 2.

      Oui, j'ai mieux regardé ce matin et LyX me fait de l’œil :) Je ne vois pas trop ce qui me manque…
      Tu les trouves/cherches où tes modèles ??
      Bon, finalement, ce journal me donne plein de billes, mais ça va être encore plus dur de me décider :)

      • [^] # Re: Lyx en un clic

        Posté par  . Évalué à 2.

        La plupart des modèles bien faits sont livrés avec Lyx. Le wiki en recense d'autres, mais c'est un wiki, donc pas à jour. On peut en trouver d'autres via le CTAN.
        MAIS comme c'est difficile de s'y retrouver dans cette jungle nouvelle, j'insiste pour que tu poses des questions sur la liste Lyx française.

        NB : la version de développement de Lyx permet d'exporter en epub, ça sortira dans la 2.4.

        J'ai hésité à te conseiller aussi LibreOffice avec un document-maître (indispensable) qui est une très bonne solution, et j'approuve les conseils des autres ci-dessus. Choisir Lyx ou LibreOffice est une affaire de préférences.

  • # overkill

    Posté par  (Mastodon) . Évalué à 3.

    Suis-je le seul à trouver que toutes les solutions proposées plus haut sont overkill ?

    Je ferai du markdown ce qui te donne le choix de l'éditeur de texte, avec aux choix du formatting immédiat ou avoir le rendu sur une vue de côté.

    Pandoc supporte les commandes latex \newpage \pagebreak

    Tu trouveras une foultitude d'outils générant automatiquement un index pour un document markdown sur les forges les plus connues.

    • [^] # Re: overkill

      Posté par  . Évalué à 5.

      Pourquoi overkill ? as-tu déjà travaillé sur un livre ?
      Certes Markdown convient pour la rédaction, mais LibreOffice, Lyx ou Latex permettent de rédiger de façon plus pratique (au hasard : on saute facilement d'une partie à l'autre, on trouve les références dans une boite de dialogue, on peut changer le texte en fonction du rendu, la mise en forme est précise, … plein de choses encore).

      • [^] # Re: overkill

        Posté par  (Mastodon) . Évalué à 2. Dernière modification le 05 mai 2021 à 20:16.

        libreoffice, tu dépends de la version et des éventuels bugs qui y sont présents. Tu peux rédiger le même markdown avec une myriade d'éditeurs différents sans le casser. La plupart des frontends web pour git te l'interprètent ce qui fait que tu peux facilement commiter depuis un laptop, entrer dans un bus bondé et relire ton travail ou continuer la rédaction sur un smartphone soit directement sur la forge ou via un éditeur de texte/code.

        latex, c'est juste illisible avant interprétation. markdown c'est super lisible même sans éditeur qui te l'interprète à chaud et rapidissime à apprendre. Ça simplicité t'ôte l'envie de faire des trucs compliqués ce qui est parfait pour un livre. Et on parle d'un livre sur Drupal, pas d'une thèse de physique ou mathématique alors pas la peine de me sortir les histoires de formules mathématiques.

        Et je ne vois pas trop ce qu'il y a de compliqué à sauter d'une partie à l'autre dans markdown. Si tu titre bien tes sections ce n'est pas bien compliqué. Sans compter que tu peux aussi décider de séparer en fichiers par section et concaténer facilement quand tu veux.

        • [^] # Re: overkill

          Posté par  . Évalué à 10. Dernière modification le 05 mai 2021 à 21:07.

          Sérieux ? On parle d'un livre, un truc qui doit respecter un certain nombre de règles typographiques, où on change de police de caractère entre les titres, le corps du texte, les encarts, les notes de bas de page, les légendes des figures, tableaux et images, etc. Un truc qui a des pages numérotées, une table des matières qui indique les numéros de page, un truc qu'on peut imprimer et relier.
          Rien à voir avec le readme d'un logiciel sur gitlab ou avec une page web.

          Un traitement de texte bien foutu fait tout ça et bien d'autres choses. Et il le fait avec un seul logiciel, sans avoir besoin de construire sa propre usine à gaz en allant chercher des plugins, des scripts et des convertisseurs un peu partout sur le net pour ajouter telle ou telle fonction.

          Au fait comment fais-tu pour corriger une faute page 236 ligne 11 dans un texte en markdown ?

          • [^] # Re: overkill

            Posté par  (site web personnel, Mastodon) . Évalué à 6.

            Sans parler des sommaires, des index et des citations.

            « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

          • [^] # Re: overkill

            Posté par  (Mastodon) . Évalué à 2.

            On parle d'un livre, un truc qui doit respecter un certain nombre de règles typographiques, où on change de police de caractère entre les titres, le corps du texte, les encarts, les notes de bas de page, les légendes des figures, tableaux et images, etc.

            je pense que tu n'as jamais lu le manuel de pandoc.

            Ne me dis pas que tu utilises une police différente à chaque titre, l'horreur!

            Un traitement de texte bien foutu fait tout ça et bien d'autres choses. Et il le fait avec un seul logiciel, sans avoir besoin de construire sa propre usine à gaz en allant chercher des plugins,

            Genre c'est tellement bien fait que personne n'utilise de plugin pour le connecter à un gestionnaire de références bibliographiques?

            Au fait comment fais-tu pour corriger une faute page 236 ligne 11 dans un texte en markdown ?

            On parle d'un livre sur Drupal, rempli de sections, sous-sections, pas d'un roman.

            • [^] # Re: overkill

              Posté par  (site web personnel, Mastodon) . Évalué à 4.

              On parle d'un livre sur Drupal, rempli de sections, sous-sections, pas d'un roman.

              Ben justement, LibreOffice est fait pour ça. En fait, pour tout dire, son bouquin n'a même pas besoin de sections qui, dans LibreOffice, sont là pour avoir des mises en forme différentes, mais des chapitres, sous-chapitres etc. Et Writer est très fort pour ça et aussi pour la mise en forme. Et, en plus, c'est un outil qui facilite le travail de correction et de relecture.

              Sinon on peut avoir une police de labeur et une police de titraille, ce n'est pas une faute de composition et, bien sûr, il faut une police pour le code.

              « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

              • [^] # Re: overkill

                Posté par  (site web personnel) . Évalué à 3.

                Ah mon avis, il y a plusieurs bonnes solutions… Pandoc en est une, LibreOffice une autre, les deux semblent avoir fait leur preuve :)
                Chacune a ses avantages et ses inconvénients. Quelque soit celle choisie, il faut savoir l'utiliser correctement pour avoir un bon résultat :)

                • [^] # Re: overkill

                  Posté par  (site web personnel, Mastodon) . Évalué à 3.

                  Ben voilà.

                  Sinon, pour le code, le mieux, à mon avis, consiste à l'écrire dans un éditeur de texte et à le copier-coller dans Writer et là, tu utilises l'extension COOOoder pour la mise en forme : tu sélectionnes le code et tu choisis le langage dans la boite de dialogue de l'extension (tu la trouveras dans Outils -> Add-ons).

                  « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

                  • [^] # Re: overkill

                    Posté par  (site web personnel) . Évalué à 2.

                    Cool ! Pour le premier livre, pas de code, mais je garde cela sous le coude…

                  • [^] # Re: overkill

                    Posté par  (site web personnel) . Évalué à 3.

                    J'y ai joué, mais la procédure copier/coller est plutôt galère. Il faudrait pouvoir insérer dans LibreOffice Writer un fichier texte externe ou le résultat de l'exécution d'une commande, et la passer éventuellement vers coooder ensuite.
                    Car corriger un fichier script d'exemple, le vérifier, puis aller le copier/coller au bon endroit dans le doc LibreOffice et redire à coooder de le traiter… franchement pas pratique.

                    Pour mon bouquin sur Python, dont mon co-auteur s'est chargé de la mise en page, ça a été LaTeX. Les fichiers scripts et résultats d'exécution sont dans des fichiers textes. Pour certains scripts on a des balises qui permettent de les découper par parties insérées en différents endroits dans le document. Le fait de passer par une phase de compilation permet d'ajouter des étapes de préparation comme l'on veut, de se créer des macros, de les modifier si besoin, de changer des processus de production.

                    Ceci dit, ça demande de l'apprentissage, du temps, des ajustements (sur ce point, quelque soit le truc automatique, il faut pouvoir "tuner" pour le rendu final si on veut qq chose de clean). Et je confirme, pour nous c'est Dunod, mais l'accompagnement par des professionnels de l'édition et par un relecteur pointilleux (le français, mais aussi la compréhension) permet d'améliorer nettement le résultat.

                    Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

                    • [^] # Re: overkill

                      Posté par  (site web personnel, Mastodon) . Évalué à 1.

                      J'y ai joué, mais la procédure copier/coller est plutôt galère. Il faudrait pouvoir insérer dans LibreOffice Writer un fichier texte externe ou le résultat de l'exécution d'une commande, et la passer éventuellement vers coooder ensuite.

                      C'est vrai que le copier-coller est une opération extrêmement complexe.

                      Cela dit, plus sérieusement, on peut insérer des objets OLE donc des fichiers avec du code !

                      « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

                      • [^] # Re: overkill

                        Posté par  (site web personnel) . Évalué à 3.

                        C'est vrai que le copier-coller est une opération extrêmement complexe.

                        Mauvaise foi. Quand c'est l'inclusion de très nombreux extraits de code, en différents endroits, ce n'est pas «complexe», c'est comme je l'ai écrit «galère» lorsque tu modifies / testes / inclues et que tu dois faire des mises à jour. Tes besoins ne sont pas les miens, et pour un bouquin sur la programmation ou le système c'est mieux d'inclure des scripts que l'on peut tester de façon automatique.

                        Je regarderais la solution OLE (pour moi c'était une techno Windows, jamais creusé sous LO Writer).

                        Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

                        • [^] # Re: overkill

                          Posté par  (site web personnel) . Évalué à 2.

                          Bon, regardé la possibilité OLE, c'est géré comme un bloc dans un cadre, non pas comme un flux textuel externe inséré dans le document… pas utilisable pour mes besoins.

                          Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

              • [^] # Re: overkill

                Posté par  (Mastodon) . Évalué à 2.

                Ben justement, LibreOffice est fait pour ça. En fait, pour tout dire, son bouquin n'a même pas besoin de sections qui, dans LibreOffice, sont là pour avoir des mises en forme différentes, mais des chapitres, sous-chapitres etc. Et Writer est très fort pour ça et aussi pour la mise en forme. Et, en plus, c'est un outil qui facilite le travail de correction et de relecture.

                Je n'ai pas dis que Libreoffice ne peut pas le faire. Mais il n'y a rien qui bloque niveau markdown à ce niveau. Et accessoirement s'il te prends l'idée d'insérer les images au fur et à mesure, éditer un document dans une éditeur de texte ou dans libreoffice c'est une autre paire de manche niveau lourdeur d'utilisation. Il faut pas grand chose pour foutre un pc "grand public" en vrac avec libreoffice rien qu'avec l'utilisation mémoire.

                Sinon on peut avoir une police de labeur et une police de titraille, ce n'est pas une faute de composition et, bien sûr, il faut une police pour le code.

                Je ne vois pas en quoi c'est un frein à l'utilisation de markdown.

                • [^] # Re: overkill

                  Posté par  (site web personnel) . Évalué à 2.

                  Oh ! Mais tu es pénible toi :) (second degré)
                  Je m'étais enfin décidé à utiliser LibreOffice, et tu me mets le doute !
                  N'étant plus à une heure près, j'ai testé Pandoc avec VSCode et pour l'instant, je ne trouve que c'est pas mal du tout :)

                  • [^] # Re: overkill

                    Posté par  (site web personnel, Mastodon) . Évalué à 3.

                    Pense à la relecture et aux corrections ! Qui va s'en occuper ?

                    « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

                    • [^] # Re: overkill

                      Posté par  (Mastodon) . Évalué à 2.

                      Ça peut se faire depuis une version html/pdf/epub générée automatiquement à chaque commit.

                      • [^] # Re: overkill

                        Posté par  (site web personnel, Mastodon) . Évalué à 4.

                        Hum, c'est très loin d'être aussi pratique que la relecture-correction du texte directement avec ajouts de commentaires éventuels. Mais bon.

                        « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

                • [^] # Re: overkill

                  Posté par  (site web personnel, Mastodon) . Évalué à 2.

                  Sinon on peut avoir une police de labeur et une police de titraille, ce n'est pas une faute de composition et, bien sûr, il faut une police pour le code.

                  Je ne vois pas en quoi c'est un frein à l'utilisation de markdown.

                  Rien à voir avec markdown, mais tout avec ta remarque précédente ! Je soulignais simplement que ce n'est pas une erreur de composition.

                  Sinon, as-tu déjà écrit un bouquin soumis à relecture ? Utilises-tu LibreOffice couramment et bien ?

                  Ce que je sais de markdown, que j'utilise tous les jours c'est que c'est limité et assez chiant pour une écriture au fil de l'eau.

                  « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

                  • [^] # Re: overkill

                    Posté par  (Mastodon) . Évalué à 2.

                    Un livre entier non. Des documents de plusieurs pages devant être disponible et agréables à lire en html et pdf oui.

                    Au niveau de la relecture, je ne vois pas d'à priori négatif, tu génères le pdf quand tu veux. Ça semble compliqué à mettre en place la première fois mais en gros tu te fais un repo git avec ton texte et un répertoire avec les images, un makefile pour générer les diverses sorties et t'es bon. Tu peux utiliser des extensions tex/latex pour que pandoc "étende" markdown à quelque chose de plus performant/flexible sans être obligé de tout rédiger en latex.

                    Ceci est un exemple de livre opensource rédigé en markdown :
                    https://github.com/semaphoreci/book-cicd-docker-kubernetes

  • # Longévité

    Posté par  . Évalué à 10.

    Un critère qu’il peut être important de considérer (ou pas : ce n’est pas forcément pertinent pour tout le monde) est la stabilité à plus ou moins long terme de la solution choisie.

    Par exemple, ma thèse écrite en LaTeX il y a dix ans compile toujours parfaitement aujourd’hui avec la dernière version de TeXLive et produit la même sortie qu’il y a dix ans.

    À l’inverse, j’ai déjà été confronté à des documentations écrites il y a trois ou quatre ans avec Sphinx et qui ne compilent plus correctement avec les dernières versions, il faut soit mettre à jour la doc pour suivre l’évolution de Sphinx soit utiliser une version d’à peu près la même époque que le document original.

    Souhaites-tu pouvoir recompiler facilement ton document dans dix ans ou plus ? Si oui, je dirais que Sphinx est à éviter, LaTeX a un bon track record en la matière — pour les autres solutions, je ne sais pas.

  • # Question

    Posté par  (Mastodon) . Évalué à 1.

    Voilà ! Si vous avez un avis,une expérience ou des ressources (modèles/solutions) à partager avec moi, ça serait top !

    J'ai testé Lyx sur un projet de livre tout simple (du texte, sans images, notes ou rien de spécial). J'aimais bien l'idée du WYSIWYG en LaTeX et ça faisait un bail que je m'étais promis de tester LaTeX. Mais j'ai très rapidement buté sur des erreurs au moment de l'export, des trucs incompréhensibles même sur des choses aussi basiques que les guillemets typographiques (malgré, apparemment, des réglages corrects pour le FR). J'ai bien fait des recherches mais j'en suis sorti avec le sentiment que , Lyx comme LaTeX n'en valaient la peine (et ils le valent probablement) que si j'étais OK de passer je ne sais combien de temps juste pour tenter d'apprendre à les utiliser et si je comptais les utiliser beaucoup.

    Ce n'est pas mon cas : j’ai des besoins limités (je n’écris pas de trucs scientifiques) et je préfère écrire mes textes plutôt qu'apprendre à faire marcher un outil, surtout si j'en ai déjà d’autres à disposition, certes plus limités mais dont les limites ne me gênent pas et qui fonctionnent sans trop m'embêter ;)

    Perso, pour être opérationnel en quelques minutes sur le genre de bouquins dont tu parles, la première chose que je séparerais c'est la mise en page de l'écriture: l'une se fait après l'autre, pas simultanément (trop de risques de perdre beaucoup de temps à chaque edit dans ton manuscrit/tes images). Et, selon que je bosse sur une commande ou tout seul/auto-édité, j'utiliserais :

    • Un traitement de texte. Writer ou Word, pour rédiger et insérer mes images en tas sans me soucier de l'apparence du truc. Puis, si ce n'est pas l'éditeur qui s'en charge et que je doive le faire moi-même, je fignolerais la mise en page dans Word/Writer et si, et seulement si la mise en page basique qu'ils permettent d'obtenir ne suffisait pas, je passerais dans InDesign ou dans Scribus (mais lui je ne l'ai encore jamais utilisé, contrairement à InDesign). Mon but n'étant pas de gagner le prix Nobel de la mise en page la plus parfaite (selon qui ? Et pour en faire quoi ?), mais de produire un livre dont la mise en page soit assez bonne (lisible/pratique, et plaisante) sans pourtant devoir y passer des semaines (ou devoir passer ce temps à apprendre à utiliser/débugger un outil).
    • Un éditeur de texte + Markdown + pandoc (ou autre markup léger qui aurait ta préférence). Peu importe l'éditeur, du moment qu'il te convienne. Idéalement, un éditeur simple à prendre en mains avec un bon support de Markdown (et de Git ? Pour le versioning du manuscrit). Pour ce qui est de la mise en page, si je m’auto-éditais, je me ficherais un peu de la mise en page "papier" : pour moi, auto-édité signifie ebook avant tout avec éventuellement, pour la poignée d’amateurs, du POD et/ou un PDF. Là encore, la question reste : quel investissement de temps suis-je prêt à y consacrer, et pour quel retour espéré ? Mais même pour faire du print en tant qu'autoédité, je préférerais me tenir a Markdown, en rallongeant à peine la chaine d’outils :

    Markdown -> pandoc -> DOCX -> InDesign/Whatever -> Un joli livre imprimé.

    Parce que je connais et parce que mon but c'est d'avoir écrit ce livre, pas devenir un pro de la mise en page ;)

    • [^] # Re: Question

      Posté par  . Évalué à 4.

      Je ne comprends pas cette notion d'étape de mise en page : avec un bon logiciel de traitement de texte, on fait la mise en page avant, en choisissant un modèle. Ensuite on écrit et la mise en page est automatique. Elle peut ensuite être ajustée en modifiant un style, par exemple changer sa police de caractère, modifier l'interlignage, modifier les espaces avant et après, etc.

      • [^] # Re: Question

        Posté par  (site web personnel, Mastodon) . Évalué à 2.

        En fait, la mise en page elle intervient quand tu veux vu que tu utilises des styles et des modèles. Du coup, tu peux en changer en cours de route. Et, pour un document long, c'est pas trop le truc sur lequel se polariser pour commencer. Mais commencer sur un modèle défini qui n'est pas le modèle par défaut est, de toute façon, une bonne chose si ledit modèle est bien conçu.

        « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

      • [^] # Re: Question

        Posté par  (Mastodon) . Évalué à 2. Dernière modification le 05 mai 2021 à 15:07.

        Ça dépend de la complexité de ce que tu veux faire, ou de ton niveau d'exigence (les possibilités de mise en page d'un traitement de texte sont assez réduites en comparaison d'un logiciel dédié), mais aussi du workflow de ton éditeur, si tu en as un.

        Beacoup d'éditeurs vont te demander/exiger aue tu bosses avec leur propre modèle de doc Word. La plupart du temps c'est surtout pour obtenir un doc plus facilement exploitable dans leur workflow habituel (edits et relecture, pour ensuite envoyer le docx finalisé à la mise en page, dans ID par ex. edit; qui, lui aussi, est calibré pour utiliser le modèle Word de l'éditeur et ses styles personnalisés) : limiter les changements d'habitudes et donc le risque d'erreurs c'est gagner beaucoup de temps, donc du pognon. C'est aussi pour ça que c'est très utile d'utiliser des styles pour le formatage de ton texte plutôt que le formatage direct: plus facile a modifier/automatiser l'importation.

        Je n'ai connu qu'un éditeur non-amateur qui faisait tout (pas trop mal, d'ailleurs) dans Word, de l'écriture jusqu'à la mise en page finale. Mais le look de ses bouquins/soin apporté à la finition n'était pas son souci prioritaire et c'était 100% assumé ;)

        • [^] # Re: Question

          Posté par  (site web personnel, Mastodon) . Évalué à 1.

          Ça dépend de la complexité de ce que tu veux faire, ou de ton niveau d'exigence (les possibilités de mise en page d'un traitement de texte sont assez réduites en comparaison d'un logiciel dédié), mais aussi du workflow de ton éditeur, si tu en as un.

          Pas si réduites que ça quand tu vois ce que LibreOffice sait faire et ce qu'il fait naturellement qui est lus compliqué à obtenir avec un logiciel pure PAO. Writer est vraiment puissant.

          « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

      • [^] # Re: Question

        Posté par  . Évalué à 3.

        C'est à dire qu'il y a mise en page et mise en page… Dans le cas présent, le rendu final peut sans doute se faire automatiquement, de manière cohérente et… monotone peut-être ? (voir les livres de chez packt pour un exemple de monotonie).

        Dans l'édition de livre d'art, par exemple, la mise en page est faite à la main, pour équilibrer les masses et même dynamiser visuellement le passage d'une page à une autre , et peut parfois aller jusqu'à bricoler les approches de lettres pour éviter qu'un "ff" ne gratte les pieds du "p" de la ligne du dessus ;). Et ça, ben tu peux pas le faire en amont.

        Bon, c'est un autre genre d'objet, et dans les deux cas, les styles sont de mise. Mais je voulais dire que, non, la mise en page, ce n'est pas juste des enchaînements rigoureux, ça peut être aussi une passion !

    • [^] # Re: Question

      Posté par  . Évalué à 2. Dernière modification le 05 mai 2021 à 17:59.

      C'était avec quelle version de Lyx ? quand ? sur quel système ? avec quel layout ?
      Je ne rencontres pas tes problèmes mais je n'utilises (depuis 20 ans) que des layouts de base et des paquets Debian.

  • # LibreOffice : quelques conseils

    Posté par  . Évalué à 7.

    Comme Ysabeau l'a déjà écrit je conseille vivement de configurer l'interface de LibreOffice Writer dans le mode "volet latéral" qui masque la barre d'outils de formatage pour ne jamais être tenté de cliquer sur bouton gras ou italique ou autre du même genre. Ce genre de chose se fait avec un style de paragraphe ou de caractère. Pour un document long, ce genre de méthodologie est fondamentale pour automatiser la maximum de choses.

    Pour le choix du modèle, vérifier qu'il est bien fait, en particulier que les styles de titre ont bien un style de suite en corps de texte sinon tu vas te retrouver avec des titres vides. Et pour la numérotation des chapitres il faut passer par le menu Outils > Numérotation des chapitres et non faire comme dans MS-Word, même si on peut depuis quelques versions. C'est ça qui est le plus robuste.

    Enfin bien sûr, on ne saute jamais de ligne (pas de paragraphe vide). Les espacements avant et après des styles de paragraphes sont faits pour gérer ça. Les paragraphes vides ça fout la bazar dans le calcul des sauts de pages automatiques. Si on a besoin de séparer un peu plus 2 paragraphes successifs, on peut définir un style "Corps de texte avec espace plus grand avant" qui aura comme style de suite le style "Corps de texte" normal.

    Enfin, bien faire attention au choix des polices de caractères : comme les logiciels, les polices ont aussi des bugs ou sont incomplètes. C'était le cas à un moment par exemple avec Vera Bitstream remplacée depuis par DejaVu. Pour le moment mes polices préférées sont Linux Libertine et Linux Biolinum qu'on peut paramétrer très finement. Si tu fais du ePub, il faut sans doute choisir des polices qui sont disponibles sur la plupart des ordinateurs, sinon le remplacement des polices manquantes par l'afficheur va donner des résultats imprévisibles.

  • # La forme puis le fond

    Posté par  (site web personnel, Mastodon) . Évalué à 3.

    Je dirais que le mieux c’est d’écrire décorrélé de la mise en forme qui parasite la rédaction.
    Rédaction en markdown avec un logiciel qui gère le contenu et tes copies d’écran, tels que Zettlr, que tu peux coupler avec un logiciel de type Zotero si tu as besoin de références bibliographiques.

    Zettlr permet par exemple d’exporter en EPUB, tex, PDF (via pandoc), LibreOffice, Word…

    Après l'epub, dans un deuxième temps pour un livre imprimé, je passerais sur Scribus, qui est aussi adapté au document long. Le grand avantage d’avoir une base en markdown, c’est sa proximité avec le texte brut, toujours récupérable. Extraire ton texte avec des données structurées après être passées en Scribus ou odt, est bien plus pénible à réaliser.

  • # Achetez aime elle !

    Posté par  (site web personnel) . Évalué à 4.

    Tant mieux si je peux générer du HTML, mais ce n'est pas ma priorité.

    Et si tu faisais l'inverse? Ecrire ton livre en html puis générer du pdf avec ?

    Après tout html permets:

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

  • # Merci pour vos réponses !

    Posté par  (site web personnel) . Évalué à 7. Dernière modification le 06 mai 2021 à 09:52.

    Merci à tous pour vos réponses, vous m'avez fait avancer dans ma réflexion. Je suis un peu confus car je n'étais pas là hier après-midi au moment des débats…
    Je vais donc essayer de partir avec Writer. Si tout fonctionne, je continuerais comme cela et sinon, je me dirigerais vers Pandoc ou LyX.
    De toutes façons, je pense faire plusieurs petits livres de 100 pages plutôt qu'un gros de 450 pages.
    Le premier sera en licence Creative Commons et j'essayerais de publier les sources pour que vous puissiez me taper sur les doigts :)
    Souhaitez moi bon courage et bonne chance :)

    • [^] # Re: Merci pour vos réponses !

      Posté par  (Mastodon) . Évalué à 2.

      Souhaitez moi bon courage et bonne chance :)

      De tout cœur :)

    • [^] # Re: Merci pour vos réponses !

      Posté par  . Évalué à 3.

      Bon courage et bonne chance ! :-)

      Si tu rencontres des difficultés avec LibreOffice Writer, n'hésite pas à demander de l'aide ici (sauf si tu veux éviter les réponses du genre "en latex il suffit de faire comme ceci ou comme cela"). Et bien sûr aussi sur la liste de discussion d'entraide users@fr.libreoffice.org ou sur https://ask.libreoffice.org/fr/

    • [^] # Re: Merci pour vos réponses !

      Posté par  . Évalué à 5.

      Je me permet ma petite remarque :)

      L'outil on s'en fou. Prend celui qui te va bien pour rédiger, écrire un bouquin est déjà assez compliqué pour ne pas se fader un outil qui ne te convient pas. Tu aura de toute manière une étape de mise en forme à faire après la rédaction.

      Si tu utilise un format texte qui ne tiens pas compte des retours à la ligne comme markdown. J'ai vu plusieurs personnes qui écrivent des bouquins dire qu'ils préfèrent maintenant taper une phrase par ligne. C'est contre intuitif, mais ça leur permet d'encore plus s'abstraire du formatage lors de la rédaction. En bonus on se rend mieux compte de la longueur de phrases.

      Souhaitez moi bon courage et bonne chance :)

      Bon courage n'hésite pas à faire un retour de ce qui a marché ou pas chez toi et pour la publicité de tes livres.

      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

    • [^] # Re: Merci pour vos réponses !

      Posté par  . Évalué à 2. Dernière modification le 06 mai 2021 à 18:40.

      Le premier sera en licence Creative Commons

      Tiens, ça me fait penser à une question que je me suis posé récemment (je n'ai pas la réponse).

      Je voulais poser une licence sur un modèle de document (et pas le contenu du document lui-même, donc). Et bien c'est peut-être plus compliqué en LaTeX qu'avec LibreOffice, au sens où on a rapidement fait de copier un include(lePackageQuiTue) sans vérifier l'homogénéité du tout.

      Cela étant, j'ai trouvé la question intéressante, car c'est un détail souvent omis : on se focalise sur la licence du document, pas forcément sur celle des petites choses autour !

      Matricule 23415

  • # Zettelkasten

    Posté par  . Évalué à 1.

    Vu que tu parles aussi de logiciel pour l'aide à l'écriture.
    On peut rajouter les logiciels d'aide à l’organisation des idées sous forme atomique et reliée.

    Voici un petit article citant plusieurs d'entre eux : GEEKRITURE 05 - Des outils numériques pour l'émergence des idées et du savoir

Suivre le flux des commentaires

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