I have been investigating a very troublesome (for me) problem with a money management application called MMEX.
You can read that thread, HERE, but basically, it seems that this problem is particular to OpenSUSE - I have confirmed it working in Ubantu 12.1.
I don’t think that it is an application problem “per se”.
It seems (from my novice view) that it is more likely to be a dependency compatibility problem trying to print unicode characters (Euro, €, 0x20 AE)?
I would be most appreciative, if anyone could suggest any test methods that I could employ to solve this problem.
The MMEX developers (understandably) are more interested in the next generation of their application, so I think that help from that direction has run out.
It is nice that you have it “confirmed it working in Ubantu 12.1”, but please specify the version of openSUSE where you report it is not “working”. And when a desktop environment is used, please also mention whicj one.
The failing build is: OpenSUSE 12.3+KDE 4.10.5, MMEX 0.9.9, HPLIP 3.12.11 and wxWidgets 0.2.8. This is all documented in the original thread over on the MMEX forum and a link was given to keep the my opening post brief.
The mode of failure is: Within MMEX, generate a report. This displays on screen and the Euro symbols display fine. If you then request that the report is printed, it enters a print dialogue. It doesn’t matter if the destination is a file or a physical printer, the application crashes with a debug report. It only crashes if the Notes field contains a unicode symbol that has a leading byte grater than 0x00.
For example the Euro € (0x20 AC), third ⅓ (0x21 53) trademark ™ (0x21 22) Z apostrophe ź (0x10 7A) etc.
An example of a debug report is attached to the thread over on the MMEX forum (can’t see how to attach a file in this forum?).
I do not know your application. I only try to check what you wrote as far as I can check.
I copied the three example characters with copy/paste from your post above in a file. The file shows:
henk@boven:~/test> cat u
€⅓ź
henk@boven:~/test>
In vi, part of the output of the :set command is:
fileencoding=utf-8
The Forums web-site is in UTF-8. Page info of Firefox about this webpage says: Content-Type text/html; charset=UTF-8. All as it should be. Thus IMHO this is all about UTF-8.
Now look at the following:
henk@boven:~/test> od -x u
0000000 82e2 e2ac 9385 bac5 000a
0000011
henk@boven:~/test>
These are the bytes of that file with the UTF-8 encoded Unicode characters. Because bytes are in the “wrong” sequence in a word, this should be read as:
e2 82 ac e2 85 93 c5 ba 0a 00
Even a short glance at this shows me that that is very different from what you say in your post above.
When we decode this into Unicode code points, we get:
As character names:
U+20AC EURO SIGN character (€)
U+2153 VULGAR FRACTION ONE THIRD character (⅓)
U+017A LATIN SMALL LETTER Z WITH ACUTE character (ź)
U+000A <control> character
U+0000 <control> character
Which is indeed what you mention. But it is the UTF-8 encoded bytes that should be in the file, not the Unicode points. When you realy have those two byte sequences in your file I can imagine that something goes wrong (though an error message of some kind is preferable above a crash >:)).
I’m not sure that I fully understand your line of enquiry. It is not what I type into these forum messages, that is only to try and illustrate my problem.
If I have used the incorrect terms: Unicode instead of UTF-8, I apologize.
If I limit my test cases to a pound sign “£” and a euro sign “€” does that help?
A print task with a euro sign in it, processed under OpenSUSE 12.3 crashes. The same task with the pound sign replacing the euro sign, does not.
A print task with a euro sign in it, processed under Ubantu 12.1 (all other variables the same) does not crash.
I do not pretend to understand how this extended character issue works (or in my case - does not work!), but in real life, I type a euro character into the Notes field of MMEX ( SQLite), I see a € sign on my screen. I then request a report that includes that Notes field. On screen, it displays correctly, but on the way to a postscript file or physical printer that euro sign causes the application to crash.
The above is a rather explaining description of what you experience. But earlier you added hex codes as if you had found those in the file to be printed. I now understand that this is not the case.
martinprowe wrote:
> gogalthorp;2597383 Wrote:
>> Run the app from a console and maybe you will see errors when it
>> crashes. Might help pinpoint the problem
>
> Thank you. Good idea. Done that.
>
> # MMEX --verbose
>
> Output reported over on the MMEX forum. No interest from them when I
> asked for the meaning of:
>
>
> Code:
> --------------------
> (mmex:27324): Gtk-CRITICAL **: IA__gtk_widget_get_direction: assertion `GTK_IS_WIDGET (widget)’ failed
> --------------------
>
> Again this is not seen when repeated in Ubantu 12.1
>
> Any ideas?
Well this time you didn’t even provide a link to where you posted the
output and I’m not going to chase around looking for it. It would help
if you posted it here if you want us to help.
But since it seems it might be a GTK problem, what are the versions of
any and all GTK components on the two systems?
You could also try turning on some GTK debug options, again from a
terminal. There’s some information at: