Am 15.11.2021 um 06:44 schrieb zhanglij...@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
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: users-h...@pdfbox.apache.org
