Bug 163062 - Editing text in a text box sometimes make it invisible
Summary: Editing text in a text box sometimes make it invisible
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Font-Rendering Textbox
  Show dependency treegraph
 
Reported: 2024-09-20 10:57 UTC by Hossein
Modified: 2024-09-22 20:02 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
PDF export of the document, 2nd page is empty (76.92 KB, application/pdf)
2024-09-20 11:07 UTC, Hossein
Details
Required fonts (137.52 KB, application/x-zip-compressed)
2024-09-21 14:12 UTC, Hossein
Details
Same content in modern docx format without preserve compatibility (57.79 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2024-09-22 20:02 UTC, Regina Henschel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Hossein 2024-09-20 10:57:30 UTC
Description:
Editing text in a text box sometimes make it invisible. This is annoying as you will be editing blindly. Typing things and edit works, but the text which is edited is invisible.

Steps to Reproduce:
1. Open attachment 183252 [details]
2. Go to page 2.
3. Select the text in the big text box (click and press ctrl+a)
4. Change the font size a few times

Actual Results:
Text sometimes becomes invisible. When you click outside the text box, it may come back or not. This is more visible in dark mode, but also happens in light mode. It may be the case that the part of the text which overflows the text box -and is usually shown during the edit- is visible.

Expected Results:


Reproducible: Always


User Profile Reset: No


Additional Info:
Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: f317746f55044927a180657f81e21d662102b0c5
CPU threads: 12; OS: Linux 6.2; UI render: default; VCL: x11
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: CL threaded
Comment 1 Hossein 2024-09-20 11:07:28 UTC
Created attachment 196561 [details]
PDF export of the document, 2nd page is empty

There are cases when you export the document to PDF, and the text box is shown blank in the PDF. The attached PDF file is the export of the attachment 183252 [details]. The second page is blank, as the text from the text box in page 2 is invisible.
Comment 2 Rafael Lima 2024-09-20 19:40:41 UTC
I was unable to reproduce the issue, both in LO 24.8 and 25.2. In all cases, increasing and decreasing the font size did not make the text disappear.

Maybe this is related to the font being used, because I don't have the font you used and some substitution was made.

Also, on a debug build, increasing/decreasing the font size is terribly slow.
Comment 3 Hossein 2024-09-21 13:26:52 UTC
(In reply to Rafael Lima from comment #2)
> I was unable to reproduce the issue, both in LO 24.8 and 25.2. In all cases,
> increasing and decreasing the font size did not make the text disappear.
> 
> Maybe this is related to the font being used, because I don't have the font
> you used and some substitution was made.
> 
> Also, on a debug build, increasing/decreasing the font size is terribly slow.
Thanks for testing.
The slowness is reported in tdf#163061.
The used fonts are:
B Nazanin, B Compset and Lotus, which are specific to Persian (Farsi).
Comment 4 Hossein 2024-09-21 14:12:39 UTC
Created attachment 196588 [details]
Required fonts

Required fonts are attached:
B Nazanin (Normal, Bold)
B Compset (Normal, Bold)
Lotus

As stated in the previous comment, these fonts are specific to Persian (Farsi).
Comment 5 Regina Henschel 2024-09-22 20:02:32 UTC
Created attachment 196617 [details]
Same content in modern docx format without preserve compatibility

I cannot reproduce the problem. I have installed your fonts. Tested with Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 976567aee323afd09629b6adf13537908f43d2a8
CPU threads: 32; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Vulkan; VCL: win
Locale: de-DE (de_DE); UI: en-US
Calc: threaded

BTW: The object on page 2 is not a text box, but a custom shape. And this custom shape has no associated text frame. So the text uses the simpler drawing text engine.

I have converted the document "without keeping compatibility" by Word. That file is attached. So you can test, whether this is a special .doc problem or is seen in .docx as well. [The import of the converted file has the page break wrong. You need to add a new page break and remove the first one.] Import now generates a text frame inside the custom shape and thus the table is not lost.