Bug 156477 - PDF export: Fit Width / Visible make the PDF open with the target large page scrolled down in PDF viewer
Summary: PDF export: Fit Width / Visible make the PDF open with the target large page ...
Status: RESOLVED FIXED
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: Neil Fachin
URL:
Whiteboard: target:26.2.0 target:25.8.1
Keywords: difficultyBeginner, easyHack, filter:pdf, skillCpp
Depends on:
Blocks: PDF-Export-Options-Dialog
  Show dependency treegraph
 
Reported: 2023-07-26 10:36 UTC by Mike Kaganski
Modified: 2025-07-31 01:49 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Kaganski 2023-07-26 10:36:19 UTC
1. Create a new text document;
2. Make its page size A3;
3. File->Export As->PDF;
4. On Initial View tab, keep "Open on page" -> 1, and choose "Fit width";
5. Continue exporting.

=> opening the resulting PDF in e.g. Acrobat Reader will show the first page not from top, but from its middle. Same thing would happen for "Fit visible".

This is a wrong implementation from start, using /FitBH with a hardcoded vertical offset "g_nInheritedPageHeight" (A4 portrait hardcoded value) for "Fit visible"; and also using the same hardcoded value for /FitH (Fit width); when the actual vertical offset there must come from the actual page itself - or possibly be omitted, as the standard tells "A null value for *top* specifies that the current value of that parameter shall be retained unchanged".

Code pointer: PDFWriterImpl::emitCatalog in vcl/source/gdi/pdfwriter_impl.cxx.
Comment 1 Stéphane Guillou (stragu) 2023-07-26 12:14:20 UTC
I can't reproduce when opening the resulting PDFs with GNOME Document Viewer, Okular, Foxit Reader, Firefox or Chromium, but my guess is that they don't support the parameter?

See for example for pdf.js the lack of support for the embedded parameter: https://github.com/mozilla/pdf.js/issues/2757
Comment 2 Mike Kaganski 2023-07-26 12:21:51 UTC
(In reply to Stéphane Guillou (stragu) from comment #1)

Missing features in PDF viewers are not handled here ;) Yes, you need a viewer that supports the discussed options of the OpenAction, as described in PDF 32000-1:2008 sect. 12.3.2.2 "Explicit destinations".
Comment 3 Commit Notification 2025-07-29 04:17:02 UTC
Neil Fachin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/54b6ed66901d9dc25e8f1636aca08fb9f3d8b5c6

tdf#155419 tdf#156477 PDF Export: emitCatalog fixes for OpenAction

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.
Comment 4 Commit Notification 2025-07-29 06:37:21 UTC
Neil Fachin committed a patch related to this issue.
It has been pushed to "libreoffice-25-8":

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

tdf#155419 tdf#156477 PDF Export: emitCatalog fixes for OpenAction

It will be available in 25.8.1.

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.