Inria sans light - formes = erreurs

Bonjour,
Voici une erreur que je ne comprends pas quand j’utilise la fonte Inria
Sans Light alors que l’ECM fonctionne avec Inria Sans
\documentclass{article}
\usepackage{fontspec}
\usepackage[a4paper]{geometry}
\usepackage{babel}

\setmainfont{Inria Sans Light}

\begin{document}
vive toto et \emph{tata}

\end{document}

le log fournit :
/usr/local/texlive/2023/texmf-dist/tex/latex/base/article.cls|10
warning| LaTeX Font Warning: Font shape `TU/InriaSansLight(0)/m/it’
undefined /m/n’ instead
/usr/local/texlive/2023/texmf-dist/tex/latex/base/article.cls|| LaTeX
Font Warning: Some font shapes were not available, defaults substituted.

Est ce que ça vient de fontspec ? Il faudrait que j’essaye avec LaTeX
Merci de vos réponses.


Pierre Le Cocq

Le 15 juin 2024 à 17:04, Pierre Le Cocq xyz@xyz.tld a écrit :

Bonjour,
Voici une erreur que je ne comprends pas quand j’utilise la fonte Inria Sans Light alors que l’ECM fonctionne avec Inria Sans

Oui, parce que le chef de famille c’est Inria Sans et qu’à partir de là il est capable d’aller chercher l’italique associé.
En revanche Inria Sans Light n’est qu’un avatar maigrichon et ne bénéficie pas de tant d’égards.

Si vous voulez que l’italique fonctionne il faut le demander explicitement.

\documentclass[french]{article}
\usepackage{fontspec}
\usepackage[a4paper]{geometry}
\usepackage{babel}

\setmainfont{Inria Sans Light}[%
UprightFeatures={
Font=Inria Sans Light,
},
ItalicFeatures={
Font=Inria Sans Light Italic
}
]

\begin{document}
vive toto et \emph{tata}

\end{document}

%%%
Vous pouvez aussi définir le gras et le gras ital et même installer tout le système de fontes de la famille.

Michel

je n’ai rien à dire sur le sujet (à part que l’utilité de cette fonte m’échappe un peu), mais du coup j’ai regardé le compagnon « sérif » et je me demande pourquoi Porchez n’a pas encore fait de procès en voyant la goutte du f et le a !

Th. B.

Le 16 juin 2024 à 19:37, Michel Bovani xyz@xyz.tld a écrit :

Vous pouvez aussi définir le gras et le gras ital et même installer tout le système de fontes de la famille.

Ce qui pourrait donner ceci :

\documentclass[french]{article}
\usepackage{fontspec}
\usepackage[a4paper]{geometry}
\usepackage{babel}

\setmainfont{Inria Sans}[%
UprightFeatures={
Font=Inria Sans,
},
ItalicFeatures={
Font=Inria Sans Italic
},
BoldFeatures={
Font=Inria Sans Bold
},
BoldItalicFeatures={Inria Sans Bold Italic
},
FontFace={l}{n}{Font=Inria Sans Light},
FontFace={l}{it}{Font=Inria Sans Light Italic},
]

\begin{document}
vive toto et \emph{tata}

\textbf{vive toto et \emph{tata}}

{\fontseries{l}\selectfont vive toto et \emph{tata}}

\end{document}

Cette fonte ne possède que trois graisses, mais il est possible d’en installer bien plus, tout en respectant l’interface NFSS, car depuis 2020 latex connait 18 “fontseries” distinctes : 9 graisses (ub, eb, b, sb, m, sl, l, el, et ul) et 9 largeurs (ux, ex, x, sx, m, sc, c, ec, uc).


Michel

Le 17 juin 2024 à 13:29, Michel Bovani xyz@xyz.tld a écrit :

BoldItalicFeatures={Inria Sans Bold Italic
},

Ceci cause chez moi une erreur:

LaTeX Error: The key ‘fontspec-opentype/Inria Sans Bold Italic’ is unknown and is being ignored.

De même avec

BoldItalicFeatures={InriaSans-BoldItalic}

Pourtant si j’écris (après begin{document} et sans le setmainfont précédent)
\fontspec{InriaSans-BoldItalic.ttf} toto
Ça marche bien…

Mais les autres options marchent (y compris Inria Sans Light Italic)

Problème de nom ? D’installation ? je suis sous LuaHBTeX, Version 1.18.0 (TeX Live 2024)

Si qqn a le même problème et a su le régler… Merci !

Jacques André

Le 18 juin 2024 à 11:36, Jacques André xyz@xyz.tld a écrit :

Le 17 juin 2024 à 13:29, Michel Bovani xyz@xyz.tld a écrit :

BoldItalicFeatures={Inria Sans Bold Italic
},

Ceci cause chez moi une erreur:

LaTeX Error: The key ‘fontspec-opentype/Inria Sans Bold Italic’ is unknown and is being ignored.

…que je reproduis parfaitement avec une texlive 2023 pourtant pourvue de sa dernière mise à jour (courant mars 2024).

De même avec

BoldItalicFeatures={InriaSans-BoldItalic}

Pourtant si j’écris (après begin{document} et sans le setmainfont précédent)
\fontspec{InriaSans-BoldItalic.ttf} toto
Ça marche bien…

Tiens donc : je vois que dans texlive sont installées en même temps le versions otf et ttf de ces fontes.
Si j’appelle les fontes par leur nom je constate que chez moi, c’est l’otf qui est choisie… Je ne vois d’ailleurs aucune bonne raison d’installer ces deux versions de la fonte.

Mais les autres options marchent (y compris Inria Sans Light Italic)

Problème de nom ? D’installation ? je suis sous LuaHBTeX, Version 1.18.0 (TeX Live 2024)

Oui, mais je ne pense pas qu’il soit concerné, il était déjà là sur TL2023 et n’ a pas été mis à jour récemment. À ta place, je tenterais une mise à jour : le dernier latex date du 1er juin et la fonte a peut-être bêtement été corrigée !


Michel

Le 18/06/2024 à 11:36, Jacques André a écrit :

Le 17 juin 2024 à 13:29, Michel Bovani xyz@xyz.tld a écrit :

BoldItalicFeatures={Inria Sans Bold Italic
},

Ceci cause chez moi une erreur:

LaTeX Error: The key ‘fontspec-opentype/Inria Sans Bold Italic’ is unknown and is being ignored.

Tu peux aussi essayer un appel par nom de fichier :

\setmainfont{InriaSans}[%
Extension = .otf,
UprightFont = *-Regular,
ItalicFont = *-Italic,
BoldFont = -Bold,
BoldItalicFont = -BoldItalic,
FontFace={l}{n}{Font=
-Light},
FontFace={l}{it}{Font=
-LightItalic},
]

Chez moi (Linux, TL2024 à jour) l’appel ci-dessus fonctionne, l’appel de
Michel aussi, résultats identiques pour les deux.


Daniel Flipo

Le 18 juin 2024 à 12:18, Michel Bovani xyz@xyz.tld a écrit :

le dernier latex date du 1er juin et la fonte a peut-être bêtement été corrigée !

Et le dernier fontspec date du 2024/05/11 (v 2.9e)…


Michel

Le 18 juin 2024 à 16:08, Daniel Flipo xyz@xyz.tld a écrit :

Le 18/06/2024 à 11:36, Jacques André a écrit :

Le 17 juin 2024 à 13:29, Michel Bovani xyz@xyz.tld a écrit :

BoldItalicFeatures={Inria Sans Bold Italic
},
Ceci cause chez moi une erreur:
LaTeX Error: The key ‘fontspec-opentype/Inria Sans Bold Italic’ is unknown and is being ignored.

Tu peux aussi essayer un appel par nom de fichier :

Tu peux me/nous ré-expliquer en quoi, à part éventuellement tirer Jacques de ce mauvais pas (mais je n’y crois pas), un appel par nom de fichier est avantageux ?


Michel

Le 18 juin 2024 à 16:08, Daniel Flipo xyz@xyz.tld a écrit :

Tu peux aussi essayer un appel par nom de fichier :

\setmainfont{InriaSans}[%
Extension = .otf,
UprightFont = *-Regular,
ItalicFont = *-Italic,
BoldFont = -Bold,
BoldItalicFont = -BoldItalic,
FontFace={l}{n}{Font=
-Light},
FontFace={l}{it}{Font=
-LightItalic},
]

Chez moi (Linux, TL2024 à jour) l’appel ci-dessus fonctionne, l’appel de Michel aussi,

J’ ai mis tout LaTeX à jour y compris fontspec
Vidé le cache font système
Vidé le cache de Library/texlive/2024/texmf-var/luatex-cache/generic/fonts/otl (fichiers .lua et .luc)

Je ne sais pas quelle a été la bonne action mais maintenant ça marche…
Merci à vous

Jacques André

Le 18/06/2024 à 16:18, Michel Bovani a écrit :

Tu peux me/nous ré-expliquer en quoi, à part éventuellement tirer
Jacques de ce mauvais pas (mais je n’y crois pas), un appel par nom de
fichier est avantageux ?

Un appel par nom de fichier est en général plus sûr : si la fonte est
sous un chemin connu de kpathsea $TEXMFDIST/fonts/truetype ou
$TEXMFDIST/fonts/openttype ou idem avec $TEXMFLOCAL ou $TEXMFHOME elle
sera trouvée.

L’appel par nom de famille suppose, selon les systèmes et les moteurs,
que les fontes soient déclarées comme polices système. On peut observer
des différences de fonctionnement en xelatex et lualatex par exemple ou
entre linux et Mac par exemple.


Daniel Flipo

Le 19/06/2024 à 14:28, Jacques André a écrit :

J’ ai mis tout LaTeX à jour y compris fontspec
Vidé le cache font système
Vidé le cache de
Library/texlive/2024/texmf-var/luatex-cache/generic/fonts/otl (fichiers
.lua et .luc)

Je ne sais pas quelle a été la bonne action mais maintenant ça marche…

Parfait, je voudrais juste rectifier ma bévue précédente :

Un autre truc que Jacques pourrait tenter sous luatex est de
reconfigurer sa base de données de polices avec la commande
fc-cache -fsv

Cette commande reconstruit la base des fontes système sous Linux
(fontconfig), je voulais parler de reconstruire la base de fontes luatex
(ce que tu as fait), la commande est :
luaotfload-tool --update --force


Daniel Flipo

Le 18/06/2024 à 16:27, Daniel Flipo a écrit :

Le 18/06/2024 à 16:18, Michel Bovani a écrit :

Tu peux me/nous ré-expliquer en quoi, à part éventuellement tirer
Jacques de ce mauvais pas (mais je n’y crois pas), un appel par nom de
fichier est avantageux ?

Un appel par nom de fichier est en général plus sûr : si la fonte est
sous un chemin connu de kpathsea $TEXMFDIST/fonts/truetype ou
$TEXMFDIST/fonts/openttype ou idem avec $TEXMFLOCAL ou $TEXMFHOME elle
sera trouvée.

L’appel par nom de famille suppose, selon les systèmes et les moteurs,
que les fontes soient déclarées comme polices système. On peut observer
des différences de fonctionnement en xelatex et lualatex par exemple ou
entre linux et Mac par exemple.

Un autre truc que Jacques pourrait tenter sous luatex est de
reconfigurer sa base de données de polices avec la commande
fc-cache -fsv


Daniel Flipo

Le 18 juin 2024 à 16:27, Daniel Flipo xyz@xyz.tld a écrit :

Le 18/06/2024 à 16:18, Michel Bovani a écrit :

Tu peux me/nous ré-expliquer en quoi, à part éventuellement tirer Jacques de ce mauvais pas (mais je n’y crois pas), un appel par nom de fichier est avantageux ?

Un appel par nom de fichier est en général plus sûr : si la fonte est sous un chemin connu de kpathsea $TEXMFDIST/fonts/truetype ou $TEXMFDIST/fonts/openttype ou idem avec $TEXMFLOCAL ou $TEXMFHOME elle sera trouvée.

L’appel par nom de famille suppose, selon les systèmes et les moteurs, que les fontes soient déclarées comme polices système. On peut observer des différences de fonctionnement en xelatex et lualatex par exemple ou entre linux et Mac par exemple.

Je suis surpris ! La classe tango que je développe actuellement ne contient que des appels par noms (que je préfère parce que je trouve ça de plus haut niveau, mais c’est sans doute culturel). Je connais au moins deux personnes sous linux qui ont compilé sans problème mon fichier test. Pour xelatex, c’est bien possible, le fait est que ça a planté dès le premier essai. Je n’ai même pas lu le message, j’ai juste remplacé \RequireTUTeX par \RequireLuaTeX… Mais tu observera que ça ne marche pas non plus avec LaTeX et que personne n’en fait toute une histoire. Le problème avec Linux, s’il était avéré, est évidemment nettement plus gênant.


Michel

Bonjour, je vais citer demain devant 20 étudiants l’article écrit par
mes anciennes étudiantes:

Comment se fait-il, à l’heure de l’open access, qu’il ne soit pas
facilement accessible?

En plus, il a été écrit en 2021. Or la loi Lemaire propose qu’ils soient
en libre accès depuis 2022.

Un grand merci par avance
E. Guichard

Bonjour,

Le 20/06/2024 à 20:55, Eric Guichard a écrit :

Donald Knuth : des mathématiques à la typographie | Cahiers GUTenberg > loi Lemaire

Je ne crois pas que la loi Lemaire impose à une association comme
Gutenberg de mettre en accès libre les articles qu’elle publie. Mais je
ne suis pas juriste alors j’aimerai bien avoir le numéro de l’article de
loi qui l’imposerait. Par contre, le DOI cité sur la page GUT est
incorrecte aujourd’hui !

Merci,

Jean-Yves

Le 21 juin 2024 à 09:51, Jean-Yves Baudais xyz@xyz.tld a écrit :

Bonjour,

Le 20/06/2024 à 20:55, Eric Guichard a écrit :

Donald Knuth : des mathématiques à la typographie | Cahiers GUTenberg > loi Lemaire

Je ne crois pas que la loi Lemaire impose à une association comme Gutenberg de mettre en accès libre les articles qu’elle publie.

Elle autorise sous certaines conditions les auteurs (s’ils sont tous d’accord) à mettre leur article en ligne, ce qui n’impose nullement à l’éditeur de la revue de le faire lui-même. J’ajoute que parmi les conditions, il y a la nécessité pour la revue concernée de paraître au moins une fois par an (ajouter ici le smiley angélique de votre choix).

Mais je ne suis pas juriste alors j’aimerai bien avoir le numéro de l’article de loi qui l’imposerait.

https://www.legifrance.gouv.fr/jorf/article_jo/JORFARTI000033202841


Michel

Le 21/06/2024 à 10:13, Michel Bovani a écrit :

Le 21 juin 2024 à 09:51, Jean-Yves Baudais xyz@xyz.tld a écrit :

Le 20/06/2024 à 20:55, Eric Guichard a écrit :

Donald Knuth : des mathématiques à la typographie | Cahiers GUTenberg > loi Lemaire

Je ne crois pas que la loi Lemaire impose à une association comme Gutenberg de mettre en accès libre les articles qu’elle publie.

Elle autorise sous certaines conditions les auteurs (s’ils sont tous d’accord) à mettre leur article en ligne, ce qui n’impose nullement à l’éditeur de la revue de le faire lui-même. J’ajoute que parmi les conditions, il y a la nécessité pour la revue concernée de paraître au moins une fois par an (ajouter ici le smiley angélique de votre choix).

Mais je ne suis pas juriste alors j’aimerai bien avoir le numéro de l’article de loi qui l’imposerait.

https://www.legifrance.gouv.fr/jorf/article_jo/JORFARTI000033202841

Heu… c’est le texte de loi relatif aux publications issues d’une
activité de recherche financée au moins pour moitié blablabla…
Était-ce le cas de l’article dont il est question ? C’était donc une
publication issues d’une activité de recherche ! Ah mais c’est
intéressant ça, et c’était quoi au juste la contribution scientifique de
l’article, le “breakthrough” ! Désolé c’est vendredi :slight_smile:

Jean-Yves

Bonjour.

Le pdf est en ligne à l’adresse Donald Knuth : des mathématiques à la typographie | Cahiers GUTenberg

Les autres articles du numéro suivront.

La publication a pris du retard parce qu’on a eu plein de gens à synchroniser pour mettre cet article en ligne. Et c’est pas faute d’avoir essayé.

Le DOI sera réglé rapidement.

Ce retard s’explique entre autres par le fait que l’association continue à manquer de bras : les bonnes volontés sont les bienvenues !

Pour l’association GUTenberg,

Patrick Bideault

Envoyé: vendredi 21 juin 2024 à 11:04
De: « Jean-Yves Baudais » xyz@xyz.tld
À: xyz@xyz.tld
Objet: Re: [gut] Cahiers inaccessibles

Le 21/06/2024 à 10:13, Michel Bovani a écrit :

Le 21 juin 2024 à 09:51, Jean-Yves Baudais xyz@xyz.tld a écrit :

Le 20/06/2024 à 20:55, Eric Guichard a écrit :

Donald Knuth : des mathématiques à la typographie | Cahiers GUTenberg > loi Lemaire

Je ne crois pas que la loi Lemaire impose à une association comme Gutenberg de mettre en accès libre les articles qu’elle publie.

Elle autorise sous certaines conditions les auteurs (s’ils sont tous d’accord) à mettre leur article en ligne, ce qui n’impose nullement à l’éditeur de la revue de le faire lui-même. J’ajoute que parmi les conditions, il y a la nécessité pour la revue concernée de paraître au moins une fois par an (ajouter ici le smiley angélique de votre choix).

Mais je ne suis pas juriste alors j’aimerai bien avoir le numéro de l’article de loi qui l’imposerait.

https://www.legifrance.gouv.fr/jorf/article_jo/JORFARTI000033202841

Heu… c’est le texte de loi relatif aux publications issues d’une
activité de recherche financée au moins pour moitié blablabla…
Était-ce le cas de l’article dont il est question ? C’était donc une
publication issues d’une activité de recherche ! Ah mais c’est
intéressant ça, et c’était quoi au juste la contribution scientifique de
l’article, le « breakthrough » ! Désolé c’est vendredi :slight_smile:

Jean-Yves

Bonsoir et merci, et surtout à JMH, qui a pris les devants.
Bien cordialement
Eric

Le 21/06/2024 à 16:28, Patrick Bideault a écrit :

Bonjour.

Le pdf est en ligne à l’adresse Donald Knuth : des mathématiques à la typographie | Cahiers GUTenberg

Les autres articles du numéro suivront.

La publication a pris du retard parce qu’on a eu plein de gens à synchroniser pour mettre cet article en ligne. Et c’est pas faute d’avoir essayé.

Le DOI sera réglé rapidement.

Ce retard s’explique entre autres par le fait que l’association continue à manquer de bras : les bonnes volontés sont les bienvenues !

Pour l’association GUTenberg,

Patrick Bideault