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.

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.

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.

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"

Created attachment 91537 [details]
test document

Created attachment 91538 [details]
pdf exported from test.odt

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

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

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.

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

Any news about this bug? 
It still not embed font used in fields.

(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!

Confirm bug on Ubuntu GNU/Linux 14.10

Libreoffice
Versione: 4.4.0.3
Build ID: 40m0(Build:3)
Versione locale: it_IT

Take a Look on this https://bugs.documentfoundation.org/show_bug.cgi?id=82509#c13

This bug is still there in 5.0.2.2.

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.

This bug is still there in 5.0.5 and 5.1.1.3

*** Bug 104114 has been marked as a duplicate of this bug. ***

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.

I'm having the same problem on LibreOffice 5.4.0.1 on openSUSE.

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.

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

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.

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.

The problem still exists on LibreOffice 6.1.5.2 on Debian.

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.

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

Created attachment 153198 [details]
Working example from 2009

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

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

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

*** Bug 127717 has been marked as a duplicate of this bug. ***

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

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

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

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

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

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

Created attachment 161459 [details]
Oringinal with one form-control

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.

(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 :-(

Strange thing is: It works with OpenOffice, without any interaction...

*** Bug 133431 has been marked as a duplicate of this bug. ***

UX input in c43, removing keyword

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.

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

Have tested this one again with LO 7.1.0.0 beta 1. The buggy behavior hasn't gone. So I reopened this bug.

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.

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.

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.

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

Sorry for the duplicated sentences, I can't find a way to edit my latest comments.

So, form is usable, but we may keep this open with normal priority for fix  per comment 43.

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.

*** Bug 118541 has been marked as a duplicate of this bug. ***

*** Bug 135416 has been marked as a duplicate of this bug. ***

*** Bug 108222 has been marked as a duplicate of this bug. ***

*** Bug 143937 has been marked as a duplicate of this bug. ***

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!

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

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

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.

If this big is closed, another one or two should be opened for fix per comment 43 and problems in comment 65.

see also Bug 146293