外付けHDDをExFATにしました。

2014年の年末に、自宅の外付けHDDのファイルフォーマットをExFAT形式にしました。MacintoshとWindows双方で標準対応する形式です。
テラ単位のHDDが複数台あったので、玉突きコピーで数日かかってしまいました。

Paragon NTFS for Macなどを使っていた時期もありましたが、KEXT(kernel extension)を色々加えるのはどうも気持ちが良くないので使うのを止めました。

今のところ意図通りに役立っており特に困ってはいませんが、検索するとExFATにまつわるトラブル話もいくつか見かけます。一抹の不安は残りますが、Macintosh標準のHFS+も必ずしも完璧なファイルフォーマットというわけではないようなのであまり気にしないこととします。

ちなみにExFAT形式はAndroidやlinuxには標準で対応していないのですね。
追加でドライバをインストールする必要があるようです。フォーマットし直した後で気付きました。
Androidの場合、root権限が必要なのでそれなりにハードルは高いです。

源ノ角ゴシックとNoto Sansをcssで指定

源ノ角ゴシック(Source Han Sans)とNoto Sans内のメタデータを調べたので、cssのfont-familyとしてあてがってみました。

源ノ角ゴシックとNoto Sansをcssで指定してみるテスト

◎確認するにはあらかじめフォントをインストールしておく必要があります。

Preferred Family(日・英の2つ)だけが「ファミリー」でフォントを命名していますが、それ以外はウェイト込みの名称となります。源ノ角ゴシックは「Normal」、Noto Sansは「Regular」を使用しました。

異なるnameIDに対して同じ命名(文字列)をしている箇所も多いので、実際には数個(源ノ角ゴシック:5個)で済みました。Noto Sansは言語別の命名をしていないのでさらに少なく(Noto Sans:3個)なります。

  • 源ノ角ゴシック(Windows用・日本語・Preferred Family)
  • 源ノ角ゴシック Normal(Windows用・日本語・Full font name 兼 Family name)
  • Source Han Sans J Normal(英語・Full font name 兼 Family name)
  • Source Han Sans J(Windows用・英語・Preferred Family)
  • SourceHanSans-Normal(Postscript name)
  • Noto Sans Japanese(Windows用・Preferred Family)
  • Noto Sans Japanese Regular(Full font name 兼 Family name)
  • NotoSansJp-Regular(Postscript name)

複数のOS、ブラウザで表示を確認してみていますが対応はバラバラです。昔からちっとも変わっていません。ざっくり調べてみたところ、

Macintosh Chrome:

  • Source Han Sans J(Windows用・英語・Preferred Family)
  • SourceHanSans-Normal(Postscript name)
  • Noto Sans Japanese(Windows用・Preferred Family)
  • NotoSansJp-Regular(Postscript name)

Macintosh Safari:

  • Source Han Sans J(Windows用・英語・Preferred Family)
  • SourceHanSans-Normal(Postscript name)
  • Noto Sans Japanese(Windows用・Preferred Family)
  • NotoSansJp-Regular(Postscript name)

Macintosh Firefox:

  • 源ノ角ゴシック(Windows用・日本語・Preferred Family)
  • 源ノ角ゴシック Normal(Windows用・日本語・Full font name 兼 Family name)
  • Source Han Sans J Normal(英語・Full font name 兼 Family name)
  • Source Han Sans J(Windows用・英語・Preferred Family)
  • SourceHanSans-Normal(Postscript name)
  • Noto Sans Japanese(Windows用・Preferred Family)
  • Noto Sans Japanese Regular(Full font name 兼 Family name)
  • NotoSansJp-Regular(Postscript name)

Windows Crome:

  • 源ノ角ゴシック Normal(Windows用・日本語・Full font name 兼 Family name)
  • Source Han Sans J Normal(英語・Full font name 兼 Family name)
  • SourceHanSans-Normal(Postscript name)
  • Noto Sans Japanese Regular(Full font name 兼 Family name)
  • NotoSansJp-Regular(Postscript name)

Windows IE11:

  • 源ノ角ゴシック(Windows用・日本語・Preferred Family)
  • 源ノ角ゴシック Normal(Windows用・日本語・Full font name 兼 Family name)
  • Source Han Sans J Normal(英語・Full font name 兼 Family name)
  • Source Han Sans J(Windows用・英語・Preferred Family)
  • Noto Sans Japanese Regular(Full font name 兼 Family name)
  • Noto Sans Japanese(Windows用・Preferred Family)

