FAQ post-processing

From DPWiki
Jump to: navigation, search
DP Official Documentation - Post-Processing and Post-Processing Verification
Languages: English Français


Le contenu de cette page est périmé et la traduction demande une mise à jour. Si vous avez des questions, veuillez contacter l'un de ses éditeurs (lien tout en bas de cette page).

Qu'est-ce que le post-processing?

Le but du post-processing est de travailler sur le texte pour en faire un livre électronique dans un format commode. De nombreux volontaires sont intervenus pendant le périple à travers les tours de relecture et de formatage: le post-processeur doit homogénéiser la mise en forme du livre et s'assurer de respecter les exigences du Projet Gutenberg. Il faut également s'occuper des erreurs résiduelles détectables. Au final, il s'agit de produire un texte mis en forme de façon homogène, contenant le moins possible d'erreurs, et reflétant fidèlement l'intention de l'auteur. Une version en texte brut est toujours requise (un fichier .txt), mais pour de nombreux projets il est également recommandé, ou bien demandé, de produire une version dans d'autres formats. Ne vous laissez pas arrêter par ces autres formats – il y a d'autres personnes qui seront ravies d'aider si vous ne voulez pas vous occuper de cela vous-même.

Contents

Qui peut faire le post-processing?

Les post-processeurs doivent avoir plus d'expérience que les relecteurs ordinaires. En effet, d'une part ces personnes sont les dernières à intervenir sur le texte, et d'autre part elles doivent prendre des décisions sur l'organisation et l'apparence du texte. Pour cette raison il est généralement requis que les post-processeurs aient formatés au moins 400 pages dans le tour F1, ou aient complété au moins 400 pages dans les anciens tours R*. La page du pool PP indique si vous remplissez les conditions, et si c'est le cas cette page contient également un bouton que vous devez cliquer pour demander l'accès (l'accès est alors automatiquement accordé).

Si vous ne remplissez pas ces conditions en terme de nombre de pages, mais que vous avez une raison pour vouloir être post-processeur (par exemple, une compétence linguistique particulière), n'hésitez pas à demander l'accès.

Quelle aide est disponible?

