Severe Lag When Selecting or Editing Mixed RTL/LTR Text in LibreOffice Writer

English
#1

Selecting or editing text in documents containing mixed RTL (e.g., Arabic, Hebrew) and LTR (e.g., English) text in LibreOffice Writer causes significant lag, making the application nearly unusable. I’ve tried different fonts (also popular ones like Arial), enabled Complex text layout for Arabic, but nothing worked. I was using LibreOffice Version: 24.2.7.2 and upgrade it to 25.2.2.2 and the problem still exist.

My device information:
OS: Ubuntu 24.04.2 LTS (Codename: noble)
Kernal: Linux 6.11.0-21-generic
GPU: Nvidia GeForce RTX 4060 Max-Q / Mobile

Version: 25.2.2.2 (X86_64) / LibreOffice Community
Build ID: 520(Build:2)
CPU threads: 32; OS: Linux 6.11; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Ubuntu package version: 4:25.2.2-0ubuntu0.24.04.1~lo1
Calc: threaded

#2

Maybe someone faced this weird situation?

#3

I assume that you assign appropriate paragraph styles to your RTL/LTR texts and do not use any other direct formatting.

Then you should use a sample document in which the problem exists to write an error report on bugzilla.

Please post the number of the error report here. Thank you.

#4

Dear mdgu,

I observed exactly the same. I am using LO 25.2.3.2, the latest version, on MacBook with an Intel processor and MacOS Sequoia 15.4.1 (24E263), the latest system release.

My text is a 30-line text, with lines in Hebrew, and line numbers in English on the right. The fonts are the regular ones.

I cannot see why this apparently simple situation could break LO. I visualized the same text with Microsoft VS Code and with Mac TextEdit, and it is done at a glance.

#5

Please attach your 30-line document for analysis.

#6

It send it by mail. FYI, it is an edited copy of Psalm 34 copy-pasted from from Les Psaumes - Chapitre 34 - תהילים.

#7

Here it is. FYI, it is an edited copy of Psalm 34.

psaume_34.docx (6.63 KB)

#8

No lag here: Fedora 42, LO 25.2.3.2, but:

  • why do you save .docx?
    This is an alien format. Converting to it on save creates problems. Hopefully, you don’t use list numbering which one of the most divergent feature between formats.
  • there is something weird with your file
    Tour text is tagged Hindi. And I couldn’t get standard RTL behaviour after I tagged it Hebrew. You seem to have simulated true RTL with various workarounds. Note that writing multi-language documents is difficult, more over mixed RTL-LTR. So, don’t add unmanageable difficulty by saving non-native.
  • your document is direct formatted
    Of course, DOCX knows nothing about character styles, but you overlaid your Body Text paragraph style with direct formatting instead of adjusting it. Multi-lingual documents require a very strict methodical approach to formatting with styles otherwise the task becomes quickly insurmountable.
#9

(post deleted by author)

#10

Hrbrgr I’m writing in the document without any special formatting. I report about it in bugzilla but with no response (Really sorry for late to post error report). I attached a test file as you can observe if you try to select first paragraph (the has mixed text) It’s so slow. The second paragraph is pure Arabic text and no problems there. The same thing for third pure English one (also no problems).

TestFile.docx (5.0 KB)

#11

No problem with your test file here (Fedora 42, KDE Plasma desktop, LO 25.2.3.2).

But once again, why do you save DOCX since you are under Ubuntu? By saving DOCX, you’ll face cumulative issues which will in the end damage your document.

Saving now as .odt will not fix possible existing misbehaviour. You must create a new blank .odt document and paste your existing contents as unformatted text to get rid of any DOCX glitches. This means you lose your formatting (but this is not important because DOCX does nearly everything with direct formatting). You must recreate it with style applications. Styles are the safest way to format a document with stability and reliability.

#12

Thank you ajlittoz for your quick response.

I recreated the file as you said and pressed Clear Direct Formatting button. So nothing special with this text. I’m saving as DOCX so I don’t have any problem when exchange with Microsoft Office users.

The testing is on Lenovo Legion 5 with RTX 4060 GPU and Ubuntu 24.04.1 LTS

NewWordDocument.odt (16.3 KB)

#13

And again your new document behaves like a charm.

You’re trading a possible anticipation of problems for guaranteed issues with repetitive conversions across your editing sessions. Officially M$ Word supports ODF (though they deliberately chose to diverge from the published standard). Thus, M$ Word users “should” be able to open .odt documents but it is also possible that M$ didn’t configure adequately the Registry to create a lock-in situation.

Therefore, work in .odt. Only when you’re on the point of sending your work to Word-collaborators convert to DOCX. When you receive comments or changes, don’t use the received DOCX (only for reading) or copy/paste as unformatted into your original.

Remember that DOCX has no character style. You lose them when you save .docx which means you ne longer centrally control your emphasises or other intra-paragraph variations (which are useful in multi-language multi-script documents).

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