doubledepth

WHATWG HTML仕様書の例からいくつか抜粋

<dl>
  <dt>♥
  <dd>Heart
  <dd>Cœur
  <dt>☘
  <dd>Shamrock
  <dd>Trèfle
  <dt>✶
  <dd>Star
  <dd>Étoile
</dl>

<ruby>
  <rb>♥</rb>
  <rtc>Heart</rtc>
  <rtc>Cœur</rtc>
  <rb>☘</rb>
  <rtc>Shamrock</rtc>
  <rtc>Trèfle</rtc>
  <rb>✶</rb>
  <rtc>Star</rtc>
  <rtc>Étoile</rtc>
</ruby>

<ruby style="ruby-position: under;"
  ><ruby style="ruby-position: over;"
    >東<rt>とう</rt>南<rt>なん</rt
  ></ruby
  ><rt>たつみ</rt
></ruby>の方角

<ruby
  ><ruby
    ><ruby
      ><ruby
        >東<rt>とう</rt>南<rt>なん</rt
      ></ruby
      ><rt>たつみ</rt
    ></ruby
    ><rt lang="zh-Latn">dōngnán</rt
  ></ruby
  ><rt lang="en">Southeast</rt
></ruby>

<ruby
  ><ruby
    >東<rt>とう</rt><rt lang="zh-Latn">dōng</rt
    >南<rt>なん</rt><rt lang="zh-Latn">nán</rt
  ></ruby
  ><rt>たつみ</rt><rt lang="en">Southeast</rt
></ruby>

<ruby>
  <rb>東</rb><rb>南</rb><rp>（</rp>
  <rtc><rt>とう</rt><rt>なん</rt></rtc><rp>、</rp>
  <rtc>たつみ</rtc><rp>、</rp>
  <rtc lang="zh-Latn"><rt>dōng</rt><rt>nán</rt></rtc><rp>, </rp>
  <rtc lang="en">Southeast</rtc><rp>）</rp>
</ruby>

陸上自衛隊信（しの）太（だ）山（やま）駐屯地（和泉市）

機械翻訳も読み上げも意味不明にしかならない旧式ruby要素は、font要素よりも性質が悪い。

信（しの）太（だ）山（やま） (WHATWG HTML Mono-Ruby)

<ruby
  >信<rp>（</rp><rt>しの</rt><rp>）</rp
  >太<rp>（</rp><rt>だ</rt><rp>）</rp
  >山<rp>（</rp><rt>やま</rt><rp>）</rp
></ruby>

信太山（しのだやま） (W3C HTML5 Jukugo-Ruby)

<ruby
  ><rb>信</rb><rb>太</rb><rb>山</rb><rp>（</rp><rtc
  ><rt>しの</rt><rt>だ</rt><rt>やま</rt></rtc><rp>）</rp
></ruby>

いつぞやのスラドの悲観的なcommentに引きずられて忘れていたが、私はMicrosoft Edgeが機能の追加や改善に関する要望を受け付けていることを思い出した。もしMicrosoft Edgeが“rb/rtc elements”や“CSS Ruby”を実装すれば、「2つ以上の相互運用可能な実装」という条件は満たされる。

『地獄変』（芥川龍之介）の最初の一文

堀川の大殿様（おほとのさま）のやうな方は、これまでは固（もと）より、後の世には恐らく二人とはいらつしやいますまい。

screen readerによる発話結果はお察しの通り。このtextをまともに読み上げられるようにしたい。

W3C HTML5 double-sided Ruby (Ruby-Base includes nested ruby)

<style> .test20150619 rb { speak: none; } </style>
<ruby class="test20150619"
  ><rb>堀川</rb><rb>の</rb
  ><rb><ruby><rb>大殿様</rb><rp>（</rp><rt>おほとのさま</rt><rp>）</rp></ruby></rb
  ><rb>の</rb><rb>やう</rb><rb>な</rb><rb>方</rb><rb>は、これまでは</rb
  ><rb><ruby><rb>固</rb><rp>（</rp><rt>もと</rt><rp>）</rp></ruby></rb
  ><rb>より、</rb><rb>後</rb><rb>の</rb><rb>世</rb><rb>には</rb
  ><rb>恐</rb><rb>らく</rb><rb>二人</rb><rb>とは</rb><rb>いらつしやいますまい</rb><rb>。</rb
  ><rp>（</rp
  ><rtc style="ruby-position: under;"
    ><rt>ほりかわ</rt><rt>の</rt
    ><rt>おおとのさま</rt
    ><rt>の</rt><rt>よう</rt><rt>な</rt><rt>かた</rt><rt>は、これまでは</rt
    ><rt>もと</rt
    ><rt>より、</rt><rt>のち</rt><rt>の</rt><rt>よ</rt><rt>には</rt
    ><rt>おそ</rt><rt>らく</rt><rt>ふたり</rt><rt>とは</rt><rt>いらっしゃいますまい</rt><rt>。</rt
  ></rtc
  ><rp>）</rp
