Bug 169327 (PDF-Pages-as-Backgrounds) - [META] Support for a PDF-form-filling workflow (Use PDF pages as background images)
Summary: [META] Support for a PDF-form-filling workflow (Use PDF pages as background i...
Status: UNCONFIRMED
Alias: PDF-Pages-as-Backgrounds
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on: 81118 PDF-Import-Draw PDF-Insert 114234 169329 169324 169330
Blocks: Page ImpressDraw-Enhancements
  Show dependency treegraph
 
Reported: 2025-11-07 21:25 UTC by Eyal Rozenberg
Modified: 2025-11-10 11:56 UTC (History)
2 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 Eyal Rozenberg 2025-11-07 21:25:37 UTC
One common task many people face is filling in forms available as PDFs - but not PDFs with fancy dynamic widgets, just regular forms one traditionally prints out and fills manually. To fill such forms on your computer, you must open the PDF in an application which is willing to treat its contents as background, and let you add text, lines, check-marks, images (e.g. your signature or photo) and so on.

There are two ways Draw could support this workflow:

I. With the PDF opened in Draw the 'regular' way:

    * Content reproduction would need to be perfect
    * User would need to be able to "freeze" the pre-existing content while making
      additions. This is currently achievable by selecting all PDF-importent 
      elements on each page, grouping, and in the object properties, protecting 
      the size and position. That is still not perfect, since that 'background'
      is still selectable.

II. The hacky way: Page background images

    * On each page, user sets the page background image to some page of the PDF 
      ... except that this is not quite supported right now - only the
      first page of the PDF is chosen when the PDF file is selected.
    * The page size needs to be set to that of the PDF pages

III. A specialized way of opening a PDF

    * Either a separate input filter, or a flag for the current input filter
      would need to be set.
    * The page size would be set to the PDF page size (and it will be a problem
      if that's not uniform, since Draw only support a single uniform page size)
    * The user would not need to do anything after opening the page - just make
      their additions

Approach (I.) is supposedly "usable" right now, but - the PDF import is far from being faithful to the source. See bug 99746 and its dependents for a plethora of issues. Also, it requires hassle on part of the user the "background-ize" the opened PDF.

Approach (II.), although hacky, is the closest thing to working right now. If one separates the PDF form into individual pages - it actually does work, with the hassle limited to the page-separation, the setting-of-background-images and the page resizing.

Approach (III.) is something we don't have at all, but - would be the most convenient (and discoverable) for users.

These approach are not mutually exclusive, and the 'blockers' for each of them are worthy bugs to resolve / features to have, in their own right. I propose this meta-bug for tracking them all.


An app which supports this as its native (and only) mode of operation is Xournal++: https://github.com/xournalpp/xournalpp  . I personally often use it over Draw for filling forms, but - when I think about, I really shouldn't have to.
Comment 1 Heiko Tietze 2025-11-10 07:58:30 UTC
Please do not add ux-advice to META tickets.