Description: When "Automatic spell checking" is set, characters may overflow from the cell. Steps to Reproduce: 1. Open new Calc. 2. Turn on the "Automatic spell checking" . 3. Insert text "AAAAAAAAAAAAAAAAAAAAAAAAAAA" into Cell [A1]. 4. Insert text "B" into Cell [B1]. Actual Results: 5. The text in cell [A1] overflows and overlaps the text in cell [B1]. Expected Results: 5. A triangle mark appears on cell [A1] and does not overlap with the text of cell [B1]. Reproducible: Always User Profile Reset: No Additional Info: When you turn off the "Automatic spell checking" , it seems to be working fine. This bug is not visible in the Windows OS. Not reproduced with [2025-07-10] Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7ef1c437f30b0869a5b9fa33809bac2c6665ace3 CPU threads: 2; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: ja-JP (ja_JP.UTF-8); UI: en-US Calc: threaded Reproducible with [2025-07-20] Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 3a2b9f384ca7b3ddfec2cc73f5cad0b67ed7483d CPU threads: 2; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: ja-JP (ja_JP.UTF-8); UI: en-US Calc: threaded
Created attachment 201910 [details] sample png Text may overflow regardless of whether "Automatic spell checking" is on or off. I'm not sure about the rules of this glitch.
Created attachment 201911 [details] sample file
confirmed and bisected. Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 6c8b8020510f8816c40a42e6c3a7fde12012b142 CPU threads: 4; OS: Linux 6.11; UI render: default; VCL: gtk3 Locale: ja-JP (ja_JP.UTF-8); UI: en-US Calc: threaded commit 6c8b8020510f8816c40a42e6c3a7fde12012b142 author Armin Le Grand StripPortions: full Primitive usage for EditEngine Paint
Taking a look. Happens as described. Now I need to find out what happened before, I am not a calc specialist. Checking out including 6c8b8020510f8816c40a42e6c3a7fde12012b142 since there is env var DISBALE_EDITENGINE_ON_PRIMITIVES to switch off that change temporarily and checking what happens there...
Analyzed and found: In ImpEditEngine::DrawText_ToPosition there are cases (like here with calc) where a ClipRegion is set at the target OutputDevice. This needs to be taken care of when using primizives to render this. Checking how to do that best...
Solution on gerrit, see https://gerrit.libreoffice.org/c/core/+/192919. Good catch! I did check calc when doing this, but obviously did not know about all possibilities, so I missed that one.
The fix is to use the set ClipRange what works and is necessary. I also added tests similar to other places to check if something needs to be painted at all, but that reveals a problem: Despite this thest being correct and due to the ClipRegion indeed *nothing* needs to be rendered at all, I cannot return here, the rendering of 'nothing' at the end of this method using a PrimitiveRenderer *has* to happen. The UnitTest CppunitTest_sc_pdf_export (and others) fail, showing that some pdf export data is mis-aligned when returning. That again shows that in StripAllPortions above in case of pdf export some pdf data seems to be 'prepared' and needs to be 'closed' by painting (actually nothing). The versions before primitive rendering did that distributed inside of ImpEditEngine::StripAllPortions mixed with direct calls to TextRendering at the OutputDevice - using already wildly distributed handling of pdf and needed embedded pdf data. This again shows that we *urgently* need a pdf export/creation isolated and cleanly based on primitive data, sigh... Now it's task is to create primitives which then get rendered to a PrimitiveProcessor, in case of pdf export a VclMetafileProcessor2D. That processor will create all the needed pdf data based on the primitive data, so any direct creation of that data in primitive creation is an error. Since this is right now too dangerous to do combined with this bugfix I will just accept to render empty content completely clipped away, but I will have a look on what's going on afterwards and try to clean this up, so we will at least have two commits (if that works) just in case this needs more work or revert.
After debugging a while and not finding any evidence of that pdf stuff I realized that it was wrong alarm: I did those clip stuff & tests too early, it needs to be done *after* aStartPos is added to the primitives, else wrong positions are checked. After correcting that also the UnitText works :-/ Corrected version on gerrit...
Armin Le Grand (collabora) committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/fa7ed3501e1ee47600b41985b7c5b7f60a6a8b29 tdf#167605 take ClipRegion at OutDev into account It will be available in 26.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Change on master, should be done. Please have a look.
(In reply to Armin Le Grand (collabora) from comment #10) > Change on master, should be done. Please have a look. Thank you, This was a very serious problem for me.
*** Bug 167777 has been marked as a duplicate of this bug. ***