gratifiant > comp.* > comp.text.tex

moky (13/02/2010, 21h49)
Bonjour à toutes et à tous

Je suis en train de taper des exercices de math[1], et j'aimerais de
temps en temps y glisser des liens vers wikipédia.
Les deux dernières en date qui me posent problème sont :
)


à cause respectivement de la parenthèse et de l'apostrophe.

Si je fais ceci
\href{http://fr.wikipedia.org/wiki/Norme_(mathématiques)}{norme}
alors le lien pointe vers


J'ai essayé d'ajouter des \ un peu partout sans succès. Est-ce qu'il y
a un truc ?
Bonne soirée
Laurent

[1] pour qui ça intéresse.
Manuel Pégourié-Gonnard (13/02/2010, 22h08)
moky scripsit :

> Les deux dernières en date qui me posent problème sont :
> )
>
> à cause respectivement de la parenthèse et de l'apostrophe.

Qui, comme par hasard, sont des caractères réservés dans l'écriture des
URI. Il y aurait un rapport que ça ne m'étonnerait pas plus que ça :-)

> J'ai essayé d'ajouter des \ un peu partout sans succès.


Ce qui n'est pas étonnant, vu que ce n'est pas à TeX que ces caractères
posent problème. Ici, il faut plutôt pourcent-encoder les caractères
problématiques. Pendant qu'on y est, autant faire la même chose avec
les caractères non-ASCII. On obtient :

