> Another example is the first button in the general palette, > the one at > the top of the display. That is a treble clef sign in a large > size, its > label is this > > <span font='16'> 𝄞 </span> > > That one displays as D834 in your screenshot. I can only guess > that on > the Mac these embedded characters are being expected in a > different > format (UTF-16 instead of UTF-8 ?). > Looking in the source of this label, the file > actions/palettes.xml I see > > label="<span font='16'> 𝄞 </span>" > > which means that 0x1D11E is the character code being inserted, > this is > what is called the unicode codepoint (I think what would be > written U > +1D11E). I don't know what else might work in that position. > Looking up > this unicode value I see that its UTF-16 representation is > > > D8 34 DD 1E > > which hints to me that the (gtk routines for) the mac is just > seeing the > D834 bit - which would explain why your screenshots seem to > show this > same code on several buttons - they are all in the musical > instruments > block, which is perhaps what the D834 refers to (the bass > clef, for > example, is D8 34 DD 22 in UTF-16). >
> Can we convert the UTF-16 to UTF-8? Something like: > https://developer.gnome.org/glib/stable/glib-Unicode-Manipulation.html#g-utf16-to-utf8 > > Are these characters expected to be UTF-16 in windows? > I used gdb to stop Denemo just as it is making the call to write the label on a palette button. this is in palettes.c at line 257 257 gtk_label_set_markup (GTK_LABEL (label_widget), newlabel); I then enquired what bytes were contained in the string newlabel that is being passed to that function. On my Debian windows system, the bytes are these: 0xF0 0x9D 0x84 0x9E Looking this up, I see that this is the UTF-8 encoding for the treble clef sign (𝄞) which has the unicode value U+1D11E So, the text entry widget is returning a UTF-8 string representation for the text you enter into it on Debian. Specifically if you paste 𝄞 the text entry widget returns a pointer to the bytes 0xF0 0x9D 0x84 0x9E 0x00. We don't know what bytes that widget is returning on the Mac but one guess is that it is returning 0xD8 0x34 0xDD 0x1E 0x00 that is it is returning the UTF-16 encoding. I tried setting newlabel to have this value 0xD8 0x34 0xDD 0x1E 0x00 from inside gdb and this caused a warning Gtk - WARNING : Failed to set text from markup due to error parsing markup: Error on line 1 char 13: Invalid UTF-8 encoded text in name - not valid '�4�" Because of this, it fails to update the label. So (in Debian) the call to gtk_label_set_markup() is expecting a UTF-8 encoded string and fails when given the string 0xD8 0x34 0xDD 0x1E 0x00 (label is not written to). So, if you are able to test on the Mac, do Right click on a palette button Edit Label delete all the text and paste in a single 𝄞 character press enter and see if the label updates to a box with D834 in it, or if it fails to update. Richard > > Jeremiah > > > I'm not sure what the way through all this is, perhaps asking > someone in > the gtk mac world about the representation of characters - or, > if gtk2 > works, then something in the upgrade documentation for gtk3 > might help. > > Richard > > > > > > _______________________________________________ Denemo-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/denemo-devel
