Re: [Denemo-devel] New Binaries?

On Tue, Jun 16, 2015 at 1:55 PM, Richard Shann <address@hidden> wrote:

On Tue, 2015-06-16 at 12:14 -0500, Jeremiah Benham wrote:
>
>
> 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="<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.
>
>
> 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 𝄞 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.

If it fails to update, (stays as the ascii you had before) the we can't
be sure what the text entry widget is returning.

If it updates to D834 in a box, then we can guess that it is the
text_entry widget that is returning a UTF_16 string which the
gtk_label_set_markup() function is failing to display.

Perhaps, nailing down what the mis-match is won't be as important as
getting the right set of libraries that work together on the Mac. We
don't know if the Mac code is supposed to be using UTF_16 or 8,

I read on a few websites mac is big endian utf-16. I don't know for sure if that is correct because it wasn't like any official mac website or anything.

Thanks for your help.

Jeremiah

whatever
it is, should be consistent between the GtkLabel and GtkEntry widgets.

Richard

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

From:	Jeremiah Benham
Subject:	Re: [Denemo-devel] New Binaries?
Date:	Tue, 16 Jun 2015 22:12:40 -0500