Bug 162382 - DOCX: (Non-printing) red triangle added to side of (textbox-replacing) frame
Summary: DOCX: (Non-printing) red triangle added to side of (textbox-replacing) frame
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.5.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 50301 DOCX
  Show dependency treegraph
 
Reported: 2024-08-07 08:21 UTC by Eyal Rozenberg
Modified: 2024-09-11 07:09 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
DOC file (839.50 KB, application/msword)
2024-08-07 08:21 UTC, Eyal Rozenberg
Details
DOCX file (1.44 MB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2024-08-07 08:21 UTC, Eyal Rozenberg
Details
Red triangle showing with LO Writer 24.2 and the DOCX from attachment 195747 (15.04 KB, image/png)
2024-08-07 08:23 UTC, Eyal Rozenberg
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eyal Rozenberg 2024-08-07 08:21:17 UTC
Created attachment 195746 [details]
DOC file

Context-free description:

Consider the attached DOC and DOCX file, saved from the save document by MS-Word 2402. It contains a frame with some text in Arabic.

When we open the DOCX file in LO Writer, we can observe several aspects of problematic behavior, but for the sake of this bug - a red triangle, pointing rightwards, is rendered on the right side of the frame. The triangle cannot be left-clicked, and right-clicking it doesn't seem to bring up a relevant context menu.

If we open the DOC file, we don't see the triangle. The triangle does not appear in MS-Word, when opening any of the files.

----

Now for some background:

This is one of several bugs separating out the issues we see in the infamous DOC from in bug 50301.

The attached document is attachment 62050 [details] with everything removed except for that single frame, and the number of columns reduced to 1.
Comment 1 Eyal Rozenberg 2024-08-07 08:21:44 UTC
Created attachment 195747 [details]
DOCX file
Comment 2 Eyal Rozenberg 2024-08-07 08:23:32 UTC
Created attachment 195748 [details]
Red triangle showing with LO Writer 24.2 and the DOCX from attachment 195747 [details]
Comment 3 Eyal Rozenberg 2024-08-07 08:33:18 UTC
I should mention that in Word, the object is indicated to be a textbox, not a frame. When opened in LO it says "frame".
Comment 4 Aron Budea 2024-08-07 13:13:08 UTC
The red triangle indicates the frame's content didn't fit in the visible area.
Comment 5 Eyal Rozenberg 2024-08-07 21:07:29 UTC
(In reply to Aron Budea from comment #4)
> The red triangle indicates the frame's content didn't fit in the visible
> area.

1. But it did fit in the visible area. And the triangle stays even if you delete more of the text.
2. The triangle stays there even when I toggle "text boundaries" off, and every other mark setting there.
3. Don't get that from the DOC.
Comment 6 Aron Budea 2024-08-08 06:11:03 UTC
(In reply to Eyal Rozenberg from comment #5)
> 1. But it did fit in the visible area. And the triangle stays even if you
> delete more of the text.
I just explained what the triangle is supposed to indicate.

> 3. Don't get that from the DOC.
I do, even from 3.3.0.
What I also see is that while with DOCX LO has the font B Nazanin in the font list, with DOC it doesn't, and the font name is shown in italic there, meaning it's substituted. Maybe it isn't supported in that format... no idea.

In case of DOCX, I start seeing the triangle with the following commit in 7.6:
https://git.libreoffice.org/core/commit/1263873edf86ce223ee54ecd93297273ac3b0e9f
Author:     Khaled Hosny <khaled@libreoffice.org>
AuthorDate: Sun Jun 4 23:28:59 2023 +0300
Commit:     خالد حسني <khaled@libreoffice.org>
CommitDate: Mon Jun 5 06:37:58 2023 +0200

    tdf#155297: Use usWinAscent and usWinDescent for B Nazanin font
Comment 7 Buovjaga 2024-09-10 11:58:52 UTC
Seems like the descent in the font is going some nanometer below the frame. Either make the font smaller or increase height of frame.

I do see the indicator even in the .doc file, but as the font is substituted, it's enough to just remove characters to make it go away.

Arch Linux 64-bit
Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 880096c3a970389de9f1272509d2d03df046570a
CPU threads: 8; OS: Linux 6.10; UI render: default; VCL: kf6 (cairo+wayland)
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: CL threaded
Built on 10 September 2024
Comment 8 Eyal Rozenberg 2024-09-10 21:03:59 UTC
(In reply to Buovjaga from comment #7)
> I do see the indicator even in the .doc file, but as the font is
> substituted, it's enough to just remove characters to make it go away.

But why does it appear at all? I don't remember seeing something like this in Writer. There is also no tooltip for it, nor the ability to right-click it. What does it signify? And how would the user know what it signifies?

In Calc, we can guess what arrows mean: Cell area not large enough for the contents. But in Writer, that's not a thing we should be warned about.
Comment 9 Buovjaga 2024-09-11 06:06:10 UTC
(In reply to Eyal Rozenberg from comment #8)
> (In reply to Buovjaga from comment #7)
> > I do see the indicator even in the .doc file, but as the font is
> > substituted, it's enough to just remove characters to make it go away.
> 
> But why does it appear at all? I don't remember seeing something like this
> in Writer. There is also no tooltip for it, nor the ability to right-click
> it. What does it signify? And how would the user know what it signifies?

Well, now you've seen it. It signifies hidden overflow, as explained by Áron in comment 4. Probably you have not seen it, because when you create a new frame in Writer, the AutoSize option is active.
 
> In Calc, we can guess what arrows mean: Cell area not large enough for the
> contents. But in Writer, that's not a thing we should be warned about.

I don't see why it shouldn't be indicated. Exactly in the case of the files in this report it is useful.
Comment 10 Eyal Rozenberg 2024-09-11 07:09:18 UTC
Fair enough for closing this bug.