Re: [Jpfop-develop] Type0 =?iso-2022-jp?B?GyRCJVUlKSVzJUhCUDF+SEcbKEJKUEZPUCAwLjIwLjQ=?=

[Satoshi I. <ish...@vi...>]

On Tue, 10 Dec 2002 19:22:52 +0900 , MIYABE Tatsuhiko wrote:

> > 90ms-RKSJ-Hは、Type0フォントが指定されたテキストは、MS932で記述
> > されている必要があるので、無理矢理ではなく、そういう仕様です。
> 
> 多分、これはMS932コードからCIDコードへのマッピングですね？
> org.apache.fop.render.pdf.PDFRenderer#renderWordAreaに渡ってくる
> キャラクタをこれに通すと化けてしまいます。
> renderWordAreaに渡ってくるcharはUnicodeなので、
> もしかすると以前のFOPはchar型にMS932のコードを入れていたのだと思いました。
> (Javaのchar型は本来Unicodeなので、無理やりというのはそういう意味です...)

既に解決済みかもしれませんが、これは、jpfop0.17.0_01のorg.apache.
fop.render.pdf.PDFRenderer#renderWordAreaにおける、

  if ( ((CIDFont)f).getCidType() == PDFCIDFont.CIDFontType2 ) {
      // CIDFontType2
      pdf.append(" <");
      for (int i=0; i < s.length(); i++) {
          char ch = s.charAt(i);
          pdf.append(Integer.toHexString((int)ch));
      }
      pdf.append("> Tj\n");
  } else {

という772行目付近で実装されています。

確かにcharはUnicodeです。この処理以前で、行内領域のStringを1度
MS932のバイト列で取得し(MS932はCIDFont.getCharEncoding()で取得)、
それを8859_1で再度Stringにしています。

Unicodeと8859_1ではLaten-1でコードポイントが同じなので、MS932の2
バイト文字は、char[n]とchar[n+1]に分割されていることになります。
それをHex文字列で出力すれば、90ms-RKSJ-Hで上手いこと表示されるは
ずです。確かに強引ですね。。。

---
石神 覚司(Satoshi Ishigami)   VIC TOKAI CORPORATION