Bug 616277

Summary: hangul text color is not properly set in kwrite
Product: [Fedora] Fedora Reporter: fujiwara <tfujiwar>
Component: ibus-qtAssignee: fujiwara <tfujiwar>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 13CC: i18n-bugs, ktakemur, llim, psatpute, shawn.p.huang, tfujiwar
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: ibus-qt-1.3.0-2.fc13 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 608966 Environment:
Last Closed: 2010-08-13 21:15:15 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 608966    

Description fujiwara 2010-07-20 01:46:15 UTC
+++ This bug was initially created as a clone of Bug #608966 +++

Description of problem:
A Hangul character entered by using iBus with Korean Input method in kwrite application is displayed in white colour text before pressing space or enter or next character.
If space or enter key is pressed or next character is typed, it appears in black colour.

Version-Release number of selected component (if applicable):

kdebase-4.3.4-4.el6.x86_64
ibus-hangul-1.3.0.20100329-1.el6.x86_64
ibus-1.3.3-1.el6.x86_64

How reproducible:

Every time

Steps to Reproduce:
1.Install kdebase by yum
2.Launch kwrite
3.Turn iBus on in kwrite
4.Type a hangul
  
Actual results:

A hangul character is in white font colour which is hard to see.

Expected results:

A hangul character is in default font colour(black)

Additional info:

Entering English or Japanese in kwrite works fine for this problem.

--- Additional comment from pm-rhel on 2010-06-29 00:11:06 EDT ---

Since this issue was entered in bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.

--- Additional comment from pm-rhel on 2010-06-29 00:22:53 EDT ---

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

--- Additional comment from dueno on 2010-06-29 03:44:49 EDT ---

I can reproduce it even on Fedora 13, if ibus-qt is installed (screenshot attached).  ibus-hangul uses white/black (fg/bg) for preedit text and requests these settings to applications via ibus-qt.  However, the KTextEdit control (which kwrite uses) overrides the bg setting.

The solution would be to make KTextEdit (kdelibs) not overwrite existing text attributes, but it might not be easy.  Another solution is to choose reasonable default colors for ibus-hangul preedit as in other IME.

--- Additional comment from dueno on 2010-06-29 03:46:54 EDT ---

Created an attachment (id=427599)
screenshot when I type "rlagrlagrla" with ibus-hangul on kwrite

--- Additional comment from psatpute on 2010-07-12 02:42:23 EDT ---

same problem is occurring in ibus-rawcode as well
see https://bugzilla.redhat.com/show_bug.cgi?id=613520

i think we should fix this from ibus-qt side, so will no need to change all ime-engine's code

--- Additional comment from tfujiwar on 2010-07-13 01:57:58 EDT ---

rf. https://bugs.kde.org/show_bug.cgi?id=241085

--- Additional comment from tfujiwar on 2010-07-16 05:10:25 EDT ---

I could reproduce this problem.
I almost understood the root cause. Will update the evaluation later.

--- Additional comment from psatpute on 2010-07-16 06:30:35 EDT ---

I just saw on fedora 13 with kdebase 4.4.5-1, this problem is not coming. 
Tested for ibus-rawcode

--- Additional comment from tfujiwar on 2010-07-19 21:31:12 EDT ---

