Re: [Denemo-devel] New Binaries?

[Jeremiah Benham]

On Tue, Jun 16, 2015 at 10:22 AM, Richard Shann <address@hidden> wrote:

>         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="&lt;span font='16'&gt; &#x1D11E;   &lt;/span&gt;"
>
>         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.

I have done this and it fails.  It has the letters D834 like the others. I thought we tested this already.

Jeremiah

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
>
>         >
>
>
>