Windows Firefox:

  • 源ノ角ゴシック(Windows用・日本語・Preferred Family)
  • 源ノ角ゴシック Normal(Windows用・日本語・Full font name 兼 Family name)
  • Source Han Sans J Normal(英語・Full font name 兼 Family name)
  • Source Han Sans J(Windows用・英語・Preferred Family)
  • Noto Sans Japanese(Windows用・Preferred Family)
  • Noto Sans Japanese Regular(Full font name 兼 Family name)

の記述が有効でした。ただし、「Preferred Family」が機能してもその際に表示されるウェイトはまちまちです。

ウェイト含めて意図通り表示させようとするとさらにブラウザごとの表示が変わります。

源ノ角ゴシックExtraLightとNoto Sans Thinをcssで指定してみるテスト

実際に使う際には、複数の名称を重ねる必要があります。また、ユーザーが源ノ角ゴシック/Noto Sansのどちらをインストールしているかはわからないので、両方とも記述する必要があります。エラーの発生する(が反応してしまう)指定を先に記述すると、意図する表示が実現しません。

さらに、Bold(<strong>タグ)の再定義も必要だと思います。

源ノ角ゴシックとNoto Sans

Adobeの源ノ角ゴシック(Source Han Sans)とGoogleのNoto Sansをダウンロードしてみました。

取り急ぎ、フォント情報を調べてみました。アプリ「OTEdit」を使っています。

源ノ角ゴシック Normal

Noto Sans JP Regular

字形は同じでも、フォント情報は全く異なるようです。マシンにインストールしても、それぞれ独立したフォントとして認識されます。

おや、「ファミリーネーム」にウェイト名称がついてしまっています。これでは各ウェイトが別のフォントとして認識されてしまうのではないでしょうか。

FontBookで表示してみました。

源ノ角ゴシック FontBook

Noto Sans FontBook

きちんと「ファミリー」で表示されています。
どの情報を使って、同じ書体群であることを認識しているのでしょうか。

以前の投稿、「游ゴシック体/游明朝体をWebで利用する」内で紹介した記事をもう一度確認するとわかりました。

フォントファイル内のメタデータ、「Preferred Family」と「Preferred Subfamily」を使ってフォントファミリーとウェイトを定義しているようです。

記事内で使われていたアプリ、「OTMaster」のLight版(無料)でメタデータを表示してみました。

源ノ角ゴシック OTMaster

Noto Sans OTMaster

「Preferred Family」はありましたが、「Preferred Subfamily」は定義されていません。「Subfamily name」はあるのでこちらで代替しているのでしょうか。

いずれにせよ、これらの書体が普及して、いろんなマシンにインストールされたとしてもcssのfont-familyで指定するのはちょっと難しいかもしれません。出来たとしても、トリッキーな記述になってしまう気がします。

GoogleあたりからWebフォントとして提供されるのを待つべきでしょうか。

游ゴシック体/游明朝体をWebで利用する

游ゴシック体/游明朝をWebで使う方法。OSX版。

新しいOSX Mavericks(10.9)には「游ゴシック体」と「游明朝体」が搭載されました。
font-family: の指定でhtmlにも使えます。

(游ゴシック体html表示サンプル|OS 10.9以降で表示)

イオンPBは「責任は全てイオンがもちます」を大前提に、製造元も原産国も記載していなかった筈なのに、いざ食品偽装が起きた途端、納入業者に責任丸投げとかなかなか清々しいクズ

(游明朝体html表示サンプル|OS 10.9以降で表示)

イオンPBは「責任は全てイオンがもちます」を大前提に、製造元も原産国も記載していなかった筈なのに、いざ食品偽装が起きた途端、納入業者に責任丸投げとかなかなか清々しいクズ

css記述時には、游ゴシック体は「YuGothic」、游明朝体は「YuMincho」となります。
英語用の「ファミリーネーム」を利用しています。

游ゴシック体 ミディアム

游明朝体 ミディアム

<strong>タグも機能しますが、游明朝体の太字はデミボールドなので差がわかりづらく、強調表現としては使えないかもしれません。

ちなみに、Windows 8.1にも游ゴシック体/游明朝体が搭載されましたが、ウェイトが微妙に異なるようです。そのようなつぶやきを見つけました。游ゴシック体 ボールドと游明朝体 デミボールドのみ、同じウェイトです。

デバイス文字のMac/Win統一のためにこの書体を利用できるかと思いましたが、ちょっと難しそうです。

131031|追記 Windows環境やブラウザの対応を考慮した記述方法についてはこちらが詳しいです。
131101|追記 Dutch Type LibraryのOTMasterというソフトでフォント情報を調べてcssの指定方法を詳しく解説した記事を見つけました。

しがらみフォント

もうビットマップフォントは不要。「しがらみフォント」を削除する方法。

しがらみフォントを削除しました。

