MusicXMLで記述されたデータを楽譜として表示するには、五線や音符、アーティキュレーションを記号として描画する必要があります。 SMuFL(Standard Music Font Layout)はW3が管理するミュージックフォントの標準です。
MusicXMLについては楽譜のデジタル表現 - 1. MusicXMLをご覧ください。
SMuFLとは
SMuFLは、記譜に必要な数千種類の記号(五線・音部記号・音符・臨時記号・アーティキュレーション・打楽器ピクトグラムなど)を、フォントの中の決まった位置(コードポイント)に統一的に配置するための仕様です。 2013年にSteinberg社のDaniel Spreadbury氏によって、自社の記譜ソフトDoricoの開発の一環として発表されました。その後MusicXMLと同じくW3C Music Notation Community Groupの管理下に移り、現在に至ります。
SMuFL登場以前は、記譜ソフトごとに独自のフォントとグリフ配置を用いていたため、あるソフト用に作られた音楽フォントを別のソフトでそのまま使うことができませんでした。SMuFLはこの状況に対し、「どの記号がフォント内のどのコードポイントにあるべきか」という配置だけを標準化することで、異なるソフト・異なるフォントの間でも記号の互換性を持たせることを目的としています。実際にどんな見た目(書体)にするかはフォント制作者の裁量に委ねられており、標準化されているのはあくまで配置と命名だけです。
コードポイントとPrivate Use Area
SMuFLの記号は、UnicodeのPrivate Use Area(私用領域)のうちU+E000〜U+F8FFの範囲に割り当てられています。この範囲はUnicode規格上「どの文字を割り当てるかは実装者に委ねる」とされている領域で、SMuFLはここに音楽記号のための独自のマッピングを定義しています。 グリフの数が増えて基本領域に収まりきらなくなったため、SMuFL 1.3以降ではSupplementary Private Use Area-A(U+F0000〜U+FFFFD)にも一部のオプショナルなグリフが割り当てられるようになりました。 なお、Unicodeには古くから音楽記号専用の領域(Musical Symbols, U+1D100〜U+1D1FF)も存在しますが、こちらはグリフ数が少なく組版に必要な記号を網羅していないため、SMuFLでは基本的に前述のPrivate Use Areaを使用し、Musical Symbols領域に対応する文字がある場合のみ、後述するglyphnames.jsonのalternateCodepointとして参照関係を記録するにとどめています。
グリフ名(glyphnames.json)
glyphnames.jsonは、SMuFLが定義する各グリフに対して、コードポイントと人間にも読める標準名を対応付けるファイルです。名前はgClefやnoteheadBlack、accidentalSharpのようにlower camel caseで記述され、機能が分かりやすいように命名されています。 たとえば代表的なグリフには次のようなものがあります。
| グリフ名 | コードポイント | 内容 | |---|---|---| | gClef | U+E050 | ト音記号 | | cClef | U+E05C | ハ音記号 | | fClef | U+E062 | ヘ音記号 | | noteheadBlack | U+E0A4 | 黒玉符頭(四分音符以下の符頭) | | accidentalFlat | U+E260 | 変記号(♭) | | accidentalSharp | U+E262 | 嬰記号(#) | | barlineSingle | U+E030 | 単純小節線 |
各グリフにはdescription(説明文)も付与されており、コードポイントと名前と説明の3つ組がSMuFLにおけるグリフの一次情報になります。アプリケーションやフォント側は、この標準名とコードポイントの対応を守ることで、任意のSMuFL準拠フォントに差し替えても記号の位置がずれない互換性を得られます。
レンジとクラス(ranges.json / classes.json)
ranges.jsonは、数千個あるグリフを機能ごとにグループ化して整理するためのファイルです。各レンジは「識別子」「人間可読な説明」「含まれるグリフ名の一覧」「そのレンジのコードポイント範囲(rangestart/rangeend)」を持ちます。たとえば「Clefs(音部記号)」「Noteheads(符頭)」「Barlines(小節線)」「Individual notes(連桁のない単独の音符)」「Articulation(アーティキュレーション)」「Percussion pictograms(打楽器ピクトグラム)」など、130を超えるレンジが定義されています。 classes.jsonはこれとは別軸の分類で、「同じ振る舞いをするグリフの集合」を表します。たとえば「すべての符頭」「ステムと組み合わせて使えるグリフ」「オクターブ記号として使えるグリフ」のように、用途や特性でグリフを横断的にグループ化しており、記譜アプリケーションが「この位置に置けるグリフの候補」を検索する際などに利用されます。
フォント固有メタデータ(metadata.json)
ここまでのglyphnames.json・ranges.json・classes.jsonはSMuFL仕様そのものが提供する共通ファイルですが、これとは別に、SMuFL準拠フォントは自身のデザインに応じたmetadata.jsonを同梱することになっています。主な項目は次の通りです。
engravingDefaults: 五線の太さ(staffLineThickness)、符幹の太さ(stemThickness)、連桁の太さ(beamThickness)、加線の太さ(legerLineThickness)、クレッシェンド記号の太さ(hairpinThickness)など、そのフォントで前提とされている線の太さや間隔をまとめたものです。記譜ソフトはこの値を読み取ることで、フォントのデザインに合った線を自前で描画できます。glyphBBoxes: 各グリフの境界ボックス(左下bBoxSW・右上bBoxNE)をステーブスペース単位で定義します。フォントのグリフ送り幅(advance width)だけでは分からない、実際の描画範囲の把握に使われます。glyphsWithAnchors: 符頭とステムの接続点(stemUpSE/stemDownNW)や、符頭の基準点(noteheadOrigin)、視覚的重心(opticalCenter)、装飾小音符の斜線の接続点(graceNoteSlashSW/graceNoteSlashNE)など、グリフ同士を正しい位置で組み合わせるための「アンカーポイント」を定義します。glyphsWithAlternatesとsets: 同じ役割を持つ複数の見た目のバリエーション(代替グリフ)を定義します。glyphsWithAlternatesは個々のグリフ単位の代替候補、setsは複数のグリフをまとめて一貫したスタイルで切り替えるための代替セット(たとえば拍子記号の数字を別デザインに統一して差し替える、など)です。ligatures: 複数の標準グリフを組み合わせるより見た目良く配置できる合字グリフを定義します。optionalGlyphs: SMuFLの推奨グリフセットには含まれないものの、そのフォート固有の追加記号として、前述のSupplementary Private Use Areaなどに配置されるグリフです。
実装フォント
SMuFL準拠フォントとしては、仕様の策定と同時にSteinbergが公開したリファレンス実装であるBravura(SIL Open Font Licenseで無償公開)が代表的です。ほかにも、手書き風書体のPetaluma(Steinberg)、MuseScore 4の既定フォントであるLeland、ジャズ譜面向けの手書き風フォントMuseJazz、LilyPondのEmmentaler、Robert Piéchaud氏によるNovemberなど、複数の記譜ソフトやフォント制作者がSMuFL準拠フォントを提供しています。いずれのフォントも、前述のコードポイント配置さえ守っていれば、同じMusicXML/MNXデータを異なる書体で描画し分けることができます。
バージョン履歴
- 0.4(2013年5月): Steinbergによる最初の公開版。約800個のグリフを定義。
- 0.5〜0.9(2013-2014): 急速な拡張が続き、0.7時点で1850個以上のグリフを定義。0.8では大幅なコードポイントの見直しが行われた。
- 1.0(2014): 既存グリフのコードポイントとグリフ名が以降変更されないことが保証され、仕様として安定。
- 1.2: 既存グリフのコードポイント・正式名を変更しないマイナーアップデート。
- 1.3: 管理元がSteinbergからW3C Music Notation Community Groupへ移管されて最初のリリース。
- 1.4(2021年3月): 新規に5レンジ・150個以上のグリフを追加。また、音楽フォントと組み合わせて使う欧文フォントをCSSのフォント指定構文で指定できるよう、フォント固有メタデータの仕様を拡張。
- 1.5: 現在ドラフトとして仕様策定が進行中。
まとめ
SMuFLは「どの記号がフォント内のどこにあるべきか」というコードポイントの配置だけを標準化し、実際の書体デザインはフォント制作者に委ねるという設計になっています。共通ファイルであるglyphnames.json/ranges.json/classes.jsonでグリフの意味と分類を定義し、各フォントが個別に持つmetadata.jsonで線の太さやアンカーポイントといった描画に必要な数値情報を補う、という役割分担を理解しておくと、Bravuraなど個々のSMuFLフォントの仕様書も読み解きやすくなります。 MusicXMLが記譜データそのものの構造を定義する仕様であるのに対し、SMuFLはそのデータを実際に画面やページ上へ記号として描画する際のフォント側の約束事を定める仕様、という関係になっています。