Japanese Translation:

本質的な問題は、文書作成に伴うエラーに起因しており、末尾のマイナス記号が背景色と同程度の灰色レベル（0.878）で設定されることで目に見えなくなることから、金融ソフトウェアが正数値を負数の値として誤認識してしまうというものです。これは、PDF の抽出処理が可視テキストだけでなくデータストリームそのものを読み取るためであり、特に

Tj

PDF の奇妙な「末尾マイナス記号」とその解決策

顧客から「出金額が負の値として表示されている」という報告を受けました。PDF を解析した結果、以下の特異な現象が判明しました。

全件にわたる異常: 金額列すべてが負の数として認識されました。
不可視の記号: 列ヘッダーの末尾に「マイナス記号（
```
-
```
）」が含まれていました。
具体的な例:
```
$110.00-
```
や
```
$1,527.57
```
のように、値の後に予期せぬマイナス記号がついています。

この問題は、PDF の内部コマンド構造とグレーレベル設定によって引き起こされています。

問題の技術的な原因

PDF は一連のコマンドで構成されます。「テキストを描画し、最後にマイナス記号を描画」する仕組みになっています。

コマンドの流れ

```
BT
```
: テキスト描画モード開始（グラフィックス状態を保存）
```
ET
```
: テキスト描画モード終了（状態復元）
```
Tf
```
: フォントとサイズを設定
```
Td
```
: 文字位置を移動
```
Tj
```
: テキストを表示
```
g
```
/
```
G
```
: グレーレベルの設定

「$110.00-」の場合

コマンドは以下の順序で実行され、最後のマイナス記号が通常色（グレー 0）で描画されます。結果として正常に表示されます。

BT
Tf
Td
Tj (テキスト: $110.00)
g (グレーレベル: 0)
Tj (テキスト: -)
ET

「$1,527.57-」の場合（問題発生）

マイナス記号を描画する際、グレーレベルが 0.878 に設定されています。

この色は背景色と一致するため、人間目には「見えない」ようになります。
しかし、コード上には文字が存在します。
結果: 変換プログラムがこれをテキストとして読み取り、「負の数」として解釈してしまいます。

なぜそのような PDF が生成されたのか？

開発者の意図は不明ですが、以下の理由から推測されます。

右揃えの精度維持:
- 数字を右揃えにする際、マイナス記号の有無による幅の違い（フォントによる差異など）を考慮して余白を調整するのは困難です。
表示位置の一貫性:
- マイナス記号が含まれる場合でも含まれない場合でも、同じ幅のスペースを確保するために「常に余分な文字分」を埋めました。
判断ミス:
- 正確な幅予測が困難だったため、「正の数値にも見えないマイナス記号を追加」する手段を選んだと考えられます。

対策：正常なデータを抽出するには

視覚的には問題ない PDF から、内部の「不可視なマイナス記号」を除去してデータを抽出する必要があります。以下の 2 つのアプローチがあります。

解決策 #1: PDF の OCR 化

PDF を画像（PNG）に変換し、OCR ソフトウェアでテキストを読み取る方法です。

概要: テキスト要素を直接解析せず、画像として認識します。
メリット: 不可視な記号の影響を受けにくく正常に抽出可能です。
デメリット:
- OCR は 100% 正確ではありません（文字誤認の可能性あり）。
- 標準的なテキスト抽出と比較して処理時間が大幅にかかります。

解決策 #2: 黒以外のテキストを削除（推奨）

銀行振替明細書などで、重要なデータは黒色のみである場合、他の色のテキストは無視できるというアプローチです。

概要: グレーレベルが 0.878 など背景に溶け込んでいるマイナス記号だけを除外し、黒い文字のみを抽出します。
現状の課題:
```
Bank Statement Converter
```
は現在、テキストの色情報を保存していません。
実装方法: 色情報を取得するためのコード追加が必要です。
結論: 多少の開発労力（色の判定ロジック追加）はかかりますが、本質的には複雑な処理ではないため、最も確実で高速な解決策です。

なぜすべての金額が負の数になっているのでしょうか？