Bug 50879 - form exported as pdf does not embed all required fonts (see comment 61)
Summary: form exported as pdf does not embed all required fonts (see comment 61)
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
4.0.2.2 release
Hardware: x86-64 (AMD64) All
: high normal
Assignee: Not Assigned
URL:
Whiteboard: target:7.1.0
Keywords: filter:pdf
: 104114 108222 118541 127717 133431 135416 143937 (view as bug list)
Depends on:
Blocks: Fonts PDF-Export
  Show dependency treegraph
 
Reported: 2012-06-08 06:05 UTC by Christian Schlittchen
Modified: 2024-03-24 12:14 UTC (History)
24 users (show)

See Also:
Crash report or crash signature:


Attachments
Document using LiberationSerif and LiberationSans (10.81 KB, application/vnd.oasis.opendocument.text)
2013-12-24 02:21 UTC, Robinson Tryon (qubit)
Details
PDF export of test ODT (16.23 KB, application/pdf)
2013-12-24 02:21 UTC, Robinson Tryon (qubit)
Details
test document (8.36 KB, application/vnd.oasis.opendocument.text)
2014-01-06 10:52 UTC, Christian Schlittchen
Details
pdf exported from test.odt (8.58 KB, application/x-pdf)
2014-01-06 10:52 UTC, Christian Schlittchen
Details
Screenshot of the example file in Acrobat Reader, Chrome and Edge (81.34 KB, image/png)
2019-05-22 12:31 UTC, Gabor Kelemen (allotropia)
Details
Working example from 2009 (109.56 KB, application/pdf)
2019-08-07 10:30 UTC, Gellért Gyuris
Details
Working example from 2009 (34.22 KB, application/vnd.oasis.opendocument.text)
2019-08-07 10:30 UTC, Gellért Gyuris
Details
Oringinal with one form-control (9.22 KB, application/vnd.oasis.opendocument.text)
2020-05-31 13:42 UTC, Robert Großkopf
Details
Exported form - font of control wasn't exported (31.11 KB, application/pdf)
2020-05-31 13:54 UTC, Robert Großkopf
Details
creating this document causes Export as PDF to lose fonts. Loading this document works. (8.92 KB, application/vnd.oasis.opendocument.text)
2021-03-12 00:47 UTC, Brenton Chapin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Schlittchen 2012-06-08 06:05:34 UTC
Form exported to pdf use a font 'LiberationSans' (Linux) or 'SegoeUI' (Windows) but do not embed this font. This makes the exported pdf unusable any platform that does not provide the font in question - form created under Linux are unsable under Windows and vice versa.

A very simple example form created under Linux without any bells and whistles:

~$ pdffonts testformular.pdf 
name                                 type              emb sub uni object ID
------------------------------------ ----------------- --- --- --- ---------
BAAAAA+LiberationSerif               TrueType          yes yes yes     14  0
LiberationSans                       TrueType          no  no  no      16  0
Comment 1 Christian Schlittchen 2013-06-04 08:04:02 UTC
The problem is still there in 4.0.2.2. It is easy to reproduce:

Create a form on Linux, export as PDF, open it using (for example)
Acrobat Reader on Windows. You get a message about missing fonts (LiberationSans
in my case). The static text shows ok, but the form fields only show placeholder chars when filled. Choosing to embed standard fonts while exporting does not
help.

This makes the creation of cross-platform PDF-forms effectivly impossible.
Comment 2 Oho 2013-07-14 07:21:02 UTC
You might save the file as PDF/A-1a.

From LibreOffice Help, by following this choice, the program "Converts [the file] to the PDF/A-1a format. This is defined as an electronic document file format for long term preservation. All fonts that were used in the source document will be embedded into the generated PDF file. PDF tags will be written."

So, all fonts, not only the standard fonts, "will be embedded into the generated PDF file". Maybe you dont want the tags, but you get them, as well.

Of course, the "Export as PDF ..."/"General" dialogue could reveal more about the meaning of the "PDF/A-1a" choice.
Comment 3 Oho 2013-07-14 07:44:26 UTC
The "standard fonts" from the "Embed standard fonts" choice, are "the 14 standard Postscript fonts", according to LibreOffice Help.

