You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@pdfbox.apache.org by Maison Mo <mo...@yahoo.fr.INVALID> on 2021/11/13 08:46:24 UTC
Text field filling silently fails
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.
Re: Text field filling silently fails
Posted by Tilman Hausherr <TH...@t-online.de>.
Am 15.11.2021 um 06:44 schrieb zhanglijie2@myhexin.com:
> When was this issue fixed?
Yesterdayhttps://issues.apache.org/jira/browse/PDFBOX-5321
> I asked it last month
Maybe that was something else. This thread was started by Mo Maison. You
did not post last month. (Or you did and it was rejected for some reason?)
Tilman
>
>
>
> zhanglijie2@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 zhanglijie2@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
>
>
>> ------------------------------------------------------------------------
>> zhanglijie2@myhexin.com
>>
>> *From:* Tilman Hausherr <ma...@t-online.de>
>> *Date:* 2021-11-14 13:15
>> *To:* users <ma...@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 <th...@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 <th...@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-unsubscribe@pdfbox.apache.org
>> >> For additional commands, e-mail: users-help@pdfbox.apache.org
>> >>
>> >>
>> >
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>> > For additional commands, e-mail: users-help@pdfbox.apache.org
>> >
>> >
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:users-unsubscribe@pdfbox.apache.org
>> For additional commands, e-mail:users-help@pdfbox.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: Re: Text field filling silently fails
Posted by "zhanglijie2@myhexin.com" <zh...@myhexin.com>.
When was this issue fixed? I asked it last month
zhanglijie2@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 zhanglijie2@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
>
> ------------------------------------------------------------------------
> zhanglijie2@myhexin.com
>
> *From:* Tilman Hausherr <ma...@t-online.de>
> *Date:* 2021-11-14 13:15
> *To:* users <ma...@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 <th...@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 <th...@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-unsubscribe@pdfbox.apache.org
> >> For additional commands, e-mail: users-help@pdfbox.apache.org
> >>
> >>
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> > For additional commands, e-mail: users-help@pdfbox.apache.org
> >
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: users-help@pdfbox.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:users-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail:users-help@pdfbox.apache.org
Re: Re: Text field filling silently fails
Posted by "zhanglijie2@myhexin.com" <zh...@myhexin.com>.
ok, I will do it as you said ,thank you!
zhanglijie2@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 zhanglijie2@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
>
> ------------------------------------------------------------------------
> zhanglijie2@myhexin.com
>
> *From:* Tilman Hausherr <ma...@t-online.de>
> *Date:* 2021-11-14 13:15
> *To:* users <ma...@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 <th...@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 <th...@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-unsubscribe@pdfbox.apache.org
> >> For additional commands, e-mail: users-help@pdfbox.apache.org
> >>
> >>
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> > For additional commands, e-mail: users-help@pdfbox.apache.org
> >
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: users-help@pdfbox.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:users-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail:users-help@pdfbox.apache.org
Re: Text field filling silently fails
Posted by Tilman Hausherr <TH...@t-online.de>.
Am 15.11.2021 um 01:51 schrieb zhanglijie2@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
>
> ------------------------------------------------------------------------
> zhanglijie2@myhexin.com
>
> *From:* Tilman Hausherr <ma...@t-online.de>
> *Date:* 2021-11-14 13:15
> *To:* users <ma...@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 <th...@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 <th...@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-unsubscribe@pdfbox.apache.org
> >> For additional commands, e-mail: users-help@pdfbox.apache.org
> >>
> >>
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> > For additional commands, e-mail: users-help@pdfbox.apache.org
> >
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: users-help@pdfbox.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:users-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail:users-help@pdfbox.apache.org
Re: Re: Text field filling silently fails
Posted by "zhanglijie2@myhexin.com" <zh...@myhexin.com>.
Please look at this issue for me,thank you very much!
zhanglijie2@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 <th...@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 <th...@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-unsubscribe@pdfbox.apache.org
>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: users-help@pdfbox.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: Text field filling silently fails
Posted by Tilman Hausherr <TH...@t-online.de>.
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 <th...@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 <th...@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-unsubscribe@pdfbox.apache.org
>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: users-help@pdfbox.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: Text field filling silently fails
Posted by Maison Mo <mo...@yahoo.fr.INVALID>.
Here is the pdf generated by CreateSimpleForm.java (when not using WinAnsiEncoding) : https://www.grosfichiers.com/VTKQFFBM9ci
Le samedi 13 novembre 2021 à 18:51:45 UTC+1, Tilman Hausherr <th...@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 <th...@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-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: users-help@pdfbox.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: Text field filling silently fails
Posted by Tilman Hausherr <TH...@t-online.de>.
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 <th...@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-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: users-help@pdfbox.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: Text field filling silently fails
Posted by Maison Mo <mo...@yahoo.fr.INVALID>.
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 <th...@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-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: Text field filling silently fails
Posted by Tilman Hausherr <TH...@t-online.de>.
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-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org