(In reply to comment #9)
> I just saw on fedora 13 with kdebase 4.4.5-1, this problem is not coming. 
> Tested for ibus-rawcode    

I can reproduce the same bug in f13 kdebase 4.4.5-1 and f14.


ibus-hangul's engine sets foreground is white and background is black.
The problem is, the foreground color only is set in the actual preedit GUI but the background color is lost and this causes both the foreground and the background color are white and users cannot read the preedit text.

kdelibs-4.3.4/kate/render/katerenderer.cpp:

QList<QTextLayout::FormatRange> KateRenderer::decorationsForLine( const KateTextLine::Ptr& textLine, int line, bool selectionsOnly, KateRenderRange* completionHighlight, bool completionSelected ) const
{
        fr.format = *a;
}


It seems kde kate rendering get one format only.
But ibus-qt sends multiple formats with QAttribute.

The solution is ibus-qt has one format only and it can have both foreground and background colors.

The suggested patch:
http://github.com/fujiwarat/ibus-qt/commit/5fa9738dc4147f11abc420efc217c4c6e7029b77

Comment 1 fujiwara 2010-07-21 05:19:32 UTC
Yesterday I discussed with the maintainer.
His point was ibus-pinyin and ibus-anthy also don't show the preedit correctly and the root cause is same but my patch fixes the reported issue only.
So I'll have the furthermore investigation. I'll compare the qt/kde with the old ones to know what was the regression. Set Need Info to me.

Need much build time...

Comment 2 fujiwara 2010-07-22 07:00:12 UTC
I tried the old qt/kde which showed the preedit text with colors but QApplication::x11ProcessEvent() didn't call IBusInputContext::x11FilterEvent() so the preedit was drawn by the default colors but IBus colors.
E.g. IBus active preedit color is purple in ibus-anthy/ibus-pinyin but the old one was black.

So actually this bus is not a regression but a feature to use inputmethod colors.
I think revering the KDE/QT codes doesn't make sense to resolve this issue.

The previous patch fixes ibus-hangul and ibus-rawcode issue, i,e, in case the drawing ranges are same.

But ibus-anthy and ibus-pinyin provides the different ranges.
underline is all preedit range.
purple background color is active lookup table range.

The bug is, ibus-anthy doesn't show the purple color.

I understood the KDE implementation:

kdelibs-4.3.4/kate/view/kateviewinternal.cpp:
void KateViewInternal::inputMethodEvent(QInputMethodEvent* e)
{
    int decorationColumn = 0;
    foreach (const QInputMethodEvent::Attribute &a, e->attributes()) {
      if (a.type == QInputMethodEvent::Cursor) {
      } else if (a.type == QInputMethodEvent::TextFormat) {
        QTextCharFormat f = qvariant_cast<QTextFormat>(a.value).toCharFormat();
        if (f.isValid() && decorationColumn <= a.start) {
          decorationColumn = a.start + a.length;
        }
      }
    }
}

The decorationColumn checks if the next format doesn't have the duplicated start point a.start.

In ibus-anthy, underline is whole the preedit length and lookup table(purple color) is one segment in preedit and the a.start is duplicated and the color formats are ignored.

I.e. KDE doesn't support the layered colors in preedit.
If we would send the multiple KateViewInternal::inputMethodEvent(), the last update is effective and the colors would be overrided.

The solution is that ibus-qt changes the layered colors to segment colors.
E.g. first segment is underline, purple background, black foreground.
     other segments are underline only.
So if the ranges are same, I think the formats should be consolidated to one format.

Revised the patch:
http://github.com/fujiwarat/ibus-qt/commit/7233a42974d959069f7399c85dcc97275fcfd86e

Comment 3 fujiwara 2010-07-22 07:08:06 UTC
typo:

(In reply to comment #2)
> so the preedit was drawn by the default colors but IBus colors.

so the preedit was drawn by the default colors not IBus colors.

> So actually this bus is not a regression but a feature to use inputmethod
> colors.

So actually this bug is not a regression but a feature to use inputmethod colors.

Comment 4 fujiwara 2010-07-23 01:12:50 UTC
Thanks for the review.
Revised the patch:
http://github.com/fujiwarat/ibus-qt/commit/9145e97544dcf49a02939fbac6c289758ff09218

Comment 5 fujiwara 2010-07-23 01:22:41 UTC
I'll integrate the patch into rawhide for the test purpose.

Comment 6 fujiwara 2010-07-23 03:15:41 UTC
Integrated the fix in rawhide:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2345562

It seems the patch is also upstreamed, thanks.

Comment 7 fujiwara 2010-07-23 03:47:27 UTC
Probably it's good to integrate the fix in f13.

Comment 8 fujiwara 2010-07-23 04:31:17 UTC
Integrated in f13:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2346026

Comment 9 Fedora Update System 2010-07-23 04:37:30 UTC
ibus-qt-1.3.0-2.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/ibus-qt-1.3.0-2.fc13

Comment 10 Fedora Update System 2010-07-27 02:27:18 UTC
ibus-qt-1.3.0-2.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update ibus-qt'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/ibus-qt-1.3.0-2.fc13

Comment 11 Fedora Admin XMLRPC Client 2010-08-02 06:23:35 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 12 Fedora Update System 2010-08-13 21:15:10 UTC
ibus-qt-1.3.0-2.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.