User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.17)
            Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
References: <4DF7CBEF.6080402@arcor.de> <4DF7D114.3020601@morningstar2.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <4DF7D72A.7070401@arcor.de>
Date:         Tue, 14 Jun 2011 23:48:26 +0200
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@listserv.uni-heidelberg.de>
Sender: Mailing list for the LaTeX3 project <LATEX-L@listserv.uni-heidelberg.de>
From: Stephan Hennig <mailing_list@ARCOR.DE>
Subject: Re: xparse and hyperref: Token not allowed in a PDF string (PDFDocEncoding)
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <4DF7D114.3020601@morningstar2.co.uk>
Precedence: list
Status: R

schrieb Joseph Wright:
> On 14/06/2011 22:00, Stephan Hennig wrote:
>> 
>> Is that expected behaviour?  Would it be possible to make
>> \NewDocumentCommand macros work with hyperref bookmarks?  I'd prefer
>> using \NewDocumentCommand macros because of the mandatory argument of
>> \DeclareExpandableDocumentCommand macros which I don't need in my context.
> 
> That is not trivial in general because you need to know what definition
> to use in an expansion context (arguments or not). That can only really
> be done by a programmer, not an automated system. For example, in
> siunitx I do provide appropriate 'shortcut' definitions and hook them
> into hyperref using \pdfstringdefDisableCommands. Doing that means
> making some pretty careful judgements on what should happen in
> bookmarks: many things simply do not make sense there.

OK, thanks!  I'll have a look at how \pdfstringdefDisableCommands can
help me.  I have already used \texorpdfstring, but having to maintain
two arguments is no fun.


> In the case case you mention, I'm not sure why you have used
> 
>   \DeclareExpandableDocumentCommand{\foob}{m}{FooB}
> 
> rather than
> 
>   \DeclareExpandableDocumentCommand{\foob}{}{FooB}
> 
> which works fine.

Well, because of this item from xparse documentation (sec. 1.7):

> * The function must have at least one mandatory argument, and in 
> particular the last argument must be one of the mandatory types (l, m
> or u).

Do I miss something?

Best regards,
Stephan Hennig