The choice "Embed standard fonts" would lead to the embedding of all your document fonts if and only if you are using only [some of] these fonts as fonts in your documents.
Comment 4 Oho 2013-07-14 08:05:42 UTC
The "Export as PDF ..."/"General" dialogue should be less cryptic about the meaning of these two choices:

Perhaps:

- the "embed standard fonts" shoud be replaced by "embed the 14 standard Postscript fonts".

- the "PDF/A-1a" should be replaced by "embed all used fonts and all tags".

Also, the "Embed standard fonts" subtitle under the title "General tab" entry in the help, could be augmented by defining the 14 Postscript standard fonts, something like:

"Specific common Type 1 fonts installed as a part of the Adobe Acrobat installation:

- 4 versions [regular, bold, italic or oblique, and bold italic] of Times (v3) or Times New Roman PS MT (v4.x)
- 4 versions [regular, bold, italic or oblique, and bold italic] of Helvetica (v3) or Arial MT (v4.x)
- 4 versions [regular, bold, italic or oblique, and bold italic] of Courier - 4 versions
- Symbol
- Zapf Dingbats"
Comment 5 Robinson Tryon (qubit) 2013-12-24 02:21:14 UTC Comment hidden (obsolete)
Comment 6 Robinson Tryon (qubit) 2013-12-24 02:21:55 UTC Comment hidden (obsolete)
Comment 7 Robinson Tryon (qubit) 2013-12-24 02:34:14 UTC Comment hidden (obsolete)
Comment 8 Christian Schlittchen 2014-01-06 10:52:18 UTC
Created attachment 91537 [details]
test document
Comment 9 Christian Schlittchen 2014-01-06 10:52:44 UTC
Created attachment 91538 [details]
pdf exported from test.odt
Comment 10 Christian Schlittchen 2014-01-06 10:55:30 UTC
The document you attached is not a form, just a text.

The problem is that the font used for input fields (default is Liberation Sans) needs to be embedded completely, but isn't. My guess is that the algorithm that decides which fonts to embed does not account for form input fields correctly.

I attached a test form odt and the exported pdf:

