Mettre l'en-tête en minuscule

Dans les messages précédents, je me suis occupé des questions posées ici (en-têtes et couleurs) et comme j'étais pressé, j'ai mis à la va-vite des paramètres un peu bidon pour les marges (configuration du package geometry). Je vais essayer de réparer un peu ça, mais ce n'est pas très simple car le diable est dans les détails et il y a de plus dans ces choix-là une dimension esthétique et typographique importante qui n'est in fine pas de mon ressort (ce n'est pas mon document).

Le premier problème, c'est qu'en réglant les marges au jugé, on obtient souvent des lignes assez longues qui ne sont pas faciles à lire (réflexe de remplir « raisonnablement » la largeur de la page...). J'en ai déjà un peu parlé dans un fil récent [1].

Le deuxième problème, c'est qu'avec la mise en page du message précédent, on a des underfull \vbox trop facilement. Pourquoi ? Parce qu'en gros — cela sera précisé plus bas —, la hauteur du bloc de texte principal n'est pas multiple de la hauteur d'une ligne. Il en résulte que si une page ne contient que du texte et peu de sauts de paragraphes, il n'y a pas assez d'élasticité totale dans l'ensemble des espaces verticaux du bloc de texte principal pour permettre à TeX de le remplir complètement.

Par défaut, l'espacement vertical entre deux paragraphes consécutifs, que TeX appelle \parskip, a une longueur naturelle nulle (et il peut être un peu étiré, mais pas démesurément). Un bon empagement exploite ce fait [2] en faisant en sorte qu'une page ne comportant que du texte tout simple ne nécessite ni étirement, ni rétrécissement des espaces verticaux. Or, si vous compilez le document du message précédent, vous verrez qu'on a un underfull \vbox dans les pages remplies qui ne contiennent que du texte : aucun titre, aucune figure ou table, aucune formule mathématique en mode display (c'est-à-dire entrée avec $\text{\[}$ ... $\text{\]}$ ou équivalent), etc. Les pages contenant des titres dans cet exemple s'en sortent vraisemblablement par chance. Ce n'est pas du très bon travail, et l'on peut faire mieux pour les pages ne contenant que du texte (avec éventuellement des sauts de paragraphes) : puisque la longueur naturelle de \parskip est nulle, il suffit de faire en sorte que le bloc de texte principal ait une hauteur correspondant à un nombre entier de lignes. Quant aux autres pages, il est généralement plus facile d'y trouver de l'élasticité dans les espacements verticaux afin de satisfaire la contrainte de remplissage : elles suivront.

Pour permettre cette amélioration de notre empagement, le package 'geometry' offre l'option 'lines=...' qui permet de spécifier la hauteur du bloc de texte principal en nombre de lignes au lieu de donner une longueur ou une fraction de la hauteur du papier (veiller à régler la taille de la police avant de configurer 'geometry'). On peut aussi calculer cette hauteur manuellement ou avec LaTeX, à partir du moment où l'on a décidé du nombre de lignes : il suffit d'utiliser le fait que la hauteur du bloc de texte principal (excluant en-tête et pied de page) est égale à
\[ \text{\topskip} + (\text{nombre de lignes} -1) \times \text{\baselineskip} \]
(ceci est dû au fait que la ligne de base de la première ligne d'une page commence à une distance \topskip de la limite supérieure du bloc de texte principal, et que l'on ignore les descendantes de la dernière ligne, c'est-à-dire que l'on considère que la ligne de base de la dernière ligne d'une page doit coïncider avec la limite inférieure du bloc de texte principal).

Comme on le voit, puisque la valeur par défaut de \baselineskip dépend de la police, ce calcul dépend des dimensions de la police et aussi du nombre de lignes (donc de la hauteur) que l'on est prêt à accorder au bloc de texte principal. Il n'y a donc pas vraiment de règle universelle et très simple que l'on peut appliquer les yeux fermés.

Markus Kohm, l'auteur du document référencé en [1], décrit deux méthodes d'empagement et permet, grâce à son package 'typearea', de faire faire les calculs automatiquement par LaTeX. Ceci par exemple avec :

\usepackage[headinclude=true,footinclude=false,BCOR=0mm,DIV=calc]{typearea}

à la place des lignes \usepackage{geometry} et \geometry{...}.

• Le 'headinclude=true' signifie que, pour le calcul de la taille du bloc d'empagement, l'en-tête est considéré comme en faisant partie [3].
• 'footinclude', c'est kif-kif pour le pied de page (ici, on ne met rien dans les pieds de page, c'est pourquoi j'ai mis 'false').
• 'BCOR', c'est la binding correction, c'est-à-dire l'espace horizontal perdu, pour une page donnée, du fait de la reliure (partie où les feuilles sont collées les unes aux autres). Une fois le document relié, la partie visible d'une page a même hauteur que la page physique, mais sa largeur vaut $\text{largeur papier} - \mathit{BCOR}$ (voir les équations p. 28 [“Fundamentals of Page Layout”] de la documentation en anglais de KOMA-Script et des packages associés, comme justement 'typearea').
• Le paramètre 'DIV', c'est pour contrôler la taille du bloc d'empagement, déterminée par la méthode de division exposée en [1]. 'DIV=calc' demande au package 'typearea' de calculer automatiquement une taille telle que la largeur de ligne soit jugée acceptable et le rapport hauteur/largeur du bloc d'empagement soit le même que celui de la page visible (« partie visible d'une page » telle que définie au point précédent).
  
  Dans le fichier .log produit lorsque l'on compile le document LaTeX, on peut voir la valeur de DIV calculée par 'typearea' et même les différentes longueurs mises en jeu [4]. Dans l'exemple ci-dessous, 'typearea' trouve la valeur 8 ($\text{DIV} = 8$). On peut mettre une valeur explicite dans l'appel \usepackage[...]{typearea}. Plus DIV est grand, plus le bloc d'empagement l'est par rapport à la page visible. Cela se comprend facilement en considérant le schéma p. 30 de [1], réalisé pour $\text{DIV} = 9$.
