View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0010322 | Scribus | Story Editor / Text Frames | public | 2011-10-16 11:47 | 2016-04-11 19:45 |
Reporter | monaka | Assigned To | |||
Priority | normal | Severity | minor | Reproducibility | always |
Status | new | Resolution | open | ||
Product Version | 1.4.0svn | ||||
Summary | 0010322: Enable the inline editing with input method engine. | ||||
Description | We 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 Reproduce | 1. Open StoryEditor. 2. Type characters with any InputMethod. | ||||
Additional Information | There seems no trouple but the patch should be reviewed cautiously because I'm not familiar to Qt. | ||||
Tags | CJK, discussion, HOST-Oman | ||||
Patch | No | ||||
|
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 |
|
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. |
|
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. |
|
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. |
|
>> 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. |
|
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. |
|
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... |
|
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. |
|
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. |
|
monaka, if you're still around, please help us test CJK texts in https://github.com/HOST-Oman/scribus/issues/143 |
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 |