Problem with full-width (asian) punctuation

If I have an East-Asian character in my (predominantly English) document, followed by a quotation mark (opening or closing), the quotation mark uses the full-width version (and it takes the font settings from the “Asian text font” section of the style definition).

For example (see attachment):

if I have the text

日 “sun”

in my document, the opening will be full-width and in a Chinese font (regardless of whether or not I have a space between the character and the quotation mark – note that the space is normal width…). If I have

日, “sun”

(with the comma) then all is fine.

image description

The only way I can solve this problem is to use direct formatting to force the opening quotation mark to use my “Western text font” (and the appropriate size), which is brittle and not very satisfactory. Is there a setting somewhere that I’ve over-looked? Or does this seem like a bug that I ought to file?

I would be most grateful for any assistance / advice / suggestions.


Apologies if I didn’t make this clear: this problem is not to do with the input method I am using; it concerns the rules according to which LO applies the “Western text font” and “Asian text font” settings. Following a logic I can only describe as “buggy”, LO formats the (normal-width, western) space and opening quotation mark immediately before the Latin letter “s” according to the “Asian text font” setting.


Bug #66791 filed.
I suspect bug #60106 is related too.

I am out of ideas for now. I think it may be best if you raise a bug. If you are switching modes as you indicate, then you should not be seeing the illustrated behaviour. The fact that you are seeing the same behaviour via a variety of input methods would seem to support this. Please include as much detail as possible in your bug report and link to this thread. You can post the bug number in a comment or answer using the format “fd0#123456”.

Thanks – I don’t entirely follow what you mean by “fd0#123456”: ought that to be automatically marked-up? because I can’t seem to get that to work! Cheers :slight_smile:

Sorry, that should have been “fdo#123456” rather than “fd0#123456”.

Looking at the character for “sun” I assume you write Japanese or Chinese.
When you write in one of these languages the space created by the space bar is always twice as big as in e.g English. This is correct.

When you want to combine one these languages with words written e.g. in English you will get automatically the double space. If you don’t want to have this you need to switch to e.g. English mode immediately after your last character and then strike the space bar. This will give you half the space.

Writing Japanese on XP with Asian Support Package I have following possibiliies

1 - Stay in Japanese mode

日 ”Sun" - Jap Character - Jap Space - " - next shift+S changes to latin characters with in the Japanese language mode and stays in this mode until I strike ENTER. Problem: The first latin character is always an upper case character

日”Sun" - Jap Character - no space - " - next shift+S changes to latin characters with in the Japanese language mode and stays in this mode until I strike ENTER. Problem: The first latin character is always an upper case character

2 - Switch back and forth between Japanese mode and English mode

日 “sun” - Jap Character - switch back to English mode (1 key stroke) - Eng Space …

Thank you for your answer. I’m afraid my problem has nothing to do with the situation you describe, however. If you look closely at my screenshot, you will see that in the incorrect version the opening quotation mark is in a different font. The quotation mark is formatted according to the style specification for “Asian text font”. The space in front of it is a normal, half-width space (U+0020) and not an ideographic space (U+3000).

(I write both Chinese and Japanese, btw.)

In which font do you write >sun<?

Do you change to English when writing >sun<?

Which OS are you using?

Actually, the answer by @ROSt53 does relate to your situation. The opening quotation mark is in a different font because you are not switching typing modes. It may be “brittle” but this is how LO handles i18n in text. A space (U+0020) is a neutral character, while a comma (U+002c) is a Western character, which triggers use of the Western font. The opening quotation mark will take on the characteristics of the currently active mode. I can’t replicate the full-width space effect.

I certainly am switching typing modes after typing 日 and before typing the space and then “. I take the point about U+002C being a neutral character (although it strikes me that it perhaps ought not to be?), but the text mode for the ought to be western in any event, given a ‘neutral’ character on one side and a western one on the other. Would you consider it a bug if LO fails to change the text mode under such circumstances?

The “full-width space effect” is actually caused by the fact that the opening quotation is rendered according to the “Asian text font” setting (in this case, PMingLiU at 10.5pt.). There is no full-width space U+3000 anywhere.

I’m using a Debian-based distro, with LO I use SCIM for choice, but the situation is no different on a second machine which uses iBus (each with Chewing for Chinese and Anthy for Japanese). Font-wise, the same issue exists regardless of the font, of course – right now I’m using PMingLiU for the 漢字 and Gentium for the Latin-based stuff.

Thanks for the extra detail. U+002c is not neutral it is a weak character that is treated as Latin by LO. The corresponding Asian neutral character is the ideographic comma (U+3001). The problem with left double quotation mark (U+201c) is that it is a neutral character, thus susceptible to the current typing mode. I will have a bit more of a think on your predicament, although it appears (on the face of it) that LO is largely behaving as I would expect. We may need to raise a bug report though.

Addendum: It is possible that your issue relates more to the input methods. iBus has been reported to have many problems under different applications. I am less certain about SCIM.

For what it’s worth, I’m pretty sure this has nothing to do with the input method: the situation is exactly the same whether I use iBus, SCIM, or if I simply paste the 漢字 as plain text with the SCIM or iBus daemon not even running.

I have no knowledge about Linux at all. However from my XP experience I feel that @oweng’s addedum is very worthwhile to look into input methods.