Re: Snippet 706: Generating custom flags

2016-01-09 Thread Masamichi HOSODA 
> 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 the other hand, XeTeX seems better than LuaTeX.
> 
> I've tried texinfo.tex ver. 2016-01-04.21 and following patches with XeTeX.
> http://lists.gnu.org/archive/html/bug-texinfo/2016-01/msg00064.html
> http://lists.gnu.org/archive/html/bug-texinfo/2016-01/msg00060.html
> 
> Command:
> $ PDFTEX=xetex make -j 16 CPU_COUNT=16 doc
> 
> As a result, there are still errors, but some of the PDFs is able to generate.
> https://drive.google.com/file/d/0ByGBX3PDrqjsT3ZmV3pEV19lZk0/view?usp=sharing
> 
> In the case of XeTeX:
> Snippet `Generating custom flags' works fine.
> But, essay can not generate due to error.
> And, I've noticed that all PDF bookmarks are not generated.
> There may be many other problems.

I've made some patches.

Perhaps errors no longer occur by XeTeX,
but there might be something wrong.

I've created Issue 4737 etc.
http://sourceforge.net/p/testlilyissues/issues/4737/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Snippet 706: Generating custom flags

2016-01-06 Thread Masamichi HOSODA 
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 the other hand, XeTeX seems better than LuaTeX.

I've tried texinfo.tex ver. 2016-01-04.21 and following patches with XeTeX.
http://lists.gnu.org/archive/html/bug-texinfo/2016-01/msg00064.html
http://lists.gnu.org/archive/html/bug-texinfo/2016-01/msg00060.html

Command:
$ PDFTEX=xetex make -j 16 CPU_COUNT=16 doc

As a result, there are still errors, but some of the PDFs is able to generate.
https://drive.google.com/file/d/0ByGBX3PDrqjsT3ZmV3pEV19lZk0/view?usp=sharing

In the case of XeTeX:
Snippet `Generating custom flags' works fine.
But, essay can not generate due to error.
And, I've noticed that all PDF bookmarks are not generated.
There may be many other problems.

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Snippet 706: Generating custom flags

2016-01-01 Thread Masamichi HOSODA 
>>> 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 from other fonts,
> but this mechanism fails for both luatex and xetex.