「しがらみフォント」とはアンチエイリアス無しの表示に最適化したビットマップフォントを持つフォントのことです(※1)。古いOS向けの古いフォントです。Macintoshであれば「Osaka」、Windowsであれば「MS Pゴシック」などがあたります。

PCやタブレット、スマホ画面の高解像度化、iOSやAndroidなど新しいOSの普及、既存OSのアップデートなどにより、テキストのアンチエイリアス表示はすっかりデフォルトになりました。
一般のサイトもClearType対応の日本語書体「メイリオ」を前提にしたcssを使うようになり、Windows日本語版特有の、貧相な見えのサイトは減ってきました。

「始めて使うOS」がスマホのOSの人も増えたと思います。最初から綺麗なアンチエイリアス表示に慣れた人はわざわざ「アンチエイリアスなしの方が見やすい」などとは言いません。

「しがらみフォント」は役割を終えたと考えるので、自分の環境からは削除します。

////////////////////////////
OSXの場合

システムから「Osaka.ttf」「OsakaMono.ttf」

/Library/Fonts/Osaka.ttf
/Library/Fonts/OsakaMono.ttf

を管理者権限で削除します。

古いサイトでは未だにOsakaをfont-family指定の最初に持ってきているものがありますが、ヒラギノ角ゴシックProNなどで表示されるようになります(ブラウザの設定によります)。

下は、私がよく見に行くサイト「デジカメジン」さんのとあるページです(引用箇所に他意はありません)。

cssにOsakaが含まれています。

osx_osaka

Osakaを削除することでヒラギノ角ゴシックになります。やや細く・大きくなります。

osx_hiragino

Osakaの品質が高ければ/好みであればそのまま放置してもよいのですが、アウトラインフォントとしてのOsakaは単なる「平成角ゴシック」です。平成角ゴシックはアウトラインフォントの普及を主目的としたもので、表示品質を最優先して開発されたフォントではありません。また、「レギュラー」のウェイトがやや太めで本文サイズでは画数の多い漢字がつぶれがちです。

////////////////////////////
Windowsの場合

「ClearTypeを有効」にし、ブラウザの書体設定を「メイリオ(Meiryo)」にしておけば概ね問題ないのですが、font-familyの先頭を「MS Pゴシック」にしているサイトはまだまだ多いので、アンチエイリアス無し表示の排除はなかなか実現しません。
力技(ちからわざ)ですが、MS Pゴシック(MSゴシックファミリー)からビットマップフォントを削除します。

作り方:(※2) フォント作成ソフト「TTEdit(有償)」を使ってシステムからMS Pゴシック、MS Pゴシック、MS UIゴシックを「一括コピー」することで、ビットマップフォントの削除を行ないます(コピー時にビットマップフォントをコピーしない)。その上で、オリジナルのフォント情報をそのまま書き写すことで、ビットマップフォントを含まないMSゴシックのクローンが出来上がります。仕上げに、フリーウェア「UniteTTC」を利用しttfファイルをttcファイルに統合し、Windowsのシステムに上書きします。

通常、本文サイズではMS Pゴシック内蔵のビットマップフォントがアンチエイリアスなしで表示されます。

win_noanti

ビットマップフォントを削除すると、アウトラインフォントをベースにClearTypeでレンダリングされます。

win_anti

今後、画面の高解像度化が進めば文字サイズは「大きく(=高精細に)」扱われるでしょう。ビットマップフォントでの小サイズ表示は不要になると考えています。

////////////////////////////

※1 いま私が名付けました。

※2 フリーウェアだけで作業したい場合は、こちらのサイト(MSゴシックとMS明朝で、ClearTypeを有効にする)が参考になると思います。あるいは、FontForgeを使える環境であれば同じく作業可能だと思います(未検証)。その他、「ビットマップフォント 削除」でググると2000年代(XP〜Vista時代)の役に立つ記事が出てくるようです。

三点リーダ 他

三点リーダ、欧文書体をあてがうと、ベースラインまで下がります。あ、記事作成中に解決方法を見つけた。他のキャラクターはどうしよう。

(Windowsやrssのフィードだと記事内容がわかりづらいと思います。OSX上のブラウザでご覧ください)

このブログのfont-family設定ですが、Lucida Grandeを先頭に持ってきています。

font-family: 'Lucida Grande', 'Hiragino Kaku Gothic ProN'……(以下略)

OSXでご覧の方は英数字がLucida Grande、和文がヒラギノ角ゴシックProNの和欧混植になっているはずです。Appleのサイトをまねています。

残念ながら、こちらはAdobeアプリで言うところの「合成フォント」とは異なり、先頭で指定した欧文書体(Lucida Grande)に含まれないキャラクターを、次に指定した和文書体(ヒラギノ角ゴシックProN)で埋めていく、あくまでも擬似的なものです。いわゆるハックです。