\href{http://fr.wikipedia.org/wiki/Norme_%28math%C3%A9matiques%29}{norme}

Par chance, hyperref est super bien fait et on a pas de problème ici
avec le signe '%'. Si on était dans l'argument d'une autre commande, ça
serait une autre histoire...

> Est-ce qu'il y a un truc ?


Je pense que ceci devrait résoudre le problème, mais en même temps je ne
prétends pas avoir une compréhension complète du RFC 3986, donc
peut-être que je dis des bêtises depuis le début. Si c'est le cas, je
pense que Paul corrigera.
Alain Ketterlin (13/02/2010, 22h15)
moky <moky.math> writes:

[...]
> Si je fais ceci
> \href{http://fr.wikipedia.org/wiki/Norme_(mathématiques)}{norme}
> alors le lien pointe vers
>
> J'ai essayé d'ajouter des \ un peu partout sans succès. Est-ce qu'il y
> a un truc ?


Je fais cela souvent, et sans problème. Peut-être que

\usepackage[T1]{fontenc}

(si c'est possible) règlera ton problème.

-- Alain.

P/S: Un exemple compilable aurait été sympa...
moky (13/02/2010, 22h31)
> \usepackage[T1]{fontenc}
> (si c'est possible) règlera ton problème.


l'ECM suivant reproduit le problème chez moi malgré \usepackage[T1]
{fontenc}

-------------------------- ECM -------------------------------
\documentclass[a4paper,12pt]{book}

\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{hyperref}

\begin{document}
\href{http://fr.wikipedia.org/wiki/Norme_(mathématiques)}{norme}
\end{document}
-------------------------- FIN -------------------------------

La solution de Manuel fonctionne, mais elle risque d'engendrer la
question
"comment faire faire des changements automatiques dans une chaîne de
caractères ?"
si je ne trouve rien dans les différentes FAQ ;)

Juste pour info, j'utilise la vieille version de texlive fournie avec
Ubuntu. Si tu crois qu'une mise à jour peut aider, je peux installer
la nouvelle (il me semble avoir lu qu'il y avait un dépot non officiel
avec texlive 2009 pour Ubuntu)

Bonne soirée et merci
Laurent
Manuel Pégourié-Gonnard (13/02/2010, 22h55)
moky scripsit :

> La solution de Manuel fonctionne, mais elle risque d'engendrer la
> question
> "comment faire faire des changements automatiques dans une chaîne de
> caractères ?"
> si je ne trouve rien dans les différentes FAQ ;)

Bah, pour faire des changements automatiques dans une chaine de
caractères, on a xstring :-) Maintenant, une question qui se pose, c'est
qu'il ne faut pas systématiquement pourcent-encoder les caractères
réservés. Ici, c'est juste parce qu'on veut les utiliser en dehors de
leur rôle de (sous-)délimiteurs. Donc faire des changements
automatiques, OK, mais il faudra quand même qu'à un moment l'humain
décide de ce qu'il faut pourcent-encoder ou pas.

Une autre question qui se pose, c'est celle des caractères non ASCII.
Là, ça me paraît déjà plus coton.

> Juste pour info, j'utilise la vieille version de texlive fournie avec
> Ubuntu. Si tu crois qu'une mise à jour peut aider, je peux installer
> la nouvelle (il me semble avoir lu qu'il y avait un dépot non officiel
> avec texlive 2009 pour Ubuntu)

Je ne crois pas qu'une mise à jour de TeX Live change des trucs à ce
sujet, mais en tout cas le dépôt TL09 pour ubuntu karmic est ici :

Pétiard François (13/02/2010, 23h04)
Le 13/02/2010 21:31, moky a écrit :
[..]
> \href{http://fr.wikipedia.org/wiki/Norme_(mathématiques)}{norme}
> \end{document}
> -------------------------- FIN -------------------------------


Chez moi (MiKTeX 2.7 à jour, aucun problème pour l'URL. Depuis Adobe
Reader, le lien est correct.
Voici le résultat de \listfiles :

*File List*
book.cls 2007/10/19 v1.4h Standard LaTeX document class
bk12.clo 2007/10/19 v1.4h Standard LaTeX file (size option)
inputenc.sty 2008/03/30 v1.1d Input encoding file
utf8.def 2008/04/05 v1.1m UTF-8 support for inputenc
t1enc.dfu 2008/04/05 v1.1m UTF-8 support for inputenc
ot1enc.dfu 2008/04/05 v1.1m UTF-8 support for inputenc
omsenc.dfu 2008/04/05 v1.1m UTF-8 support for inputenc
fontenc.sty
t1enc.def 2005/09/27 v1.99g Standard LaTeX file
hyperref.sty 2010/02/08 v6.80e Hypertext links for LaTeX
keyval.sty 1999/03/16 v1.13 key=value parser (DPC)
kvsetkeys.sty 2010/01/28 v1.8 Key value parser (HO)
infwarerr.sty 2007/09/09 v1.2 Providing info/warning/message (HO)
etexcmds.sty 2010/01/28 v1.3 Prefix for e-TeX command names (HO)
pdfescape.sty 2007/11/11 v1.8 Provides hex, PDF name and string
conversions
(HO)
pdftexcmds.sty 2009/12/12 v0.7 Utility functions of pdfTeX for LuaTeX
(HO)
ifluatex.sty 2009/04/17 v1.2 Provides the ifluatex switch (HO)
ltxcmds.sty 2010/01/28 v1.2 LaTeX kernel commands for general use (HO)
ifpdf.sty 2010/01/28 v2.1 Provides the ifpdf switch (HO)
ifvtex.sty 2008/11/04 v1.4 Switches for detecting VTeX and its
modes (HO)
ifxetex.sty 2009/01/23 v0.5 Provides ifxetex conditional
hycolor.sty 2009/12/12 v1.6 Color options of hyperref/bookmark (HO)
xcolor-patch.sty 2009/12/12 xcolor patch
letltxmacro.sty 2008/06/24 v1.3 Let assignment for LaTeX macros (HO)
pd1enc.def 2010/02/08 v6.80e Hyperref: PDFDocEncoding definition (HO)
intcalc.sty 2007/09/27 v1.1 Expandable integer calculations (HO)
hyperref.cfg 2002/06/06 v1.2 hyperref configuration of TeXLive
kvoptions.sty 2009/12/08 v3.6 Keyval support for LaTeX options (HO)
url.sty 2006/04/12 ver 3.3 Verb mode for urls, etc.
bitset.sty 2007/09/28 v1.0 Data type bit set (HO)
bigintcalc.sty 2007/11/11 v1.1 Expandable big integer calculations (HO)
atbegshi.sty 2009/12/02 v1.10 At begin shipout hook (HO)
hpdftex.def 2010/02/08 v6.80e Hyperref driver for pdfTeX
atveryend.sty 2010/01/25 v1.4 Hooks at very end of document (HO)
rerunfilecheck.sty 2010/01/25 v1.3 Rerun checks for auxiliary files (HO)
uniquecounter.sty 2009/12/18 v1.1 Provides unlimited unique counter (HO)
nameref.sty 2010/01/25 v2.36 Cross-referencing by name of section
refcount.sty 2008/08/11 v3.1 Data extraction from references (HO)
gettitlestring.sty 2009/12/18 v1.3 Cleanup title references (HO)
gettitlestring.cfg
test-hyperref-href.out
test-hyperref-href.out
***********

François
unbonpetit (13/02/2010, 23h43)
Le 13/02/2010 21:55, Manuel Pégourié-Gonnard a écrit :
> moky scripsit :
> Bah, pour faire des changements automatiques dans une chaine de
> caractères, on a xstring :-)


Oui, il y a aussi ted, et sa délicieuse macro \Substitute non ? :P

> Une autre question qui se pose, c'est celle des caractères non ASCII.
> Là, ça me paraît déjà plus coton.

Bah, ça ne pose pas trop de problème puisque le catcode de chaque
caractère importe peu.
En utf8, le caractère "é" est constitué de 2 octets C3 A9 et inputenc
avec l'option utf8 déclare la caractère ^^c3 comme actif. Pour xstring,
comme pour ted, cela n'a pas grande importance puisque les catcodes sont
pris en compte, la substitution se fait normalement.

Par contre, je me suis rendu compte d'un petit bug dans xstring il y a
quelques jours : le comptage des caractères est faux en utf8 lorsque les
arguments ne sont pas développés (ce qui est tout à fait logique
d'ailleurs puisque xstring compte les octets). Le bug est que ce n'est
pas signalé dans la doc.

\documentclass{article}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{xstring}
\begin{document}
\StrSubstitute{étété}{é}{u}

Nombre de caractères dans étété : \StrLen{étété}

\noexpandarg
\StrSubstitute{étété}{é}{u}

Nombre de caractères dans étété : \StrLen{étété}
\end{document}
moky (13/02/2010, 23h48)
> Bah, pour faire des changements automatiques dans une chaine de
> caract?res, on a xstring :-) Maintenant, une question qui se pose, c'est
> qu'il ne faut pas syst?matiquement pourcent-encoder les caract?res
> r?serv?s. Ici, c'est juste parce qu'on veut les utiliser en dehors de
> leur r?le de (sous-)d?limiteurs. Donc faire des changements
> automatiques, OK, mais il faudra quand m?me qu'? un moment l'humain
> d?cide de ce qu'il faut pourcent-encoder ou pas.


Je vais donc me lire un peu la doc de xtring pour voir. De toutes
façons, mes liens vers wikipédia sont via une macro :
\newcommand{\wikipedia}[3]{\href{http://#1.wikipedia.org/wiki/#2}{#3}}

Je vais juste augmenter cette macro pour %coder les caractères
ennuieux. ....
.... et comme un bon petit gars vient même de poster un exemple de
subsitution ... je vais tester tout ça :)

Merci
Laurent
moky (14/02/2010, 00h26)
href n'a pas l'air d'aimer \StrSubstitute

+++++++++++++++++++++++++++++++++++++++++++

\documentclass[a4paper,12pt]{book}

\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{xstring}
\usepackage[ps2pdf]{hyperref}

\begin{document}

\href{\StrSubstitute{Norme}{N}{M}}{norme}
\StrSubstitute{étété}{é}{u}

\end{document}

++++++++++++++++++++++++++++

donne
! Argument of \KV@def has an extra }.
<inserted text>
\par
l.10 \href{\StrSubstitute{Norme}{N}{M}}
{norme}

J'enquête pour voir qui est ce \KV@def

Bonne nuit
Laurent
Manuel Pégourié-Gonnard (14/02/2010, 00h33)
Pétiard François scripsit :

> Chez moi (MiKTeX 2.7 à jour, aucun problème pour l'URL. Depuis Adobe
> Reader, le lien est correct.


Oui, enfin ce n'est pas parce que ça a l'air de marcher dans un cas que
l'URI était correcte. Un certain nombre de logiciels essayent d'être
arrangeant avec les syntaxes incorrectes. [1]

Dans un sens, ils n'ont pas tort. D'un autre côté, ça encourage les gens
à continuer à écrire les URI de façon incorrecte, parce que « ça marche
chez moi ».

La meilleure façon de mettre toutes les chances de son côté pour que ça
marche le plus souvent possible reste encore de respecter les standards.

[1] Firefox « maquille » les URI pour qu'ils aient l'air sympa dans la
barre d'adresse mais utilise une syntaxe correcte en sous-main. Par
exemple, quand la barre d'adresse dit

la requête qu'il a réellement faite (enregistrée avec Live HTTP headers)
commence par :
GET /wiki/Norme_d%27op%C3%A9rateur HTTP/1.1
D'ailleurs, je viens de remarquer que quand on copie-colle depuis la
barre d'adresse, le contenu du presse-papiers est correctement
pourcent-encodé :-)
Manuel Pégourié-Gonnard (14/02/2010, 00h40)
unbonpetit scripsit :

> Le 13/02/2010 21:55, Manuel Pégourié-Gonnard a écrit :
>> Bah, pour faire des changements automatiques dans une chaine de
>> caractères, on a xstring :-)

> Oui, il y a aussi ted, et sa délicieuse macro \Substitute non ? :P

Dans ce cas, oui. Mais xstring est quand même plus général, donc je
préfère recommender des solutions plus générales :-)
> Bah, ça ne pose pas trop de problème puisque le catcode de chaque
> caractère importe peu.
> En utf8, le caractère "é" est constitué de 2 octets C3 A9 et inputenc
> avec l'option utf8 déclare la caractère ^^c3 comme actif. Pour xstring,
> comme pour ted, cela n'a pas grande importance puisque les catcodes sont
> pris en compte, la substitution se fait normalement.

Oui, mais. D'une part, si le source n'est pas encodé en utf-8, il faut se
farcir la conversion. D'autre part, même si le source est encodé en
utf-8, il faut faire gaffe de pas développer en entier les chaines qu'on
va traiter, parce que sinon elles vont de retrouver encodées en T1 et on
aura tout perdu. Bref, peut-être qu'en pratique ça passe des fois (dans
le cas de Laurent, si son source est encodé en utf-8, je pense que ça
peut bien se passer), mais en général, prudence...

