Open pdf file blank or failed #287

Activity

1. c-prompt commented on Apr 3, 2023

   

   c-prompt

   on Apr 3, 2023

   More actions

   I'm experiencing the same problem:

   Doesn't matter if pdfviewer is enabled or disabled. Tried multiple browsers and multiple files/file sizes. pdfviewer shows the files correctly.

   NextCloud 26.0.0 Community Document Server 0.1.13 ONLYOFFICE 7.8.0 PDF viewer 2.7.0

   The OpenOffice team suggested suggested posting here as Community Document Server is created by Nextcloud.
2. github-actions commented on Feb 19, 2024

   

   github-actionsbot

   on Feb 19, 2024 – with GitHub Actions

   More actions

   This issue has been marked 'stale' due to lack of recent activity. If there is no further activity, the issue will be closed in another 60 days. Thank you for your contribution!

   Retaking repo management include inheritance of old, not treated, and probablty obsolete issues, this is why it was decided to mark issues as stale.
3. github-actions

   added

   stale

   on Feb 19, 2024
4. binaryfire commented on May 2, 2024

   

   binaryfire

   on May 2, 2024

   Last edited by binaryfire

   More actions

   I'm experiencing the same problem with 0.1.17 and OnlyOffice 9.2.0.

   Looks like this issue has been open for more than 1 year. Does that mean this won't be fixed?
5. github-actions

   removed

   stale

   on Nov 4, 2024
6. joshtrichards

   added

   bugSomething isn't workingSomething isn't working

   on Mar 3, 2025
7. chadek

   added 2 commits that reference this issue on Sep 15, 2026

   Pin the bundled font paths so PDF export is not blank (nextcloud#371, n…

   ...

   bc07ff6

   Pin the bundled font paths so PDF export is not blank (#371, #251, #287…

   ...

   8fea4eb
8. chadek commented on Sep 15, 2026

   

   chadek

   on Sep 15, 2026

   Collaborator

   More actions

   Fixed for v0.4.0, by #402, for the blank part of what you reported.

   Your two screenshots are two different problems, and I want to be clear about which one this is. The 139 KB PDF opening blank is the one fixed here. The 50 MB PDF failing to open is not — that is a size/resource limit in the converter, and if it still bites you on v0.4.0 it is worth its own issue with the log line the conversion produces, which will now actually say something.

   What it was. server/FileConverter/bin/font_selection.bin stores an absolute path to every bundled font, written by whichever machine ran allfontsgen — the build machine, for an app store install. When one of those paths does not resolve on the machine that is running, x2t's PDF writer prints Can't load fontfile on stdout, writes a PDF with no glyphs in it, and exits 0. Nothing was logged and nothing was thrown, so from everywhere else in the system a blank PDF and a good one were the same successful conversion. That is why this stood for four years: there was no failure to find.

   Same input, same binary, same exit code:

   font_selection.bin holds	x2t exit	PDF size	text characters
   paths that do not resolve here	0	1 937 B	0
   paths pinned to ../../../core-fonts/	0	12 804 B	the text that went in

   The build already pinned AllFonts.js to paths relative to x2t's working directory and deliberately left font_selection.bin alone, on a belief written into the Makefile: that its paths "are not used for loading". They are not used by the change-replay path that comment is about, which reads AllFonts.js. They are used by the PDF writer.

   What changed (#402):

   • The paths are pinned relative at build time, so one machine's layout is no longer shipped to everybody. x2t accepts relative paths in font_selection.bin — verified first, since AllFonts.js accepting them does not prove it. The file is not sed-able (its strings are length-prefixed with a little-endian int32, so replacing one without fixing its prefix corrupts everything after it), so the rewriter is a real one, shared between the build and the runtime rebuild so both produce the same thing. Custom fonts live in appdata, outside the app directory, and keep the absolute paths they are found at.
   • A font rebuild that does not rebuild now says so. The old check accepted any AllFonts.js containing /core-fonts/ — including a stale one left over from the build — so a rebuild that wrote nothing at all reported success, and it never looked at font_selection.bin at all. It now verifies that this run wrote both files, that the write succeeded, and that every pinned path resolves; and it refuses up front, naming the file and the user, when it cannot write. That case is the shape of Exception: sh: ../../tools/allfontsgen: not found #145 and Segmentation fault while rebuilding fonts #278, each of which left the user with blank PDFs and no diagnostic.
   • The failure is visible now. x2t's stdout is scanned for Can't load fontfile and logged, rather than discarding the one stream that mentioned it. occ documentserver:fonts also returned 1 on success and 0 on failure, so anything scripting it was told the opposite of what happened.

   Proof. tests/rig/pdf_test.py is new — the rig had no PDF coverage at all, which is exactly why this survived. It asserts on extracted text rather than file size. Run against master just now, Nextcloud 34, ONLYOFFICE connector 10.1, bundled Euro-Office 9.3.4:

   == a converted PDF has the text in it
      ok - "PdfFontProbe" is in the 12859 byte PDF
   == a font path that does not resolve reaches the log
      ok - logged, and the PDF came out blank as expected
   == a font rebuild that cannot write says so
      ok - exit 1, and it named the file
   
      VERDICT: conversion=ok reported=ok rebuild=ok
   -- pdf: PASS in 6s
   

   The second case deliberately breaks a font path and checks that the blank PDF is now reported, so the silent-failure half cannot come back either. It was confirmed to fail against the pre-fix font file (FAIL - "PdfFontProbe" is not in the 1937 byte PDF).

   This ships in v0.4.0, and the test runs in CI on pull requests and weekly.
9. chadek

   closed this as completedin #400on Sep 16, 2026