I certainly agree that automatic justification can create unfortunate results, but they are not too bad, all-in-all. I have seen worse, in newspapers for instance, where the whole width of a column may be populated by a single word, such as ‘its’, spread out across the column. Maybe somebody ought to specify something or other as the standard. If they do, I vote for the double-space after periods.
I prefer it too, and so far I’m getting away with it. Yeah, there should be some option for a longer space perhaps. One should be able to format a doc as one damned well wants, no? I’m not going to get too worked up about it either way.
My idea about this issue, and more generally about punctuation in general, is to extend the AutoCorrect Options, Localized Options tab to be able to specify which type of space should automatically be added before or after some glyphs. This way, you could have a space taken from U+2001 to U+200A (chosen by user) followed by a typed ordinary space. Since the special spaces have not the “expandable” property, expansion is made on the ordinary space and we eliminate the problem with double spaces. You choose the width of the special space to fit your taste.
Some locales (e.g. French) already have provision for automatic insertion of non-breaking spaces (this is necessary to avoid separating the punctuation from its anchoring word with a line break). However, this is typographically wrong. NBSP is way too wide to comply with typography tradition. It comes from legacy character sets where the 190 count of printable characters did not allow for many spaces. Unfortunately, this was not revised with the advent of Unicode.
If I had the skill (and time too), I’d experiment along this idea.
Too much plumbing. It’s nice to have all that power, but sometimes, even tho I’m now a styling guy, I wish for my plain text editor where you get exactly what you type. Mind … I’ve now converted all my tables, and tho I’ve doubtless made many mistakes, it’s very cool to be able to, say, transpose an entire column or reformat the whole thing with a few commands.
BTW are my bug reports kosher?
It took me a while to find this ‘local options’ tab, but it looks promising, though, despite the open source nature of things, someone else such as LibreOffice will have to play with it. I am, as you say you are, unskilled in these things. I have enough trouble typing, much less coding enigmatic commands.
ajlittoz
February 18
GrumpyGeezer925:
Maybe somebody ought to specify something or other as the standard. If they do, I vote for the double-space after periods.
rayandrews:
Yeah, there should be some option for a longer space perhaps. One should be able to format a doc as one damned well wants, no?
My idea about this issue, and more generally about punctuation in general, is to extend the AutoCorrect Options, Localized Options tab to be able to specify which type of space should automatically be added before or after some glyphs. This way, you could have a space taken from U+2001 to U+200A (chosen by user) followed by a typed ordinary space. Since the special spaces have not the “expandable” property, expansion is made on the ordinary space and we eliminate the problem with double spaces. You choose the width of the special space to fit your taste.
Some locales (e.g. French) already have provision for automatic insertion of non-breaking spaces (this is necessary to avoid separating the punctuation from its anchoring word with a line break). However, this is typographically wrong. NBSP is way too wide to comply with typography tradition. It comes from legacy character sets where the 190 count of printable characters did not allow for many spaces. Unfortunately, this was not revised with the advent of Unicode.
If I had the skill (and time too), I’d experiment along this idea.
Visit Topic or reply to this email to respond.
To unsubscribe from these emails, click here.
An update on this issue: made an exact clone of a 128 page doc, loaded it, LO in exactly the same state, and the page count was 27, this with the same display settings. Now, if I click on the ‘Page’ count, the ‘Go to Page’ will let me jump to an accurate page, like 127, but the counter still shows only 27 pages. So it’s clear that LO knows the accurate count, but isn’t displaying it. But if I go to the top of the doc, and then keep doing ‘Page Down’, you can see it ‘catching’ various page count mistakes and fixing them one by one until at the bottom of the doc, the count is correct.