Re: 2.23.11 build failure on cygwin #2

[Masamichi Hosoda]

> We just released LilyPond 2.23.12 with these changes. Could you verify
> that it works correctly now on Cygwin?

It works on Cygwin.
Thank you.

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

Re: 2.23.11 build failure on cygwin #2

[Masamichi Hosoda]

> second issue building on Cygwin
> 
> The Cygwin headers are very picky and the "-std=c++14" cause some not
> standard calls to fail compilation due to the reduced scope.
> 
> The solution is to remove the "-std=c++14" or to replace with
> "-std=gnu++14"

This fix also contained in the following merge request.
https://gitlab.com/lilypond/lilypond/-/merge_requests/1554

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

Re: 2.23.11 build failure on cygwin #1

[Masamichi Hosoda]

> Le 13/08/2022 à 22:30, Marco Atzeri a écrit :
>> Dear Developers,
>>
>> I am the Cygwin package maintainer for Lilypond and Guile
>> latest 2.22.2 builds without issue.
>>
>> On the first tentative to build/package 2.23.x for Cygwin I hit two
>> different problems so I will report them separately
>>
>>
>> first one is almost immediate
>>
>> --
>> Making flower/out/library.a
>> make[1]: *** No rule to make target 'out/lilypond.1', needed by
>> 'man'. Stop.
>> make: ***
>> [/pub/devel/lilypond/lilypond-2.23.11-1.x86_64/src/lilypond-2.23.11/./make/generic-targets.make:6:
>> all] Error 2
>> *** ERROR: make failed
>> --
>>
>> a workaround is to replace on lily/GNUmakefile
>>
>>    HELP2MAN_EXECS = lilypond
>> with
>>    HELP2MAN_EXECS = lilypond$(program_suffix)
>>
>> the build completes but has the unwanted outcome of
>> an extra ".exe" on the manual page
>>
>>   $ find lily -name "*.1"
>>   lily/out/lilypond.exe.1
>>
>> so a different solution is welcome
> 
> 
> Possibly this would be related?
> 
> commit cad8241c1339432a30dd0613b76b2245670bdb31
> Author: Jonas Hahnfeld 
> Date:   Sat May 14 22:15:47 2022 +0200
> 
>     mingw: Consistently append program_suffix
> 
>     This moves a patch from the release scripts to the proper
> GNUmakefile.
> 
> 
> Jonas, any thoughts?

I use Cygwin environment, so I created a merge request.
https://gitlab.com/lilypond/lilypond/-/merge_requests/1554

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

Re: Mistranslation in Japanese documentation?

[Masamichi Hosoda]

>> On 4 May 2022, at 20:43, Jean Abou Samra  wrote:
>> 
>> Le 03/05/2022 à 10:12, TamuraJun via bug-lilypond a écrit :
>>> Hello,
>>> 
>>> There seems to be a little mistranslation in Japanese documentation.
>>> 
>>> In https://lilypond.org/doc/v2.23/Documentation/notation/bars#bar-numbers 
>>> 
>>> 
 楽譜から小節線を削除する
 Score コンテキストから Bar_number_engraver を削除することで、小節線を完全に削除することができます。
>>> 
>>> This is probably meant to be:
>>> 
>>> 楽譜から小節番号を削除する
>>> Score コンテキストから Bar_number_engraver を削除することで、小節番号を完全に削除することができます。
>>> 
>>> The original English version reads:
>>> 
>>> Removing bar numbers from a score
>>> Bar numbers can be removed entirely by removing the Bar_number_engraver 
>>> from the Score context.
>>> 
>>> Best regards,
>>> 
>>> Jun Tamura
>>> https://imslp.org/wiki/User:Jun_T 
>> 
>> 
>> 
>> Hi,
>> 
>> Thanks for the report. Given that nobody in the development team speaks
>> Japanese (I had to use a diff tool to figure out the difference between
>> the current and correct version)…
> 
> Using an online translate tool, though not very reliable, it looks like 
> "number" (番号) has been translated as (線を).

Yes, you are generally correct.
"番号" means "number".
"線" means "line".

"を" is a Japanese particle, not a noun,
and is attached to not only to the mistranslated "線"
but also to the "番号" in the correct translation.
https://en.wikipedia.org/wiki/Japanese_particles
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Mistranslation in Japanese documentation?

[Masamichi Hosoda]

Hi,

I've created the merge request.
https://gitlab.com/lilypond/lilypond/-/merge_requests/1345

I would be happy to create your GitLab account
to review and approve the request if you can.

> Hi, Masamichi,
> 
> Would you kindly submit a merge request for this case? 
> 
> FYI, I’ve been translating Frescobaldi GUI to Japanese and, when I have some 
> spare time, I’d like to continue translating Frescobaldi rather than learning 
> git, to be honest. My Frescobaldi translation is not complete, around 35% by 
> December last year, but most of the menu items and dialogs have been covered. 
> I haven’t made much progress since December but hope to continue it once my 
> “day job" gets less hectic.
> 
> Best regards,
> 
> Jun
> 
>> 2022/05/05 15:44、Masamichi Hosoda のメール:
>> 
>> Hi,
>> 
>> Thank you for pointing out the mistranslation.
>> I speak Japanese and have experience submitting merge requests.
>> If you are interested in contributing to LilyPond,
>> you are welcome to submit a merge request, even if it takes some time.
>> If not, I can submit a merge request.
>> 
>>> Hi, Jean,
>>> 
>>> Thanks for the pointer. I’ve started reading the "Contributor’s Guide," 
>>> especially "5.9 Translating the documentation,” to see what I can possibly 
>>> contribute. I’m fine with Unix/Linux CLI but I’ve never used git or any 
>>> other version control systems. I think that I need some time to understand 
>>> how git works.
>>> 
>>> Best regards,
>>> 
>>> Jun
>>> 
>>>> 2022/05/05 3:43、Jean Abou Samra のメール:
>>>> 
>>>> Le 03/05/2022 à 10:12, TamuraJun via bug-lilypond a écrit :
>>>>> Hello,
>>>>> 
>>>>> There seems to be a little mistranslation in Japanese documentation.
>>>>> 
>>>>> In https://lilypond.org/doc/v2.23/Documentation/notation/bars#bar-numbers 
>>>>> <https://lilypond.org/doc/v2.23/Documentation/notation/bars#bar-numbers>
>>>>> 
>>>>>> 楽譜から小節線を削除する
>>>>>> Score コンテキストから Bar_number_engraver を削除することで、小節線を完全に削除することができます。
>>>>> 
>>>>> This is probably meant to be:
>>>>> 
>>>>> 楽譜から小節番号を削除する
>>>>> Score コンテキストから Bar_number_engraver を削除することで、小節番号を完全に削除することができます。
>>>>> 
>>>>> The original English version reads:
>>>>> 
>>>>> Removing bar numbers from a score
>>>>> Bar numbers can be removed entirely by removing the Bar_number_engraver 
>>>>> from the Score context.
>>>>> 
>>>>> Best regards,
>>>>> 
>>>>> Jun Tamura
>>>>> https://imslp.org/wiki/User:Jun_T <https://imslp.org/wiki/User:Jun_T>
>>>> 
>>>> 
>>>> 
>>>> Hi,
>>>> 
>>>> Thanks for the report. Given that nobody in the development team speaks
>>>> Japanese (I had to use a diff tool to figure out the difference between
>>>> the current and correct version), it would be even better if you created
>>>> a merge request yourself to fix this mistake. Have a look at
>>>> 
>>>> https://lilypond.org/doc/v2.23/Documentation/contributor/working-with-source-code
>>>>  
>>>> <https://lilypond.org/doc/v2.23/Documentation/contributor/working-with-source-code>
>>>> 
>>>> Someone else can also do this for you, just that they will most likely
>>>> be doing the contribution blindly.
>>>> 
>>>> The text is in Documentation/ja/notation/rhythms.itely around line 3174.
>>>> 
>>>> Be aware that the contributing instructions contain a flaw, which has
>>>> been fixed recently (but came too late for the 2.23.8 release). After
>>>> creating a GitLab account, and before cloning the repository, you need
>>>> to perform the steps at
>>>> https://docs.gitlab.com/ee/user/ssh.html 
>>>> <https://docs.gitlab.com/ee/user/ssh.html>
>>>> 
>>>> Best regards,
>>>> Jean
>>> 
>>> ___
>>> bug-lilypond mailing list
>>> bug-lilypond@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/bug-lilypond
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Mistranslation in Japanese documentation?

[Masamichi Hosoda]

Hi,

Thank you for pointing out the mistranslation.
I speak Japanese and have experience submitting merge requests.
If you are interested in contributing to LilyPond,
you are welcome to submit a merge request, even if it takes some time.
If not, I can submit a merge request.

> Hi, Jean,
> 
> Thanks for the pointer. I’ve started reading the "Contributor’s Guide," 
> especially "5.9 Translating the documentation,” to see what I can possibly 
> contribute. I’m fine with Unix/Linux CLI but I’ve never used git or any other 
> version control systems. I think that I need some time to understand how git 
> works.
> 
> Best regards,
> 
> Jun
> 
>> 2022/05/05 3:43、Jean Abou Samra のメール:
>> 
>> Le 03/05/2022 à 10:12, TamuraJun via bug-lilypond a écrit :
>>> Hello,
>>> 
>>> There seems to be a little mistranslation in Japanese documentation.
>>> 
>>> In https://lilypond.org/doc/v2.23/Documentation/notation/bars#bar-numbers 
>>> 
>>> 
 楽譜から小節線を削除する
 Score コンテキストから Bar_number_engraver を削除することで、小節線を完全に削除することができます。
>>> 
>>> This is probably meant to be:
>>> 
>>> 楽譜から小節番号を削除する
>>> Score コンテキストから Bar_number_engraver を削除することで、小節番号を完全に削除することができます。
>>> 
>>> The original English version reads:
>>> 
>>> Removing bar numbers from a score
>>> Bar numbers can be removed entirely by removing the Bar_number_engraver 
>>> from the Score context.
>>> 
>>> Best regards,
>>> 
>>> Jun Tamura
>>> https://imslp.org/wiki/User:Jun_T 
>> 
>> 
>> 
>> Hi,
>> 
>> Thanks for the report. Given that nobody in the development team speaks
>> Japanese (I had to use a diff tool to figure out the difference between
>> the current and correct version), it would be even better if you created
>> a merge request yourself to fix this mistake. Have a look at
>> 
>> https://lilypond.org/doc/v2.23/Documentation/contributor/working-with-source-code
>>  
>> 
>> 
>> Someone else can also do this for you, just that they will most likely
>> be doing the contribution blindly.
>> 
>> The text is in Documentation/ja/notation/rhythms.itely around line 3174.
>> 
>> Be aware that the contributing instructions contain a flaw, which has
>> been fixed recently (but came too late for the 2.23.8 release). After
>> creating a GitLab account, and before cloning the repository, you need
>> to perform the steps at
>> https://docs.gitlab.com/ee/user/ssh.html 
>> 
>> 
>> Best regards,
>> Jean
> 
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-lilypond
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Garbage copied from PDF when using certain fonts

[Masamichi Hosoda]

>> In my experiment, Cairo without LilyPond does not generate garbled
>> characters.  It seems to be a LilyPond issue instead of a Cairo
>> issue.  Here's a python-cairo sample that works fine.  [...]
> 
> I can conform that this small script generates a PDF where
> copy-and-paste works as expected (I have cairo version 1.16.0
> installed on my GNU/Linux system).  Looking into the uncompressed
> version of PDF (created with `pdftk`) I see that it contains proper
> ToUnicode cmaps for the two fonts.
> 
> Does `-dbackend=cairo` pass markup strings directly to Cairo?  

If I understand correctly, the cairo backend in LilyPond is passing
already garbled characters to the cairo library.

I created
https://gitlab.com/lilypond/lilypond/-/issues/6173

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

Re: Garbage copied from PDF when using certain fonts

[Masamichi Hosoda]

 The problem does not appear if the cairo backend is used, see
 https://gitlab.com/lilypond/lilypond/-/merge_requests/853.
>>> 
>>> This is good news!
>> 
>> When copying and pasting from a PDF generated using cairo backend,
>> some characters turned into similar but different characters.  The
>> characters are garbled in both AJ1 and AI0 fonts.  If you use ps
>> backend, characters by the AJ1 font are not garbled.  [...]
> 
> I've looked up the cairo bug tracker but couldn't find something
> related to copy-and-paste of CID-keyed fonts.  Masamichi-san, could
> you submit an issue there so that this gets fixed eventually?  I guess
> this would be beneficial for other projects, too.

In my experiment, Cairo without LilyPond does not generate garbled characters.
It seems to be a LilyPond issue instead of a Cairo issue.
Here's a python-cairo sample that works fine.

```
#!/bin/env python3

import cairo

def main():
with cairo.PDFSurface("test.pdf", 300, 100) as surface:
context = cairo.Context(surface)

context.select_font_face("Noto Serif CJK JP")
context.set_font_size(12)
context.move_to(12, 24)
context.show_text("初見はハ長調で高音の白玉があった")

context.select_font_face("HaranoAjiMincho")
context.set_font_size(12)
context.move_to(12, 48)
context.show_text("初見はハ長調で高音の白玉があった")

surface.show_page()

if __name__ == '__main__':
main ()
```

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

Re: Garbage copied from PDF when using certain fonts

[Masamichi Hosoda]

>>> When using certain fonts (in my case, Noto CJK, both pan-CJK and
>>> subset versions), the output looks right but when copied from the
>>> generated PDF file, everything becomes garbage.  [...]
>>
>> The problem does not appear if the cairo backend is used, see
>> https://gitlab.com/lilypond/lilypond/-/merge_requests/853.
> 
> This is good news!

When copying and pasting from a PDF generated using cairo backend,
some characters turned into similar but different characters.
The characters are garbled in both AJ1 and AI0 fonts.
If you use ps backend, characters by the AJ1 font are not garbled.

```
\version "2.22.0"
\markup {
  \override #'(font-name . "Noto Serif CJK JP") % Adobe-Identity-0 (AI0) font
  { 初見はハ長調で高音の白玉があった }
  \override #'(font-name . "HaranoAjiMincho") % Adobe-Japan1 (AJ1) font
  { 初見はハ長調で高音の白玉があった }
}
```

.ly file  -> Copied and pasted from PDF generated using cairo backend
見 U+898B -> U+2F92
長 U+9577 -> U+2ED1
高 U+9AD8 -> U+2FBC
音 U+97F3 -> U+2FB3
白 U+767D -> U+2F69
玉 U+7389 -> U+2F5F

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

