ok, I will do it as you said ,thank you!
zhanglij...@myhexin.com From: Tilman Hausherr Date: 2021-11-15 11:44 To: users Subject: Re: Text field filling silently fails Am 15.11.2021 um 01:51 schrieb zhanglij...@myhexin.com: > Please look at this issue for me,thank you very much! Hello, The issue has been fixed, a snapshot is available at https://repository.apache.org/content/groups/snapshots/org/apache/pdfbox/pdfbox-app/2.0.25-SNAPSHOT/ I doubt you have the same problem. Please start a new thread and explain what happens. Tilman > > ------------------------------------------------------------------------ > zhanglij...@myhexin.com > > *From:* Tilman Hausherr <mailto:thaush...@t-online.de> > *Date:* 2021-11-14 13:15 > *To:* users <mailto:users@pdfbox.apache.org> > *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
