Problème d'affichage de polices Linux/Windows (TTF/OTF) - Page 1

J'ai un souci depuis un certain temps, et je n'arrive pas à trouver de solution malgré de longues recherches en ligne.
Un certain nombre de polices que j'utilise fonctionnent correctement sous Windows, mais ont un rendu incorrect sous Linux (LUbuntu et Arch, à la fois sous LibreOffice 4 ou 5, ainsi que sur LeafPad, mais c'est peut-être plus général, je n'ai pas testé ailleurs).
J'ai le problème tant avec des polices du commerce (Adobe Garamond Pro, ainsi que d'autres de la même grande famille) qu'avec des polices gratuites (New Athena Unicode, mais c'est loin d'être la seule). Je n'ai pas l'impression que ce souci se retrouve avec les polices Microsoft ni avec les polices livrées traditionnellement avec Linux.

Mon souci est au niveau de l'interligne (à moins que ce ne soit la ligne de base qui soit incorrecte), qui est beaucoup plus petit sous Linux que sous Windows. A priori, il y a plusieurs normes au niveau des fichiers TTF/OTF concernant l'espacement vertical, et j'ai trouvé ça sur le sujet : https://fontforge.github.io/editexample5.html#Vertical mais je ne vois pas comment faire pour changer les choses (j'ai édité une police avec fontforge, ai fait mumuse avec les chiffres en question, et ça n'a rien changé).

Je sais qu'il y a des linuxiens ici et peut-être que certains auront une idée sur le sujet ; je vais essayer de contacter Sally par ailleurs, il a peut-être plus d'expérience en la matière...

Alors je n’ai pas windows, juste macos et linux, mais je peux te donner la théorie. L’interligne de base est en principe égal au corps de la fonte (12pt si tu prends du Garamond 12 etc.), ensuite le logiciel applique un multiplicateur qui généralement est 1,2 par défaut mais est réglable. Le problème est de savoir comment le logiciel calcule le corps de la fonte, car il y a plusieurs méthodes...

Est-ce que ton problème est qu’en ouvrant le même document libreoffice sous linux et sous windows, tu n’obtiens pas le même résultat (y compris à l’impression), ou est-ce que c’est que si tu choisis une même fonte et tapes du texte en partant d’un document vide ça ne génère pas le même document sous les deux systèmes ?

Je lis dans la doc de libreoffice que l’interligne par défaut (« single ») « is calculated automatically based on the font size » ce qui est particulièrement imprécis (ils ont sans doute oublié d’ajouter « in an unspecified system-dependent way » ­— ceci dit c’est open-source donc on peut toujours aller voir ), « proportional » est un pourcentage de « single », mais d’après ce que je comprends tu peux le changer pour mettre « leading » et entrer l’interligne à la main, ça devrait au moins assurer que tes documents aient le même aspect sous tous les systèmes, et donc fournir une solution meilleure que rien si tu n’arrives pas à corriger les fichiers de polices...

Mais bon en fait ton problème est officiellement normal et ce sont les fichiers de polices qui sont mal faits : pour citer la doc apple, « Other tables may have information duplicating data contained in the 'hhea' table, most notably the ascent and descent fields. Such information may be found in tables such as the 'OS/2' table or the 'bloc' table. Care should always be taken that metric information within a font is consistent, as different applications and systems get the metric information from different places. »

et donc normalement en bidouillant les valeurs avec fontforge pour que tout soit cohérent tu devrais pouvoir résoudre le problème. Si ça ne fait rien jusqu’ici c’est sans doute que tu n’as pas modifié les bonnes...)

voilà le meilleur lien que j’ai trouvé : https://www.microsoft.com/typography/otspec/recom.htm#tad et cherche aussi le paragraphe intitulé « baseline to baseline distance » un peu plus bas.

Les 5 champs importants de la table OS/2 sont décrits ici : https://www.microsoft.com/typography/otspec/os2.htm#sta
et la table hhea là : https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6hhea.html

Sally? toi ici? Je reve?

• Godzil se frotte les yeux

Nil qui est de retour, Sally qui re-apparait aussi, c'est quoi ce vent nouveau qui souffle sur yN?

