Issue 42985 - Fonts not included for "PDF Form fields"
Summary: Fonts not included for "PDF Form fields"
Alias: None
Product: gsl
Classification: Code
Component: code (show other issues)
Version: 680m77
Hardware: PC Windows XP
: P3 Trivial with 10 votes (vote)
Target Milestone: OOo 3.3
Assignee: h.ilter
QA Contact: issues@gsl
: 44905 104881 (view as issue list)
Depends on: 108743
  Show dependency tree
Reported: 2005-02-17 11:35 UTC by edas
Modified: 2017-05-20 10:24 UTC (History)
5 users (show)

See Also:
Latest Confirmation in: ---
Developer Difficulty: ---

PDF without font for input fields (3.03 KB, application/pdf)
2005-02-17 11:37 UTC, edas
no flags Details
Document for generating PDF (6.89 KB, application/vnd.oasis.opendocument.text)
2005-02-17 11:38 UTC, edas
no flags Details
Problematic PDF (3.03 KB, application/pdf)
2005-02-17 12:46 UTC, edas
no flags Details
Problematic document (7.01 KB, application/vnd.oasis.opendocument.text)
2005-02-17 12:46 UTC, edas
no flags Details
Didn't set fonts in DocLevel because acrobat embeds font automatically when font was used :( (8.32 KB, application/pdf)
2005-02-17 15:31 UTC, edas
no flags Details
the sample UI described before (25.44 KB, image/jpeg)
2005-12-06 16:40 UTC, linuxsmiley
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description edas 2005-02-17 11:35:57 UTC
When exporting PDF from writer documents fonts for forms are not included, and
forms are filled with dots instead of Non ASCII characters. 
The problem occurs because PDF Export module does not specifies font from forms
properties and uses default font (Helvetica) instead. As you know, Helvetica
(shipped with Reader) does not contain characters for non ASCII alphabet.
Attached 2 documents.
Comment 1 edas 2005-02-17 11:37:29 UTC
Created attachment 22736 [details]
PDF without font for input fields
Comment 2 edas 2005-02-17 11:38:27 UTC
Created attachment 22737 [details]
Document for generating PDF
Comment 3 philipp.lohmann 2005-02-17 11:49:40 UTC
That is intentional. If we wanted to supply a font we'd have to use one
containing every Unicode point since we do not know which characters the user
may enter. Think e.g. chinese  which would use something like an 8 MB font.
Sadly PDF does not allow for fallbacks being used in case a font does not
contain a needed character. So we settled for one of the standard fonts which
can at least display all Iso8859-1 characters (not Ascii as you mentioned).

Currently there is no good solution for this problem.
Comment 4 philipp.lohmann 2005-02-17 11:50:08 UTC
Comment 5 edas 2005-02-17 11:58:37 UTC
But you can let the user to specify which script (codepage) can be used for
forms input (in forms properties). That is Acrobat's way for form design.
Another way -- let Acrobat use system fonts for form fields (don't explicitly
declare, that form must use Helvetica).
Comment 6 philipp.lohmann 2005-02-17 12:19:55 UTC
A system font has the disadvantage that you will get nothing at all if the
system does not actually have the font - which looses a major feature of PDF:
portability. If not for that this would have been my choice since the font is of
course an attribute of a form control in OOo's documents which i'd like to
export also.

The codepage solution would also work, but we'd need new UI (for the user to
select the code page) and code that can embed font subsets with more than 256
characters (a current limitation of our code). This necessary rework means we
cannot go this way in the 2.0 timeframe since we simply do not have the
resources for this at the moment.
Comment 7 edas 2005-02-17 12:20:21 UTC
And another problem. Font's size is not specified. Size always defaults to 8pt.
Comment 8 philipp.lohmann 2005-02-17 12:22:14 UTC
setting mmp on CC: what's your opinion should we use Helvetica in PDF form
controls which is supported everywhere at least in Ansi1252 or should we rely on
system fonts, that could support all desired characters, but would fail entirely
on systems not haviong the font ?

