Myanmar Geeks - Burmese Computing Network

Posted: **November 19th, 2007, 10:40 pm**

======================================================================================

QT Acting UTN11?

Code: Select all: #rpm -q qt qt-3.*

I made sure that, I used UniBurma lastest build, which is partial unicode font which has no rendering synchronization by mean of OTL and AAT.

When I prepared guide for KDE Post installation for UniBurma XKB at this post article, and I found out these few strange results. In the following screenshots, I quickly compared the same text data on three different text editors.

Openoffice <> KEdit <> KWrite
Openoffice has ICU, so it is not QT dependent. So, KEdit and KWrite is using KDE native renderer, which is QT. Then you will see the result of same text displaying different result throughout these three editor. KEdit and KWrite is trying to halt with dotted circle 25CC(or probably I guess) for UTN11 statement about Vowel E. Then, I tried to input as logical sequence as UTN11 statement at the follow by line, it re-order on KEdit and KWrite but not on Openoffice. The following happening is what I previously discussed abuout #reor at this aricle, that has to be better handled by renderer side. (But also possible to be done in Opentype and AAT as font side)

need to analyze to dig this.. it nice to know that qt did the job.. but still have to make sure something..
if qt acting well, then it shoould be the first official rendering engine that speak burmese unicode

This is not happening in Gnome, GTK.
I'll be adding more analysis data soon. Pls help your ur way to add in found out. Pls include qt version. Mine is 3+.

http://www.sankholin.com/qt/

Posted: **November 19th, 2007, 11:15 pm**

Hi vic, here is the one we talked about Qt issue on burmese fonts.
i am tested with zawgyi, but uniburma also same results now.
mine is qt 4.3.2, i only tested on windows now.

Posted: **November 19th, 2007, 11:48 pm**

aTxIvG4001 wrote:I am tested with zawgyi, but uniburma also same results now.

Yap, both Zawgyi and UniBurma are partial unicode which do not dependant on renderer.

For quick fix, pls try this, bro.
Whenever converting about "a thet" from Win Innwa (ASCII), pls add one more unicode extra value: U+200C a.k.a \u200C.

Which mean:

Code: Select all: Win Innwa "A Thet" ASCII Value ==> \u1039 \u200C

This is because QT is probably UTN11-1 and "a thet" is only visible when with \u1039 \u200C combination. When you convert from Win Innwa, you will be probably mapping only to \u1039. So, with only \u1039 on UTN11-1--nized QT--ware, it won't draw "a thet" and that's why you cant see "a thet" on converted Maung Maung -- "nga thet".

When you want to let client to copy the converted text data for using with partial unicode font on elsewhere(like fontconv.htm does), again you might need to strip \u200C for being not to be copy over. Because client might use on non-qt system. If you didn't strip, there may extra one glyph carry over and might print out one extra squre box. (Pls test it pratically, I'm not sure thou.)

This is about ASCII ==> UTN11-1 case and one of the similar cases like what I mentioned at Prince Ka Naung topic. But again, if ASCII ==> UTN11-2, it won't need as such again because "a thet" now has its unique code block address in Unicode 5.1, \u103A. Therefore, for Win Innwa to converting UTN11-2 with Unicode 5.1 fonts, its simply like this equation.

Which mean:

Code: Select all: Win Innwa "A Thet" ASCII Value ==> \u103A

========
NOTE: I used "a thet" as simple phonetic tone. With unicode style, it is in "ASAT", visiable virama.

----------
p.s. You seem okay while you are using with Tkinter at this topic. So, you see QT must be something. LoL. So, the question is that how Tkinter and PyQT handle text rendering? You might want to read about this thread from python list where py users are talking about text rendering related issue for GUI..

Posted: **November 20th, 2007, 9:35 am**

victor_lin21 wrote:For quick fix, pls try this, bro.
Whenever converting about "a thet" from Win Innwa (ASCII), pls add one more unicode extra value: U+200C a.k.a \u200C.

