内容が誤っていたので全面的に書き換え。(2019-05-26)
検証には何度も「ビルド」という重い作業(他の作業が非常にしづらく、時間もかかる)をやる必要があって気力が出ず、かつ他にも検証したいことがあって遅れてました。申し訳ありません。
https://opengrok.libreoffice.org/xref/core/sc/source/core/data/documentimport.cxx?r=49bc42bf#631
なお、p->mbLatinNumFmtOnlyの値は、odsファイルの場合はfalseです。
この値はここで設定されています。
https://opengrok.libreoffice.org/xref/core/sc/source/filter/xml/xmlimprt.cxx?r=a361231b#955
ので、セルの内容全体が西洋系の言語として扱われます。
- 一方、数式の場合、代入がされず、以下のコードによりSvtScriptType::UNKNOWNであると思います。
https://opengrok.libreoffice.org/xref/core/sc/source/core/data/celltextattr.cxx?r=f1a10d4f#17
- さて、LibreOfficeはファイルをロードするに当たり、各行の高さを設定するのですが、最適な高さを求める際に、その内容がどの系統の言語なのか(西洋系？東洋系？CTL)がUNKNOWNである場合に、その文字列から、リッチテキストのようなものを文字列の各部(Span)に対して生成しており、これらにはその言語系に応じたフォントが当てられるようです。
https://opengrok.libreoffice.org/xref/core/sc/source/core/data/column4.cxx?r=aae39e5d#998
https://opengrok.libreoffice.org/xref/core/sc/source/core/data/column4.cxx?r=aae39e5d#1019
-
なので、手動で、数値のセルの書式から西洋系のフォントを、違いがわかりやすいSerif系のフォントにしてあげると「￥5」の両方がSerifになります。
-
一方、数式のセルは「￥」は東洋系、「5」は西洋系として扱われているので、当該セルの西洋系のフォントをSerif系にしても「￥」の部分は変化しません。東洋系のフォントをSerifにしたときに変更されます。
-
そしてこの見た目の違いはフォントの違いから来るものであって、文字が異なるわけではありませんでした。
-
余談ですが、私の環境ではどうもv6.3系と自家ビルドの挙動が何故か異なるようです。おそらくですが、西洋系の言語用のorg.openoffice.VCL:LocalizedDefaultFontsに並べられたフォントの中に当該文字用のグリフを含むものがないのでしょう。Windowsの場合、代わりのフォントを探す際に(LibreOfficeのディレクトリ)/share/fonts/truetype/に格納されたフォントを一つ一つチェックするみたいで、自家ビルドではこれはGen Shin Gothic Boldになっており、ワークシートをPDFとして出力してデータを調べたときに使われているフォントと一致しました。また、このtruetypeフォルダをリネームしてみたところ、別のフォントが候補に上がることを確認しました。
https://opengrok.libreoffice.org/xref/core/vcl/win/gdi/salfont.cxx?r=d0265c12#331
- コード上にこのフォント名が文字列リテラルとして登場するわけではないのも調査が難航した一因です。
