On Tue, Apr 28, 2015 at 1:43 PM, Urs Liska <u...@openlilylib.org> wrote:

>
>
> Am 28.04.2015 um 20:16 schrieb David Nalesnik:
>
> Hi Urs,
>
> On Tue, Apr 28, 2015 at 11:38 AM, Urs Liska <u...@openlilylib.org> wrote:
>
>>
>>
>> Am 28.04.2015 um 18:14 schrieb Urs Liska:
>>
>>>
>>>
>>> Am 28.04.2015 um 17:53 schrieb Urs Liska:
>>>
>>>> I think I have found something.
>>>>
>>>> After some experimenting with a copy of font-config-get-font-file and
>>>> trying different approaches I could guess from the documentations available
>>>> I found that replacing an item in the FcPatternGetString call this function
>>>> returns the font name and not the Postscript name or the font file.
>>>>
>>>> The following preliminary function (if added to font-config-scheme.cc)
>>>> returns either the Font Name (if the font exists) or "Emmentaler-11" (on my
>>>> system) if it doesn't exist. I assume it would return other names on other
>>>> systems:
>>>>
>>>> LY_DEFINE (ly_font_config_font_exists, "ly:font-config-font-exists", 1,
>>>> 0, 0,
>>>>
>>>>  ...
>>>>
>>>> Best
>>>> Urs
>>>>
>>>
>>> Wrapping this Scheme function around that:
>>>
>>> fontExists =
>>> #(define-scheme-function (parser location font-name)(string?)
>>>    (string=? font-name (ly:font-config-font-exists font-name)))
>>>
>>> shows that my idea is right: The C++ function returns the family name of
>>> either the given font or the (system-dependent) fallback font. Now all
>>> there would be to it is moving the comparison of the latter Scheme function
>>> to the C++ function .
>>>
>>> Urs
>>>
>>
>>
>> Last one for this working session: The following function
>> ly:font-config-font-exists will return true or false depending on whether
>> the given font is available.
>
>
>  I tried this out on my VM (Ubuntu 10.04.4 -- yes, I need to update to
> the most recent LilyDev...)
>
>  Should it work for any font that's listed by
> ly:font-config-display-fonts?  It works for most of the names I've tried,
> though not all.  For example. "Kedage" returns #f.
>
>
> AFAICS it should, What is the "font name" of Kedage?
>

Here is a part of the output of (display (ly:font-config-display-fonts):

family DejaVu Sans Mono
 DejaVu Sans Mono:style=Book
family DejaVu Sans Mono
 DejaVu Sans Mono:style=Bold
family Century Schoolbook L
 Century Schoolbook L:style=BoldItalic
family Liberation Serif
 Liberation Serif:style=Italic
family Umpush
 Umpush:style=BoldOblique
family Kedage
 Kedage:style=Normal
family Lohit Bengali
 Lohit Bengali:style=Regular

I simply used the family name, so
\fontExists "Kedage"

Doing so with this list, all return #t except Kedage and Umpush.

Both

(display (ly:font-config-get-font-file "Kedage"))

and

(display (ly:font-config-get-font-file "Umpush"))

return

/usr/share/fonts/truetype/thai/TlwgTypo.ttf

so I presume I am using the right name for the two fonts.



> You could try out with my version from the second-to-last post, which
> returns the "plain" result of the fontconfig lookup.
>

OK, here with both Umpush and Kedage I get
Tlwg Typo

\fontExists "Tlwg Typo"
does in fact return #t with the later patch.

but then one of the entries from ly:font-config-display-fonts is

family Tlwg Typo
 Tlwg Typo:style=Oblique

...so I'm pretty sure I understand nothing of what is going on here :(



>
>
>
>
>> The only drawback (yet) is that now the comparison is case sensitive. But
>> *that* should be easy now?
>>
>
>  I don't find anything convenient.  I suppose you could just convert both
> strings to lower- or uppercase and then compare.
>
>
> An Unicode/utf8 things to consider here?
>

Yes, there's that.  I find this link:
http://stackoverflow.com/questions/11635/case-insensitive-string-comparison-in-c
Maybe there's something useful there.


>
>

>
>   But is this desirable?  I mean, is LilyPond ever case-insensitive?
>
>
> Well, when calling *text* fonts it has always been case insensitive. And I
> would like to keep that because you can't really look into the fonts to
> know how they are capitalized. So I'd be happy if we can make music fonts
> case insensitive too instead of the other way round.
>

Makes sense to me.

David
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Reply via email to