Variable width non-breaking space

English
#1

In a justified text, is it possible to make non-breaking spaces stretch like normal spaces?

Update:
My use case is to prevent line break between a preposition and the following word. Such breaks are considered wrong in Russian. But a fixed-width space looks ugly; the space should look the same as all other spaces on the line.

Another use case is the space before an em dash. This is especially problematic as the space after one should allow line break but they clearly need to be the same width. I’m not sure should they stretch but generally, they look ugly if they don’t. The same applies to abbreviations like “т. е.”

Basically, there are very few cases where I’d not want the NBSP to stretch, like between a number and a unit. In other languages rules and conventions may be different of course.

Software
Version: 7.4.3.2 / LibreOffice Community
Build ID: 40(Build:2)
CPU threads: 16; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb)
Locale: ru-RU (ru_RU.UTF-8); UI: ru-RU
Calc: threaded

OS: Void Linux
Format: ODT (the default)

P.S.

editing your question instead of answering with a comment

Totally unexpected, I thought this is more like a forum…

#4

This is not a forum but a Question & Answer site. To be useful to visitors, a question should be followed by one or several answers. The question should contain all necessary information so that a visitor can understand the problem without the pain of going through a (sometimes long) thread of progressive precision. Unfortunately many newcomers don’t take the time to read the rules and use the site as a forum, greatly reducing the “reusability” of questions.

#6

This is tdf#41652

2 Likes
#8

Where can I find the rules? I’ve only seen the “community guidelines” link which leads to a page identical to the FAQ albeit under different URL (not a redirect). And that page states this is a forum. (The “about” page does state “Questions and answers for LibreOffice” but that’s not how one mandates a format).

#2

No. Only U+0020 SPACE is taken into account by the justification engine. All other spaces are rendered with the width defined in the font.

You should have described the specific use case(+) in which you need a U+00A0 NO-BREAK SPACE to expand. I don’t see where it is needed as such a space is use to prevent line break between a word and the next element, usually a punctuation.

Frequently, text pasted from the internet has ordinary spaces replaced by no-break spaces. This is a typographical error. It is better to replace them by ordinary spaces with Edit>Find & Replace.

(+)In case you are willing to describe your specific use case, please do that by editing your question instead of answering with a comment. While at it, mention OS name, LO version and save format (file extension).

EDIT 2023-02-09
I found a contorted way of achieving what you want.

The trick is to make the ordinary U+0020 SPACE part of the word.

  1. put the cursor at the end of the preposition
  2. Insert>Formatting Mark>Word Joiner
    (This word joiner is followed by an ordinary space so that it can be expanded by justification.)

But, don’t add a second one after the space. It looks like it cancels the effect of the first one regarding line break.

I am not sure about the em dash case because I don’t see the problem with line break except if you don’t want the em dash at start of line. Experiment with word joiner and ordinary space. Personally, I’d let Writer do the layout without word joiner.

In abbreviations, use a word joiner after the period.

1 Like
#3

Updated the question with new information.

1 Like
#5

Word Joiner is U+2060 . @ajlittoz workaround seems to work well on my short test. You could add the combination to an AutoCorrect or Autotext entry.

A non-breaking space between a preposition and the next word would be a common case for Russian I assume, is there any setting in Tools > AutoCorrect > AutoCorrect Options > Localised Options?

1 Like
#7

Thanks. This works, mostly. Sometimes though, the word joiner doesn’t prevent the break. That’s not easy to reproduce but I got that once accidentally. Here is a (anonymized) sample if you care:
odt (11.2 KB)
pdf (7.4 KB)
(you’d need the exact same font I suppose; it’s Nimbus Sans)

#10

Not sure if this is the fundamental cause, but in your sample file, the first line contains twice double spaces. It may disturb the justification algorithm because as soon as I remove one space, the u+word joiner+space is flushed to next line although I created more space in the line with the removal.
Same when I remove the space betwee “wuu” and the comma.

Morale: since we’re trying to outsmart Writer, write carefully your text according to usual conventions. In other words, only a single space between words, no space before a punctuation (except special fixed-width spaces like en-space, em-space, narrow non-breaking space, …). And, if you’re a US-trained user, no double-space after period (this is an outdated typewriter usage).

#11

I don’t have Nimbus Sans, a quick search on the internet says it is fully metric compatible with Helvetica, copyright 1999 so possibly quite old.
Testing the sample with Arial and Liberation Sans (metric compatible with Helvetica) at 1/10ths point increments I couldn’t force the split at the word joiner or following space.
If I set the font to an equally old font, Windings, the words split at the Word Joiner. Do either of these older fonts know about Word Joiner? Or is it a character substitution problem?

#12

The Nimbus family installed by default under Linux are © 2014 URW++. We can expect they are technically up-to-date. But effectively U+2060 WORD JOINER is not implemented in Nimbus Sans. Thus, word joiner is substituted. However since this is not a real glyph, rather a “function” one, does it really need to be implemented? This is the same issue as ordinary space which is not used “literally” by document processors.

#13

The reason that the space doesn’t matter in keeping the words together at the end of a line is the default setting set to On, On in Tools > AutoCorrect > AutoCorrect Options > Options > Delete spaces and tabs at beginning and end of line. If the space is at the end of the line it is deleted and the Word joiner then connects two words. If the setting is turned off then the words can split at the end of a line.

The remaining question then is why the trick works with some fonts but not other ones, mainly older ones with fewer characters.

1 Like
#14

I don’t follow. If your suggestion is correct, Writer attempts to connect the word before the end-of-line space with the first word on next line. Then it sees there is no space for such a sequence and flushes it to next line. But we now have again preceding word-word joiner-space-next word. Unless Writer considers it is done with the previous line, we may face an infinite loop where it will try to stuff preceding word-word joiner-space in the line above.

It would be interesting to have information about line building algorithm.

#15

There is a potential infinite loop but from a previous question ( Justification Spacing Issues) about justification it seems that writer only looks forward at one line at a time for justifying text which doesn’t give the best results but works for this situation.

#16

The problem is tdf#151162. It is actually easy to reproduce once you know how. Line justification is irrelevant. Fonts are likely coincidence.

#17

For comparison, Calligra Words does stretch the U+00A0. It doesn’t support the WJ+space combination though.

#18

Yes. Easy to reproduce, turn off the setting in AutoCorrect Options I referred to in an earlier comment.

If that setting is enabled then Liberation Sans never seems to split at the space following the word joiner. Other, mainly older, fonts like Binner Gothic or Wingdings will split at that space if you just add other words before the word.

This question is about justification of text.

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.