I've made attached quick hack patch for texinfo.tex.
The following command does not occur `Undefined control sequence.'
with the patch.

$ TEX=luatex PDFTEX=luatex PDFLATEX=lualatex make -j 16 CPU_COUNT=16 LANGS='' 
doc

Some other errors occur, but † U+2020 DAGGER, ‡ U+2012 DOUBLE DAGGER,
§ U+00A7 SECTION SIGN and ¶ U+00B6 PILCROW SIGN are not missing in the PDF.
However, all of the fonts in the PDF are lmroman10-regular.otf by the patch.
--- a/texinfo.tex
+++ b/texinfo.tex
@@ -58,7 +58,7 @@
 %
 % The GNU Texinfo home page is http://www.gnu.org/software/texinfo.
 
-
+\input luaotfload.sty
 \message{Loading texinfo [version \texinfoversion]:}
 
 % If in a .fmt file, print the version number
@@ -1780,8 +1780,8 @@ end
 % #5 = OT1
 %
 \def\setfont#1#2#3#4#5{%
-  \font#1=\fontprefix#2#3 scaled #4
-  \csname cmap#5\endcsname#1%
+  \font#1{file:lmroman10-regular.otf}%
+  #1%
 }
 % This is what gets called when #5 of \setfont is empty.
 \let\cmap\gobble
@@ -9479,7 +9479,7 @@ directory should work if nowhere else does.}
  \latninechardefs
   %
   \else \ifx \declaredencoding \utfeight
- \setnonasciicharscatcode\active
+ %\setnonasciicharscatcode\active
  % since we already invoked \utfeightchardefs at the top level
  % (below), do not re-invoke it, then our check for duplicated
  % definitions triggers.  Making non-ascii chars active is enough.
@@ -10563,48 +10563,7 @@ directory should work if nowhere else does.}
 
 % Latin1 (ISO-8859-1) character definitions.
 \def\nonasciistringdefs{%
-  \setnonasciicharscatcode\active
-  \def\defstringchar##1{\def##1{\string##1}}%
-  %
-  \defstringchar^^80\defstringchar^^81\defstringchar^^82\defstringchar^^83%
-  \defstringchar^^84\defstringchar^^85\defstringchar^^86\defstringchar^^87%
-  \defstringchar^^88\defstringchar^^89\defstringchar^^8a\defstringchar^^8b%
-  \defstringchar^^8c\defstringchar^^8d\defstringchar^^8e\defstringchar^^8f%
-  %
-  \defstringchar^^90\defstringchar^^91\defstringchar^^92\defstringchar^^93%
-  \defstringchar^^94\defstringchar^^95\defstringchar^^96\defstringchar^^97%
-  \defstringchar^^98\defstringchar^^99\defstringchar^^9a\defstringchar^^9b%
-  \defstringchar^^9c\defstringchar^^9d\defstringchar^^9e\defstringchar^^9f%
-  %
-  \defstringchar^^a0\defstringchar^^a1\defstringchar^^a2\defstringchar^^a3%
-  \defstringchar^^a4\defstringchar^^a5\defstringchar^^a6\defstringchar^^a7%
-  \defstringchar^^a8\defstringchar^^a9\defstringchar^^aa\defstringchar^^ab%
-  \defstringchar^^ac\defstringchar^^ad\defstringchar^^ae\defstringchar^^af%
-  %
-  \defstringchar^^b0\defstringchar^^b1\defstringchar^^b2\defstringchar^^b3%
-  \defstringchar^^b4\defstringchar^^b5\defstringchar^^b6\defstringchar^^b7%
-  \defstringchar^^b8\defstringchar^^b9\defstringchar^^ba\defstringchar^^bb%
-  \defstringchar^^bc\defstringchar^^bd\defstringchar^^be\defstringchar^^bf%
-  %
-  \defstringchar^^c0\defstringchar^^c1\defstringchar^^c2\defstringchar^^c3%
-  \defstringchar^^c4\defstringchar^^c5\defstringchar^^c6\defstringchar^^c7%
-  \defstringchar^^c8\defstringchar^^c9\defstringchar^^ca\defstringchar^^cb%
-  \defstringchar^^cc\defstringchar^^cd\defstringchar^^ce\defstringchar^^cf%
-  %
-  \defstringchar^^d0\defstringchar^^d1\defstringchar^^d2\defstringchar^^d3%
-  \defstringchar^^d4\defstringchar^^d5\defstringchar^^d6\defstringchar^^d7%
-  \defstringchar^^d8\defstringchar^^d9\defstringchar^^da\defstringchar^^db%
-  \defstringchar^^dc\defstringchar^^dd\defstringchar^^de\defstringchar^^df%
-  %
-  \defstringchar^^e0\defstringchar^^e1\defstringchar^^e2\defstringchar^^e3%
-  \defstringchar^^e4\defstringchar^^e5\defstringchar^^e6\defstringchar^^e7%
-  \defstringchar^^e8\defstringchar^^e9\defstringchar^^ea\defstringchar^^eb%
-  \defstringchar^^ec\defstringchar^^ed\defstringchar^^ee\defstringchar^^ef%
-  %
-  \defstringchar^^f0\defstringchar^^f1\defstringchar^^f2\defstringchar^^f3%
-  \defstringchar^^f4\defstringchar^^f5\defstringchar^^f6\defstringchar^^f7%
-  \defstringchar^^f8\defstringchar^^f9\defstringchar^^fa\defstringchar^^fb%
-  \defstringchar^^fc\defstringchar^^fd\defstringchar^^fe\defstringchar^^ff%
+   \relax
 }
 
 
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Snippet 706: Generating custom flags

2015-12-31 Thread Masamichi HOSODA 
>> 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 *, †, ‡, §
>>and ¶ to
>> ```
>>
>> If I understand correctly,
>> it seems that LuaTeX with texinfo.tex can not handle the following letters.
>> § U+00A7 SECTION SIGN
>> ¶ U+00B6 PILCROW SIGN
> 
> This is a bug (most probably in luatex) which I've meanwhile reported
> to the texinfo team.  Maybe they can fix it easily with a modification
> of `texinfo.tex' – a long-term fix in luatex doesn't help us right
> now.
> 
> Until then, we might replace `§' and `¶' (the latter character also
> fails with luatex), with the commands `@S' and `@P', respectively.
> Patch appended.

