> Thanks for preparing the test files. Experimenting, I found it wasn't
> related to the character encoding problem, because removing the
> \directlua code made no difference.
>
> I got it down to the following:
>
[...snip...]
>
> This discussion on the lualatex-dev mailing list suggested the pr
Here's a file that I ran with pdftex and with luatex: both worked.
If this looks right, the code can be moved into texinfo.tex.
>>
>> \ifx\XeTeXrevision\thisisundefined
>> \else
>> \XeTeXinputencoding "bytes"
>> \fi
>>
>> although I haven't been able to test this.
>
> I've tried the at
Here's a file that I ran with pdftex and with luatex: both worked.
If this looks right, the code can be moved into texinfo.tex.
>>
>> \ifx\XeTeXrevision\thisisundefined
>> \else
>> \XeTeXinputencoding "bytes"
>> \fi
>>
>> although I haven't been able to test this.
>
> I've tried the at
>>> Here's a file that I ran with pdftex and with luatex: both worked.
>>> If this looks right, the code can be moved into texinfo.tex.
>
> \ifx\XeTeXrevision\thisisundefined
> \else
> \XeTeXinputencoding "bytes"
> \fi
>
> although I haven't been able to test this.
I've tried the attached file.
>> This appears to be the code to get the byte values into LuaTeX:
>>
>> http://wiki.luatex.org/index.php/Process_input_buffer#Latin-1
>>
>> It needs a bit more background knowledge before it can be copied and
>> pasted into texinfo.tex.
>
> Here's a file that I ran with pdftex and with luatex: bo
On 4 January 2016 at 14:06, Masamichi HOSODA wrote:
> But, still another errors occur while making LilyPond documents.
> Attached files --- macro-html.texi and macro-quotation.texi --- are minimal
> examples.
>
> By pdfTeX, both they are worked fine.
> By LuaTeX, both they are failed like followi
On 4 January 2016 at 03:12, Werner LEMBERG wrote:
>
>> Here's a file that I ran with pdftex and with luatex: both worked.
>> If this looks right, the code can be moved into texinfo.tex.
\ifx\XeTeXrevision\thisisundefined
\else
\XeTeXinputencoding "bytes"
\fi
although I haven't been able to test
> Here's a file that I ran with pdftex and with luatex: both worked.
> If this looks right, the code can be moved into texinfo.tex.
Nice! Does similar code exist for XeTeX?
Werner
Here's a file that I ran with pdftex and with luatex: both worked.
Worked for me too (also tex and etex; xetex still fails, of course, but
that's ok). Nice job. I could ask my LuaTeX friends if we're missing
anything, but it looks straightforward.
My only comment is merely stylistic: for t
On 1 January 2016 at 09:43, Gavin Smith wrote:
>
> This appears to be the code to get the byte values into LuaTeX:
>
> http://wiki.luatex.org/index.php/Process_input_buffer#Latin-1
>
> It needs a bit more background knowledge before it can be copied and
> pasted into texinfo.tex.
Here's a file th
>>> Thanks for working on this. This patch uses native LuaTeX support
>>> for Unicode. If we wanted to support this in texinfo.tex, it should
>>> probably be optional.
>>
>> Rather not.
>
> Why not? What about the reasons Karl mentioned for defaulting to
> bytewise input (assuming we find some way
On 2 January 2016 at 19:24, Werner LEMBERG wrote:
>
>>> I've made attached quick hack patch for texinfo.tex. The
>>> following command [to compile the lilypond documentation] does
>>> not occur `Undefined control sequence.' with the patch.
>>
>> Thanks for working on this. This patch uses
>> I've made attached quick hack patch for texinfo.tex. The
>> following command [to compile the lilypond documentation] does
>> not occur `Undefined control sequence.' with the patch.
>
> Thanks for working on this. This patch uses native LuaTeX support
> for Unicode. If we wanted to su
On 2 January 2016 at 06:20, Werner LEMBERG wrote:
>> I agree it should be skipped.
>>
>> In some ideal world, but in this world, I think doing so would lead
>> to huge problems. For the present, it seems far more feasible to me
>> to keep using the UTF-8 code in texinfo.tex for the immediate
> I agree it should be skipped.
>
> In some ideal world, but in this world, I think doing so would lead
> to huge problems. For the present, it seems far more feasible to me
> to keep using the UTF-8 code in texinfo.tex for the immediate
> problem than refactor all the font stuff, all the ch
On 31 December 2015 at 23:32, Karl Berry wrote:
> Does anyone know how to check whether luatex or xetex is being used
> in TeX?
>
> \luatexversion
> \XeTeXrevision
> See, e.g., ifxetex.sty, ifluatex.sty, ifplatform.sty.
>
> You also want to know if (for luatex) the output is PDF (ifpdf.sty
I agree it should be skipped.
In some ideal world, but in this world, I think doing so would lead to
huge problems. For the present, it seems far more feasible to me to
keep using the UTF-8 code in texinfo.tex for the immediate problem than
refactor all the font stuff, all the character supp
On 31 December 2015 at 13:48, Werner LEMBERG wrote:
>
>> So here's what's happening. When @documentencoding UTF-8 is given,
>> it makes bytes 128-255 active. However, for LuaTeX, it's actually
>> making characters 128-255 active.
>
> Do we need active characters in that range at all for luatex (a
> So here's what's happening. When @documentencoding UTF-8 is given,
> it makes bytes 128-255 active. However, for LuaTeX, it's actually
> making characters 128-255 active.
Do we need active characters in that range at all for luatex (and
xetex)? The UTF8 support (this is, the code that convert
On 31 December 2015 at 12:58, Gavin Smith wrote:
> On 31 December 2015 at 11:17, Werner LEMBERG wrote:
>>
>>> I think the "Undefined control sequence" message comes for an active
>>> character (that is, a byte with category code 13) which doesn't have a
>>> definition. This would be hex c2.
>>
>>
On 31 December 2015 at 11:17, Werner LEMBERG wrote:
>
>> I think the "Undefined control sequence" message comes for an active
>> character (that is, a byte with category code 13) which doesn't have a
>> definition. This would be hex c2.
>
> Can you really make byte 0xC2 active in luatex? This wou
>> You could try the attached file and send the log here to see if we
>> can find any enlightenment from it. [...]
XeTeX fails in a similar way, see attached log.
Werner
This is XeTeX, Version 3.14159265-2.6-0.2 (TeX Live 2015) (preloaded
format=xetex 2015.12.31) 31 DEC 2015 12:18
en
> I think the "Undefined control sequence" message comes for an active
> character (that is, a byte with category code 13) which doesn't have a
> definition. This would be hex c2.
Can you really make byte 0xC2 active in luatex? This would completely
break Unicode support, since 0xC2 is an incomp
On 30 December 2015 at 23:24, Werner LEMBERG wrote:
>
> Processing the attached document with luatex, I get
>
> ! Undefined control sequence.
> l.7 which assigns the symbols *, †, ‡, §
> , ¶ to
>
> It works just fine with pdtex. A bug?
I think the
> I guess we're talking about U+00A7, the section sign, \S in
> plain.tex?
Yes, and \P. Note, however, that both @S and @P work within a texinfo
document. It's just that texinfo.tex's \DeclareUnicodeCharacter for
`§' and `¶' (which use `\S' and `\P' for its definition) seem to be
modified, resu
Processing the attached document with luatex, I get
I guess we're talking about U+00A7, the section sign, \S in plain.tex?
I suppose something somewhere is overwriting that definition, and we
should \let the plain \S as some other longer name to avoid the problem.
(Plain LuaTeX itself does n
> §, ¶
Sigh. This should be
§, ¶
of course.
Werner
> Processing the attached document [...]
Oops! Apparently the wrong file encoding, so here's another try.
\input texinfo.tex
@documentencoding UTF-8
§, ¶
@bye
Processing the attached document with luatex, I get
! Undefined control sequence.
l.7 which assigns the symbols *, †, ‡, §
, ¶ to
It works just fine with pdtex. A bug?
Werner
\input texinfo.tex
@documentencoding UTF-8
§, ¶
@bye
29 matches
Mail list logo
