Another manifestation of this problem:
if I search for trailing spaces using this regex:
[[:space:]]$
then it finds all lines that have objects anchored as characters after a space in the end of a line:

[something][space][obj-anchored-as-character][eol]

This makes it impossible, e.g., to trim trailing spaces.

It seems to me that the bug is unique : the one related in comment 1.

Description :
- when you say "When an object is anchored as character, it should behave like it is a character", does that imply for you "an alphabetical character" ? i.e. something that do not cause a word break ?
- OpenOffice apparently endorses that an object behave like a word-breaking character rather than en alphabetic character ; so the point 1 is not a bug,
- both solutions are defendable ; however, if you think that the string "(<formula>)" must be processed like a word (for the purpose of wrapping) so that "anchored as character" must now be understood as "anchored as alphabetical character", I'm afraid that it raises new bug issues like "my sentence <sentence_body><large_image_object> does no longer wrap correctly when <sentence_body> ends with a letter : the wrapped image always pulls the last word with her..."
- in description point 2 : could "... improperly placed punctuation (as if there is no object..." be replaced by "properly placed punctuation (because for the sake of wrapping the object is processed as a non-letter...".
- may I suggest that you include the parenthesis into the formula ?

Comment 1 :
- I confirm that "<text><blank><object><paragraph_mark>" matches "[[:space:]]$",
- This fact can't be summarized as "... there is no object..." because "<space><object><space>" doen't match "<space><space>" (either with and without the Regular Expression box checked)
- also this text "<space><object><space>" doesn't match "[[:space:]][[:space:]]" but it matches "[[:space:]].[[:space:]]"
- so the bug is : inconsistencies in the way the pseuso-character representing an object anchored as character is used anywhere (word wrapping, searching, etc). A consistent behaviour should be proposed, closest to the current behaviour.

(In reply to comment #2)
> - OpenOffice apparently endorses that an object behave like a word-breaking
> character rather than en alphabetic character ; so the point 1 is not a bug,
> - both solutions are defendable
You are absolutely right! I must have thought about this myself.

> however, if you think that the string
> "(<formula>)" must be processed like a word (for the purpose of wrapping) so
> that "anchored as character" must now be understood as "anchored as
> alphabetical character", I'm afraid that it raises new bug issues like "my
> sentence <sentence_body><large_image_object> does no longer wrap correctly
> when <sentence_body> ends with a letter : the wrapped image always pulls the
> last word with her..."
You are right; however, the current state only allows for one thing: unconditionally wrapping the object. The proposed change allows one to control this: simply add the spaces around objects that need wrapping, and everything is OK; otherwise, if you need object to stay with leading/trailing text, it is doable by omitting the space.
This is likely to break layout of some existing documents. This may be mitigated either by automatically inserting spaces (if absent) around such objects on importing documents created by older versions (this needs knowledge of version of creator software), or by introducing a new option selectable by user document-wide or per object.

> - may I suggest that you include the parenthesis into the formula ?
No :) Actually, this is a wrong approach. Consider this text:
<some text> (for example, <formula object>).
Here, if I put right closing parenthesis into the formula, I run into a number of issues:
1. I must use the syntax "right none ... left )" inside the formula to enter only one parenthesis, and it is the scaling parenthesis, so it will likely not match the size of opening parenthesis written in plain text;
2. Even if I manage to enter one closing parenthesis of correct size (by enclosing it in quotes in formula), it will likely be of a different shape (by different font);
3. Even if I define the same font for the formula (which may be undesirable, to keep visual distinction of formulas), I will depend on correct vertical alignment of the parenthesis (which is not always that correct), so the parenthesis will likely be misaligned.
4. The resulting text will fire warnings from spell checker.
And maybe there are some other issues I haven't thought of.

