Le comment

Vu que l’installation des binaires se fait forcément dans l’arborescence principale de TeX Live, toutes les explications qui suivent supposent que vous installez les fichiers d’initialisation dans TEXMFLOCAL, car je ne vois pas de raison d’utiliser plutôt TEXMFHOME. Pour connaître la valeur de TEXMFLOCAL, utilisez la commande suivante.

kpsewhich --var-value TEXMFLOCAL

Par ailleurs, je suppose que vous avez les privilèges suffisants pour effectuer toutes les opérations décrites. Il est conseillé d’installer TeX Live en tant que simple utilisateur (surtout si vous comptez la bidouiller beaucoup, comme c’est l’objet de ces billets), mais si vous ne l’avez pas fait, n’hésitez pas à utiliser sudo ou su sous Unix, ou « ouvrir une ligne de commande en tant qu’administrateur » sous Windows au besoin.

Dans TEXMFLOCAL/tex/generic/config, créez un fichier nommé luatexiniconfig.tex ayant le contenu suivant.

\begingroup
\catcode `\{=1
\catcode `\}=2
\expandafter\ifx\csname luatexversion\endcsname\relax
  \let\luatexversion\undefined
  \directlua{tex.enableprimitives('', tex.extraprimitives())}
\fi
\endgroup

Ensuite, trouvez l’arborescence TEXMFDIST (utilisez kpsewhich --var-value au besoin), et copiez de cette arborescence vers TEXMFLOCAL les fichiers suivants.

tex/plain/config/luatex.ini
tex/plain/config/pdfluatex.ini
tex/latex/latexconfig/lualatex.ini
tex/latex/latexconfig/pdflualatex.ini

Éditez ensuite la copie présente dans TEXMFLOCAL de chacun de ces fichiers, pour ajouter au tout début (juste après les commentaires initiaux) la ligne

\input luatexiniconfig

Il faut maintenant mettre à jour la base de données des fichiers de TeX. Vu que tous les fichiers créés sont dans TEXMFLOCAL, il suffit de se placer dans ce répertoire et de taper

mktexlsr .

Tout ceci est à effectuer une fois avant d’installer une version supérieure ou égale à 0.39.0 de LuaTeX, par la méthode donnée dans le billet précédent.

Le pourquoi du comment

Sans la manipulation décrite ci-dessus, vous aurez une erreur au moment de re-générer les formats (l’étape fmtutil-sys). En effet, les fichiers d’initialisation des formats supposent qu’un certain nombre de primitives fournies par e-TeX ou pdfTeX existent, ce qui est bien naturel vu qu’il sont destinés à un moteur précis.

Or, depuis la version 0.39.0, LuaTeX (en mode INI, c’est-à-dire sans format pré-chargé) démarre avec exactement les même primitives que TeX82, sauf \directlua en plus. Si on veut accéder aux nouvelles primitives, il faut explicitement demander leur activation avec la fonction Lua tex.enableprimitives(). Ceci présente deux avantages :

• si dans un futur distant on veut réellement remplacer pdfTeX par LuaTeX, on peut (en utilisant le deuxième argument de tex.enableprimitives()) n’activer que les primitives pdfTeX dans ce mode-là.
• en activant les primitives, on peut si on veut (premier argument de tex.enableprimitives()) leur ajouter un préfixe (par exemple \LuaTeXprimitive au lieu de \primitive) pour éviter les conflits de noms avec des macros déjà utilisés dans différents paquets.

Pour plus de détails, voir les parties 2.1 et 4.1.14 d’un version récente du manuel LuaTeX.

Avertissements préliminaires

• Pour les versions de LuaTeX supérieures ou égales à 0.39.0, une étape supplémentaire est requise (à effectuer une seule fois), décrite dans le billet suivant.
• Tout ceci concerne une version « nature » de TeX Live. Si vous utilisez les paquets TeX Live de Debian, des paquets pour LuaTeX existent (dans sid et testing) et fournissent des version relativement récentes de LuaTeX.

Le how-to et certaines explications

Pour une fois, c’est un peu plus qu’un « comment j’ai fait », puisqu’au moins une autre personne a testé. La première chose à faire est bien sûr de récupérer le binaire d’une version récente de LuaTeX. On en trouve pour Linux et Windows sur la page Gforge de LuaTeX, et pour d’autres plateformes, mais avec potentiellement un peu plus de délai, sur la page téléchagement de LuaTeX. (Attention, sur la page Gforge, l’ordre est trompeur et les version les plus récentes sont en bas de la page).

Il faut maintenant intégrer ce binaire à votre TeX Live. Si vous avez accepté les réglages par défaut lors de l’installation, vos binaires « normaux » de TeX Live sont sous

/usr/local/texlive/2008/bin/<arch>-linux
C:\Program Files\texlive\2008\bin\win32

selon que vous êtes sous Linux ou Windows. Nous allons placer les nouveaux binaires dans un répertoire parallèle en remplaçant la dernière composante du chemin ci-dessus par i386-linux-latest ou win32-latest par exemple. (Adaptez au besoin.)

Cet emplacement n’est pas choisi au hasard : il y a dans TeX Live tout un tas de fichiers que TeX et ses variantes on besoin de localiser. Comme il est a priori possible d’installer TeX Live n’importe où sur le disque, il faut que les programmes aient un moyen de s’y retrouver. Le moyen retenu (sous TeX Live) est simple : le programme regarde où il se trouve sur le disque, et en déduit où se trouvent les autres fichiers. Il faut donc bien prendre garde de ne pas le placer n’importe où.

Il faut ensuite ajouter ce répertoire à son PATH, avant le répertoire par défaut de TeX Live. Je reviendrai là-dessus dans la partie spécifique au système d’exploitation.

Il faut ensuite re-générer les formats. Si cette dernière phrase vous paraît incongrue, un mot d’explication. Quand on utilise la commande latex, il y a en fait (essentiellement) deux fichiers en jeu : le programme pdftex (ou pdftex.exe) et le « format » latex.fmt. Ce dernier comprend des définitions (comme par exemple celle de \documentclass) sous une forme « pré-compilée » et très rapide à charger. Les fichiers .fmt utilisent un format binaire qui ne peut pas être partagé entre différentes versions du programme sous-jacent. Je répète donc : il faut ensuite re-générer les formats (en espérant que ça passe mieux cette fois).

C’est très simple, en ligne de commande on fait

fmtutil-sys --byfmt luatex
fmtutil-sys --byfmt pdfluatex
fmtutil-sys --byfmt lualatex
fmtutil-sys --byfmt pdflualatex

(Muni des privilèges suffisants pour écrire dans les répertoire de TeX Live. Pour un utilisateur d’Unix, ça peut impliquer l’usage de sudo où su.)

Bien, on a fait la moitié du travail pour pouvoir lancer une commande comme pdflualatex : créer un fichier pdflualatex.fmt viable. L’autre moitié est de faire comprendre à notre système d’exploitation que quand on lance la commande pdflualatex, c’est en fait notre nouveau programme luatex (ou luatex.exe) qu’il faut utiliser. Cette partie dépend du système d’exploitation.

Sous Linux, Mac OS, ou autre variante d’Unix

C’est très simple, il suffit, dans notre répertoire ii386-linux-latest (ou autre) nouvellement créé, et qui ne contient que luatex pour le moment, de créer des liens symboliques vers celui-ci.

for l in pdfluatex lualatex pdflualatex texlua texluac; do
ln -s luatex $l; done

Hop, c’est tout. Vous avez remarqué texlua et texluac ? C’est pour utiliser LuaTeX comme un simple interpréteur Lua (resp. un compilateur de Lua en bytecode). Utile si vous voulez pratiquer tranquillement Lua, ou écrire des scripts portable à utiliser dans le contexte de TeX (par exemple, texdoc est un script interprété par texlua depuis TeX Live 2008, ce qui lui permet de fonctionner aussi sur windows, contrairement à la précédente implémentation sous forme de script shell).

Maintenant, ça vous dérange peut-être d’avoir dans votre PATH deux répertoires rien que pour TeX Live. Moi ça me dérange en tout cas. Pas de problème, on fait (par exemple)

for f in ../x86_64-linux/*; do ln -s $f; done

pour créer des liens symboliques de notre nouveau répertoire vers les fichiers de l’ancien, et on peut ainsi ne garder que le nouveau dans le PATH.

Attention, si lors de l’installation vous aviez choisi l’option « ajouter des liens symboliques dans les répertoires standard », oubliez tout ce que j’ai dit précédemment sur le PATH. Placez simplement des liens symboliques vers .../bin/<arch>-latest en amont de /usr/local/bin dans votre PATH. En principe, ~/bin fait très bien l’affaire pour ça (enfin, peut-être pas sous OS X). Il vous faut bien sûr créer des liens symboliques avec tous les noms voulus. Par contre, il faut continuer à placer le binaire à l’endroit indiqué (et pas par exemple directement dans votre ~/bin, car c’est ce qui compte pour qu’il trouve ensuite les fichiers de TeX Live.

Sous windows

Ici, on n’a pas de liens symboliques (quoi que… sous NTFS je crois que si, mais je ne sais pas faire). Qu’à cela ne tienne, on va faire des copies. On crée donc dans notre nouveau répertoire win32-latest des copies de luatex.exe nommées pdfluatex.exe, lualatex.exe, pdflualatex.exe, texlua.exe et texluac.exe (voir ci-dessus pour l’utilité de ces deux derniers).

Si vous souhaitez n’avoir qu’un seule répertoire TeX Live dans votre PATH, le plus simple est de commencer par recopier le précédent sous le nouveau nom, et ensuite seulement de remplacer les fichiers dans la copie.

Dernières remarques

LuaTeX est vraiment en bêta. Ne l’utilisez qu’à des fins de test ou de développement. Par ailleurs, une bonne raison pour en installer une version plus récente que 0.25.4 est que cette dernière souffre d’un problème important. Elle ne peut pas charger les fontes qui sont utilisée par défaut par LaTeX avec usepackage[T1]{fontenc}. (Pour l’anecdote, ce n’est pas à proprement parler un bug de LuaTeX : c’est une anomalie dans les fichiers .tfm de ces fontes, non détectée par les variantes de TeX usuel. Dans un sens, LuaTeX avait « raison » de ne pas les accepter, mais les version récentes préfèrent avoir tort et fonctionner…)

Au passage, si vous voulez tester pdflualatex, attention, suite à des progrès importants réalisé par LuaTeX (par rapport à pdfTeX) en matière d’encodages d’entrées et de fontes, inputenc et fontenc ne sont pas actuellement compatibles avec LuaTeX. Il suffit de supprimer inputenc et d’encoder son fichier en utf-8 pour régler le premier point. Pour le deuxième, on peut quand même utiliser fontenc avec T1 en attendant, mais on aura des problèmes sur certains caractères (tout ceux, heureusement rares, qui ne sont pas à la même position dans latin1 et dans T1).

Petite parenthèse pour qui se demande d’où vient cette idée de désinstaller la libc : ça fait partie du folklore de fr.misc.bavardages.linux, un groupe iouzenette ma foi fort sympathique (voir ses conseils d’utilisation et notamment les liens de la section 4 (alerte procrastination) mais aussi le fortune-file (alerte bis)). La vérification du rapport avec la désinstallation de libc est laissée au lecteur.

Bref, souhaitant retrouver les termes exacts de la phase de sécurité en question (pour vérifier si elle suppose bien que l’utilisateur est de sexe masculin, ce qui ne serait pas forcément sexiste : une fille est bien trop responsable pour désinstaller sa libc…), me voilà parti à bidouiller les trois commandes sus-citées pour leur faire cracher le message. Quand, sûr de moi car n’ayant pas précisé --force-remove-essential je tape (en root sur mon laptop, qui est ma machine principale) :

dpkg --force-depends --remove libc6

à ma grande surprise ça « marche » (si l’on peut dire), sauf les scripts post-désinstallation, qui échouent, comme on devrait s’en douter. J’ai alors le plaisir d’entretenir avec mon shell préféré un dialogue aussi réjouissant que

% /bin/ls
zsh: command not found: /bin/ls
% ??!

le temps de réaliser ce que je viens de faire.

Arrivés à ce stade de votre lecture, vous êtes sans doute mort de rire. Même si j’en suis heureux, ce n’est pas la finalité principale de ce blog, qui avait plutôt pour but de partager des astuces techniques en LaTeX, ou en geekeries linuxiennes. La partie technique arrive : je vais vous expliquer comment il est facile de réinstaller sa libc. (Je lis la déception dans votre regard : rassurez-vous, ça m’a quand même pris un bon moment avant de comprendre que c’était facile.)

On s’arme bien sûr d’un bon Live CD, car le système n’est pas bootable (on pourrait en fait, avec l’option init=/sbin/sash mais je ne pense pas que ça avance à grand chose). Mon choix se porte que grml pour sa parenté avec Debian, son état d’esprit et sa finition que j’apprécie (je pratique aussi sysresccd à l’occasion). Je vous épargne les détails, mais je finis par découvrir ici l’option --root de dpkg qui semble résoudre mon problème.

Après avoir monté toutes les partition adéquates de mon disque dur (petit instant de doute en voyant qu’il n’y a rien dans /dev/mapper, mais la FAQ grml me conseille Start lvm et a bien raison), j’essaie et là c’est le drame : la version de dpkg du CD grml gravé il y a un an est trop vieille pour toucher à ma Lenny (la prochaine version de Debian) à jour. Yaka en graver une plus récente. Ou pas, parce que graver un CD en tournant sur Live CD, euh… Bref, vivent le boot sur clé USB, et les tutoriels qui marchent du premier coup (c’est aussi pour ça que j’aime grml).

Deuxième essai. Ok, dpkg fait de son mieux mais c’est le script d’installation qui marche pas : command not found: /bin/ls, ça vous dit quelque chose ? Visiblement --root en fait un peu trop. On passe donc au 6.3.7 de la page qui en parlait : faire soi-même le boulot de dpkg. Enfin, juste une partie de son boulot, lui il est plus subtil. Mais ça suffit, ouf.

Donc résumé en deux mots, le how-to (même si le mieux c’est de pas commencer, hein) :

1. Démarrer sur Live CD, récent ou pas.
2. Télécharger le .deb de la libc sur http://packages.debian.org.
3. Monter ses partoches ou volumes LVM du système cassé quelque part.
4. ar x lic6-*.deb où vous voulez, puis tar xf data.tar.gz à la racine du point de montage.
5. Redémarrage sur le système anciennement cassé, et dpkg -i libc6-*.deb quand même, juste pour que les petits papiers de dpkg soient à jour.

Morale de l’histoire : ne plus jamais tester des trucs idiots ailleurs que sur une machine de test (fut-ce une machine virtuelle ou un simple chroot).

Télécharger les sources du noyau sur kernel.org. Pour une version stable (ex. aujourd’hui : 2.6.27.7), utiliser le lien F (full source) sur la ligne. Dans tous les autres cas, il faut télécharger le patch (lien du numéro de version, ex. 2.6.28-rc6) et la base à laquelle l’appliquer, donnée par le lien B sur la même ligne. Dans les exemples qui suivent, je suppose que les trucs sont enregistrés sous ~/tmp.

Ajouter son utilisateur au groupe src si ce n’est pas déjà fait. Par exemple :

# adduser mpg src

Puis se relogguer avec cet utilisateur pour que la modification soit effective. Le vérifier en tapant id ou groups.

En utilisateur, aller dans /usr/src, y détruire le lien symbolique linux. Décompresser l’archive des sources. S’il s’agit d’une version à patcher, procéder comme dans l’exemple suivant.

% tar xjf ~/tmp/linux-2.6.27.tar.bz
% bunzip2 ~/tmp/patch-2.6.28-rc6.bz2
% cp -r linux-2.6.27 linux-2.6.28-rc6
% cd linux-2.6.28-rc6
% patch -p1 <~/tmp/patch-2.6.28-rc6

Une fois obtenue une belle arborescence des sources dûment patchée au besoin, rétablir le lien symbolique linux vers sa racine.

Il faut maintenant configurer le nouveau noyau. Pour partir de la configuration de l’ancien, faire par exemple

% cp /boot/config-2.6.27.5 /usr/src/linux/.config

Aller alors dans /usr/src/linux et y lancer alors make menuconfig. (Il faut sans doute installer un ou deux paquets pour ça, dont libncurses-devet peut-être d’autres.) Selon les besoins, sélectionner les drivers voulus (chez moi, c’est ath9k qui m’a motivé à installer une version récente du noyau, et que je vais activer la première fois dans Device driver -> Networks device support -> Wireless Lan -> Atheros 802.11n wireless cards support).

Il est alors temps de construire le noyau. Pour cela, il faut avoir installé les paquets nécessaires : kernel-package, fakeroot, build-essential et initramfs-tools en font partie, et je crois qu’ils suffisent. Exécuter alors

% fakeroot make-kpkg clean
% fakeroot make-kpkg --initrd kernel_image

(Si on envisage de faire plusieurs noyaux personnalisés successifs à partir d’une même version upstream, on a intérêt à utiliser l’option --append-to-version=.20081107 (ou tout autre numéro) pour les distinguer et ne pas mélanger leurs modules.) C’est en tout cas le moment de s’en jeter une petite de son breuvage favori, ou de faire autre chose d’intéressant sur sa machine si on elle a un double cœur.

Maintenant, la seule étape nécessitant les droits de root : l’installation du paquet créé.

# dpkg -i /usr/src/linux-image-2.6.27.5_2.6.27.5-10.00.Custom_amd64.deb

Voilà, il ne reste plus qu’à rebooter sur le nouveau noyau, et éventuellement recompiler les modules externes.

Premièrement, pourquoi avoir installé une TeX Live nature plutôt que les paquets TeX Live de Debian ? Plusieurs raisons :

• L’équipe TeX de Debian n’a pas encore eu le temps d’empaqueter la version 2008, et j’étais impatient de jouer avec les nouveautés de cette version.
• La version 2008 de TeX Live possède son propre gestionnaire de paquet, et je ne sais pas comment il sera utilisable dans la version Debian de la chose : dans le doute, installer la version nature me paraît raisonnable.
• Une raison personnelle : étant développeur TeX Live, il me paraît naturel d’utiliser la version nature pour mieux la connaître.

Maintenant, le problème qui se pose avec les installations locales, c’est que le gestionnaire de paquets de la distribution n’en est a priori pas au courant, et qu’il faudrait qu’il en tienne compte dans ses calculs de dépendance pour ne pas installer une deuxième version de ce qu’on a déjà installé. (On peut bien sûr choisir d’installer côte à côte une TeX Live de Debian et une nature, mais il faut être sûr de bien contrôler son environnement si on veut éviter les problèmes.)

La solution proposée par Debian tient en un mot : equivs. Ce petit paquet contient ce qu’il faut pour créer facilement des paquets Debian ne contenant rien à part des informations de dépendances pour APT. Voyons comment s’en servir pour créer un paquet texlive-local qui informera APT qu’on a déjà une TeX Live, merci. On commence par installer equivs et se mettre dans un répertoire temporaire de travail (je suppose que ~/tmp existe et que c’est là-dessous qu’on aime travailler). On commence alors par utiliser equivs-control.

# aptitude install equivs
$ mkdir ~/tmp/tl-loc
$ cd !$
$ equivs-control texlive-local

La dernière ligne a pour effet de préparer un squelette fichier de contrôle pour notre futur paquet. C’est là qu’on va indiquer à quels paquets Debian réels correspond notre installation locale, grâce à la ligne Provides:. On édite aussi quelques autres informations au passage (champs Package, Version, Maintainner et Description) ; le fichier obtenu est le suivant.

Section: misc
Priority: optional
Standards-Version: 3.6.2

Package: texlive-local
Version: 2008-1
Maintainer: MPG <mpg@roth.elzevir.fr>
Provides: cm-super, cm-super-minimal, context, latex-beamer,
 latex-cjk-all, latex-cjk-chinese, latex-cjk-chinese-arphic-bkai00mp,
 latex-cjk-chinese-arphic-bsmi00lp, latex-cjk-chinese-arphic-gbsn00lp,
 latex-cjk-chinese-arphic-gkai00mp, latex-cjk-common, latex-cjk-japanese,
 latex-cjk-japanese-wadalab, latex-cjk-korean, latex-cjk-thai,
 latex-sanskrit, latex-xcolor, lmodern, luatex, musixtex, pgf, prosper,
 tex4ht, tex4ht-common, texinfo, texlive-base, texlive-base-bin,
 texlive-base-bin-doc, texlive-bibtex-extra, texlive-common,
 texlive-doc-base, texlive-doc-bg, texlive-doc-cs+sk, texlive-doc-de,
 texlive-doc-el, texlive-doc-en, texlive-doc-es, texlive-doc-fi,
 texlive-doc-fr, texlive-doc-it, texlive-doc-ja, texlive-doc-ko,
 texlive-doc-mn, texlive-doc-nl, texlive-doc-pl, texlive-doc-pt,
 texlive-doc-ru, texlive-doc-th, texlive-doc-tr, texlive-doc-uk,
 texlive-doc-vi, texlive-doc-zh, texlive-extra-utils, texlive-font-utils,
 texlive-fonts-extra, texlive-fonts-extra-doc, texlive-fonts-recommended,
 texlive-fonts-recommended-doc, texlive-formats-extra, texlive-full,
 texlive-games, texlive-generic-extra, texlive-generic-recommended,
 texlive-humanities, texlive-humanities-doc, texlive-lang-african,
 texlive-lang-arab, texlive-lang-armenian, texlive-lang-croatian,
 texlive-lang-cyrillic, texlive-lang-czechslovak, texlive-lang-danish,
 texlive-lang-dutch, texlive-lang-finnish, texlive-lang-french,
 texlive-lang-german, texlive-lang-greek, texlive-lang-hebrew,
 texlive-lang-hungarian, texlive-lang-indic, texlive-lang-italian,
 texlive-lang-latin, texlive-lang-manju, texlive-lang-mongolian,
 texlive-lang-norwegian, texlive-lang-other, texlive-lang-polish,
 texlive-lang-portuguese, texlive-lang-spanish, texlive-lang-swedish,
 texlive-lang-tibetan, texlive-lang-ukenglish, texlive-lang-vietnamese,
 texlive-latex-base, texlive-latex-base-doc, texlive-latex-extra,
 texlive-latex-extra-doc, texlive-latex-recommended,
 texlive-latex-recommended-doc, texlive-latex3, texlive-math-extra,
 texlive-metapost, texlive-metapost-doc, texlive-music, texlive-omega,
 texlive-pictures, texlive-pictures-doc, texlive-plain-extra,
 texlive-pstricks, texlive-pstricks-doc, texlive-publishers,
 texlive-publishers-doc, texlive-science, texlive-science-doc,
 texlive-xetex, tipa, 
Architecture: all
Description: Installation locale de TeX Live.
 Installation locale d'une TeX Live nature complete.

C’est presque fini. Maintenant que notre fichier de contrôle est prêt, on peut créer le paquet et l’installer :

$ equivs-build texlive-local
# dpkg -i texlive-local_2008-1_all.deb

(Seule le dernière étape se fait en root ou avec sudo : dans tous mes exemples, $ ou % représent un shell utilisateur, et # un shell root.) On peut aussi si on le souhaite sauvegarder le paquet Debian créé : personnellement, je garde une copie de tous mes paquets créés localement dans /usr/local/debs.

Enfin, j’ai quand même installé lmodern, et tex-common dont il dépend, depuis les dépôts Debian : le but est simplement d’enregistrer ces polices au niveau de defoma et de X11. (Si j’étais un peu moins pataud en fontes, je le ferais à la main.) Le paquet tex-common ne risque pas d’interférer avec mon installation : il contient essentiellement des scripts de gestion propres à Debian.

Je peux ainsi installer (depuis les dépôts Debian) des éditeurs comme Kile ou TeXmaker, voire le module aucTeX pour Emacs (que j’essaierai un jour lointain, quand j’aurai beaucoup de temps) sans qu’Aptitude n’essaie de m’installer le moitié d’une TeX Live Debian en plus comme dépendances.

Pour cela, on peut bien sûr utiliser XeLaTeX et l’excellent module fontspec, ou convertir les polices au format PostScript Type 1, et générer les fichiers (tfm, vf, fd,…) dont ont besoin (pdf)TeX et LaTeX pour les utiliser. Je me propose ici de vous exposer comment j’ai mis en oeuvre cette deuxième option, qui, on le verra dans un prochain billet, est également utile avec XeLaTeX, en attendant un meilleur support de l’OpenType mathématique, et une police mathématique OpenType accordée à Minion (peut-être Minion Math ?).

Tout le travail pénible et déjà été fait pour nous : on trouve sur le CTAN les fichiers de support nécessaires, et un script pour la conversion des polices elles-même, dans le paquet minionpro. Les fichiers dont vous avez besoin dépendent de votre version de Minion. Parcourez le README pour savoir comment adapter les explications ci-dessous.

Avant toute chose, vérifiez de vous avez installé lcdf-typetools, la collection d’outils utilisée par les script de conversion. Puis créez un répertoire temporaire, récupérez et décompressez les fichiers nécessaires.

% mkdir tmp/minionpro
% cd !$
% wget http://mirror.ctan.org/fonts/minionpro/{README,enc-1.000.zip,metrics-base.zip,metrics-full.zip,metrics-opticals.zip,scripts.zip}
% for i in *.zip; do unzip $i; done

Il s’agit alors de copier dans le répertoire otf créé les fichiers de Minion au format OpenType. Vous êtes alors prêts à lancer la conversion et à placer le résultat dans un endroit approprié.

%  cp ~/.fonts/Adobe/Western\ Fonts/Minion\ Pro\ Opticals/* otf
% ./convert.sh
% mkdir -p fonts/type1/adobe
% mv pfb !$/MinionPro

La dernière étape consiste à intégrer les fichiers au reste de votre distribution TeX. Si vous n’êtes pas administrateur sur la machine en question, ou ne souhaitez installer les fontes que pour vous, remplacez le répertoire TEXMF de base par votre TEXMFHOME, et la commande updmap-sys par updmap.

% cp -r doc fonts tex /usr/local/texlive/texmf-local
% mktexlsr !$
% updmap-sys --enable Map MinionPro.map

Voilà, c’est fini (c’était facile, hein ?), il ne vous reste plus qu’à tester. Chez moi, ça marche avec pdflatex, latex+dvips+pstopdf, et latex+xdvipdfmx. Il faut aussi avoir le paquet MnSymbol pour les maths, j’ai supposé qu’il était déjà installé.

Un dernier mot d’avertissement : comme tous les how-to ici, c’est plutôt un « comment j’ai fait chez moi pour que ça marche chez moi ». En particulier, je fais les suppositions suivantes :

• on est sous Linux, le shell est zsh ou un truc voisin (bash doit convenir) ;
• la distribution TeX est une TeX Live « nature », les chemins changent sinon ;
• l’utilisateur qui fait la dernière étape a les droits en écriture sur l’arborescence utilisée. Chez moi, j’ai donné à l’utilisateur mpg (moi) les droits sur /usr/local/texlive : ça m’évite de passer root ou d’utiliser sudo chaque fois que je veux bidouiller ma TeX Live.

Amusez-vous bien avec cette jolie fonte, et faites de beaux documents !

Le première point qui m’a frappé en essayant Wordpress, c’est que jamais je ne pourrai m’habituer au pseudo-éditeur de texte en ligne qu’il propose par défaut pour rédiger les billets. J’ai pensé un moment copier-coller depuis vim, mais c’est pénible, et de plus WP fait par défaut subir à mon texte un traitement bizarre qui remplace les fins de lignes par des balises <br /> : pénible, quand on édite sur 80 colonnes. (Je reviendrai sur ces traitements dans le prochain billet.)

Pour l’intégration de vim et de WP, j’ai gougueuler un peu à tout hasard, et après avoir trouvé une extension Firefox qui permettrait d’éditer n’importe quel champ de texte d’une page ouèbe dans vim (ou emacs pour ceux qui y tiennent), ce qui a l’air prometteur mais ne tient malheureusement pas ses promesse après 5 minutes d’essai/combat, j’ai plutôt rapidement trouvé le Nirvana, sous la forme de vimpress, un plugin vim.

L’idée est très simple : WP propose plusieurs API utilisant le protocole XMLRPC. En gros, ce protocole (pour ce que j’en comprends) est très générique et permet de représenter en XML quelques types de données naturels dans les langages courants. À partir de là, on peut définir facilement des type de données « billet de blog », « liste de billets », etc. et les échangers en XML. Pour l’utilisateur-programmeur, c’est magique : modulo l’existence d’une bibliothèque XMLRPC dans son langage favori, on a un type de données dans ce langage qui réprésente un billet de blog, et une fonction simple pour le récupérer ou l’envoyer.

vimpress, c’est l’implémentation de tout ça sous la forme d’un plugin vim en python, utilisant l’API MovableType, et sous GPL. (Il faut donc avoir une version de vim compilée avec le support python, j’en reparlerai sans doute un de ces jours.) C’est bel et bon, mais ça un défaut : ça ne gère pas la fonctionalité qui permet d’affiicher seulement les première lignes d’un billets comme je le fais sur le page d’accueil : quand on tente de récupérer un tel billet pour l’éditer, on reçoit seulement ses prmières lignes, justement.

Heureusement, après avoir un peu fouillé, on finit par comprendre des choses sur l’API metaWeblog (à mon avis mal documentée : là où j’ai le mieux compris, c’est dans le source PHP de WP), à savoir que les premières lignes d’un message et sa suite sont deux éléments metaWeblog distincts, à savoir description et mt_text_more. Heureusement aussi que python est facile à lire et à éditer même si on ne le connait pas : quelques temps après, j’avais patché avec succès ma version locale de vimpress.

Bref, c’est maintenant un plaisir pour moi de pouvoir éditer mes billets sous vim, confortablement. Pour augmenter ce confort, je rédige en markdown (et plus précisément en markdown extra), mais je vous ai déjà assez ennuyé pour aujourd’hui : ce sera l’objet du prochain billet.

Tout d’abord, j’ai lancé un petit aptitude install wordpress et commencé à regarder ce qui se trouvait dans /u/s/d/wordpress. Il y avait un README et des exemples de configuration Apache et de script pour aider à créer une base mysql et permettre à wordpress d’y accéder.

J’ai d’abord été surpris de constater que le script échouait, tout simplement parce que je n’avais pas de serveur mysql qui tournait. Enquête faite, mysql-server est simplement suggéré par wordpress et pas installé d’office, car on pourrait en principe utiliser une bdd distante. Soit, j’installe mysql-server-5.0 et tout marche.

Mais après quelques minutes à configurer la chose, je change d’avis et me met à penser que c’est mieux d’installer wordpress à la main dans mon home : je trouve lourd d’avoir à être root pour installer des thèmes par exemple. Donc on efface tout et on recommence, sauf qu’avant de désinstaller on dit aptitude unmarkauto avec la liste des dépendances de wordpress histoire de les garder sous le coude.

Bref, je suis donc parti du site http://fr.wordpress.org/, j’ai téléchargé l’archive et l’ai dézippée dans ~/www/weblog. J’ai alors suivi les instructions en bas de page et plus spécifiquement celles présentes ici pour la création et configuration de la bdd. Tout a bien marché.

Par contre, en testant, j’ai une mauvaise surprise, provenant des exemples de .htaccess préalablement recopiés : il semblerait que la directive ErrorLog, qui ne provoquait pas d’erreur à la relecture de la configuration, faisait par contre tout bonnement mourir le serveur (dans des souffrances atroces, j’imagine) quand on tentait d’accéder à la page. J’ai abandonné l’idée d’utiliser cette fonctionnalité pour le moment.

L’autre petit souci est survenu quand j’ai voulu configurer des jolis permaliens : d’une part il faut penser à mettre le code aimablement fournit par wordpress dans une directive <Directory> comme nous l’apprend le message d’erreur. D’autre part, c’est stupide mais il faut y penser : il faut activer mod_rewrite

Pour finir, deux mots sur la configuration d’Apache. Comme souvent chez Debian, c’est un peu sophistiqué mais assez bien fait : pour les sites comme pour les modules, il y a un répertoire *-available et un *-enabled et on active les trucs en faisant des liens symboliques du deuxième vers le premier. J’en profite d’ailleurs pour place dans le home de mon utilisateur les fichiers de configuration propres à chacun des serveurs virtuels, et lui donne le droit grâce à sudo de demander à Apache de relire ses fichiers de configuration.

Je trouve ça plus pratique que de lister les sites virtuels dans le fichier de conf principal d’Apache puis d’utiliser des .haccess. D’une part, au moment du reload on a les messages d’erreur si les directives ne sont pas correctes, d’autre part, ça fait toujours un fichier de moins à analyser chaque requête pour Apache.

Bref, mon ~/www/weblog.conf Kimarch® est le suivant :

<VirtualHost *:*>
    ServerName weblog.elzevir.fr
    DocumentRoot /home/mpg/www/weblog
    <Directory />
        Options FollowSymLinks
        AllowOverride All
    <IfModule mod_rewrite.c>
        RewriteEngine On
        RewriteBase /
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteCond %{REQUEST_FILENAME} !-d
        RewriteRule . /index.php [L]
    </IfModule>
    </Directory>
</VirtualHost>

Je crois n’avoir rien oublié, tout a l’air de marcher pour le moment.