Bug 145553 - Improve UI on export of form-fillable pdfs, provide UI to set a suitable "PDF default" (now is Helevetica by default) and warn of subset for other user-selected (non-PDFcore) fonts
Summary: Improve UI on export of form-fillable pdfs, provide UI to set a suitable "PDF...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
7.1.5.2 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 143110 (view as bug list)
Depends on:
Blocks: PDF-Export
  Show dependency treegraph
 
Reported: 2021-11-05 10:24 UTC by MarjaE
Modified: 2024-03-24 15:51 UTC (History)
4 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 MarjaE 2021-11-05 10:24:24 UTC
1. Create draw file.

2. Open Form Controls, create a fillable text field, open Control Properties, select a font.

3. Export as pdf.

4. Open in a pdf viewer, click on the text field, start typing. It's in Helvetica for some reason.
Comment 1 MarjaE 2021-11-05 10:33:28 UTC
Seeing bug 50879, this may be a deliberate regression. But users may prefer different fonts either for style or for readability.
Comment 2 V Stuart Foote 2021-11-05 14:01:53 UTC
Expected behavior, for dev perspective see 

https://bugs.documentfoundation.org/show_bug.cgi?id=50879#c61

Quoting Miklos:

Yes, this is the whole point of this bug. Given that pdf only embeds used subsets of the fonts, and editable pdf forms may contain any characters, the only sane option seems to be to use fonts in form controls which are mandated to be present in pdf readers.

Meaning, we will not (i.e. can not reliably) use other fonts for fillable forms.

So, this is an enhancement and IMHO => WF
Comment 3 Timur 2021-11-05 19:41:57 UTC
In that bug not all was done, UX agreed to warn the user during export that he/she is using nonstandard fonts in form fields and give a simple confirmation box:

Your document contains non-standard fonts that might be not readable on other systems. Do you want to include these extra fonts?
[Help]    [Yes, include fonts] [_No, export as it_]

(No is the default, closing the box per x and maybe an additional cancel button should stop the export.)

So I set New.
Comment 4 MarjaE 2021-11-05 21:23:22 UTC
Okay, I understand the logic of choosing *some* standard font that any reader is likely to be able to use.

In that case, however

1. An alert during export that LibreOffice will be substituting Helvetica would be useful.

2. A dialogue during export allowing users to pick from a short list of fonts would be more useful. I have trouble reading computer screens, and Helvetica doesn't help. A choice of fonts could help users export fillable pdfs with easier-to-read and/or more-appropriate fonts.

3. And the rigamarole of selecting fonts, individually, from the full list, for each field turns out to be a useless waste of time. Maybe a short list of the standard fonts would be useful.
Comment 5 MarjaE 2021-11-06 01:32:05 UTC
P.S. And after creating a document with Courier, which I find the most readable of the standard fonts, LibreOffice exports the Courier as Helvetica, the least readable.
Comment 6 MarjaE 2021-11-06 01:35:04 UTC
My bad, exported from wrong app. If I exprt directly from LibreOffice, Courier works.
Comment 7 Timur 2022-07-28 12:58:26 UTC
*** Bug 143110 has been marked as a duplicate of this bug. ***
Comment 8 Brenton Chapin 2023-06-29 12:46:20 UTC
I reported bug 143110 which was tagged as a duplicate of this bug.  Per the request in bug 126687 that 143110 was mistakenly tagged as duplicating, I tested for the problem again.  As of 7.5.4.2, it is still not working.

In 143110, I said why it wasn't working: support for different fonts for text entry fields was never implemented.  LibreOffice still does and will still always uses Helvetica for text entry fields in PDF forms until support for different fonts is implemented.  Fixing it could be as simple as using the existing code that embeds the fonts used for text in plain PDFs.
Comment 9 V Stuart Foote 2023-06-29 15:40:28 UTC
(In reply to Brenton Chapin from comment #8)
> I reported bug 143110 which was tagged as a duplicate of this bug.  Per the
> request in bug 126687 that 143110 was mistakenly tagged as duplicating, I
> tested for the problem again.  As of 7.5.4.2, it is still not working.
> 
> In 143110, I said why it wasn't working: support for different fonts for
> text entry fields was never implemented.  LibreOffice still does and will
> still always uses Helvetica for text entry fields in PDF forms until support
> for different fonts is implemented.  Fixing it could be as simple as using
> the existing code that embeds the fonts used for text in plain PDFs.

This is the correct BZ issue and is intentional, see comment 3 here and discussion on bug 50879 as resolved [1].

Issue is not the embedding. Rather that PDF do not embed full font's, just subsets (and even then those are not installable). Meaning, authoring a PDF form with fields that can not be filled makes no sense--to ensure a form can be filled the PDF export filter changes font used for fields to PDF "standard" compliant font that "should" be available to the PDF reader in use. Normally Helvetica, but it will respond to font family selection made in Writer.

Meaning--still up to the form designer to select a suitable [2] font in Writer if they need WYSIWYG for the form. Of course YMMV with os/DE font fallback handling of the output from the PDF reader.

Potential to refactor (major dev effort), but as noted project approach is to acknowledge that incomplete subsetting leads to useless forms (or bloated PDF with a full font) and instead to use one of the core 14 PDF fonts defined by Adobe--so that any reader/form filler will accommodate. We can't/shouldn't do more than that.

But what is still needed, for UX, is missing UI feedback to author when exporting to form from Writer that they are exporting a form designed with fillable fields without font support.

@Miklos, Khaled -- anything to add?

=-ref-=
[1] https://gerrit.libreoffice.org/c/core/+/99032

[2] 
Fixed Pitch Fonts
 Courier
 Courier-Bold
 Courier-Oblique
 Courier-BoldOblique

Proportional Fonts
 Helvetica
 Helvetica-Bold
 Helvetica-Oblique
 Helvetica-BoldOblique
 Times-Roman
 Times-Bold
 Times-Italic
 Times-BoldItalic
 Symbol
 ZapfDingbats
Comment 10 Brenton Chapin 2023-06-29 22:47:19 UTC
I think you should reconsider.  Firstly, I admire efficiency, of space.  But that's not what PDF is about.  As everyone who works with PDF knows, it is an absolutely terrible format if your goal is to save space.  Go ahead and bloat the PDF file with an entire font, to support entry of any text characters.  That's what Acrobat does, and it works.  The forms fields can display any user entered character in any desired font.  Every mainline PDF reader I have tested can show the entered text in the correct font.  So, that's what LibreOffice should do too.  And yes, the resulting PDFs are huge.

Also, the LibreOffice native file format supports and preserves the use in text entry boxes of any font desired.  It's a bit jarring to see such a form work within Writer, then fail to export identically to PDF.  The whole reason for PDF is to preserve the exact look of a document, and when LibreOffice silently changes fonts, it breaks that expectation of PDF.  Don't do that.  At first, I wondered if the problem was a limitation of PDF.

If you're still not convinced, what of the scenario in which both text and text entry fields are using the same non-default font?  The PDF must already have the font embedded for the text, and in that case, adding in the unused glyphs to support their use in a text entry box wouldn't be that big an imposition, would it?