[Tex/LaTex] eforms using a LaTeX (custom) font for text fields \textFont

dvipsfontsformspdf

I'm unable to use a LaTeX font (e.g., Augie) for text fields in a PDF form generated with eforms. I'm using MikTeX 2.9 on Windows 10. Acrobat Reader is choosing another font to display in its place (looks like MyriadPro-Regular, which seems to be what Adobe Reader substitutes for missing fonts):

The LaTeX font is fully embedded as "Augie" according to Adobe Reader's Properties:

Also, according to pdffonts:

pdffonts embedViaPS.pdf
name                                 type              encoding         emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
[none]                               Type 3            Custom           yes no  no      27  0
Augie                                Type 1C           WinAnsi          yes no  no      24  0
ZapfDingbats                         Type 1C           Custom           yes no  yes     13  0
Helvetica                            Type 1C           WinAnsi          yes no  no      17  0

It's my understanding that for a font to be used in a field, it must be fully embedded (as opposed to an embedded subset). I am achieving this using -j0 on dvips and a customized ps2pdf by way of GhostScript. Here's the (redacted) output from TeXstudio showing all the commands:

latex.exe -src -interaction=nonstopmode embedViaPS.tex

dvips.exe -j0 -o embedViaPS.ps embedViaPS.dvi

This is dvips(k) 5.998 Copyright 2018 Radical Eye Software (www.radicaleye.com)

' TeX output 2018.08.31:1642' -> embedViaPS.ps
<C:\MikTeXPortable\texmfs/data\fonts\pk\ljfour\jknappen\ec\dpi600\ecrm1000.pk>    
<C:/MikTeXPortable/texmfs/install/dvips/base/tex.pro>    
<C:/MikTeXPortable/texmfs/install/fonts/enc/dvips/base/8r.enc>
<C:/MikTeXPortable/texmfs/install/dvips/base/texps.pro> 
<C:/MikTeXPortable/texmfs/install/dvips/base/special.pro>. 
<C:/MikTeXPortable/texmfs/install/fonts/type1/emerald/faumw.pfb>

[1]
Process exited normally

"C:\Program Files\gs\gs9.10\bin\gswin64c.exe" -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -dPDFSETTINGS=/prepress -dEmbedAllFonts=true -dSubsetFonts=false -sOutputFile="C:\hiddenpath\embedViaPS.pdf" -f "C:\hiddenpath\embedViaPS.ps"

Process exited normally    

Process started: "C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe" "C:\hiddenpath\embedViaPS.pdf"

Process exited normally

I've done some debugging using the MWE below:

\documentclass{article}
\usepackage[dvips]{eforms}
\usepackage{emerald}
\usepackage[T1]{fontenc}
\begin{document}
\everyTextField{
    \BC{1 0 0} % border color
    \BG{.941 1 .941} % background color
    \textColor{0 0 1} % is black
    \AA{\AAFormat{console.println("Font set to: '" + event.target.textFont + "', trying to set it to: '" + event.target.value + "'"); event.target.textFont = event.target.value;}}
    \textSize{10}
    \Ff{\FfDoNotScroll}
}


% Content containing form fields, such as...
{\ECFAugie
Your name: }
\textField[\textFont{Augie}]{name}{1.5in}{12bp}
\end{document}

Upon opening in Adobe Reader DC the PDF generated from this document, I see in the JavaScript console (enabled in Preferences) the following output:

Font set to: 'Augie', trying to set it to: ''

I'm using Augie as the name, since that is what's showing up in pdffonts and the properties of Adobe Reader. However, even though I have initialized the \textField with that font (from the output), it's not displaying that font in Adobe Reader DC. Furthermore, if I try to reset it to Augie using the form field (typing Augie and pressing enter), I get the following:

Font set to: 'Augie', trying to set it to: 'Augie'

InvalidSetError: Set not possible, invalid or unknown.
Field.textFont:2:Field name:Format