> Par contre, je me suis rendu compte d'un petit bug dans xstring il y a
> quelques jours : le comptage des caractères est faux en utf8 lorsque les
> arguments ne sont pas développés (ce qui est tout à fait logique
> d'ailleurs puisque xstring compte les octets). Le bug est que ce n'est
> pas signalé dans la doc.

Ouaip, le point c'est qu'avant développement la chaîne est encodée en
UTF-8, après elle est encodée en T1 (ou en l'encodage de fonte courant).

Y'a pas à dire, vivent les moteurs gérant Unicode nativement, hein.
Manuel Pégourié-Gonnard (14/02/2010, 00h47)
moky scripsit :

> href n'a pas l'air d'aimer \StrSubstitute

\StrSubstitute n'est pas fait pour être utilisé comme ça. (Sur l'air
bien connu de « Les macros ne sont pas des fonctions »...)

Il faut mieux essayer un truc comme

\StrSubstitute{Norme}{N}{M}[\result]
\href{\result}{...}
unbonpetit (14/02/2010, 00h52)
Le 13/02/2010 23:26, moky a écrit :
> href n'a pas l'air d'aimer \StrSubstitute


ben parce que \StrSubstitute ne vaut pas la chaine qu'elle affiche. il
ne faut pas confondre macro et résultat qu'elle affiche.

Je propose ce code, vite fait où seule la conversion de "é" en "%C3%A9"
est faite.

\documentclass[a4paper,12pt]{book}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{xstring}
\noexpandarg
\usepackage[ps2pdf]{hyperref}
\makeatletter
\newcommand\substurl[2]{%
\StrSubstitute{#1}{é}{\%C3\%A9}[\tmp@url]%
\expandafter\href\expandafter{\tmp@url}{#2}}
\makeatletter
\begin{document}
\substurl{http://fr.wikipedia.org/wiki/Norme_(mathématiques)}{norme}
\end{document}
Pétiard François (14/02/2010, 00h55)
Le 13/02/2010 23:33, Manuel Pégourié-Gonnard a écrit :
> Pétiard François scripsit :
> Oui, enfin ce n'est pas parce que ça a l'air de marcher dans un cas que
> l'URI était correcte. Un certain nombre de logiciels essayent d'être
> arrangeant avec les syntaxes incorrectes. [1]
> Dans un sens, ils n'ont pas tort. D'un autre côté, ça encourage les gens
> à continuer à écrire les URI de façon incorrecte, parce que « ça marche
> chez moi ».
> La meilleure façon de mettre toutes les chances de son côté pour que ça
> marche le plus souvent possible reste encore de respecter les standards.


Tout à fait d'accord mais cela n'explique pas pourquoi ça ne fait pas la
même chose chez moky et chez moi...

François
unbonpetit (14/02/2010, 00h57)
Le 13/02/2010 23:40, Manuel Pégourié-Gonnard a écrit :

Discussions similaires