keep text together?

By convention this should not happen because the minus sign (or plus sign) should be considered as part of the number. I am using LO v6.1.5.2 and the same thing happens here. One work-around might be to add an extra space in front of the minus sign, in order to force it on to the next line with the rest of the number. But if you edit that first line in any way, you will have to remember to check what happens to the number.

I think this should be reported as a bug at https://bugs.documentfoundation.org/

Hello, no this is not a bug IMHO. The hyphen is the designated delimiter. To prohibit LO Writer from seperating the hyphen from the number you could insert a non-breaking hyphen instead of a “minus”. Use CTRL-SHIFT-‘minus’ ("-"). The result will be a hyphen in a somehow gray box.

To show the community your question has been answered, click the check mark (✓) next to the correct answer. Also you could ‘upvote’ by clicking on the up arrow (^) for any helpful answers. This is the mechanisms for communicating the quality of the Q&A on this site. Thanks!

OK, so the minus sign is properly positioned but why would would gray box background be acceptable? Still seems a problem.

The gray background is only a reminder that the character has some special property. It shows on screen only and does not print.

Right, only to signal that this is a protected hyphen. I found two other methods in the documentation. First, you could put the word into the dictionary and exclude it from being separated (did not try since this is only reasonable for more then one time used words) and second there seems to be a way for individual exclusion with menu (don’t know for the english version) Format - Zeichen - Schriftart >> “keine”. But that did not work for me, which is probably a bug.

For me it’s LO 6.2.2.2 on Windows 10.

The hyphen is the designated delimiter

@Cookievore : I am not a purist but this must be a mistake. It is not a hyphen, it is a minus sign. The sign of a number (plus or minus) is a part of the number, just like the decimal point (or comma), and should not be separated from the number in normal text. So any “hyphen” directly in front of a number should be considered as a minus sign and part of the number. I think the OP would be justified in reporting this as a bug.

@ve3oat : interesting point of view. I agree with you in question of ‘part of the number’ but actually the minus is used to function as hyphen and as minus since there is no other key on the keyboard. Maybe Writer should be improved in its behaviour but other wordprocessors act the same way and are taking a “-” (minus) as indicator to break the line at this point if necessary. Also the given example runs the same way e.g. in Word. Maybe a Dev could give us a reason why using it as break indicator has a higher priority then interpreting it as algebraic sign that should be linked to the number. Also the existence of CTRL-SHIFT-‘minus’ method indicates to me, that this is intended behaviour and implemented to cover such scenarios.

The ambiguity between hyphen and algebraic sign is as old as computers. Even Unicode does not set new rules for this as it would break virtually every document written up-to-date. In my knowledge, only programming language APL introduced a distinction between sign (an intrinsic property of a number) coded as 0x40 in ISO IR-68 and the negation/subtraction operator coded as 0x5F in ISO IR-68 (equivalent to U+002D HYPHEN-MINUS).

Strangely enough, I haven’t found the APL minus sign in the APL Unicode block. The closest approximation would be macron U+00AF, but once again this causes an ambiguity between the linguistic use of macron and the sign of a number.

Consequently we must live with this ambiguity. If we want to be immune against spurious line wrapping, we can use U+2212 MINUS SIGN as suggested by @RGB-es since this is the intended semantics or add a ZERO WIDTH JOINER U+200D between hyphen and number but not sure if it prevents line break.

Anyway, not very user-friendly

@Cookievore : Thanks for your comments and it seems you are probably right about the CTRL-SHIFT-‘minus’ method being the intended solution for this problem. And certainly most keyboards do not allow one to distinguish between the function of a minus sign and a hyphen. WordPerfect behaves the same as LO, though in many years of preparing documents (and more recently in LO), I can not recall ever encountering the problem before. Despite my own experience, this must not be a rare problem and I am glad the OP has raised it. I will upvote his question.

@ajlittoz : Very interesting. I could be wrong but I recall that in FORTRAN the “-” sign was always treated as a minus sign unless it was part of the name of a variable, although on second thought it might not have been allowed there. Indeed, the situation is not user-friendly.

@ve3oat: in FORTRAN (at least up to F77) a dash sign is either a negative sign or the subtraction operator. At that time, names (variables, function and subprograms) where limited to 6 characters from A-Z0-9, a constraint inherited from the IBM mainframes of the '50s. Remember FORTRAN had a strange (for contemporary idiosyncrasies) rule of ignoring spaces outside strings or Hollerith constant, putting a serious stress on compilers to determine the extension of identifiers or even recognise statements (e.g.: what is DO10I? Is it a REAL variable or the beginning of a DO statement?

Nostalgy …

@ajlittoz : Yes, and thanks. In my simple mind I had not distinguished between the negative sign of a number and the subtraction operator itself. FORTRAN was wonderful to work with … it was so explicit and easy to debug. Thanks for reminding me. While our Questioner’s problem involves a real can of worms.

A general way to prevent a linebreak in a specific place is to insert the unicode WORD JOINER U+2060 there.
In recent LibO: Type 2060 and hit Alt+X then.

1 Like

This does not work for me. ALT-X opens the menu Extras. Here it is ALT-C while ALT-X is maybe intended for use in dialogs?

Brilliant tip! I used it to make a London post code that has a space in the middle stay on one line.

@Hippobabe
For the common case of non-word-separator spaces, use U+0040 NO-BREAK space. It is quicker. Keyboard managers usually provide it by pressing some modifier key (Shift, Ctrl, Alt or Alt Gr) or combination of before hitting the space bar.

If you find U+0040 NO-BREAK SPACE too wide, you can have a try to the various spaces in block U+20xx.

Typographically speaking, a dash cannot be considered a “minus sign” :wink: There is a dedicated minus sign in Unicode (U+2212) that will go to the following line with the number. You can insert it in Writer by typing

:-:

(colon, normal dash, colon). As soon as you insert the second colon, the minus sign is introduced.

:-: does not work here. But could reproduce (U+2212) as designated Unicode “minus” whilst it looks like a dash related to the length. OP is using a hyphen / minus which is IMHO typographically the correct symbol for an algebraic sign. Difference in length is dash − and hyphen - and the typographical (again IMHO) function of a dash is not to be used as algebraic sign although it is linked to the number.
Edit: You are right, U+2212 − is the typographically correkt “minus” but cause of the common use of - it looks so familar. I saw these long − mostly in LaTeX or formula generators aso.

This is a bug. The behavior is explicitly described in Unicode Line Breaking Algorithm (UAX #14):

HY Hyphen HYPHEN-MINUS Provide a line break opportunity after the character, except in numeric context