Bug 160870 - Continued footnote number is flipped
Summary: Continued footnote number is flipped
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
24.2.2.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-04-30 13:16 UTC by ardv
Modified: 2024-05-01 07:33 UTC (History)
0 users

See Also:
Crash report or crash signature:


Attachments
number is flipped in page 13 (10.55 KB, application/vnd.oasis.opendocument.text)
2024-04-30 13:17 UTC, ardv
Details
Bad rendering of field value (32.16 KB, application/vnd.oasis.opendocument.text)
2024-04-30 16:36 UTC, ajlittoz
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ardv 2024-04-30 13:16:48 UTC
Description:
If the text in the footnote is in a right to left language then the footnote continue number will be flipped: 14 will be 41


Steps to Reproduce:
1.insert footnotes
2.add a continuation notice in footnotes
3.language is arabic

Actual Results:
41

Expected Results:
14


Reproducible: Always


User Profile Reset: No

Additional Info:
Version: 24.2.2.2 (X86_64) / LibreOffice Community
Build ID: 420(Build:2)
CPU threads: 4; OS: Linux 6.9; UI render: default; VCL: kf6 (cairo+wayland)
Locale: ar-DZ (en_US.UTF-8); UI: en-US
24.2.2-3
Calc: threaded
Comment 1 ardv 2024-04-30 13:17:28 UTC
Created attachment 193906 [details]
number is flipped in page 13
Comment 2 ajlittoz 2024-04-30 16:36:18 UTC
Created attachment 193910 [details]
Bad rendering of field value

This bug report is a follow-on to https://ask.libreoffice.org/t/continues-footnote-numbering-problem/105328/

The bug is more generic than what @ardv describes. IMHO it is related to the way field value is inserted in text.

Once the value of a field is determined , it is converted into a string of characters. This string "loses" any Unicode property, notably the script associated to characters, and it is inserted as a "neutral" collection of glyphs. The characters are inserted one after the other using the writing directionality of the context.

In my attachment, I took the opposite disposition of @ardv: inserting Arabic text inside English. I defined a reference over this Arabic text for later use.

I created a lengthy note. Tools>Footnotes & Endnotes is configured to insert continuation notices start as "0123456789 alef beh teh theh to page" and end as "0123456789 alef beh teh theh from page".

We see that the Arabic strings are inserted in this order instead of "theh teh beh alef 0123456789 to/from page".

The same occurs when a cross-reference tries to duplicate the source.

Field "value" seems to be considered as already laid out and is passed without further manipulation to display (I voluntarily don't use word "rendering" as it seems skipped).

Here LO 7.6.63 (x86_64) VCL kf5 (cairo+xcb)
But occurs also on my other computer with LO 24.2.2.2 and kf6