The script allows me to type a font name into the field and when I press enter, it attempts to set the font of that field using JavaScript. I'm able to set the field to other values, e.g., Helv, Helvetica, Another, Bauhaus93, etc. (the last two are installed on my Windows machine as TrueType fonts).

I don't want (or rather can't) use XeTeX as it seems there's no way to fully embed fonts into the PDF.

Is there perhaps another name for the font than Augie?
Is there perhaps some other detail for the font that's not right, e.g. it's not editable according to its fsType/FSType? ~~Can I even control that in LaTeX?~~ Edit As a test, I hacked the Augie font (faumw.pfb) using FontForge and set its fsType to 8 – editable embedding, but nothing changed.
I have not yet tried to install a TrueType (OpenType) font in MikTeX because it's a long process, but perhaps that will yield a better result?

Best Answer

In theory, acc. to the PDF specification, any embedded document font can also be used in interactive PDF forms, such as text input fields. For this to work, the font must be properly registered in the /AcroForm dictionary of the document's PDF Catalog.

Here is a LaTeX example, using the standard CM Font (PostScript Type 1) in various combinations of style, size and colour:

Evince

Also, Foxit Reader properly displays the font.

Alas,

Acrobat Reader

fails to display the embedded T1 font, which is a bug, most likely. It seems that AR digests only TrueType fonts correctly.

In order to produce the PDF shown, the standard packages for creating PDF Forms, hyperref and eforms, cannot be used as they fail to register the embedded fonts for use in forms. Instead, we re-implement a \textField command based on the file pdfbase.sty. It provides \pbs_add_form_font: which maps the current text font object as a font resource in the /AcroForm dictionary. In order to get access to the font object, \pbs_add_form_font: makes use of the pdftex built-in \pdffontobjnum. The example below can therefore be processed only with pdflatex or lualatex.

