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

[Thomas Morley]

2015-09-05 19:08 GMT+02:00 Masamichi HOSODA <address@hidden>:
>>>>>>>>>>> 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
>>>>>>>> <     <dir prefix="xdg">fonts</dir>
>>>>>>>> <     <!-- the following element will be removed in the future -->
>>>>>>>> 39c37
>>>>>>>> <         <edit name="family" mode="assign" binding="same">
>>>>>>>> ---
>>>>>>>>>         <edit name="family" mode="assign">
>>>>>>>> 51c49
>>>>>>>> <         <edit name="family" mode="assign" binding="same">
>>>>>>>> ---
>>>>>>>>>         <edit name="family" mode="assign">
>>>>>>>> 63c61
>>>>>>>> <         <edit name="family" mode="assign" binding="same">
>>>>>>>> ---
>>>>>>>>>         <edit name="family" mode="assign">
>>>>>>>> 76,77d73
>>>>>>>> <     <cachedir prefix="xdg">fontconfig</cachedir>
>>>>>>>> <     <!-- the following element will be removed in the future -->
>>>>>>>
>>>>>>> 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 ../../../share/fontconfig/conf.avail/65-fonts-persian.conf
> ln -s ../../../share/fontconfig/conf.avail/65-nonlatin.conf
> ln -s ../../../share/fontconfig/conf.avail/69-unifont.conf
> ln -s ../../../share/fontconfig/conf.avail/80-delicious.conf
> ln -s ../../../share/fontconfig/conf.avail/90-synthetic.conf
>
> I'll make GUB's patch.
> Sorry.

You did great, most impressive work. No idea where we would be without you.
And ofcourse, better to identify a problem than not.

Thanks a lot,
  Harm