Re: Heureka! (Was: Some chord symbols still broken in 2.5.19)
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)
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