Cannot write non-latin characters in Scribus

I can confirm the problem with scribus-ng (1.3.3.4).

If I enter Chinese with SCIM, sometimes it crashes, and it never seems to accept the Chinese. Same with scribus (1.2.4.1). If I type Chinese surrounded by English, the English shows up, but not the Chinese. However, if I load a text file into the Story Editor (utf-8), it seems to work fine. Also, if I copy it from gedit and paste it into the Story Editor, it works as well. I suspect it is the way SCIM is inputting characters into the qt framework. Scribus complains:
"WARNING: please edit ~/.scim/global and change /DefaultConfigModule to kconfig"

A work-around would be to type into gedit and paste into the scribus StoryEditor, or save as a text file and load them into the StoryEditor.

Regarding abiword - it seems to be because Abiword doesn't do font substitution. Highlight those circles and choose a font that contains Chinese characters and it will work fine. This is not really a bug. There are times I don't want font substitution.

Openoffice.org also supports Chinese.

Thirdly, regarding lyx - I don't even know if it supports unicode. If you need TeX quality typesetting, a good flavor that supports Unicode and TrueType fonts (sorry, no GUI) is XeTeX which supports Chinese, and even vertical typesetting with vertical font metrics. Search for XeTeX for Linux.

The bug with scribus, however, still stands.

Lyx does not support CJK unless patched. The patches for CJK support tend to cause trouble.

Thanks for your report.
Some improvements has been made to scribus in 1.3.4 and 1.3.5svn regarding Chinese and Japanese support. Can you try with latest Ubuntu release? Thanks in advance.

Launching scribus-ng on Hardy (scribus-ng 1.3.4.dfsg+svn20071115-1ubuntu1), story editor defaults to font Arial Regular
I type in Chinese, hit RETURN, and it crashes with "Scribus crashes due to Signal #6"
sent to console:
sending IMEnd with 3 chars to 0x915a5a8, text=???
sending IMStart with 0 chars to 0x915a5a8
sending IMCompose to 0x915a5a8 with 0 chars, cpos=0, sellen=0, text=
sending IMEnd with 0 chars to 0x915a5a8, text=
scribus-ng: /build/buildd/scribus-ng-1.3.4.dfsg+svn20071115/scribus/text/storytext.cpp:307: void StoryText::insertChars(int, QString, bool): Assertion `pos <= length()' failed.
Scribus Crash
-------------
Scribus crashes due to Signal #6
QGArray::at: Absolute index 12 out of range

If, however, I change the font in the Story Editor to AR PL UKai CN Book， it has no problems. This is exactly how it behaved earlier. If the font does not support the characters, the story editor it rejects them and scribus becomes unstable. If I copy and paste in, it works fine, even with a non-chinese font. Then the main screen shows squares where the font does not support the characters. And the story editor still shows the characters. So the problem is entirely how the story editors works with input. If I try to input into the text box directly, I am unable to type any Chinese.

I think this is a known problem: http://bugs.scribus.net/view.php?id=4305

Yes, this is a well known issue upstream.
All problems related to support for non latin character in Scribus are referred in a metabug at http://bugs.scribus.net/view.php?id=3965.
You should directly comment on upstream bug reports.

Thanks again.

Confirm we can't write with iBus in ScribusNG 1.3.8

WORKAROUND : write your text in a text editor (Gedit for example), then copy/paste it in Scribus.

See if installing ibus-qt makes it works. If so, it should be marked as a dependency if you use ibus and qt apps.

Thank you for taking the time to report this bug and helping to make Ubuntu better. We are sorry that we do not always have the capacity to look at all reported bugs in a timely manner. There have been many changes in Ubuntu since that time you reported the bug and your problem may have been fixed with some of the updates. It would help us a lot if you could test it on a currently supported Ubuntu version. When you test it and it is still an issue, kindly upload the updated logs by running `apport-collect 67882` and any other logs that are relevant for this particular issue.

Furthermore, Edgy reached EOL on 2008-04-26.
See this document for currently supported Ubuntu releases: https://wiki.ubuntu.com/Releases

I've tried recreating this bug with Trusty and was unable to, given the information you've provided. Please upgrade to the latest version and re-test. If the bug is still reproducible please do what I write above.

Do feel free to report any other bugs you may find.

Invalidating the bug.
A lot of time passed since my last request, and the problem is totally upstream.
(the auto-expire thingy does not work here because of the remote tracker)