Re: Garbage copied from PDF when using certain fonts

[Masamichi Hosoda]

>> When using certain fonts (in my case, Noto CJK, both pan-CJK and
>> subset versions), the output looks right but when copied from the
>> generated PDF file, everything becomes garbage.  [...]
> 
> Confirmed.
> 
>> It seems to be all about CID. Maybe related to Issue #6058?
> 
> Yes and no.  The fix for #6058 was to make CID fonts display correctly
> at all.  AFAICS, to make copy and paste work for CID fonts it is
> necessary to add a ToUnicode map.  We don't do that currently.  [This
> is probably worth an entry in our issues database.]  Masamichi-san,
> please correct me if I am wrong.

Yes, you need ToUnicode CMap to copy and paste characters
from Adobe-Identity-0 (AI0) fonts.
Current LilyPond does not embed the ToUnicode CMap.
Noto CJK is an AI0 font. 
Therefore, you cannot copy and paste.

If the font is not AI0, but Adobe-GB1 (AG1), Adobe-Japan1 (AJ1), etc.,
you do not necessarily need the ToUnicode CMap for copy and paste.

To copy and paste, you can use HaranoAji fonts, which are AG1 or AJ1 fonts.

HaranoAjiFontsCN (AG1 for Simplified Chinese)
https://github.com/trueroad/HaranoAjiFontsCN

HaranoAjiFonts (AJ1 for Japanese)
https://github.com/trueroad/HaranoAjiFonts

Here is a sample.

```
\version "2.22.0"
\markup {
  \override #'(font-name . "HaranoAjiMincho")
  {English}
  \override #'(font-name . "HaranoAjiMinchoCN") % For Simplified Chinese
  {中文}
  \override #'(font-name . "HaranoAjiMincho") % For Japanese
  {にほんご}
}
```
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Compilation error, due to changes in pango

[Masamichi Hosoda]

> The question is now what exactly causes this:
> 
>   error: invalid conversion from 'gpointer' {aka 'void*'}
>  to 'FT_Face' {aka 'FT_FaceRec_*'}
> 
> during the lilypond compilation?  Is this really caused by pango?  Or
> is this a glib issue?  Could you investigate?

Pango 1.44 seems to have changed
the return type of pango_fc_font_lock_face () from FT_Face to gpointer.

https://gitlab.gnome.org/GNOME/pango/commit/fe3294ccf5a0b37c8a0950cc994ee0dfdd1dd909#594159b337483b122645586e446206f28d553b6e_56_52

LilyPond's lily/pango-font.cc has

```
FT_Face face = pango_fc_font_lock_face (fcfont);
```

If you use Pango 1.44,
the return type of pango_fc_font_lock_face () is different
from the variable type of face.

Here's a quick hack but I have not tried.

```
FT_Face face = static_cast(pango_fc_font_lock_face (fcfont));
```

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

Re: PDF docs for 2.19.82 broken/missing fonts

[Masamichi Hosoda]

Thank you for your logs.

If I understand correctly,
the time when the intermediate PDF (missing fonts) exist is extremely short.

e.g.
`input/regression/lilypond-book/suffix-tely.pdf`
in lilypond-doc.log

L1186  : texi2pdf   (intermeidate PDF suffix-tely.pdf is generated)
L1187  : extractpdfmark (PDFmark is extracted)
L1188-L1193: gs (final PDF suffix-tely.final.pdf is generated)
L1194  : rm (intermediate PDF suffix-tely.pdf is removed)
L1195  : mv (final PDF suffix-tely.final.pdf
 is renamed to suffix-tely.pdf)
L14091 : www_post   (copying document files to offline-root)
L14109 : rsync  (copying offline-root to lilypond-doc-2.19.82-root)
L14217 : tar(lilypond-2.19.81-1.documentation.tar.bz2
 is generated)

The intermediate PDF `suffix-tely.pdf` exists only between L1186 and L1194.
`suffix-tely.pdf` is copied to offline-root at L14091
which is quite later since the intermediate PDF has removed.

However, `suffix-tely.pdf` in lilypond-2.19.81-1.documentation.tar.bz2
is the intermediate PDF.

```
$ pdfinfo suffix-tely.pdf
Creator: XeTeX output 2018.06.24:1337
Producer:   xdvipdfmx (0.7.9)
CreationDate:   Sun Jun 24 21:37:54 2018 JST
...
```

In the other hand, non-English,
e.g. `Documentation/web.nl.pdf`
in lilypond-doc.log

L13134 : texi2pdf   (intermediate pdf web.pdf for nl is generated)
L13205 : extrectpdfmark (PDFmark is extracted)
L13208 : gs (final PDF web.final.pdf for nl is generated)
L13521 : rm (intermediate PDF web.pdf for nl is removed)
L13522 : mv (final PDF web.final.pdf for nl
 is renamed to web.pdf)
L13524 : cp (final PDF web.final.pdf for nl
 is copied to web.nl.pdf)
L14091 : www_post   (copying document files to offline-root)
L14109 : rsync  (copying offline-root to lilypond-doc-2.19.82-root)
L14217 : tar(lilypond-2.19.81-1.documentation.tar.bz2
 is generated)

The time between removing the intermediate PDF and copying to offline-root
is shorter than suffix-tely.pdf case.
However, `web.nl.pdf` in lilypond-2.19.81-1.documentation.tar.bz2
is the final PDF.

```
$ pdfinfo web.nl.pdf
Creator: XeTeX output 2018.06.24:1355
Producer:   GPL Ghostscript 9.21
CreationDate:   Sun Jun 24 21:55:44 2018 JST
ModDate:Sun Jun 24 21:55:44 2018 JST
...
```

I have no idea why the intermediate PDF that have removed beforehand remains.

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

Re: PDF docs for 2.19.82 broken/missing fonts

[Masamichi Hosoda]

> - Original Message - 
> From: "Knut Petersen" 
> 
>> Yes. notation.pdf looks as if extractpdfmark/gs was not used. But the
>> part of the build log Phil published clearly proves that
>> extractpdfmark and ghostscript were used.
> 
>> @Phil: If you have a look at the notation.pdf in the build tree: is
>> that file ok or is the same broken version as published on
>> lilypond.org?
> 
> 
> Please see the attached outcome from piping find to ls -l.  As you see
> the English notations vary in size, and the small ones lack the
> embedded fonts.

If I understand correctly,
at the end of `make doc`,
Documentation/out-www/notation.pdf
is copied to
out-www/online-root/Documentation/notation.pdf
and
out-www/offline-root/Documentation/notation.pdf
.
So the three files should all be the same file.
But, they are different files.

Would you show us the GUB's whole lilypond-doc log file?
If you preserve the 2.19.81 (Jan. 2018) lilypond-doc log file,
I'd like to compare the 2.19.82 log file (broken PDFs)
and the 2.19.81 log file (correct PDFs).

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

Re: PDF docs for 2.19.82 broken/missing fonts

[Masamichi Hosoda]