$ pdffonts test.pdf
name                                 type              encoding         emb sub uni object ID                               
------------------------------------ ----------------- ---------------- --- --- --- ---------                               
BAAAAA+LiberationSerif               TrueType          WinAnsi          yes yes yes     13  0                               
LiberationSans                       TrueType          WinAnsi          no  no  no      15  0
Comment 11 Owen Genat (retired) 2014-09-14 14:42:22 UTC
(In reply to comment #10)
> The problem is that the font used for input fields (default is Liberation
> Sans) needs to be embedded completely, but isn't. My guess is that the
> algorithm that decides which fonts to embed does not account for form input
> fields correctly.

Reproduced under GNU/Linux using v4.3.1.2 Build ID: 958349dc3b25111dbca392fbc281a05559ef6848 using the provided example.
Comment 12 jelhan 2014-10-22 13:19:31 UTC
Bug is still there under LibreOffice Writer 4.2.63 running on Linux Ubuntu 14.04 LTS and Windows 8.1. Only a font subset is embeded even when font is used in a formular. So if user trying to fillout the formular has not installed font he is unable to proceed.
Comment 13 Joel Madero 2014-11-05 03:19:52 UTC Comment hidden (obsolete)
Comment 14 Robinson Tryon (qubit) 2014-11-12 01:29:02 UTC
(In reply to schlittchen from comment #10)
> The problem is that the font used for input fields (default is Liberation
> Sans) needs to be embedded completely, but isn't. My guess is that the
> algorithm that decides which fonts to embed does not account for form input
> fields correctly.
> 

CONFIRMED with LO 4.4.0.0.alpha2 + Ubuntu 14.04

Tested with attachment 91537 [details].
Exported using the PDF button (stock export behavior)

$ pdffonts
name                                 type              encoding         emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
BAAAAA+LiberationSerif               TrueType          WinAnsi          yes yes yes     11  0
LiberationSans                       TrueType          WinAnsi          no  no  no      13  0

And indeed, LiberationSans was not embedded into the document.
Comment 15 mstrey 2015-01-15 14:16:10 UTC
Any news about this bug? 
It still not embed font used in fields.
Comment 16 Robinson Tryon (qubit) 2015-01-15 16:09:57 UTC
(In reply to schlittchen from comment #1)
> Create a form on Linux, export as PDF, open it using (for example)
> Acrobat Reader on Windows. You get a message about missing fonts
> (LiberationSans
> in my case). The static text shows ok, but the form fields only show
> placeholder chars when filled.

when you say "placeholder chars", what does that entail? Do you mean the same glyphs but in a different font, just rectangles, or?

> 
> This makes the creation of cross-platform PDF-forms effectivly impossible.

Yep, it's important for me to understand the impact of this bug so we can properly triage it. Thanks!
Comment 17 Paolo Melchiorre 2015-02-12 18:39:07 UTC
Confirm bug on Ubuntu GNU/Linux 14.10

Libreoffice
Versione: 4.4.0.3
Build ID: 40m0(Build:3)
Versione locale: it_IT
Comment 18 Ingo Belka 2015-02-17 09:34:03 UTC Comment hidden (obsolete)
Comment 19 Ingo Belka 2015-09-23 05:58:46 UTC
Take a Look on this https://bugs.documentfoundation.org/show_bug.cgi?id=82509#c13
Comment 20 Christian Schlittchen 2015-10-23 11:36:44 UTC
This bug is still there in 5.0.2.2.
Comment 21 Joel Madero 2015-10-23 14:31:30 UTC
Please slow down and read the warnings carefully...when you change the version it very explicitly says version field is the oldest version tested on not the latest. Reverting change.
Comment 22 Peter Nagy 2016-04-07 16:31:06 UTC
This bug is still there in 5.0.5 and 5.1.1.3
Comment 23 Alex Thurgood 2016-11-24 10:09:46 UTC
*** Bug 104114 has been marked as a duplicate of this bug. ***
Comment 24 Joe 2017-07-05 21:08:26 UTC
I am having this same problem on 5.1.6.2 using Ubuntu 16.04.  I create a form in Libre Office, export it to PDF, and when I open it in Windows in Acrobat Reader I receive the message about missing fonts and all of the drop down menus that I created in the form only show dots where they should show words.
Comment 25 Moritz 2017-07-23 13:43:11 UTC
I'm having the same problem on LibreOffice 5.4.0.1 on openSUSE.
Comment 26 Liam Morland 2017-09-14 23:25:03 UTC
I am observing this problem as well in version 5.4.0.3 on Debian.

I would be happy if there was a way to set the form control's font to one of the standard 14 PostScript fonts so that there is no need to embed anything. I just need the form controls to be readable.
Comment 27 Marc R 2017-10-09 18:37:08 UTC
Is this bug being worked on? Having the same issue (create a form in Libre Office, export it to PDF, and when I open it in Acrobat Reader receive the message about missing fonts). Would be great to get a fix!

OSX, LibreOffice 5.4.2.2
Comment 28 kevin.quiggle 2018-03-23 17:29:43 UTC
This bug is still present in Version: 6.0.2.1 (running on Ubuntu Linux 16.04).  As a workaround, I installed the Arial font on my Linux system and used this font for the form fields.

Some additional experiments using Liberation Serif font showed that even when the font is present as an embedded subset it fails to display properly in form fields, even though it properly displays in the rest of the document.
Comment 29 airbuff 2018-05-12 10:13:17 UTC
macOS 10.13.4
Libreoffice 5.2.7.2

The issue shows up here too.

Repro:
- Create writer document
- Add form elements (I use text fields and checkboxes)
- Make sure the form elements use a non standard font that would have to be embedded when exporting as PDF
- Make sure File/Properties/Font embed fonts is checked
- save
- file/export as pdf
- under "General" options, make sure "Create PDF Form" is ticked
- Export

- Open PDF in Acrobat Reader
- Open File/Properties
- check "Font" tab
- find the used font

Expected:
Font is found as we embedded it.

Actual:
"Actual Font: Unknown"

the issue doe *not* show up choosing the "Archive PDF/A-1a..." option in export PDF dialogue. Unfortunately this option does not allow to "Create PDF Form", which is mandatory for us.
Comment 30 QA Administrators 2019-05-13 02:50:14 UTC Comment hidden (obsolete)
Comment 31 Liam Morland 2019-05-19 17:46:54 UTC
The problem still exists on LibreOffice 6.1.5.2 on Debian.
Comment 32 Gabor Kelemen (allotropia) 2019-05-22 12:31:07 UTC
Created attachment 151592 [details]
Screenshot of the example file in Acrobat Reader, Chrome and Edge

Still occurs, I get a warning from Acrobat Reader that the LiberationSans font is missing and some characters won't show up appropriately.
Indeed the form field shows lots of characters as dots.

This is on a machine without any LibreOffice installed. Reinstallation (which includes the missing font) solves this problem.

Interestingly, web browsers can replace missing fonts rather reliably.
Comment 33 Gellért Gyuris 2019-08-07 10:30:20 UTC
Created attachment 153197 [details]
Working example from 2009

This is a regression. 

I have a good exported document from 2009. I made this document with OpenOffice 3.0. See attachments. There are no problem with Adobe Reader, Master PDD Editor, Foxit Reader, Chromium, Evince. Works as expected.

pdffonts "PDF form with OpenOffice 3.0.pdf" 
name                                 type              encoding         emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
BAAAAA+CharisSIL-Bold                TrueType          WinAnsi          yes yes yes    105  0
CAAAAA+Gentium                       TrueType          WinAnsi          yes yes yes     95  0
DAAAAA+Gentium-Italic                TrueType          WinAnsi          yes yes yes    100  0
Helvetica                            Type 1            WinAnsi          no  no  no       5  0
ZapfDingbats                         Type 1            ZapfDingbats     no  no  no      11  0
Comment 34 Gellért Gyuris 2019-08-07 10:30:53 UTC
Created attachment 153198 [details]
Working example from 2009
Comment 35 Gellért Gyuris 2019-08-08 17:11:45 UTC
Workaround... add this script to exported PDF as a top-level document JavaScript:

function updateFields() {
  for ( var fieldNumber = 0; fieldNumber < this.numFields; fieldNumber++) {
    getField(getNthFieldName(fieldNumber)).textFont = font.Helv;
  }
}
updateFields();

Other fonts:
Times-Roman           = font.Times
Times-Bold            = font.TimesB
Times-Italic          = font.TimesI
Times-BoldItalic      = font.TimesBI
Helvetica             = font.Helv
Helvetica-Bold        = font.HelvB
Helvetica-Oblique     = font.HelvI
Helvetica-BoldOblique = font.HelvBI
Courier               = font.Cour
Courier-Bold          = font.CourB
Courier-Oblique       = font.CourI
Courier-BoldOblique   = font.CourBI
Symbol                = font.Symbol
ZapfDingbats          = font.ZapfD
Comment 36 p10 2019-08-28 19:11:01 UTC
(In reply to Gellért Gyuris from comment #35)
> Workaround... add this script to exported PDF as a top-level document
> JavaScript:
> 
> function updateFields() {
>   for ( var fieldNumber = 0; fieldNumber < this.numFields; fieldNumber++) {
>     getField(getNthFieldName(fieldNumber)).textFont = font.Helv;
>   }
> }

Hello,

Where do I put this code ? in LO ? in a new module ?

Thanks.
Comment 37 Gellért Gyuris 2019-09-04 16:34:08 UTC
(In reply to p10 from comment #36)
> 
> Hello,
> 
> Where do I put this code ? in LO ? in a new module ?
> 
> Thanks.

Not in LO. Export document in LO to PDF, and add this small script with a PDF-editor. I used Master PDF Editor (Document>Document Javascript).
Comment 38 NISZ LibreOffice Team 2019-09-23 14:36:08 UTC
*** Bug 127717 has been marked as a duplicate of this bug. ***
Comment 39 Lionel Elie Mamane 2019-09-23 15:11:15 UTC
(In reply to Gellért Gyuris from comment #33)
> Created attachment 153197 [details]
> Working example from 2009
> 
> This is a regression. 
> 
> I have a good exported document from 2009. I made this document with
> OpenOffice 3.0. See attachments. There are no problem with Adobe Reader,
> Master PDD Editor, Foxit Reader, Chromium, Evince. Works as expected.
> 
> pdffonts "PDF form with OpenOffice 3.0.pdf" 
> name                                 type              encoding         emb
> sub uni object ID
> ------------------------------------ ----------------- ---------------- ---
> --- --- ---------
> BAAAAA+CharisSIL-Bold                TrueType          WinAnsi          yes
> yes yes    105  0
> CAAAAA+Gentium                       TrueType          WinAnsi          yes
> yes yes     95  0
> DAAAAA+Gentium-Italic                TrueType          WinAnsi          yes
> yes yes    100  0
> Helvetica                            Type 1            WinAnsi          no 
> no  no       5  0
> ZapfDingbats                         Type 1            ZapfDingbats     no 
> no  no      11  0

I think you have no issue because your Forms in that PDF use "Helvetica", that's one of the 14 standard fonts, and all readers have a copy of this font locally.

So, in my opinion, this does not show this is a regression. If you had a PDF form created with an old version of Libre/OpenOffice with a non-standard font for input fields embedded, then we would have a regression.
Comment 40 Thorsten Behrens (allotropia) 2019-10-03 14:57:10 UTC
I wonder how much of this is a bug, vs. a user experience deficiency.

Technically, LibreOffice _could_ embed the entire font, for those that don't prohibit that in the font flags (N.B. most Windows fonts do _not_ permit that).
The drawback is a significant increase in PDF size, especially for short 1-2 page forms (fonts with good unicode coverage are easily 2-10MB in size).

For fonts where LibreOffice cannot embed more than a subset, several options come to mind:
* leave things as they are, and perhaps issue a warning during export (suggesting users to pick one of the 12 standard PDF fonts)
* try to be smart & embed a subset that matches the language selected at the text at hand
* always fallback to Helvetia (or something) for PDF forms
Comment 41 Christian Schlittchen 2019-10-10 06:58:35 UTC
> For fonts where LibreOffice cannot embed more than a subset, several options
> come to mind:
> * leave things as they are, and perhaps issue a warning during export
> (suggesting users to pick one of the 12 standard PDF fonts)
> * try to be smart & embed a subset that matches the language selected at the
> text at hand
> * always fallback to Helvetia (or something) for PDF forms

I think the best way to handle this is to warn the user during export that he/she is using nonstandard fonts in form fields and give a choice between a) exporting as it is b) use a suggested/chooseable standard font as a replacement or c) embed the full font (only if the font permits it). Pros and cons of each choice should be explained in the online help.
Comment 42 Thorsten Behrens (allotropia) 2019-10-10 08:12:01 UTC Comment hidden (obsolete)
Comment 43 Heiko Tietze 2019-10-10 09:07:24 UTC
(In reply to Thorsten Behrens (CIB) from comment #42)
> Let's get some UX input on the proposal.

Fully agree with Schlittchen's proposal but wouldn't distinguish between full and partial sets (trying to be smart is doomed to fail IMHO). So a simple confirmation box could do the trick:

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.)
Comment 44 Lionel Elie Mamane 2019-10-10 10:03:27 UTC
(In reply to Thorsten Behrens (CIB) from comment #40)
> * always fallback to Helvetia (or something) for PDF forms

Actually, I couldn't figure out how to change my forms fields to Times or Helvetia or something like that. They are not in the list of fonts I can choose from.
Comment 45 Tony Reyelts 2020-03-17 17:17:53 UTC
(In reply to Heiko Tietze from comment #43)
> (In reply to Thorsten Behrens (CIB) from comment #42)
> > Let's get some UX input on the proposal.
> 
> Fully agree with Schlittchen's proposal but wouldn't distinguish between
> full and partial sets (trying to be smart is doomed to fail IMHO). So a
> simple confirmation box could do the trick:
> 
> 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.)

The "Do you want to include?" option would be awesome. I've been fighting the same problem for hours trying to find a workable solution. In my case, neither of the fonts are standard:

$ pdffonts test1*
name                                 type              encoding         emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
BAAAAA+Arial-BoldMT                  TrueType          WinAnsi          yes yes yes     29  0
CAAAAA+TimesNewRomanPS-BoldMT        TrueType          WinAnsi          yes yes yes     24  0
DAAAAA+IBMPlexSans-SemiBold          TrueType          WinAnsi          yes yes yes     34  0
EAAAAA+Free3of9                      TrueType          WinAnsi          yes yes yes     19  0
IBMPlexSans-SemiBold                 TrueType          WinAnsi          no  no  no      38  0
Free3of9                             TrueType          WinAnsi          no  no  no      36  0

The "xAAAAA+*" form comes from adding some fixed text using the problem fonts. But the form fields want to refer to the unembedded form of the same font. Note: I really don't want the fixed text. This is just to show the fonts can be embedded... just the form fields won't use them (or they won't be embedded under the name the form fields want... I'd be ok with either one).
Comment 46 Tony Reyelts 2020-03-17 17:18:25 UTC Comment hidden (obsolete)
Comment 47 Robert Großkopf 2020-05-31 13:42:40 UTC
Created attachment 161459 [details]
Oringinal with one form-control
Comment 48 Robert Großkopf 2020-05-31 13:54:53 UTC
Created attachment 161460 [details]
Exported form - font of control wasn't exported

I tried the same error while sending much forms to pupils last months. The default font of form-controls will never been exported. It is "Noto Sans" on my systems - and if someone asks: Where have you added this font: It's the default LO will create since I test all these things with databases - so a long time.

It doesn't work with PDF/A-2b or PDF/A-1b.

So only possibility to get this working was to change all the default fonts in the form-controls to a default font all this Windows and AcrobatReader users have already installed.
Comment 49 Lionel Elie Mamane 2020-05-31 13:58:56 UTC
(In reply to Robert Großkopf from comment #48)
> So only possibility to get this working was to change all the default fonts
> in the form-controls to a default font all this Windows and AcrobatReader
> users have already installed.

How did you do that? What font can I select from my GNU/Linux system that Windows / Acrobat Reader users will already have? Ideally, I would like to use one of the 14 "standard" fonts (Times, Helvetica, ...), but GNU/Linux systems usually don't have them, they have "compatible" ones with different names, so it doesn't work :-(
Comment 50 lemba 2020-06-01 17:09:42 UTC
Strange thing is: It works with OpenOffice, without any interaction...
Comment 51 NISZ LibreOffice Team 2020-06-02 07:21:44 UTC
*** Bug 133431 has been marked as a duplicate of this bug. ***
Comment 52 Heiko Tietze 2020-06-02 12:32:10 UTC
UX input in c43, removing keyword
Comment 53 Commit Notification 2020-07-20 10:55:33 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/6294ecd7b4da38de98b24ddfb9f201cef98c1f41

tdf#50879 PDF export: ensure only built-in fonts are used for forms

It will be available in 7.1.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 54 Miklos Vajna 2020-07-20 13:01:37 UTC
(In reply to Robert Großkopf from comment #48)
> So only possibility to get this working was to change all the default fonts
> in the form-controls to a default font all this Windows and AcrobatReader
> users have already installed.

I think this is now fixed on master.
Comment 55 Robert Großkopf 2020-12-15 16:47:50 UTC
Have tested this one again with LO 7.1.0.0 beta 1. The buggy behavior hasn't gone. So I reopened this bug.
Comment 56 Miklos Vajna 2020-12-22 08:25:28 UTC
Can you provide more details? Steps to reproduce the problem you see and what is the actual & expected result? The above commit makes sure that forms never refer to fonts which are not one of the standard ones. If you want to embed full custom fonts, please close this bug again and file a follow-up bug for that.
Comment 57 Brenton Chapin 2021-03-12 00:47:05 UTC Comment hidden (off-topic)
Comment 58 Brenton Chapin 2021-03-12 00:48:40 UTC Comment hidden (off-topic)
Comment 59 Timur 2021-04-14 13:44:51 UTC Comment hidden (off-topic)
Comment 60 Timur 2021-04-14 14:10:43 UTC
Could someone explain this bug? 
I created form with Cantarell font 16 (which I have in Linux and not in Windows, examples with Liberation are not good because it's available in Windows where LO is installed.) 
Upon export, used font is Helvetica or Arial, is it on purpose? Font size is not 16.
So it's not as created but is usable.
Comment 61 Miklos Vajna 2021-04-14 15:24:35 UTC
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. I suggest to close this bug again, the testcase shows that this is working in general and the reporter didn't answer to needinfo since Dec.
Comment 62 Paolo Melchiorre 2021-04-14 16:41:31 UTC
> I created form with Cantarell font 16 ... Upon export, used font is Helvetica or Arial, is it on purpose? Font size is not 16. So it's not as created but is usable.

> 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.

The solution you suggested is only a workaround and not a fix of this specific bug because the final PDF is usable but is not like the original creator intended.

The solution you suggested is only a workaround and not a fix for this specific bug because the final PDF is usable but it is not as intended by the original creator, who obviously wants the font used in the form to be the one he decided and not an alternative generic font. 

A fix of this bug for me is instead to embed used fonts (and NOT only a subset) in the generated PDF when a form is present.

A real fix for this bug for me is to embed all fully used characters, and NOT just a subset, in the generated PDF when there is a fillable form in the original document.
Comment 63 Paolo Melchiorre 2021-04-14 16:43:26 UTC
Sorry for the duplicated sentences, I can't find a way to edit my latest comments.
Comment 64 Timur 2021-04-14 17:03:58 UTC
So, form is usable, but we may keep this open with normal priority for fix  per comment 43.
Comment 65 Timur 2021-04-15 06:24:58 UTC
I have a proposal for this bug: to redirect issue to exporting size and style (bold, italic), because it doesn't now so form may look very different from designed. (so fonts wouldn't be exported). 
And that font embedding is done in bug 137421 via PDF-A.
Comment 66 Timur 2021-04-15 08:41:13 UTC
*** Bug 118541 has been marked as a duplicate of this bug. ***
Comment 67 Timur 2021-04-15 09:08:39 UTC
*** Bug 135416 has been marked as a duplicate of this bug. ***
Comment 68 Timur 2021-04-21 13:22:57 UTC
*** Bug 108222 has been marked as a duplicate of this bug. ***
Comment 69 Timur 2021-08-19 14:21:58 UTC
*** Bug 143937 has been marked as a duplicate of this bug. ***
Comment 70 Miklos Vajna 2021-10-21 14:31:14 UTC
Discussed in today's ESC call: the original problem was that special characters may be missing when filling in PDF forms: restricting the font to builtin names fixes that problem.

If you still want to embed a full custom font (all glyphs) for fill form purposes, please file a separate bug for that. Thanks!
Comment 71 Daniel James 2021-10-21 16:31:05 UTC
(In reply to Miklos Vajna from comment #70)
> Discussed in today's ESC call: the original problem was that special
> characters may be missing when filling in PDF forms: restricting the font to
> builtin names fixes that problem.
> 
> If you still want to embed a full custom font (all glyphs) for fill form
> purposes, please file a separate bug for that. Thanks!

Hi Mikos, I'm not sure you're correct that this bug is only about special characters. The bug I found was the same as in comment 1 by Christian Schlittchen dated 2012-06-08. 

PDF forms created in LibreOffice don't work cross-platform, apparently because the 'standard' Type 1 fonts originally selected by Adobe in the PDF specification are no longer supported in LibreOffice. Substitute form fonts are not embedded in the form fields, causing a 'missing fonts' error. Placeholder characters are shown instead, particularly in Adobe Reader.
Comment 72 Lionel Elie Mamane 2021-10-21 16:37:20 UTC
(In reply to Daniel James from comment #71)
> Hi Mikos, I'm not sure you're correct that this bug is only about special
> characters.

Indeed, it was about *all* characters, not only "special" ones.

> The bug I found was the same as in comment 1 by Christian
> Schlittchen dated 2012-06-08. 

You found it in versions 6.1.5 and 6.4.5. This bug is fixed in 7.1.0 only.

> PDF forms created in LibreOffice don't work cross-platform, apparently
> because the 'standard' Type 1 fonts originally selected by Adobe in the PDF
> specification are no longer supported in LibreOffice.

Please try again with LibreOffice 7.1.0 or later. There, the form fonts are forced to be one of the standard Type 1 fonts on PDF export.
Comment 73 Daniel James 2021-11-01 17:03:08 UTC
Thanks Lionel, I can confirm that LibreOffice 7.2.2 on Debian 10.11 'buster' makes PDF forms that can be filled and printed in Adobe Reader 9 even when the Type 1 Helvetica font is not installed locally. In my test case it was substituted by Arial.
Comment 74 Timur 2021-11-02 08:24:48 UTC
If this big is closed, another one or two should be opened for fix per comment 43 and problems in comment 65.
Comment 75 Xisco Faulí 2021-11-03 11:15:20 UTC Comment hidden (no-value)
Comment 76 Ralf Hauser 2021-12-18 10:46:48 UTC
see also Bug 146293