View Issue Details

IDProjectCategoryView StatusLast Update
0010322ScribusStory Editor / Text Framespublic2016-04-11 19:45
Reportermonaka Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status newResolutionopen 
Product Version1.4.0svn 
Summary0010322: Enable the inline editing with input method engine.
DescriptionWe couldn't do inline editing with Input Method Engines (IME) for a long time.
I attach a patch to fix this issue.
It might this patch will fix a part of issue 0008471 .

I've tested with no trouble on OSX 10.6.8, Kotoeri (Apple's genuine IME), Google Japanese Input.
Steps To Reproduce1. Open StoryEditor.
2. Type characters with any InputMethod.
Additional InformationThere seems no trouple but the patch should be reviewed cautiously because I'm not familiar to Qt.
TagsCJK, discussion, HOST-Oman
PatchNo

Activities

monaka

2011-10-16 11:47

reporter  

0001-Fix-to-enable-the-inline-editing-with-input-method-e.patch (1,600 bytes)   
From 5cebcf89e045ce4bc98dd8d1ae7dc4b9f86e082f Mon Sep 17 00:00:00 2001
From: Masaki Muranaka <monamour@monaka.org>
Date: Sun, 16 Oct 2011 20:30:19 +0900
Subject: [PATCH] Fix to enable the inline editing with input method engines.

---
 Scribus/scribus/ui/storyeditor.cpp |    8 +++-----
 1 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/Scribus/scribus/ui/storyeditor.cpp b/Scribus/scribus/ui/storyeditor.cpp
index 4abe806..487545b 100644
--- a/Scribus/scribus/ui/storyeditor.cpp
+++ b/Scribus/scribus/ui/storyeditor.cpp
@@ -282,14 +282,12 @@ void SEditor::setCurrentDocument(ScribusDoc *docc)
 void SEditor::inputMethodEvent(QInputMethodEvent *event)
 {
 	QString uc = event->commitString();
-	if ((!uc.isEmpty()) && ((*doc->AllFonts)[CurrFont].canRender(uc[0])))
+	if (!uc.isEmpty() && (uc[0] == '\n'))
 	{
-		// Should be processed by the handleContentsChange slot
-		// insertCharsInternal(event->commitString());
-		QTextEdit::inputMethodEvent(event);
 		emit SideBarUp(true);
 		emit SideBarUpdate();
 	}
+	QTextEdit::inputMethodEvent(event);
 }
 
 void SEditor::keyPressEvent(QKeyEvent *k)
