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.
Seeing bug 50879, this may be a deliberate regression. But users may prefer different fonts either for style or for readability.
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
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.
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.
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.
My bad, exported from wrong app. If I exprt directly from LibreOffice, Courier works.
*** Bug 143110 has been marked as a duplicate of this bug. ***
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.
(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
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?