></ruby>

Firefox 38+

Internet Explorer 11

下段Ruby-Textのみを発話させる発想。実際は「おおとのさまのようなかた『ha』」と読み上げられる場合も。この方法の問題点は、CSS Ruby Autohidingにとって試練すぎる・記述量が増えすぎる・原文の改竄疑惑など。W3C HTML5 Rubyも普通に入れ子にできるようだが、CSSを外すと入れ子のRuby-Textの一部が重なる点には注意すべきかもしれない（たとえば、）。

あるいは、aria-labelやaria-labelledbyを使うべきだろうか？　しかしaria-label単独では、NVDAに対して何の効果も及ぼさなかった。私の使い方が間違っているのかもしれない。

role="img"と組み合わせれば、うまくいく（場合もある）。画像ではないのが問題ではある。

堀川の
<ruby role="img" aria-label="おおとのさま"><rb>大殿様</rb><rp>（</rp><rt>おほとのさま</rt><rp>）</rp></ruby>
の
<span role="img" aria-label="ようなかた">やうな方</span>
は、これまでは
<ruby role="img" aria-label="もと"><rb>固</rb><rp>（</rp><rt>もと</rt><rp>）</rp></ruby>
より、
<span role="img" aria-label="のち">後</span>
の世には恐らく二人とは
<span role="img" aria-label="いらっしゃいますまい">いらつしやいますまい</span>
。 <!-- Actual condition has to be written without newlines to stop unnecessary whitespace -->

原文の改竄を極力避けるなら、読み上げ専用の別項を作成し、aria-labelledbyを用いて都度参照するしかなさそうだ。W3C HTML5 Rubyによる全文ふりがな書き下ろしよりは、機械的に作成しやすそうではある。

「堀川の大殿様」とは、藤原基経 （ふじわらのもとつね）と推測されている。姓と名の間の、どこから出てきたのかよくわからない「の」を、W3C HTML5 Rubyは「空のrb要素」に当てて表現できる。

<ruby
  ><rb>藤原</rb><rb></rb><rb>基経</rb>
  <rp>（</rp
  ><rtc
    ><rt>ふじわら</rt><rt>の</rt><rt>もとつね</rt
  ></rtc
  ><rp>）</rp
></ruby>

『カエルの死』（夢枕獏）のような作品を電子書籍はいつか扱えるようになるだろうか。いや全頁SVG wrappingとかはもうできるだろうけど、そういうことではなく。

原稿用紙ぶち抜き方式(Group-Ruby)（半角英数字Ruby-Text）

<ruby>原稿用紙ぶち抜き方式<rp>(</rp><rt>Group-Ruby</rt><rp>)</rp></ruby>

ChromeやFirefoxなどで、このRubyは『原稿用』+『紙ぶち抜(Group-Ruby)』+『き方式』と見分けがつかない。Internet Explorerのように、半角英数字のRuby-Textに対しても均等割り付けや両端揃えが行われるなら、著者が特別な工夫をする必要はないのだが、残念ながらそうではないので、Ruby範囲明示用のworkaroundを考える。

• Ruby-Textを全角英数字に変更しても、ChromeやFirefoxでは効果なし。
• background-colorの変更は鬱陶しいうえに、誤解を与える見た目が解消されない。
• CSS4 element()関数でrt要素を画像化して、CSS3 object-fitを適用しようと試みたが、うまくいかなかった。
• Ruby-Textを一文字ずつspan要素で区切って疑似要素で空白を生成したが、やはり読み上げ時に英単語が分断されてしまった。
• letter-spacingは唯一まともに使えそうだが、最適値はRuby-Box sizeに依存するので、JavaScriptなしでの微調整は非現実的。

<ruby>原稿用紙ぶち抜き方式<rp>(</rp
  ><rt><span style="letter-spacing: 1.4em;">Group-Rub</span>y</rt
><rp>)</rp></ruby>

原稿用紙ぶち抜き方式(Group-Ruby)。Ruby-Textの内容だけを変えると: 原稿用紙ぶち抜き方式(Ruby)。Oh…

Ruby-Textの読み上げ制御

振り仮名などを読み上げられたくない場合は、Ruby-Textにaria-hidden="true"を指定すればだいたい効く。CSS Speech Module “speak: none;”は実装がまだ無いが、これが使えればRuby-Textにとっては非常に助かる。以下の検証はWindows 8.1 + [Firefox 38, Iron 43, IE11] + NVDA 2015.2jpによる。