• Il y a quelques autres options que l'on peut passer à 'typearea', par exemple pour spécifier le nombre de lignes de l'en-tête.

Pour que tout cela fonctionne bien, il faut que la taille de la police et l'espacement entre les lignes soit connus de 'typearea', donc faire ces réglages avant de charger 'typearea', ou bien lui faire recalculer explicitement les dimensions du bloc d'empagement une fois que la taille de la police et l'espacement entre les lignes ont été fixés (cf. \recalctypearea dans [1]).

Cela étant dit, on n'est évidemment pas obligé d'utiliser 'typearea' et il est toujours possible d'utiliser le package 'geometry' en lui passant l'option 'lines=...', ou bien le résultat de calculs faits à la main ou avec LaTeX. Dans l'exemple suivant (la suite de celui du message précédent), je demande à 'geometry' d'utiliser à un pouillème près la largeur de texte précédemment calculée par 'typearea' (pour la police lmodern en taille 11 points), le reste étant réglé un peu au pif ; mais cette fois-ci, la hauteur du bloc de texte principal est donnée en nombre de lignes, ce qui évite au moins le problème d'underfull \vbox évoqué ci-dessus dans les pages totalement remplies ne contenant que du texte (pas de formule mathématique en mode display, pas de titre, etc.). Il peut évidemment rester occasionnellement des petites difficultés de remplissage du bloc de texte principal, mais cela dépend du contenu précis du texte, des éventuels titres, des dimensions choisies, etc.