> 
> Masamichi-san?  Any idea?
> 
> Knut Petersen  writes:
> 
>> This problems seems to be related to 
>> https://codereview.appspot.com/314130043/
>>
>> The file http://lilypond.org/doc/v2.19/Documentation/notation.pdf seems to 
>> be  the intermediate version of notation.pdf.
>> pdfinfo shows:
>>
>>Creator: XeTeX output 2018.06.24:1343
>>Producer:   xdvipdfmx (0.7.9)
>>CreationDate:   Sun Jun 24 14:43:19 2018 CEST
>>
>> 'Producer: xdvipdfmx' is unxpected and definitely broken.
>>
>> The file http://lilypond.org/doc/v2.19/Documentation/notation.de.pdf is the 
>> expected final version of notation.de.pdf
>>  pdfinfo shows:
>>
>>Creator: XeTeX output 2018.06.24:1347
>>Producer:   GPL Ghostscript 9.21
>>CreationDate:   Sun Jun 24 14:47:40 2018 CEST
>>ModDate:    Sun Jun 24 14:47:40 2018 CEST
>>
>> The intermediate pdfs should have been processed with extractpdfmark
>> and ghostscript according to this snippet from texinfo-rules.make:
>>
>>$(outdir)/%.pdf: $(outdir)/%.texi $(outdir)/version.itexi 
>> $(outdir)/%.pdf.omf $(outdir)/weblinks.itexi | $(OUT_TEXINFO_MANUALS)
>>ifeq ($(WEB_VERSION),yes)
>>     PDFTEX=$(PDFTEX) PDFLATEX=$(PDFLATEX) 
>> $(buildscript-dir)/run-and-check "cd $(outdir); texi2pdf $(TEXI2PDF_FLAGS) 
>> -D web_version -I $(abs-src-dir) $(TEXINFO_PAPERSIZE_OPTION) $(> /dev/null" "$*.texi2pdf.log"
>>else
>>     PDFTEX=$(PDFTEX) PDFLATEX=$(PDFLATEX) 
>> $(buildscript-dir)/run-and-check "cd $(outdir); texi2pdf $(TEXI2PDF_FLAGS) 
>> -I $(abs-src-dir) $(TEXINFO_PAPERSIZE_OPTION) $(> "$*.texi2pdf.log"
>>endif
>>ifeq ($(USE_EXTRACTPDFMARK),yes)
>>     $(EXTRACTPDFMARK) -o $(outdir)/$*.pdfmark $@
>>     $(GS920) -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -dAutoRotatePages=/None 
>> -sOutputFile=$(outdir)/$*.final.pdf -c "3000 setvmthreshold" -f 
>> $(top-build-dir)/out-fonts/*.font.ps $(outdir)/$*.pdfmark $@
>>     rm $@
>>     mv $(outdir)/$*.final.pdf $@
>>endif
>>
>> Apparently that worked for notation.de.pdf but not for notation.pdf. Why? At 
>> the moment I don't see the reason, maybe it's too late.
>>
>> @Masamichi: Any idea ?
> 
> Any non-pattern rule overriding?  Stuff getting copied before being
> finished because of bad parallelism?  $@ stripping .de. stuff and
> similar so that everything is going through the same temporary file (not
> likely I guess) At any rate, it doesn't seem to be related to your
> recent patches.

If I understand correctly,

GUB generated correct PDFs for 2.19.81 in Jan. 2018.
extractpdfmark was used for generating PDFs of all languages including English.

http://lilypond.org/downloads/binaries/documentation/lilypond-2.19.81-1.documentation.tar.bz2

```
$ pdfinfo notation.pdf
Creator: XeTeX output 2018.01.28:1325
Producer:   GPL Ghostscript 9.21
CreationDate:   Sun Jan 28 22:25:13 2018 JST
ModDate:Sun Jan 28 22:25:13 2018 JST
...

$ pdfinfo notation.de.pdf
Creator: XeTeX output 2018.01.28:1333
Producer:   GPL Ghostscript 9.21
CreationDate:   Sun Jan 28 22:33:44 2018 JST
ModDate:Sun Jan 28 22:33:44 2018 JST
...
```

However, GUB generated broken PDFs for 2.19.82 in Jun. 2018.
extractpdfmark was used for generating non-English PDFs.
For English PDFs, extractpdfmark was not used.

http://lilypond.org/downloads/binaries/documentation/lilypond-2.19.82-1.documentation.tar.bz2

```
$ pdfinfo notation.pdf
Creator: XeTeX output 2018.06.24:1343
Producer:   xdvipdfmx (0.7.9)
CreationDate:   Sun Jun 24 21:43:19 2018 JST
...

$ pdfinfo notation.de.pdf
Creator: XeTeX output 2018.06.24:1347
Producer:   GPL Ghostscript 9.21
CreationDate:   Sun Jun 24 21:47:40 2018 JST
ModDate:Sun Jun 24 21:47:40 2018 JST
...
```

GUB has not been changed between Jan. and Jun.
Its last change is Aug. 2017.
https://github.com/gperciva/gub/commits/master

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

Re: GUI show messy unreadable code

[Masamichi Hosoda]

> Thanks for your patch,it work.Simplified Chinese menu is display normally.

Thank you for your report.

I've send pull request for LilyPad.
https://github.com/gperciva/lilypad/pull/11

After it is merged,
I'll create LilyPad source tarball and pull reqest for GUB.

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

Re: GUI show messy unreadable code

[Masamichi Hosoda]

>> Yes, it means Simplified Chinese.Thanks for your help!But Ver.2.19.65-1 is
>> broken either.
> 
> I prepared Simplified Chinese environment
> (Japanese Windows 10 + Simplified Chinese Language Pack).
> It reproduced in the environment.
> 
> I've created Issue 5177.
> https://sourceforge.net/p/testlilyissues/issues/5177/

I've created a patch that fixes the issue.
Would you try the following `lilypad.exe`?

https://sourceforge.net/p/testlilyissues/issues/5177/#56ba
https://sourceforge.net/p/testlilyissues/issues/_discuss/thread/6b4c86da/56ba/attachment/20170820-lilypad.zip

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

Re: GUI show messy unreadable code

[Masamichi Hosoda]

> Yes, it means Simplified Chinese.Thanks for your help!But Ver.2.19.65-1 is
> broken either.

I prepared Simplified Chinese environment
(Japanese Windows 10 + Simplified Chinese Language Pack).
It reproduced in the environment.

I've created Issue 5177.
https://sourceforge.net/p/testlilyissues/issues/5177/

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

Re: GUI show messy unreadable code

[Masamichi Hosoda]

> OS Language   中文(简体，中国)
> OS Installer Language 中文(简体，中国)

If I understand correctly, it means Simplified Chinese. Correct?
Most people in bug-lilypond@gnu.org cannot understand CJK letters.

Anyway, old LilyPad (LilyPond editor for Windows) has an issue
that is CJK strings are broken.
https://sourceforge.net/p/testlilyissues/issues/431/

Would you try newest unstable LilyPond (e.g. 2.19.65)
instead of stable LilyPond (e.g. 2.18.2)?
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: bugs in web.pdf

[Masamichi Hosoda]

> If I understand correctly, there are two different problems.
> 
> The former one is that XeTeX does not support `/Rotate`.
> It occurs in both your environment and the GUB environment.
> 
[...snip...]
> 
> But, the former one seems to be difficult to solve.

I've created the patch to solve the former one.
https://sourceforge.net/p/testlilyissues/issues/5128/

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

Re: bugs in web.pdf

[Masamichi Hosoda]

>> - PDF page 10 is in landscape (while the document is a regular A4 of
>> - course)
>> 
> 
> This is the actual bug. I've investigated...
> If you replace v2.19 with previous versions you can see that previous
> builds used PdfTex instead of Xetex and the image was compressed to
> fit on the vertical A4 sheet.
> 
> What's interesting is that my locally compiled web.pdf (with Xetex
> version 2017.03.30:1237) displays page 10 almost correctly, in that
> the page stays A4 vertical but the image is rotated 90°
> counter-clockwise. See attached the extracted page.
> web.pdf on lilypond.org was built with a more recent version of Xetex.
> 
> Masamichi, any idea of what's going on?

In my investigate, if I understand correctly,
`Documentation/ly-example/granados.ly` has landscape settings.
So `granados.pdf` generated from `granados.ly` has `/Rotate 90`.

pdfTeX supports `/Rotate` in including PDFs.
Unfortunately, XeTeX does not support it.
http://tug.org/pipermail/xetex/2015-November/026197.html

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

Re: Coloring broken in Lily 2.19.51? (PNG alpha-transparency coloring is broken)

[Masamichi Hosoda]

>> If master is ok, but not the released version, it's more likely a
>> GUB-problem as David suspected.
>> Maybe Masimichi-San can could say more, cc-ed.
> 
> Between LilyPond 2.19.50 and 2.19.51,
> Ghostscript bundled with the binary distributed on lilypond.org
> has been updated.
> 
> 2.19.50 has Ghostscript 9.15.
> 2.19.51 has Ghostscript 9.20.
> (Also 2.19.52 has Ghostscript 9.20.)
> 
> I've tried some versions.
> 
> LilyPond 2.19.49 + Ghostscript 9.15:
>   no problem.
> 
> LilyPond 2.19.49 + Ghostscript 9.16:
>   no problem.
> 
> LilyPond 2.19.49 + Ghostscript 9.18:
>   no problem.
> 
> LilyPond 2.19.49 + Ghostscript 9.19:
>   reproduced.
> 
> LilyPond 2.19.49 + Ghostscript 9.20:
>   reproduced.
> 
> LilyPond 2.19.52 + Ghostscript 9.18:
>   no problem.
> 
> LilyPond 2.19.52 + Ghostscript 9.19:
>   reproduced.
> 
> LilyPond 2.19.52 + Ghostscript 9.20:
>   reproduced.

I've reported it to Ghostscript Bugzilla.
http://bugs.ghostscript.com/show_bug.cgi?id=697423

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

Re: Coloring broken in Lily 2.19.51? (PNG alpha-transparency coloring is broken)

[Masamichi Hosoda]

> If master is ok, but not the released version, it's more likely a
> GUB-problem as David suspected.
> Maybe Masimichi-San can could say more, cc-ed.

Between LilyPond 2.19.50 and 2.19.51,
Ghostscript bundled with the binary distributed on lilypond.org
has been updated.

2.19.50 has Ghostscript 9.15.
2.19.51 has Ghostscript 9.20.
(Also 2.19.52 has Ghostscript 9.20.)

I've tried some versions.

LilyPond 2.19.49 + Ghostscript 9.15:
  no problem.

LilyPond 2.19.49 + Ghostscript 9.16:
  no problem.

LilyPond 2.19.49 + Ghostscript 9.18:
  no problem.

LilyPond 2.19.49 + Ghostscript 9.19:
  reproduced.

LilyPond 2.19.49 + Ghostscript 9.20:
  reproduced.

LilyPond 2.19.52 + Ghostscript 9.18:
  no problem.

LilyPond 2.19.52 + Ghostscript 9.19:
  reproduced.

LilyPond 2.19.52 + Ghostscript 9.20:
  reproduced.

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

Re: Lilypond taking forever to typeset

[Masamichi Hosoda]

>> Also it might be interesting where it happens.  Perhaps run it under a
>> debugger, give it a C-c during its long delay and then take a look at
>> the resulting backtrace to see where LilyPond is when the delay happens?
> 
> The main problem is: I need an idea of where to start looking for the
> font cache (or repeat the experiment on a clean machine). Unless I
> delete the cache, I'm unable to reproduce the problem.
> 
> If I just switch from 2.18 to 2.19 or if I delete 2.19 and install it
> again from scratch, I'm not able to reproduce the behaviour, so the
> font cache is obviously not in the folder with LilyPond.app.

I'm not familiar with OSX.
But if I understand correctly,

If you use the binary which is downloaded from LilyPond website,
fontconfig cache directory is `~/.lilypond-fonts.cache-2`.
So you can delete the cache by the following command.

$ rm -fr ~/.lilypond-fonts.cache-2

If you use other binaries (e.g. MacPorts),
fontconfig cache directory may be `~/.cache/fontconfig` and/or `~/.fontconfig`.

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

Re: Lilypond taking forever to typeset

[Masamichi Hosoda]

> I've noticed this one-time startup delay as well on Windows (7 and 8) and
> found that it got triggered anytime I changed the contents of the system
> font folder (C:\Windows\Fonts), whether adding or deleting a file. At the
> next time of compiling a LilyPond file, a new font-cache database would be
> created in "C:\Users\[MYUSERNAME]\.lilypond-fonts.cache-2" (note the
> initial period in the directory name). If I clear the contents of this
> folder, the initial delay comes up again to create a new database file. I
> suspect that this directory can be found across OSs in a similar location
> in the user's main directory, but I haven't confirmed this.

For the LilyPond website binary (GUB-generated binary),
fontconfig cache directory is `~/.lilypond-fonts.cache-2`.

https://github.com/gperciva/gub/blob/87efb1105d976dfbecf8f3c9c6c9c869a2158bbb/gub/specs/lilypond.py#L130

For other binaries,
fontconfig cache directory seems to be the default of fontconfig.
e.g. `~/.cache/fontconfig` etc.

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

Re: Header fonts

[Masamichi Hosoda]

> That's a rather bad problem.  We usually have a two-week schedule of
> developer releases.  When you find a really bad regression like that, it
> makes sense to indicate its urgency and decide between
> 
> a) revert the patch causing the problem, and then create a new patch
> reintroducing the change in a fixed manner
> b) speed up the submission of the followup patch and not waiting for the
> regular countdown.
> 
> When the fix is quite simple (like a typo or a very obvious oversight
> needing very little code), option b) is likely the easiest.  Otherwise
> it makes sense to go via route a).
> 
> Also, when submitting an issue like 4918, you should label it as
> category "Regression" when it is a recently introduced problem and state
> explicitly which patch/issue (if known) introduced the problem.  Only
> then will it be obvious to others what the consequences may be and
> whether they should suggest to you or the Patch meister how to best deal
> with this particular problem.

Sorry.

I did not notice that it has such affected.
I thought it was a trivial issue of EPS output only.

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

Re: Header fonts

[Masamichi Hosoda]

> Fonts for the header fields are not set correctly for the second and
> subsequent books in a file.
> 
> Pre-built version 2.19.45, 64-bit Linux.

It will be fixed by Issue 4918.
https://sourceforge.net/p/testlilyissues/issues/4918/

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

Re: Ghostscript crashes on Japanese characters on Ubuntu 16.04

[Masamichi Hosoda]

[...snip...]
> After deleting the the noto font (rm -r
> /usr/share/fonts/opentype/noto/), everything works fine.
> 
> The font noto was not part of ubuntu Desktop 14.04 64 Bit, I've checked
> that.
> 
> I have no idea, what might be wrong with this font, ghostscript or
> lilypond. However, deleting the font is a workaround.

Maybe, your Noto Sans CJK font is OTC (OpenType Collection) font.
https://www.google.com/get/noto/help/cjk/

If I understand correctly,
Ghostscript cannot handle OTC font because it is new format.

You can use `Region specific OTF subset' version Noto Sans CJK fonts
because they are not OTC fonts.

Or, you can use other Japanese fonts by the following commands.

$ sudo apt-get install fonts-ipafont-mincho
$ sudo apt-get install fonts-ipafont-gothic
$ sudo apt-get install fonts-ipaexfont-mincho
$ sudo apt-get install fonts-ipaexfont-gothic

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

Re: Install confirmation test file misleading

[Masamichi HOSODA]

>> Sorry, I should be more precise.
>> It appears that the process of dragging the test file over the LP icon
>> is
>> not working for me. Despite the shortcut path being correct. The
>> install is
>> fine.
>>
>>
> 
> Which version of Windows? This drag-n-drop feature was originally
> documented by myself when I used to use Windows 7, I've never tried it
> since using Windows 8.x (or 10.x).

If I understand correctly,
it is because the current directory of the LilyPond's shortcut is
set to the all users desktop (C:\Users\Public\Desktop).

The all users desktop can be written only with administrator privileges.
LilyPond writes PDF etc. to the current directory.
Usually, it can not write because it does not have administrator privileges.

One of the following can be workaroud.
  Double click *.ly file instead of drag-and-drop to LilyPond shortcut.
  Empty current directory settings instead of C:\Users\Public\Desktop.

Both of them, LilyPond will write PDF etc. to the same directory
as the *.ly file.

I don't have English Windows,
but perhaps, current directory settings in English Windows is
``Start in'' in shortcut properties.

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

Re: PNG output cannot be created with Mac OS X version of Lilipond 2.18.2-1

[Masamichi HOSODA]

I not familiar with OSX.
Maybe the gs that is contained in lilypond-2.18.2 for OSX has an issue.

https://lists.gnu.org/archive/html/bug-lilypond/2015-11/msg00045.html

If I understand correctly, development version has been fixed the issue.
Would you try lilypond-2.19.35?

> Hi Andrew,
> 
> I’ve realized that the libgs.8.70.dylib is included in the Lilypond 
> application bundle as:
> 
> /Applications/LilyPond.app/Contents/Resources/lib/libgs.8.70.dylib
> 
> Best regards,
> 
> Jun
> 
>> 2016/01/03 21:19、田村 淳  のメール：
>> 
>> Hi Andrew,
>> 
>> Thanks for really prompt reply.
>> 
>> I’m running Mac OS X 10.11.2.
>> 
>> I frist noticed this issue while trying to use the OOoLilyPond extension for 
>> OpenOffice/LibreOffice. Then I tried something similar from within 
>> Frescobaldi. Finally I tried it from the Terminal, as I reported, and the 
>> result was essentially the same. The error messages from the 3 methods above 
>> were essentially the same:
>> 
>> Converting to PNG...dyld: Library not loaded: ./bin/../sobin/libgs.8.70.dylib
>>  Referenced from: /Applications/LilyPond.app/Contents/Resources/bin/../bin/gs
>>  Reason: image not found
>> 
>> fatal error: GS exited with status: 5
>> 
>> I thought that /Applications/LilyPond.app/Contents/Resources/bin//gs might 
>> be trying to load libgs from wrong location 
>> (./bin/../sobin/libgs.8.70.dylib).
>> 
>> Best regards,
>> 
>> Jun
>> 
>>> 2016/01/03 18:44、Andrew Bernard  のメール：
>>> 
>>> Hi Jun,
>>> 
>>> What version of Mac OS X are you on? Current version 10.11.2 provides 
>>> libgs.9.16.dylib.
>>> 
>>> Andrew

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

Re: lilypond-book: "external" fonts and --pdf option problem

[Masamichi HOSODA]

>> Thank you for finding this. I'm wondering if there is a more generic way to
>> identify third-party fonts rather than hard-coding it like this? Perhaps by
>> checking if the font has the LILY, LILC, and LILF subtables? I'm just
>> brain-storming...
> 
> How about following patch?
> 
> In the case of text font, variable `font' is set to #f.
> In the case of music font, variable `font' is set to non-#f.

I've created issue 4701.

http://sourceforge.net/p/testlilyissues/issues/4701/
https://codereview.appspot.com/284830043

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

Re: lilypond-book: "external" fonts and --pdf option problem

[Masamichi HOSODA]

> Thank you for finding this. I'm wondering if there is a more generic way to
> identify third-party fonts rather than hard-coding it like this? Perhaps by
> checking if the font has the LILY, LILC, and LILF subtables? I'm just
> brain-storming...

How about following patch?

In the case of text font, variable `font' is set to #f.
In the case of music font, variable `font' is set to non-#f.


```
diff --git a/scm/framework-ps.scm b/scm/framework-ps.scm
index 60d7bb3..f6d1700 100644
--- a/scm/framework-ps.scm
+++ b/scm/framework-ps.scm
@@ -246,10 +246,15 @@
footer)))
 
 (define (write-preamble paper load-fonts? port)
-  (define (internal-font? file-name)
-(or (string-startswith file-name "Emmentaler")
-(string-startswith file-name "emmentaler")
-))
+  (define (internal-font? font-name-filename)
+(let* ((font (car font-name-filename))
+   (file-name (caddr font-name-filename))
+   (font-file-name (ly:find-file (format #f "~a.otf" file-name
+  (and font
+   (cff-font? font)
+   font-file-name
+   (string-contains font-file-name
+(ly:get-option 'datadir)
 
   (define (load-font-via-GS font-name-filename)
 (define (ps-load-file file-name)
@@ -272,7 +277,7 @@
 (if (mac-font? bare-file-name)
 (handle-mac-font name bare-file-name)
 (cond
- ((internal-font? file-name)
+ ((and font (cff-font? font))
   (ps-load-file (ly:find-file
  (format #f "~a.otf" file-name
  ((string? bare-file-name)
@@ -402,7 +407,7 @@
 ((ly:get-option 'gs-load-lily-fonts)
  (if (or (string-contains (caddr name)
   (ly:get-option 'datadir))
- (internal-font? (caddr name)))
+ (internal-font? name))
  (load-font-via-GS name)
  (load-font name)))
 (else
```

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

Re: lilypond-book: "external" fonts and --pdf option problem

[Masamichi HOSODA]

Hi

If I understand correctly,
the cause is lilypond's `-dgs-load-fonts' option
with non-emmentaler music font.

I've reproduced the issue with the following smaller example.

```
$ cat foobar.ly
{ c'' }
\paper {
  #(define fonts
(set-global-fonts
 #:music "improviso"
   ))
}

$ lilypond -dgs-load-fonts foobar.ly
GNU LilyPond 2.19.28
Processing `foobar.ly'
Parsing...
foobar.ly:1: warning: no \version statement found, please add

\version "2.19.28"

for future compatibility
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `/tmp/lilypond-wiLRqX'...
warning: cannot embed "improviso-20"="improviso-20"
Converting to `foobar.pdf'...
Deleting `/tmp/lilypond-wiLRqX'...
Success: compilation successfully completed

$
```

Of course, it has no error without `-dgs-load-fonts' option.
Here is a quick hack patch for the issue.

```
--- framework-ps.scm.org2015-09-27 21:01:25.0 +0900
+++ framework-ps.scm2015-12-10 22:03:53.743514600 +0900
@@ -249,6 +249,7 @@
   (define (internal-font? file-name)
 (or (string-startswith file-name "Emmentaler")
 (string-startswith file-name "emmentaler")
+(string-startswith file-name "improviso")
 ))
 
   (define (load-font-via-GS font-name-filename)
```

> 2015-12-09 15:10 GMT+02:00 tisimst :
>> Dmytro,
>>
>> Sorry for my delayed comment. I don't know what is causing this, but I've
>> seen this come up before from other users. I'm excited to see you like
>> Improviso! I hope we can get this figured out.
> Abraham,
> yes, I like it very much, THANK you :)
> 
> When I insert some (display ...)'s into framework-ps.scm I can see
> that ly:find-file fails to find font-file with --pdf option for some
> reason.
> 
> Ok, as you can see, I can be wrong! Don't mind, please :)
> 
> Now I've simply added "fallback" workaround:
> 
> --- framework-ps.scm.orig   2015-12-08 10:44:54.293262621 +0200
> +++ framework-ps.scm2015-12-08 12:07:52.786888984 +0200
> @@ -237,16 +237,18 @@
>  (let* ((font (car font-name-filename))
> (name (cadr font-name-filename))
> (file-name (caddr font-name-filename))
> -   (bare-file-name (ly:find-file file-name)))
> +   (bare-file-name (ly:find-file file-name))
> +   (font-file-name (ly:find-file (format #f "~a.otf" file-name
>(cons name
>  (if (mac-font? bare-file-name)
>  (handle-mac-font name bare-file-name)
>  (cond
>   ((internal-font? file-name)
> -  (ps-load-file (ly:find-file
> - (format #f "~a.otf" file-name
> +  (ps-load-file font-file-name))
>   ((string? bare-file-name)
>(ps-load-file file-name))
> + ((string? font-file-name)
> +  (ps-load-file font-file-name))
>   (else
>(ly:warning (_ "cannot embed ~S=~S") name file-name)
>""))
> 
> -- 
>   Dmytro O. Redchuk

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

Re: Cannot locate libffi.so.6 on openSUSE Leap 42.1

[Masamichi HOSODA]

> The downloadable version of lilypond 2.19.32 will not run on openSUSE Leap 
> 42.1 as it is unable to find libffi.so.6, which is not installed on this OS.
> 
> The lilypond distribution includes this shared library in its usr/lib64 
> directory. But the installer script only creates a lilypond wrapper start 
> script referencing usr/lib and not usr/lib64:
> 
> #!/bin/sh
> me=`basename $0`
> #export LD_LIBRARY_PATH="/home/andro/lilypond/usr/lib"
> export 
> LD_LIBRARY_PATH="/home/andro/lilypond/usr/lib:/home/andro/lilypond/usr/lib64"
> exec "/home/andro/lilypond/usr/bin/$me" "$@"
> 
> 
> If I add the lib64 directory as above, which contains libffi.so.6 all is well.
> 
> Why does the installer script omit the lib64 directory?
> 
> This is a defect because users of the downloadable lilypond cannot run it on 
> openSUSE.
> 
> Andrew

libffi.so.6 should be on usr/lib instead of usr/lib64.
Maybe it is a GUB's issue.
(GUB is LilyPond official binary building tool.)

I'm creating the patch for GUB that will fix the issue.

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

Re: Cannot locate libffi.so.6 on openSUSE Leap 42.1

[Masamichi HOSODA]

>> The downloadable version of lilypond 2.19.32 will not run on openSUSE Leap 
>> 42.1 as it is unable to find libffi.so.6, which is not installed on this OS.
>> 
>> The lilypond distribution includes this shared library in its usr/lib64 
>> directory. But the installer script only creates a lilypond wrapper start 
>> script referencing usr/lib and not usr/lib64:
>> 
>> #!/bin/sh
>> me=`basename $0`
>> #export LD_LIBRARY_PATH="/home/andro/lilypond/usr/lib"
>> export 
>> LD_LIBRARY_PATH="/home/andro/lilypond/usr/lib:/home/andro/lilypond/usr/lib64"
>> exec "/home/andro/lilypond/usr/bin/$me" "$@"
>> 
>> 
>> If I add the lib64 directory as above, which contains libffi.so.6 all is 
>> well.
>> 
>> Why does the installer script omit the lib64 directory?
>> 
>> This is a defect because users of the downloadable lilypond cannot run it on 
>> openSUSE.
>> 
>> Andrew
> 
> libffi.so.6 should be on usr/lib instead of usr/lib64.
> Maybe it is a GUB's issue.
> (GUB is LilyPond official binary building tool.)
> 
> I'm creating the patch for GUB that will fix the issue.

I've created issue 4669.
http://sourceforge.net/p/testlilyissues/issues/4669/

I'm checking the patch.
I'll pull request it.

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

Re: strange result for escaping "\" with other font-name

[Masamichi HOSODA]

>> >>> >> > trying to escape "\" in a string leads to strange results, for some
>> >>> >> > font-names.
>> >>> >> > Example below was ok with 2.18.2
>> >>> >> >
>> >>> >> > \version "2.19.26"
>> >>> >> >
>> >>> >> > \markup \override #'(font-name . "Times New Roman") "\\<==what?"
>> >>> >>
>> >>> >> The displayed font is definitely not `Times New Roman'.  It seems
>> >>> >that
>> >>> >> the font substituted by FontConfig is a CJK font using half-width
>> >>> >> glyphs, and there it sometimes happens that the `\' slot gets
>> >>> >replaced
>> >>> >> with the Yen sign `¥', for compatibility with ancient Japanese
>> >>> >> practice.
>> >>> >>
>> >>> >
>> >>> >Agreed, so far.
>> >>> >
>> >>> >>
>> >>> >> I think there is nothing to be done here, since it displays a font
>> >>> >> problem (or bug).
>> >>> >>
>> >>> >
>> >>> >Though, if 2.18.2 displays nicely (and it does), I'd tend to think
>> >>> >something on our part causes this misbehahiour.
>> >>> >(Ofcourse "Times New Roman" _is_ installed)
>> >>> >
>> >>> >Cheers,
>> >>> >  Harm
>> >>> >___
>> >>> >bug-lilypond mailing list
>> >>> >bug-lilypond@gnu.org
>> >>> >https://lists.gnu.org/mailman/listinfo/bug-lilypond
>> >>>
>> >>> Would you show us both 2.18.2 and 2.19.26 results of following command?
>> >>>
>> >>> $ FC_DEBUG=1 lilypond --verbose fonts-test-01.ly > result.txt 2>&1
>> >>>
>> >>
>> >> Will do in the evening. Have to run for my rl job :(
>> >>
>> >
>> > Got a spare minute.
>> >
>> > Remark: I always rename latest devel-version to lilydevel
> 
> 
> Many thanks for your time looking into this.
> 
>>
>>
>> Perhaps, it has two problems.
>>
>> First, both 2.18.2 and 2.19.26, fontconfig is requested "Times New" font,
>> instead of "Times New Roman".
>> Ofcourse, "Times New" font does not exist.
>> So fontconfig finds substitute font.
> 
> 
> Indeed very interesting that it can be done inserting the comma
> 
> \version "2.19.26"
> 
> \markup \override #'(font-name . "Times New Roman,") "\\<==what?"
> 
> http://sourceforge.net/p/testlilyissues/issues/4591/
> 
> Meanwhile I've found
> http://code.google.com/p/lilypond/issues/detail?id=699
> 
> Obviously it worked some time in the past, than not, than again 

If I understand correctly,

Pango 1.23.0 (2009-02-03) was added "Roman" style.
https://git.gnome.org/browse/pango/commit/pango/fonts.c?id=b072c3353cc2d10d6b26fb86cb13694a967a59cd
https://git.gnome.org/browse/pango/commit/pango/fonts.c?id=07992d0e2c7cca25032aeac650c847a905079b23

So Pango 1.22.4 (2008-12-15) and below versions did not have "Roman" style.

Issue 699
http://sourceforge.net/p/testlilyissues/issues/699/
was reported 2008-10-24.

In other words, Pango at the time did not have "Roman" style.
So "Times New Roman" was interpreted "Times New Roman" font family
and no styles.

>> Second, your 2.19.26's fontconfig configure files
>> do not seem to have substitute settings.
> 
> It's not clear to me why this happens. Is it a LilyPond-problem or
> something at my part?
> With 2.18.2 and 2.19.26 I'm on a 64-bit LINUX
> Trying with a build from master, lilyDev (32bit Debian), I do get
> substitute settings
> 
> If I try
> \version "2.19.26"
> \markup \override #'(font-name . "not existing font") "\\<==what?"
> 
> I do get substitute settings as well.

According to the log file, your 2.19.26's fontconfig
default top configure file is
/home/hermann/lilydevel/usr/etc/fonts/fonts.conf

And, maybe,
/home/hermann/lilydevel/usr/etc/fonts/local.conf
/home/hermann/lilydevel/usr/etc/fonts/conf.d/*.conf
are fontconfig auxiliary configure files.

Your 2.18.2's one are
/home/hermann/lilypond/usr/etc/fonts/fonts.conf
/home/hermann/lilypond/usr/etc/fonts/local.conf
/home/hermann/lilypond/usr/etc/fonts/conf.d/*.conf

Would you compare them?

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

Re: strange result for escaping "\" with other font-name

[Masamichi HOSODA]

 Second, your 2.19.26's fontconfig configure files
 do not seem to have substitute settings.
>>>
>>> It's not clear to me why this happens. Is it a LilyPond-problem or
>>> something at my part?
>>> With 2.18.2 and 2.19.26 I'm on a 64-bit LINUX
>>> Trying with a build from master, lilyDev (32bit Debian), I do get
>>> substitute settings
>>>
>>> If I try
>>> \version "2.19.26"
>>> \markup \override #'(font-name . "not existing font") "\\<==what?"
>>>
>>> I do get substitute settings as well.
>>
>> According to the log file, your 2.19.26's fontconfig
>> default top configure file is
>> /home/hermann/lilydevel/usr/etc/fonts/fonts.conf
>>
>> And, maybe,
>> /home/hermann/lilydevel/usr/etc/fonts/local.conf
>> /home/hermann/lilydevel/usr/etc/fonts/conf.d/*.conf
>> are fontconfig auxiliary configure files.
>>
>> Your 2.18.2's one are
>> /home/hermann/lilypond/usr/etc/fonts/fonts.conf
>> /home/hermann/lilypond/usr/etc/fonts/local.conf
>> /home/hermann/lilypond/usr/etc/fonts/conf.d/*.conf
>>
>> Would you compare them?
>
> I don't have the skills to appraise what I see.
> Here's a simple diff. Is this sufficient?
>
> diff /home/hermann/lilydevel/usr/etc/fonts/fonts.conf
> /home/hermann/lilypond/usr/etc/fonts/fonts.conf
> 28,29d27
> < fonts
> < 
> 39c37
> < 
> ---
>> 
> 51c49
> < 
> ---
>> 
> 63c61
> < 
> ---
>> 
> 76,77d73
> < fontconfig
> < 

 Would you try following command?

 $ diff -ursN /home/hermann/lilydevel/usr/etc/fonts 
 /home/hermann/lilypond/usr/etc/fonts
>>>
>>> I did
>>> diff -ursN /home/hermann/lilydevel/usr/etc/fonts
>>> /home/hermann/lilypond/usr/etc/fonts > log.txt 2>&1
>>>
>>> last line reads:
>>> Files /home/hermann/lilydevel/usr/etc/fonts/local.conf and
>>> /home/hermann/lilypond/usr/etc/fonts/local.conf are identical
>>>
>>> Do you need the entire file (it has 2000 lines)?
>>
>> Yes, please.
>
> Here you are

 Thank you.

 It seems to lack the necessary files.
 How do you install 2.19.26?
>>>
>>> I download
>>> lilypond-2.19.26-1.linux-64.sh
>>> from
>>> http://lilypond.org/development.html
>>> navigate to Desktop (where it is stored) and then:
>>> sh lilypond-2.19.26-1.linux-64.sh
>>>

 Do following files exist?
 /home/hermann/lilydevel/usr/etc/fonts/conf.avail/*.conf
>>>
>>> No !!
>>>
 /home/hermann/lilydevel/usr/etc/fonts/conf.d/*.conf
>>>
>>> yes
>>>

 If not, would you try to re-install LilyPond?

 Or, would you try to install official web site's LilyPond 2.19.26 binary?
>>>
>>> I uninstalled it and re-installed it, with a fresh download of
>>> lilypond-2.19.26-1.linux-64.sh
>>> (refusing to rename it for now)
>>> exercising  all the steps listed above.
>>>

 And, just idea,
 it might be solved by copying official binary's
 lilypond/usr/etc/fonts/*
 files to
 /home/hermann/lilydevel/usr/etc/fonts/
 .
>>>
>>> Not sure what exactly you suggest.
>>> I tried to copy/paste conf.avail from 2.18.2 to 2.19.26
>>> The issue persists, though.
>>>
>>> Obviously conf.avail is missing for me with 2.19.26. If it's my
>>> problem then it's bad, but if it's a general problem for 64-bit-Linux
>>> then it's worse.
>>>
>>> Best would be others with 64-bit Linux could do testing for:
>>>
>>> \version "2.19.26"
>>> \markup \override #'(font-name . "not a font") "\\<==what?"
>>>
>>>
>>> or look, whether
>>> lilypond/usr/etc/fonts/conf.avail/*.conf
>>> exists at all.
>>
>> I've tried to install official 2.19.26.
>> I've found GUB's problem.
>>
>> I understand correctly,
>> Most platform's 2.19.26 official binaries have this problem.
>> Only mingw (Windows) platform does not have this problem.
>>
>> The cause is that fontconfig conf files symbolic links are absolute path.
>> Installed directory is different in each environment.
>> So absolute path can not find link destination.
>>
>> Windows can not handle symbolic links.
>> Symbolic link is not used. conf files are copied.
>> So installed conf files are exist. It's no problem.
>>
>> To fix installed LilyPond is here.
>>
>> cd lilypond/usr/etc/fonts/conf.d
>> rm -fr *.conf
>> ln -s ../../../share/fontconfig/conf.avail/10-scale-bitmap-fonts.conf
>> ln -s ../../../share/fontconfig/conf.avail/20-unhint-small-vera.conf
>> ln -s ../../../share/fontconfig/conf.avail/30-metric-aliases.conf
>> ln -s ../../../share/fontconfig/conf.avail/30-urw-aliases.conf
>> ln -s 

Re: strange result for escaping "\" with other font-name

[Masamichi HOSODA]

 Second, your 2.19.26's fontconfig configure files
 do not seem to have substitute settings.
>>>
>>> It's not clear to me why this happens. Is it a LilyPond-problem or
>>> something at my part?
>>> With 2.18.2 and 2.19.26 I'm on a 64-bit LINUX
>>> Trying with a build from master, lilyDev (32bit Debian), I do get
>>> substitute settings
>>>
>>> If I try
>>> \version "2.19.26"
>>> \markup \override #'(font-name . "not existing font") "\\<==what?"
>>>
>>> I do get substitute settings as well.
>>
>> According to the log file, your 2.19.26's fontconfig
>> default top configure file is
>> /home/hermann/lilydevel/usr/etc/fonts/fonts.conf
>>
>> And, maybe,
>> /home/hermann/lilydevel/usr/etc/fonts/local.conf
>> /home/hermann/lilydevel/usr/etc/fonts/conf.d/*.conf
>> are fontconfig auxiliary configure files.
>>
>> Your 2.18.2's one are
>> /home/hermann/lilypond/usr/etc/fonts/fonts.conf
>> /home/hermann/lilypond/usr/etc/fonts/local.conf
>> /home/hermann/lilypond/usr/etc/fonts/conf.d/*.conf
>>
>> Would you compare them?
> 
> I don't have the skills to appraise what I see.
> Here's a simple diff. Is this sufficient?
> 
> diff /home/hermann/lilydevel/usr/etc/fonts/fonts.conf
> /home/hermann/lilypond/usr/etc/fonts/fonts.conf
> 28,29d27
> < fonts
> < 
> 39c37
> < 
> ---
>> 
> 51c49
> < 
> ---
>> 
> 63c61
> < 
> ---
>> 
> 76,77d73
> < fontconfig
> < 

Would you try following command?

$ diff -ursN /home/hermann/lilydevel/usr/etc/fonts 
/home/hermann/lilypond/usr/etc/fonts

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

Re: strange result for escaping "\" with other font-name

[Masamichi HOSODA]

 Second, your 2.19.26's fontconfig configure files
 do not seem to have substitute settings.
>>>
>>> It's not clear to me why this happens. Is it a LilyPond-problem or
>>> something at my part?
>>> With 2.18.2 and 2.19.26 I'm on a 64-bit LINUX
>>> Trying with a build from master, lilyDev (32bit Debian), I do get
>>> substitute settings
>>>
>>> If I try
>>> \version "2.19.26"
>>> \markup \override #'(font-name . "not existing font") "\\<==what?"
>>>
>>> I do get substitute settings as well.
>>
>> According to the log file, your 2.19.26's fontconfig
>> default top configure file is
>> /home/hermann/lilydevel/usr/etc/fonts/fonts.conf
>>
>> And, maybe,
>> /home/hermann/lilydevel/usr/etc/fonts/local.conf
>> /home/hermann/lilydevel/usr/etc/fonts/conf.d/*.conf
>> are fontconfig auxiliary configure files.
>>
>> Your 2.18.2's one are
>> /home/hermann/lilypond/usr/etc/fonts/fonts.conf
>> /home/hermann/lilypond/usr/etc/fonts/local.conf
>> /home/hermann/lilypond/usr/etc/fonts/conf.d/*.conf
>>
>> Would you compare them?
>
> I don't have the skills to appraise what I see.
> Here's a simple diff. Is this sufficient?
>
> diff /home/hermann/lilydevel/usr/etc/fonts/fonts.conf
> /home/hermann/lilypond/usr/etc/fonts/fonts.conf
> 28,29d27
> < fonts
> < 
> 39c37
> < 
> ---
>> 
> 51c49
> < 
> ---
>> 
> 63c61
> < 
> ---
>> 
> 76,77d73
> < fontconfig
> < 

 Would you try following command?

 $ diff -ursN /home/hermann/lilydevel/usr/etc/fonts 
 /home/hermann/lilypond/usr/etc/fonts
>>>
>>> I did
>>> diff -ursN /home/hermann/lilydevel/usr/etc/fonts
>>> /home/hermann/lilypond/usr/etc/fonts > log.txt 2>&1
>>>
>>> last line reads:
>>> Files /home/hermann/lilydevel/usr/etc/fonts/local.conf and
>>> /home/hermann/lilypond/usr/etc/fonts/local.conf are identical
>>>
>>> Do you need the entire file (it has 2000 lines)?
>>
>> Yes, please.
> 
> Here you are

Thank you.

It seems to lack the necessary files.
How do you install 2.19.26?

Do following files exist?
/home/hermann/lilydevel/usr/etc/fonts/conf.avail/*.conf
/home/hermann/lilydevel/usr/etc/fonts/conf.d/*.conf

If not, would you try to re-install LilyPond?
Or, would you try to install official web site's LilyPond 2.19.26 binary?

And, just idea,
it might be solved by copying official binary's
lilypond/usr/etc/fonts/*
files to
/home/hermann/lilydevel/usr/etc/fonts/
.

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

Re: strange result for escaping "\" with other font-name

[Masamichi HOSODA]

>> Second, your 2.19.26's fontconfig configure files
>> do not seem to have substitute settings.
>
> It's not clear to me why this happens. Is it a LilyPond-problem or
> something at my part?
> With 2.18.2 and 2.19.26 I'm on a 64-bit LINUX
> Trying with a build from master, lilyDev (32bit Debian), I do get
> substitute settings
>
> If I try
> \version "2.19.26"
> \markup \override #'(font-name . "not existing font") "\\<==what?"
>
> I do get substitute settings as well.

 According to the log file, your 2.19.26's fontconfig
 default top configure file is
 /home/hermann/lilydevel/usr/etc/fonts/fonts.conf

 And, maybe,
 /home/hermann/lilydevel/usr/etc/fonts/local.conf
 /home/hermann/lilydevel/usr/etc/fonts/conf.d/*.conf
 are fontconfig auxiliary configure files.

 Your 2.18.2's one are
 /home/hermann/lilypond/usr/etc/fonts/fonts.conf
 /home/hermann/lilypond/usr/etc/fonts/local.conf
 /home/hermann/lilypond/usr/etc/fonts/conf.d/*.conf

 Would you compare them?
>>>
>>> I don't have the skills to appraise what I see.
>>> Here's a simple diff. Is this sufficient?
>>>
>>> diff /home/hermann/lilydevel/usr/etc/fonts/fonts.conf
>>> /home/hermann/lilypond/usr/etc/fonts/fonts.conf
>>> 28,29d27
>>> < fonts
>>> < 
>>> 39c37
>>> < 
>>> ---
 
>>> 51c49
>>> < 
>>> ---
 
>>> 63c61
>>> < 
>>> ---
 
>>> 76,77d73
>>> < fontconfig
>>> < 
>>
>> Would you try following command?
>>
>> $ diff -ursN /home/hermann/lilydevel/usr/etc/fonts 
>> /home/hermann/lilypond/usr/etc/fonts
> 
> I did
> diff -ursN /home/hermann/lilydevel/usr/etc/fonts
> /home/hermann/lilypond/usr/etc/fonts > log.txt 2>&1
> 
> last line reads:
> Files /home/hermann/lilydevel/usr/etc/fonts/local.conf and
> /home/hermann/lilypond/usr/etc/fonts/local.conf are identical
> 
> Do you need the entire file (it has 2000 lines)?

Yes, please.

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

Re: strange result for escaping "\" with other font-name

[Masamichi HOSODA]

>> Second, your 2.19.26's fontconfig configure files
>> do not seem to have substitute settings.
>
> It's not clear to me why this happens. Is it a LilyPond-problem or
> something at my part?
> With 2.18.2 and 2.19.26 I'm on a 64-bit LINUX
> Trying with a build from master, lilyDev (32bit Debian), I do get
> substitute settings
>
> If I try
> \version "2.19.26"
> \markup \override #'(font-name . "not existing font") "\\<==what?"
>
> I do get substitute settings as well.

 According to the log file, your 2.19.26's fontconfig
 default top configure file is
 /home/hermann/lilydevel/usr/etc/fonts/fonts.conf

 And, maybe,
 /home/hermann/lilydevel/usr/etc/fonts/local.conf
 /home/hermann/lilydevel/usr/etc/fonts/conf.d/*.conf
 are fontconfig auxiliary configure files.

 Your 2.18.2's one are
 /home/hermann/lilypond/usr/etc/fonts/fonts.conf
 /home/hermann/lilypond/usr/etc/fonts/local.conf
 /home/hermann/lilypond/usr/etc/fonts/conf.d/*.conf

 Would you compare them?
>>>
>>> I don't have the skills to appraise what I see.
>>> Here's a simple diff. Is this sufficient?
>>>
>>> diff /home/hermann/lilydevel/usr/etc/fonts/fonts.conf
>>> /home/hermann/lilypond/usr/etc/fonts/fonts.conf
>>> 28,29d27
>>> < fonts
>>> < 
>>> 39c37
>>> < 
>>> ---
 
>>> 51c49
>>> < 
>>> ---
 
>>> 63c61
>>> < 
>>> ---
 
>>> 76,77d73
>>> < fontconfig
>>> < 
>>
>> Would you try following command?
>>
>> $ diff -ursN /home/hermann/lilydevel/usr/etc/fonts 
>> /home/hermann/lilypond/usr/etc/fonts
>
> I did
> diff -ursN /home/hermann/lilydevel/usr/etc/fonts
> /home/hermann/lilypond/usr/etc/fonts > log.txt 2>&1
>
> last line reads:
> Files /home/hermann/lilydevel/usr/etc/fonts/local.conf and
> /home/hermann/lilypond/usr/etc/fonts/local.conf are identical
>
> Do you need the entire file (it has 2000 lines)?

 Yes, please.
>>>
>>> Here you are
>>
>> Thank you.
>>
>> It seems to lack the necessary files.
>> How do you install 2.19.26?
> 
> I download
> lilypond-2.19.26-1.linux-64.sh
> from
> http://lilypond.org/development.html
> navigate to Desktop (where it is stored) and then:
> sh lilypond-2.19.26-1.linux-64.sh
> 
>>
>> Do following files exist?
>> /home/hermann/lilydevel/usr/etc/fonts/conf.avail/*.conf
> 
> No !!
> 
>> /home/hermann/lilydevel/usr/etc/fonts/conf.d/*.conf
> 
> yes
> 
>>
>> If not, would you try to re-install LilyPond?
>>
>> Or, would you try to install official web site's LilyPond 2.19.26 binary?
> 
> I uninstalled it and re-installed it, with a fresh download of
> lilypond-2.19.26-1.linux-64.sh
> (refusing to rename it for now)
> exercising  all the steps listed above.
> 
>>
>> And, just idea,
>> it might be solved by copying official binary's
>> lilypond/usr/etc/fonts/*
>> files to
>> /home/hermann/lilydevel/usr/etc/fonts/
>> .
> 
> Not sure what exactly you suggest.
> I tried to copy/paste conf.avail from 2.18.2 to 2.19.26
> The issue persists, though.
> 
> Obviously conf.avail is missing for me with 2.19.26. If it's my
> problem then it's bad, but if it's a general problem for 64-bit-Linux
> then it's worse.
> 
> Best would be others with 64-bit Linux could do testing for:
> 
> \version "2.19.26"
> \markup \override #'(font-name . "not a font") "\\<==what?"
> 
> 
> or look, whether
> lilypond/usr/etc/fonts/conf.avail/*.conf
> exists at all.

I've tried to install official 2.19.26.
I've found GUB's problem.

I understand correctly,
Most platform's 2.19.26 official binaries have this problem.
Only mingw (Windows) platform does not have this problem.

The cause is that fontconfig conf files symbolic links are absolute path.
Installed directory is different in each environment.
So absolute path can not find link destination.

Windows can not handle symbolic links.
Symbolic link is not used. conf files are copied.
So installed conf files are exist. It's no problem.

To fix installed LilyPond is here.

cd lilypond/usr/etc/fonts/conf.d
rm -fr *.conf
ln -s ../../../share/fontconfig/conf.avail/10-scale-bitmap-fonts.conf
ln -s ../../../share/fontconfig/conf.avail/20-unhint-small-vera.conf
ln -s ../../../share/fontconfig/conf.avail/30-metric-aliases.conf
ln -s ../../../share/fontconfig/conf.avail/30-urw-aliases.conf
ln -s ../../../share/fontconfig/conf.avail/40-nonlatin.conf
ln -s ../../../share/fontconfig/conf.avail/45-latin.conf
ln -s ../../../share/fontconfig/conf.avail/49-sansserif.conf
ln -s ../../../share/fontconfig/conf.avail/50-user.conf
ln -s ../../../share/fontconfig/conf.avail/51-local.conf
ln -s ../../../share/fontconfig/conf.avail/60-latin.conf
ln -s 

Re: strange result for escaping "\" with other font-name

[Masamichi Hosoda]

On 2015年9月4日 17:51:16 JST, Thomas Morley  wrote:
>2015-09-04 7:57 GMT+02:00 Werner LEMBERG :
>
>> > trying to escape "\" in a string leads to strange results, for some
>> > font-names.
>> > Example below was ok with 2.18.2
>> >
>> > \version "2.19.26"
>> >
>> > \markup \override #'(font-name . "Times New Roman") "\\<==what?"
>>
>> The displayed font is definitely not `Times New Roman'.  It seems
>that
>> the font substituted by FontConfig is a CJK font using half-width
>> glyphs, and there it sometimes happens that the `\' slot gets
>replaced
>> with the Yen sign `¥', for compatibility with ancient Japanese
>> practice.
>>
>
>Agreed, so far.
>
>>
>> I think there is nothing to be done here, since it displays a font
>> problem (or bug).
>>
>
>Though, if 2.18.2 displays nicely (and it does), I'd tend to think
>something on our part causes this misbehahiour.
>(Ofcourse "Times New Roman" _is_ installed)
>
>Cheers,
>  Harm
>___
>bug-lilypond mailing list
>bug-lilypond@gnu.org
>https://lists.gnu.org/mailman/listinfo/bug-lilypond

Would you show us both 2.18.2 and 2.19.26 results of following command?

$ FC_DEBUG=1 lilypond --verbose fonts-test-01.ly > result.txt 2>&1

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

Re: strange result for escaping "\" with other font-name

[Masamichi HOSODA]

>> trying to escape "\" in a string leads to strange results, for some
>> font-names.
>> Example below was ok with 2.18.2
>>
>> \version "2.19.26"
>>
>> \markup \override #'(font-name . "Times New Roman") "\\<==what?"
> The displayed font is definitely not `Times New Roman'.  It seems
 that
> the font substituted by FontConfig is a CJK font using half-width
> glyphs, and there it sometimes happens that the `\' slot gets
 replaced
> with the Yen sign `¥', for compatibility with ancient Japanese
> practice.
>
 Agreed, so far.

> I think there is nothing to be done here, since it displays a font
> problem (or bug).
>
 Though, if 2.18.2 displays nicely (and it does), I'd tend to think
 something on our part causes this misbehahiour.
 (Ofcourse "Times New Roman" _is_ installed)

 Cheers,
  Harm
 ___
 bug-lilypond mailing list
 bug-lilypond@gnu.org
 https://lists.gnu.org/mailman/listinfo/bug-lilypond
>>> Would you show us both 2.18.2 and 2.19.26 results of following command?
>>>
>>> $ FC_DEBUG=1 lilypond --verbose fonts-test-01.ly > result.txt 2>&1
>>>
>> Will do in the evening. Have to run for my rl job :(
>> ___
> Here:
> 
> https://drive.google.com/file/d/0B9nZ5LHV2Ds6alctWXZYQXd2Tms/view?usp=sharing
> 
> and
> 
> https://drive.google.com/file/d/0B9nZ5LHV2Ds6SnRFYXJYQ0E0UlE/view?usp=sharing
> 
> Hope this helps.
> 
> NB: I didn't change the 'version' statement in the LP file when I
> compiled it with 2.18.2 in case that adds noise to the output.
> 
> James
> 
> PS I am using Linux Mint latest (whatever that is - I lose track!)

In James's results, both lilypond's fontconfig
seem to have substitute settings.
So both results show that DejaVu Sans is selected.

However, both fontconfig is requested "Times New" font,
instead of "Times New Roman".

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

Re: strange result for escaping "\" with other font-name

[Masamichi HOSODA]

>>> trying to escape "\" in a string leads to strange results, for some
>>> font-names.
>>> Example below was ok with 2.18.2
>>>
>>> \version "2.19.26"
>>>
>>> \markup \override #'(font-name . "Times New Roman") "\\<==what?"
>> The displayed font is definitely not `Times New Roman'.  It seems
> that
>> the font substituted by FontConfig is a CJK font using half-width
>> glyphs, and there it sometimes happens that the `\' slot gets
> replaced
>> with the Yen sign `¥', for compatibility with ancient Japanese
>> practice.
>>
> Agreed, so far.
>
>> I think there is nothing to be done here, since it displays a font
>> problem (or bug).
>>
> Though, if 2.18.2 displays nicely (and it does), I'd tend to think
> something on our part causes this misbehahiour.
> (Ofcourse "Times New Roman" _is_ installed)
>
> Cheers,
>  Harm
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-lilypond
 Would you show us both 2.18.2 and 2.19.26 results of following command?

 $ FC_DEBUG=1 lilypond --verbose fonts-test-01.ly > result.txt 2>&1

>>> Will do in the evening. Have to run for my rl job :(
>>> ___
>> Here:
>> 
>> https://drive.google.com/file/d/0B9nZ5LHV2Ds6alctWXZYQXd2Tms/view?usp=sharing
>> 
>> and
>> 
>> https://drive.google.com/file/d/0B9nZ5LHV2Ds6SnRFYXJYQ0E0UlE/view?usp=sharing
>> 
>> Hope this helps.
>> 
>> NB: I didn't change the 'version' statement in the LP file when I
>> compiled it with 2.18.2 in case that adds noise to the output.
>> 
>> James
>> 
>> PS I am using Linux Mint latest (whatever that is - I lose track!)
> 
> In James's results, both lilypond's fontconfig
> seem to have substitute settings.
> So both results show that DejaVu Sans is selected.
> 
> However, both fontconfig is requested "Times New" font,
> instead of "Times New Roman".

I've created issue 4591
`Times New Roman' can not select by override fonts

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

Re: lilypond does not compile: fontforge version not detected

[Masamichi HOSODA]

 i attempted to install lilypond- gentoo ebuild but it fails because it 
 does not detect fontforge version correctly:
 
 # ./configure
 ...
 configure: creating ./config.status
 config.status: creating config.make
 config.status: creating config.hh
 configure: WARNING: unrecognized options: --with-ncsb-dir
 
 WARNING: Please consider installing optional programs or files:  dblatex 
 pdflatex epsf.tex lh CTAN package (texlive-lang-cyrillic or texlive-texmf-
 fonts)
 
 ERROR: Please install required programs:  /usr/bin/fontforge = 20110222 
 (installed: 99da6faa1ea3b4f80ecd333f596ea7dab205325)
 
 See INSTALL.txt for more information on how to build LilyPond
 ...
 
 here is the output of fontforge:
 
 # fontforge --version
 Copyright (c) 2000-2014 by George Williams. See AUTHORS for Contributors.
  License GPLv3+: GNU GPL version 3 or later 
 http://gnu.org/licenses/gpl.html
  with many parts BSD http://fontforge.org/license.html. Please read 
 LICENSE.
  Based on sources from 10:14 CEST 19-Aug-2015-ML-D.
  Based on source from git with hash: 
 99da6faa1ea3b4f80ecd333f596ea7dab205325e
 no xdefs_filename!
 TESTING: getPixmapDir:/usr/share/fontforge/pixmaps
 TESTING: getShareDir:/usr/share/fontforge
 TESTING: GResourceProgramDir:/usr/bin
 trying default theme:/usr/share/fontforge/pixmaps/resources
 fontforge 10:14 CEST 19-Aug-2015
 libfontforge 20150819
 
 
 it apparently catches git hash instead of the date version.

Would you try the attached patch?
It is necessary `./autogen.sh' before `./configure'.
From a0f236e881b4b52088cc51bcd52049c44e42387c Mon Sep 17 00:00:00 2001
From: Masamichi Hosoda truer...@trueroad.jp
Date: Sat, 22 Aug 2015 21:20:17 +0900
Subject: [PATCH] Fix fontforge version detection

Newer fontforge shows git hash in `fontforge --version`.
In that case, configure script
might recognize it as date (version).
---
 aclocal.m4 | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/aclocal.m4 b/aclocal.m4
index 48d0b77..0037c58 100644
--- a/aclocal.m4
+++ b/aclocal.m4
@@ -42,7 +42,8 @@ AC_DEFUN(STEPMAKE_GET_VERSION, [
 
 if test -z $_ver; then
 ## If empty, try date [fontforge]
-eval _ver=\\`($1 --version || $1 -V) 21 | grep '[0-9]\{6,8\}' \
+eval _ver=\\`($1 --version || $1 -V) 21 \
+	| grep '\(^\|[^0-9a-f]\)[0-9]\{6,8\}\([^0-9a-f]\|$\)' \
 	| head -n 1 \
 	| sed -e 's/^[^.0-9]*//' -e 's/[^.0-9]*$//'\`\
 fi
-- 
2.4.5

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

Re: lilypond does not compile: fontforge version not detected

[Masamichi HOSODA]

 hi,
 
 this patch fixes the issue. fontforge is now detected and configure
 script finishes without issue.
 
 thanks.
 
 Dne 22.8.2015 v 14:25 Masamichi HOSODA napsal(a):
 i attempted to install lilypond- gentoo ebuild but it fails because it 
 does not detect fontforge version correctly:

 # ./configure
 ...
 configure: creating ./config.status
 config.status: creating config.make
 config.status: creating config.hh
 configure: WARNING: unrecognized options: --with-ncsb-dir

 WARNING: Please consider installing optional programs or files:  dblatex 
 pdflatex epsf.tex lh CTAN package (texlive-lang-cyrillic or texlive-texmf-
 fonts)

 ERROR: Please install required programs:  /usr/bin/fontforge = 20110222 
 (installed: 99da6faa1ea3b4f80ecd333f596ea7dab205325)

 See INSTALL.txt for more information on how to build LilyPond
 ...

 here is the output of fontforge:

 # fontforge --version
 Copyright (c) 2000-2014 by George Williams. See AUTHORS for Contributors.
  License GPLv3+: GNU GPL version 3 or later 
 http://gnu.org/licenses/gpl.html
  with many parts BSD http://fontforge.org/license.html. Please read 
 LICENSE.
  Based on sources from 10:14 CEST 19-Aug-2015-ML-D.
  Based on source from git with hash: 
 99da6faa1ea3b4f80ecd333f596ea7dab205325e
 no xdefs_filename!
 TESTING: getPixmapDir:/usr/share/fontforge/pixmaps
 TESTING: getShareDir:/usr/share/fontforge
 TESTING: GResourceProgramDir:/usr/bin
 trying default theme:/usr/share/fontforge/pixmaps/resources
 fontforge 10:14 CEST 19-Aug-2015
 libfontforge 20150819


 it apparently catches git hash instead of the date version.
 Would you try the attached patch?
 It is necessary `./autogen.sh' before `./configure'.

I've created Issue 4573.
https://code.google.com/p/lilypond/issues/detail?id=4573
https://codereview.appspot.com/258400043

Thank you.

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

Re: Good news for Fedora 22 users (fwd)

[Masamichi HOSODA]

 Hi,
 
 I just updated fontconfig from 2.11.93 to version-2.11.94 (now in
 updates-testing) on Fedora 22
 
 $ sudo dnf update --enablerepo=*testing update fontconfig*
 
 And a quick test shows Lilypond started working again :-)

Thank you for your information.
I'm glad to hear it.

LilyPond uses Pango.
Pango uses fontconfig.

I suspected Pango.
However, it may be an issue of fontconfig which is used by Pango.

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

Re: lilypond 2.19.20 on fedora gs bug

[Masamichi HOSODA]

 The Fedora 22 package fails for everyone, the www.lilypond.org version
 works.
 
 I tried this minimal example:
 
 % f22test.ly
 \version 2.19.21
 {c'}
 
 And then did
 
 $ lilypond --ps --verbose f22.ly  f22test1.txt
 $ ps2pdf14 f22test.ps f22test.pdf  f22test2.txt
 
 results: see attachment.
 f22test1.txt f22test2.txt f22test.ps

Thank you for your files.

I suspect an issue of pango package of fedora 22.

First, I've tried your f22test.ps on my environment with gs-9.15.
It is failed. That is, it is not gs-9.16's issue.
The result is following.

```
$ ps2pdf14 f22test.ps f22test.pdf
Error: /undefinedresult in --glyphshow--
Operand stack:
   0.6146   5.6906   -2.8453   space
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   
--nostringval--   2   %stopped_push   --nostringval--   --nostringval--   
--nostringval--   false   1   %stopped_push   1967   1   3   %oparray_pop   
1966   1   3   %oparray_pop   1950   1   3   %oparray_pop   1836   1   3   
%oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   
--nostringval--   --nostringval--   2   %stopped_push   --nostringval--   0   
--nostringval--   %repeat_continue   --nostringval--
Dictionary stack:
   --dict:1186/1684(ro)(G)--   --dict:0/20(G)--   --dict:108/200(L)--
Current allocation mode is local
Last OS error: No such file or directory
Current file position is 131424
GPL Ghostscript 9.15: Unrecoverable error, exit code 1

```

Then, I've found problems of f22test.ps.
Broken f22test.ps sets font size to zero.
Using the patch file for f22test.ps that is attached to this mail,
ps2pdf14 is succeed.

If I understand correctly, LilyPond gets the font size from pango.
www.lilypond.org version LilyPond bundles pango that has no problem,
and always uses it.

Fedora 22's packaged LilyPond uses fedora 22's packaged pango?
--- f22test.ps.org	2015-05-29 08:58:52.323780200 +0900
+++ f22test.ps	2015-05-29 09:14:07.983424500 +0900
@@ -2210,7 +2210,7 @@
 /helpEmmentaler-20 where {pop helpEmmentaler-20} if
 /helpEmmentaler-23 where {pop helpEmmentaler-23} if
 /helpEmmentaler-26 where {pop helpEmmentaler-26} if
-5.6906 -2.8453 moveto /CenturySchL-Roma 0. output-scale div selectfont
+5.6906 -2.8453 moveto /CenturySchL-Roma 3.86523438 output-scale div selectfont
 0.6146 0. 0. /space
 1 print_glyphs
 14.2264 -9.6093 moveto 11.6142 0. 0.0500 0. 0.1000 draw_line
@@ -2225,7 +2225,7 @@
 22.9264 -11.1593 24.2425 -10.0593 (textedit:///home/m.tarenskeen/f22test.ly:2:1:2) mark_URI
 22.9264 -10.6093 moveto magfontemmentaler-20mXVo /noteheads.s2 glyphshow
 31.0704 -165.1170 moveto 0. -0.47800630 currentpoint vector_add  57.36075591 1.63887874 currentpoint vector_add (http://lilypond.org/) mark_URI
-31.0704 -165.1170 moveto /CenturySchL-Roma 0. output-scale div selectfont
+31.0704 -165.1170 moveto /CenturySchL-Roma 3.86523438 output-scale div selectfont
 1.1950 0. 0. /g
 0.9902 0. 0. /r
 1.0926 0. 0. /o
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: lilypond 2.19.20 on fedora gs bug

[Masamichi HOSODA]

 % can't compile anything due to gs error
 % warning: `(gs -q -dSAFER -dDEVICEWIDTHPOINTS=595.28
 -dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH
 -r1200 -sDEVICE=pdfwrite -sOutputFile=./n.pdf -c.setpdfwrite -fn.ps)' failed
 (256)
 % gs command itself gives Error: /undefinedresult in --glyphshow--
 % generated ps files can't be read by gv or zathura-ps viewers
 % it worked normally on fedora 21 and lilypond 2.18.2
 \version 2.19.20
 \relative c {a}

Is your lilypond installed from fedora 22's package?
Or, downloaded from www.lilypond.org?

Would you try the following commands and show us the whole output?

$ lilypond --verbose n.ly
$ ps2pdf14 n.ps n.pdf

And, would you send us the generated ps file?

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

Re: my favorite bug :-)

[Masamichi HOSODA]

 The bug would be fixed if lilypond would make ghostscript use a
 complete path to the intermediate lines.ps file for the ps to pdf
 conversion.
 Does anyone know how to convert from any path (relative and absolute
 path)
 to absolute path in scheme (guile) ?
 
 Maybe the functions in this file help you?
 https://github.com/openlilylib/openlilylib/blob/master/ly/_internal/utilities/os-path.scm

Thank you.

But, now, I think using an absolute path
for solving ghostscript file name issue is not a good idea.

Using mkstemp generated temporary file is a good idea.
It is the same way as gcc's intermediate file treatment.

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

Re: my favorite bug :-)

[Masamichi HOSODA]

 The bug would be fixed if lilypond would make ghostscript use a
 complete path to the intermediate lines.ps file for the ps to pdf
 conversion.
 
 Does anyone know how to convert from any path (relative and absolute path)
 to absolute path in scheme (guile) ?

When the following command is used,
lilypond uses the absolute (complete) path to the intermediate files.

$ lilypond -dgui `pwd`/lines.ly

It works fine.

However, I think that the intermediate file should be temporary
by mkstemp etc.
If lilypond uses mkstemp generated temporary file,
this ghostscript problem will not occur.

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

Re: my favorite bug :-)

[Masamichi HOSODA]

 There is a big difference: If you compile a .c file, the .o files
 stays by default; the compiler doesn't remove it.
 
 Uh, wrong?
 
 cd /tmp;echo main(){return 0;} gega.c;gcc -o gega gega.c;ls gega*
 gega  gega.c
 
 I've meant using option `-c' of the compiler.  BTW, if you specify
 option `-o', does gcc create an intermediate file `gega.o' that
 overwrites another file `gega.o' in the compilation directory?

If I understand correctly,
in this case, gcc does not use gega.o.
gcc uses /tmp/ccXX.o etc.
(XX is replaced by random unique charactor by mkstemp.)
gcc removes it.

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

Re: my favorite bug :-) (fwd)

[Masamichi HOSODA]

 Did you know it is not possible/allowed to name a lilypond file
 align.ly or lines.ly? On my Fedora system I can find all the names
 that suffer from this bug by typing
 
 #ls /usr/share/ghostscript/9.15/lib/*.ps
 
 all these filenames (minus .ps) can not be used as lilypond inputfiles
 (plus .ly)
 
 for example create a file lines.ly with a minimal content
 
 \version 2.19.19
 {c' d' e' f'}
 
 and compile ...
 
 Fortunately there are no prelude.ps, etude.ps, or sonata.ps in the
 ghostscript files ;-)

In my cygwin64 environment, I've reproduced it.
(I've installed lilypond by cygwin64 setup in the environment.)

And, the following commands also has been reproduced it.

$ lilypond -f ps lines.ly
$ ps2pdf14 lines.ps lines.pdf

On the other hand, the following commands has not been reproduced it.

$ lilypond -f ps lines.ly
$ ps2pdf14 `pwd`/lines.ps lines.pdf

Perhaps it's a ghostscript's bug.
(ps2pdf14 is ghostscript included command.)

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

Re: my favorite bug :-)

[Masamichi HOSODA]

 The bug would be fixed if lilypond would make ghostscript use a
 complete path to the intermediate lines.ps file for the ps to pdf
 conversion.

Does anyone know how to convert from any path (relative and absolute path)
to absolute path in scheme (guile) ?

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

Re: Ghostscript problem in 2.19.18

[Masamichi HOSODA]

 How do you install lilypond-2.19.18-1.linux-x86.sh?
 
 I execute the script as user to install it to ~/lilypond (with the
 wrappers in ~/bin).
 Then (and that's maybe where the problem starts) I move the ~/lilypond
 folder to the location on /shared and create a symlink at ~/lilypond.
 This is what I've always done and what has always worked.

How do you move and create symlink them?
symlink's symlinks are OK?

 gs requires its resource files (gs_init.ps etc.).
 It finds them by environment variable GS_LIB or its built in search
 path.
 
 echo $GS_LIB doesn't return anything.

GS_LIB is set by lilypond.
And it is unset when lilypond is finished.

 If I run gs --version on the gs file inside the lilypond-2.19.18-1
 installation it returns 9.05!

OK.
Your system's gs is 9.05.
It is not 9.10.

gs executable is just a loader.
It loads and calls libgs.

gs-9.15 executable loads libgs.so.9.
lilypond included libgs.so.9 is symlink to libgs.so.9.15.
Both files in lilypond's libraries directory.

By the default,
lilypond's libraries directory is not in library search path.

Perhaps, your system's libgs.so.9 is symlink to libgs.so.9.05,
and both files are in library search path.
So, lilypond included gs executable loads your system's libgs.
It is 9.05.

On the other hands,
lilypond-2.19.17-1.linux-x86.sh includes gs-8.70.
Its gs executable loads libgs.so.8.
If your system has libgs.so.8 and it is symlink to libgs.so.8.70,
lilypond-2.19.17 works fine.

 I just installed 2.19.18-1 again and left it in its default location
 ~/lilypond.
 Now everything works.
 
 Can it be that there's some hardcoded path anywhere, so the included
 gs isn't found anymore?
 But if that's the case I think it should be fixed because I should be
 able to move around the actual lilypond installation - and it did work
 up to 2.19.17

If I understand correctly,
~/lilypond/ files don't have hardcoded absolute path.
However, ~/bin/ wrapper script files have absolute path.

~/bin/lilypond wrapper script set LD_LIBRARY_PATH
for changing library search path.

If you move installed ~/lilypond/ files,
I recommend to rewrite ~/bin/lilypond wrapper script.

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

Re: Ghostscript problem in 2.19.18

[Masamichi HOSODA]

 OK.
 
 Compiling a file with  lilypond-2.19.18-1.linux-x86.sh ends with
 
 Invoking `gs -dSAFER -dDEVICEWIDTHPOINTS=595.28
 -dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH
 -r1200 -sDEVICE=pdfwrite -sOutputFile=./document.pdf -c.setpdfwrite
 -fdocument.ps'...
 
 
 gs: Interpreter revision (905) does not match gs_init.ps revision
 (915).
 
 warning: `(gs -dSAFER -dDEVICEWIDTHPOINTS=595.28
 -dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH
 -r1200 -sDEVICE=pdfwrite -sOutputFile=./document.pdf -c.setpdfwrite
 -fdocument.ps)' failed (256)
 
 
 
 while compiling with a self-built version ends with
 
 Invoking `gs -dSAFER -dDEVICEWIDTHPOINTS=595.28
 -dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH
 -r1200 -sDEVICE=pdfwrite -sOutputFile=./document.pdf -c.setpdfwrite
 -fdocument.ps'...
 
 GPL Ghostscript 9.05 (2012-02-08)
 
 Copyright (C) 2010 Artifex Software, Inc. All rights reserved.
 
 This software comes with NO WARRANTY: see the file PUBLIC for details.
 
 ]/home/uliska/git/lilypond/lilypond-builds/current/out/share/lilypond/current/scm/lily.scm
 
 
 Success: compilation successfully complete
 
 
 Here we obviously call Ghostscript 9.05 also (which seems to be the
 current version on Debian stable) but without conflicting with
 gs_init.ps.
 
 
 So what is wrong here?
 If it is simply an issue with my personal installation I'd consider
 ignoring it, but somehow this looks like an issue. So it would be good
 to have a confirmation that either I'm the only one experiencing it or
 not.

How do you install lilypond-2.19.18-1.linux-x86.sh?

In your system, does
/shared/software/lilypond/current-devel/usr/bin/gs
exist?

Is it executable?


gs requires its resource files (gs_init.ps etc.).
It finds them by environment variable GS_LIB or its built in search path.

lilypond-2.19.18-1.linux-x86.sh includes gs-9.15 executable
and its resource files.

I think that this issue is as following.

In your environments, the case of lilypond-2.19.18-1.linux-x86.sh,
lilypond invokes system's gs-9.10 instead of included gs-9.15.
But, GS_LIB indicates included resource files for gs-9.15.
The versions of gs executable and gs resource files are different.
Then, it fails.

In the case of your self-built, lilypond invokes system's gs-9.10
(self-built lilypond doesn't include gs executable),
GS_LIB is maybe unset
(self-built lilypond doesn't include gs resource files),
and gs finds system's gs resource files for gs-9.10.
The versions of gs executable and gs resource files are same gs-9.10.
Then, it succeeds.

In my environments, the case of lilypond-2.19.18-1.linux-x86.sh,
lilypond invokes included gs-9.15,
and GS_LIB indicates included resource files for gs-9.15.
The versions of gs executable and gs resource files are same gs-9.15.
Then, it succeeds.

I think the problem of your system is
why lilypond invokes system's gs instead of included gs.

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

Re: Ghostscript problem in 2.19.18

[Masamichi HOSODA]

 This is on Debian with the linux-386 binary and applies to _any_ file,
 even
 { c }
 .
 
 Compiling with the 2.19.17 binary works.
 Compiling with the 2.19.18 binary fails.
 Compiling with a custom build from current master works.
 
 As there are no relevant commits between the 2.19.18 tag and current
 master I assume this is due to the binary build (i.e. recent GUB
 changes).

I've tested official binary lilypond-2.19.18-1.linux-x86.sh
on both Ubuntu 32 bit and Ubuntu 64 bit.

It is fine for my both environments.

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

Re: Ghostscript problem in 2.19.18

[Masamichi HOSODA]

 I have just installed lilypond-2.19.18-1.linux-x86.sh on another
 machine running Debian 7 stable with latest updates. And the error is
 identical. Maybe (this is a big maybe) I'll have a chance to test it
 on another (different) 32bit Linux installation later today, but
 that's not sure at all.
 
 What kind of dependencies could I look for that could be handled by
 GUB or documented as requirements?

Would you try like following command?

$ lilypond --verbose foo.ly

And, would you show me the whole output of the command?

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

Re: Ghostscript problem in 2.19.18

[Masamichi HOSODA]

 gs: Interpreter revision (905) does not match gs_init.ps revision
 (915).

lilypond-2.19.18-1.linux-x86.sh includes gs-9.15.
However, lilypond seems to be invoking the external gs-9.05
instead of included gs-9.15.

My ubuntu 64 bit environment have been installed gs-9.10.
However, lilypond invokes included gs-9.15 instead of system's gs-9.10.
My ubuntu 32 bit environment have not been installed gs.

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

Re: [PATCH] Fix unset PATH crash

[Masamichi HOSODA]

 On 2015-03-01 02:07 AM, Masamichi HOSODA wrote:
 On Windows, lilypond crashes when the environment variable PATH is not
 set.

 ```
 C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\binset PATH=

 C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\binlilypond
 GNU LilyPond 2.19.16
 terminate called after throwing an instance of 'std::logic_error'
what():  basic_string::_S_construct null not valid

 This application has requested the Runtime to terminate it in an
 unusual way.
 Please contact the application's support team for more information.

 C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\bin
 ```

 Even in the case of linux, this issue is a possible crash.
 A patch file is attached.

 
 Should this be added to Issue 1948
 https://code.google.com/p/lilypond/issues/detail?id=1948: Windows
 install clobbered system PATH and the issued be re-opened?

It seems that that issue is about Windows installer and has been fixed.
This issue that I've reported is not about Windows installer,
is about lilypond itself.

On Windows, this issue can be easily crash lilypond,
as shown in the above example.

Even linux, it is possible to crash lilypond like following commands.

```
$ cd /home/gub/gub/target/linux-64/root/usr/bin
$ unset PATH
$ lilypond
GNU LilyPond 2.19.16
terminate called after throwing an instance of 'std::logic_error'
  what():  basic_string::_S_construct null not valid
Aborted (core dumped)
$
```

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

[PATCH] Fix unset PATH crash

[Masamichi HOSODA]

On Windows, lilypond crashes when the environment variable PATH is not set.

```
C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\binset PATH=

C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\binlilypond
GNU LilyPond 2.19.16
terminate called after throwing an instance of 'std::logic_error'
  what():  basic_string::_S_construct null not valid

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

C:\tmp\lilypond-2.19.16-0.mingw\$_OUTDIR\usr\bin
```

Even in the case of linux, this issue is a possible crash.
A patch file is attached.
From 68e233c11b3eeaad0ee442a4b3a47e206ebc70e0 Mon Sep 17 00:00:00 2001
From: Masamichi Hosoda truer...@trueroad.jp
Date: Sun, 1 Mar 2015 17:44:54 +0900
Subject: [PATCH] Fix unset PATH crash

When the environment variable PATH is not set,
getenv (PATH) returns NULL.
File_path::parse_path converts the argument into std::string.
To convert NULL into std::string raises an exception.

This patch check the return value of getenv (PATH)
and pass to the File_path::parse_path only when it is not NULL.
---
 lily/relocate.cc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/lily/relocate.cc b/lily/relocate.cc
index 2adfb6f..73fde03 100644
--- a/lily/relocate.cc
+++ b/lily/relocate.cc
@@ -181,7 +181,9 @@ setup_paths (char const *argv0_ptr)
 {
   /* Find absolute ARGV0 name, using PATH.  */
   File_path path;
-  path.parse_path (getenv (PATH));
+  char *p = getenv (PATH);
+  if (p)
+path.parse_path (p);
 
 #ifndef __MINGW32__
   argv0_abs = path.find (argv0_filename.to_string ());
-- 
2.1.4

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

Re: time-signature-single-digit.ly and time-signature-single-digit.ly don't have \version

[Masamichi HOSODA]

 Thanks for your continuing help.  I get this (the logfile is again
 coming directly to you):
 
 bin/gub tools::gawk
 calculating dependencies
 *** Stage: download (gawk, tools)
 downloading http://ftp.gnu.org/pub/gnu/gawk/gawk-3.1.6.tar.gz -
 /home/gub/NewGub/gub/downloads/gawk/
 .
 done (2488684)
 Checking for gcc ... /usr/bin/gcc
 must rebuild[tools]: system::gcc gawk
 building package: tools::gawk
 *** Stage: download (gawk, tools)
 *** Stage: untar (gawk, tools)
 *** Stage: patch (gawk, tools)
 *** Stage: autoupdate (gawk, tools)
 *** Stage: configure (gawk, tools)
 *** Stage: compile (gawk, tools)
 *** Stage: install (gawk, tools)
 *** Stage: package (gawk, tools)
 *** Stage: clean (gawk, tools)
 *** Stage: pkg_install (gawk, tools)
 
 done
 
 
 $ bin/gub linux-x86::cross/gcc-core
 
 bin/gub linux-x86::cross/gcc-corecalculating dependencies
 Checking for g++ ... /usr/bin/g++
 Checking for gcc ... /usr/bin/gcc
 must rebuild[linux-x86]: system::gcc system::g++ cross/gcc-core
 glibc-core cross/gcc glibc
 building package: linux-x86::cross/gcc-core
 *** Stage: download (cross/gcc-core, linux-x86)
 *** Stage: untar (cross/gcc-core, linux-x86)
 *** Stage: patch (cross/gcc-core, linux-x86)
 *** Stage: autoupdate (cross/gcc-core, linux-x86)
 *** Stage: configure (cross/gcc-core, linux-x86)
 *** Stage: compile (cross/gcc-core, linux-x86)
 Command barfed: cd
 /home/gub/NewGub/gub/target/linux-x86/build/cross/gcc-core-4.9.2 
 make -j16
 tooldir='/home/gub/NewGub/gub/target/linux-x86/root/usr/cross/i686-linux'
 gcc_tooldir='/usr/i686-linux' all-gcc all-target-libgcc
 
 Tail of target/linux-x86/log/cross/gcc-core.log 
 config.status: creating testsuite/Makefile
 config.status: creating config.h
 config.status: executing default commands
 Command barfed: cd
 /home/gub/NewGub/gub/target/linux-x86/build/cross/gcc-core-4.9.2 
 make -j16
 tooldir='/home/gub/NewGub/gub/target/linux-x86/root/usr/cross/i686-linux'
 gcc_tooldir='/usr/i686-linux' all-gcc all-target-libgcc
  Tail of target/linux-x86/log/cross/gcc-core.log
 
 *** Failed target: linux-x86::cross/gcc-core
 gub@gub-VirtualBox:~/NewGub/gub$

I've received your log file.

The log file includes following messages.

```
configure: error: in 
`/home/gub/NewGub/gub/target/linux-x86/build/cross/gcc-core-4.9.2/i686-linux/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
```

Would you show me the config.log?

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

Re: time-signature-single-digit.ly and time-signature-single-digit.ly don't have \version

[Masamichi HOSODA]

 I've received your log file.

 The log file includes following messages.

 ```
 configure: error: in
 `/home/gub/NewGub/gub/target/linux-x86/build/cross/gcc-core-4.9.2/i686-linux/libgcc':
 configure: error: cannot compute suffix of object files: cannot
 compile
 See `config.log' for more details.
 ```

 Would you show me the config.log?
 
 
 Attached are the config.log from the directory above and from the
 gcc-core-4.9.2 directory.

Thank you for config.log files.

Probably, when build / host and target are just same, gcc building is failed.

In my environment (Ubuntu 64bit),
To build linux-x86::cross/gcc-core:
 checking build system type... x86_64-unknown-linux-gnu
 checking host system type... x86_64-unknown-linux-gnu
 checking target system type... i686-pc-linux-gnu
To build linux-64::cross/gcc-core:
 checking build system type... x86_64-unknown-linux-gnu
 checking host system type... x86_64-unknown-linux-gnu
 checking target system type... x86_64-pc-linux-gnu
Therefore, build / host and target are different.

In your environment (Ubuntu 32bit),
To build linux-x86::cross/gcc-core:
 configure:2322: checking build system type
 configure:2336: result: i686-pc-linux-gnu
 configure:2383: checking host system type
 configure:2396: result: i686-pc-linux-gnu
 configure:2416: checking target system type
 configure:2429: result: i686-pc-linux-gnu
Therefor, build / host and target are just same.

I've fixed this issue in my branch.
https://github.com/trueroad/gub/tree/gcc-4.9

Would you update GUB and try again?

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

Re: time-signature-single-digit.ly and time-signature-single-digit.ly don't have \version

[Masamichi HOSODA]

 Zipped, it's a 500k file, so I'm sending it to Masamichi privately.

I've received it.
Thank you.

Maybe, there is no gawk in your system.
I've installed gawk to ubuntu by the following command.

$ sudo apt-get install gawk

Would you try the following commands?

$ bin/gub tools::gawk
$ bin/gub linux-x86::cross/gcc-core

If succeed this, I'll add the dependency.

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

Re: time-signature-single-digit.ly and time-signature-single-digit.ly don't have \version

[Masamichi HOSODA]

 I've cloned this git repo and swapped to the gcc-4.9.2 branch and run
 make bootstrap.  This is on Ubuntu 14.04 32 bit running in a virtual
 machine.  I get an error as follows:
 
 Output from make:
 
 building package: tools::p7zip
 *** Stage: download (p7zip, tools)
 *** Stage: untar (p7zip, tools)
 *** Stage: patch (p7zip, tools)
 *** Stage: shadow (p7zip, tools)
 *** Stage: compile (p7zip, tools)
 Command barfed: cd
 /home/gub/NewGub/gub/target/tools/build/p7zip-9.20.1.src.all  make
 -j16
 
 Output from the p7zip logfile:
 
 *** Stage: compile (p7zip, tools)
 invoking cd
 /home/gub/NewGub/gub/target/tools/build/p7zip-9.20.1.src.all  make
 -j16
 mkdir -p bin
 make -C CPP/7zip/Bundles/Alone all
 make[1]: Entering directory
 `/home/gub/NewGub/gub/target/tools/build/p7zip-9.20.1.src.all/CPP/7zip/Bundles/Alone'
 g++ -O -pipe -s -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DNDEBUG
 -D_REENTRANT -DENV_UNIX -D_7ZIP_LARGE_PAGES -DBREAK_HANDLER -DUNICODE
 -D_UNICODE -c -I.  -I../../../myWindows -I../../../
 -I../../../include_windows ../../../myWindows/myGetTickCount.cpp
 make[1]: g++: Command not found
 make[1]: *** [myGetTickCount.o] Error 127
 make[1]: Leaving directory
 `/home/gub/NewGub/gub/target/tools/build/p7zip-9.20.1.src.all/CPP/7zip/Bundles/Alone'
 make: *** [7za] Error 2
 Command barfed: cd
 /home/gub/NewGub/gub/target/tools/build/p7zip-9.20.1.src.all  make
 -j16
 
 Can anyone help with what the problem is here?

Does your Ubuntu have g++?
If not, please try the following command.

$ sudo apt-get install g++

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

Re: time-signature-single-digit.ly andtime-signature-single-digit.ly don't have \version

[Masamichi HOSODA]

 I've just had a look at your branch on:
 https://github.com/trueroad/gub/network
 
 That's an impressive set of patches over six months of hard work.
 
 Congratulations!  And many thanks for moving this on!

Thank you for your congratulation.

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

Re: time-signature-single-digit.ly and time-signature-single-digit.ly don't have \version

[Masamichi HOSODA]

 I'm now getting an error shown in
 target/linux-x86/log/cross/gcc-core.log:
 
 config.status: creating Makefile
 config.status: creating testsuite/Makefile
 config.status: creating config.h
 config.status: executing default commands
 Command barfed: cd
 /home/gub/NewGub/gub/target/linux-x86/build/cross/gcc-core-4.9.2 
 make -j16
 tooldir='/home/gub/NewGub/gub/target/linux-x86/root/usr/cross/i686-linux'
 gcc_tooldir='/usr/i686-linux' all-gcc all-target-libgcc
 
 Not sure this is very helpful as an error message, but I can't find
 another.

Would you show me whole of gcc-core.log?

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

Re: time-signature-single-digit.ly and time-signature-single-digit.ly don't have \version

[Masamichi HOSODA]

 I'd not bother then.  2.19.16 is a developer release, so it is not
 required that it works for every platform.  Before stable releases, we
 try our best to get things to work according on the feedback we get for
 developer releases.
 
 The whole point of GUB is that most developers don't need to bother at
 all with platforms they don't actually use themselves.
 
 On the other hand, Darwin is the core components and subset of Mac OS
 X.  Therefore, I thought that it could be used as Max OS X
 substitutes.

 However, lilypond requires Carbon that are not included in Darwin.  It
 is included only Mac OS X.  I found that Darwin could not be used as
 Mac OS X substitutes.
 
 I think it might make sense telling this to the Pango people: if Pango
 was able to work without Carbon, that would be an advantage for users of
 Free Software.  But I don't know what this means for font support.
 
 Personally, I would be fine with supporting only fonts working with
 Darwin, just to get the message to Apple that they should make Darwin an
 actually useful option when they want to call it Open Source or
 whatever.
 
 I've found some issues.
 Now, I'm trying to fix them.
 
 If you don't have an actual MacOSX platform, I'd recommend that we just
 release 2.19.16 and wait for user feedback from testers who _have_ a
 Mac.  There is a price to pay for proprietary platforms, and it makes
 more sense to me if that price is paid by those preferring those
 platforms than by the developers working on free platforms.
 
 And those users can test a lot more realistically anyway: any changes
 you make to your Darwin setup in order to make a problem go away might
 either be a MacOSX/Darwin difference, or an actual problem also occuring
 on MacOSX.  And that's what MacOSX users are more qualified to report.

I've fixed the issues I found.

And lilypond's
input/regression/time-signature-numbered.ly
input/regression/time-signature-single-digit.ly
\version issue has also been fixed.

Therefore, in this branch,
https://github.com/trueroad/gub/tree/gcc-4.9
I've succeed GUB's ``make lilypond''.
All lilypond installers have been built by gcc-4.9.2.

In darwin-x86 (Intel Mac):
lilypond installer and lilypond work fine.
Correct PDF is generated.

In darwin-ppc (PowerPC Mac):
I can't prepare PowerPC Mac. Therefore, it is untested.
It would be necessary to wait for user feedback
from testers who have a PowerPC Mac, as you say.

In other environments
(mingw (Windows), linux-64, linux-x86, linux-ppc, freebsd-64, freebsd-x86):
I've tested lilypond installer and lilypond, again. Then, they work fine.
Correct PDF is generated.

It should be noted that, in order to build on the branch,
it is necessary to the new freebsd-runtime file.
https://github.com/trueroad/gub/commit/d402f1f437dc646facfb8f54db49ee0546f7d83f

The file can be made by the following information.
https://github.com/trueroad/gub/blob/d402f1f437dc646facfb8f54db49ee0546f7d83f/gub/freebsd.py#L28
Or I may mail the file.

In addition, my GUB environment is Ubuntu 14.04 LTS 64bit.

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

Re: time-signature-single-digit.ly and time-signature-single-digit.ly don't have \version

[Masamichi HOSODA]

 No need to wait: as I said, I already pushed the fix myself.  Next time,
 it would be nice if you provided a patch by calling git format-patch.
 That way, we get your commit message as well and the patch is pretty
 sure to apply (using git am instead of git apply) and you have less
 trouble when rebasing your own branch on master since Git then
 recognizes that the commit/patch is already there.

Thank you.
Next time, I'll try it.

 Huh.  I had the impression OpenDarwin is dead anyway.  If we have an
 actively maintained and free Darwin version, it would of course be nice
 if we could support it with an installer from us, but only if we
 actually expect people to use our installer.  I think that probably few
 people use our GNU/Linux installer, and it is not clear whether anybody
 actually uses our FreeBSD installer (rather than compile himself or use
 the version of LilyPond packaged by FreeBSD).
 
 But I think PureDarwin/OpenDarwin are a problem for later: I don't think
 we supported them in 2.19.15, so it would be important to get 2.19.16
 out first with the currently supported platforms before trying something
 new.

I don't want PureDarwin / OpenDarwin corresponding lilypond.

I want to test the Mac version lilypond. I didn't have Mac.
On the other hand, Darwin is the core components and subset of Mac OS X.
Therefore, I thought that it could be used as Max OS X substitutes.

However, lilypond requires Carbon that are not included in Darwin.
It is included only Mac OS X.
I found that Darwin could not be used as Mac OS X substitutes.


So, I've been prepared Mac.
And, I've tested darwin-x86::lilypond that I've build by gcc-4.9.2.
In the results, the following command is succeed:

$ ./lilypond

Correct messages is shown.
However, the following command is failed:

$ ./lilypond test.ly

I've found some issues.
Now, I'm trying to fix them.

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

time-signature-single-digit.ly and time-signature-single-digit.ly don't have \version

[Masamichi Hosoda]

Hi

In lilypond current master branch, I found that
input/regression/time-signature-numbered.ly
and
input/regression/time-signature-single-digit.ly
files don't have ``\version''.

http://git.savannah.gnu.org/gitweb/?
p=lilypond.git;a=commitdiff;h=8298bc08d2d6398af3b1c988b825ad36d355e7ee

Then, GUB's ``make lilypond'' is failed.
Here is a patch.

```
--- a/input/regression/time-signature-numbered.ly   2015-02-19 
22:39:42.810909400 +0900
+++ b/input/regression/time-signature-numbered.ly   2015-02-19 
22:40:59.826572000 +0900
@@ -1,3 +1,5 @@
+\version 2.19.16
+
 \header {
   texidoc = The numbered time signature style prints a fraction.
 }
--- a/input/regression/time-signature-single-digit.ly   2015-02-19 
22:37:58.662289400 +0900
+++ b/input/regression/time-signature-single-digit.ly   2015-02-19 
22:41:15.639086900 +0900
@@ -1,3 +1,5 @@
+\version 2.19.16
+
 \header {
   texidoc = The single-digit time signature style prints the numerator 
only.
 }
```



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

Re: time-signature-single-digit.ly and time-signature-single-digit.ly don't have \version

[Masamichi Hosoda]

 Please submit git-formatted patches (including commit message) if
 possible.

 I pushed a fix to staging but could not make use of your patch.

I'll try it in this weekend.
Please wait few days.

 Are you actually working on GUB currently?  We are obviously having some
 problems getting 2.19.16 into gear at the moment.  While I've got Jan to
 look at it sometime next week, it is a bad idea if we don't have any
 active experts working with it.  So if we find someone willing to invest
 some more time in getting GUB back to work with newer GCC versions, we'd
 might manage to get unstuck.

In this branch,
https://github.com/trueroad/gub/tree/gcc-4.9
I've succeed to build all lilypond installers by gcc-4.9.2.

In mingw, linux-x86, linux-64, linux-ppc, freebsd-x86, freebsd-64:
I've tested lilypond-installer and lilypond. Then, they work fine.
Correct PDF is generated.

In darwin-x86 and darwin-ppc:
I'm still working.
I use PureDarwin / OpenDarwin because they are open source and free OS.
However, PureDarwin / OpenDarwin can't execute lilypond.
lilpond (libpangoft2) depends on Carbon.
PureDarwin / OpenDarwin doesn't have Carbon.



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