Capitale à chaque première lettre de mot
Poutounet
Je souhaite écrire une macro (\n par exemple) qui mette en grande
capitale chaque première lettre de mot compris dans son argument et en
petites capitales les fins de mot. C'est sans doute pas très clair, donc
voici un exemple : "VOIci uNE PhRAse" donnerait "Voici Une Phrase" (en
remplaçant les minuscules par des petites capitales).
Pour le moment, j'ai réussi à mettre en grande capitale la première
lettre de l'argument (sur l'exemple précédent j'obtiens donc "Voici une
phrase"), grâce à l'astuce suivante glanée sur le net :
\def\first#1#2@{\MakeUppercase{#1}}
\def\rest#1#2@{\MakeLowercase{#2}}
\newcommand{\n}[1]{\textsc{\expandafter\first#1@\expandafter\rest#1@}}
J'imagine que l'étape suivante serait de "splitter" l'argument de
manière récursive, mais je n'y arrive pas.
Si une bonne âme charitable voulais bien me mettre sur le chemin de la
solution, je lui en serais reconnaissant.
--
Poutounet
Manuel Pégourié-Gonnard
> \def\first#1#2@{\MakeUppercase{#1}}
> \def\rest#1#2@{\MakeLowercase{#2}}
> \newcommand{\n}[1]{\textsc{\expandafter\first#1@\expandafter\rest#1@}}
>
Juste une remarque : les \expandafter ne servent � rien, ici, si on
suppose que l'argument est vraiment un truc comme ��VoIci dU teXtE��. Il
servent seulement si on a fait
\newcommand\texte{VoIci dU teXtE}
\n{\texte}
> J'imagine que l'�tape suivante serait de "splitter" l'argument de
> mani�re r�cursive, mais je n'y arrive pas.
>
Pour �a, je pense que \StrBefore, \StrBehind et/ou \StrBetween de
xstring font l'affaire. Il reste � organiser la r�cursion...
--
Manuel P�gouri�-Gonnard Institut de math�matiques de Jussieu
http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/
unbonpetit
> Pour ça, je pense que \StrBefore, \StrBehind et/ou \StrBetween de
> xstring font l'affaire.
Puisqu'on me force la main :
%%%%%%%%%%%%%%%%%%%%%%%%%
\documentclass[a4paper,10pt]{article}
\usepackage{xstring}
\newcommand\n[1]{%
\begingroup\noexpandarg
\lowercase{\StrSubstitute{\MakeUppercase#1}{ }{ \MakeUppercase}}%
\endgroup}
\begin{document}
\n{VOIci uNE PhRAse pleine De letTrEs MajUSCulEs mochES}
\end{document}
%%%%%%%%%%%%%%%%%%%%%%%%%
Poutounet
> Manuel Pￜgouriￜ-Gonnard a ￜcrit :
>> Pour ï¿œa, je pense que \StrBefore, \StrBehind et/ou \StrBetween de
Super ! ￜa fonctionne (aprￜs une petite mise ￜ jour de mon package
xstring qui n'avait pas \noexpandarg), et sans rï¿œcursion en plus... J'ai
juste ajoutￜ un petit \textsc pour avoir exactement ce que je voulais.
Merci beaucoup !
--
Poutounet
unbonpetit
> Super ! Ça fonctionne (après une petite mise à jour de mon package
> xstring qui n'avait pas \noexpandarg), et *sans récursion en plus*
>
En apparence seulement parce qu'il y a nécessairement une récursivité
dans \StrSubstitute pour parcourir l'ensemble de l'argument.
Manuel Pégourié-Gonnard
> Manuel P�gouri�-Gonnard a �crit :
>> Pour �a, je pense que \StrBefore, \StrBehind et/ou \StrBetween de
Rh� mais bien s�r, \StrSubstitute, c'est tellement plus �l�gant que ce �
quoi je pensais. Bien vu. (Bon du coup on pouvait m�me le faire avec
ted, niark niark.)
unbonpetit
> Rhâ mais bien sûr, \StrSubstitute, c'est tellement plus élégant que ce à
> quoi je pensais.
Héhé, le pire, c'est que tu m'as influencé ! J'avais commencé à écrire
un truc récursif assez lourd avec \StrBefore et autres, avant de
réaliser qu'il suffisait de remplacer chaque espace.
> (Bon du coup on pouvait même le faire avec
> ted, niark niark.)
>
Oui, hélas, je l'ai compris quelques secondes après avoir posté mon
message. Je m'en suis terriblement voulu, j'aurais trouvé assez plaisant
de te poster une solution avec ted ;)
Jacques M
> Manuel Pￜgouriￜ-Gonnard a ￜcrit :
Bonsoir,
Cet exemple me semble intï¿œressant car je voudrais l'exploiter pour faire
autre chose mais j'ai un problï¿œme.
Voici ce que je voudrais faire : lorsque l'on compose du texte avec tex,
celui-ci est en couleur noire (couleur par dï¿œfaut).
Je voudrais crï¿œer une macro dont l'argument est du texte et dont le
rￜsultat est le mￜme texte formatￜ de la mￜme faￜon (cￜsure au mￜme
endroit que si la macro ne s'appliquait pas ￜ cet argument...) mￜme
taille, mï¿œme espacement ... tout pareil sauf la couleur : je voudrais
que la couleur de tous les caractï¿œres (lettres, nombres, virgules
apostrophes, ...) soit choisie de faï¿œon alï¿œatoire.
Merci
unbonpetit
> je voudrais
> apostrophes, ...) soit choisie de façon aléatoire.
>
J'avoue que je sèche ! Colorier les "caractères" un par un est assez
facile, mais je ne m'explique pas pourquoi la composition des
paragraphes n'est pas identique si le package babel est chargé avec
l'option frenchb. En tous cas, la réponse d'un expert m'intéressera !
Voici le code, qu'il faudra de toutes façons améliorer :
\documentclass{article}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{xcolor}
\usepackage{xstring}
\usepackage[first=0,last=255,seed=3]{lcg}
%\usepackage[frenchb]{babel}% à décommenter pour voir la différence
\makeatletter
\newcommand\colorize[1]{%
\rand\edef\rand@rgb{\strip@pt\dimexpr\arabic{rand}pt/255}%
\rand\edef\rand@rgb{\rand@rgb,\strip@pt\dimexpr\arabic{rand}pt/255}%
\rand\edef\rand@rgb{\rand@rgb,\strip@pt\dimexpr\arabic{rand}pt/255}%
\expandafter\StrSplit\expandafter{#1}1\str@a\str@b
\ifx\str@a\space\ \else\textcolor[rgb]{\rand@rgb}{\str@a}\fi
\unless\ifx\@empty\str@b
\expandafter\colorize\expandafter\str@b\fi}
\makeatother
\begin{document}
\colorize{Voici un texte très coloré, la lisibilité n'est d'ailleurs pas
idéale, je dirais même qu'elle est franchement mauvaise. Comme on peut
le voir,
si le package babel avec l'option frenchb est chargé, la composition
n'est pas
strictement identique. Un expert va sûrement expliquer ça.}
Voici un texte très coloré, la lisibilité n'est d'ailleurs pas idéale, je
dirais même qu'elle est franchement mauvaise. Comme on peut le voir, si le
package babel avec l'option frenchb est chargé, la composition n'est pas
strictement identique. Un expert va sûrement expliquer ça.
\end{document}
Jacques M
> Le 27/12/2009 01:21, Jacques M a ï¿œcrit :
>> je voudrais
>> que la couleur de tous les caractï¿œres (lettres, nombres, virgules
>> apostrophes, ...) soit choisie de faï¿œon alï¿œatoire.
>>
>
> J'avoue que je sï¿œche ! Colorier les "caractï¿œres" un par un est assez
> facile, mais je ne m'explique pas pourquoi la composition des
> l'option frenchb. En tous cas, la rï¿œponse d'un expert m'intï¿œressera !
>
> Voici le code, qu'il faudra de toutes faï¿œons amï¿œliorer :
>
> \documentclass{article}
> \usepackage[utf8]{inputenc}
> \usepackage[T1]{fontenc}
> \usepackage{xcolor}
> \usepackage{xstring}
> \usepackage[first=0,last=255,seed=3]{lcg}
> \makeatletter
> \newcommand\colorize[1]{%
> \rand\edef\rand@rgb{\strip@pt\dimexpr\arabic{rand}pt/255}%
> \rand\edef\rand@rgb{\rand@rgb,\strip@pt\dimexpr\arabic{rand}pt/255}%
> \rand\edef\rand@rgb{\rand@rgb,\strip@pt\dimexpr\arabic{rand}pt/255}%
> \expandafter\StrSplit\expandafter{#1}1\str@a\str@b
> \ifx\str@a\space\ \else\textcolor[rgb]{\rand@rgb}{\str@a}\fi
> \unless\ifx\@empty\str@b
> \expandafter\colorize\expandafter\str@b\fi}
> \makeatother
> \begin{document}
> idï¿œale, je dirais mï¿œme qu'elle est franchement mauvaise. Comme on peut
> le voir,
> si le package babel avec l'option frenchb est chargￜ, la composition
> n'est pas
> strictement identique. Un expert va sï¿œrement expliquer ï¿œa.}
>
> Voici un texte trￜs colorￜ, la lisibilitￜ n'est d'ailleurs pas idￜale, je
> dirais mï¿œme qu'elle est franchement mauvaise. Comme on peut le voir, si le
> package babel avec l'option frenchb est chargￜ, la composition n'est pas
> strictement identique. Un expert va sï¿œrement expliquer ï¿œa.
> \end{document}
Peut-il y a-t-il lￜ dessous une histoire de crￜnage et d'autres choses.
Si on prend le premier mot (Voici), on voit que que la distance entre en
le V et le o n'est pas la mï¿œme dans la version couleur ou la version
noire, que ce soit avec babel ou pas. Les distances entre les mots sont
changï¿œes. Enfin, si l'on rajoute des ligatures comme fi ou fl ou ffl, on
voit qu'elle n'apparaissent jamais dans la version colorï¿œe. Cela doit
venir du fait que (et cela ne vient peut-ï¿œtre pas de babel avec frenchb
ou english par exemple), ￜ mon avis, tex ne peut plus gￜrer les mots
mais seulement des lettres une ￜ une avec parfois des espaces. Du coup,
tex ne compose plus le texte de faï¿œon fine lorsque l'on change les
couleurs. Peut-on amï¿œliorer cela ? Si l'on ne peut pas y arriver c'est
assez regrettable car le fait de changer la couleur ne modifie ni la
fonte si la taille ni autre chose. Je me doutais bien qu'il y aurait un
soucis et c'est pour cela que je l'avais prￜcisￜ dans ma demande.
Peut-ￜtre faudrait-il avoir accￜs ￜ la faￜon doit tex fabrique les mots,
comment il gï¿œre la position des lettres les unes par rapport aux autres
pour fabriquer les mots.
unbonpetit
> Peut-il y a-t-il là dessous une histoire de crénage et d'autres choses.
> voit qu'elle n'apparaissent jamais dans la version colorée. Cela doit
> venir du fait que (et cela ne vient peut-être pas de babel avec frenchb
> ou english par exemple), à mon avis, tex ne peut plus gérer les mots
> mais seulement des lettres une à une avec parfois des espaces. Du coup,
> tex ne compose plus le texte de façon fine lorsque l'on change les
> couleurs. Peut-on améliorer cela ? Si l'on ne peut pas y arriver c'est
> fonte si la taille ni autre chose. Je me doutais bien qu'il y aurait un
>
> Peut-être faudrait-il avoir accès à la façon doit tex fabrique les mots,
> comment il gère la position des lettres les unes par rapport aux autres
> pour fabriquer les mots.
>
Oui, tu as raison pour le crénage, je n'avais pas entrepris de chercher
d'aussi faibles différences, je plaide coupable ! Quant à la façon dont
est composé le texte, c'est vrai que chaque lettre est gérée séparément,
et il est en effet probable que TeX ne puisse pas mettre en œuvre le
même mécanisme de composition que lorsqu'elles sont les unes à la suite
des autres dans le code.
C'est un peu le même problème qu'avec {V}{o}{i}{c}{i} au lieu de Voici :
la différence de crénage est nettement visible.
Bref, je ne vois absolument pas comment on pourrait faire pour que TeX
voit les lettres comme si elles se suivaient dans le code. En effet, il
faut bien qu'une commande demande à changer la couleur entre chaque
lettre (d'où l'impossibilité pour TeX de faire des ligatures). Un expert
-- Manu ou Jean-Côme -- pourra sans doute nous en dire plus...
Sinon, à part le fait que ce problème est très intéressant, est-ce qu'il
est si important pour l'usage que tu veux faire que la composition soit
exactement la même avec et sans couleur ?
Christian
PS : la différence considérable qui apparait lorsque babel est chargé
avec frenchb n'est toujours pas expliquée par contre...
Jacques M
> Le 27/12/2009 22:10, Jacques M a ï¿œcrit :
>> Peut-il y a-t-il lￜ dessous une histoire de crￜnage et d'autres choses.
>> voit qu'elle n'apparaissent jamais dans la version colorï¿œe. Cela doit
>> venir du fait que (et cela ne vient peut-ï¿œtre pas de babel avec frenchb
>> ou english par exemple), ￜ mon avis, tex ne peut plus gￜrer les mots
>> mais seulement des lettres une ￜ une avec parfois des espaces. Du coup,
>> tex ne compose plus le texte de faï¿œon fine lorsque l'on change les
>> couleurs. Peut-on amï¿œliorer cela ? Si l'on ne peut pas y arriver c'est
>> fonte si la taille ni autre chose. Je me doutais bien qu'il y aurait un
>>
>> comment il gï¿œre la position des lettres les unes par rapport aux autres
>> pour fabriquer les mots.
>>
>
> Oui, tu as raison pour le crï¿œnage, je n'avais pas entrepris de chercher
> d'aussi faibles diffￜrences, je plaide coupable ! Quant ￜ la faￜon dont
> est composￜ le texte, c'est vrai que chaque lettre est gￜrￜe sￜparￜment,
> et il est en effet probable que TeX ne puisse pas mettre en ï¿œuvre le
> mￜme mￜcanisme de composition que lorsqu'elles sont les unes ￜ la suite
> des autres dans le code.
Exactement, il ne reconnaï¿œt pas qu'il y a des mots.
> C'est un peu le mï¿œme problï¿œme qu'avec {V}{o}{i}{c}{i} au lieu de Voici :
> la diffï¿œrence de crï¿œnage est nettement visible.
Oui
> Bref, je ne vois absolument pas comment on pourrait faire pour que TeX
> voit les lettres comme si elles se suivaient dans le code. En effet, il
> faut bien qu'une commande demande ￜ changer la couleur entre chaque
> lettre (d'oￜ l'impossibilitￜ pour TeX de faire des ligatures). Un expert
> -- Manu ou Jean-Cï¿œme -- pourra sans doute nous en dire plus...
Regarde ï¿œa, c'est extrï¿œmement intï¿œressant. C'est une documentation sur
MetaFun : http://www.pragma-ade.com/general/manuals/metafun-p.pdf
Va aux la pages 240 et 241. C'est clair la solution existe car les mots
sont bien reconnus (regarde les cï¿œsures et les ligatures). En fait cet
exemple va mï¿œme encore plus loin car certaines lettres peuvent ï¿œtre
ï¿œtirï¿œes ou comprimï¿œes horizontalement et TeX reconnaï¿œt encore les mots
(lￜ je trouve ￜa encore plus fort car ce n'est pas seulement la couleur
qui change mais aussi la forme des lettres). Je me demande ce qu'il faut
pour arriver ￜ ce rￜsultat. Metapost, Metafun et ConTeXt (pdftex aussi
visiblement d'aprï¿œs ce qui est dit page 240) ? Si un pro de ces domaines
pouvait passer par lￜ.
> Sinon, ￜ part le fait que ce problￜme est trￜs intￜressant, est-ce qu'il
> est si important pour l'usage que tu veux faire que la composition soit
> exactement la mï¿œme avec et sans couleur ?
Non car le rï¿œsultat n'est pas trï¿œs lisible et ton code le prouve mais si
j'arrive ￜ rￜsoudre ce problￜme cela me ferait trￜs plaisir d'une part
et d'autre part, cela me permet d'en apprendre davantage sur les
mï¿œcanismes de TeX. En effet, il y a quelque chose dans ce problï¿œme (et
dans le fait de voir qu'une solution existe dans le document sur
Metafun) qui montre que la frontiï¿œre entre le graphisme et la
typographie semble de plus en plus mince et que l'utilisation que les
concepteurs de ConTeXt font de Metapost tend ￜ la rendre de plus en plus
mince. En tous cas, c'est avec ce genre d'interaction entre metapost et
tex que j'en ai l'impression alors mï¿œme que le code metapost n'est pas
un code TeX comme peut l'ï¿œtre celui de TikZ (que j'apprï¿œcie
particuliï¿œrement du reste).
> Christian
>
> PS : la diffￜrence considￜrable qui apparait lorsque babel est chargￜ
> avec frenchb n'est toujours pas expliquï¿œe par contre...
c'est vrai
Elie
>
> C'est un peu le même problème qu'avec {V}{o}{i}{c}{i} au lieu de Voici :
> la différence de crénage est nettement visible.
>
> Bref, je ne vois absolument pas comment on pourrait faire pour que TeX
> voit les lettres comme si elles se suivaient dans le code. En effet, il
> faut bien qu'une commande demande à changer la couleur entre chaque
> lettre (d'où l'impossibilité pour TeX de faire des ligatures).
Alors parmis les trucs totalement géniaux qui sont dans Omega et se
retrouvent dans Aleph et LuaTeX, il y a (outre les primitives
\localrightbox et \localleftbox que je dois être le seul avec Yannis à
utiliser...), les primitives \leftghost et \rightghost... pas très
médiatisées, elles permettent pourtant de faire ça (pour aleph,
supprimer les deux premiers let) :
\let\rightghost\luatexrightghost
\let\leftghost\luatexleftghost
{V\rightghost o}{\leftghost Vo\rightghost i}{\leftghost oi\rightghost
c}{\leftghost ic\rightghost i}{\leftghost ci}
et d'avoir en théorie le même résultat... sauf que en fait ça marche
pas... je ne saurais pas dire pourquoi. Ça a l'air de marcher pour
oici, mais pas pour Vo... bref, une piste en tout cas...
--
Elie
Manuel Pégourié-Gonnard
> Oui, tu as raison pour le crï¿œnage, je n'avais pas entrepris de chercher
> d'aussi faibles diffￜrences, je plaide coupable ! Quant ￜ la faￜon dont
> est composￜ le texte, c'est vrai que chaque lettre est gￜrￜe sￜparￜment,
> et il est en effet probable que TeX ne puisse pas mettre en ï¿œuvre le
> mￜme mￜcanisme de composition que lorsqu'elles sont les unes ￜ la suite
> des autres dans le code.
>
> C'est un peu le mï¿œme problï¿œme qu'avec {V}{o}{i}{c}{i} au lieu de Voici :
> la diffï¿œrence de crï¿œnage est nettement visible.
>
Tout ￜ fait.
> Bref, je ne vois absolument pas comment on pourrait faire pour que TeX
> voit les lettres comme si elles se suivaient dans le code. En effet, il
> faut bien qu'une commande demande ￜ changer la couleur entre chaque
> lettre (d'oￜ l'impossibilitￜ pour TeX de faire des ligatures). Un expert
> -- Manu ou Jean-Cï¿œme -- pourra sans doute nous en dire plus...
>
Sauf erreur de ma part, c'est impossible ￜ faire en pdfTeX. C'est
peut-ï¿œtre possible en Aleph/Omega (donc LuaTeX) avec la solution
proposï¿œe par ï¿œlie, mais c'est trï¿œs certainement possible en LuaTeX vu sa
faï¿œon diffï¿œrente de gï¿œrer les couleurs, et les possibilitï¿œs qu'il offre
pour gï¿œrer une liste de noeuds.
Si j'ai le temps dans les jours qui viennent, j'essairai de faire ï¿œa,
il me semble que ï¿œa peut ï¿œtre un exemple intï¿œressant.
> PS : la diffￜrence considￜrable qui apparait lorsque babel est chargￜ
> avec frenchb n'est toujours pas expliquï¿œe par contre...
La flemme d'essayer lￜ tout de suite, mais une idￜe au hasardￜ: le
mï¿œcanisme de coupure de lignes de TeX est relativement instable, dans le
sens oￜ de petits changements peuvent avoir de gros effets (mais pas
toujours). Est-ce que ce n'est pas tout simplement l'explication du
phï¿œnomï¿œne ? Et l'explication du fait qu'on observe une aussi grosse
diffï¿œrence seulement avec frenchb serait juste l'effet du hasard.
--
Manuel Pￜgouriￜ-Gonnard Institut de mathￜmatiques de Jussieu
http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/
Linuxman
>
>> Oui, tu as raison pour le crï¿œnage, je n'avais pas entrepris de chercher
>> d'aussi faibles diffￜrences, je plaide coupable ! Quant ￜ la faￜon dont
>> est composￜ le texte, c'est vrai que chaque lettre est gￜrￜe sￜparￜment,
>> et il est en effet probable que TeX ne puisse pas mettre en ï¿œuvre le
>> mￜme mￜcanisme de composition que lorsqu'elles sont les unes ￜ la suite
>> des autres dans le code.
>>
>> C'est un peu le mï¿œme problï¿œme qu'avec {V}{o}{i}{c}{i} au lieu de Voici :
>> la diffï¿œrence de crï¿œnage est nettement visible.
>>
> Tout ￜ fait.
>
>> Bref, je ne vois absolument pas comment on pourrait faire pour que TeX
>> voit les lettres comme si elles se suivaient dans le code. En effet, il
>> faut bien qu'une commande demande ￜ changer la couleur entre chaque
>> lettre (d'oￜ l'impossibilitￜ pour TeX de faire des ligatures). Un expert
>> -- Manu ou Jean-Cï¿œme -- pourra sans doute nous en dire plus...
>>
> Sauf erreur de ma part, c'est impossible ￜ faire en pdfTeX. C'est
> peut-ï¿œtre possible en Aleph/Omega (donc LuaTeX) avec la solution
> proposï¿œe par ï¿œlie, mais c'est trï¿œs certainement possible en LuaTeX vu sa
> faï¿œon diffï¿œrente de gï¿œrer les couleurs, et les possibilitï¿œs qu'il offre
> pour gï¿œrer une liste de noeuds.
>
> Si j'ai le temps dans les jours qui viennent, j'essairai de faire ï¿œa,
> il me semble que ï¿œa peut ï¿œtre un exemple intï¿œressant.
Est-ce que ï¿œa un rapport avec ï¿œa :
http://github.com/khaledhosny/fontspec
Khaled Hosny ï¿œcrit : "Color will be implemented in |luaotfload| too "
Mais que fait-il en fait ? Il amï¿œliore luaotfload aussi ?
Elie
>
> Est-ce que ça un rapport avec ça :
>
> http://github.com/khaledhosny/fontspec
>
> Khaled Hosny écrit : "Color will be implemented in |luaotfload| too "
Voire avec ça :
http://github.com/mpg/luaotfload/commit/3a9d5bbcba410869be83a42f5d6f0d0301c05416
Khaled Hosny écrit : "Initial XeTeX-like font color support"
> Mais que fait-il en fait ? Il améliore luaotfload aussi ?
C'est cela même, il suffit de regarder les derniers commits pour s'en
rendre compte... impressionnant !
--
Elie
Linuxman
> On 3 jan, 20:31, Linuxman <linuxm@n> wrote:
>>
>> http://github.com/khaledhosny/fontspec
>>
>> Khaled Hosny �crit : "Color will be implemented in |luaotfload| too "
>
> Voire avec �a :
>
> http://github.com/mpg/luaotfload/commit/3a9d5bbcba410869be83a42f5d6f0d0301c05416
>
> Khaled Hosny �crit : "Initial XeTeX-like font color support"
>
>> Mais que fait-il en fait ? Il am�liore luaotfload aussi ?
>
> C'est cela m�me, il suffit de regarder les derniers commits pour s'en
> rendre compte... impressionnant !
> --
> Elie
Luaotfload et fontspec vont �tre des packages concurrents sur Lualatex,
non ?
Manuel Pégourié-Gonnard
> Luaotfload et fontspec vont �tre des packages concurrents sur Lualatex,
> non ?
Non, luaotfload s'occupe des trucs de bas niveau, et fontspec pr�sente
une interface sympa � l'utilisateur. Au final et quand tout sera fini,
l'utilisateur aura l'impression que c'est fontspec qui est utilis�
partout (sur LuaLaTeX comme sur XeLaTeX).
--
Manuel P�gouri�-Gonnard Institut de math�matiques de Jussieu
http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/
Elie
>
> Non, luaotfload s'occupe des trucs de bas niveau, et fontspec présente
> une interface sympa à l'utilisateur. Au final et quand tout sera fini,
> l'utilisateur aura l'impression que c'est fontspec qui est utilisé
> partout (sur LuaLaTeX comme sur XeLaTeX).
Pour préciser un peu, luaotfload fait que la commande \font se
comporte de la même façon (ou presque) que celle de XeTeX, c'est à
dire qu'elle ouvre des otf, accepte des options opentype, etc.
Fontspec ne fait qu'utiliser cette commande \font boostée, de la même
façon (ou presque) sous XeLaTeX et LuaLaTeX, et donc a besoin de
luaotfload pour que ça marche.
--
Elie
Manuel Pégourié-Gonnard
> Sauf erreur de ma part, c'est impossible � faire en pdfTeX. C'est
> peut-�tre possible en Aleph/Omega (donc LuaTeX) avec la solution
> propos�e par �lie, mais c'est tr�s certainement possible en LuaTeX vu sa
> fa�on diff�rente de g�rer les couleurs, et les possibilit�s qu'il offre
> pour g�rer une liste de noeuds.
>
> Si j'ai le temps dans les jours qui viennent, j'essairai de faire �a,
> il me semble que �a peut �tre un exemple int�ressant.
>
Bon, alors je m'�tais compl�tement tromp� : l'exemple n'est pas
int�ressant du tout, Heiko a fait toute la partie ��marrante�� :-)
Plus pr�cis�ment, il a impl�ment� une gestion des couleurs en utilisant
les possibilit�s de LuaTeX, de fa�on qui n'interf�re pas le moins du
monde avec quoi que ce soit d'autre. En principe donc, il suffit de
charger luacolor pour activer cette gestion moderne des couleurs, et
hop.
En pratique, ce n'est pas vraiment � jour par rapport au format lualatex
qui a chang� dans TL09, donc une petite ligne en plus pour pouvoir le
charger. (Heiko est au courant, il n'a sans doute pas eu le temps.)
Un petite hack en plus pour pouvoir rebasculer sur l'anciennes gestion
des couleurs pour comparer, et pour le plaisir on se choisi ses couleurs
al�atoires en Lua, �a donne le code suivant.
\documentclass[a4paper]{article}
\usepackage[T1]{fontenc}
\usepackage[oldstyle]{kpfonts} % pour bien voir les ligatures :-)
\usepackage{xcolor}
\usepackage{xstring}
% en attendant que luacolor soit adapt�...
\directlua{tex.enableprimitives('', tex.extraprimitives('luatex'))}
% juste pour comparer les deux versions
% � faire avant de charger luacolor !
\makeatletter
\let\ori@set@color\set@color
\let\ori@reset@color\reset@color
\newcommand\RestoreStandardColors{%
\let\set@color\ori@set@color
\let\reset@color\ori@reset@color}
\makeatother
\usepackage{luacolor}
% pendant qu'on y est, on utilise Lua pour l'al�atoire...
% et on met un niveau maxi pour pas que �a fasse trop clair
\newcommand\random{%
\directlua{tex.print(math.random(0,127))}}
% merci Christian...
\makeatletter
\newcommand\colorize[1]{%
\expandafter\StrSplit\expandafter{#1}1\str@a\str@b
\ifx\str@a\space\ \else
\textcolor[RGB]{\random,\random,\random}{\str@a}%
\fi
\unless\ifx\@empty\str@b
\expandafter\colorize\expandafter\str@b\fi}
\makeatother
\newcommand\exemple{%
VAZY, montre-moi des approches de paires. Que c'est difficile
de trouver finement des ligatures affolantes d'esth�tique sans entrer dans
une secte !}
\begin{document}
\section{Au naturel}
\exemple
\section{Couleurs fa�on Lua\TeX}
\colorize\exemple
\section{Couleurs � l'ancienne}
\RestoreStandardColors
\colorize\exemple
\end{document}
Alors attention, je fais mon gros porc niveau encodage, j'abuse du fait
que les caract�res que j'utilise ont la m�me position dans Unicode que
dans T1 : les enfants, ne faites pas �a chez vous !
Enfin voil�, c'�tait juste pour dire que LuaTeX, c'est cool.
--
Manuel P�gouri�-Gonnard Institut de math�matiques de Jussieu
http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/
Paul Gaborit
� (at) Wed, 6 Jan 2010 00:05:24 +0100 (CET),
Manuel P�gouri�-Gonnard <m...@elzevir.fr> �crivait (wrote):
> Alors attention, je fais mon gros porc niveau encodage, j'abuse du fait
> que les caract�res que j'utilise ont la m�me position dans Unicode que
> dans T1 : les enfants, ne faites pas �a chez vous !
>
> Enfin voil�, c'�tait juste pour dire que LuaTeX, c'est cool.
Pour que la bidouille de codage fonctionne, il faut effectivement que
le document soit cod� en utf8.
Pour m'amuser, j'ai voulu m�langer deux enfilades : celle concernant
le 7 barr� et celle-ci. J'ai donc essay� ton exemple en utilisant
frcursive. Et j'arrive � ce petit ECM :
\documentclass[a4paper]{article}
\usepackage[T1]{fontenc}
\usepackage{frcursive}
\begin{document}
\begin{cursive}
ligature
\end{cursive}
\end{document}
Compiler avec pdflatex ou lualatex, il ne donne pas exactement le m�me
r�sultat. Est-ce d� � un bug de frcursive ou � une limitation de
lualatex ?
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Manuel Pégourié-Gonnard
> Pour que la bidouille de codage fonctionne, il faut effectivement que
> le document soit cod� en utf8.
>
Oui, en effet.
> \documentclass[a4paper]{article}
> \usepackage[T1]{fontenc}
> \usepackage{frcursive}
> \begin{document}
> \begin{cursive}
> ligature
> \end{cursive}
> \end{document}
>
> Compiler avec pdflatex ou lualatex, il ne donne pas exactement le m�me
> r�sultat.
En effet, c'est le moins que l'on puisse dire.
> Est-ce d� � un bug de frcursive ou � une limitation de
> lualatex ?
>
L�, je t'avoue que je n'en sais rien du tout. Aucun embryon de d�but
d'explication possible ne daigne traverser mon esprit...
Elie
>
> > Est-ce dû à un bug de frcursive ou à une limitation de
> > lualatex ?
>
> Là, je t'avoue que je n'en sais rien du tout. Aucun embryon de début
> d'explication possible ne daigne traverser mon esprit...
C'est selon toute vraisemblance un bug de LuaTeX... est-ce que
quelqu'un (sous debian sid par exemple, mais peu importe) peut
vérifier si
\font\toto=frca10 at 10pt\toto
ligature
\bye
donne bien des résultats différents sous LuaTeX 0.50 et pdfTeX? (je
n'ai pas la dernière version de LuaTeX sur la machine sur laquelle je
suis actuellement)
Merci,
--
Elie
Manuel Pégourié-Gonnard
> \font\toto=frca10 at 10pt\toto
> ligature
> \bye
>
> donne bien des r�sultats diff�rents sous LuaTeX 0.50 et pdfTeX? (je
> n'ai pas la derni�re version de LuaTeX sur la machine sur laquelle je
> suis actuellement)
>
C'est bien le cas. �a fonctionne correctement sous pdfTeX, pas sous
LuaTeX 0.50. Je ne sais pas si �a prouve que c'est un bug de LuaTeX (on
a vu des cas o� pdfTeX acceptait des .tfm th�oriquement invalides et pas
LuaTeX) mais la question m�rite s�rement d'�tre pos�e sur la liste. Qui
s'en occupe ?
Elie
Je m'en suis occupé : http://tug.org/pipermail/luatex/2010-January/001147.html
Merci,
--
Elie
Jacques M
>
>> Sauf erreur de ma part, c'est impossible � faire en pdfTeX. C'est
>> peut-�tre possible en Aleph/Omega (donc LuaTeX) avec la solution
>> propos�e par �lie, mais c'est tr�s certainement possible en LuaTeX vu sa
>> fa�on diff�rente de g�rer les couleurs, et les possibilit�s qu'il offre
>> pour g�rer une liste de noeuds.
>>
>> Si j'ai le temps dans les jours qui viennent, j'essairai de faire �a,
>> il me semble que �a peut �tre un exemple int�ressant.
>>
> Bon, alors je m'�tais compl�tement tromp� : l'exemple n'est pas
> int�ressant du tout, Heiko a fait toute la partie � marrante � :-)
>
> Plus pr�cis�ment, il a impl�ment� une gestion des couleurs en utilisant
> les possibilit�s de LuaTeX, de fa�on qui n'interf�re pas le moins du
> monde avec quoi que ce soit d'autre. En principe donc, il suffit de
> charger luacolor pour activer cette gestion moderne des couleurs, et
> hop.
Bonsoir et merci Manu de te pencher � nouveau sur ce probl�me
> En pratique, ce n'est pas vraiment � jour par rapport au format lualatex
> qui a chang� dans TL09, donc une petite ligne en plus pour pouvoir le
> charger. (Heiko est au courant, il n'a sans doute pas eu le temps.)
Mais quel est le probl�me au fond par rapport au format, je voudrais
bien savoir ? Le fait qu'avant (dans TL 08) le format lualatex avait une
sortie dvi (il fallait utiliser pdflualatex pour avoir une sortie pdf)
alors que maintenant la sortie est pdf (et pour avoir une sortie dvi, il
faut utiliser dvilualatex) ? Je dis �a j'en sais rien. Mais le package
devr tenir compte du fait qu'il devra se comporter diff�remment selon
qu'il est utilis� avec TL08 et TL09.
Manu, tu as contact� Oberdiek pour savoir ?
> Un petite hack en plus pour pouvoir rebasculer sur l'anciennes gestion
> des couleurs pour comparer, et pour le plaisir on se choisi ses couleurs
> al�atoires en Lua, �a donne le code suivant.
>
> \documentclass[a4paper]{article}
> \usepackage[T1]{fontenc}
> \usepackage[oldstyle]{kpfonts} % pour bien voir les ligatures :-)
> \usepackage{xcolor}
> \usepackage{xstring}
>
> % en attendant que luacolor soit adapt�...
> \directlua{tex.enableprimitives('', tex.extraprimitives('luatex'))}
Donc d�s que luacolor sera � jour cette ligne sera inutile donc.
Et l� je suis un peu largu�. Que faut-il modifier pour faire les choses
proprement ?
> Enfin voil�, c'�tait juste pour dire que LuaTeX, c'est cool.
C'est vrai c'est super, tout se passe bien.
Comment faire pour que cette commande marche aussi par exemple avec le
package lipsum quand je fais \colorize{\lipsum[1]} ou encore quand je
veux colorizer le titre d'une section.
Luatex c'est vrai que c'est g�nial rien que pour des trucs comme �a !
Manuel Pégourié-Gonnard
> Bonsoir et merci Manu de te pencher � nouveau sur ce probl�me
>
Je t'en prie, c'est aussi l'occasion pour moi d'en apprendre un peu
plus sur LuaTeX :-)
>> En pratique, ce n'est pas vraiment � jour par rapport au format lualatex
>> qui a chang� dans TL09, donc une petite ligne en plus pour pouvoir le
>> charger. (Heiko est au courant, il n'a sans doute pas eu le temps.)
>
> Mais quel est le probl�me au fond par rapport au format, je voudrais
> bien savoir ?
Le fait que depuis 2009, les nouvelles primitives de LuaTeX ne sont pas
pr�sentes dans le format, sauf \directlua : pour les utiliser, il faut
d'abord les activer, �ventuellement avec un pr�fixe, en utilisant une
fonction lua. Le but �tant d'essayer d'augmenter la compatibilit� avec
les macros existantes en rendant des conflits de noms moins probables.
> Manu, tu as contact� Oberdiek pour savoir ?
>
Je l'ai contact� avant la sortie de TL09 pour l'avertir du changement
dans le format. Il m'a r�pondu qu'il en prenait bonne note, mais n'avait
pas le temps d'effectuer la mise � jour dans les semaines qui venaient.
>> % en attendant que luacolor soit adapt�...
>> \directlua{tex.enableprimitives('', tex.extraprimitives('luatex'))}
>
> Donc d�s que luacolor sera � jour cette ligne sera inutile donc.
>
Exactement.
>> Alors attention, je fais mon gros porc niveau encodage, j'abuse du fait
>> que les caract�res que j'utilise ont la m�me position dans Unicode que
>> dans T1 : les enfants, ne faites pas �a chez vous !
>
> Et l� je suis un peu largu�. Que faut-il modifier pour faire les choses
> proprement ?
>
J'ai fait les choses salement parce que j'avais la flemme de r�fl�chir �
cette question, justement :-)
Niveau codage d'entr�e, puisqu'on sait que le truc sera compil� avec
LuaTeX, mettre de l'UTF-8 sans le d�clarer est correct, puique c'est
l'encodage par d�faut du moteur. C�t� codage de sortie, � ma
connaissance il n'y a pas encore de moyen ��propre�� d'utiliser des
fontes non-unicode comme �a. Donc il faudrait soit charger une police
Unicode (le plus probablement OpenType) ce qui marche bien avec
luaotfload mais avec un syntaxe fa�on Plain TeX, l'interface fa�on LaTeX
(� savoir la version LuaLaTeX de fontspec) n'�tant pas encore finie.
Pour utiliser des fontes T1, il faudrait charger luainputenc avec le
mode Kivabien pour qu'il fasse les choses � l'ancienne en rendant actifs
tous les caract�res non-ascii, mais il faut bien reconna�tre que �a fait
un peu mal au coeur...
> C'est vrai c'est super, tout se passe bien.
> Comment faire pour que cette commande marche aussi par exemple avec le
> package lipsum quand je fais \colorize{\lipsum[1]} ou encore quand je
> veux colorizer le titre d'une section.
>
Pour faire marcher \colorize{\lipsum[1]}, il faut il me semble changer
toute sa logique. Mais c'est possible � faire marcher de fa�on fiable en
LuaTeX : c'est un autre exercice que j'aimerais faire quand j'aurai le
temps.
Pour un titre de section, il me semble que �a devrait marcher comme �a :
\section{\protect\colorize{Blabla}}
(pas test�). Si c'est le cas, on peut remplacer \newcommand\colorize pas
\DeclareRobustCommand\colorize plus haut pour �viter d'avoir � saisir le
\protect � chaque fois.
Elie
>
> Pour utiliser des fontes T1, il faudrait charger luainputenc avec le
> tous les caractères non-ascii, mais il faut bien reconnaître que ça fait
> un peu mal au coeur...
C'est \usepackage[utf8]{luainputenc} qui fait ça, pour utiliser
directement des fontes unicode pas besoin de charger luainputenc.
--
Elie
Jacques M
>
>> Bonsoir et merci Manu de te pencher � nouveau sur ce probl�me
>>
> Je t'en prie, c'est aussi l'occasion pour moi d'en apprendre un peu
> plus sur LuaTeX :-)
>
>>> En pratique, ce n'est pas vraiment � jour par rapport au format lualatex
>>> qui a chang� dans TL09, donc une petite ligne en plus pour pouvoir le
>>> charger. (Heiko est au courant, il n'a sans doute pas eu le temps.)
>> Mais quel est le probl�me au fond par rapport au format, je voudrais
>> bien savoir ?
>
> Le fait que depuis 2009, les nouvelles primitives de LuaTeX ne sont pas
> pr�sentes dans le format,
Et cela vient de quoi ? D'un choix de l'�quipe texlive ou luatex ?
> sauf \directlua : pour les utiliser, il faut
> d'abord les activer, �ventuellement avec un pr�fixe, en utilisant une
> fonction lua.
Int�ressant et comment fait-on cela ? En faisant exactement comme tu
l'as fait dans le code que tu as propos� � savoir :
\directlua{tex.enableprimitives('', tex.extraprimitives('luatex'))}
Si je comprends bien, tu as r�activ� les primitives tex seulement (mais
pas celles de etex, pdftex, omega, aleph peut-�tre je ne sais pas tu me
diras) en ne leur donnant aucun pr�fixe ('') ?
> Le but �tant d'essayer d'augmenter la compatibilit� avec
> les macros existantes en rendant des conflits de noms moins probables.
>
>> Manu, tu as contact� Oberdiek pour savoir ?
>>
> Je l'ai contact� avant la sortie de TL09 pour l'avertir du changement
> dans le format. Il m'a r�pondu qu'il en prenait bonne note, mais n'avait
> pas le temps d'effectuer la mise � jour dans les semaines qui venaient.
>
>>> % en attendant que luacolor soit adapt�...
>>> \directlua{tex.enableprimitives('', tex.extraprimitives('luatex'))}
>> Donc d�s que luacolor sera � jour cette ligne sera inutile donc.
>>
> Exactement.
>
>>> Alors attention, je fais mon gros porc niveau encodage, j'abuse du fait
>>> que les caract�res que j'utilise ont la m�me position dans Unicode que
>>> dans T1 : les enfants, ne faites pas �a chez vous !
>> Et l� je suis un peu largu�. Que faut-il modifier pour faire les choses
>> proprement ?
>>
> J'ai fait les choses salement parce que j'avais la flemme de r�fl�chir �
> cette question, justement :-)
>
> Niveau codage d'entr�e, puisqu'on sait que le truc sera compil� avec
> LuaTeX, mettre de l'UTF-8 sans le d�clarer est correct, puique c'est
> l'encodage par d�faut du moteur.
Tr�s clairement, cela signifie qu'avec lualatex
\usepackage[utf8]{luainputenc} ne sert strictement � rien ?
> C�t� codage de sortie, � ma
> connaissance il n'y a pas encore de moyen � propre � d'utiliser des
> fontes non-unicode comme �a. Donc il faudrait soit charger une police
> Unicode (le plus probablement OpenType) ce qui marche bien avec
> luaotfload mais avec un syntaxe fa�on Plain TeX, l'interface fa�on LaTeX
> (� savoir la version LuaLaTeX de fontspec) n'�tant pas encore finie.
Tu voulais ajouter une autre chose : tu disais "il faudrait soit ..."
mais tu as oubli� de donner l'autre id�e (introduite par un autre "soit")
> Pour utiliser des fontes T1, il faudrait charger luainputenc avec le
> mode Kivabien pour qu'il fasse les choses � l'ancienne en rendant actifs
> tous les caract�res non-ascii, mais il faut bien reconna�tre que �a fait
> un peu mal au coeur...
>
>> C'est vrai c'est super, tout se passe bien.
>> Comment faire pour que cette commande marche aussi par exemple avec le
>> package lipsum quand je fais \colorize{\lipsum[1]} ou encore quand je
>> veux colorizer le titre d'une section.
>>
> Pour faire marcher \colorize{\lipsum[1]}, il faut il me semble changer
> toute sa logique. Mais c'est possible � faire marcher de fa�on fiable en
> LuaTeX : c'est un autre exercice que j'aimerais faire quand j'aurai le
> temps.
>
> Pour un titre de section, il me semble que �a devrait marcher comme �a :
>
> \section{\protect\colorize{Blabla}}
>
> (pas test�). Si c'est le cas, on peut remplacer \newcommand\colorize pas
> \DeclareRobustCommand\colorize plus haut pour �viter d'avoir � saisir le
> \protect � chaque fois.
Ca marche tr�s bien. Il ne reste plus que le probl�me avec lipsum. Ce
n'est pas la premi�re fois que ce package pose quelques petits soucis
dans des situations bien pr�cises.
Merci Manu
Manuel Pégourié-Gonnard
>> Le fait que depuis 2009, les nouvelles primitives de LuaTeX ne sont pas
>> pr�sentes dans le format,
>
Rh�a, mais je dois n'importe quoi, moi. Elles sont pr�sentes, simplement
elles sont pr�fix�es par 'luatex', sauf si leur nom commence d�j� par
luatex, et sauf \directlua :
- \directlua reste \directlua
- \attribute devient \luatexattribute
- \primitive devient \luatexprimitive, et l'alias \pdfprimitive reste
- \luatexversion reste \luatexversion
> Et cela vient de quoi ? D'un choix de l'�quipe texlive ou luatex ?
>
L'�quipe LuaTeX, apr�s une "longue discussion parfois agit�e" sur la
liste LuaTeX, a d�cid� que toutes les primitives non-TeX82 sauf
\directlua seraient cach�es en mode INITEX (celui qui est utilis� pour
construire les formats) et activables en Lua, pr�cis�ment pour permettre
ce genre de chose. La d�cision finale de proc�der comme �a vient de TeX
Live, apr�s de longues discussions impliquant des membres de l'�quipe
LaTeX3.
Tout �a m fait penser qu'on a oubli� de bien documenter la chose et ses
motivations... Enfin j'avais expliqu� �a par mail � tous les auteurs
connus de paquets pour LuaLaTeX, mais bon...
> Int�ressant et comment fait-on cela ? En faisant exactement comme tu
> l'as fait dans le code que tu as propos� � savoir :
> \directlua{tex.enableprimitives('', tex.extraprimitives('luatex'))}
>
> Si je comprends bien, tu as r�activ� les primitives tex seulement (mais
> pas celles de etex, pdftex, omega, aleph peut-�tre je ne sais pas tu me
> diras) en ne leur donnant aucun pr�fixe ('') ?
>
L�, j'a activ� les primitives sp�cifiques � luatex (argument de
tex.extraprimitives) sans aucun pr�fixe. Celles d'etex et de pdftex sont
activ�es dans le format. Pour avoir en plus celles d'omega et aleph, on
aurait fait :
\directlua{tex.enableprimitives('',
tex.extraprimitives('luatex', 'omega', aleph'))}
>> Niveau codage d'entr�e, puisqu'on sait que le truc sera compil� avec
>> LuaTeX, mettre de l'UTF-8 sans le d�clarer est correct, puique c'est
>> l'encodage par d�faut du moteur.
>
> Tr�s clairement, cela signifie qu'avec lualatex
> \usepackage[utf8]{luainputenc} ne sert strictement � rien ?
>
Non, au contraire. �a active un mode de compatibilit� qui permet �
fontenc de fonctionner. Dans l'attente d'une �mulation de fontenc qui
n'ait pas besoin de �a, c'est la seule solution pour utiliser des fontes
utilisant un encodage � classique � comme T1, par opposition aux fontes
Unicode.
Sans entre dans les d�tails, disons qu'il y a trois encodages en jeu
dans l'histoire : l'encodage d'entr�e, l'encodage interne, l'encodage de
sortie (de fonte). Par d�faut, LuaTeX utilise UTF-8 comme encodage
d'entr�e, le num�ro de point de code Unicode comme repr�sentation
interne, et suppose que les fontes sont en Unicode.
Au contraire, LaTeX avec inputenc et fontenc utilise l'option d'inputenc
comme encodage d'entr�e, la LICR (LaTeX internal character
representation) comme... repr�sentation interne (sans rire), et l'option
donn�e � fontenc comme encodage de sortie (mais en fait ici c'est plus
compliqu�, il sait jongler entre plusieurs encodages, par exemple il va
chercher l'euro dans TS1, etc).
Donc, fontenc ne sait que traduire de LICR vers l'encodage de sortie. Si
on veut qu'il marche, il faut donc traduire l'entr�e en LICR, et c'est
ce que fait (pour l'instant ?) \usepackage[utf8]{luainputenc}.
>> C�t� codage de sortie, � ma
>> connaissance il n'y a pas encore de moyen � propre � d'utiliser des
>> fontes non-unicode comme �a. Donc il faudrait soit charger une police
>> Unicode (le plus probablement OpenType) ce qui marche bien avec
>> luaotfload mais avec un syntaxe fa�on Plain TeX, l'interface fa�on LaTeX
>> (� savoir la version LuaLaTeX de fontspec) n'�tant pas encore finie.
>
> Tu voulais ajouter une autre chose : tu disais "il faudrait soit ..."
> mais tu as oubli� de donner l'autre id�e (introduite par un autre "soit")
>
... soit utiliser un fonte T1 (ou autre) comme expliqu� ci-dessus.
D�sol� pour la rupture de syntaxe.
>> Pour utiliser des fontes T1, il faudrait charger luainputenc avec le
>> mode Kivabien pour qu'il fasse les choses � l'ancienne en rendant actifs
>> tous les caract�res non-ascii, mais il faut bien reconna�tre que �a fait
>> un peu mal au coeur...
>> (pas test�). Si c'est le cas, on peut remplacer \newcommand\colorize pas
>> \DeclareRobustCommand\colorize plus haut pour �viter d'avoir � saisir le
>> \protect � chaque fois.
>
> Ca marche tr�s bien. Il ne reste plus que le probl�me avec lipsum. Ce
> n'est pas la premi�re fois que ce package pose quelques petits soucis
> dans des situations bien pr�cises.
>
Non, l� ce n'est pas un probl�me de lipsum, �a planterait aussi avec un
\textbf ou tout autre commande apparament innocente.
Le probl�me, c'est qu'on veut effectuer un truc � caract�re par
caract�re �, mais qu'en (pdf)TeX on ne peut pas : on travail lex�me par
lex�me. En clair, avec un \textbf dans le coin, le code actuel va tenter
un \textcolor{red}{\textbf} et tu te doutes que �a fait mal :-)
C'est une limitation fondamentale de (pdf)TeX. LuaTeX permet d'attendre
que le source soit transform� en paragraphe pour ensuite travailler
vraiment sur les caract�res qui le composent, un par un, comme on veut.
Elie
>
> Je m'en suis occupé :http://tug.org/pipermail/luatex/2010-January/001147.html
Réponse de Taco:
Something is wrong in luatex: the routine that inserts the
discretionaries has a problem with the massive amount of ligatures
in the frca10 font. I will add a tracker item, but it may take a
while to fix this.
--
Elie
Manuel Pégourié-Gonnard
>> Ca marche tr�s bien. Il ne reste plus que le probl�me avec lipsum. Ce
>> n'est pas la premi�re fois que ce package pose quelques petits soucis
>> dans des situations bien pr�cises.
>>
> Non, l� ce n'est pas un probl�me de lipsum, �a planterait aussi avec un
> \textbf ou tout autre commande apparament innocente.
>
> Le probl�me, c'est qu'on veut effectuer un truc � caract�re par
> caract�re �, mais qu'en (pdf)TeX on ne peut pas : on travail lex�me par
> lex�me. En clair, avec un \textbf dans le coin, le code actuel va tenter
> un \textcolor{red}{\textbf} et tu te doutes que �a fait mal :-)
>
> C'est une limitation fondamentale de (pdf)TeX. LuaTeX permet d'attendre
> que le source soit transform� en paragraphe pour ensuite travailler
> vraiment sur les caract�res qui le composent, un par un, comme on veut.
>
Bon, pour info j'ai essay� de faire le truc vraiment caract�re par
caract�re avec LuaTeX, et une fois qu'on a compris comment faire c'est
relativement moins compliqu� que je n'aurais cru. Le probl�me, c'est que
luacolor n'offre pas d'interface Lua � certaines fonctionnalit�s, donc
on ne peut pas r�gler le couleur des noeuds en Lua a posteriori.
Fin de l'histoire pour le moment : c'est th�oriquement possible de faire
une macro \colorize qui marche en toutes circonstances, mais pas avec le
luacolor actuel.
� l'occasion, je soumettrai un patch � Heiko pour �a, �a serait vraiment
sympa. On peut imaginer toutes sortes d'applications (genre mettre
automatiquement en rouge toutes les occurences d'un mot, etc). (Mais il
y a des trucs plus urgents � voir au niveau des packages LuaTeX, donc �a
arrivera quand �a arrivera.)
Sébastien
Tu veux dire que Oberdiek a d�j� pas mal de boulot sur des packages
d�di� � luatex ? Sur quoi travaille-t-il ?
Toute am�lioration qui tendrait � am�liorer les interactions entre le
texte et l'aspect graphique (qui ne concerne pas le texte) est toujours
la bienvenue et je crois que c'est vraiment dans ce domaine que tex a
besoin de repousser les limites pour montrer son efficacit�.
Manuel Pégourié-Gonnard
> Manuel P�gouri�-Gonnard a �crit :
>> � l'occasion, je soumettrai un patch � Heiko pour �a, �a serait vraiment
>> sympa. On peut imaginer toutes sortes d'applications (genre mettre
>> automatiquement en rouge toutes les occurences d'un mot, etc). (Mais il
>> y a des trucs plus urgents � voir au niveau des packages LuaTeX, donc �a
>> arrivera quand �a arrivera.)
>
> Tu veux dire que Oberdiek a d�j� pas mal de boulot sur des packages
> d�di� � luatex ? Sur quoi travaille-t-il ?
Je ne sais pas ce que fait Heiko et ce qu'il projette pour la suite (mis
� part que ses paquet pour luatex ne sont actuellement pas � jour).
Ce que je voulais dire, c'est que sur ma todo-list personnelle
concernant le support de luatex sous latex, il y a des trucs plus
urgents que pr�parer ce patch et le soumettre � Heiko. Et je suis
d�sol�, mais pour l'instant ce sont surtout des fonctions de bas niveau
(la partie de base de luatextra) et de compatibilit� (luainputenc, une
�ventuelle adaptation de fontenc) donc rien de tr�s sexy.
> Toute am�lioration qui tendrait � am�liorer les interactions entre le
> texte et l'aspect graphique (qui ne concerne pas le texte) est toujours
> la bienvenue et je crois que c'est vraiment dans ce domaine que tex a
> besoin de repousser les limites pour montrer son efficacit�.
Bien s�r. Pour l'instant, j'ai l'impression (peut-�tre suis-je
pessimiste) qu'on devrait d'abord viser l'�tape 0, � savoir ��juste �a
marche � de fa�on comparable � XeLaTeX actuellement (� savoir : qu'on
puisse facilement porter sous lualatex un document latex existant, que
l'essentiel des trucs qui marchaient sous pdfTeX continuent de marcher,
certaines nouveaut�s essentielles (fontspec) soient essentiellement
fonctionnelles, et que la paquets de base pour les d�veloppeurs soient
stables). C'est en bonne voie, mais on y est pas encore.
Sébastien
Ce qui sera sympa, c'est de pouvoir agir sur les lettres prises une �
une (changer les couleurs tout en respectant les ligatures, le cr�nage,
comme dans l'exemple que tu as donn�) ou un peu plus globalement sur les
mots pris un par un.
Manuel Pégourié-Gonnard
> Ce qui sera sympa, c'est de pouvoir agir sur les lettres prises une �
> une (changer les couleurs tout en respectant les ligatures, le cr�nage,
> comme dans l'exemple que tu as donn�)
On peut, c'est pr�cis�ment ce que j'aurais voulu montrer, car c'est une
des avanc�es majeures par rapport � pdfTeX. C'est juste que l'action
"changer la couleur" n'est actuellement pas disponible via Lua.
> ou un peu plus globalement sur les
> mots pris un par un.
D�s qu'on a une bonne d�finition de � mot �, c'est faisable aussi :-)
Sébastien
>
>> Ce qui sera sympa, c'est de pouvoir agir sur les lettres prises une �
>> une (changer les couleurs tout en respectant les ligatures, le cr�nage,
>> comme dans l'exemple que tu as donn�)
>
> On peut, c'est pr�cis�ment ce que j'aurais voulu montrer, car c'est une
> des avanc�es majeures par rapport � pdfTeX. C'est juste que l'action
> "changer la couleur" n'est actuellement pas disponible via Lua.
>
>> ou un peu plus globalement sur les
>> mots pris un par un.
>
> D�s qu'on a une bonne d�finition de � mot �, c'est faisable aussi :-)
Euh la d�finition de mot telle que nous la connaissons dans la grammaire
fran�aise, je n'en vois pas d'autres. Apr�s, s'il s'agit de s'int�resser
� d'autres langues �a peut devenir difficile.
En fait tu voulais parler de comment faire comprendre � TeX ce qu'est un
mot. Une piste : je crois qu'il existe des scripts (perl peut-�tre)
capable de compter les mots : il n'y a *plus qu'�* traduire en lua. Trop
fastoche.
Jean-Côme Charpentier
> Manuel P�gouri�-Gonnard a �crit :
>
> Euh la d�finition de mot telle que nous la connaissons dans la grammaire
> fran�aise, je n'en vois pas d'autres. Apr�s, s'il s'agit de s'int�resser
> � d'autres langues �a peut devenir difficile.
> En fait tu voulais parler de comment faire comprendre � TeX ce qu'est un
> mot.
C'�tait �videmment la question... Enfin, je suppose, je ne suis pas
non plus dans la t�te de Manuel.
> Une piste : je crois qu'il existe des scripts (perl peut-�tre)
> capable de compter les mots : il n'y a *plus qu'�* traduire en lua. Trop
> fastoche.
1. Ce n'est pas si fastoche visiblement.
2. C'est une FAQ.
3. Il n'existe pas un mais une pl�thore d'outils et le truc marrant,
c'est qu'aucun ne donne les m�mes r�sultats.
Un exemple mais je suis s�r que des vrais grammariens trouveront
encore plus tordu.
positif-n�gatif -> combien de mot(s) ?
chou-fleur -> combien de mot (sans s) ?
Jean-C�me Charpentier
--
Tu n'h�sites pas sur la m�me chose que celle sur laquelle Jean-C�me
affirme qu'il n'h�site pas (c'est clair ma phrase ?). Il dit qu'il
sait sans h�siter que \telque �a veut dire "tel que", tu dis que tu
ne sais pas si �a se repr�sente par une barre verticale ou pas, je dis
que je m'en fous, il dit qu'il n'a plus de genou, ils disent qu'ils ne
voient pas le rapport.
-+- mpg in fr.comp.text.tex -+-
Paul Gaborit
� (at) Wed, 13 Jan 2010 07:39:18 +0100,
Jean-C�me Charpentier <Jean-Come....@wanadoo.fr> �crivait (wrote):
> Un exemple mais je suis s�r que des vrais grammariens trouveront
> encore plus tordu.
>
> positif-n�gatif -> combien de mot(s) ?
> chou-fleur -> combien de mot (sans s) ?
On a aussi les classiques :
l'�t� => a priori, deux mots
aujourd'hui => a priori, un mot
Denis Bitouzé
Paul Gaborit <Paul.G...@invalid.invalid> a écrit :
> On a aussi les classiques :
>
> l'été => a priori, deux mots
> aujourd'hui => a priori, un mot
Et que dire du sot-l'y-laisse ?
--
Denis
Jean-Côme Charpentier
> Le mercredi 13/01/10 ￜ 10h16,
> Paul Gaborit <Paul.G...@invalid.invalid> a ï¿œcrit :
>
>> On a aussi les classiques :
>>
>> aujourd'hui => a priori, un mot
>
> Et que dire du sot-l'y-laisse ?
En fait, je reviens mï¿œme sur l'affirmation que la dï¿œfinition
(grammaticale) du mot ￜ mot ￜ est ￜvidente. Voir par exemple
<http://fr.wikipedia.org/wiki/Mot>
avec le dￜpart ￜ la notion de mot soulￜve d'importants problￜmes
d'identification ￜ. ￜa peut calmer certaines ardeurs (juvￜniles ?)
Jean-Cï¿œme Charpentier (vieux schnock)
--
<zpz> \newcommand*{\paran}[2][0pt]{\mathpalette\p@r@n{{#1}{#2}}}
<Joss> C'est l'un des premiers codes non triviaux qui soit programmￜ
proprement que je voie sur ce forum. Je suis ï¿œmu.
-+- in fr.comp.text.tex -+-
Sébastien
> S�bastien scripsit :
>
>> Manuel P�gouri�-Gonnard a �crit :
>>> � l'occasion, je soumettrai un patch � Heiko pour �a, �a serait vraiment
>>> sympa. On peut imaginer toutes sortes d'applications (genre mettre
>>> automatiquement en rouge toutes les occurences d'un mot, etc). (Mais il
>>> y a des trucs plus urgents � voir au niveau des packages LuaTeX, donc �a
>>> arrivera quand �a arrivera.)
>> Tu veux dire que Oberdiek a d�j� pas mal de boulot sur des packages
>> d�di� � luatex ? Sur quoi travaille-t-il ?
>
> Je ne sais pas ce que fait Heiko et ce qu'il projette pour la suite (mis
> � part que ses paquet pour luatex ne sont actuellement pas � jour).
On voit passer des mises � jour des packages d'Heiko Oberdeik, c'est
peut-�tre le temps Manu de lui soumettre ton patch s'il est dans une
p�riode o� il cherche � mettre � niveau ses packages.
Enfin, moi je dis �a, j'dis rien...