Autrement, vous pouvez toujours commenter les lignes relatives à 'geometry' dans cet exemple et décommenter celle de la forme \usepackage[...]{typearea} si vous voulez voir ce que produit 'typearea' (pas sûr que vous en acceptiez les marges, c'est pourquoi j'ai laissé la méthode avec 'geometry' non commentée :-)). Voici donc le document complet, avec ces petits changements par rapport au message précédent (ah oui, j'oubliais : j'ai aussi utilisé le package 'titlesec' pour introduire un peu plus d'espacement vertical élastique dans les pages démarrant un chapitre, sinon LaTeX a du mal à les remplir tout en respectant la contrainte de hauteur du bloc de texte principal — le diable est toujours dans les détails !).

\documentclass[a4paper,11pt,french]{book}
\usepackage{lmodern}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage{babel}
\usepackage{textcomp}

\usepackage{geometry}
\geometry{top=4cm, headsep=1cm, lines=42, width=374pt, inner=3cm,
          marginparwidth=3.5cm, marginparsep=0.5cm, includemp=false}
% Pour tester 'typearea' (calcul automatique des marges, etc.), commenter les
% trois lignes précédentes relatives à 'geometry' et décommenter la suivante.
%\usepackage[headinclude=true,footinclude=false,BCOR=0mm,DIV=calc]{typearea}

\usepackage{kantlipsum}
\usepackage[svgnames]{xcolor}
\usepackage{titlesec}
\usepackage{fancyhdr}

\definecolor{unCertainBleu}{RGB}{37,29,118}

% Cette indirection est facultative mais plus propre à mon avis. Par exemple,
% si on est limité à des couleurs spécifiques (contrainte imprimeur, charte
% graphique, etc.), on les définit d'abord comme 'unCertainBleu' ci-dessus,
% puis on les affecte aux différents rôles dont on a besoin.
\colorlet{couleurEnTeteChapitres}{DarkRed} % couleur définie par le standard SVG
\colorlet{couleurEnTeteSections}{unCertainBleu}
\colorlet{couleurPage}{yellow!9!white} % mélange de deux couleurs

\pagecolor{couleurPage}         % colore le fond de chaque page

% Simule la présentation du “LaTeX book” (le livre de Lamport). Ceci vient de
% la doc. de fancyhdr (“Two book examples”) avec modification minime pour
% afficher « Chapitre : » dans l'en-tête (ainsi qu'il a été demandé) en
% respectant la langue choisie avec babel.
\pagestyle{fancy}
\addtolength{\headwidth}{\marginparsep}
\addtolength{\headwidth}{\marginparwidth}
% À ajuster en fonction de la taille de la police utilisée dans les en-têtes :
\setlength{\headheight}{13.6pt}
\renewcommand{\chaptermark}[1]{\markboth{#1}{}}
\renewcommand{\sectionmark}[1]{\markright{\thesection\ #1}}

\fancyhf{}
\fancyhead[LE,RO]{\textbf{\thepage}}
\fancyhead[LO]{%
  \textcolor{couleurEnTeteSections}{%
    \textbf{\rightmark}}}
\fancyhead[RE]{%
  \textcolor{couleurEnTeteChapitres}{%
    \textbf{\chaptername~\thechapter{} : \leftmark}}}
\fancypagestyle{plain}{%
  \fancyhead{} % get rid of headers
  \renewcommand{\headrulewidth}{0pt} % and the line
}

% Petit bricolage : par défaut, un nouveau chapitre commence sur une page
% impaire dans la classe book. Les quatre lignes qui suivent font en sorte que
% les pages (toujours paires) qui peuvent être insérées pour « remplir » dans
% un tel cas soient toujours totalement blanches. Sinon, on a l'en-tête
% défini par le style 'fancy'.
\let\cleardoublepageORI\cleardoublepage % sauvegarde de la commande d'origine
\renewcommand{\cleardoublepage}{% cf. doc de fancyhdr, “Those blank pages”
  \clearpage
  {\pagestyle{empty}\cleardoublepageORI}}

% Configuration de 'titlesec'. Les définitions suivantes correspondent à ce
% que font les classes LaTeX standard, à deux exceptions près :
%   1) On laisse un alinea à tous les paragraphes, même le premier suivant un
%      titre (convention française à laquelle n'adhèrent pas les
%      anglo-saxons).
%   2) On donne un peu d'élasticité aux espaces verticaux insérés par \chapter,
%      sinon il est très difficile de remplir le bloc d'empagement.
\titleformat{\chapter}[display]
  {\normalfont\huge\bfseries}{\chaptertitlename\ \thechapter}{20pt}{\Huge}
\titleformat{\section}
  {\normalfont\Large\bfseries}{\thesection}{1em}{}
\titleformat{\subsection}
  {\normalfont\large\bfseries}{\thesubsection}{1em}{}
\titleformat{\subsubsection}
  {\normalfont\normalsize\bfseries}{\thesubsubsection}{1em}{}
\titleformat{\paragraph}[runin]
  {\normalfont\normalsize\bfseries}{\theparagraph}{1em}{}
\titleformat{\subparagraph}[runin]
  {\normalfont\normalsize\bfseries}{\thesubparagraph}{1em}{}

\titlespacing{\chapter}{0pt}
  {50pt plus 2pt minus 2pt}{40pt plus 1.5pt minus 0.25pt}
\titlespacing{\section}{0pt}{3.5ex plus 1ex minus .2ex}{2.3ex plus .2ex}
\titlespacing{\subsection}{0pt}{3.25ex plus 1ex minus .2ex}{1.5ex plus .2ex}
\titlespacing{\subsubsection}{0pt}{3.25ex plus 1ex minus .2ex}{1.5ex plus .2ex}
\titlespacing{\paragraph}{0pt}{3.25ex plus 1ex minus .2ex}{1em}
\titlespacing{\subparagraph} {\parindent}{3.25ex plus 1ex minus .2ex}{1em}

\title{Petits essais}
\author{}
\date{}

\begin{document}
\maketitle

\chapter{Un chapitre}

\marginpar{Une petite note dans la marge : a a ar ar ar ar ar aer ar ze ze ze
  z z z z ztztze e ae aer aer aer e aer ae ear aer er aer ae raer ear aer ar.}
\kant[1-10]

\section{Une section dans le premier chapitre}

\kant[11-15]

\section{Autre section dans le premier chapitre}

\kant[15-19]

\chapter{Autre chapitre}

\kant[20-26]
\end{document}

[1] Si vous avez le temps, je recommande toujours la lecture de la documentation de KOMA-Script (manuel en anglais ; si vous lisez bien l'allemand, choisissez plutôt l'original). Notamment “Calculating the Page Layout with typearea” p. 27 et suivantes du manuel actuel en anglais.

[2] L'empagement consiste à déterminer les dimensions et l'emplacement du bloc de texte principal (et j'imagine aussi de l'en-tête et du pied de page lorsqu'on ne les considère pas comme faisant partie du bloc d'empagement).

[3] C'est subjectif, ça dépend s'il fait « corps » avec le bloc de texte ou pas... et certains auteurs ont l'air de considérer que ça ne doit jamais être le cas. Bref, ça se discute. ;-)

[4] \paperwidth, \paperheight, \textwidth, \textheight, \evensidemargin, \oddsidemargin, \topmargin, \headheight, \headsep, \topskip, \footskip, \baselineskip.

Edit : plusieurs reformulations pour plus de clarté, à partir du paragraphe commençant par « Le deuxième problème, c'est qu'avec la mise en page du message précédent (...) ».

Attention, c'est \textcolor, pas \textecolor.

Il faut comparer ligne à ligne, ou bien réduire votre exemple à quelque chose de minimal qui compile (en supprimant tout ce qui n'est pas nécessaire pour reproduire le problème) et le poster ici après avoir cliqué sur l'icône « Code formaté » du forum. Il y a aussi certainement des erreurs rapportées par LaTeX quand ça ne fonctionne pas. Il faudrait les regarder et éventellement les poster ici, avec la balise « code » susmentionnée.

Ce sont les lignes suivantes qui donnent la couleur dans mon exemple :

\usepackage[svgnames]{xcolor}

\definecolor{unCertainBleu}{RGB}{37,29,118}

% Cette indirection est facultative mais plus propre à mon avis. Par exemple,
% si on est limité à des couleurs spécifiques (contrainte imprimeur, charte
% graphique, etc.), on les définit d'abord comme 'unCertainBleu' ci-dessus,
% puis on les affecte aux différents rôles dont on a besoin.
\colorlet{couleurEnTeteChapitres}{DarkRed} % couleur définie par le standard SVG
\colorlet{couleurEnTeteSections}{unCertainBleu}
\colorlet{couleurPage}{yellow!9!white} % mélange de deux couleurs

\pagecolor{couleurPage}         % colore le fond de chaque page

\fancyhead[LO]{%
  \textcolor{couleurEnTeteSections}{%
    \textbf{\rightmark}}}
\fancyhead[RE]{%
  \textcolor{couleurEnTeteChapitres}{%
    \textbf{\chaptername~\thechapter{} : \leftmark}}}

Pourquoi n'utilisez-vous pas fancyhdr, c'est quand-même pas mal fichu ? On peut peut-être faire ce que vous proposez (y'a qu'à essayer...) mais je remplacerais au moins

\markboth{\slshape bla bla}{...}

par

\markboth{\textsl{bla bla}}{...}

car les accolades (les plus extérieures) de \markboth{...}{...} délimitent les arguments de la commande \markboth, mais pas un groupe au sens de TeX ; autrement dit, il se pourrait qu'avec votre version, \slshape affecte plus de choses que ce que vous croyez (cela dépend in fine de l'implémentation de \markboth). Autrement, on peut limiter la portée du \slshape en mettant soi-même des accolades délimitant un groupe, comme ceci :

\markboth{{\slshape bla bla}}{...}

Là, on est sûr de la portée du \slshape. Mais je préfère la séparation contenu / formatage avec la méthode de 'fancyhdr' (\markboth et \markright définissent ce que j'appelle le contenu, i.e., les titres non trafiqués ; les commandes comme \fancyhead et \fancyfoot, quant à elles, peuvent utiliser ces « variables » pour réaliser la mise en page souhaitée : c'est là que je mettrais les modifications de forme telles que \slshape). Mais bon, si vous ne pouvez vraiment pas utiliser fancyhdr...

Edit : correction typo juste au-dessus ('fanchdr' remplacé par 'fancyhdr', comme il se doit).

Ravi de l'entendre. :-)