rt要素へのaria-hidden適用例1: 原（M）稿（o）用（n）紙（o）の（-）升（R）目（u）方（b）式（y）

<ruby
  >原<rp>（</rp><rt aria-hidden="true">M</rt><rp>）</rp
  >稿<rp>（</rp><rt aria-hidden="true">o</rt><rp>）</rp
  >用<rp>（</rp><rt aria-hidden="true">n</rt><rp>）</rp
  >紙<rp>（</rp><rt aria-hidden="true">o</rt><rp>）</rp
  >の<rp>（</rp><rt aria-hidden="true">-</rt><rp>）</rp
  >升<rp>（</rp><rt aria-hidden="true">R</rt><rp>）</rp
  >目<rp>（</rp><rt aria-hidden="true">u</rt><rp>）</rp
  >方<rp>（</rp><rt aria-hidden="true">b</rt><rp>）</rp
  >式<rp>（</rp><rt aria-hidden="true">y</rt><rp>）</rp
></ruby>

読み上げ結果: 「はら」「こう」「よう」「かみ」「の」「ます」「め」「ほう」「しき」。読み上げを抑止できてはいるが、一文字読み上げるつど文字送り操作を要求される。これは論外。

rt要素へのaria-hidden適用例2: 原稿用紙ぶち抜き方式（Group-Ruby）

<ruby>原稿用紙ぶち抜き方式<rp>（</rp><rt aria-hidden="true">Group-Ruby</rt><rp>）</rp></ruby>

読み上げ結果: 「げんこうようしぶちぬきほうしき」。IE11:

rt要素へのCSS Speech Module適用例: 見よ（読むな）

<ruby>見よ<rp>（</rp><rt style="speak: none;">読むな</rt><rp>）</rp></ruby>

読み上げ結果: Firefoxでは「みよよむな」、IEでは「みよ」「よむな」、Blinkでは「よむな」「みよ」。基本的にrt要素の読み上げを全部禁止して、一部のみdata-must-speak="true"なりaria-hidden="false"なりで選り分けて発話させる方式が使えるなら、既存文書への書き換えは最低限で済みそう。

ああ、でも、そもそもCSSが無効の場合は意味がないのか……。確実性ではrt要素全部にaria-hiddenを付与する方式に軍配が上がる。

というかaria-hidden="false"はなるべく使わないでね、的なことが仕様書に書いてある。なんぞ。

rtc要素を用いるW3C HTML5 Rubyの例: 原稿用紙の升目方式 (Mono-Ruby)

<ruby
  ><rb>原</rb><rb>稿</rb><rb>用</rb><rb>紙</rb><rb>の</rb><rb>升</rb><rb>目</rb><rb>方</rb><rb>式</rb>
  <rtc><rt>M</rt><rt>o</rt><rt>n</rt><rt>o</rt><rt>-</rt><rt>R</rt><rt>u</rt><rt>b</rt><rt>y</rt></rtc
></ruby>

読み上げ結果: 「げんこうようしのますめほうしきモーノーマイナスルービー」。IE11 + NVDAでは、preview時は期待通りに読み上げられるが、全文読み上げ時は「はら、こう、よう、かみ……」「エム、オー、エヌ、オー……」。Ruby-Textの読み上げを抑止する場合はrtc要素のaria-hiddenをいじる。

本来なら強引にtextを分断せずとも済むはずだが、「半角英数字の均等割り付け・両端揃え」は鬼門。

<ruby style="ruby-align: start;"> (case Left-to-Right)

……Ruby-BaseとRuby-Textは、textの書字方向開始側に寄せられる。

<ruby style="ruby-align: center;">

……Ruby-BaseとRuby-Textは、Ruby-Boxのinline-sizeを基準として中央に寄せられる。

<ruby style="ruby-align: space-between;">

……Ruby-BaseとRuby-Textは、Ruby-Boxのinline-sizeを基準として、両端に揃えられたうえで均等に割り付けられる。ただし半角英数字は空白によってのみ調整される。“G r o u p - R u b y”のように空白やtabを挟めば、見た目上は両端が揃う。