The change to using a system font would be possible in 2.0 timeframe, IMHO
Comment 9 philipp.lohmann 2005-02-17 12:29:47 UTC
edas: you  can specify the font size by setting the font property of the control
in OOo; the font's size is exported to the PDF file, whereas it's family name is
changed to Helvetica.
Comment 10 edas 2005-02-17 12:44:05 UTC
In my case font sizes always defaults to 8pt.
Attached 2 documents.
Comment 11 edas 2005-02-17 12:46:21 UTC
Created attachment 22742 [details]
Problematic PDF
Comment 12 edas 2005-02-17 12:46:54 UTC
Created attachment 22743 [details]
Problematic document
Comment 13 mantas 2005-02-17 13:29:52 UTC
I think PDF export should work in WYSIWYG manier - if a user chooses some e.g.
Times font, then Times should be in PDF, if user chooses Helvetica - then
Helvetica. If one font property - font's size is exported to the PDF file, then
why another font property - family name is always changed to Helvetica ?

If it's not possible to get this simple solution into 2.0, then we should use
any other solution, which works with the majority of international characters,
e.g. Lithuanian or Russian, not only iso8859-1.
At least we can make a checkbox "use system font for form fields" in "Export to
PDF" dialog window.
On the other case there would be problems when pushing to public
sector, e.g. there is a Project on Open Standards in Local Authorities in
Lithuania and Latvia (see ) and
we plan to suggest to install at least one copy of OOo in every governmental and
public institution in order to publish the information in open formats (e. g.
PDF, because majority of users can read PDF and fill PDF forms without buying
any software).
Currently most documents in Lithuanian governmental institutions are published
in MS Office formats partly because it is necessary to buy aditional expensive
software for publishing in wide spread open format - PDF and PDF forms.
OOo 2.0 could replace expensive Adobe Acrobat for generating PDF forms but only
if there would be an ability to enter Lithuanian characters
(iso8859-13/Windows-1257 encoding).
Comment 14 edas 2005-02-17 13:54:01 UTC
pl: maybe there is possibility to specify fonts with alternative substitutions?
Like in CSS (font-family:arial,sans-serif)
Figured out, that bigger problem is with Adobe, which doesn't supply Unicode
substitution fonts with Reader (even with CE and ME ones). Going to file bug to
Winsoft (Adobe localization partner).
Comment 15 edas 2005-02-17 15:06:22 UTC
To pl: found solution. We can use "Document Level" javascripts to check for
fonts availability on users system and use font substitutions for each form field.
Since I'm not a programmer -- all coding I left for you :)
Algorythm: "Check for available fonts on current system"> Declare variable for
available font> use available Unicode font for form fields.

Document level javascripts:
this.getField("FieldName").textFont = "On users system found Unicode Font name";
this.getField("FieldName").textSize = 10;

And some enhancements for field browsing:
Document level javascripts:

function OnFieldFocus()
var txtField =;
txtField.borderStyle = border.i;
txtField.linewidth = 2;

function OnFieldBlur()
var txtField =;
txtField.borderStyle = border.s;
txtField.linewidth = 0;
txtField.strokeColor = color.transparent;

Form fields javascripts:
On Focus > OnFieldFocus()
On Blur > OnFieldBlur()

Everything works since Acrobat 5.0, font embedding not required
That's all
Comment 16 philipp.lohmann 2005-02-17 15:25:25 UTC
This leaves out the important detail of how a JavaScript would be able to find
out a unicode font - which it isn't AFAIK.
Comment 17 edas 2005-02-17 15:31:32 UTC
Created attachment 22747 [details]
Didn't set fonts in DocLevel because acrobat embeds font automatically when font was used :(
Comment 18 philipp.lohmann 2005-02-17 15:46:04 UTC
"There was an error processing a link or annotation"

besides i see only the "glyph not available" in the two edit boxes.
Comment 19 edas 2005-02-17 15:49:41 UTC
pl: not so important, because acrobat versions, which can fill in forms with non
ASCII characters (known as "Reader CE" and "Reader ME") are only supported on
Win and MAC. I can list you font names which support ME (middle eastern) and CE
(central european) characters on windows platform: Arial, Tahoma, Georgia, etc.
Not so difficult to find fonts on users system and compare there names with
known list. 
Anyway, that would be better than nothing.

> besides i see only the "glyph not available" in the two edit boxes.
Does your system has "Arial" font installed? Are you using CE version of reader?
Comment 20 philipp.lohmann 2005-02-17 15:58:34 UTC
No and no; i'm using acrobat reader 5.05 on Linux. Which seems to be a good
example why we went for Helvetica in the first place :-) .
Comment 21 mantas 2005-03-04 15:10:58 UTC
On Thu Feb 17 07:49:41 -0800 2005, edas wrote:
> [..] because acrobat versions, which can fill in forms with non
ASCII characters (known as "Reader CE" and "Reader ME") are only supported on
Win and MAC.

