Descender dans le développement mobile — essence, signification et influence sur la mise en page

Qu’est-ce que Descender en typographie

Descender est la partie d’un glyphe située sous la ligne de base. Alors que le corps principal de la lettre repose sur la baseline, le descender s’étend au-delà, créant la silhouette caractéristique de la police. Dans l’alphabet latin, les lettres avec descender incluent « g », « j », « p », « q », « y » — leurs éléments inférieurs descendent sous la ligne.

La profondeur du descender décrit la distance de la baseline au bord inférieur du glyphe (descender-line). Dans les polices de qualité, cette distance est équilibrée : un descender trop court rend les lettres avec descender difficiles à reconnaître, tandis qu’un descender trop long crée un espace vide excessif entre les lignes et réduit la densité du texte. Différentes polices montrent des différences significatives dans la longueur du descender.

Selon le Google Fonts Metrics Guide (2025), un descender est considéré comme optimal lorsque sa profondeur est de 20–25 % de la taille em complète (1000 FUnits). Les valeurs inférieures à 15 % rendent les lettres avec descender difficiles à distinguer, tandis que les valeurs supérieures à 30 % nécessitent une augmentation obligatoire du line-height pour prévenir les collisions de lignes.

Métriques numériques de Descender : OpenType et TrueType

Dans les polices numériques, le descender est stocké comme une valeur négative dans les tables de métriques. Dans le format OpenType, il s’agit du champ hhea.descent (table hhea) et sTypoDescender (table OS/2). Les deux valeurs sont négatives car elles sont mesurées à partir de la baseline vers le bas. Pour TrueType, la table OS/2 est utilisée avec le champ usWinDescent — sa valeur est positive mais désigne la même métrique.

# Lecture du descender à partir de la police via fontTools
from fontTools.ttLib import TTFont

font = TTFont('Roboto-Regular.ttf')
hhea = font['hhea']
os2 = font['OS/2']

descent_hhea = hhea.descent        # -500 FUnits (Roboto)
typo_descender = os2.sTypoDescender # -500 FUnits
win_descent = os2.usWinDescent      # 500 (positive value)

# Convertir en pixels pour une taille de police 16pt
px_per_em = 16
descent_px = abs(descent_hhea) * px_per_em / 1000  # 8 px

La différence critique entre les plateformes : iOS utilise hhea.descent pour le rendu, tandis que Android utilise sTypoDescender d’OS/2. Si ces valeurs diffèrent (ce qui arrive dans les polices mal configurées), le même texte s’affichera avec des interlignages différents sur iOS et Android. Une différence de 100 FUnits (environ 1,6 px pour une taille de police de 16 pt) est déjà visuellement perceptible.

Selon la Microsoft OpenType Specification v1.9 (2025), pour un rendu multiplateforme correct, les valeurs hhea.descent et sTypoDescender doivent être égales à 50 FUnits près. Lors du choix d’une police pour une application mobile, cela doit être vérifié via fontTools ou un utilitaire similaire.

Descender dans iOS : UIFont et Core Graphics

Dans iOS, la valeur du descender est disponible via la propriété UIFont.descender. Cette propriété retourne un nombre négatif indiquant la distance de la baseline au bord inférieur de la police (y compris le descender). Par exemple, pour SF Pro en 17 pt, la valeur du descender est d’environ -4,2 pt. Plus la valeur absolue est grande, plus les extensions inférieures de la police sont longues.

// Obtention du descender sur iOS via UIFont
let font = UIFont.systemFont(ofSize: 17)
let descender = font.descender     // ~ -4,2 pt pour SF Pro 17pt
let ascender = font.ascender        // ~ 16,2 pt
let lineHeight = font.lineHeight    // ~ 20,4 pt

// Rendu personnalisé avec décalage du descender
let attrString = NSAttributedString(
    string: "Sample text with letter p and y",
    attributes: [.font: font]
)

// Core Text : obtention de la boîte englobante avec descender
let ctFont = CTFontCreateWithName(
    "SF Pro Text" as CFString, 17, nil
)
let descent = CTFontGetDescent(ctFont)  // ~4,2 pt

Lors de l’utilisation de TextKit (NSTextStorage, NSLayoutManager), le descender est automatiquement pris en compte dans lineFragmentPadding et lineFragmentRect. Cependant, lors du rendu personnalisé via Core Graphics (draw(in:)), vous devez ajuster manuellement les coordonnées en ajoutant la valeur absolue du descender à la marge inférieure du conteneur. Si cela n’est pas fait, les lettres avec descender dépasseront les limites de rendu et seront rognées.

Descender dans Android : Paint et Compose

Dans Android, les métriques du descender sont disponibles via Paint.FontMetrics.descent. Contrairement à iOS, la valeur descent est positive — elle représente la distance de la baseline au bord inférieur du texte. La propriété FontMetrics.bottom inclut non seulement le descender mais aussi l’espace supplémentaire recommandé par le concepteur de la police (leading). Pour un calcul précis du seul descender, utilisez descent plutôt que bottom.

// Obtention du descender sur Android via Paint
val paint = Paint().apply {
    textSize = 17 * density
}

val metrics = paint.fontMetrics
val descent = metrics.descent     // ~4,5 px pour 17sp
val bottom = metrics.bottom       // ~5,0 px avec leading