> - I confirm that "<text><blank><object><paragraph_mark>" matches
> "[[:space:]]$",
> - This fact can't be summarized as "... there is no object..." because
> "<space><object><space>" doen't match "<space><space>" (either with and
> without the Regular Expression box checked)
> - also this text "<space><object><space>" doesn't match
> "[[:space:]][[:space:]]" but it matches "[[:space:]].[[:space:]]"
> - so the bug is : inconsistencies in the way the pseuso-character
> representing an object anchored as character is used anywhere (word
> wrapping, searching, etc). A consistent behaviour should be proposed,
> closest to the current behaviour.
I agree. And I think that the correct behavior of search and replace should treat such objects as a character that can be matched by regexes like ".", "[^[:space:]]", "[^[:alpha:]]", "[^[:digit:]]", "[[:print:]]" (because it's printable object), "[^[:cntrl:]]", "[^[:lower:]]", "[^[:upper:]]". If so, lines like <text><space><object> will not match regex [[:space:]]$

I think that this issue should be split to two (one bug report about regexes and one RFE).

I'm trying the sequence "<text><space>(<nBS><Formula><nBS>)<endOfParagraph>"
where <nBS>=<nonBreakingSpace>

The second <nBS> seems to failed, I manage to get:
"<longText><space>(<nBS><Formula><nBS><EOL>
)<endOfParagraph>"

However, the following works well :
- "<longText><space>(<nBS>xxxx<nBS>)<endOfParagraph>" (<EOL> possible before "(" and after ")")
- "<longText><space>(<nBS>++<nBS>)<endOfParagraph>" (<EOL> possible before "(", between the "+" and after ")")
- "<longText><space>(<nBS><nBS>)<endOfParagraph>" (<EOL> possible before "(" and after ")")

Could it be another evidence of the bad qualification of the <formulaAnchoredAsCharacter> for breaking ? If that point was corrected, may the use of <nBS> satisfy your need ?

Same issue here with 4.2.4 on linux.

Writing a scientific document, I have formulas that are graphic objects anchored as characters (made with the texmaths extension).

Unfortunately, these objects anchored as character are mistreated. Whenever I have a comma following one of this objects, the comma can often go alone after a line break.

This is like

text text text text formula
, text text text

Marking the bug as 'new' from 'unconfirmed' since it is now seen by more than a single user.

Switching from platform Windows to platform all, since I am seeing this on Linux and I am pretty sure that the issue is cross-platform.

An addition to Dominique Boutry:

I strongly recommend one of the following alternatives:

1) treating objects anchored as characters as alphabetical characters

Rationale: this would be much better than the current situation. In the current situation there are no workarounds for the broken behavior

text text text <formula>
, text text text

putting the comma in the formula is not OK, since the comma would be in a math font rather than in the correct text font.

Conversely the issue of,

text<image>

not breaking can be worked around by simply inserting an invisible (thin) space between text and image.

2) introducing a no-break flag (or treat as alphabetical character flag) into objects anchored as character. This may not be fully conformant with the ODF spec, but would simply be ignored by other odf apps not understanding it, so it would not cause any significant breakage

3) introduce a 'glue' formatting mark, like a non-breaking space that takes no space.

Personally, I prefer 1, which I think is the solution causing less trouble. In any case, I believe that a solution needs to be found, because as is the behavior makes LibO unsuitable for scientific documents.  Technical documents, where small graphics are often used to represent keys on a keyboard or operator actions, are likely to represent another situation for which the current behavior makes LibO unsuitable.

By the way, I have just noticed that the sequence
<nonbreaking space><comma> can get a linebreak between the nonbreaking space and the comma.

The issue is still present in LibO 5.1.2. Makes LibO unsuitable for writing scientific papers or documents.

*** Bug 105770 has been marked as a duplicate of this bug. ***

Still repro with Version: 6.2.1.1 (x64)
Build ID: 757c58e8cb70b2982843211a54750fb3cd79acd5
CPU threads: 12; OS: Windows 10.0; UI render: GL; VCL: win; 
Locale: ru-RU (ru_RU); UI-Language: en-US
Calc: threaded

*** Bug 149295 has been marked as a duplicate of this bug. ***

Dear Mike Kaganski,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug