#1

writer: tab stop size global setting resets to install default of 1.27cm upon paste of RTF clipboard data

LO 6.4.3.2 x64 for Windows up to and including 7.1alpha 64-bit seem to have the following bug (details below). Did not remove any LO profile data or make any other changes. After a couple of days using it I noticed tab stop size was reset back to its native default of 1.27cm. Normally have tab stops set to 0.5cm and just gave in for a while and had been wondering why it kept resetting back to 1.27cm.

Copying rich text from other applications then pasting into LO seems to reset the tab stops value every time the paste special function is used .
This happens regardless of whether pasting into a frame or the normal background page. Have tried this out with PDFXChange and Windows write.exe.

It could have been happening previously to this and I just didn’t notice (because I have only really started using tab stops a lot in the last few months). It could have been affecting the previous version (which I think was the release prior to 6.4.3.2), but I cannot be sure.

If this is a bug; this can have have undesired consequences as highlighted in the following scenario: open up an older completed document for ammending or editing and all formatting and layout is incoherent. A user does not know why their document is now formattedly differently and has to reformat the whole document again to get back the original formatting, when all they need to really to is set the tab stops back to what they originally used. (but the user does not know that tab stops were unwittingly reset, so they do not know to change the setting).

Am not sure what safety checking LibreOffice has under the hood or if there are other changes happening behind the scenes when we paste RTF (and potentially other clipboard data?) Could this be causing other problems?

c:\temp\libreoffice - bug qq - tab stop setting reset upon paste of RTF clipboard data
c:\temp\libreoffice - bug qq - tab stop setting reset upon paste of RTF clipboard data696×520 17.6 KB

Version: 6.4.3.2 (x64) - up to an including 7.1alpha 64-bit
Build ID: 747b5d0ebf89f41c860ec2a39efd7cb15b54f2d8
CPU threads: 16; OS: Windows 10.0 Build 18363; UI render: GL; VCL: win;
Locale: en-US (en_US); UI-Language: en-GB
Calc: CL

programmatically set "tab stops" options value to mitigate bug
#2

Looks related to tdf#133888 (although the strange things there, related to tabs and pasting RTF, are slighly different… but also the version is not the same…).

#3

still getting this in version 7.0.0 and have to very frequently set the tab stops back to 0.50.
additionally, there are frequent intermittent occurances of undo and redo no longer functioning – so I end up making cutting a paragraph and losing it.

#4

still getting this in 7.1alpha (64-bit).
filed a bug report tdf#136740 - not sure if I am supposed to allocate this or change any of the fields to ensure it doesn’t gets actioned.

#5

Umm, @blashrkh , you may wish to re-edit your comment from sep 14, '20.

I am guessing here, but I would think you do wish to have this bug acted upon, as opposed to what you wrote in the comment.

The thing, that may be throwing the interface off is your Computer locale, and then the use of “0.50”.

I know this may seem silly, but if your Computer is setup for North-American English or US-English, and then you change the parameter to “0.50” in the opening portion of “writer” is the option for the Default tab stops.

But…

If you compose a document in UK English, with a UK computer(or international keyboard),or UK locale, then the PRINTER settings would be in CM.

Then , if you save the document from Word/Writer.exe/ or similar, then the RTF does not “know” that 0.50 is the default Tab-stop in CM, and saves the parameter “tab-stop” as 0.50.

Now, you save this file , to a device (anything), and then try to import the RTF parameters.

Then guess what? It ignores the …

#6

While I am not 100%, that I found the answer.

I may have found a clue as to what is going on here.

It has to do with two settings.

The user locale, and the Language of English selected for the interface (UI).

See this picture with the highlighted areas:

image description
image description698×89 22.6 KB

In this persons Locale: field, the “System” is expecting settings for en-US operations.

This means $ sign instead of Euro, Printer settings in Inches, and type settings in Pica etc.

But, the User Interface, (UI), is set for en-GB…

Ok, now I’m from Canada(eh!), where Canadians had to go through a forced conversion to metric. (circa 1972), so this is how I was able to spot the problem, when the user mentioned 1.27cm. See Gimli Glider to highlight the differences between Metric measurement and US Customary Weights and measures.

If the user changes the Interface to en-US, this will solve (partially) the problem.

Since RTF does not know the difference between UK 0.50 tab stop (in cm) to US tab stop 0.50 in inches, this is where the computer gets lost, and then tries to import the text using what it knows at the time (inches), but then displays stuff in cm, when the text is saved in RTF format.(on UK computers), but on a US computer (there is that locale thing again), the computer thinks everything is in inches and breaks the text.

This is only a proposed solution at this time as it has not been tested (April 2021). I will update this ‘fix’ as I attempt to re-create the problem, and then implement a ‘fix’.(or work around)