1

フォーム フィールドの奇妙な動作について質問があります。

  1. 2 つの PDF ドキュメント。両方とも、Helvetica をフォントとして使用するテキスト フィールドがあります。
  2. 両方とも、同じ iText ロジックを使用して値で埋められます (以下の cp)。

フィールド値 (/V) は両方の PDF で正しいですが、フィールドの外観は正しくありません。1 つの Pdf は正常に機能し、他のスクランブルはユーロ記号 € などの特殊文字または üöäß などのドイツ文字をスクランブルします。私は代替フォントを定義しようとしましたが (本で説明されているように)、€ と ß が機能しませんでした。

私が見つけた唯一の違いは、 /DR ディクショナリが（グローバルなものに加えて）機能しないPDFのフィールドレベルで定義されていることです。しかし、それを削除しても、€ 記号は機能しません。ここでは、アジアや一部のエキゾチックな Unicode 文字について話しているわけではないことに注意してください。すべて標準のヘルベチカ フォントの一部です (他の PDF が証明しているように)。

質問:

  1. 動作していない PDF に文字を正しく表示する方法はありますか?
  2. または、PDF は何らかの形で pdf 仕様に違反していますか? (Acrobat を使用して作成されたため、可能性は低くなりますが、不可能ではありません)。
  3. フォームフィールドのフォントを置き換えることを提案した場合- 完全に有効で機能しているファイルに対してはそうしたくないので、機能している PDF ファイルと機能していない PDF ファイルを区別するにはどうすればよいですか?

更新：コードは問題ではありません（両方のコードが同じであるため、私はそれを確信しています）が、完全を期すためにここにあります：

AcroFields acroFields = stamper.getAcroFields();
try {
    boolean successful = acroFields.setField("Mitarbeiter", "öäü߀@");
    if (!successful) {
        //throw some exception
    }
}
catch (DocumentException de) {
    //some exceptionhandling
}
4

1 に答える 1

1

これに関する PDF リファレンスには何の手がかりも見つかりませんでしたが、フィールドに使用されているフォントはエンコーディングを定義していません。ただし、エンコーディングはリソース ディクショナリ ( /DR) のレベルで定義されます。そのエンコーディングを使用すると、フィールドの外観が正しく作成されます。/EncodingISO 仕様は、リソース ディクショナリのレベルでのエントリの存在について何も述べていないことに注意してください。

iText を少し更新しました。リビジョン 6693での変更を確認できます。/DRこのようにして、フォントのレベルでエンコーディングが定義されていない場合、iText はディクショナリにエンコーディング値があるかどうかをチェックします。この修正により、フォームは正しく入力されます。

于 2015-01-13T16:43:49.693 に答える