Regression: trunk fails to produce correct Unicode (with ^U) for some characters

[David Mathog]

Downloaded devlibs and trunk yesterday using bzr and built them on Windows XP SP3.

Discovered today that unicode entry using the ^U method does not work for some characters. For instance, try to enter
"delta" as ^U3b4<return> inserts nothing. However ^U60<return> inserts a "<".

Going back to a trunk version built from trunk downloaded on 1/23/12 ^U method was working for all characters tested.

Hmm, most ^U numbers work in the most recent version, but not 3A0 - 3FF. 39F and below works, 400 and above works. Wait, not so fast. Characters are appearing in the range U370-U39F, but they are not the right characters:

http://www.unicode.org/charts/PDF/U0370.pdf

For instance, U372 is supposed to be a sort of T shape, but what appears is a capital W with a caret over it.

The version built from 1/23/12 source works correctly for all characters tested in the range 370-3ff.

Looks like something broke in the last month or so, and it seems to be quite specific for greek letters.

[David Mathog (mathog)]

The font used for the preceding tests was Arial.

[David Mathog (mathog)]

The problem extends much further. Codes U180-U24F (generally) result in visible characters, but they are the wrong visible characters.

U190 gives the "3/4" character.
U191 gives the upside down "?" character

These I can probably find, looking them up.. Oh crud 190 DECIMAL is the "3/4" character, 191 DECIMAL is the "?" character.

Looks like ^U has started using decimal numbers instead of hex. 372X -> 882. Plug in ^U882 and, bingo the expected T character.

Evidently in the last month the ^U mechanism has gone from using hex to using decimal!

[David Mathog (mathog)]

text-context.cpp in two places has something like this:

    std::stringstream ss;
    ss << tc->uni;
    ss >> uv;

where it used to have something like this:

    sscanf(tc->uni, "%x", &uv);

That looks like it might be the issue. Reverting and recompiling now...

[David Mathog (mathog)]

Rather than reverting I modified the existing code to use the "hex" basefield format flag. That fixed the problem. I am not sure which of the two methods was at fault, but changing both fixed this. diff -u attached

[David Mathog (mathog)]

This bug would presumably affect all versions, not just windows.

[su_v (suv-lp)]

On OS X 10.7.2:
Not reproduced with
- Inkscape 0.48+devel r10923
Reproduced with
- Inkscape 0.48+devel r10935, as well as latest r11034

Probably introduced in r10932:
<https://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/10932>

The same revision also changed a format string in 'src/extension/internal/gimpgrad.cpp' which produces these compiler warnings:
  CXX extension/internal/gimpgrad.o
extension/internal/gimpgrad.cpp: In member function 'virtual SPDocument* Inkscape::Extension::Internal::GimpGrad::open(Inkscape::Extension::Input*, const gchar*)':
extension/internal/gimpgrad.cpp:225:71: warning: unknown conversion type character '.' in format [-Wformat]
extension/internal/gimpgrad.cpp:225:71: warning: unknown conversion type character '.' in format [-Wformat]
extension/internal/gimpgrad.cpp:225:71: warning: too many arguments for format [-Wformat-extra-args]

See also launchpad build bot log, e.g. for r11034:
<https://launchpadlibrarian.net/84636368/buildlog_ubuntu-precise-amd64.inkscape_1%3A0.48%2Bdevel%2B10729%2B25~precise1_BUILDING.txt.gz>

[su_v (suv-lp)]

@Kris - could you review your changes in r10932 and restore Unicode input for the text tool?
<http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Text-Creating.html#id3273531>

[Kris (kris-degussem)]

The issue should be fixed now (revision 11035).
Sorry for the inconvenience and thanks for the fix David.