Hi Heiko, and Akira,
On 06/11/2011, at 3:55 AM, Heiko Oberdiek wrote:
> \special{%
> pdf:ann width 4bp height 2bp depth 2bp<<%
> /Type/Annot%
> /foo/ab#abc
> /Subtype/Link%
> /Border[0 0 1]%
> /C[0 0 1]% blue border
> /A<<%
On Sat, Nov 05, 2011 at 04:14:03PM +, Jonathan Kew wrote:
> > Thanks Akira. But caution, it could break bookmark strings that
> > currently works more or less accidently, sometimes with warnings.
>
> IIRC (it's a while since I looked at any of this), I believe Unicode
> bookmark strings work
Dear Jonathan, Heiko,
> IIRC (it's a while since I looked at any of this), I believe
> Unicode bookmark strings work deliberately (not accidentally)
> - I think this came up early on as an issue, and encoding-form
> conversion was implemented to ensure that it works.
> (It's possible there are bu
On Sun, Nov 06, 2011 at 12:57:12AM +0900, Akira Kakuto wrote:
> > > > I have disabled to reencode pdf strings to UTF-16 in xdvipdfmx: TL
> > > > trunk r24508.
> > > > Now
> > > > /D
> > > > and
> > > > /Names[7 0 R]
>
> We can choose that both of the above are UTF16BE with BOM,
> by reencoding b
On 5 Nov 2011, at 15:24, Heiko Oberdiek wrote:
> On Sat, Nov 05, 2011 at 02:45:32PM +, Jonathan Kew wrote:
>
>> On 5 Nov 2011, at 10:24, Akira Kakuto wrote:
>>
>>> Dear Heiko,
>>>
Conclusion:
* The encoding mess with 8-bit characters remain even with XeTeX.
>>>
>>> I hav
Dear Heiko, Jonathan,
> > > I have disabled to reencode pdf strings to UTF-16 in xdvipdfmx: TL trunk
> > > r24508.
> > > Now
> > > /D
> > > and
> > > /Names[7 0 R]
We can choose that both of the above are UTF16BE with BOM,
by reencoding both of them. Which do you think is beter?
> Thanks Akira.
On Sat, Nov 05, 2011 at 02:45:32PM +, Jonathan Kew wrote:
> On 5 Nov 2011, at 10:24, Akira Kakuto wrote:
>
> > Dear Heiko,
> >
> >> Conclusion:
> >> * The encoding mess with 8-bit characters remain even with XeTeX.
> >
> > I have disabled to reencode pdf strings to UTF-16 in xdvipdf
On 5 Nov 2011, at 10:24, Akira Kakuto wrote:
> Dear Heiko,
>
>> Conclusion:
>> * The encoding mess with 8-bit characters remain even with XeTeX.
>
> I have disabled to reencode pdf strings to UTF-16 in xdvipdfmx: TL trunk
> r24508.
> Now
> /D
> and
> /Names[7 0 R]
>
> Thanks,
> Akira
Dear Heiko,
> > >>> Conclusion:
> > >>> * The encoding mess with 8-bit characters remain even with XeTeX.
I have disabled to reencode pdf strings to UTF-16 in xdvipdfmx: TL trunk r24508.
Now
/D
and
/Names[7 0 R]
Thanks,
Akira
--
Subscriptions, A
On Sat, Nov 05, 2011 at 11:59:29AM +1100, Ross Moore wrote:
> >>> Conclusion:
> >>> * The encoding mess with 8-bit characters remain even with XeTeX.
> >>
> >> Well, surely it is manifest only in the driver part: xdvipdfmx
> >
> > No, the problem are both parts. XeTeX can only write UTF-8,
> >
On Fri, Nov 04, 2011 at 07:31:02AM +1100, Ross Moore wrote:
> On 04/11/2011, at 1:58 AM, Heiko Oberdiek wrote:
>
> > Hello,
> >
> > to get more to the point, I start a new thread.
>
> Yes. very good idea.
>
> > As we have learned, the PDF specification uses byte strings
> > for anchor names. A
Hi Heiko,
On 04/11/2011, at 1:58 AM, Heiko Oberdiek wrote:
> Hello,
>
> to get more to the point, I start a new thread.
Yes. very good idea.
> As we have learned, the PDF specification uses byte strings
> for anchor names. And there is a wish to use "normal" characters
> in anchor names.
With
Hello,
to get more to the point, I start a new thread.
As we have learned, the PDF specification uses byte strings
for anchor names. And there is a wish to use "normal" characters
in anchor names. Let's make an example:
xetex --ini --output-driver='xdvipdfmx -V4' test
%%% test.tex %%%
\catcode`\
13 matches
Mail list logo