(c'est du retour en fanfare)

Dans le même thread en plus
En tout cas merci pour les infos, j'avais passé une heure sur le problème de Nil quand il avait posté, sans rien trouver de probant pour le résoudre

Sally (./2) :
Est-ce que ton problème est qu’en ouvrant le même document libreoffice sous linux et sous windows, tu n’obtiens pas le même résultat (y compris à l’impression), ou est-ce que c’est que si tu choisis une même fonte et tapes du texte en partant d’un document vide ça ne génère pas le même document sous les deux systèmes ?

Oui, c'est exactement ça (sinon, ce ne serait pas aussi problématique, ce serait juste gênant). Ca ne semble pas être spécifique à LibreOffice/OpenOffice, puisque la police s'affiche de façon identique sous LO/OO Linux et sous Leafpad (Linux), et sous LO/OO Win et sous le bloc-notes.

Je n'étais pas tombé sur les mêmes liens que les tiens, donc je vais ajouter ça à ma liste, mais ça me conforte dans l'idée que c'est vraiment la merde (même si c'est ce que je vais faire, je ne considère pas comme normal d'avoir à éditer un fichier de polices - qui plus est commercial - pour que ça fonctionne :/)

En tout cas, merci d'avoir pris le temps de me répondre !

(À tous les autres : non, non, ne vous réjouissez pas trop vite du retour de Sally ; je l'ai sollicité en privé pour avoir son avis sur la question, d'où sa présence )

Bon, en effet, en reprenant les données (sous FontForge) de OS/2\Métriques\"Win Ascend" et "Win Descend" et en les répercutant dans OS/2\Metriques\"Ascendantes", "Descendantes" (en négatif), "HHead Ascendantes", "HHead descendantes" et General\"Ascendantes" et "Descendantes", ça a l'air de compenser (mais je ne suis pas sûr que l'interligne soit strictement le même, je vais devoir générer des fichiers PDF de contrôle.

Merci encore !

Alooooors... suite de mes recherches : j'ai trouvé la page d'un gars qui s'est (vraiment) pris la tête avec tout ça et qui a amassé l'ensemble des informations trouvées sur Internet. Le moins qu'on puisse dire est que c'est loin d'être trivial et que personne n'est d'accord avec les valeurs à mettre (ou non) dans chacune des cases (ce qui ne m'étonne qu'à peine : si même Adobe n'y arrive pas, alors qui peut y arriver ?!).

https://grahamwideman.wikispaces.com/Font+Vertical+Metrics

Je pense qu'il y a matière à faire une thèse de doctorat sur le sujet x_x

Si jamais quelqu'un tombe sur ce sujet et a le même souci que moi : la seule solution pour les polices problématiques est de modifier à la main tous les fichiers avec FontForge pour corriger les données de métriques erronées. C'est le cas avec toutes les polices Adobe et la plupart des polices gratuites trouvées sur Internet O_O

Donc c'est pas plus un problème de linux que de windows ou d'osx ? C'est quand même dingue, ça, autant de data erronnées oO

Le problème est plus compliqué que Linux/Win/OSX... En fait, chacun a utilisé des champs différents du format TTF/OTF pour y placer des informations sur l'interlignage. Et chacun a une notion différente de ce qu'est l'interlignage.
Du coup, les créateurs de polices ont fait "comme ils ont pu", en l'absence de norme claire. Comme la PAO sous Linux, ça représente peanuts, ils s'embêtent à coller à la norme de Windows, d'OSX, du PostScript (et encore, ils font ça à l'aveugle vu que tu ne sais jamais exactement quel paramètre va faire quoi ). Le lien que j'ai mis en ./8 reprend toutes les façons les plus courantes d'aborder le problème et de calculer quelle valeur va dans quel champ, mais on voit bien qu'on est loin d'avoir une normalisation.
Les conséquences directes du truc, c'est que quand on écrit un document sur une plateforme (OSX, vieux Windows, Windows récent...) on n'a aucune assurance qu'il soit affiché à l'identique sur une autre (le plus fort étant bien entendu lorsque sur une même plateforme on trouve plusieurs librairies pour les polices ; suivant les endroits/les applications, l'interligne sera calculé de totalement différemment).

Bref, nous sommes en 2015