Re: Heureka! (Was: Some chord symbols still broken in 2.5.19)

2005-05-09 Thread Han-Wen Nienhuys
Matthias Neeracher wrote:
in ly/chord-modifiers-init.ly, the appropriate UTF-8 chars are  defined.
These are passed through lily. At some point, they end up at
Stencil Pango_font::text_stencil (), which calls
Stencil Pango_font::pango_item_string_stencil().
I finally found what was going on: Pango and freetype were actually  
working just fine, as far as I can tell. The problem was that wcrtomb  
on MacOS X does not necessarily perform Unicode->UTF8 conversion  
because it's locale sensitive, and it seems that the default locale  
setting is not UTF8 friendly for this call.

Simply hand coding the conversion seemed to work fine, but I'm not  sure 
what other places in the code rely on wide character functionality.
thanks for the patch, I applied it. For the future, could you provide 
ChangeLogs? That makes it easier to track the copyright status of LilyPond.

--
Han-Wen Nienhuys - [EMAIL PROTECTED]
LilyPond Software Design - http://www.lilypond-design.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel


Heureka! (Was: Some chord symbols still broken in 2.5.19)

2005-05-08 Thread Matthias Neeracher
On Apr 27, 2005, at 5:31 PM, Han-Wen Nienhuys wrote:
Op wo, 27-04-2005 te 14:31 -0700, schreef Matthias Neeracher:
Can you tell me where in the lilypond code the font for the  
triangle is
looked up? I could probably understand the issue better if I know  
where
to hook up the debugger.


in ly/chord-modifiers-init.ly, the appropriate UTF-8 chars are  
defined.
These are passed through lily. At some point, they end up at
Stencil Pango_font::text_stencil (), which calls
Stencil Pango_font::pango_item_string_stencil().
I finally found what was going on: Pango and freetype were actually  
working just fine, as far as I can tell. The problem was that wcrtomb  
on MacOS X does not necessarily perform Unicode->UTF8 conversion  
because it's locale sensitive, and it seems that the default locale  
setting is not UTF8 friendly for this call.

Simply hand coding the conversion seemed to work fine, but I'm not  
sure what other places in the code rely on wide character functionality.

Matthias


utf8.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel