[ 新着記事
| 数学・プログラミング
| 天文・暦
| シリア語・Unicode・詩
| ジョーク
| 漫画・アニメ
| 字幕
| 哲学・ファンタジー
| 全記事 ]
チラ裏コーナー（過去のチラ裏）
2019-10-16 問題が条件付きで回避されるのは、LAVFilters のうち、2019-03-16 の v0.74 以降（※）。リリースノートに Fixed: Fonts embedded in MKVs without a proper mimetype were not being imported
とある（※※）。MPC-HC では、2019-03-17 の v1.8.5 以降に当たる。
（※） ソース変更は 2019-03-15。問題報告 #261 への対応だった。報告者のサンプルファイルによると #261 の原因は新メディア型ではないが、メディア型の問題。事実標準とは異なる application/octet-stream が使われており、それにプレーヤーが対応できなかった。
（※※） 何が proper mimetype
なのか明確でないことが、問題の核心。
この回避は、拡張子チェックによるものだが、大文字・小文字を区別してしまったため「.ttf なら良くても .TTF では駄目」といった制約あり。さらに .ttc にも対応できない。メディア型の本当のサポートは、2019-10-15 の v0.74.1-28 以降（「第2報」参照）。MPC-HC に関しては対応待ち。
2019-10-15 MPC-BE, LAV とも新標準対応のバイナリー（テスト版）が出そろった。内部的に LAV を使う MPC-HC の更新も時間の問題。どのバージョン以降で対応しているかについては、下記「第2報」参照。HC (clsid2) の次の正式版リリースは2019年12月以降か。
2019-10-12 [INFO] MKV「新仕様」の背景（第3報）
「壊れてないのに直すな！」という格言がある。フォント埋め込みMKVは、2004年に実験的に実装され、次第にサポートが充実、今ではクロスプラットフォーム（再生側のOSに依存しない形）での相互運用が当たり前。それがなぜ突然「仕様変更」なのか。古いプレーヤーが新しいMKVに対応できなくなり、未来のプレーヤーが古いMKVに対応できなくなるかもしれないのに…。
問題が生じた背景は、次の通り。
text/css とか image/png といった識別子を見たことある方は多いだろう。MIME Type は、文脈によっては Media Type とも呼ばれる（以下「メディア型」）。application/octet-stream などで一応間に合っていた。@font-face が標準化され、状況は急変。ブラウザにバックグランドでフォントをダウンロードさせ、特定フォントを使ってウェブページを表示させることが一般化した。ダウンロードさせるフォーマットも ttf/eot/woff などバラバラ。ブラウザから見ると「漠然と application/octet-stream と言われ、ダウンロードしてみたら未対応の形式だった」となれば時間の無駄だし、ページの表示も遅れ、帯域も浪費され、エンドユーザーから見ても迷惑。従って、フォーマットごとにフォントのメディア型を標準化する必要が生じ、多少の混乱もあったが、2017年には font/ttf や font/woff などの新しい型が公式に定義された。「公式な型がなかったのなら、今までMKVの添付フォントはどうなってたの。どうやって再生互換性が維持されてたの？」という疑問が生じるでしょうが、メディア型の仕様には「x- で始まるサブタイプは、プライベートで自由に使えるよ」という規定があって、
application/x-truetype-font
というプライベート型が、MKV に TTF を埋め込むときの事実標準となっていた（初期の実装において Haali/Gabest が採用した型）。でも Matroska は、誰でも自由に使えるオープンなフォーマット。仕様書で「ファイルのMIME型を指定する」と明記されている。新たにMKVを作るとき「今の公式な型は font/ttf だから、それを使おう」と考える人が出てきても、それを止められない。
結果として、もしプレーヤーが新旧両方のメディア型に対応していないと、未対応型フォントの字幕がデザイン通りに表示されず、困ったことになる。「フォントが違うだけで文字は読める」のなら実用上OKかもしれないが、場合によっては、字幕をオンにしても文字が表示されない。バグ報告・問い合わせが殺到し、多くの人の時間とエネルギーが浪費され、最悪、作成済みのMKVを全部作り直す羽目になる！ 大混乱が生じる前に、先手を打って対応しておきたい。
2種類のテスト用ファイルが doom9 の MKVToolNix スレの 2019-10-07/08 にあるので（※1）、MPC系/LAV利用/mpv以外で未対応のプレーヤーを発見したら（ZoomPlayerなどはLAV利用）、そのプレーヤーの開発者に対して、サポート追加を丁重にお願いしてほしい。新形式ファイルの登場による問題で、プレーヤー内部の不具合ではないので、バグ報告ではなく、新形式対応のリクエストという形で。「新形式といっても FileMimeType の文字列が違うだけで中身は同じ」という点を伝えてください。疑問点・問題点・コメントがあれば、上記スレや各プレーヤーのスレに書くと吉。動画作成者は、当面（少なくともプレーヤー側の対応が整うまで）古いメディア型を使い続けるのが無難（速報の「推奨」参照）。趣味で字幕やカラオケを作ってる友達がいたら、このことを教えてあげてください。
※1 テスト内容は、画面上部の文字（ハードサブ）と同じフォントで下の文字（ソフトサブ）を表示できるか。一つ目のサンプルの Test1～4 に合格すれば、そのプレーヤーは実用上ほぼOK。二つ目のサンプルの Test5 に合格すれば TTC 対応もOK。Test8 は「メディア型を本当にサポートしているか、拡張子に基づくその場しのぎのサポートか」を判別するもの。Test6/7 はWOFFサポートを試すものだが、WOFF埋め込みMKVは現在実際には使われていないので、6/7 の結果はどうでもいい（これに通るプレーヤーがあれば神）。
2019-10-10 [INFO] MKVの添付フォント・新仕様対応状況（第2報）
MPC-BE＝対応完了（世界初！）: 1.5.4.4799 において、font/ttf と font/otf と font/sfnt がサポートされた。コード更新は 2019-10-07、バイナリー公開は 2019-10-08。残りの2タイプについてサポート追加をリクエスト（2019-10-09）。同日1.5.4.4808 において、font/collection と application/font-sfnt も認識されるようになった。2019-10-10T08:30Z 現在バイナリー待ち。公開されたら動作確認する。〔追記: 同日午後バイナリー公開、テスト結果＝OK〕
LAV Filters＝TTC以外対応完了: 0.74.1-26 において、font/ttf と font/otf と font/sfnt と application/font-sfnt が認識されるようになった（font/collection は認識されない）。コード更新 2019-10-07、バイナリー公開 2019-10-09。font/collection のサポート追加についてはリクエスト済み。〔追記: 2019-10-14 TTCにも対応。2019-10-15 v0.74.1-28 バイナリー公開、テスト結果＝OK〕
MPC-HC（clsid2 build）: 新しい LAV Filters を取り込めば、自動的に同じ更新が反映される。現時点での最新版バイナリー（1.8.8.234）は、上記の LAV の更新より前にビルドされていて、font/ttf などを明示的にサポートしていない。「MPC-HC（非公式）では既に font/ttf などが認識される」と速報に記したが、拡張子が小文字の .ttf などである必要があり、それが .TTF に変わるだけで認識されなくなる…という危ういもの。順当にいけば、次の 1.8.9 では全部ちゃんと認識されるようになる。
アクティブに開発が続いている各プレーヤーについては、1～2カ月以内に、新標準に対応可能になるだろう。良いことだが、そうなると、今度は作成ツール側で「フォントを添付するとき、新標準の font/ メディア型を使おうかな…」となるのは必然。この変更を急ぎ過ぎると「新規作成した MKV が古いプレーヤーでは意図通りに再生されない」という混乱を招く。状況の背景・詳細については後日あらためて解説するが、今回の協調更新の趣旨は「新仕様のファイルが来ても再生できるように、先回りして準備」。「旧仕様の添付フォントのサポートをやめる」ということではない。「動画作成側がコマンドラインから明示的に新仕様を使う」または「作成ツールの添付フォント処理のデフォルトが変わる」のどちらかが起きない限り、当面、エンドユーザーには何の影響も生じない。
何らかの理由で古いプレーヤーを使い続けた場合、今から数年以内に「それまでは問題なかった字幕のフォントスタイルが正しく表示されないケース」が起こり得る。特殊な文字だと、最悪、表示が□や？や空白になってしまうかもしれない。そうした問題が起きたときには、あわてず、内部の Matroskaスプリッターをオフにして、外部の LAV を試してみよう。そうすれば、元祖 Gabest バージョンの MPC（約10年前）でさえ、新仕様の添付フォントを利用できる！
2019-10-07 [INFO] MKVにフォントを添付する場合: 新たに生じている問題点と対応（速報）
要約: TTFフォントを添付する場合、メディア型（いわゆるMIME）が font/ になるケースがある。これは2017年に定義されたウェブ標準のメディア型だが、多くのプレーヤーはまだこの型を認識できず、添付フォントがロードされないという不具合（字幕スタイルが壊れる）が生じる。
推奨: 当面、フォントを添付する場合、レガシーのメディア型を明示的に指定。コマンドラインの場合、TTF なら --attachment-mime-type application/x-truetype-font、OTF なら --attachment-mime-type application/vnd.ms-opentype （※注）。GUI の場合、mux前に、そうなっていることを確認する。
（※注） OTF については、TTF と同じメディア型 application/x-truetype-font でもロードされるらしい。
補足: (1) 非公式の新しい MPC-HC (clsid2 builds) なら、一定条件下で新しいメディア型の添付フォントもロードされるが、公式の MPC-HC や MPC-BE や LAV に依存するプレーヤーでは、現在、字幕が壊れる。MPC-BE と LAV については、次のバージョンから新しいメディア型がサポートされる見通し。
(2) MKVToolNix は、現在、TTF についてはデフォルトで application/x-truetype-font を使うように設計されていて、本来、明示的に指定する必要はないのだが、一部の環境では、2018年ごろから、意図通りにならないことがある。過渡期の混乱が生じているため、フォントを添付した場合、念のため、システムからそのフォントをアンインストールした状態で添付フォントがロードされるかテストした方がいい。万全を期すなら、フォントがキャッシュされている可能性を考慮し、再起動後にテスト。
(3) 添付ファイルの MIME は、MPC系なら [Shift]+[F10] の Resources タブでも確認できる。
(4) フォントのメディア型の標準化とその背景については、RFC 8081 参照。「どちらでも同じ」なら標準化された新しい型を使うべきだが、現在、プレーヤー側のサポートが追いついていないので、当面は古い MIME を使い続けるのが現実的。自分たちだけでなく Matroska の開発者も同意見。
![2016 = (28+28+28)×[28−(28+28+28+28)/28]](/image/2016/2016-28.png)
Map の長所、splice より速い要素挿入法も紹介。 〔最終更新: 2016年4月10日〕bdi 要素と Unicode 6.3 の新しい双方向アルゴリズム (2012-12-04)dir 属性は落とし穴が多い。HTML5 の <bdi> は役立つ。近い将来、「ユーザー入力欄などの語句は、このタグで隔離」が常識になるかも。 〔最終更新: 2014年4月27日〕
fad() は濁りやすい。各種の代替手段を紹介。msystem.waw.pl / videolan.org