[Xy-pic] distance betwen double arriws

[Ross Moore]

Hi Michael, Kris Rose, and others

On 20/03/2014, at 7:07 AM, Michael Barr wrote:

> If you use diagxy (or the barr option in the latest version of xy), the problem does not seem to arise.  Or you can use the arrow offset feature to place the arrows separately.

The problem is rather interesting.

We tried to create wider double arrows using coding such as:

 \ar @<2pt>@{-}@*{[|(4)]}[d]|-(1)*{\hole}
 \ar @<-2pt>@{-}@*{[|(4)]}[d]|-(1)*{\hole}
 \ar @2@{{}>}@*{[|(4)]}[d]

but when using the XY-ps backend (i.e. TeX+dvi+Ghostscript)
 --- necessary to implement the  @*{[|(4)]}  for thicker lines
an extra dot appears.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: texshop_image.jpeg
Type: image/jpeg
Size: 12396 bytes
Desc: not available
URL: <http://tug.org/pipermail/xy-pic/attachments/20140320/c615e1ba/attachment-0001.jpeg>
-------------- next part --------------


In the above image, the right line uses the *{\hole}
whereas the left line uses 

    \ar @<-2pt>@{-}@*{[|(4)]}[d(.68)]

I can trace the internal coding to a line of zero length
in the final PostScript output.

       {0.0 0.0 l}xy

thus giving a dot at the concurrent endpoints,
since there is a round line-cap.


The question then arises whether this is a bug or a feature.
If a bug, where should the conditions be picked up,
and how should it be fixed?


A. 
Should Xy-pic detect that the line is zero length?
e.g. in the  \checkoverlap@@  method

I can imagine situations where you want an object at
a line of zero length; e.g. when using a finite object
set successively along the line.


B.
Should the method to place the line segment code
be where to detect this; e.g.
  in  \xyPSspread@  or  \xyPSsolidSpread@
  which are driver-specific.

Other drivers would then need such a test also?
And other spread methods would need patching too.


C.
Or patch it in the PostScript library,
so that the 'l' operator checks whether its arguments 
(Reverse Polish) are not both zero?



Personally I think that these are too low-level to be
the correct places to patch.
The problem arises because a break in the line/arrow
is meant to include an end-point. When this happens,
surely the coding should not generate the zero-length
line in the first place.

I'm trying to determine where within the Xy-pic internals
a test can be done to allow such a decision to be made.


> 
> Michael
> 
> On Wed, 19 Mar 2014, xy-pic-request at tug.org wrote:
> 
>> Send xy-pic mailing list submissions to
>> 	xy-pic at tug.org
>> 
>> To subscribe or unsubscribe via the World Wide Web, visit
>> 	http://tug.org/mailman/listinfo/xy-pic
>> or, via email, send a message with subject or body 'help' to
>> 	xy-pic-request at tug.org
>> 
>> You can reach the person managing the list at
>> 	xy-pic-owner at tug.org
>> 
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of xy-pic digest..."
>> 
>> 
>> Today's Topics:
>> 
>>  1. Re: double arrows (Ross Moore)
>> 
>> 
>> ----------------------------------------------------------------------
>> 
>> Message: 1
>> Date: Thu, 20 Mar 2014 06:53:59 +1100
>> From: Ross Moore <ross.moore at mq.edu.au>
>> To: Davide Sangiorgi <Davide.Sangiorgi at cs.unibo.it>
>> Cc: "xy-pic at tug.org list" <xy-pic at tug.org>
>> Subject: Re: [Xy-pic] double arrows
>> Message-ID: <BB70F58F-528C-475A-8D6E-DACC5043CC1E at mq.edu.au>
>> Content-Type: text/plain; charset="us-ascii"
>> 
>> Hi Davide,
>> 
>> On 20/03/2014, at 12:18 AM, Davide Sangiorgi wrote:
>> 
>>> Dear Ross:
>>> Putting postive numbers does not seem to help:
>>> now the shortening of the line and the dots go at the other end of the lines.  Thanks.  If you happen to find out something, i'd be very interested (i use weak arrows a lot in my talks)
>> 
>> Here is a way to do it; but there is a catch.
>> 
>> 
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: texshop_image.jpeg
>> Type: image/jpeg
>> Size: 12652 bytes
>> Desc: not available
>> URL: <http://tug.org/pipermail/xy-pic/attachments/20140320/c9fb8c67/attachment.jpeg>
>> -------------- next part --------------
>> 
>> 
>> \ar @<2pt>@{-}@*{[|(4)]}[d(.68)]
>> \ar @<-2pt>@{-}@*{[|(4)]}[d(.68)]
>> \ar @2@{{}>}@*{[|(4)]}[d]
>> 
>> That number (.68) needs to be found by trial and error.
>> It is the fraction of the distance to the matrix position
>> of the cell [d] from the target.
>> It will be different for different diagrams if you adjust the
>> row spacing, and different for longer arrows connecting cells
>> further apart, etc.
>> 
>> But if you use it a lot, some numbers with become quite common
>> for you.
>> In practice, you can pass it as an argument to a macro
>> e.g. with argument pattern
>>   \dblar[#1](#2)
>>  ---> \ar @<2pt>@{-}@*{[|(4)]}[#1(#2)] etc.


Cheers,

	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
------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo.png
Type: image/png
Size: 5257 bytes
Desc: not available
URL: <http://tug.org/pipermail/xy-pic/attachments/20140320/c615e1ba/attachment-0001.png>
-------------- next part --------------