Please look at this issue for me,thank you very much!
zhanglij...@myhexin.com From: Tilman Hausherr Date: 2021-11-14 13:15 To: users Subject: Re: Text field filling silently fails Am 13.11.2021 um 19:28 schrieb Maison Mo: > Here is the pdf generated by CreateSimpleForm.java (when not using > WinAnsiEncoding) : https://www.grosfichiers.com/VTKQFFBM9ci OK, thanks, fixed. Re "do you consider a good practice to not define any font encoding when defining a font" no, probably not. But apparently not illegal. Tilman > > Le samedi 13 novembre 2021 à 18:51:45 UTC+1, Tilman Hausherr > <thaush...@t-online.de> a écrit : > > Hi, > > Please share that PDF (upload it somewhere). > > Tilman > > Am 13.11.2021 um 18:28 schrieb Maison Mo: >> Hello, >> Thank you for advice ! Indeed it works in example.The difference is that the >> Helvetiva font is created with WinAnsiEncoding, and that encoding contains >> 'eacute'. >> See PDType1Font constructor L136 : encoding = WinAnsiEncoding.INSTANCE; >> >> If we modify this line and use instead readEncodingFromFont(), it fails as >> described in my initial message(in annotation : /V <41E942> but in >> appearance stream : <41FF42> Tj ) >> In my use case I can't modify pdf : only fill fields, and fail gracefully if >> this is not possible.Unfortunately for now it fails silently. >> >> M. >> >> >> Le samedi 13 novembre 2021 à 13:50:48 UTC+1, Tilman Hausherr >> <thaush...@t-online.de> a écrit : >> >> 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 >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org > For additional commands, e-mail: users-h...@pdfbox.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org For additional commands, e-mail: users-h...@pdfbox.apache.org
--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org For additional commands, e-mail: users-h...@pdfbox.apache.org