// Rendu personnalisé avec décalage du descender
val baseline = y
canvas.drawText("Exemple : gpq", x, baseline, paint)

// Limite inférieure avec descender
val bottomBound = baseline + descent  // limite inférieure correcte

Dans Jetpack Compose, le descender peut être obtenu via TextLayoutResult. La méthode getLineBottom retourne la coordonnée Y du bord inférieur de la ligne, qui inclut déjà le descender. Lors de la mise en page personnalisée de chaînes avec différentes tailles de police (par exemple, un prix remisé et un prix plein), l’alignement sur la baseline en tenant compte du descender donne un résultat plus précis que l’alignement sur le bord inférieur.

// Compose : vérification de la limite inférieure du texte
val text = "Text with descenders: gpq"
var layoutResult by remember { mutableStateOf<TextLayoutResult?>(null) }

Text(
    text = text,
    onTextLayout = { layoutResult = it },
    modifier = Modifier.drawBehind {
        layoutResult?.let { result ->
            val lastLine = result.lineCount - 1
            val bottom = result.getLineBottom(lastLine)
            val top = result.getLineTop(lastLine)
            // Vérifier que le descender ne dépasse pas les limites du conteneur
        }
    }
)

Selon Google Material Design — Typography Implementation (2025), pour éviter le rognage du descender dans les conteneurs à hauteur fixe, vous devez ajouter un padding vertical d’au moins la valeur descent de la police, que le texte actuel contienne ou non des lettres avec descender. Cela garantit que l’interface ne se brisera pas lors du remplacement dynamique du texte.

Descender et collisions de lignes dans les interfaces mobiles

Une collision de lignes est une situation où le descender d’une lettre de la ligne supérieure croise physiquement l’ascender d’une lettre de la ligne inférieure. Dans les interfaces mobiles, cela est particulièrement visible dans les titres multilignes, les fiches produits et les blocs de texte avec un petit interlignage. Le problème est aggravé par l’utilisation de polices avec des descenders longs et un petit line-height.

Le line-height minimum qui prévient les collisions peut être calculé avec la formule : line-height = ascender + descender + 2 px de marge. Pour SF Pro en 17 pt, cela donne un line-height d’environ 16,2 + 4,2 + 2 = 22,4 pt (un coefficient d’environ 1,32). Pour Roboto en 16 sp, environ 1,35. Si le line-height est inférieur à cette valeur, les collisions sont garanties dans les textes contenant des lettres avec descender.

// iOS : calculer le line-height minimum pour éviter les collisions
let font = UIFont.systemFont(ofSize: 17)
let minLineHeight = abs(font.ascender) + abs(font.descender) + 2.0

let paragraphStyle = NSMutableParagraphStyle()
paragraphStyle.minimumLineHeight = minLineHeight
paragraphStyle.maximumLineHeight = minLineHeight

let attributedText = NSAttributedString(
    string: "Text with p on first line\nand y on second line",
    attributes: [
        .font: font,
        .paragraphStyle: paragraphStyle
    ]
)

Une attention particulière doit être apportée lors du travail avec les polices décoratives et manuscrites — leur descender peut atteindre 35–40 % de la taille em. Ces polices sont rarement utilisées pour le texte courant mais peuvent être appliquées dans les titres. Même une seule occurrence d’une lettre avec un descender long dans un titre peut provoquer une collision avec un élément d’interface voisin.

Erreurs courantes lors du travail avec Descender

L’erreur la plus fréquente est le rognage du descender dans les boutons et les champs de texte. Lorsque nous définissons la hauteur d’un bouton ou d’un champ de texte égale au line-height sans tenir compte du descender, les lettres avec descender sont coupées au bord inférieur. Cela est particulièrement visible sur les boutons système aux coins arrondis, où le descender peut dépasser la limite du rayon d’angle.

• Boutons à hauteur fixe — si la hauteur du bouton est égale à ceil(line-height), les lettres avec descender sont rognées. Solution : augmentez la hauteur du bouton de la valeur absolue du descender (4–5 pt pour une police système de 17 pt) pour le padding supérieur et inférieur.
• TextField sans prise en compte du descender — les UITextField et EditText standard ont un padding qui tient compte du descender, mais les implémentations personnalisées l’oublient souvent. Vérifiez que le curseur et le bloc de texte ne rognent pas les lettres avec descender.
• Mélange de tailles de police dans une même ligne — si NSAttributedString ou SpannableString contient des segments de différentes tailles de police, le descender de la police plus grande peut chevaucher l’ascender de la plus petite. Utilisez baselineOffset pour la compensation et vérifiez le résultat.
• Rendu SVG de texte — lors du rendu de texte en SVG ou sur Canvas (en particulier dans les WebViews), le descender peut ne pas être pris en compte automatiquement. Spécifiez toujours un viewBox explicite avec une marge de 10–15 % de la taille de la police.

Selon Nielsen Norman Group — Mobile Typography Research (2025), 41 % des applications mobiles ont au moins un écran où le texte avec descenders dépasse les limites du composant. Cela entraîne une diminution de 15 % de la lisibilité et une augmentation du temps d’exécution des tâches par l’utilisateur. Des tests réguliers avec du texte contenant des lettres avec descender aident à identifier ces problèmes dès les premiers stades du développement.