<ruby style="ruby-align: space-around;"> (Firefox 38's default)

……Ruby-BaseとRuby-Textは、Ruby-Boxのinline-sizeを基準として均等に割り付けられる。ただし半角英数字は空白によってのみ調整される。空白によって見た目上均等に割り付けたとしても、読み上げや機械翻訳はうまくいかなくなる。

𒂊𒉡𒈠𒂊𒇺〜 (天地乖離す開闢の星〜)

Ruby-Textに画像などを挟むことによって、Firefox 38+にRuby Autohidingを適用させつつ、機械用に別の内容を出し分けることができる。これができて嬉しい状況というのは特には思いつかない。

Windows版BlinkはFontLinkをsupportしない。Web page側が書体を指定しないと、ある文字を表示できる書体がComputerに導入されていたとしても、それを用いない場合がある。見出しから書体指定を外すと: 𒂊𒉡𒈠𒂊𒇺

OSを問わず・確実にuserに書体を持たせて・確実に文字を表示するためには、たしかにWeb fontsに頼る以外に手がなさそうではある。そのためにはFontLinkに依存するべきでないことも、理解はできる。

Κενότητος ἀστράπσατω δὲ τεμέτω！(来れ　虚空の雷　薙ぎ払え！)

Firefox 38+において“Autohiding Base-identical Annotations”は“browsers’ default stylesheets”に準ずる扱いであることがわかった。CSSが剥がれても重複内容は隠される。ということは、これは見出しが大きく表示されるのと同じように、「当たり前であるべき外観」なのだろう（すくなくともFirefoxの場合は）。

Autohidingはおもに振り仮名にとって有益だが、別の活用法もありそうだ。本節見出しのRuby-Text末尾は、screen reader, translator, browsersなどの機械には「薙ぎ払え！」として見えている。もはや役割を終えつつあるrp要素の代わりに、形態素解析器に対する分離符としてこれら約物を使えないだろうか。

Autohiding is effective:

<rb>δὲ τεμέτω</rb><rb>！</rb>
<rt>薙ぎ払え</rt><rt>！</rt>

<rb>δὲ τεμέτω</rb><rb>！</rb>
<rt>薙ぎ払え</rt><rt><mark>&#xFF01;</mark></rt>

<rb>δὲ τεμέτω</rb><rb>!</rb>
<rt>薙ぎ払え</rt><rt><mark style="text-transform: full-width;">!</mark></rt>

<rb>δὲ τεμέτω</rb><rb>！</rb>
<rt>薙ぎ払え</rt><rt><mark><object
    data="img/1F422.png" type="image/png" typemustmatch="typemustmatch"
  >&#xFF01;</object></mark></rt>

[Blink/WebKit, Edge/Trident]

Autohiding is not effective:

<rb>δὲ τεμέτω</rb><rb>!</rb>
<rt>薙ぎ払え</rt><rt>！</rt>

<rb>δὲ τεμέτω</rb><rb>！</rb>
<rt>薙ぎ払え</rt><rt><mark style="text-transform: full-width;">!</mark></rt>

<rb>δὲ τεμέτω</rb><rb>！</rb>
<rt>薙ぎ払え</rt><rt><mark><img src="img/1F422.png" alt="&#xFF01;" /></mark></rt>

[Firefox 38+]

半角と全角は区別される。Attribute nodeなどの値は比較されない。間に他の要素が挟まっても構わない。最後が多少問題で、いわゆるreplaced inline-level elementsが提供する代替内容はbrowserに依存する。object要素を挟んで内容を選択してcopyしたとき、Blink系では感嘆符がclipboardに入らない。

CSS text-transformによる全角化は、いまのところFirefoxしかsupportしていないが、欧文書体と和文書体を往復するうえで便利と思われる。縦書きと横書きを往復する際も便利かもしれない。

“Κενότητος”にRuby-Textとして「来れ （きたれ）」が当たっているが、“Κενότητος”に意味論上対応する語は「虚空」なので、<ruby>Κενότητος<rt>来れ</ruby>と書くのはなんとなくためらわれる。そこで閉じたらまずくない？　rtc要素によって「塊としての対応関係」を示せるW3C HTML5のほうが、うしろめたさは減る。

rtc要素の直下にRuby-Textを書くと、Ruby-Textが列をまたぐことができる

<ruby
  ><rb>流離</rb><rb>の</rb><rb>大俳人</rb>
  <rp>（</rp
  ><rtc
    ><rt>さすらい</rt><rt>の</rt><rt>だいはいじん</rt
  ></rtc>
  <rp>／</rp>
  <rtc style="ruby-position: under;">グレイトハイカー</rtc
  ><rp>）</rp
></ruby>

Firefox 38+では両面rubyが表示される。W3C HTML5 RubyをsupportしないBlink/WebKit/Edge/Tridentに対しても、そのまま読み上げたり翻訳できるような形でtextが提供される。整形しなくても普通に読める点が重要。

Bopomofo/Furigana/Pinyin類のRuby Annotationが機械処理できないとなると、漢字文化圏にとって相当まずいような気がするが、日本人作家などもWHATWG HTML仕様を支持しているのが、よくわからない。Blinkの中の人にとっては技術的に解決できる問題なのだろうか。あるいはMathMLをMathJaxに丸投げするような感じか。

HTML5 でのルビのスタイル(CSS 2.1 のみで) - CSS小技集

これは凄い！　W3C HTML5 Rubyを、Blink/WebKit/Edge/Tridentに対して、Well-formed textのまま提供できる！　ただしこれを導入した頁では、WHATWG HTMLのRuby記法は一部使えなくなる。常にrb/rtc要素を使うようにすれば、ほぼ問題ない。

CSS Rubyの「送り仮名を自動で隠す機能」や、前節のグレイトハイカーの例のような「列をまたぐ両面Ruby」は、著者の期待通りには表示されなくなる。これはFirefox 38+をFeature Queriesで除外すれば解決する。

@supports not ( ruby-position: under ) {
  /* ここに「HTML5 でのルビのスタイル(CSS 2.1 のみで)」を書く */
}

IE11は縦書き厳禁。これはまあ、仕方ない。

いやあ、私にとっての最適解が出せてすっきりした。来月からこのCSSをお借りする予定。

返信

ここは御長寿なインターネットですね（界隈でトップクラスに）

Σ

ruby_enabler2.js test

“W3C HTML5 Ruby”と“WHATWG HTML Ruby”の折衷を試みるJavaScript。application/xhtml+xmlの頁で使う場合は、script内の大文字HTML要素関連を全部小文字に置換しておかないと動かない。

う〜ん。形態素解析可能だった塊よ、さらば。次の検証。

見た目を統一してくれるのはありがたい。頁内に#sidebarが存在しないにもかかわらずwindow.sidebarが存在し、かつ(RegExp.prototype.source.length < 1)が偽なら、おそらくFirefox 38+なので除外するように改造した。しかし結局まだ使わずに様子を見ることにした。

続・WHATWG HTML Living Standard仕様にはrb要素もrtc要素も無かった

スラドの要約がわかりやすかった。私の記憶が確かなら、日本のいくつかの出版社はRequirements for Japanese Text Layoutや関連仕様の策定のために既に数千万円を投じていたはずだし（明確なsourceが見つからない。昔読んだ関係者の日記などから、私が記憶を捏造した可能性もある。すみません）、多言語組版研究会を見る限り韓国や台湾も無関係ではない。WHATWG版では、Rubyの位置指定や、機械処理しやすいtextなどが断念される:

ruby-position: over;

Column	1	2	3	4
Ruby-Text	ふ	り	が	な
Ruby-Base	振	り	仮	名

For Blink/WebKit/Edge/Trident: 『振(ふ)り仮名(がな)』 (Plain text: 『振ふり仮名がな』)

ruby-position: under; (I do not have enough knowledge, so this example may be inaccurate)

Column	1	2	3	4
Ruby-Base	汉	语	拼	音
Ruby-Text	hàn	yǔ	pīn	yīn

For Blink/WebKit/Edge/Trident: 『汉(hàn)语(yǔ)拼(pīn)音(yīn)』 (Plain text: 『汉hàn语yǔ拼pīn音yīn』)

ruby-position: inter-character; (I do not have enough knowledge, so this example may be inaccurate)

1		2		3		4
注	ㄓ ˋ ㄨ	音	ㄧ ㄣ	符	ㄈ ˊ ㄨ	號	ㄏ ˋ ㄠ
rb	rt	rb	rt	rb	rt	rb	rt

For Blink/WebKit/Edge/Trident: 『注(ㄓㄨˋ)音(ㄧㄣ)符(ㄈㄨˊ)號(ㄏㄠˋ)』 (Plain text: 『注ㄓㄨˋ音ㄧㄣ符ㄈㄨˊ號ㄏㄠˋ』)

translatorやscreen readerは、振り仮名と当て字を区別できるだろうか。『全て遠き理想郷（アヴァロン）』ならtextを全部処理し、『全（すべ）て遠（とお）き理（り）想（そう）郷（きょう）』ならRuby-Textだけ捨てる、などの器用な処理を期待できるだろうか。できない。

文節の影に過ぎない振り仮名はそもそもtextにするべきではなかったのかもしれないが、Internet Explorer 5の「見えるものはtextとして書く」という方針が間違っていたわけでもないし、その発展形としてはW3C版Rubyが正しい。しかしWHATWGは別の正しさを持つ。結局どうすれば良いのか？

ruby要素は当て字に限定する。振り仮名は使わない。振り仮名を属性値に押し込めて、疑似要素にdisplay:xxxを当てて凌ぐ方法もあるが、「不撓不屈」が疑似要素ごと「ふふ たわわとう ふふ かがむくつ」などと読み上げられる場合もあり、結局WHATWGのRubyと大差ない気がする。一文字ずつ画像化するのも馬鹿馬鹿しい。

いや、そんな自重をしたところで、将来「ruby関連要素はfont要素と大差ないし、機械処理の精度を下げるからdeprecated」とか言われたらお終いだ。それはそれで正しい、W3CのHTML5 Rubyでも“not well-formed text”は書けてしまうわけだし。私はそんなことを気にせず一人でCSS Rubyを使い続ければ良いのだ。

先日の訂正

青空文庫は「傍点・傍線」という形で圏点用構文を持っていた。私は事実を誤認していた。失礼しました。青空文庫の圏点は背景画像のrepeatによって実現される（私も真似た）。この方法は成立条件がきわめて限定される:

• 等幅書体に限られる。Proportional typeface, たとえば「ＭＳ Ｐゴシック」の場合、平仮名カタカナへの圏点がどんどんずれていく。
• 書体が異なると、圏点がずれる。
• 頁翻訳などによって、圏点がずれる。
• 文字のsizeのみが拡大縮小されると、圏点がずれる。
• 解像度が異なる環境に追従しきれない。
• 背景色が白以外のとき、圏点が背景に馴染まない。
• 書字方向が異なると、圏点がずれる。青空文庫を縦書きで読めるapplicationは、適宜合わせてくれる場合が多いけれど。

青空文庫で使える圏点の種類はCSS圏点とほぼ一致している。これは将来の移行を見据えたもの（おそらく）。前述の問題を解決する方法はあるが、rubyによる圏点はscreen readerを門前払いにするし、-webkit-先行実装はIE/Firefoxを門前払いにするので、背景画像による圏点がworkaroundとしては最良だろう。

WHATWG HTML Living Standard仕様にはrb要素もrtc要素も無かった

そんなー

返信

「BMS名鑑」でググったらこんなん出ました。 （１２月３１日（水）のとこ）

初々しいというか若々しいというかテンション高いというか、

まあそれらは置いといて今さらになって興味深く拝読いたしました。

※あえてこっちにはレス不要つけない

お読みいただきありがとうございました……　私は最初の二行を見てそっとtabを閉じたことにしました……

人力入力型databaseはInternet Rankingの台頭によって廃れましたが、Artists一覧から掘っていけるBMS名鑑の便利さは他所にはありませんでした。なんというかHTML化して遺跡化したい気持ちがありました。幸いBMS名鑑はLR2IRと異なりInternet Archiveにindexされていたので、「私の記憶も消えた」は盛り過ぎでした。

余談ですが、選曲画面がそのままdatabase状になっているWeb BMS Playerがあります。“Bemuse”がInternet Ranking機能を手に入れれば、私たちはBemuseを第三のBMS event会場として用いることさえできるでしょう。

振り仮名（ふりがな）

<ruby
  ><rb>振</rb><rb>り</rb><rb>仮</rb><rb>名</rb><rp>（</rp
  ><rt>ふ</rt><rt>り</rt><rt>が</rt><rt>な</rt><rp>）</rp
></ruby>

Ruby-Baseに対応するRuby-Textの内容が同一のとき、正しいCSS Ruby実装はRuby-Textを表示しない。現時点ではFirefox 38+だけが実装済み。(Autohiding Base-identical Annotations // Typo: <ruby>…<ruby>, Correct: <ruby>…</ruby>)

以下の例は主要な全browserで望ましい表示になるが、screen readerに「ふふりがながな」と読み上げられる。

<ruby>振<rt>ふ</ruby>り<ruby>仮名<rt>がな</ruby>

実際は正しいからといって普通に使っていけるわけでもないので、chicken gameに参加している気分にさせられる。Firefox 1.0は-moz-border-radiusを知っていたが (WD-css3-border-20021107)、十年前の状況では3行3列の表組みが現実解だった。なお当時の私はbrowserという単語すら知らなかった。

Blink/WebKitは本物の圏点を使えるという強みもある。これを“<ruby>圏点<rt>●●</ruby>”などと書くと将来的に自分の首を絞めることは明白なので、私としてはCSS圏点（1999年1月27日提案、現在勧告候補）を使っていきたい。とはいえ平文投稿しか選択肢がない場合は変換器の問題になってしまう。一般的な明示的ruby構文の場合、たとえば『霧の｜ロンドン警視庁《スコットランドヤード》』が『霧のロンドン警視庁(スコットランドヤード)』になる。圏点のための構文は無いので『圏点《●●》』と書くしかない。自分でHTMLを手打ちすれば、変換器の制約からは自由になれる。

BMS名鑑

Early BMS snapshotというか、1998–2003年頃の日本のBMSは殆ど網羅されていたような印象がある。海向こうの方も数人見える。MixWaver作者氏などは当時も知られていたはずだが、載っていない。推測だが、「日本のBMS Review siteへの投稿経験」が暗黙の掲載基準だったかもしれない（すくなくともkommy氏は見かけた）。

Artists一覧は今もなお検索の手掛りを教えてくれる。usersによる追加図表が載っていないのも良い。誰でも編集できた結果としてSPAMの餌食になった。ような気がするが、私は別のsiteと勘違いしているかもしれない。2003年頃からはnazoIRが名鑑の役割を兼ねるようになったようだが、よく知らない。

別の資料“BMS HISTORY”は月単位でBMSを整理していた。これはMurak氏個人による手打ち文書であり、立ち位置は今でいうBMSChanに近い。重要な仕事だが、一部頁はInternet Archiveにおいて文字化けの憂き目に遭い、二度と読めなくなってしまった。『BMSの歴史本』が最後の砦だ。

CSS Ruby仕様書の例を見て不思議な気分になった。

BMS楽曲に対する改竄

垂直移動を禁止するだけでは、愚かな私にとって十分ではなかった。水平移動のみを許可する選択肢こそ必要だったのだが、それさえ安全ではなかった。楽曲記述部と図表記述部を分離できれば、「図表編集における、楽曲への改竄」は防げる。しかし「意図された曲変更における、意図せざる改竄」までは防げない。

公開された図表を著者が改訂したい場合は？　IR参加者を万全に誘導できるなら、修正を躊躇う理由はない。本来ならarcade版で新作が出る時のように、IRも定期的にsweepされてよいのだが、LR2IRが日本BMS sceneの記憶をも丸ごと背負っている現状では、そう短絡的にもなれない。BMS名鑑が消えたとき、私の記憶も消えた。

4月下旬に頁題が“(During the test)”だった某所を、役割の分散という観点から注視している。IRが相対的に軽くなれば、図表の改訂を気にする必要もなくなるかもしれない。

Bemuse v1.0.0-beta.11 — Custom BMS now supported (May 18, 2015)

(6月4日にはbeta.12が公開されたが) Userのlocal PC上にある7keys-BMSを演奏することが可能になっている。

Blink系列(Google Chrome, SRWare Iron, Opera, Vivaldi, etc.)およびWebKit系列(Apple Safari)では、解説頁の画像のようにBMS folderをdrag-and-dropすることによって、対象BMSが選曲可能になる。

Gecko系列(Mozilla Firefox)の場合は、BMS folderではなく、「BMS folderの中身」をすべて選択してdrag-and-dropすることによって、対象BMSが選曲可能になる。

5-Keys BMS, DPBMS, 9-Buttons PMSはsupportされない（supportされる見込みも薄い）。実質的にBemuseは7-Keys BMS専用で、これはBemuseが全図表に対してO2jam型(S D F ␣ J K L)とLR2型(Z S X D C F V)を両立させるために課さざるを得ない制限だ（space barを中央に置くことを最優先しているともいえる）。“Keyboard Mode”においてturntable laneがBGMに変わる仕様もあり、「鍵盤が存在しない7-Keys図表」などは歌listに出現しえない。効率は良い。

v1.0.0-beta.16: 5-keys BMS support (on Aug 4, 2015)

“BMS Support in Bemuse”には、BMSの特徴に関するsupport状況が書かれている。

“Running Your Own Music Server”には、現在のBemuseの歌listのような“Web 7keys-BMS package”を、あなた自身の音楽server上に構築するための方法が書かれている。どこでも遊べるcross-platform BMS collection!

Horizontal scrollbar vs. me

無限にzoomできるbrowserが存在するので必ず負ける。monitor/canvasはいつかcontentsに合わせて広がってくれるようになるのだろうか。HoloLensに期待する。

editors.html微改訂

BM98k, BMSC, DDR 0.50 beta4.2未満において、使用可能なObjectsはBPM変更やBGAなどもひっくるめて10000個が上限だった。BMSEで[01–FF]を図表に課している著者でさえ、それをもはや気にしてはいないだろう。古い機種が実際にtestできなくなった時点で、この種の豆知識は失伝するに違いない。

拡張子部分に大文字が混じっている図表fileをiBMSCは開くことができない。iBMSCが開く図表は、拡張子が厳密に“*.bms, *.bme, *.bml, *.pms, *.txt”のいずれかでなければならない。“FOON.BMS”とか反応しない。

BMSCで「設定→オプション」からViewerを「追加」しようとすると、BMCreate.exeの同位にExApps.cfgなるtext fileが生成される。この内容を変更することによって、複数のViewerを切り替えられる。例:

uBMplay
D:\ubmplay\uBMplay.exe
-P -N0 [filename]
-P -N[note#] [filename]
-S

BMS Viewer
bmview.exe
-B -A -S -P -N0 [filename]
-B -A -S -P -N[note#] [filename]
-S

Windows XP SP3では相対pathも指定できていたが、Windows 8.1ではfull pathを指定する必要があるようだ。あるいはpathとして“uBMplay.exe”のみを指定し、BMCreate.exeの同位にuBMplay.exeを置く必要が。

私はITK氏によるExApps.cfgを発見した。私のbmse_viewer.iniと酷似していてsympathyを感じた。

Editorについて全然書いていなかった

書いておかないと忘れそうなことを思い出そうと努力している。BMSC/BMSE/iBMSCは英語localeを持つ。GDAC2公式siteのdtx_dtxv.zip(06/05/23)は英語版Lane script filesを含むが、それらはBMS用ではない。

「BM98で演奏できる図表」は今も書かれており、最も新しい例は『第二回なんちゃって無名作家が物申す！』にいくつか見ることができる（BMSEの“Use Old Format [01–FF]”を用いた図表が妙に多かった）。“DRUM'N'BASSCRUSADERZ”はBGMを29列以上持つ。“BRAVIAN”は分解能192で表せないrhythmを持つ。

後者をBMSCで保存してErrorが出て思い出したが、細かいrhythmを詰め込みまくるとBMSCは死ぬ。死なないGDAC2は革命的だった。これは後で表に加筆しておきたい（加筆済）。ともかく「拡張定義」が定着しきって死語と化した今もなお、古い形式には一定の需要がある。あるいはEditorの定義制限こそが需要を作っている。

iBMSCはexBPM/STOP objectsを使いまわすことができる。BMSEはexBPM/STOP object一個につき定義ひとつを使う（値が変わらない場合さえ）。#BPMzz/#STOPzzは各1295個まで値を定義できるので、値を使いまわせるiBMSCのほうが加速や停止をたくさん行える。単純な音頭差分などをiBMSCで保存し直してみればわかる。

Editorとは関係ないことを思い出した。「Long Noteは終端を判定しない」「Charge Noteは終端を判定する」という話は誰が言いだしたのだろう？　“KEYBOARDMANIA”やnanasigrooveの『ロングノート』は終端を判定していたが、そのあたりは事情があって忘れられたのかもしれない。私はLN/CNが苦手なのでよくわからない。

editors.htmlほかつれづれ

私のimpressionは書き残しや書き直しが多すぎて不安定なので、umt_ki氏による元の版も併せて参照されたい。書き残したことのひとつは、例えば“#WAV0G a.wav”とだけ書かれたBMS fileがBMSCにdropされた場合の反応。構文解析時における情報の欠落を著者に通知するeditorは、私が挙げた4種類のうちではBMSCだけのはずだ。とはいえ読み込み時に小節五等分rhythmが192等分に丸められる等の改竄は、普通に看過されるのだが。

楽曲が複数の図表を持ち、過度に装飾的な図表が描かれ、第三者によってuserstyles.org的なcommunityが運営されるなか、図表著者は今なお「楽曲を改竄しうる手段」のみを用いてANOTHER chartを描く。HTMLにstyle属性値を直接書き込むかの如き行いだが、BMSにおいて楽曲と図表は不可分なのでやむを得ない。

「creatorによって提供される図表」と「userによって追加される図表」を分離する案は考えたが、難しい。

1. 図表追加者は、base図表に対し不可視notesのみを加える。
2. 実行時macroは、元のKEY notesをすべてBGMに置換する。
3. 実行時macroは、「縦座標と番号の双方が不可視notesと一致したBGM notes」を、KEYに置換する。
4. 実行時macroは、縦座標・列座標・番号の参照が済んだ不可視notesを削除する。

実際は不可視以外のchannelが使われるべきだろうし、拡張子は*.user.bmなどのように適当に区別されるべきだろうが、図表追加者が楽曲を改竄していないことを保証する手段のひとつとしては「音を鳴らすふり」は有りだ。しかし不可視以外の云々が不可能だし、そもそも詐称に対して無力なので、あえなく廃案。

小節線はいまのところSKINの領分とされている。“pop'n music”が小節線を表示しないので、“pop'n music”を模したSKINは小節線を表示しない。bemaniaDXは小節線の表示・非表示を設定から切り替えられる。十年前の楽曲“100% minimoo-G”は、図表側から小節線を非表示にした例として知られている（私の記憶が確かなら、あれは家庭用のTraining Modeにおいて演奏開始小節を普通に変更できたはずだ）。

実際の小節線を装飾として用いる演出は、userに様々な不利益をもたらす。密集する小節線は小節数を不足させる。糞長い小節は分解能を際限なく上昇させる。それらはuBMplayやnanasigroove (Training Mode)やBMX2WAVなどにおいてseekを困難にさせる。font-sizeを調節するために入れ子にされた見出し要素を私は思い出す。

<h3>
  font-size:
  <h1>
    xx-large,
    <h6>xx-small,</h6>
    <h6>xx-small,</h6>
  </h1>
  medium;
</h3>