Hi,

The build has an example CreateSimpleForm.java and I changed that one to include "AéB" and it was displayed. Please try with that example and find out how your own code differs.

Tilman


Am 13.11.2021 um 09:46 schrieb Maison Mo:
Hello,
I encounter a strange problem when filling an acroform text field : some chars 
are missingin generated appearance.

The field uses the Helvetica standard font, without any defined encoding :7 0 
obj
<< /BaseFont /Helvetica /Name /Helv /Subtype /Type1 /Type /Font >>
The field is filled by calling method PDTextField.setValue("AéB")
After PDDocument is saved (without flattening) I see that the value is correct 
in field value :
<< /AP << /N 15 0 R >> /DA (/Helv 10 Tf 0 g)  /T (lieu_signature) /Type /Annot /V 
<41e942> ... >>
but incorrect in field appearance :15 0 obj
<< /Resources << /Font << /Helv 7 0 R >> >> /Subtype /Form /Type /XObject /Length 108 
... >>
stream
/Tx BMC
[...]
BT
/Helv 10 Tf
/DeviceGray cs
0 sc
2 3.5383 Td
<41FF42> Tj  <--- E9 has been replaced by FF ?!
ET

Tried to debug this using pdfbox-2.0.24 :

In debugger I see that a PDType1Font is created this way :
else if (encodingBase == null)
{
     this.encoding = readEncodingFromFont();
and as it is a std14 font, I get here (PDType1Font L509) :
// read from AFM
return new Type1Encoding(getStandard14AFM());
So this font is : Helvetica with encoding: built-in (Type 1)
I guess that for this standard font, builtin encoding actually is 
"StandardEncoding" as defined in annex D of PDF32000 ?

 From here, when generating the appearance stream, we pass in method :  byte[] 
PDType1Font encode(int unicode)which has a special path for std14 fonts :if 
(isStandard14())
{
     // genericFont not needed, thus simplified code
     // this is important on systems with no installed fonts
     if (!encoding.contains(name))
Here we have name="eacute" and indeed encoding contains the eacute glyph name 
in 'inverted' map
(inverted map contains 315 glyphs, whereas the codeToName map only has 150 ; because many 
glyphs are mapped to code -1 in AFM file)However int code = inverted.get(name) = 
inverted.get("eacute") return -1.Hence the FF in appearance stream.
Ok, eacute is not present in font encoding, but I would rather expect an 
exceptionlike the ones thrown in other paths :    U+%04X ('%s') is not 
available in this font %s encoding: %s

BTW, do you consider a good practice to not define any font encoding when 
defining a font ?

Thank you in advance for your help.
   M.






---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: users-h...@pdfbox.apache.org

Reply via email to