> It seems that LuaTeX can not build LilyPond documents due to LuaTeX's bug.
> http://lists.gnu.org/archive/html/bug-texinfo/2016-01/msg00055.html
>
> Moreover, recent LuaTeX seems to have made significant changes
> to the PDF-related function.
> Perhaps, latest LuaTeX can not use current
It seems that LuaTeX can not build LilyPond documents due to LuaTeX's bug.
http://lists.gnu.org/archive/html/bug-texinfo/2016-01/msg00055.html
Moreover, recent LuaTeX seems to have made significant changes
to the PDF-related function.
Perhaps, latest LuaTeX can not use current texinfo.tex.
On
>>> By your patch, `@S' and `@P' are no problem. † and ‡ occur no
>>> errors but they are missed in PDF.
>
> Yes, there are more problems in texinfo.tex with non-8bit engines – it
> seems that the complete UTF-8 logic is severely broken in that case.
>
> For 8bit engines, the glyphs for † and ‡
>> To use LuaTeX, I've tried following command.
>>
>> $ PDFTEX=luatex PDFLATEX=lualatex make -j 16 CPU_COUNT=16 LANGS='' doc
>>
>> Then, it shows the following error.
>>
>> ```
>> ./18/lily-10433670.texidoc:3: Undefined control sequence.
>> l.3 ...on, which assigns the symbols *, †, ‡, §
>>
> Any words on XeTeX? I consider it likely that texinfo.tex is not
> prepared to deal with any non-8bit-engine. If that's the case,
> XeTeX would likely be similarly affected.
You are right. Sigh. It fails exactly the same way. This is, well,
embarrassing.
Werner
> Now that they are more common and Karl is no longer the main driving
> force behind texinfo.tex, it might be worth bringing up the topic on
> the Texinfo mailing list again(?).
We are right now discussing this issue on bug-texinfo.
Werner
___
Werner LEMBERG writes:
>> To use LuaTeX, I've tried following command.
>>
>> $ PDFTEX=luatex PDFLATEX=lualatex make -j 16 CPU_COUNT=16 LANGS='' doc
>>
>> Then, it shows the following error.
>>
>> ```
>> ./18/lily-10433670.texidoc:3: Undefined control sequence.
>> l.3 ...on, which
> Until then, we might replace `§' and `¶' (the latter character also
> fails with luatex), with the commands `@S' and `@P', respectively.
> Patch appended.
I've noticed another problem.
By your patch, `@S' and `@P' are no problem.
† and ‡ occur no errors but they are missed in PDF.
Attached
>> By your patch, `@S' and `@P' are no problem. † and ‡ occur no
>> errors but they are missed in PDF.
Yes, there are more problems in texinfo.tex with non-8bit engines – it
seems that the complete UTF-8 logic is severely broken in that case.
For 8bit engines, the glyphs for † and ‡ are taken
My previous mail seems Japanese encoding.
So I re-send the mail in UTF-8.
> Until then, we might replace `§' and `¶' (the latter character also
> fails with luatex), with the commands `@S' and `@P', respectively.
> Patch appended.
I've noticed another problem.
By your patch, `@S' and `@P' are no
Werner LEMBERG writes:
>>> By your patch, `@S' and `@P' are no problem. † and ‡ occur no
>>> errors but they are missed in PDF.
>
> Yes, there are more problems in texinfo.tex with non-8bit engines – it
> seems that the complete UTF-8 logic is severely broken in that case.
>
> For
Masamichi HOSODA writes:
> My previous mail seems Japanese encoding.
> So I re-send the mail in UTF-8.
>
>> Until then, we might replace `§' and `¶' (the latter character also
>> fails with luatex), with the commands `@S' and `@P', respectively.
>> Patch appended.
>
>
> To use LuaTeX, I've tried following command.
>
> $ PDFTEX=luatex PDFLATEX=lualatex make -j 16 CPU_COUNT=16 LANGS='' doc
>
> Then, it shows the following error.
>
> ```
> ./18/lily-10433670.texidoc:3: Undefined control sequence.
> l.3 ...on, which assigns the symbols *, †, ‡, §
>
>>> pdfTeX warning: pdfetex (file
>>> /usr/share/texmf-dist/fonts/type1/public/tex-gyre
>>> /qcsr.pfb): glyph `f_i' undefined
>>
>> Yep, the font in question only contains `fi' and `fl' glyph names.
>
> How could we fix this?
We can't, except using luatex, as suggested by Masamichi-san.
pdfTeX warning: pdfetex (file
/usr/share/texmf-dist/fonts/type1/public/tex-gyre
/qcsr.pfb): glyph `f_i' undefined
>>>
>>> Yep, the font in question only contains `fi' and `fl' glyph names.
>>
>> How could we fix this?
>
> We can't, except using luatex, as suggested by
In the PDF version of the snippet above, the "fl" letters of "flag"
are missing. I think this is probably because they are being
converted to a ligatured glyph, and then not displaying. Anyone
know how to prevent this from happening?
>>>
>>> If I understand correctly, it is
- Original Message -
From: "Werner LEMBERG" <w...@gnu.org>
To: <truer...@sea.plala.or.jp>
Cc: <m...@philholmes.net>; <lilypond-devel@gnu.org>
Sent: Tuesday, December 29, 2015 11:38 AM
Subject: Re: Snippet 706: Generating custom flags
In the PDF ver
>> In the PDF version of the snippet above, the "fl" letters of "flag"
>> are missing. I think this is probably because they are being
>> converted to a ligatured glyph, and then not displaying. Anyone
>> know how to prevent this from happening?
>
> If I understand correctly, it is pdfTeX
In the PDF version of the snippet above, the "fl" letters of "flag" are
missing. I think this is probably because they are being converted to a
ligatured glyph, and then not displaying. Anyone know how to prevent this
from happening?
___
> In the PDF version of the snippet above, the "fl" letters of "flag" are
> missing. I think this is probably because they are being converted to a
> ligatured glyph, and then not displaying. Anyone know how to prevent this
> from happening?
If I understand correctly, it is pdfTeX issue.
In
20 matches
Mail list logo