[Xy-pic] Really weird behavior

Daniel Müllner daniel at danifold.net
Fri Dec 13 10:01:51 CET 2013


Hi Ross,

thanks for expanding my terse explanation with better details. We both
agree what happens in case there is a \relax in the minimal example.
However, let's look at the code without the \relax again:

\xy
%\relax
{\color{red}Test}
\endxy

Note that I didn't claim that Xy-pic typesets an <object> here (which
your answer somehow implied). An <object> would of course be created by

*{\color{red}Test}

Without the star, however, Xy-pic expects a <coor>dinate, and according
to the reference manual, the coordinate is "the c [current coordinate]
resulting from interpreting the group". (As an aside, there is no Xy-pic
code inside the group since Xy-pic encounters the \color first and
switches to TeX mode.) Hence, what I am claiming is that there is no
<object> in the example above. The "nested Xy-pic environment" that I
referred to is not an <object> but a <coord>inate.

Am I right? It's a small detail but Xy-pic parsing can be quite intricate...

Best,

Daniel


On 12/13/2013 01:37 AM, 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
> ------------------------------------------------------------------------
> 
> 
> 
> 


-- 
Daniel Müllner
Tobelsteig 3
8046 Zürich
Switzerland
Phone +41 44 370 10 72
URL http://danifold.net


More information about the xy-pic mailing list