Thank you for your informatin.

At least the following letters are failed with same error:
ø U+00F8 LATIN SMALL LETTER O WITH STROKE (\o) in internals and music-glossary,
ù U+00F9 LATIN SMALL LETTER U WITH GRAVE (\`u) in snippets,
ü U+00FC LATIN SMALL LETTER U WITH DIAERESIS (\"u) in essay.

Also, many other letters will be failed.

\S and \P may be minor.
So they can be replaced easily.

However, If I understand correctly, \"u is major in german text.
It is difficult to replace all \"u, isn't it?

Moreover, there are other errors as following.

```
/home/trueroad/git/lilypond/lilypond/Documentation/contributor/introduction.itex
i:98: This command can appear only outside of any environment, not in environme
nt @quotation.
@badenverr ...temp , not @inenvironment @thisenv }
  
@checkenv ...@ifx @thisenv @temp @else @badenverr 
  @fi 
@\node #1->@checkenv {}
   @donode #1 ,@finishnodeparse 
l.98 @node Summary for experienced developers
```

```
./learning/tutorial.texi:107: This command can appear only outside of any envir
onment, not in environment @quotation.
@badenverr ...temp , not @inenvironment @thisenv }
  
@checkenv ...@ifx @thisenv @temp @else @badenverr 
  @fi 
@\node #1->@checkenv {}
   @donode #1 ,@finishnodeparse 
l.107 @node Producing output
```

```
./notation/pitches.texi:924: This command can appear only outside of any enviro
nment, not in environment @quotation.
@badenverr ...temp , not @inenvironment @thisenv }
  
@checkenv ...@ifx @thisenv @temp @else @badenverr 
  @fi 
@\node #1->@checkenv {}
   @donode #1 ,@finishnodeparse 
l.924 @node Note names in other languages
```

```
./usage/running.texi:406: This command can appear only in environment @table, n
ot in environment @quotation.
@badenverr ...temp , not @inenvironment @thisenv }
  
@checkenv ...@ifx @thisenv @temp @else @badenverr 
  @fi 
@\end ...pandafter @checkenv @csname #1@endcsname 
  @csname E#1@endcsname @end...
l.406 @end table
```

```
./web.texi:112: File ended while scanning use of \doignoretext.
 
@par 
@scanmacro ...atspaces }@scantokens {#1@texinfoc }
  @aftermacro 
l.112 @divId{pageHeader}
  
```

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Snippet 706: Generating custom flags

2015-12-31 Thread Werner LEMBERG 

> 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

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Snippet 706: Generating custom flags

2015-12-31 Thread Werner LEMBERG 

> 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

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Snippet 706: Generating custom flags

2015-12-31 Thread David Kastrup 
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 assigns the symbols *, †, ‡, §
>>and ¶ to
>> ```
>>
>> If I understand correctly,
>> it seems that LuaTeX with texinfo.tex can not handle the following letters.
>> § U+00A7 SECTION SIGN
>> ¶ U+00B6 PILCROW SIGN
>
> This is a bug (most probably in luatex) which I've meanwhile reported
> to the texinfo team.  Maybe they can fix it easily with a modification
> of `texinfo.tex' – a long-term fix in luatex doesn't help us right
> now.
>
> Until then, we might replace `§' and `¶' (the latter character also
> fails with luatex), with the commands `@S' and `@P', respectively.
> Patch appended.

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.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Snippet 706: Generating custom flags

2015-12-31 Thread Masamichi HOSODA 
> 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 file is its screenshot.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Snippet 706: Generating custom flags

2015-12-31 Thread Werner LEMBERG 

>> 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 from other fonts,
but this mechanism fails for both luatex and xetex.

> I think it's safe to say that this patch is not going to help.
> We'll need a fix in texinfo.tex.

Yep.  It's really surprising that noone has ever reported those
problems, which certainly exist since a few years...


Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Snippet 706: Generating custom flags

2015-12-31 Thread Masamichi HOSODA 
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 problem.
† and ‡ occur no errors but they are missed in PDF.

Attached file is its screenshot.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Snippet 706: Generating custom flags

2015-12-31 Thread David Kastrup 
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 8bit engines, the glyphs for † and ‡ are taken from other fonts,
> but this mechanism fails for both luatex and xetex.
>
>> I think it's safe to say that this patch is not going to help.
>> We'll need a fix in texinfo.tex.
>
> Yep.  It's really surprising that noone has ever reported those
> problems, which certainly exist since a few years...

My guess would be that Karl Berry considered "this newfangled stuff none
of my beeswax" at a time when those engines (as well as non-ASCII input
and/or fonts) were less common.  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(?).

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Snippet 706: Generating custom flags

2015-12-31 Thread David Kastrup 
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.
>
> 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 file is its screenshot.

I think it's safe to say that this patch is not going to help.  We'll
need a fix in texinfo.tex.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Snippet 706: Generating custom flags

2015-12-30 Thread Werner LEMBERG 
> 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 *, †, ‡, §
>and ¶ to
> ```
>
> If I understand correctly,
> it seems that LuaTeX with texinfo.tex can not handle the following letters.
> § U+00A7 SECTION SIGN
> ¶ U+00B6 PILCROW SIGN

This is a bug (most probably in luatex) which I've meanwhile reported
to the texinfo team.  Maybe they can fix it easily with a modification
of `texinfo.tex' – a long-term fix in luatex doesn't help us right
now.

Until then, we might replace `§' and `¶' (the latter character also
fails with luatex), with the commands `@S' and `@P', respectively.
Patch appended.


Werner


==


diff --git a/input/regression/footnote-auto-numbering-page-reset.ly 
b/input/regression/footnote-auto-numbering-page-reset.ly
index 369db80..7fc4635 100644
--- a/input/regression/footnote-auto-numbering-page-reset.ly
+++ b/input/regression/footnote-auto-numbering-page-reset.ly
@@ -1,8 +1,14 @@
 \version "2.19.21"