Edas, you are not right, Adobe Reader 7.0 can fill in forms with non ASCII
characters and there is 7.0 beta version on Linux already.

I've downloaded AdbeRdr70_linux_enu.0.beta1.tar.bz2 from and tested with your
attached PDF forms on Debian GNU/Linux 3.1 (Sarge).

It seems I can write (and see) all lithuanian and russian symbols in
Bug_In_PDF_Export.pdf and Bug_In_PDF_Export_With_font_sizes.pdf except ccaron
and zcaron(these both have identifical size, I think differences are just in
file name).
When I open Runaround_for_Bug_In_PDF_Export_.pdf then I see only dots in text
fields instead of characters, but when I place cursor on text boxes then all
characters except ccaron and zcaron are displayed correctly.

I don't know where is the bug - in or in Adobe Reader 7.0 Linux
beta, could someone test these PDF files with stable version of Adobe Reader 7.0
on windows ?

Next week I'll try to write zcaron and ccaron in other PDF forms, created with
Scribus, maybe results will be different to PDF forms, produced with 1.9 ?
Comment 22 lohmaier 2005-06-08 19:22:16 UTC
*** Issue 44905 has been marked as a duplicate of this issue. ***
Comment 23 linuxsmiley 2005-12-06 07:19:41 UTC
An idea:

On exporting the PDF check if the entered font-family is a valid PDF one (e.g. 
Helvetica). If it's not: display a window in which the user can specify a 
substitute for each non-compliant font. I put up a sample on how this window 
might look like and will attach it if requested.

Maybe one should allow an empty substitute which has the effect (after an 
warning) that the font family isn't changed at all (in order to use a Unicode 
font for example). I think it's good to let the user decide while the default 
should be to substitute the fonts.

What do you think?
Comment 24 philipp.lohmann 2005-12-06 11:45:22 UTC
I think this is a good idea. Please attach the sample UI.
Comment 25 linuxsmiley 2005-12-06 16:40:50 UTC
Created attachment 32135 [details]
the sample UI described before
Comment 26 philipp.lohmann 2009-09-08 10:26:27 UTC
*** Issue 104881 has been marked as a duplicate of this issue. ***
Comment 27 stefankalte 2009-09-08 10:40:44 UTC
an suggestion,
as the problem exist long long time,
why making the same error as making just bevore, while trying to resolving the
compatibility problem with ms-office (doc, ...), here the problem is the same,
trying to resolve the compatibility to adobe (pdf).
as openoffice will be stronger every day, why not making a own open standard for
archiving documents and a kind of "pdf".
Comment 28 philipp.lohmann 2009-09-08 10:55:36 UTC
I'm not sure if I understood you right, but you seem to suggest we create an own
document format. Incidentally we have, it's called Open Document Format, please
find the specification here
Comment 29 philipp.lohmann 2009-09-09 10:39:37 UTC
Hopefully it will be possible to rely on system fonts here (as an option and not
in the PDF/A case)
Comment 30 stefankalte 2009-09-09 11:25:11 UTC
odf is the basic, but the rest can be develope, like pdf, fast, not 
modificable, easy to use and filling out forms, but all in opensource without 
adobe :)
Comment 31 norbert2 2009-09-09 11:39:23 UTC

Sorry, but your suggestion is nonsense.
Comment 32 stefankalte 2009-09-09 15:46:35 UTC
thanks, probably the nonsens make adobe leader of his products and everybody
depends from the "monopolist"

by the way something other, using the font and changing it pdf in the form field
then it display an error that CAAAAA+font will not found. searching i found this
font in the tag-elements. the font CAAAAA+Verdana in my case and in the base
font BAAAAA+Veranda Bold. as this fonts don't exist then adobe take the
helvetica when it converts it in pdf
Comment 33 philipp.lohmann 2009-10-28 18:36:41 UTC
To improve the situation at least a little, I built in that system fonts get
used for form fields; you can still use the base fonts (which I'd recommend) by
setting the font explicitly to "Times", "Helvetica" or "Courier". This does not
solve the encoding problem however; the system fonts will still use
WinAnsiEncoding (aka ansi1252 or iso8859-1). I'm still not sure how to tackle
that problem; sadly it seems one has to create the PDF file containing specific
advance widths for each encoded character.

Using system fonts for fields is checked in CWS vcl107
Comment 34 philipp.lohmann 2009-11-13 11:24:42 UTC
please verify in CWS vcl107
Comment 35 h.ilter 2009-12-03 09:51:57 UTC
Verified with cws vcl107 = ok