unreadable char widgets when reopening an RTL box file

[GoogleCodeExporter]

What steps will reproduce the problem?

1. generate a boxfile with tesseract, open the couple image-box in 
pyTesseractTrainer

2. do whatever needed in pyTesseractTrainer, save and close

3. Reopen the image-box couple in pyTesseractTrainer

What is the expected output? What do you see instead?

I would like to see readable chars in the widgets on the lower part of the 
screen, to go on working. Instead, most chars have almost zero width and are 
unreadable (see attached)

What version of the product are you using? On what operating system?

pyTesseractTrainer-1.02.py Ubunto 10.04

Please provide any additional information below.

If it is not evident, I'm training for a RTL language. It is quite likely that 
the opposite-sided width is confusing the widget - in fact the few LTR 
characters are displayed ok.

Original issue reported on code.google.com by ohelshai@gmail.com on 1 Jan 2011 at 11:46

Attachments:

• reopening.png

[GoogleCodeExporter]

Please send me image file and original box file and corrected file.

Original comment by zde...@gmail.com on 2 Jan 2011 at 1:01

[GoogleCodeExporter]

Attached the example of above (but the behavior is generic).
To be clear: the visualization is wrong if I just close pyTesseractTrainer and 
reopen it, there is no need of generating a different version of the box file.

[logged in from wrong account last time]

Original comment by enrico.s...@weizmann.ac.il on 2 Jan 2011 at 7:58

Attachments:

• pangrams-stam.png
• pangrams-stam.box

[GoogleCodeExporter]

thanks. I found out that RTL text in gtk.enty "receives" layout-offset... (in 
case of LTR chars it is ok). At the moment I am not able to identify where is 
problem, because there is no offset definition or something unusual...

Original comment by zde...@gmail.com on 4 Jan 2011 at 8:20

• Changed state: Accepted

[GoogleCodeExporter]

try this version
http://pytesseracttrainer.googlecode.com/files/pyTesseractTrainer-1.03.py

Original comment by zde...@gmail.com on 4 Jan 2011 at 10:00

[GoogleCodeExporter]

First check: now it looks perfectly ok.
With one additional bonus: cpu usage before opening an image is 0%. I'll report 
that for consistency also in issue #10

Original comment by enrico.s...@weizmann.ac.il on 4 Jan 2011 at 10:39

[GoogleCodeExporter]

Original comment by zde...@gmail.com on 5 Jan 2011 at 7:43

• Changed state: Fixed