Re: Snippet 706: Generating custom flags
> 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
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
>>> 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
> 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
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
>> 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
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
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
> 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
> 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
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
>> 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
> 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
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
>>> 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
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
- Original Message - From: "Werner LEMBERG" To: Cc: ; 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
>> 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
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 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