[XeTeX] bidi package abilities and lshort in Persian

[Ross Moore]

Hi Vafa,

On 17/07/2009, at 10:41 PM, Vafa Khalighi wrote:

> and This is what Jonathan said about hyperef and RTL in XeTeX a  
> while ago: (http://tug.org/mailman/htdig/xetex/2008-April/009508.html)
>
> "I think all this is related to the basic problem that when the TeX--
> XeT bidi mechanism is used, horizontal lists get reversed before
> output. This means that when you have \special commands in the line,
> their order also gets reversed. So if the text contains a \special
> that in some way implements "begin a link" or "set a new color", and
> later in the same line there's "end link" or "pop the color stack",
> the DVI driver ends up seeing these in the opposite order.

I understand what you are saying here, but it doesn't agree
completely with the results of my own (perhaps naïve) testing.
In the attached PDF, the bookmarks work just fine.

  
   
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lshort-bit.pdf
Type: application/pdf
Size: 120618 bytes
Desc: not available
URL: <http://tug.org/pipermail/xetex/attachments/20090718/c25f0aef/attachment-0001.pdf>
-------------- next part --------------


Citations are not resolved --- I've not experimented with these
yet --- however there is an active link in the ToC that seems
to work OK.
There is a portion of page 3 that is set in red, immediately
following the first footnote marker. It is that marker that is
meant to be a hyperlink, to the footnote itself, isn't it?
Maybe this is an example of the problems you describe?


The example was built using the  lshort  that you indicated in
an earlier posting, with just 2 kinds of modification:
   1.  comment-out the  \NoHyper  in  lshort.sty ;
   2.  don't \include  any of the actual content, just include
       the  \frontmatter  and  \backmatter  portions.

>
> I submitted the original message in this thread to the XeTeX bug
> tracker at <http://sourceforge.net/tracker/?
> group_id=194926&atid=951385>, as I think it's an issue that can't
> easily be solved at the level of individual documents or macro
> packages.

I'm yet to be convinced of the validity of this last statement.
(Don't take this to mean that I think it is false; just that I
can take some convincing, involving my own experimentation.)

> You may be able to work around some of the problems, but a
> general solution will need to be implemented at a more fundamental
> level."
>
> JK

Hope this helps,

	Ross

------------------------------------------------------------------------
Ross Moore                                       ross at maths.mq.edu.au
Mathematics Department                           office: E7A-419
Macquarie University                             tel: +61 (0)2 9850 8955
Sydney, Australia  2109                          fax: +61 (0)2 9850 8114
------------------------------------------------------------------------