Q&A
> チェックはすり抜けてしまった
というのは可だったのか不可だったのか、どちらでしょう。
> フォントとしては対応していないという事象
ということは、不可だったのでしょうか。
しかし
> 実際にフォントで表現する際、空白表現が正しくできないという状態
というのは、「不可」だったら当然かと思いますが…。
タブを「どうしたい」のに「どうなってしまった」のか、もう少しはっきりお書きくださいませんか。
Javaで、指定フォントで表現できるかどうかチェックする処理を作りたいと思っています。
java.awt.Font.canDisplayUpTo(String str)
上記関数を利用してできそうだと思っていたんですが、落とし穴がありました。
タブ（\t、U+0009）をチェックしようとした際に、チェックはすり抜けてしまったのですが、
フォントとしては対応していないという事象が発生しました。
タブの場合、文字列としては、「\t」で処理されますが、実際には、空白があく表現になります。
canDisplayUpToを使ったチェック時には、「\t」としてチェックされるので、そのまますり抜けますが、
実際にフォントで表現する際、空白表現が正しくできないという状態になっています。
「\t」とかだけであれば、ピンポイントでチェック条件を追加してしまえばいいのんですが、ほかにも同様の
文字があった場合に、都度追加をしなくてはいけないのは少し手間に感じます。
実際の表現ベースでフォントとして表現できる・できないをチェックする効率のいい手段はありますでしょうか？
代替の手順としては、何かしらの画像に実際に出力して、出力できる・できないを確認する方法も考えていますが、
チェック処理が増えると、画像変換が無駄処理に思えてきて、ほかのいい方法を探しています。
宜しくお願いします。
すみません。追記いたします。
チェックはすり抜けてしまった
該当関数の戻り値としては、
戻り値: このFontが表示できないstr内の最初の文字を指すstrへのオフセット、またはこのFontがstr内のすべての文字を表示できる場合は-1。
となっているため、期待値としては、問題の文字のオフセットが戻ることですが、タブの場合は、「-1」が戻ってきている状態となります。
フォントとしては対応していないという事象
というのは、「不可」だったということになります。
「不可」なので、当然、実際にフォントでの表現ができない状態となります。
今回の「タブ」のように、実際にフォントで表現できない文字が含まれているかどうか、正確にチェックしたいです。
表現できる・できないを、実際に変換してからエラーとして処理するのではなく、事前にチェックをして、表現できないのであれば、変換処理を行わないような処理にしたいです。
再度追記致します。
「フォントで表現できない」という部分ですが、最終的には、PDPageContentStreamを利用してPDF出力しようとしています。
java
1PDFont font = PDType0Font.load(doc, new File("TTFファイルパス")); 2 3PDPage page = new PDPage(rectangle); 4PDDocument doc = new PDDocument(); 5doc.addPage(page); 6 7PDPageContentStream contents = new PDPageContentStream(doc, page) 8contents.beginText(); 9contents.setFont(font, 12); 10contents.showText("文字列");
この処理をした際、指定したフォントファイル（TTFファイル）で対応できないと、例外エラーが発生してしまうため、そのような文字列ではないことの確認を事前にやりたいという流れになります。
java.lang.IllegalArgumentException: No glyph for U+0009 in font IPAPGothic at org.apache.pdfbox.pdmodel.font.PDCIDFontType2.encode(PDCIDFontType2.java:363) at org.apache.pdfbox.pdmodel.font.PDType0Font.encode(PDType0Font.java:398) at org.apache.pdfbox.pdmodel.font.PDFont.encode(PDFont.java:324) at org.apache.pdfbox.pdmodel.PDPageContentStream.showTextInternal(PDPageContentStream.java:509) at org.apache.pdfbox.pdmodel.PDPageContentStream.showText(PDPageContentStream.java:471)
タブが「フォントで表現できない」とはどういう意味ですか?
タブはフォントで表現するものではないため、正しく表示できないのであればフォント側ではなく文字表示エンジン側の問題ではないでしょうか。
フォントによってタブが表現できるものと表現できないものがあるのでしょうか。その場合画像を貼ってください。
> canDisplayUpToを使ったチェック時には、「\t」としてチェックされるので
たぶんあなたの勘違いだと思うのですが、なぜそう判断したのですか?
> タブの場合は、「-1」が戻ってきている状態
canDisplayUpTo("\t") が -1 だったということですね。つまり「表示出来る」と返されたと。
でも実際にそのフォントで表示すると TAB のようには表示されなかった(スペースと同じだったとか幅0だったとか)ということでしょうか。
回答1件
0
ベストアンサー
「canDisplayUpTo("\t") は -1 が返るのに実際に表示してみると"文字"にはならない。こういったコードを(実際に描画する前に)予め弾くことはできるか」というご質問と解釈します。
恐らく 0x0～0x1F のコードは初めから分けて考えるのではないでしょうか。
つまり文字列を表示する場合の想定として
各文字において
・文字が 0x0～0x1f だったらコントロールコードとしての処理(カーソル移動、改行やタブや・・・）をして次の文字へ。
・canDisplay(文字) が表示可能だったらグリフを表示して次の文字へ。
・それ以外ならエラーを出すか無視するか特別な文字(ソ〇トバンクモバイルの"="マーク?)を表示して次の文字へ。
という流れということです。(あくまで想像ですが。)
そして、この一連の処理の前に canDisplayUpTo("タブ等を含む文字列") で上の”それ以外"の処理となるコードがあるかを調べられるということでは無いかと思います。
投稿2021/08/05 16:15
編集2021/08/05 17:51総合スコア12756
ありがとうございます。
コントロールコードを正しく処理できていないのがいけないのだと理解致しました。。
チェックの理処理として、canDisplayUpToとコントロールコードの有無を合わせて対応するのが正しいと思うので、試してみるようにします。
> PDPageContentStreamを利用してPDF出力
どのような感じになるのかと検索して以下の記事を見ましたところ、
( https://blog1.mammb.com/entry/2020/03/30/090000 )
記事の中ほどに
「なお、.replaceAll("\p{C}", "") は ASCII 制御文字を空文字置換しています。改行コードなどが含まれていた場合に対象フォントが存在せずにエラーとなるため、行の分割後にこれらを削除しています。」
という文がありました。
改行('\n')で分割した後にこのような処理をされていますので(この記事だけを見て"一般的な方法"とは言えませんが)悪くない方法なのではないかと思います。
ありがとうございます。
登録時にチェックして弾く方法と、出力時に変換してエラーを回避する方法がありそうなので、内容によって処理に合った方法で対応したいと思います。
分かりにくい質問となり申し訳ございませんが、回答くださりありがとうございます。
> それ以外ならエラーを出すか無視するか特別な文字(ソ〇トバンクモバイルの"="マーク?)を表示して
Unicodeだと置換文字（U+FFFD、�）もありますね。
> Unicodeだと置換文字
確かに見たことあります。すっかり忘れてました、ありがとうございます。
流石にソ〇トバンクマークは古かったですかね ^^;
あなたの回答
tips
プレビュー