@@ -451,7 +449,7 @@ void SEditor::handleContentsChange(int position, int charsRemoved, int charsAdde
 		{
 			QTextCursor cursor = textCursor();
 			cursor.setPosition(position);
-			cursor.setPosition(position + charsAdded, QTextCursor::KeepAnchor);
+			cursor.setPosition(position + charsAdded - charsRemoved, QTextCursor::KeepAnchor);
 			QString addedChars = cursor.selectedText();
 			if (addedChars.length() > 0)
 				StyledText.insertChars(position, addedChars, true);
-- 
1.7.3.2

monaka

2011-10-16 11:56

reporter   ~0027020

This is a big issue for the people that uses input methods like Japanase, Korean, Chinese, and so on.
So this should be fixed until 1.4.0 official release.
Please tell me in case it's required more technical information.

jghali

2011-10-16 17:34

administrator   ~0027023

I did some basic tests with that patch. Unfortunately i cannot commit it in current state :
- at least the change in handleContentsChange() is broken : tests shows that discrepancies between the story editor content and the text frame content quickly appears.
- the change in SEditor::inputMethodEvent() breaks intended behavior : if current font does not contain the necessary glyphs, input must be prevented.

monaka

2011-10-17 00:56

reporter   ~0027026

Last edited: 2011-10-17 00:57

hello, jghall.
Thanks for your review. I have a request and a question.

request:
Could you show me your test case?

question:
I see the current behavior of SEditor::inputMethodEvent(). And is it reasonable?
For example, notepad.exe doesn't care glyphs. GUI version emacs also.
And users can modify the font that does not contain required glyphs after he typed.
So I think the current behavior is not reasonable.

jghali

2011-10-17 09:22

administrator   ~0027029

Last edited: 2011-10-17 11:57

>> Could you show me your test case?

- Open story editor
- Insert some text
- Select 3 characters
- Type 1 characters
- Update text frame
=> The text frame content does not match story editor content anymore

>> I see the current behavior of SEditor::inputMethodEvent(). And is it reasonable?

Very reasonable. Remember that contrary to notepad or emacs Scribus output is mainly intended at being printed on press. And a reprint because of missing glyphs will cost hundreds of dollars.

monaka

2011-10-17 12:27

reporter   ~0027031

Thanks for showing your test case. I'll try it later and re-produce the another patch.


> Very reasonable. Remember that contrary to notepad or emacs Scribus output is mainly intended at being printed on press. And a reprint because of missing glyphs will cost hundreds of dollars.

I have one question. Have you press contents that written in multi-byte characters?

I agree that repaint causes a lot of costs as you say. But the current behavior cannot avoid risks you say.
In case the user change the font after he typed, he will pay a lot of costs.
Indeed there have some treat to avoid this kind of risks on WYSIWYG editor like write.exe, word.exe, OpenOffice Writer/Impress and so on. Maybe QuarkExpress and/or InDesign also.
But their solutions are not similar to the current version of Scribus.

ale

2011-10-17 16:39

manager   ~0027033

i think that enforcing good workflows is not that a bad idea...

but i don't know how people people manage languages with multi-byte characters...

JLuc

2011-10-17 17:09

developer   ~0027036

Checking missing glyphs should happen during the checking process that is launched when printing or PDF export is requested... or be checked in every operations that affects content or fonts, including font change.

monaka

2011-10-18 01:10

reporter   ~0027040

I also don't know all WYSIWYG applications in the world.
But almost all applications have similar approach.
They have "default font". It covers almost all glyphs for user's language in the default font. It is converted to the default font by the application in case the user types the character which glyph is not supported by selected font.
The default font will be language and runtime specific. For example, Hiragino or Osaka will be used in OSX/Japanese. MS Mincho and/or Meiryo will be used in Windows/Japanese.

Anyway I don't know the application that reject user's input depends his font selection except Scribus.
So I think it's not reasonable.


Though...
It's impractical to support in 1.4.0 as it'll be a major modification to support "default font".
My suggestion for the current version is to cut the glyph checking in inputMethod off.
The user will need to check glyphs and select fonts before press regardless of input time checking.

Kunda

2016-04-11 19:40

updater   ~0040088

monaka, if you're still around, please help us test CJK texts in https://github.com/HOST-Oman/scribus/issues/143

Issue History

Date Modified Username Field Change
2011-10-16 11:47 monaka New Issue
2011-10-16 11:47 monaka File Added: 0001-Fix-to-enable-the-inline-editing-with-input-method-e.patch
2011-10-16 11:56 monaka Note Added: 0027020
2011-10-16 17:34 jghali Note Added: 0027023
2011-10-17 00:56 monaka Note Added: 0027026
2011-10-17 00:57 monaka Note Edited: 0027026
2011-10-17 09:22 jghali Note Added: 0027029
2011-10-17 11:57 jghali Note Edited: 0027029
2011-10-17 12:27 monaka Note Added: 0027031
2011-10-17 16:39 ale Note Added: 0027033
2011-10-17 17:09 JLuc Note Added: 0027036
2011-10-18 01:10 monaka Note Added: 0027040
2015-09-17 20:08 Kunda Category Story Editor / Text Frames => Story Ed/Txt Frames
2015-09-17 20:12 Kunda Category Story Ed/Txt Frames => Story Editor / Text Frames
2016-04-11 19:37 Kunda Tag Attached: CJK
2016-04-11 19:40 Kunda Note Added: 0040088
2016-04-11 19:40 Kunda Tag Attached: discussion
2016-04-11 19:40 Kunda Tag Attached: HOST-Oman
2016-04-11 19:45 Kunda Patch => No
2016-04-11 19:45 Kunda Severity major => minor