Cette FAQ contient énormément d'information, en particulier la section 'aide'. Il y a également des fils de discussions utiles dans le forum "Post processing", en particulier le sujet de discussion No Dumb Questions. Vous pouvez obtenir de l'aide plus rapidement en utilisant Jabber (il y a généralement quelqu'un sur la Chat Room DP, tous fuseaux horaires confondus!). Vous pouvez également faire appel à un tuteur (voir PP Mentoring et PP Mentors). PG a ses propres directives. Enfin il est particulièrement recommandé de regarder des livres similaires déjà présents sur PG.

Quels outils puis-je utiliser?

Les post-processeurs utilisent de nombreux systèmes d'exploitation et des outils variés. Vous êtes libre de choisir quels outils utiliser, mais au minimum vous devrez utiliser:

  • un éditeur de texte,
  • un programme capable d'afficher des images,
  • un correcteur orthographique,
  • et Gutcheck

Si vous créez une version HTML, vous devrez également utiliser le validateur HTML en ligne, ainsi que le validateur de CSS et qu'un vérificateur de liens. Si votre projet possède des illustrations, vous aurez besoin d'un éditeur d'images.

Il y a d'autres programmes utiles qui ne sont pas indispensables, mais qui peuvent s'avérer extrêment utiles et peuvent vous faire gagner beaucoup de temps. Certains incluent le programme Gutcheck. La plupart des post-processeurs utilisent Guiguts, il y a donc beaucoup d'aide, de conseils et un tutoriel pour Guiguts.

Quel livre choisir?

Pour votre premier projet, il est préférable de choisir une œuvre de fiction avec un nombre relativement faible de pages (moins de 200 environ). En effet:

  • Il est plus facile et plus rapide de manipuler un petit nombre de pages;
  • Les pages d'un roman ou d'une œuvre de fiction sont en général moins denses, sont plus simples à scaner et à formater, et de ce fait ont moins de chances de comporter des erreurs d'OCR et des problèmes de formatage non homogène;
  • Il y a en général moins de choses compliquées comme des tableaux, des notes de bas de page, des illustrations, etc. qui sont plus difficiles à traiter pour les post-processeurs débutants.

Mais de nombreux PPers n'ont pas commencé par un roman, et tout s'est bien passé en final. C'est juste un conseil raisonnable.

Voici quelques bonnes façons de trouver un livre disponible pour le post-processing:

  1. Le fil de discussions Projects for new PPers. C'est là que sont annoncés les projets qui sont adaptés pour commencer. Vous pouvez également vous signaler dans ce forum si vous êtes à la recherche d'un bon projet pour débuter.
  2. Si vous relisez ou formatez un projet qui vous intéresse particulièrement, vous pouvez demander au responsable du projet si ce livre a déjà été réservé pour un PPer (cette information figure également dans la page de projet.) Si aucun PPer n'est pour l'instant désigné, ou si le PPer désigné est le responsable de projet, demandez au responsable du projet s'il peut vous réserver le livre. Il faudra néanmoins que le livre finisse les tours de relecture et de formatage avant d'être disponible pour le post-processing. L'autre solution est d'examiner la des livres sans PPer et de contacter le responsable de projet. Faites attention à ce que vous demandez, car vous risquez de l'obtenir!
  3. Contactez un tuteur de PP. Ils peuvent vous aider pour toutes questions que vous vous posez sur le processus, mais peuvent également trouver des projets adaptés, ou vous suggérer d'autres options que celles mentionnées ici.


Note: vous ne prenez aucun engagement lorsque vous choisissez un livre en PPing. Si pour une raison quelconque vous souhaitez cesser le travail que vous avez commencé sur un projet, il est préférable de contacter le responsable pour pouvoir faire le passage de relai le mieux possible. On ne vous en voudra pas d'arrêter, et vous ne subirez aucune pression. L'auteur de cette présente FAQ a rendu plus de livres qu'elle n'en a fini le PPing, ce qui est parfaitement acceptable! Il faut voir les choses ainsi: on offre à quelqu'un d'autre la chance de pouvoir travailler sur le projet qu'on abandonne, et en même temps on récupère un temps précieux pour travailler sur un autre projet!


Téléchargez le texte brut du projet que vous avez choisi en utilisant le lien "Download Zipped Text" depuis la page du projet (le lien est situé vers le bas de la page). Ne choisissez pas "Download Zipped TEI Text" qui correspond à un format différent (sauf si vous savez ce qu'est le TEI et que vous voulez utiliser cela). A priori vous avez besoin de la version en texte brut.

Parcourez le texte rapidement pour voir s'il y a des difficultés, comme des notes de bas de page, de la poésie, des passages en langues étrangères ou en dialecte, des tables, etc. Ainsi vous saurez à quoi vous attendre et pouvez décider en connaissance de cause si vous continuez sur ce projet ou si vous préférer choisir un autre projet. Si vous pensez que vous pouvez venir à bout des difficultés, n'hésitez pas à vous lancer. Il y a toujours profusion d'aide disponible.

Jetez un coup d'œil au fil de discussion du projet, pour voir ce que les relecteurs et formateurs ont signalé. Cela peut également révéler des difficultés possibles.

Assurez-vous que le livre vous est bien attribué, sans quoi vous risquez de passer des heures sur ce projet et découvrir à la fin que le livre a été fini par quelqu'un d'autre. Si le livre vous est attribué, il apparaît dans la table de vos projets dans votre page PP.


Note: de temps en temps des livres charmants et sans difficulté particulière apparaissent dans le pool PP. Si vous voulez choisir ce livre, une fois que vous avez pris la température du projet en faisant les vérifications indiquées plus haut, vous pouvez vous attribuer vous-même le projet en cliquant sur le bouton "Check Out Book". N'oubliez pas de vérifier que le livre vous est bien attribué, avant de commencer vraiment le travail.

Combien de temps cela prend-il?

Il est très difficile de répondre à cette question à l'avance. Le temps dépend de trois facteurs:

  • la difficulté et la longueur du livre lui-même;
  • les outils utilisés;
  • l'expérience du post-processeur.

Le temps peut varier de quelques heures à plusieurs jours. Quelques livres particulièrement difficiles peuvent prendre des semaines (ou plus). Pensez à sauvegarder votre travail souvent, en utilisant des noms de fichier différents à chaque fois, pour pouvoir repartir sur la dernière version saine si vous faites une erreur. Travaillez à votre rythme, ne vous pressez pas – vous êtes la dernière personne à travailler en détail sur ce livre avant qu'il soit publié sur le projet Gutenberg (même si d'autres personnes effectueront certaines vérifications).

Ne vous découragez pas si vous avez l'impression qu'il vous faut un temps très long pour finir un livre "facile". Concentrez-vous sur l'apprentissage du processus de post-processing, prenez le temps de vous familiariser avec les outils que vous utilisez, et de faire un travail de qualité plutôt que de viser la vitesse. Vous deviendrez naturellement plus rapide avec la pratique.

Et si je change d'avis, ou que je n'aie plus de temps?

Si vous réalisez que le projet que vous avez choisi est trop compliqué, ou que vous manquez de temps, il est parfaitement acceptable de rendre le projet au pool PP. Vous pouvez chercher un autre projet plus facile dans la foulée, ou attendre d'avoir un peu plus de temps.

Pour rendre un projet, cliquez sur le lien "Return to Available" depuis la page de projet. Avant d'utiliser ce bouton, vous pouvez ajouter un commentaire dans le champ "update comment and project status". Si le projet est difficile, ou s'il y a des problèmes comme par exemple des pages manquantes, c'est bien de signaler ces problèmes pour que d'autres personnes soient au courant. Puis cliquez le bouton pour rendre le projet disponible.

Si vous avez déjà fait un travail conséquent sur ce projet, vous pouvez avoir envie de passer votre travail à un autre PPer. Trouvez un autre PPer dans le forum Post-Processing et arrangez-vous avec lui pour le transfert. Ne retournez pas le projet directement dans le pool, dans ce cas.

Chantier.png vérifier si ce paragraphe n'est pas rendu obsolète par la possibilité de déposer des fichiers temporaires.

Que faut-il faire?

Note: bon nombre des actions décrites plus bas sont automatisées par les outils. Référez-vous aux guides et manuels introductifs des outils que vous utilisez.

Il vous faudra garder trace des actions que vous avez déjà faites, pour ne rien oublier. Une façon de faire consiste à utiliser le champ "update comment and project status" depuis la page de projet, sur le site, mais n'importe quel fichier sur votre ordinateur fera aussi bien l'affaire. C'est dans cette check-list que vous noterez les actions déjà faites, les choses à surveiller, y compris les points signalés par les correcteurs. Vous pourrez ainsi interrompre votre travail de post-processing par moments et pouvoir repartir directement sans perdre le fil.

Faire un peu de recherche

Lisez les commentaires de projet et le forum du projet. Si les correcteurs ont noté des difficultés particulières, gardez-en note pour le traiter au moment approprié. Vérifiez que vous suivez les instructions du responsable de projet: par exemple il est souvent demandé de faire une version du livre en format HTML.

Vérifier les astérisques * laissées par les correcteurs

Faites une recherche des astérisques * et notez les problèmes potentiels.

Vérifier le marquage

Assurez-vous que les marques /* */, /# #/, etc. sont correctement refermées. Vérifiez que la poésie possède le bon marquage garantissant que les retours à la ligne seront conservés. Vérifiez également la bonne indentation de chaque poème. Chaque <i> doit être refermé par un </i>, et de même pour les autres marques. Vous pouvez être amené à changer certaines marques issues des tours de formatage par des marques propres à vos outils (par exemple /p p/, /f f/); consultez la documentation de vos outils. Le responsable de projet aura peut-être été amené à demander d'utiliser des marques particulières pendant les tours de formatage. Vérifiez également le formatage qui s'étend sur plusieurs pages: en général il faudra retirer toutes les marques de fermeture et de ré-ouverture aux changements de page.

La meilleure façon de procéder est de balayer le texte page par page, en affichant l'image de la page scannée correspondante dans votre logiciel de visualisation d'image. Vous noterez ainsi rapidement les poèmes ou les blocs de citations pour lequel le marquage serait manquant. C'est aussi le bon moment de vérifier s'il ne manque pas de page (cela arrive parfois, rarement).

conserver retours à la ligne? indenter?
Pas de marque, par défaut oui non
/* */: poésie, etc. non non
/# #/: bloc de citation, etc. oui oui

Non conforme aux directives de formatage, mais utilisé par divers outils:

conserver retours à la ligne? indenter?
/$ $/: tables, etc. non non
/p p/: poésie, etc. non oui

Chacune de ces marques doivent avoir une ligne blanche avant la marque ouvrante, et une après la marque fermante. Ces marques doivent se trouver seules sur leur ligne (sauf si votre outil permet le contraire).

Arranger la page de titre, la table des matières, etc.

Vous avez un peu de liberté concernant la mise en forme de la page de titre. Vous pouvez faire quelques ajustements, par exemple déplacer le nom de l'auteur juste sous le mot "par". Il n'est pas nécessaire de reproduire une indentation relative des lignes, mais vous pouvez le faire si vous le souhaitez. Conservez les numéros de page dans les tables des matières et les listes des illustrations. Alignez verticalement les titres et les numéros de page pour que le résultat soit plaisant et facile à lire. En général une imitation du format de la table des matières donne un bon résultat. Laissez toute l'information originale sur la page de titre, y compris l'édition, la date de publication, et les indications de copyright (sauf s'il s'agit d'une réimpression – vérifiez avec le responsable du projet en cas de doute). Il vaut mieux ajouter toute l'information disponible, que de laisser planer des doutes ultérieurement.

Notes de bas de page

Il faudra rejoindre les notes coupées sur plusieurs pages. Puis, dans la version en texte seul, vous devez choisir entre positionner les notes juste après le paragraphe où figure l'appel de note, ou bien en fin de chapitre ou de section. Faites attention en cas de rénumérotation de conserver les mêmes numéros entre les appels de note et les notes elles-mêmes. Il est déconseillé de représenter les notes en ligne [Note: dans le corps du texte], même quand ces notes sont extrêmement brèves.

Envisagez de placer les notes juste après le paragraphe si ces notes sont peu fréquentes, courtes et uniques. Placez les notes en fin de chapitre ou de section si elles sont plus longues, ou nombreuses, ou si une même note est référencée plusieurs fois. Dans tous les cas soyez cohérent: n'utilisez pas tantôt l'un, tantôt l'autre dans un même ouvrage.

Pour la version HTML, les notes doivent être liées avec des liens hyper-texte. La plupart des outils de post-processing font cela automatiquement: consultez la documentation des outils que vous utilisez.

Vous pouvez renuméroter les notes, si vous le souhaitez, de telle sorte que chaque note du livre ait un numéro ou une lettre unique (ou même un chiffre romain, s'il n'y a pas plus de vingt ou trente notes, car sinon les chiffres deviennent difficiles à lire). Vous pouvez sinon les laisser telles qu'elles apparaissent dans le livre original.

Vérifier les problèmes courants

  • espaces autour des traits d'union
  • espaces avant la ponctuation . ! ? ; : ,
  • espaces autour des guillemets
  • espaces à l'intérieur des () [] {}
  • espaces dans les sigles
  • espaces excédentaires à l'intérieur des marques /* */
  • pauses <tb> incorrectement formatées
  • points de suspension incorrects
  • tirets incorrects (exemple: trois signes moins)
  • espaces incorrects autours des tirets -- et ----
  • vérifier les astérisques * laissés par les correcteurs. En tant que PPer c'est à vous de résoudre les problèmes signalés par les correcteurs. Si vous avez besoin d'un conseil ou d'une autre opinion, voyez plus bas la section aide. Vous pouvez également rejoindre les mots coupés en fin de page à ce stade.
  • examiner les mots coupés en fin de ligne, en regardant l'usage dans l'ensemble du texte. S'il y a une nette préférence pour une forme – par exemple 20 long-temps et un longtemps – vous pouvez supposer une erreur de l'imprimeur et mettre partout long-temps. S'il n'y a pas de majorité claire, vous devrez décider entre laisser chaque instance comme sur l'original, ou choisir quoi corriger (et dans ce cas, vous devez aussi décidez si cela mérite une note du transcripteur ou pas).

Rejoindre les pages

Retirer les séparations entre pages, vérifier pour chaque page si la nouvelle page commence par un paragraphe ou un chapitre, ou si le texte continue au sein du même paragraphe. C'est également le bon moment pour retirer les [Blank Page].

Correcteur orthographique

Même si ça paraît à l'avance pénible, il est presque toujours nécessaire d'utiliser un correcteur orthographique. Les textes imprimés avant que l'orthographe ne comporte de règle peuvent constituer une exception, mais même dans ce cas la vérification orthographique est souvent utile.

Traiter les illustrations

Déplacez la marque d'illustration à un endroit approprié du texte. Certains PPers conservent l'illustration au plus près du paragraphe qu'elles illustrent. D'autres préfèrent les placer au début ou à la fin du chapitre, pour ne pas interrompre le fil de la lecture. Faites ce que vous jugez approprié pour votre livre.

Note: nous conservons les légendes d'illustrations dans la version en texte seul, au cas où les personnes veuillent se référer à la version HTML plus tard. Ne retirez pas les indications d'illustration. Si vous ne voulez pas produire une version HTML, mais que votre livre comporte des illustrations, utilisez le pool HTML pour recruter quelqu'un qui fera la version HTML pour vous. DP impose une version HTML pour les livres comportant des illustrations (même si le responsable de projet ne le demande pas).

Replier les lignes

C'est le moment de "replier" les lignes (anglais: rewrap). Avez-vous vu des tables, de la poésie? Si non, il est facile de replier les lignes. Il s'agit de déplacer les retours à la ligne à l'intérieur des paragraphes pour que chaque ligne fasse entre 65 et 75 caractères de large. Chaque programme a une façon différence de faire cela, à vous de voir quel outil marche le mieux pour vous.

S'il faut en venir au pire, et que vous ne trouvez aucun moyen simple de replier les lignes, remplacez tous les retours à la ligne par des espaces, et insérez les retours à la ligne manuellement pour que les lignes fassent moins de 75 caractères. C'est pénible, mais ça marche. Mais en pratique cette solution extrême ne devrait pas être nécessaire.

Une fois que le texte est replié, retirez tous les espaces superflus en fin de ligne (encore une fois: utilisez l'outil de post-processing si possible! Tous les outils actuels comportent cette fonction).

Vérifier le formatage

Les en-têtes de chapitre doivent avoir quatre lignes blanches avant, et deux après; les sections doivent avoir deux lignes blanches avant, tout comme les Directives de formatage de DP.

Les pauses <tb> doivent être remplacées par des astérisques. La structure la plus employée est 7 espaces, puis 5 astérisques espacées de 6 espaces:

       *     *     *     *     *

PG accepte d'autres conventions, mais il est important d'être homogène au sein d'un même livre.

La poésie doit être indentée d'au moins 2 espaces (c'est une exigence de PG, pour indiquer qu'il faut conserver les retours à la ligne dans d'autres versions dérivées du format texte). Les indentations au sein du poème doivent s'ajouter à ces deux espaces: si vous avez un poème qui alterne des vers non indentés et des vers indentés de 4 espaces, le résultat final aura des vers indentés de 2 espaces et d'autres indentés de 6.

On peut également indenter les blocs de citation pour marquer nettement la séparation d'avec le reste du texte.

Si vous avez aligné verticalement des numéros de page dans une table des matières ou une liste des illustrations, cette table doit également être indentée pour indiquer qu'il faut conserver les espaces et les retours à la ligne.

Gutcheck!

L'outil Gutcheck a été écrit spécifiquement pour détecter un grand nombre de problèmes courants dans les textes de PG. Gutcheck est incorporé à la plupart des outils de PPing: suivez dans ce cas les instructions de votre outil de PPing. Sinon vous pouvez télécharger gutcheck ici, en suivant les instructions figurant là-bas. Lancez-le initialement avec toutes les options activées. Vérifiez chaque erreur potentielle. Les points signalés par gutcheck ne sont pas tous des erreurs (par exemple il peut signaler des lignes anormalement courtes à l'intérieur d'un poème ou d'un tableau), mais il faut vérifier chaque point et corriger si c'est nécessaire. Quand les corrections ont été faites, continuez de lancer gutcheck jusqu'à ce qu'il ne signale plus aucune erreur réelle.


Quelques points à surveiller:

  • les marques de note sont signalés par erreur comme des 'Wrongly spaced brackets'. Vérifiez quand même.
  • Les mots particulièrement longs peuvent causer des lignes courtes. Essayez de reformater le paragraphe avec des lignes un peu plus longues ou plus courtes, cela permet souvent de résoudre le problème. Les lignes courtes dans des tables ou de la poésie ne sont pas un problème.
  • les directives de PG indiquent que le texte normal ne devrait pas avoir des lignes plus longues que 75 caractères. Il y a une tolérance à 80 caractères pour les tables ou d'autres cas particuliers (par exemple, de la poésie à longues lignes). S'il n'y a absolument pas moyen de raccourcir un chose comme un arbre généalogique, il est admis de le laisser tel quel. Il est souvent utile de demander dans le forum Post-Processing, car d'autres personnes peuvent suggérer des méthodes pertinentes pour réduire ou remettre en forme le passage problématique.
  • À moins que vous ne cherchiez spécifiquement à faire une version en pur ASCII, il faut simplement ignorer les remarques à propos des "Non-ASCII character".
  • L'erreur "Wrongspaced quotes" apparaît fréquemment quand des citations s'étendent sur plusieurs paragraphes. Vérifiez à tout hasard, mais si les guillemets sont conformes aux directives de relecture de DP, il n'y a rien à changer pour PG.


À la fin de ce processus, vous avez en vos mains un livre qui contient du marquage HTML, ainsi que des marques propres à DP comme [Footnote] ou <tb>. Faites une copie de ce fichier dual, nommé par exemple truc-marques.txt. Si vous voulez proposer ce livre à la lecture courante, c'est le bon moment.

Pour les points particuliers – tables, grec, poésie, etc. – voyez la section Aide.

Est-ce tout?

Et bien, la base est faite. Vous pouvez effectuer des actions supplémentaires pour fournir un texte de la meilleure qualité possible.

Tests paranoïaques

Les tests de recherche de scannos furtives, de ponctuation aberrante, etc. peuvent être faits grâce à des outils distincts, ou bien incorporés dans votre outil principal de post-processing.

Il existe ainsi des programmes "evolués" qui recherchent par exemple des anomalies liées aux mots he/be (en anglais), ou des combinaisons de lettres peu probables comme 'tb' (pour 'th'). Il y a également des listes d'expressions régulières reconnaissant des schémas peu plausibles, ainsi que des outils pour faire une recherche systématique de ces expressions régulières. Consultez la documentation de vos outils. Voyez aussi la clinique des expressions régulières.

Un exemple de test très simple et généralement rentable est de rechercher l'expression régulière \n\n\n, c'est à dire trois retours à la ligne consécutifs, soit deux lignes vides: cela permet de balayer rapidement les en-têtes de chapitre et de sections et vérifier qu'ils comportent le bon nombre de lignes vides, et aussi de détecter des lignes vides excédentaires apparues par exemple après traitement des marques /* et /#.

Lecture courante

Quand vous avez fini vos tests standards, et que vous êtes prêt à produire le ou les versions finales, pous pouvez choisir de proposer ce projet en lecture courante. Un lecteur supplémentaire est souvent utile et trouve souent des choses que vous pourriez n'avoir pas remarqué. La lecture courante se fait en général sur une version texte, donc faites une copie de votre livre, remplaçez les <i> et </i> par des _, et utilisez votre convention favorite pour représenter <b> et <b> (les options les plus fréquemment employées sont discutées ici); remplacez les <tb> par la ligne d'astérisques usuelle; retirez pour le moment tout le reste du marquage; enfin, faites une archive zip contenant ce fichier texte.

Depuis la page du projet, utilisez l'un des liens pour proposer ce projet en lecture courante pour une, deux ou quatre semaines. Voyez les détails dans la FAQ lecture courante.

Pendant la période de lecture courante, vous pouvez commencer à travailler sur les autres formats, ou bien traiter les illustrations.

Notes du transcripteur

Si vous effectuez des changements au texte, il est recommandé d'inclure une note du transcripteur. C'est parfois très simple:

Note concernant la transcription: La ponctuation a été normalisée.

Une note généraliste très utile, en particulier pour les livres anciens, est la suivante:

Note du transcripteur: on a conservé toutes les erreurs de l'imprimeur.

(Cette note évite aux personnes de PG de recevoir de longues listes d'errata de la part de lecteurs bien intentionnés voulant "corriger" votre texte. Néanmoins ce n'est pas une excuse pour laisser des erreurs d'OCR qui ne sont pas conformes à la page scannée.)

Parfois, la note peut être assez longue:

Notes du transcripteur:
On a effectué les corrections suivantes:
Page 13, "10,00 hommes" corrigé en "10,000 hommes" (Nous combattîmes 10,000
hommes à St Germain.)
Page 27, "Faw-cett" corrigé en "Fawcett". (Le commandant Fawcett dicta
l'ordre.)
etc. etc.

Ainsi, bien que les séparations de page ne soient pas conservées dans la version texte, cela donne une idée de l'emplacement relatif, et le lecteur peut rechercher le texte entre parenthèses pour retrouver l'endroit exact de la correction.


En HTML, il est possible d'utiliser des bulles flottant au-dessus du mot corrigé, pour réduire la taille de la liste des corrections sans perdre l'information. Demandez les détails dans le forum Post-Processing.


La plupart des post-processeurs corrigent les erreurs manifestes (par exemple "manitesfes"). Mais nous ne modernisons pas l'orthographe ou la grammaire: notre rôle est de préserver l'histoire, pas de l'améliorer.

Mettez les notes courtes, ou qui s'appliquent au texte dans son intégralité, au début du livre, avant la page de titre. Mettez le reste à la fin (après les index et les notes de bas de page). Les notes du transcripteur sont optionnelles, mais peuvent aider le lecteur à comprendre comment nous sommes intervenus sur le texte. Il vous revient de déterminer ce que vous estimez nécessaire de mentionner dans votre note. En cas de doute, demandez aux autres post-processeurs dans les forums, Jabber ou par message privé comment ils ont géré diverses situations.

Dans tous les cas il doit être absolument clair pour le lecteur de savoir ce qui fait partie du livre original et ce qui constitue votre note du transcripteur.

Finition

Création d'une version en texte seul

Prenez une copie de votre fichier, nommée par exemple truc-texte.txt. Gardez une version de sauvegarde du fichier avec marquage comme référence. Commencez à retirer le marquage du fichier texte: les marques concernant les retours à la ligne doivent disparaître; <i> et </i> sont remplacés par des _; utilisez votre convention favorite pour représenter <b> et <b>; remplacez les <tb> par la ligne d'astérisques usuelle: 7 espaces, puis 5 astérisques séparées chacune par 5 espaces:

       *     *     *     *     *

Si votre projet contient des marques <sc>, il faudra remplacer ces marques par quelque chose ayant un sens dans la version en texte (voyez le guide sur les petites capitales).

Si le texte contient des lettres supérieures ou en exposant, il est peut-être pertinent de remplacer le ^ par quelque chose ayant un sens dans la version texte: par exemple remplacer M^{me} par Mme, 1^o par .

À la fin, faites une recherche rapide des caractères < et >, au cas où certaines marques vous aient échappé.

C'est également le moment de rendre vos notes plus jolies: par exemple [1] texte au lieu de [Footnote 1: texte].

Enfin, faites une passe finale de gutcheck, pour vérifier qu'il ne reste plus d'erreur, et que le polissage final n'a pas introduit de problème (par exemple des lignes trop courtes une fois que le marquage a été retiré).

Création d'une version HTML

Voyez plus bas. Utilisez une copie de votre fichier avec marquage, nommée par exemple truc-htm.html. Gardez une version de sauvegarde du fichier avec marquage comme référence.

Soumettre pour Vérification de PP

(anglais, uploading for PPV) Nommez les fichiers définitifs avec des noms de fichiers courts, utilisant uniquement les lettres minuscules (sans accent), chiffres, signe "moins" et caractère "souligné". Évitez les espaces, et les caractères spéciaux comme ?, #, $, etc. Créez une nouvelle archive zip, et mettez dans cette archive le fichier en texte seul, et les versions dans d'autres formats si vous en avez. Les illustrations doivent être situées dans un dossier nommé "images/". Si vous utilisez Guiguts, incluez également les fichiers .bin pertinents (c'est extrêmement utile pour les PPVers qui utilisent Guiguts). Ces fichiers .bin ne seront pas envoyés à PG.

Votre archive zip devrait contenir des fichiers ressemblant à ceci:

  • machin.txt
  • machin.html
  • machin.txt.bin (s'il a été créé par Guiguts)
  • machin.html.bin (s'il a été créé par Guiguts)
  • images/ (un répertoire)
    • image1.png
    • image2.png
    • image3.jpg
  • machin-utf8.txt (SEULEMENT si vous incluez une version en UTF-8, en complément ou à la place de machin.txt)

Selon les paramètres de votre logiciel de zip, vous devrez peut-être indiquer à celui-ci de "sauver les chemins relatifs". Si vous utilisez un Mac, vous pouvez également demander d'omettre les fichiers du Finder (pour ne pas inclure les fichier invisibles).

Depuis la page de projet, sélectionnez le bouton "Upload for Verification". Ajoutez une adresse email dans vos commentaires à destination du PPV si vous souhaitez être informé par email de la publication du livre sur PG. Vous pouvez également utiliser le champ commentaires pour mentionner des vérifications particulières que vous auriez faites, ou alerter l'attention du PPVer sur des particularités de ce livre. Vérifiez que vos préférences sont correctes en ce qui concerne la valeur "PP Credits", car c'est ce paramètre qui gouverne l'inclusion de votre nom dans les crédits du livre publié sur PG. Si vous ne voulez pas être nommé, ou si vous voulez utiliser un nom différent, mentionnez cela dans vos commentaires.


Votre adresse email ne figurera pas dans le livre final, mais pourra être utilisée par le PPVer pour vous adresser des commentaires. Si vous n'incluez pas d'adresse email, les commentaires du PPV vous parviendront par un message privé sur le site.

Que devient mon livre maintenant?

D'abord, votre livre ira chez un post-processeur expérimenté pour la Vérification de Post-Processing (PPV). Cette personne vérifiera votre travail soigneusement pour vérifier que toutes les étapes ont été suivies (correcteur orthographique passé, images redimensionnées correctement, pas de problèmes de gutcheck, HTML valide, etc.) Parfois un PPVer demandera que le projet vous revienne pour que vous apportiez des corrections supplémentaires. Cela ne signifie pas que vous êtes un mauvais post-processeur, c'est sans doute simplement que vous avez manqué ou mal exécuté une étape du processus. Vous recevrez un email ou un message privé expliquant ce qu'il reste à faire et souvent proposant de l'aide ou indiquant où trouver de l'aide.

Une fois que votre travail a passé la PPV, le PPVer soumet le livre au projet Gutenberg. Un "white-washer" (WWer) de PG fait une vérification finale de votre travail (et de celui du PPVer), et ajoute les mentions standard de PG, incluant les mentions légales. Parfois un WWer aura une question et elle vous parviendra par l'intermédiaire du PPVer.

Enfin votre livre est publié sur le site du Projet Gutenberg! Félicitations! Lorsque votre projet sera posté, vous recevrez un feedback de votre PPVer. Il vous indiquera les choses que vous avez traitées correctement, et vous donnera des suggestions d'amélioration pour vos futurs projets. N'hésitez pas à contacter votre PPVer pour toutes questions que vous auriez à propos de votre projet. Si vous ne recevez pas de nouvelles et que votre projet a été publié, demandez dans le forum PPV.

Voyez plus bas si vous trouvez une erreur après que le livre a été posté.


J'ai obtenu l'accès direct à PG

Une fois que plusieurs de vos projets auront été vérifiés en PPV, si vous avez reçu l'accès direct pour poster vos projets sur PG, vous recevrez des instructions du coordinateur PPV sur la conduite à tenir. French/Conditions_d'accès#Direct_Uploading

À l'aide!

Page ou image manquante ou problématique

Parfois une page est sautée par erreur lorsque le livre est scanné. Normalement le fournisseur de contenu et le responsable de projet ont déjà vérifié, mais ne vous y fiez pas: vérifiez également. Parfois la page a été scannée, mais est en partie illisible. Contactez d'abord le responsable de projet pour obtenir une meilleure page. S'il lui est impossible, pour une raison ou une autre, de fournir un scan correct, utilisez le wiki sur les pages manquantes.

Si vous obtenez les images manquantes, informez Db-req. Mentionnez l'endroit où se trouvent les images sur dpscans, le titre et l'identifiant du projet, et le projet sera réparé pour vous. C'est très important pour des questions d'archivage.


Projets en plusieurs parties

Si vous avez plusieurs sections d'un même livre, et que vous voudriez qu'elles soient recousues ensemble pour faciliter le PPing, vous pouvez demander à Db-req. Il sera plus simple de travailler avec un seul projet que de faire la jonction vous-même, et db-req vous renumérotera les numéros de png facilement si les numéros sont en conflit.

NOTE: les volumes multiples d'un ouvrage peuvent être postés séparément sur PG, et n'ont pas besoin de ce traitement. Si vous avez un doute, demandez au responsable du projet ou bien envoyez un mail à Db-req.

Autres formats

Chaque projet DOIT comporter une version en texte seul (sauf si le projet ne peut absolument pas être représenté en texte seul – par exemple une partition de musique). Outre cette version, il existe d'autres formats qui peuvent ajouter de l'information et donner plus de valeur au livre.

HTML

C'est le format, autre que le texte seul, le plus couramment employé. Si vous travaillez sur une partie d'un uber-projet, ou un volume d'un périodique, il se peut qu'il existe déjà un guide de style (demandez dans le forum Uber-projets). Sinon, il vous revient de produire un texte cohérent et lisible. Vous pouvez utiliser les outils qui vous sont familiers, si vous avez déjà fait de la publication sur le web. Les outils principaux de PPing produisent également du HTML qui n'a besoin que de quelques retouches pour être valable et plaisant. Enfin, vous pouvez utiliser PG2HTML sur votre texte seul pour produire un HTML très élémentaire, qu'il vous reste ensuite à améliorer.

Demandez de l'aide dans le forum de Post-Processing. De nombreuses personnes ont appris l'HTML pour la première fois ici, alors qu'elles commençaient le post-processing, et ce n'est en définitive pas très difficile!

Sinon, vous pouvez poster dans le pool HTML, en donnant quelques détails sur votre projet: certains de nos membres aiment faire des versions HTML et seront ravies de produire l'HTML à votre place.

L'HTML est indispensable si le projet comporte des illustrations. Il est également très utile pour les projets comprenant de nombreuses notes en bas de page (grâce aux liens hyper-texte), ou des alphabets autres que latin (comme le grec, qui peut être codé de manière à s'afficher directement en caractères grecs). Même si votre projet n'a rien de tout ça, de nombreux lecteurs trouveront un fichier HTML plus lisible que le texte seul, et donc ça vaut toujours la peine de produire une version HTML si possible.

Si vous faites une version HTML, veillez à ce que la balise <title> contienne l'expression The Project Gutenberg eBook of (titre), by (auteur). Par exemple, si le projet est "A Chrismas Carol", par Charles Dickens, il faut que le titre soit: <title>The Project Gutenberg eBook of A Christmas Carol, by Charles Dickens</title>

Lilypond

C'est utilisé pour représenter de la musique – demandez à la Music Team.

LaTeX

Utilisé pour les formules mathématiques – voyez la section sur le LaTeX plus bas, ou contactez la LaTeX team.

TEI

C'est un style de marquage utilisé pour générer à partir d'un même fichier des versions en texte, HTML et en d'autres formats, grâce à des convertisseurs automatiques. PG n'utilise pas le standard complet, mais définit progressivement un sous-ensemble. À ce jour, PG accepte les projets soumis au format PG-TEI. Si le projet est un document PG-TEI valide, David Widger, de l'équipe des White-washers, prend le fichier .tei et génère les versions en texte seul, HTML et PDF. Vous pouvez utiliser l'un des convertisseurs en ligne sur le site PG-TEI (il y en a un pour le texte, un pour HTML et un pour PDF) pour voir à quoi pourra ressembler les formats dérivés. Ce processus est nouveau, et est susceptible de délais de traitement et de modifications mineures. Voyez les détails dans le wiki PGTEI. Ou alors vous pouvez utiliser les outils TEI chez vous, mais soumettre le résultat après conversion (texte seul, HTML et d'autres formats si vous le souhaitez). Cette dernière façon de faire pose probablement moins de problème, et ainsi vous avez un meilleur contrôle sur l'apparence finale de votre livre.

PDF

Ce format est utile pour certains projets (par exemple en LaTeX) qui bénéficient de la représentation en pages de taille fixe, et de l'emport de polices de caractères spécialisées; il est moins utile dans d'autres cas, car il est très difficile de modifier le PDF ultérieurement. Si vous envisagez de faire une version PDF, discutez-en avec un tuteur de PP ou le responsable de projet. (Notez que le PDF est l'un des formats créés automatiquement à partir d'un document maître en PG-TEI).

DOC, ou autres formats propriétaires

Le Projet Gutenberg accepte ces formats, mais préfère les éviter. Les problèmes de compatibilité entre versions de logiciel se posent plus souvent qu'avec des formats comme le texte seul ou l'HTML. Si vous envisagez d'utiliser un format inhabituel, discutez-en avec un tuteur de PP ou le responsable de projet.

Unicode, UTF-8, UTF-16, etc.

Vous pouvez produire un fichier UTF-8 si vous avez besoin de représenter des caractères qui ne sont pas dans le jeu de caractères Latin-1. C'est probablement inutile si vous avez un seul mot contenant un œ, mais si votre projet contient une certaine quantité de grec ou d'autres caractères, la version UTF-8 préservera le contenu de la façon la plus fidèle possible. La plupart des outils de PPing supportent UTF-8. Demandez également dans le forum Post-Processing si vous avez besoin d'aide. UTF-16 est un autre codage pour représenter pratiquement la même information: demandez dans le forum si vous pensez avoir besoin d'utiliser UTF-16, car il y a probablement d'autres solutions.

Si vous produisez un fichier texte en UTF-8, nommez le fichier machin-utf8.txt lorsque vous l'envoyez pour PPV. Cela aidera le PPVer, et c'est également un demande des White-washers de PG. Les WWers ont un script qui convertit automatiquement les caractères UTF-8 en équivalent Latin-1 et ASCII, donc si vous pensez que ce processus fournira un résultat valable (ce qui est généralement le cas pour les caractères comme œ, š, ĭ etc.) il n'est pas nécessaire de soumettre en plus de la version UTF-8 des versions en latin-1 et en ASCII pur. En revanche si vous avez un livre avec des quantités de ♣, ♠, ♥ et ♦, par exemple, ou en esperanto (où l'accent présent en utf-8 est représenté en ASCII en ajoutant la lettre 'x'), il vous incombe de produire également une version en ASCII (ou en Latin-1). Nommez cette dernière version machin.txt (ou machin-7.txt pour l'ASCII si vous avez en plus une version Latin-1 nommée machin.txt). Assurez-vous que c'est réellement de l'ASCII, et que les caractères UTF-8 ne se sont pas glissés dedans! Et souvenez-vous d'inclure toutes les versions utiles dans votre envoi pour PPV.

Symboles, alphabets, charactères non ASCII, choses carrément bizarres

Demandez dans le forum Post-Processing, avec un lien vers l'image de la page. Vous obtiendrez en retour des opinions variées sur la nature exacte de votre tache d'encre problématique, sa présence en Latin-1, ou UTF-8, ou sur les options de représentation dans divers formats.

Notes en bas de page

  • il y a 18 [1] dans le texte et seulement une note [Footnote 1: ]

Parfois une même note est référencée plusieurs fois. Ce n'est pas un problème, il faut juste s'assurer que tous les [1] pointent vers la même note.

  • appel de note sans note correspondante, ou note sans appel de note.

Si vous pouvez déterminer où devrait aller l'appel de note manquant, le mieux est de le rajouter avec une note du transcripteur. S'il y a un appel sans note correspondante, une simple note du transcripteur est peut-être préférable. Voyez les exemples à la section des Notes du transcripteur.

  • la note en petits caractères est illisible

Si ni vous ni les relecteurs ne peuvent lire la note, contactez le responsable du projet ou le wiki des pages manquantes pour obtenir un meilleur scan.

Notes en marge

Certains PPer paniquent quand ils rencontrent des notes en marge. C'est en général une mauvaise réaction (mais d'un autre côté c'est parfois justifié).

Le cas le plus simple est quand il y a peu de notes en marge, en général une par paragraphe, et le plus souvent au début du paragraphe. Dans ce cas, il suffit de mettre la note juste avant le paragraphe auquel elle correspond. Dans la version en texte seul, il est sans doute préférable de conserver un marquage comme par exemple [En marge: bla bla bla], pour que le lecteur comprenne à quoi il a affaire. Certains PPers préfèrent laisser une ligne blanche entre la note et le paragraphe.

En HTML, il vaut peut-être mieux laisser flotter la note sur le côté. Vous pouvez choisir entre mettre les notes dans la marge (ainsi elles ne perturbent pas la disposition du paragraphe) ou les faire flotter du côté du texte. Il est sans doute préférable de suivre l'original dans la mesure du possible. Si vous faites apparaître les notes dans la marge, vous devrez sans doute utiliser une marge plus large. La version HTML est sans doute plus facile à lire si toutes les notes en marge sont d'un seul côté.

S'il y a de nombreuses notes en marge, avec plus d'une note par paragraphe, la situation se complique. On ne peut pas tout ramener au début du paragraphe sans perdre d'information.

Dans la version texte, on a plusieurs options. Le plus simple est de mettre la note (avec sa marque, par exemple [En marge: bla bla]) au début de la phrase à laquelle elle se réfère. Le texte reste ainsi lisible, mais l'inconvénient est que la note peut être loin du texte auquel elle se réfère si la phrase est très longue. On peut sinon mettre la note au plus près du passage qu'elle commente, mais dans ce cas la lecture est plus difficile. Enfin si les notes sont longues le meilleurs compromis est peut-être de les traiter comme des notes en bas de page, et de les déplacer en fin de paragraphe, en laissant des balises à l'intérieur du paragraphe.

Le placement des notes au milieu des paragraphes est plus facile en HTML, mais il faut prendre garde que deux notes ne se chevauchent pas, en vérifiant dans plusieurs navigateurs à des tailles différentes (les notes peuvent devenir illisibles si elles se chevauchent).

Illustrations

Les illustrations sont ce qui posent le plus de difficultés au début pour de nombreux post-processeurs, et en même temps sont la raison la plus courante pour rendre nécessaire une version HTML. Si vous ne vous sentez pas l'envie de vous attaquer à l'HTML ou de traiter les images, ce n'est pas grave! Demandez dans le pool HTML – il y a beaucoup de gens qui n'aiment pas s'occuper de la partie texte en post-processing.

Encore motivé? Bien!

Certains projets n'ont qu'une image ou deux, comme un portait d'auteur ou un frontispice occupant une page entière. Ces images doivent être redimensionnées, de manière que l'image résultante figure dans le document HTML à l'échelle un (un pixel de l'image résultante correspond à un pixel de ce qui est affiché dans l'HTML).

D'autres projets sont abondamment illustrés, et souvent les illustrations constituent une bonne part de l'intérêt à poster ce livre sur le projet Gutenberg. Dans ce cas il est recommandé de mettre dans le fichier HTML principal des versions de taille réduite des illustrations, chacune pointant sur une image plus grande, de meilleure qualité. Cela permet aux utilisateurs ayant une connection internet de bas débit d'avoir une première impression du livre sans attendre des heures. Vérifiez que le responsable du projet a inclus les illustrations de haute qualité dans le projet. Elles sont situées souvent à la suite des pages scannées, et ont souvent l'extension .jpg.

Une bonne pratique en terme de taille est la suivante: utiliser des images d'environ 400 à 600 pixels pour les images de taille réduite et les illustrations en pleine page, et moins de 1200 pixels pour les images de haute résolution en dehors du fichier HTML principal. L'échelle entre les illustrations doit être respectée. Si l'image la plus large est une illustration pleine page que vous avez réduit à 400 pixels, alors les culs de lampe qui s'affichent à la fin d'un chapitre devraient n'avoir qu'une fraction de cette taille. Le but est de reproduire dans la mesure du possible l'apparence des illustrations dans la page du livre original. Si vous avez besoin de diminuer la taille des fichiers, ou de faire des retouches sur les images, voyez le guide de traitement d'image.

Chantier.png il manque la mention des tailles en octet.

Si même les images de haute résolution sont trop foncées ou endommagées, demandez au responsable de projet de fournir des images en remplacement. Parfois le responsable de projet a fourni le mieux possible pour ce livre. Une autre option est le wiki |pages manquantes, quelqu'un peut peut-être fournir de meilleurs scans des images.

Toutes les images appelées par le fichier HTML final doivent être rangées dans un répertoire nommé images/. Une fois que l'HTML est fini, assurez-vous par une dernière vérification que toutes les images sont appelées par le fichier HTML, et qu'aucun fichier temporaire ou superflu n'est inclus.

Pour toutes les questions ou demandes de conseil au sujet des illustrations, contactez l'équipe des Illustrateurs (certains parlent parfaitement français).

Poésie

À condition que les marques de poésie soient en place correctement, il ne devrait pas y avoir de différence entre le traitement d'un livre de poésie et d'un livre en prose. Assurez-vous de conserver des sauvegardes régulières – ce sera le meilleur moyen de récupérer en cas d'erreur de formatage catastrophique :) Consultez des livres de poésie récemment postés sur PG, pour avoir des idées de présentation (en vous souvenant que la poésie doit toujours être indentée d'au moins deux espaces). Certains outils de PP ont des fonctionnalités particulières dédiées au traitement de la poésie – consultez la documentation de ces outils.

Tableaux

Normalement les tableaux auront déjà été formatés avec soin par les tours de formatage, et respecteront les règles édictées par PG (moins de 75 caractères de large, au pire 80 caractères dans les cas désespérés). Si vous avez besoin d'aide sur une table, ou que vous avez des questions sur la représentation des tables en HTML, voyez l'équipe Turn the Tables.


Grec

Le grec aura normalement fait l'objet d'une translittération lors de la relecture (il sera représenté avec des lettres de l'alphabet latin). Il y a plusieurs façons de traiter le grec en post-processing.

Dans la version en texte seul, vous pouvez laisser la translittération, et même retirer le marquage [Greek: ] (ou au minimum le traduire [Grec: ]). Vous pouvez également utiliser votre propre marquage, comme par exemple +, en mentionnant dans ce cas sa signification dans une note du transcripteur. Ou bien, si vous avez de nombreux passages en grec ou utilisant d'autres lettres inhabituelles, vous pouvez produire une version UTF-8, avec les vrais caractères grecs. Demandez dans le forum si vous voulez de l'aide. Il est possible également d'obtenir des réponses très rapides pour de courts passages, via Jabber.

Dans le fichier HTML, vous pouvez représenter les lettres grecques par des entités HTML, ou faire un HTML en UTF-8. Il est conseillé d'inclure le grec dans un <span> et de mettre la translittération dans l'attribut "title", de telle sorte que la translittération peut être lue même si le navigateur n'affiche pas les caractères grecs (ou si le lecteur ne lit pas le grec):

<span title="Hyposêmeiôsê">Υποσημείωση</span>

Encore une fois, demandez de l'aide si vous en avez besoin. Il y a vraiment des gens qui aiment faire ça!

Passages occasionnels en d'autres langues

Consultez la Language Skills List. Ne vous laissez pas rebuter par le fait que les discussions semblent au point mort dans une équipe dédiée à une langue particulière – peut-être que votre question dans le forum de cette équipe sera juste ce qu'il faut pour lancer une discussion utile et conviviale dans cette communauté.

Index

Conservez les numéros de page dans l'index, même dans la version en texte seul. Il est très facile dans la version HTML de lier les numéros vers les ancres de pages (consultez la documentation de vos outils de post-processeur). Si vous avez un grand nombre de numéros de page à convertir semi-automatiquement en lien le plus simple sera d'utiliser une expression régulière (demandez dans la clinique des expressions régulières). Il faudra vérifier quand même que des nombres autres que les numéros de page n'auront pas été transformés en lien automatiquement. Voyez aussi l'équipe Junkies, Index.

Pages d'errata

Elles doivent être incluses. Il y a deux façons de les traiter: vous pouvez laisser le lecteur reporter les corrections, ou vous pouvez appliquer les corrections au fil du texte et le signaler par une note du transcripteur. Le choix vous appartient, en fonction du type de projet. Simplement ne faites pas de correction silencieuse, et n'omettez pas les errata.

Une possibilité en HTML consiste à afficher le texte corrigé, et utiliser un <span> pour signaler qu'un mot a été corrigé, le texte avant correction apparaissant dans une bulle lorsque la souris passe au-dessus du mot corrigé. Consultez des exemples ou demandez dans le forum PP.

Un problème une fois que le livre a été posté

Pas de panique! C'est déjà arrivé à chaque PPer. Si ça n'est pas déjà arrivé à quelqu'un, cela lui arrivera, faites-moi confiance ;)

Si le livre a été posté sur PG très récemment (au cours des deux dernières semaines), contactez votre PPVer et indiquez-lui le problème. Le PPVer relayera l'information au Whitewasher qui a posté le projet, et qui sera le plus à même de faire la correction.

Si le livre a été posté depuis plus de temps, contactez errata2017@pglaf.org. C'est l'adresse mail principale pour suggérer des corrections. Mentionnez que vous êtes le post-processeur de ce livre, incluez le numéro de texte PG, le titre et l'auteur, et une description claire du problème et de la façon de le corriger. Si vous avez vérifié sur les pages scannées, mentionnez-le également.

Qu'est-ce qui change pour...

Périodiques

De nombreux périodiques ont un style standard pour la version texte et HTML, permettant d'obtenir une présentation homogène pour l'ensemble des numéros. Vérifiez dans le forum des überprojets si votre périodique fait partie d'un überprojet, et suivez les recommandations pour ce projet.

de nombreuses personnes hésitent à relire, formater ou effectuer le post-processing des périodiques parce qu'elles imaginent que ces projets sont difficiles. Les post-processeurs rusés en profiteront, dès qu'ils auront acquis la maîtrise du style d'un périodique particulier, puisqu'ils auront ainsi accès à de nombreux projets amusants avec peu de concurrence. Un guide de style lève les hésitations perpétuelles que l'on peut avoir, comme par exemple de décider s'il faut noter un titre avec <h2> or <h3>. Les périodiques ont souvent des pages plus longues, et des publicités ou des points de formatage spéciaux. Les problèmes inhabituels de formatage auront déjà été rencontré sur les volumes précédents, et une solution aura généralement été définie dans le fil de discussion de l'überprojet. Sinon, demandez une clarification dans ce forum.

Le dernier volume d'un périodique apparu sur PG sera généralement une excellente source d'inspiration (encore mieux si ce volume a été traité par DP, cela assure la meilleure homogénéité de style).

Théâtre

de nombreuses personnes hésitent à relire, formater ou effectuer le post-processing des pièces de théâtre parce qu'elles imaginent que ces projets sont difficiles. Bien sûr parfois c'est effectivement difficile, comme par exemple des pièces en français du dix-septième siècle avec l'orthographe de l'époque. Mais en général le théâtre ne pose pas de difficulté particulière.

Pour toutes les pièces, calquez votre version texte sur les directives de formatage.

Formatez les noms des personnages de manière aussi proche que possible du livre original. Si la pièce est en vers, faites particulièrement attention aux marques /* */ avant de replier les lignes (il est parfois plus simple de replier à la main les quelques parties en prose qui le nécessitent, par exemple quelques indications scéniques).

Il y a diverses façons de formater les pièces de théâtre en HTML. Vous trouverez des idées en regardant des exemples récemment postés sur PG, ou en demandant dans le forum Post-Processing. Il existe également une équipe nommée Plays The Thing. Dans l'idéal, obtenez un rendu aussi proche de l'original qu'il est possible raisonnablement de le faire.

Überprojets

Vous trouverez ici une liste des grands projets, comprenant de nombreux volumes, et qui seront probablement présents sur DP pour de nombreuses années.

Voir aussi la section périodiques.

Musique

Consultez tous les détails sur la page Music Guidelines (en anglais).

DP poste régulièrement sur PG des livres contenant des parties de musique, grandes ou petites. Une façon simple de procéder en HTML est d'inclure les partitions comme des illustrations. Mais on peut apporter de la valeur au livre final en transcrivant la musique dans un format électronique, qui offre les avantages suivants:

  • une partition plus propre, en HTML
  • un fichier midi, si bien que le lecteur sur PG peut écouter la musique
  • facilité d'éditer la musique.

DP utilise couramment le format GNU LilyPond, un format ouvert dans une notation texte, concise et expressive. Lilipond, en tant que texte, peut être saisi directement avec les mécanismes classiques sur DP. Il existe d'autres façons de transcrire la musique, surtout si la transcription est faite en dehors des tours de relecture. Les éditeurs graphiques comme Finale, Sibelius, NoteEdit, Noteworthy Composer, ou Harmony Assistant peuvent être utilisés à ces fins, et ont également l'avantage de permettre un export au format MusicXML, le standard actuel de notation musicale portable.

Pour demander de l'aide pour une transcription de musique, demandez simplement à l'équipe Music team.

Il est recommandé d'inclure, dans au moins une des versions, la source la plus portable, en particulier pour des partitions complètes. Idéalement cette source serait en MusicXML, mais nous ne produisons pas ce format le plus souvent.

Pour les projets en Lilypond avec de grandes parties de musique, la meilleure façon de procéder est de fournir un fichier lilypond. Les fragments courts peuvent être inclus sous forme de commentaires HTML, ou comme valeur de l'attribut alt des images utilisées pour représenter les partitions.

Maths (LaTeX)

LaTeX est un outil précieux pour la mise en page de formules mathématiques.

ce format est utilisé principalement dans les projets contenant des mathématiques ou des notations scientifiques qui ne peuvent pas simplement être représentées dans d'autres formats.

Vous pouvez obtenir de l'aide sur LaTeX à différents endroits:

  • dans les liens figurant dans certains commentaires de projets
  • les discussions de la LaTeX team, sur l'usage de LaTeX et les standards à respecter sur DP
  • des guides LaTeX sur Internet (demandez des conseils à la LaTeX team).

Les fichiers postés sur PG doivent toujours inclure le code source LaTeX, de préférence dans un fichier unique (incluant des remarques et des instructions de compilation détaillées), ainsi que toutes les illustrations (dans un répertoire "images"). Le code source doit pouvoir être traité sur une installation LaTeX "standard", parce que c'est ce que les whitewashers utiliseront pour générer la version PDF.

Langues étrangères

Vous souhaiterez sans doute parler la langue, ou obtenir d'une personne dont c'est la langue maternelle qu'elle fasse la correction orthographique et/ou une lecture courante. Cependant, pour certaines langues, il y a peu voire pas du tout de personnes maîtrisant cette langue sur le site. Ces projets peuvent être choisis par des personnes qui sont prêtes à fournir l'effort supplémentaire de traiter une langue qu'elles ne connaissent pas. Vérifiez la liste des compétences linguistiques pour trouver à qui demander des conseils et de l'aide.

Lorsque vous fournissez une version de votre texte en Latin-1, il n'est pas nécessaire de fournir une version ASCII (même si la FAQ de PG dit le contraire!) PG possède les outils pour faire facilement une version ASCII à partir du Latin-1. Cependant si la version idéale ASCII serait différente de ce qui serait obtenu en effectuant des conversions standard comme ü -> ue, é -> e, etc., vous devriez produire une version ASCII vous-même. Si c'est le cas, expliquez pour quelle raison vous avez fait une version ASCII (les PPVers relayeront cette explication aux gens de PG).

Comme PPer, vous avez une certaine latitude pour décider de la meilleure façon de représenter votre texte. Pour les textes qui ne sont pas en anglais, une typographie particulière peut provoquer de nombreuses erreurs de gutcheck. Si vous avez une bonne raison d'utiliser une présentation particulière, et si vous avez appliqué cette présentation de façon homogène et cohérente, alors vous pouvez ignorer ces erreurs (et seulement celles-ci). Vous pouvez indiquer ce point dans vos notes à destination du PPVer. Par exemple, dans de nombreuses langues il paraît plus naturel d'avoir des espaces autour des tirets. Il est parfaitement acceptable de laisser ou d'ajouter ces espaces si vous le choisissez.

Vous devriez remplacer les marques en anglais présentes dans le texte final par une version dans la langue majoritaire du texte. Par exemple Footnote / Fußnote / Note / Ootnotefay / Υποσημείωση / Voetnoot / Nota de rodapé.

Liens

To comment or request edits to this page, please contact lhamilton or hdmtrad.

Return to DP Official Documentation Menu