Bug 138625 - FILEOPEN DOCX: The footnote/endnote number in an imported word text is not in a superscript (non-English UI only), because its formatting loaded in a new character style named "Footnote Characters" or "Endnote Characters"
Summary: FILEOPEN DOCX: The footnote/endnote number in an imported word text is not in...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.0.0.3 release
Hardware: Other All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard: non-English-UI-needed target:7.5.0 ta...
Keywords: filter:docx
Depends on:
Blocks: Footnote-Endnote DOCX-Styles DOCX-Footnote-Endnote 82173
  Show dependency treegraph
 
Reported: 2020-12-02 18:04 UTC by Francesco
Modified: 2022-10-10 09:04 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Comparison between original text and imported text (155.87 KB, image/png)
2020-12-02 20:58 UTC, Francesco
Details
Word original document (18.48 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2020-12-03 08:24 UTC, Francesco
Details
Doc per Bugzilla_fileopen.pdf: exaggerated fontsize of 22 to show superscript on file open (27.58 KB, application/pdf)
2020-12-29 10:32 UTC, Justin L
Details
The example file in current master, en_US UI (210.61 KB, image/png)
2021-07-28 17:03 UTC, NISZ LibreOffice Team
Details
The example file in current master, hu-HU UI (198.94 KB, image/png)
2021-07-28 17:05 UTC, NISZ LibreOffice Team
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Francesco 2020-12-02 18:04:39 UTC
Description:
When I import a text in .doc or .docx format containing footnotes, regularly the reference number of the note is not placed at the superscript, as in the original, but is written in normal font. To modify it I have to go to the style menu.

Actual Results:
Import a .doc or .docx document that has footnotes with the note number at superscript. 

Expected Results:
The imported text does not have a footnote number in superscript.


Reproducible: Always


User Profile Reset: No



Additional Info:
Maintain the formatting of the footnote as in the original.
Comment 1 Roman Kuznetsov 2020-12-02 18:50:01 UTC

*** This bug has been marked as a duplicate of bug 108765 ***
Comment 2 Justin L 2020-12-02 19:15:41 UTC
I don't think this is a duplicate. That bug report is talking about CREATING new footnotes, but this one is talking about just importing. The importing part ought to be identical. We would need to have an example document as well.
Comment 3 Roman Kuznetsov 2020-12-02 19:51:49 UTC
(In reply to Justin L from comment #2)
> I don't think this is a duplicate. That bug report is talking about CREATING
> new footnotes, but this one is talking about just importing. The importing
> part ought to be identical. We would need to have an example document as
> well.

I though that a root of the problem is the same. Of course feel free to change a status to NEW if you think differently. Thanks
Comment 4 Francesco 2020-12-02 20:58:51 UTC
Created attachment 167774 [details]
Comparison between original text and imported text

I enclose two screenshots: the first from the original document in .docx (Microsoft Word for Mac, version 16.43); the second from the same text imported into Libre Office (version 7.0.3.1).You can see that the footnote number in the imported text (1) is not in superscript and - (2) second bug not always needed, the number that is replaced by a 'zero' is missing.
Comment 5 Justin L 2020-12-03 04:55:09 UTC
Thanks for the screenshots Francesco. What we really need is the original DOCX file too. Actually, it would be best if you just make a simple, 1 footnote document that demonstrates the problem. If you can't reproduce it in a new document, then attaching the original is OK - and someone else can try to reduce it to a useable problem-demonstrator.
Comment 6 Francesco 2020-12-03 08:24:55 UTC
Created attachment 167782 [details]
Word original document

I send only one page of the original document in word .docx. When you import this document into Libre you see only the first bug (the numbers of the notes no longer in superscript), but not the second (the replacement of numbers with zeros), because this problem arises only when the document is very long (about 554,000 characters).
Comment 7 Francesco 2020-12-03 08:25:12 UTC Comment hidden (no-value)
Comment 8 Justin L 2020-12-10 13:17:17 UTC
(In reply to Francesco from comment #6)
> in LibreOffice you see only the first bug (the numbers of the
> notes no longer in superscript).
I cannot reproduce this in 6.4.7 or master. The first five footnote numbers are all in superscript. (The tops clearly all align with the top of the footnote text, but the bottom of the number is definitely higher than the bottom of the footnote text.)  To my eyes, it is identical to Word 2016.
Comment 9 Roman Kuznetsov 2020-12-28 20:16:43 UTC
I can confirm the problem in

Version: 7.1.0.0.alpha1+
Build ID: 6427bf87360a97f41ae351feaa35975c868260ec
CPU threads: 4; OS: Linux 5.5; UI render: default; VCL: kf5
Locale: ru-RU (ru_RU.UTF-8); UI: ru-RU
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-11-04_14:28:50
Calc: threaded
Comment 10 Justin L 2020-12-29 10:32:52 UTC
Created attachment 168554 [details]
Doc per Bugzilla_fileopen.pdf: exaggerated fontsize of 22 to show superscript on file open

OK - I think by import you are referring to Insert - Text from file. In that case, the existing footnote style is not changed to match the definition in the DOCX file.  (I wouldn't consider that to be a bug.)
Comment 11 Francesco 2020-12-29 11:00:46 UTC
No, by "import" I mean. "opening in Libre a .doc file created with Microsoft Word". Note that this problem only occurs when the file is very long, not for short documents.
Comment 12 NISZ LibreOffice Team 2021-07-28 17:03:56 UTC
Created attachment 173929 [details]
The example file in current master, en_US UI

Looks good in:

Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 67f2a99229101757af4f40118f4d3c83ba38648b
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win
Locale: hu-HU (hu_HU); UI: en-US
Calc: CL
Comment 13 NISZ LibreOffice Team 2021-07-28 17:05:28 UTC
Created attachment 173930 [details]
The example file in current master, hu-HU UI

Less so in:

Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 67f2a99229101757af4f40118f4d3c83ba38648b
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win
Locale: hu-HU (hu_HU); UI: hu-HU
Calc: CL

There might be something funny with importing the localized (or not) character style names.
Comment 14 Justin L 2022-09-12 18:03:49 UTC
For English UI, this was fixed in LO 6.0
commit 707eb4db1918658e0c2c2c2033c6a69f80c4eafd
Author: Justin Luth on Sat Jun 3 10:02:20 2017 +0300
    tdf#82173 writerfilter: charStyle XnoteReference->Xnote Characters
Comment 15 Commit Notification 2022-10-03 19:21:20 UTC
László Németh committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/5a1c668747f3495ddc7567ae95f2145663565647

tdf#138625 DOCX import: fix superscript footnote numbering in l10n

It will be available in 7.5.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.
Comment 16 László Németh 2022-10-04 12:28:59 UTC
Note: non-English-UI-needed, i.e. to check the fix is enough an arbitrary non-English localized build with the Italian test document of the bug report.

Commit description:

tdf#138625 DOCX import: fix superscript footnote numbering in l10n

Footnote/endnote numbers in the footnote area didn't get
superscript etc. formatting in non-English locale
settings because of the writerfilter mapping to
the English localization ("Footnote Characters" and
"Endnote Characters") instead of the correct
programmatic character style names ("Footnote Symbol"
and "Endnote Symbol") according to
SwStyleNameMapper::GetChrFormatProgNameArray().

Testing: unit test of tdf#82173. Manual: e.g. open test
document of tdf#138625 in an Italian build, after setting
Italian locale in it in Tools->Options...->Language Settings->
Languages->Language of user interface.

Follow-up to commit 707eb4db1918658e0c2c2c2033c6a69f80c4eafd
"tdf#82173 writerfilter: charStyle XnoteReference->Xnote Characters".
Comment 17 Commit Notification 2022-10-04 12:31:23 UTC
László Németh committed a patch related to this issue.
It has been pushed to "libreoffice-7-4":

https://git.libreoffice.org/core/commit/b4ce64c4a02ad81a5f08623bab22910ef3daedbf

tdf#138625 DOCX import: fix superscript footnote numbering in l10n

It will be available in 7.4.3.

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.
Comment 18 László Németh 2022-10-04 14:35:17 UTC
Note: the bad mapping resulted a new character style named "Footnote Characters" (while the localized Footnote Characters style, e.g. in a Hungarian locale "Lábjegyzet
Comment 19 László Németh 2022-10-04 14:38:23 UTC
-karakterek" (end of the prev. comment).
Comment 20 Roman Kuznetsov 2022-10-04 18:35:25 UTC
Verified the fix in

Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 85353c42de80e7492f5c80499e18375f942c75c9
CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Vulkan; VCL: win
Locale: ru-RU (ru_RU); UI: ru-RU
Calc: threaded

Thank you László!
Comment 21 Commit Notification 2022-10-05 05:14:54 UTC
László Németh committed a patch related to this issue.
It has been pushed to "libreoffice-7-3":

https://git.libreoffice.org/core/commit/26e323976cc29b549eeb3c0f586e007045a3206e

tdf#138625 DOCX import: fix superscript footnote numbering in l10n

It will be available in 7.3.7.

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.
Comment 22 László Németh 2022-10-10 09:04:24 UTC
(In reply to Roman Kuznetsov from comment #20)
> Thank you László!

@Roman: thanks for the verification and feedback!