LibreOffice plugin doesn't add spacebar after last character of prefix is a number
Report ID: 1748597952
LibreOffice plugin doesn't add spacebar after the last character of prefix is a number
To reproduce:
- Open/Create a document in LibreOffice
- use the provided plugin to 'Insert Citation' to open Quick Format Citation
- after having selected an entry, click on it (or press ctrl + ↓)
- enter prefix with the last character being a number, or any other special character (exceptions are: dot (.), colon (:) and semi-colon (;))
Actual behaviour: no space is added (except the excptions mentioned above)
Expected behaviour: add a space in all these cases (also when numbers & other characters are added)
LibreOffice plugin doesn't add spacebar after the last character of prefix is a number
To reproduce:
- Open/Create a document in LibreOffice
- use the provided plugin to 'Insert Citation' to open Quick Format Citation
- after having selected an entry, click on it (or press ctrl + ↓)
- enter prefix with the last character being a number, or any other special character (exceptions are: dot (.), colon (:) and semi-colon (;))
Actual behaviour: no space is added (except the excptions mentioned above)
Expected behaviour: add a space in all these cases (also when numbers & other characters are added)
I'm not sure what's actually expected here. There's some risk in automatic space too much, since it does restrict options, but I can't right now think of a case where we wouldn't want a space.
I can't think of a reason, either, why one would want to end up with the prefix attached to the author or year of publication (at least in APA)
(eg. discussion about the sign “@”Robinson, 2015)
It's interesting that the space is not dependent on the last character of the prefix. Note the following difference:
- (cf discussion about “@”Akkermans et al., 2013) [no space after "@"]
- (cf discussion about “@ sign” Akkermans et al., 2013) [there is a space]
The same 'space issue' plays with the suffix.
I left it to manual insertion mostly for simplicity. It's easy to explain that a space needs to be inserted manually; if we do it automatically, there shouldn't be edge cases remaining that will confuse people when they hit them. That was the thinking, anyway.
I can think of a few cases where a space would not be wanted. Hyphen, em-dash, en-dash, zero-width-space, open brace, open bracket, and open parens are a few. Also kanji, hangul and the two flavors of kana--those should actually swallow space, if a character of the same class follows. I'm not sure about languages using Arabic script, and Hebrew. There might be a general rule in those, or there might be differing treatment among characters, and there might be differences across languages that share the same script. At least I don't know the answers to those.
Anyway, I'm agnostic, but there should be a pretty full list of do's and don't's before the joining typography is automated.
Never mind drawing up that list of do's and don'ts then :P