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