\documentclass{article}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Text Input Field
% \textField{<name>}{<width>}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\usepackage{pdfbase,xcolor}
\makeatletter
\ExplSyntaxOn
  \newcommand{\textField}[2]{
    % register current font in /AcroForm <<...>> PDF dictionary
    \pbs_add_form_font:
    % get current text colour
    \extractcolorspec{.}\@tempb
    \expandafter\convertcolorspec\@tempb{rgb}\@tempb
    \edef\@tempa{\expandafter\@rgbcomp\@tempb\@nil}
    % insert Text Field
    \raisebox{0.4\depth}{\makebox[#2][l]{
      \pbs_pdfannot:nnnn{#2}{\ht\strutbox}{\dp\strutbox}{
        /Subtype/Widget/FT/Tx/T (#1)
        % set font, size, current colour
        /DA (\pbs_last_form_font:\space\f@size\space Tf~\@tempa\space rg)
        /MK<</BC [0~0~0]/BG [0.9~0.9~0.9]>>
      }\strut
    }}
    % register Text Field in /AcroForm
    \pbs_appendtofields:n{\pbs_pdflastann:}
  }
\ExplSyntaxOff
\def\@rgbcomp#1,#2,#3\@nil{#1 #2 #3} %helper
\makeatother  

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% set of characters of the current font to be embedded
\usepackage{luatex85}
\newcommand{\embedChars}[1]{\pdfincludechars\font{#1}}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\parindent=0pt

\begin{document}
%\normalfont%
\embedChars{ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789- /}%
First Name: \textField{myFName1}{0.4\linewidth}\\
Last Name: \textField{myLName1}{0.4\linewidth}\\
Date of Birth: \textField{myBDate1}{0.2\linewidth}\\

\scshape\Large\color{red}%
\embedChars{ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789- /}%
First Name: \textField{myFName2}{0.4\linewidth}\\
Last Name: \textField{myLName2}{0.4\linewidth}\\
Date of Birth: \textField{myBDate2}{0.3\linewidth}\\

\huge\itshape\color{blue}%
\embedChars{ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789- /}%
First Name: \textField{myFName3}{0.4\linewidth}\\
Last Name: \textField{myLName3}{0.4\linewidth}\\
Date of Birth: \textField{myBDate3}{0.6\linewidth}\\

\end{document}

1.

'I would like to know what the "random" letters before the font name in the table means (e.g. on line one we have PEUMGT).'

These letters are a prefix to the original fontname and they indicate that the font was embedded, but NOT as the full set of glyphs available for this font, but only as a subset. According to the PDF spec, the fontname prefix should indeed be random and unique when compared to other subset fontnames using the same full font.

2.

'I would like to learn how to interpret the font output table better. In the last second to last column, we have in the final row the number 592. What does this mean?'

As Herbert already said, PDF files contain objects which are numbered (and have a "generation" sub-number, which in most cases is 0). If you want to look up the exact PDF code for the object 592 generation 0, you should search for the section in the PDF starting with the line 592 0 obj, ending with the line endobj. Everything in between defines this object. However, some other objects may be referenced: if you find strings saying 691 0 R you know to look for object 691, generation 0 now in the same way as you looked for object 592 initially.
And if you want to know at which and at how many places in the PDF your 592 object is used, search for all occurences of 592 0 R...

Update:

3.

What does the values in the uni column mean? (Actually, not asked by the OP, but added by myself because it fits the context... :)

Values in the uni column indicate whether the font in question is accompanied by a /ToUnicode table (a separate object in the PDF, if present). This table provides a reverse mapping from "character codes" to unicode characters or code points.
Without a correct and valid /ToUnicode table, any text extraction will most likely fail for Custom-encoded fonts and result in unreadable garbage:
- pdftotext will not work as expected;
- screen readers will not be able to read PDF contents aloud to users who may need it;
- copy'n'paste will not work as expected.
You can test this by opening any PDF in a text editor. If you find the string /ToUnicode inside, change it to /toUnicode. (That change in capitalization will make the case sensitive keyword no longer be found.) After that, your PDF will still display identically, but text extraction will no longer work (for these fonts which the disabled /ToUnicode tables where serving).

[You may now ask: how is the text then still displayed correctly inside the viewer? The reason is that the forward mapping of the (Unicode) characters or code points (to glyph shapes to be drawn for them) is using a different mechanism... see point 4.]

4.

Newer versions of pdffonts display an additional column, encoding. It looks like this:

name                       type       encoding         emb sub uni object ID
-------------------------- ---------- ---------------- --- --- --- ---------
UBYABV+CMR10               Type 1C    Builtin          yes yes no       8  0

What do the values in the encoding column mean? (Question also added by me :)

The 'encoding' of a font represents actually the mentioned forward mapping (see point 3) from a "character code" to the glyph ID inside the font so that the PDF renderer knows how to draw a particular glyph representing the char code. (Note, that the technical term "char code" in this context is not the same as "letter" or "character". The "char code" for expressing the letter "a" in a PDF text object may be "z", or anything else.)
There are various mechanisms for font encodings:
- Base encodings (for Type 1 fonts): amongst these are StandardEncoding, WinAnsiEncoding and MacRomanEncoding. These are well-known to the PDF reader and need not to be embedded in the PDF.
- Custom encodings (for Type 1 fonts): these are based a named base encoding, but modified by adding a /Differences array to the final font encoding.
- Identity-H, Identity-V encodings: standard encodings for CID font types (fonts with many more than the max. 256 different glyphs which a Type 1 font can contain).
- Builtin encodings: a built-in encoding is what every font program (except Type 3 fonts) must include.
So why do PDFs not always use the 'builtin' encodings? Because they do not always embed the full font program. Sometimes they embed only that subset of glyphs which actually occur in the PDF document.

[Tex/LaTex] How to avoid Type3 fonts when submitting to ManuscriptCentral

I had the same problem. I replaced a \mathbbm{1} command I had with \mathds{1} and the issue has been resolved: no Type 3 Font Error in Manuscript Central.

Best Answer

Evince

Acrobat Reader

Related Solutions

[Tex/LaTex] Using and interpreting pdffonts

1.

2.

3.

4.

[Tex/LaTex] How to avoid Type3 fonts when submitting to ManuscriptCentral

Related Question