+
+% In the \header text below, we have to replace characters `§' and `¶'
+% with @S and @P, respectively, otherwise luatex can't process the
+% documentation due to a bug (as present in TeXLive 2015 together with
+% `texinfo.tex' version 2015-12-20.12).
+
 \header {
   texidoc = "This is an example of automatic footnote numbering
 where the number is reset on each page.  It uses the symbol-footnotes
-numbering function, which assigns the symbols *, †, ‡, § and ¶ to
+numbering function, which assigns the symbols *, †, ‡, @S{} and @P{} to
 successive footnotes, doubling up on the symbol after five footnotes
 have been reached.
 "
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Snippet 706: Generating custom flags

2015-12-29 Thread Werner LEMBERG 
>>> 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.

Lilypond uses the OpenType (CFF) version of TeXGyreSchola to create
the PDF.  pdftex, however, uses the Type 1 (PFB) version.  The former
contains `f_i' and `f_l' glyphs, while the latter has `fi' and `fl'.
To make the output PDF file as small as possible, pdftex tries (a) to
merge the (subsetted) fonts of included PDF files, and (b) to subset
the fonts afterwards again.  To unify fonts, pdftex obviously looks at
the font name only – it assumes that fonts with identical names have
identical glyph names, which normally is a sound assumption, but here
it fails.

There are two bugs in pdftex.

  (1) It touches the fonts of an included PDF file without any need,
  since the test LaTeX document doesn't use TeXGyreSchola.

  (2) It doesn't check for alternative glyph names of ligatures; due
  to the Adobe Glyph Name (AGN) algorithm, valid names for the
  `fi' ligature are both `fi' and `f_i'.

Similarly, there is a bug in TeXGyre: There is absolutely no need to
use the two different glyph names `fi' and `f_i', depending on the
font format.  If you really want to do that, it is trivial to make the
CFF and PFB version both contain `fi' and `f_i'.

luatex, on the other hand, also uses the CFF version, so there is no
font format clash.


Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Snippet 706: Generating custom flags

2015-12-29 Thread Masamichi HOSODA 
 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.
> 
> Lilypond uses the OpenType (CFF) version of TeXGyreSchola to create
> the PDF.  pdftex, however, uses the Type 1 (PFB) version.  The former
> contains `f_i' and `f_l' glyphs, while the latter has `fi' and `fl'.
> To make the output PDF file as small as possible, pdftex tries (a) to
> merge the (subsetted) fonts of included PDF files, and (b) to subset
> the fonts afterwards again.  To unify fonts, pdftex obviously looks at
> the font name only – it assumes that fonts with identical names have
> identical glyph names, which normally is a sound assumption, but here
> it fails.
> 
> There are two bugs in pdftex.
> 
>   (1) It touches the fonts of an included PDF file without any need,
>   since the test LaTeX document doesn't use TeXGyreSchola.
> 
>   (2) It doesn't check for alternative glyph names of ligatures; due
>   to the Adobe Glyph Name (AGN) algorithm, valid names for the
>   `fi' ligature are both `fi' and `f_i'.
> 
> Similarly, there is a bug in TeXGyre: There is absolutely no need to
> use the two different glyph names `fi' and `f_i', depending on the
> font format.  If you really want to do that, it is trivial to make the
> CFF and PFB version both contain `fi' and `f_i'.
> 
> luatex, on the other hand, also uses the CFF version, so there is no
> font format clash.

Thank you for your explanation.

There may be a workaround that is
to delete all TeX Gyre PFB fonts in pdfTeX search path.
I've deleted them. Then, pdfTeX works fine.

Of course, there are many problems with the workaround.
To use LuaTeX instead of pdfTeX would be a genuine solution.

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 *, †, ‡, §
   and ¶ to
```

If I understand correctly,
it seems that LuaTeX with texinfo.tex can not handle the following letters.
§ U+00A7 SECTION SIGN
¶ U+00B6 PILCROW SIGN


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Snippet 706: Generating custom flags

2015-12-29 Thread Masamichi HOSODA 
 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 my environment, after full make doc,
>>> build/Documentation/snippets.texi2pdf.log shows the following:
>>>
>>> ```
>>> 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.
>>
>>
>>Werner
> 
> 
> How could we fix this?

To use LuaTeX instead of pdfTeX may be one of the solution.
However, the following command is failed in my environment.

$ PDFTEX=luatex PDFLATEX=lualatex make -j 16 CPU_COUNT=16 LANGS='' doc

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Snippet 706: Generating custom flags

2015-12-29 Thread Phil Holmes 
- 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 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 my environment, after full make doc,
build/Documentation/snippets.texi2pdf.log shows the following:

```
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.


   Werner



How could we fix this?

--
Phil Holmes 



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Snippet 706: Generating custom flags

2015-12-29 Thread Werner LEMBERG 

>> 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 my environment, after full make doc,
> build/Documentation/snippets.texi2pdf.log shows the following:
> 
> ```
> 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.


Werner

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Snippet 706: Generating custom flags

2015-12-28 Thread Phil Holmes 
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?


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Snippet 706: Generating custom flags

2015-12-28 Thread Masamichi HOSODA 
> 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 my environment, after full make doc,
build/Documentation/snippets.texi2pdf.log shows the following:

```
pdfTeX warning: pdfetex (file /usr/share/texmf-dist/fonts/type1/public/tex-gyre
/qcsr.pfb): glyph `f_i' undefined


pdfTeX warning: pdfetex (file /usr/share/texmf-dist/fonts/type1/public/tex-gyre
/qcsr.pfb): glyph `f_l' undefined
>\documentclass{article}
\usepackage{graphicx}
\begin{document}

\includegraphics{lily-cc95e515-1}

\end{document}


lily-cc95e515-1.pdf
Description: Adobe PDF document
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel