Diagramme commutatif

Pourquoi les accolades autour de la couleur ? Cf. https://tex.stackexchange.com/questions/7058/coloring-arrows-in-xymatrix.

La suggestion était de supprimer les accolades.

\documentclass{article}
\usepackage{xcolor}
\usepackage[all]{xy}
\begin{document}

\[\xymatrixcolsep{2cm}\xymatrix{
    U \ar[r]^-{\psi} \ar @[blue][d]_f  & V\times W\ar[ld]^{p_1} \\
    V
  }\]
\end{document}

Je suis nul avec xy, mais quand je compile le code de Math Coss avec pdflatex, il y a bien une flèche bleue... Peut-être cela aiderait-il si tu attachais le fichier .log.

Je crains que ce fichier .log ne résulte pas de la compilation du document complet minimal donné par Math Coss. Il serait quand même bien utile pour pouvoir t'aider de savoir si ce document donne le résultat escompté sur ton système ! La distribution TeX utilisée a l'air assez ancienne et surtout, il y a ça :

Non-PDF special ignored!
Non-PDF special ignored!
Non-PDF special ignored!
Non-PDF special ignored!
Non-PDF special ignored!
Non-PDF special ignored!
Non-PDF special ignored!
Non-PDF special ignored!
Non-PDF special ignored!
Non-PDF special ignored!
Non-PDF special ignored!
Non-PDF special ignored!


Non-PDF special ignored!
Non-PDF special ignored!
Non-PDF special ignored!
Non-PDF special ignored!

Si l'option dvips est passée à \documentclass ou à xcolor, cela pourrait expliquer le problème. En général, il vaut mieux laisser faire la détection automatique du driver. Et s'il y a du PSTricks dans le document, utiliser la voie DVI puis PostScript, ou passer par pdfTricks si ce truc marche encore. Sinon, TikZ.

L'histoire du driver et des specials, version courte (ah non, raté...) : lorsque TeX a été conçu, Knuth n'a rien mis de spécifique dedans pour gérer la couleur, mais il a laissé la possibilité d'ajouter des fonctionnalités à TeX via des objets appelés whatsit (si, si, cf. le TeXbook) qui peuvent être placés dans les boîtes au même titre qu'une boîte caractère, un filet (\hrule ou \vrule), un \kern ou un glob of glue (\hskip, \vskip...). L'écriture dans les fichiers depuis TeX (\write) utilise également les whatsits (sauf avec \immediate) ; c'est d'ailleurs ce qui permet à la commande \label d'écrire les bons numéros de pages dans le fichier .aux, par exemple.

Bref, ce système de whatsits permet d'attacher un peu ce que l'on veut aux boîtes que TeX agence les unes par rapport aux autres (caractères, lignes de paragraphes, bloc d'empagement, page complète...). La primitive \special produit des whatsits et a traditionnellement été la méthode utilisée pour mettre de la couleur avec TeX, LaTeX, etc. (avec LuaTeX, il y a une nouvelle technique mais je ne crois pas qu'elle soit déjà utilisée par beaucoup de packages).

Cependant, TeX, dans sa version d'origine, sort du DVI, et pour autant que je sache, ce format ne spécifie rien qui soit relatif à la gestion des couleurs. Donc avec la méthode que j'ai appelée traditionnelle et qui est encore utilisée presque partout, lorsqu'un package veut faire de la couleur, il va directement ou indirectement sortir du code dans un \special{...}, code dont le langage dépend complètement du format de sortie final. Si le format final est PostScript et qu'on utilise dvips pour traduire le DVI en PostScript, le code à l'intérieur de \special{...} doit utiliser une syntaxe spécifique que dvips reconnaît ; ce dernier pourra alors traduire ça en instructions PostScript relatives à la couleur. Si le format de sortie est PDF et que l'on passe par dvipdfm, il faut que ça utilise une syntaxe reconnue par dvipdfm qui doit traduire le ... en « code PDF » de gestion de la couleur. Si le format de sortie est SVG et qu'on le produit avec dvisvgm, même chose : il faut une syntaxe reconnue par dvisvgm qui permette de mettre de la couleur dans un fichier SVG.

On comprend donc qu'il y a autant de manières d'écrire le contenu des \special{...} utilisés pour mettre la couleur qu'il y a de chemins possibles pour arriver au format final, et chacun a sa propre syntaxe, ses propres limitations (espaces colorimétriques supportés, précision, etc.). C'est ça que représente le driver : c'est le composant logiciel qui transforme le format interne en sortie du moteur TeX, correspondant grosso modo au DVI, en le format final (PDF, SVG, PostScript, etc.). Donc on a les drivers pdftex (interne au programme pdfTeX), dvips, dvipdfm, dvisvgm, etc.

Il fut un temps où, je pense, il fallait spécifier manuellement le driver dans le document TeX. C'est logique : quand on compile un fichier vers du DVI, comment les packages produisant de la couleur peuvent-ils savoir si on va utiliser dvips, dvipdfm, dvipdfmx ou dvisvgm derrière ? Ils ont pourtant besoin de cette information pour savoir quelle syntaxe utiliser dans les \special ! En fait, quand on compile avec pdfTeX en mode PDF, le driver par défaut est pdftex. Quand on compile en mode DVI, c'est par défaut dvips. XeTeX, qui peut produire un format DVI un peu spécial, doit mettre son driver à lui, je pense. Bref, le programme TeX invoqué (pdfTeX, XeTeX, LuaTeX) utilise un driver par défaut plausible selon la façon dont il est utilisé (mode DVI ou PDF, etc.). Cela marche bien en général. Ce n'est que lorsque ce programme ne peut pas deviner quelle va être la suite qu'il faut préciser le driver. Je pense que c'est le cas lorsqu'on utilise dvipdfm ou dvisvgm, mais je n'ai pas l'habitude de ça.

Je dois abréger. Y a-t-il encore un problème avec ton « vrai document » ? Au vu de ton log, je ne suis pas sûr que cette histoire de driver soit la bonne piste, finalement (il y a des lignes qui ont l'air de dire que le driver pdftex a été autodétecté). Mais tu dois maintenant avoir un document avec lequel ça marche, et peut-être un avec lequel ça ne marche pas. Tu peux donc utiliser la méthode de dichotomie pour localiser le problème.