Re: [Denemo-devel] New Binaries?

[Richard Shann]

On Tue, 2015-06-16 at 22:12 -0500, Jeremiah Benham wrote:
>         > I have done this and it fails.  It has the letters D834 like
>         the
>         > others. I thought we tested this already.
>         
>         
>         Sorry, what you have written is ambiguous: did it fail to
>         update the
>         label, or did it update it to become D834 in a box?
> 
> 
> It had the rasterized [D834] letters in a []. It was not a font. 
> 
>   
>         (That is, to test, start with a label that works, just ascii,
>         and then
>         try to edit it to be the single &#119070 character).
> 
> 
> I tried that for a while a sifted through a bunch of symbols that I
> could not locate in the denemo.ttf or anything. I was navigating in
> the dark.


I'm sorry, we are still not understanding each others communications
here: I asked "did it fail to update the, or did it update it to become
D834 in a box?"
You replied that "It had the rasterized [D834] letters in a []" without
saying if it had updated the label to that or whether that was what was
there already and it had failed to update the label.

And then, when it suggested testing label update by starting with a
plain ASCII label and pasting in the treble clef character I think you
understood me to be suggesting you look through the character map of
denemo.ttf. It is *very* difficult to locate a given character just by
looking, you need a tool that displays just the Musical Symbols block
and then you can scroll over. But this isn't what I was thinking of -
I've already checked that denemo.ttf does have the correct symbol at the
correct place, with all the correct encodings. What I was trying to
understand is if the gtk_label_set_markup() call on line 257 is passing
in a wrongly encoded string. On Debian this results in a warning, while
I guess there is no warning on Mac and instead it displays [D834]. I
think what you have found (see other email) is that when it displays
[D834] is is being passed 0xF0 0x9D 0x84 0x9E 0x00 (the UTF-8 encoding).
If that is true then the conversion to UTF-16 that results in it
displaying [D834] is being done in some backend and doesn't really
concern us and we would be back to asking if it has found the correct
font. *BUT* I am most suspicious of the libxml2 string import format at
the moment (see other email).

HTH

Richard