Download it now!
Bug 114351 - Cross-reference does not work as a link in exported PDF
Summary: Cross-reference does not work as a link in exported PDF
Status: CLOSED INVALID
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Fields-Cross-Reference
  Show dependency treegraph
 
Reported: 2017-12-08 16:57 UTC by Matthew Kogan
Modified: 2020-05-20 12:27 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Document that demonstrates cross-reference link not working in exported PDF (102.13 KB, application/vnd.oasis.opendocument.text)
2017-12-08 16:58 UTC, Matthew Kogan
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matthew Kogan 2017-12-08 16:57:10 UTC
Description:
When the attached document is exported headlessly to PDF, one particular cross-reference does not work as a link, even though an identical cross-reference in a previous paragraph works correctly.

Steps to Reproduce:
1. Export the document to PDF with the command line:
soffice --convert-to pdf BrokenCrossRef.odt --outdir %userprofile%\documents
2. Open the exported PDF in Adobe Acrobat Reader
3. Scroll to to the top of page 3

Actual Results:  
The "1.7" in the middle of the first line on page 3 should be a link to paragraph 1.7 on the previous page.

Expected Results:
The "1.7" in the middle of the first line on page 3 is not a link. I did notice, though, that part of the word "uxjas" just before the "1.7" is a link to the correct paragraph, though. It looks like the link is just not quite where it should be.


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 5.3.7.2
Build ID: 6b8ed514a9f8b44d37a1b96673cbbdd077e24059
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; Layout Engine: new; 
Locale: en-GB (en_GB); Calc: group


User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Comment 1 Matthew Kogan 2017-12-08 16:58:31 UTC
Created attachment 138317 [details]
Document that demonstrates cross-reference link not working in exported PDF
Comment 2 Dieter 2017-12-09 08:46:03 UTC
I tried the following:

1. I opened your document
2. File => Export PDF

The cross-reference on page 3 works correctly. Have you tried it in this way?
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED', your problem isn't solved or to WORKSFORME if the proposed solution works.

Version: 6.0.0.0.beta1 (x64)
Build ID: 97471ab4eb4db4c487195658631696bb3238656c
CPU threads: 4; OS: Windows 10.0; UI render: default; 
Locale: de-DE (de_DE); Calc: group threaded
Comment 3 Matthew Kogan 2017-12-09 11:07:36 UTC
Thank you Dieter. I know that it works correctly when you export it from the GUI. That is why I included the word "headlessly" in the title, and why I explained how to export it with the command line in the steps to reproduce. Exporting from the GUI is not a suitable solution for me, though.

Also, worksforme is defined here https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/RESOLVED#WORKSFORME as "Someone in QA has tested this bug and is unable to reproduce it using the provided steps and/or test documents." so it would be wrong to use it unless you can't reproduce the bug using the *provided* steps, i.e. exporting from the command line.

So, I am changing the status back to unconfirmed.
Comment 4 Buovjaga 2017-12-18 15:57:13 UTC
It does not work correctly from the GUI. 1.7 does not become a link. uxjas is the link. Tested with Adobe Acrobat and Okular.

Arch Linux 64-bit
Version: 6.1.0.0.alpha0+
Build ID: b2d87e00ed93db79ba64a9bef83e20d44c69dd7c
CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group threaded
Built on December 18th 2017

Version: 6.1.0.0.alpha0+ (x64)
Build ID: 0bb0299b29960c3a27427eba5d5fc34e5e913a8b
CPU threads: 4; OS: Windows 10.0; UI render: default; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2017-12-09_00:15:04
Locale: fi-FI (fi_FI); Calc: group threaded

Arch Linux 64-bit
LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4
Comment 5 QA Administrators 2018-12-19 03:51:47 UTC Comment hidden (obsolete)
Comment 6 Matthew Kogan 2019-01-03 18:16:13 UTC
I downloaded 6.2.0 RC1 to test this, and I couldn't even open the document I attached. It says:

Read Error.
Format error discovered in the file in sub-document styles.xml at 1,538888(row,col).

Anyway, I opened and re-saved the document in 5.4, which fixed the error opening it in 6.2.0, and this version does indeed seem to have fixed the bug. I also tested 6.1.4, and it was still broken in that version.

Could somebody tell me what exactly is causing the read error, please?
Comment 7 Buovjaga 2019-01-03 19:50:22 UTC
(In reply to Matthew Kogan from comment #6)
> I downloaded 6.2.0 RC1 to test this, and I couldn't even open the document I
> attached. It says:
> 
> Read Error.
> Format error discovered in the file in sub-document styles.xml at
> 1,538888(row,col).

I bibisected the error and then did a search for existing reports referencing the same problematic commit. I found several and this looks most similar: bug 122144
So let's follow that one. Maybe we should wait for it to be fixed before closing this.
Comment 8 Justin L 2019-01-28 18:28:04 UTC
(In reply to Matthew Kogan from comment #6)
> Could somebody tell me what exactly is causing the read error, please?
In styles.xml, the right page footer is looking for a background image file, but there is no image in the Pictures subfolder.
Comment 9 Matthew Kogan 2019-01-28 20:50:41 UTC
OK, that'll be my fault - I deleted the image as part of the anonymisation of the file. It's a little odd that 6.2 fails to open a file that 5.4 opens successfully, but at least I know now that it's an artificial situation.
Comment 10 AndrewForrest 2019-04-30 07:36:52 UTC Comment hidden (spam)
Comment 11 morganalice 2019-05-21 06:04:24 UTC Comment hidden (spam)
Comment 12 Patricia Sperry 2019-07-26 10:20:08 UTC Comment hidden (spam)
Comment 13 jasonry2786 2019-08-10 08:41:59 UTC Comment hidden (spam)
Comment 14 Mark Carlton 2019-09-20 10:22:56 UTC Comment hidden (spam)
Comment 15 abeerhayat 2019-10-11 10:40:09 UTC Comment hidden (spam)
Comment 16 Jeniifer 2020-03-09 04:06:50 UTC Comment hidden (spam)
Comment 17 William Mike 2020-05-05 11:03:04 UTC Comment hidden (spam)
Comment 18 Noah Rufus 2020-05-06 10:32:32 UTC Comment hidden (spam)
Comment 19 Robert Walt 2020-05-07 09:59:02 UTC Comment hidden (spam)
Comment 20 Robert Walt 2020-05-07 09:59:50 UTC Comment hidden (spam)
Comment 21 Oliver Mike 2020-05-08 10:51:47 UTC Comment hidden (spam)
Comment 22 Oliver Mike 2020-05-11 13:21:15 UTC Comment hidden (spam)
Comment 23 Timur 2020-05-20 12:17:41 UTC
Reading all this and comment 6 and bug from comment 7, I don't see a point in keeping this open. If you disagree, please explain,
Comment 24 Matthew Kogan 2020-05-20 12:27:31 UTC
I agree with closing it, although I object a little to it being closed as invalid. It was a bug, which was fixed in 6.2.