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
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.
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.
(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).
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).
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.
Dear Hossein, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
This is still reproducible with the latest LO stable: Version: 25.8.3.2 (X86_64) Build ID: 8ca8d55c161d602844f5428fa4b58097424e324e CPU threads: 20; OS: Windows 11 X86_64 (build 26200); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded But it requires dark background, so that the text goes white, and then becomes invisible. I use "Dark Gray 3" as the background color. I set it in "Tools > Options > Appearance > Customizations > Document Background". In other words, editing background is different from displaying background, and that is the cause of this issue. This is also reproducible with the text boxes, and not only custom shapes. I set the title accordingly.
[Automated Action] NeedInfo-To-Unconfirmed
Tested on Windows 11 with LibreOffice 25.8.3.2 (X86_64) stable and 26.2.0.0.alpha0+ (X86_64). With a dark document background (Tools ▸ Options ▸ Appearance ▸ Document Background = Dark Gray 3), text inside text boxes and custom shapes remains visible during editing. Changing font size does not make the text invisible. No blind editing was observed. Environment details: UI locale: uk-UA, VCL: win, IK: Skia/RASTER. Result: NOT REPRODUCED