Comment supprimer les badbox ?

Bonjour à vous,

Je ne sais pas si c'est normal, mais lors de la compilation, je me retrouve avec plein de messages bizarres
(mais qui n'empêche pas que la compile marche...). Je me demandais s'il y avait un moyen simple
de les supprimer (j'en ai une bonne centaine)? ou bien faut-il les garder, car ils n'ont pas de conséquences sur le pdf ?

Les messages en questions sont :

\headheight is too small (12.0pt):Make it at least 14.49998pt.
Underfull \hbox (badness 10000) in paragraph at lines 81--82
W0024(minitoc(hints)) Some hints have been written(minitoc(hints)) in the Test1.log file.

Merci par avance pour votre précieuse aide.

Réponses

  • Bonjour,

    En général, les “bad boxes” ne sont pas très bonnes pour l'apparence du document, pour sa lisibilité. Une overfull hbox, ça veut dire que quelque part, TeX doit mettre des trucs (lettres, chiffres, images... peu importe : ce sont toutes des boîtes pour TeX) les uns à la suite des autres horizontalement[1] et que la tâche s'avère impossible car le contenu est trop large pour le contenant (la boîte qui est “overfull”). Conséquence : le contenu va dépasser, et TeX précise toujours de combien, en points (pt).

    Une manière très simple de générer un overfull hbox consiste à mettre un \mbox{truc très très très long ici} au sein d'un paragraphe. Ce \mbox{...} forme une boîte très longue (horizontalement) qui, si on l'a bien remplie, ne peut pas rentrer dans la boîte horizontale définissant la ligne courante (de largeur \linewidth), donc la boîte \mbox{...} va nécessairement déborder dans la marge droite (les boîtes peuvent être mises les unes dans les autres comme des poupées russes, c'est ce qui se passe avec les caractères au sein de chaque ligne d'un paragraphe).

    N.B. : les espaces inter-mots ne sont pas des boîtes, ce sont des “ressorts” qui peuvent, dans une certaine mesure, s'étirer ou se rétrécir relativement à leur longueur naturelle (c'est-à-dire celle qu'ils prennent à l'intérieur d'un \mbox{...}). D.E. Knuth, dans le TeXbook, appelle ça de la glue (= colle). Donc une hbox correspondant à une ligne de paragraphe standard contient des boîtes correspondant aux caractères, collées les unes aux autres au sein d'un mot, et séparées par morceaux de “glue”, que certains francophones appellent « ressorts » (ce sont des espaces étirables).

    Overfull vbox, c'est kif-kik mais dans la direction verticale. Pour en produire un, il suffit d'insérer une boîte plus haute que \textheight, par exemple une image très haute ou une boîte quelconque (lettre, etc.) mise à l'échelle avec \scalebox.

    Les underfull hbox ou vbox, c'est la situation inverse : TeX a reçu comme consigne de bien remplir une boîte (horizontalement pour une hbox, verticalement pour une vbox), c'est-à-dire d'un bord à l'autre, mais le contenu ne le permet pas, soit parce qu'il n'y a pas de glue à l'intérieur, soit parce qu'il faudrait, pour remplir la boîte, étirer la glue plus qu'autorisé. On voit des underfull hbox typiquement quand on compose un paragraphe avec une \linewidth assez petite, par exemple dans une colonne étroite d'un tableau et/ou avec des mots plutôt longs dont les points de césure, s'il y en a, ne tombent pas au bon endroit pour permettre de couper les lignes convenablement. Ceci est dû au fait que par défaut, TeX comme LaTeX justifient toutes les lignes d'un paragraphe sauf la dernière. Pour les underfull vbox, c'est pareil : au moins dans la classe book si je me souviens bien, les pages sont par défaut toutes de même hauteur sauf la dernière, ce qui conduit à rétrécir ou étirer les espaces verticaux le permettant... dans les limites autorisées. Si l'on met des boîtes (images p. ex.) qui prennent beaucoup de place verticalement et/ou s'il y a des points de coupure interdits ou découragés (p. ex. après un titre), alors la tâche de remplissage d'une page peut s'avérer impossible sans étirer démesurément les espaces verticaux étirables (p. ex. ceux définis par \parskip entre deux paragraphes), d'où un underfull vbox.

    De manière plus pratique, TeX indique dans sa sortie ou ça se passe quand il y a un tel problème, et l'option draft de \documentclass conduit LaTeX à placer des rectangles noirs aux endroits en question pour aider à localiser ces problèmes (c'est pour ça que je passe explicitement l'option 'final' au package microtype, sinon quand je passe 'draft' à \documentclass pour voir les bad boxes, microtype verrait seulement l'option 'draft' et se mettrait à fonctionner en mode “low cost” pour ainsi dire, de sorte que les coupures et lignes et/ou de pages risqueraient fort d'être différentes de la version sans 'draft' ; essayer de supprimer les bad boxes dans ces conditions serait stupide).

    Enfin, il est souvent contreproductif de régler ce genre de problèmes avant la version finale d'un document, car un tas de changements peuvent faire apparaître et disparaître les bad boxes : changement de la taille du papier, des marges, des polices de caractères, ajout ou suppression de texte, reformulation, activation ou changement des options de microtypographie (microtype) telles que l'interlettrage variable, etc.

    Les corrections à apporter sont généralement : reformulation du texte ou action qui ajoute (ou déplace) des points où la coupure de ligne (hbox) ou de page (vbox) est autorisée. Dans certains cas, on ne veut vraiment rien changer mais juste faire disparaître les warnings. On peut alors utiliser \sloppy ou l'environnment sloppypar, voire jouer sur le paramètre TeX \tolerance.

    [1] Normalement de gauche à droite, sauf extensions par rapport au TeX d'origine (celui de D.E. Knuth) pour les langues s'écrivant de droite à gauche, cas que nous exclurons ici.
  • Bonjour Brian,

    Merci pour toutes ces explications.
    Quelles sont les solutions concrètes qui s'offrent à moi pour y remédier (ca fait une semaine que je tape ce rapport sans interruption) et je ne voudrai surtout pas recommencer à zéro.
    Je me permets de vous copier les 1ère lignes de mon programme afin que vous me conseilliez des choses à changer. D'avance merci.
    \documentclass[a4paper, 12pt,fleqn]{book}
    
    \usepackage[left=2cm,right=2cm,top=1.25cm,bottom=1.25cm]{geometry}   
    \usepackage{helvet}  
    \usepackage{fancyhdr}
    \pagestyle{fancy}
    \renewcommand \headrulewidth{0pt}
    \parindent=0pt
    
    \usepackage[french]{babel}
    \usepackage[T1]{fontenc}
    \usepackage[utf8]{inputenc}
    \usepackage{amsmath}
    \usepackage{graphicx}
    \usepackage{xcolor}
    \usepackage{sectsty}
    \usepackage{calc}
    \usepackage[babel=true]{csquotes}
    \usepackage{grffile}
    \usepackage{rotfloat}
    \usepackage{pdfpages}
    \usepackage{minitoc}
    \usepackage{eso-pic}
    \usepackage{enumitem}
    
    \setlength{\fboxrule}{0.5mm}
    \setlength{\fboxsep}{2mm}
    
  • Une façon efficace de produire des underfull hbox, c'est de faire un retour à la ligne avec un double slash plutôt qu'en laissant une ligne vide. Il est facile d'y remédier.
    Un retour à la ligne à éviter.\\
    La suite est mal espacée verticalement et il n'y a pas d'indentation. Pas bon.
    
    Il est pourtant si simple de commencer un nouveau paragraphe (la ligne vide
    ci-dessus !).
    
  • Bonjour Math Coss,

    Vous parlez de ce type de ligne vide ?

    \pagestyle{fancy}

    \renewcommand \headrulewidth{0pt}


    Il faut que je les définisse ainsi ?
    \pagestyle{fancy} \\
    \renewcommand \headrulewidth{0pt} \\
  • Non, je veux dire que plutôt qu'écrire
    Un paragraphe.\\
    Le paragraphe suivant.
    
    il vaut mieux écrire
    Un paragraphe.
    
    Le paragraphe suivant.
    
  • Merci pour la précision.
    En effet, vous avez raison. En supprimant \\ ca fait disparaît Badbox.
    En revanche, comment interprétez vous l'erreur : \headheight is too small (12.0pt):Make it at least 14.49998pt. ?

    Pensez vous qu'à l'impression ca changera quelque chose si je laisse le document comme tel ?
  • 1) Sauf bug du lecteur PDF (ou PostScript) ou dans la chaîne d'impression, ce que tu vois dans la prévisualisation (avec okular, Acrobat Reader, etc.) devrait être imprimé tel quel[1].

    2) “\headheight is too small (12.0pt)” dit bien ce que ça veut dire : tu dis quelque part à LaTeX de mettre des choses dans une boîte de hauteur \headheight qui vaut 12pt à l'endroit en question, mais ces choses sont plus hautes que 12pt. Comme l'indique le manuel de fancyhdr en bas de la page 11 (version en anglais), c'est un problème fréquent avec les classes LaTeX standard en taille 11pt ou 12pt, car (d'après ce document) la hauteur réservée à l'en-tête (le \headheight) est assez faible par défaut. De ton côté, tu mets du 12pt et tu changes la police par défaut, rien d'étonnant à ce qu'il faille adapter \headheight et consorts. Il suffit donc d'augmenter cette hauteur ou de ne pas mettre des choses aussi hautes dans les en-têtes (headers). Pour connaître la valeur de ton \headheight, tu peux utiliser le package layouts :
    \documentclass[...]{...}
    
    (...)
    
    \usepackage{layouts}
    
    \begin{document}
    
    (...)
    
    \showthe\headheight
    % \printinunitsof{cm}{\pagevalues}
    \pagedesign
    \pagediagram
    \pagevalues
    \end{document}
    

    Le \showthe\headheight va aussi afficher la valeur sur la sortie standard de LaTeX et dans le log, comme ça :
    > 12.0pt.
    l.616 \showthe\headheight
    

    Ça veut dire qu'à la ligne 616 de mon document, j'ai un \showthe\headheight et que la valeur de \headheight à cet endroit est 12pt. Attention à faire ça au bon endroit, car une commande \chapter change le style de la page courante (il passe à plain, normalement), donc la valeur risque d'être différente par rapport à une page dans un autre style de page (p. ex., fancy).

    Une fois que tu as la valeur, il faut l'augmenter et l'utiliser pour le page style qui pose problème, par exemple si c'est fancy :
    \documentclass[...]{...}
    
    \usepackage{fancyhdr}
    \pagestyle{fancy}
    \setlength{\headheight}{14pt}
    % On peut aussi augmenter la valeur sans la connaître, cf. doc de fancyhdr page 12 :
    % \addtolength{\headheight}{0.5cm}
    

    Si, en revanche, le page style qui pose problème est 'plain' (pages de début de chapitre), il faudra sans doute faire ça à l'intérieur d'un
    \fancypagestyle{plain}{...}
    

    (voir “Redefining plain style” dans la doc de fancyhdr, pp. 7 et 8).

    3) Normalement, ceci :
    bla bla bla\\
    bli
    

    ne produit pas d'underfull hbox. C'est un saut de ligne explicite sans justification de la ligne. Ça termine simplement la ligne courante et passe à la suivante[2]. Ce n'est pas un saut de paragraphe, et n'ajoute pas de \parksip, ni aucun espace étirable, donc effectivement, si on remplace tous les sauts de paragraphes par des choses comme ça (horreur), il risque d'y avoir des problèmes pour remplir la page verticalement. Bref, ça peut être utile occasionnellement, mais pas pour passer d'un paragraphe au suivant, ce n'est pas fait pour ça. Plusieurs commandes \\ à la suite produisent des underfull hbox, de toute façon c'est horrible : il vaut mieux utiliser des choses comme \\[2cm] ou \\*[2cm] (pas de coupure de page autorisée) ou mieux la plupart du temps, un saut de paragraphe suivi d'un \smallskip, \medskip, \bigskip ou d'un \vspace ou \vspace* explicite :
    ... fin du premier paragraphe.
    
    \vspace{2ex}% ou \smallskip, \medskip, etc.
    Paragraphe suivant un peu espacé du précédent.
    

    On peut aussi utiliser des espaces étirables, ce qui aide TeX à justifier les pages verticalement :
    \vspace{1ex plus 0.2ex minus 0.1ex\relax}% max. 1.2ex, min. 0.9ex
    \vspace{\fill}% \fill est infiniment étirable, contrairement à l'espace qui précède
    \vspace{\stretch{2.5}}% ressort qui s'étire 2,5 fois plus qu'un \fill (très pratique pour composer une page de titre)
    

    Ne pas confondre \\ (ou encore \newline) avec \linebreak. Ceci
    bla bla bla\linebreak
    bli
    

    va presque à coup sûr provoquer un underfull hbox car \linebreak dit à TeX de couper la ligne et de la justifier (horizontalement) donc, sauf cas particuliers, TeX devra presque toujours en pareil cas étirer énormément les espaces inter-mots pour satisfaire ces contraintes.

    4) Il va être difficile de donner des réponses plus concrètes sans avoir des bouts de code compilables qui reproduisent le(s) problème(s).

    [1] Sauf paramétrage spécial : p. ex., on peut dire à okular de changer la couleur de fond des pages pour pouvoir lire des PDF dont le fond est blanc sans se faire mal aux yeux. On peut ainsi choisir librement la couleur de fond affichée ; cela change la visualisation mais pas l'impression. Idem pour les annotations du genre Post-It.

    [2] Si ce qui suit est une fin de paragraphe (ligne blanche dans le fichier .tex ou bien commande \par) ou bien un autre \\, là, on risque d'avoir un underfull hbox.

    Edit : j'ai ajouté un \relax dans
    \vspace{1ex plus 0.2ex minus 0.1ex\relax}
    
    pour être tranquille. Si vous voulez savoir, c'est parce que 1ex plus 0.2ex minus 0.1ex est du TeX et non du LaTeX, et que la grammaire de TeX est un peu spéciale ; dans ce cas précis, je crois que ça ne changerait rien parce qu'on a spécifié les deux composantes plus et minus, mais s'il n'y en avait qu'une, une fois la commande \vspace développée (i.e., remplacée par sa définition), il se pourrait que TeX trouve par exemple 'minus 1cm' juste après ce qui suivait l'appel à \vspace et l'intègre malencontreusement à la longueur spécifiée dans l'argument de \vspace. C'est pour ça qu'il est généralement considéré comme une bonne habitude de mettre un \relax après une longueur spécifiée en syntaxe TeX ('xxx plus yyy minus zzz', les composantes 'plus yyy' et 'minus zzz' étant optionnelles).
  • Bonsoir Brian (ou plutôt Brillant !),

    Je me demande réellement comment vous faîtes pour connaître autant de choses sur ce langage, qui n'est autre qu'un éditeur d'écriture. C'est presque à se demander si vous n'en êtes pas l'auteur !:):)
    Je vais imprimer toutes vos remarques et les travailler à tête reposée...

    Merci très sincèrement.
  • De rien. ;-)

    À vrai dire, je ne sais pas grand-chose en TeX et en LaTeX comparé à ce que certains intervenants de ce forum savent en maths... Pour progresser, je crois que c'est un peu comme en maths : il faut lire, pratiquer et essayer de comprendre ce qui se passe quand on n'a pas ce que l'on souhaitait faire au départ, ou que l'on rencontre une erreur.

    Pour revenir au sujet, comme fancyhdr t'a gentiment dit
    \headheight is too small (12.0pt):Make it at least 14.49998pt.
    

    je souhaite préciser que là où j'ai mis la commande \setlength{\headheight}{14pt} comme exemple ci-dessus, tu devrais sans doute commencer par \setlength{\headheight}{14.5pt}. En d'autres termes, pas besoin de chercher la valeur de \headheight comme j'ai indiqué, puisque fancyhdr te donne la valeur minimale requise (a priori).

    D'autre part, les marges de ton document sont minuscules, à supposer que c'est pour imprimer au format A4. La documentation de KOMA-Script (manuel en anglais ; si vous lisez bien l'allemand, choisissez plutôt l'original) donne de bons conseils pour choisir la longueur des lignes et donc, entre autres, les marges de la page (voir “Calculating the Page Layout with typearea” p. 27 et suivantes du manuel actuel en anglais).

    N.B. :
    1. KOMA-Script est un ensemble de classes plus sophistiquées que les classes LaTeX standard, qui résolvent pas mal de problèmes courants sans nécessiter de recourir à des packages particuliers (je ne suis pas sûr que je le recommanderais à quelqu'un qui débute, ou alors seulement si la personne a pas mal d'autonomie et de temps pour lire la doc et faire des essais par elle-même). L'auteur de KOMA-Script fournit aussi des packages LaTeX qui fonctionnent avec les classes LaTeX standard ; c'est le cas de typearea, qui est documenté dans le PDF susmentionné. De plus, si c'est pour envoyer aux éditeurs de revues scientifiques, je crois ce c'est exclu : ils veulent en général des docs utilisant une classe LaTeX standard, à ma connaissance.
    2. Ce fichier PDF (manuel de KOMA-Script) ne respecte pas du tout les principes qu'il énonce. La principale raison, d'après ce que j'en ai compris, est qu'il est fait pour lire sur écran, et que l'auteur estime que les marges sont inutiles dans ces conditions.

    Il y a d'autres « règles » pour le calcul des marges (il y a un côté empirique et esthétique qui laisse un peu de marge, si j'ose dire), mais en général, on recommande des lignes pas trop longues (guère plus de 70 caractères par ligne, plutôt entre 60 et 70), ce qui conduit à des marges gauche et droite importantes (d'autant plus que la police est petite, à largeur de papier fixée). Tu peux voir ici un exemple de document utilisant la méthode standard de KOMA-Script. C'est une version tout en noir et blanc pour imprimer, mais grâce aux possibilités de programmation de LaTeX, le même document est disponible dans un format très différent, plus agréable pour lire sur écran, voire pour faire joujou en format présentation pour écrans 16:9. Les deux versions pour écran utilisent le package geometry ; la version papier utilise spécifiquement les fonctionnalités de KOMA-Script (ici, typearea) avec \KOMAoptions{paper=A4,BCOR=0mm,DIV=calc} (ceci ne peut pas être utilisé avec la classe book). Il y a le code source de ce document et quelques autres informations ici.

    Edit : pour bien apprécier les marges, il faut avoir une vue d'ensemble avec les pages paires et impaires en vis à vis, comme dans ces captures d'écran de la version papier A4.

    Enfin, j'ai brièvement parlé de microtype dans un message précédent. Mais (au moins la version que j'ai) ne marche que si les polices peuvent être mises à l'échelle (scalable fonts : formats PostScript Type 1, TrueType ou OpenType). Avec seulement le préambule que tu as posté plus haut, ça ne marche pas avec pdfTeX car la police par défaut est ecrm... l'histoire est un peu longue, mais en gros, pdfTeX embarque dans le PDF une police bitmap (une matrice de points pour chaque glyphe) fabriquée à partir d'une police vectorielle décrite dans le langage Metafont. Bref, un moyen simple pour que ça marche, c'est de mettre \usepackage{lmodern} (par exemple juste après la ligne du \documentclass).

    Enfin, si ton document ne fait que
    \usepackage{helvet}
    
    comme le laisse entendre ce que tu as posté, Helvetica n'est utilisée que quand tu passes en \sffamily. La police 'roman' par défaut n'est pas changée, je ne sais pas si c'est vraiment voulu. Et puis encore un truc en rapport avec helvet et le \headheight trop petit : le document Using common PostScript fonts with LaTeX dit ceci à propos de helvet :

    Helvetica is actually somewhat larger than other typefaces of the same nominal size. As a result, mixing, e.g., Times and Helvetica within running text may look bad.

    This can be fixed by loading the package with the option [scaled=<scale>], for instance: \usepackage[scaled=.92]{helvet}. As a result, the font family phv (Helvetica) will be scaled down to 92% of its ‘natural’ size, which is suitable for use with Adobe Times. Specifying [scaled] alone is equivalent to [scaled=0.95].

    En gros, tu aurais peut-être intérêt à remplacer ton
    \usepackage{helvet}
    
    par
    \usepackage[scaled]{helvet}
    
    ou quelque chose comme ça avant de toucher à \headheight. Le passage en anglais dit qu'Helevetica est un peu grosse par rapport aux autres polices pour une même taille nominale (ex., 12pt) et suggère de la réduire d'un facteur de 1/0,95 ou approchant afin qu'elle se comporte à peu près comme les autres polices, du point de vue de la taille.
  • brian a écrit:
    en général, on recommande des lignes pas trop longues (guère plus de 70 caractères par ligne

    Tenez, ce message du fil Devinette nous sert sur un plateau un magnifique exemple de ce qu'il ne faut pas faire avec des lignes qui vont quasiment d'un bord à l'autre (largeur du format A4). On pourra noter l'origine du document...
Connectez-vous ou Inscrivez-vous pour répondre.