# [Xy-pic] Really weird behavior

Michael Barr barr at math.mcgill.ca
Fri Dec 13 14:01:52 CET 2013

It's all very well to say I should use the xy color option, but despite
your suggestion (which totally failed to work) to put [red] before the
\ar, I have still not found a way to use the xy color option to work in
$$\xy \ar@{->}^{f}(20,0) \endxy$$

Michael

On Fri, 13 Dec 2013, Ross Moore wrote:

> Hi Daniel, Michael, and others
>
> On 11/12/2013, at 6:08 AM, Daniel Müllner wrote:
>
>> Hi Michael,
>>
>> here is an even more minimalistic example that shows what's going on:
>>
>> \documentclass{article}
>> \pdfoutput1
>> \usepackage{color}
>> \usepackage{xy}
>>
>> \begin{document}
>> \xy
>> %\relax
>> {\color{red}Test}
>> \endxy
>> Test
>> \end{document}
>>
>> With the \relax, Xy-pic treats the curly brackets as a <decor>ation
>> (ibid., Figure 4). The curly brackets are passed through all levels of
>> Xy-pic parsing; hence the \color{red} has local scope.
>
> That is the effect, but not necessarily the clearest way to explain it
> — depending upon how well-versed you are with Xy-pic concepts and jargon.
>
> The next paragraph expands this.
>
> The \relax has ended the Xy-pic parsing, which cannot be switched back
> on again without some explicit Xy-pic macro, such as  \POS or \drop etc.
> Thus the {\color{red}Test} just generates some TeX content that sits inside
> the overall box for this particular instance of an Xy-pic diagram.
> There is no easy way to move to its top/bottom/left/right extents,
> or use it as the source/target of lines and arrows.
>
> OK, so this is what is meant by a <decor>ation, rather than an <object>.
>
>>
>> Without the \relax, Xy-pic treats the curly brackets as a Xy-pic group
>> and interprets the content like a nested Xy-pic environment (Xy-pic
>> reference manual, Figure 1, line 22).
>
> Yes.
> The '{' does not end the parsing, but rather results in an \hbox{
> building up an <object>. Within that \hbox  the parser restarts,
> (for Daniel's  "nested Xy-pic environment" )
> but finishes again upon encountering  \color , which is not an
> Xy-pic macro. The closing '}' closes the \hbox{...} construction,
> to complete the capture of the content for the <object>, but this is
> not the end of the TeX group required to trigger the result of
> the \aftergroup  in the expansion of \color .
>
> Thus whatever is required to change the colour back, within
> the PDF output, is not going to be wrapped up inside that \hbox ;
> hence color can bleed out of scope.
>
>> The curly brackets are stripped
>> and are lost as a TeX group;
>
> This is rather similar to doing:
>
>  \def\myredtext{\color{red}Test}
>  Here is my \myredtext.
>
> So that the {...} are delimiting an argument, rather than
> enclosing the scope of a macro definition.
>
>> therefore the \color{red} has global scope.
>
> Well, not necessarily completely global, just a wider scope
> than what you might think.
> In this simple example it *is* global.
>
> Note that the .log file gets a message:
>
>>>> pdfTeX warning: /usr/local/texlive/2012/bin/x86_64-darwin/pdflatex: pop empty c
>>>> olor page stack 0
>
> which indicates that something is definitely not fully synchronised.
> It is as if the stack is being popped before the actual push has happened.
>
>
> Due to these kinds of problems, which are rather subtle,
> you really should stick to using Xy-pic's way of handling color
> as a property (or style) of the <object>.
>
> Mixing LaTeX colour commands within Xy-pic diagrams is not recommended,
> unless you are fully aware of how LaTeX does it, and can handle
> the complicated nested groupings properly.
>
>
> The example from below should work fine as:
>
>>>> \documentclass{article}
>>>> \usepackage{color}
>>>> \usepackage[pdftex,color,arrow,matrix]{xy}
>>>> \begin{document}
>>>>
>>>> $$\xy >>>> \ar@[red]@{->}^[green]{f}(20,0) >>>> \endxy$$
>>>> Test
>>>>
>>>> \end{document}
>
>
> Note however the *requirement* to have  \usepackage{color}
> in order to have LaTeX's standard color names recognised.
> (red, green, blue, cyan, magenta, yellow, black, white)
>
> This is a dependency that has somehow escaped our attention.
>
> I now think this is more a deficiency in the documentation
> than a problem with Xy-pic's coding for colour support.
>
>
> The crucial point is that LaTeX's  \definecolor  command
> creates a macroname  \color@<name>
>       (via coding \csname color@#2\endcsname ).
>
> Now Xy-pic, when testing whether a  [...]  style specifier
> is defined, includes a test for such a macro name when the
> color option has been loaded.
>
> In the case of Daniel's pdftex.sty  and related coding,
> this is done through  \xP at checkcolor ; viz.
>
>>>> \next@ ->\xP at checkcolor {TealBlue}
>>>>
>>>> \xP at checkcolor #1->\@ifundefined {\string \color@ \detokenize {#1}}{\OBJECT at sha
>>>> pei [#1]}{\xP at append \toks@ {\noexpand \xP at color {{\detokenize {#1}}}}\xyFN@ \O
>>>> BJECT@ }
>>>> #1<-TealBlue
>
>
> Thus it is not necessary for Xy-pic to have coding that
> specifically supports those colour names.
> Indeed any colour defined by any other LaTeX package should
> automatically become available as a named colour for use within
> an Xy-pic diagram.
> This could be spelt out more clearly in the documentation.
>
> That snippet of macro expansion tracing also shows that
> a colour name will override a style defined with that same name.
> Thus
>
>   \ar@[thick]@{->}^[green]{f}(20,0)
>
> will not give a thicker line if there is a colour named 'thick'.
>
>
>>
>> Regards,
>>
>> Daniel
>>
>>
>> On 12/10/2013 05:51 PM, Michael Barr wrote:
>>> If you compile the following file:
>>>
>>> \documentclass{article}
>>> \pdfoutput1
>>> \usepackage{color}
>>> \def\red{\color{red}}
>>> \def\green{\color{green}}
>>> \usepackage[arrow]{xy}
>>>
>>> \begin{document}
>>> \newcount \xytest
>>> $$\xy >>> \xytest0 >>> {\red\ar@{->}^{\green f}(20,0)} >>> \endxy$$
>>> Test
>>> \end{document}
>>>
>>> you find nothing special about the output.  In particular, the word Test
>>> is black.  Now comment out the line \xytest0 and see what happens.  On
>>> my computer the word Test is now red.  How can this totally irrelevant
>>> assignment make a difference in the behavior?  And how can this color
>>> assignment, which is inside a group, make a difference outside?
>>>
>>> This would appear to have something to do with something in xy-pic since
>>> the simple test line: {\red Test} Test gives the expected result, the
>>> first word in red and the second one black.
>>>
>>> Michael
>
>
>
> Hope this helps,
>
> 	Ross
>
> ------------------------------------------------------------------------
> Ross Moore                                       ross.moore at mq.edu.au
> Mathematics Department                           office: E7A-206
> Macquarie University                             tel: +61 (0)2 9850 8955
> Sydney, Australia  2109                          fax: +61 (0)2 9850 8114
> ------------------------------------------------------------------------
>
>

--
Every gun that is made, every warship launched, every rocket fired
signifies, in the final sense, a theft from those who hunger and are not
fed, those who are cold and are not clothed. -Dwight D. Eisenhower