文字種単位での指定ができないため、いくつかのキャラクターが意図しない表示になります。

  • 文末でよく使う 「三点リーダ」[ ]がLucida Grande[ … ]で表示されてしまいます。ボディ中央でなくベースラインまで下がってしまいます。
  • ][ ]などの「まる」が小さく[ ● ][ ○ ]なってしまいます。欧文のバレット[•(option+8で入力)]に近いサイズまで縮小してしまいます。
  • 同じく[ ][ ]などの「しかく」も小さく[ ■ ][ □ ]なります。
  • 註釈の頭などに付ける[ ]「こめじるし」も小さく[ ※ ]なります。 アスタリスクのような大きさになります。

「ハック」なのであきらめるのが基本です(※3)。半角ピリオド三つ[ … ]のように見えますが、気にしてはいけません。行頭のバレットは素直に<li>を使います。めんどくさい方は[ ◎ ]や[ ◉ ]を使いましょう。こちらは縮小しません。

////////////////////////////

font-familyの先頭に欧文書体を置いて和欧混植風な文字組みを行うのはポピュラーなテクニックですが、その際にどの文字種が和文書体と異なる表示になるかを調べる(※1)には、メニューバーの入力メニュー「文字ビューア」を使うと一目瞭然です。「三点リーダ」は英語では「HORIZONTAL ELLIPSIS(省略記号:水平)」と記載(※2)されています。

文字ビューア

※1
とは言うものの、欧文の三点リーダは基本、ベースラインに揃うタイプです。このエントリーを書くきっかけになったブログ小粋空間の記事、三点リーダが真ん中に表示されない理由の記事、に例示されている「三点リーダが真ん中に表示されるフォント」は汎用ファミリー(generic-family)やシステムフォントでフォント名ではありません。Lucida Grandeが含まれているのは単なる間違いと思われます。また、MS UI Gothicは和文フォントです。

※2
厳密には異なるようです。テクニカルな解説としては、エリプシス(ellipsis)と三点リーダ – Mac OS Xの文字コード問題に関するメモが大変参考になりました。

※3
三点リーダだけならば、

(U+22EF)の「⋯」を使うだけ

で解決するようです。「三点リーダの表示位置」問題を完全かつ最終的に解決する – めもおきばに方法が記載されていました。辞書登録しなくては。丸や四角など、他のキャラクターは見つけることができるでしょうか。「文字ビューア」で探してみることにします。あ、Androidだとダメですね。表示されません。グリフが用意されていないようです。

動画のカラーマネジメント

再生するソフトウェアによって、動画の色がかなり異なる。どうしたらいいんだろう。

動画のカラーマネジメントはさっぱりわかりません。
YouTubeで再生した時に表示される画面(※1)とオリジナルのファイルを手元で再生した画面とで
色(彩度・色相)がかなり異なるのです。

Sonyのデジカメ、DSC-RX100で撮影したAVCHD動画です。
撮影時のmtsファイルを無加工でそのままアップロードしています。

QuickTime Player

QuickTime Player(※2)で再生した画面(のキャプチャー)。鮮やかさが全く異なります。色相もだいぶ違う。
鮮やかなターコイズ(青緑)が枯れたラベンダー(青紫)になってしまいました。

Movist (FFmpeg)

動画プレーヤーMovist(FFmpeg系)で再生した画面。こちらの方がややYouTube画面の色味に似ています。

VLC

動画プレーヤーvlcで再生した画面。

気になったのでいろんな組み合わせで再生したものをキャプチャーして見ましたが、どれも少しずつ色味が異なります。
公開はYouTubeで行う事がほとんどではありますが、何を基準に判断していいものやら……。

Final cut Pro

Final Cut ProXの編集画面(のキャプチャー)。作業の都合上、とりあえず、ここらあたりを基準にするしかないとは考えていますが、QuickTime系の色味は調べた中では少数派(※3)……。

結論はありません。「動画のカラーマネジメント」で検索しても、今ひとつ決定的な情報が出てきません。引き続き調べようと思います。

※1 Chrome内蔵のFlash Playerで再生したYouTube。
※2 mtsファイルはデフォルトの環境では再生できないので、AVCCAM Importerプラグインをインストールしています。
※3 検索結果上位にある記事、WUXGA対応 高解像度ワイド液晶ディスプレイ選び「液晶ディスプレイとカラーマネージメント 編」内のコラム「動画でも色管理をする時代がやってくる」によると、OSX(=QuickTime)では動画に対してもカラーマネージメントが働いているとのこと。確かにそう考えると辻褄が合います。