Which mean:
Code: Select all
Win Innwa "A Thet" ASCII Value ==> \u1039 \u200C

ok, got it. its make sense.

btw what the difference between \u200C and \u200B, as i known \u200B is zero width space.

regards and thanks,

Posted: **November 22nd, 2007, 12:34 am**

FontConv updated at SVN,

various fonts support now but still having "a that" problem.

even i write "\u1039\u200c" manually its wont show correctly.

Posted: **November 23rd, 2007, 1:59 am**

Mac Screenshot

====

It is 90% confirmed that it is not because of rendering nor the logic sequence. Since, both WinInnwa and Zawgyi/UniBurma are ASCII and partial coded, it will print out no matter QT acting UTN11-1 or not. I confirmed by the following test, on Mac and it is probably Qt/PyQt or coding issue on Window Platform.

Test Scenario #1
Without addin 200C (case1 loop), a thet still printed out.

Test Scenario #2
With addin 200C (case1 loop), a thet still printed out with 200C.

So, we will continue to discuss this issue in this thread.

And, let's discuss more about QT _only_ related found out here to continue.

Posted: **March 14th, 2009, 4:18 pm**

---------- Forwarded message ----------
From: Tin Myo Htet <tmhtet@...>
Date: Feb 8, 2006 2:25 PM
Subject: Re: Fwd: Regarding Myanmar Language Enabling
To: Ngwe Tun <myazedi@...>, Ngwe Tun <ngwestar@...>

Hi Ko Ngwe Tun,
I've compiled qt-3.3.6 successfully and it's working. (pure qt only
not with kde)
Please find attached the screen shot. In the background is the
translation tool "linguist" bundled together with qt and in front is
the i18n example with translated gui. Great!!!!
Some rendering problem in Mr. Lars' snapshot is due to mismatch of my
font's rules and his implementation of opentype feature flag in qt.
Since I've done implemented in pango module for opentype feature flag
(in previous, the default is to check all the feature in the font but
Mr. Lars implemented to check only feature in accordence with
position), it should be OK if he change accordingly.

CU this afternoon,
Myo Htet

On 1/31/06, Ngwe Tun < myazedi@...> wrote:
> Dear Lars,
>
> Now, I got actual URL what you pointed that.
> I'm looking into it. I just have some rendering problem in png file.
>
> I will response back some minor errors next 2 day when I go back to my
> office.
>
> Well, And I will meet with Tin Myo Htet and reply to you soon
>
> Very nice and hardworking implementation for the Myanmar Language.
>
> See you later.
>
> Ngwe Tun
>
>
> On 1/30/06, Lars Knoll <lars@trolltech....> wrote:
> > Hi,
> >
> > On Saturday 28 January 2006 12:28, Ngwe Tun wrote:
> > > Thanks for you implementing on enabling Myanmar KDE.
> >
> > I'm happy to be able to help you there
> >
> > > On 1/24/06, Lars Knoll <lars@trolltech...> wrote:
> > > > You can find the current version of the patch on
> > > > http://anarki.troll.no/~lars/myanmar. You will need a
> recent Qt 3.3.6
> > > > snapshot (which you can get from ftp.troll.no/qt/snapshots/) to be
> able
> > > > to apply and compile the patch.
> > >
> > > I can't go this URL. Please provide actual URL.
> >
> > Sorry, the correct URL is
> http://chaos.troll.no/~lars/myanmar/ . You should
> > find the patch, the copyright assignment text and the screenshot I made
> > there.
> >
> > Best regards,
> > Lars
> >
>
>

Myanmar Geeks - Burmese Computing Network

QT Acting UTN11

QT Acting UTN11

Re: QT Acting UTN11

Re: QT Acting UTN11

Re: QT Acting UTN11

Re: QT Acting UTN11

Re: QT Acting UTN11

Re: QT Acting UTN11