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
<[email protected]> 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
><[email protected]> 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: [email protected]
> For additional commands, e-mail: [email protected]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
