doubledepth

BMIIDXView2015 v3.02 (July 22, 2015)

地雷(#xxxD1-E9)を外観のみsupport。Custom Scripts (Lua)をsupport。

カスタムスクリプトについて

カスタムスクリプトとは、解析後のBMSデータを1オブジェずつ取り出し、

新たに任意のチャンネルに配置するためのスクリプト型のプラグインです。

このスクリプトはテキストファイルのためメモ帳などで編集することが出来ます。

---

スクリプトはLua言語を使用します。

---

同梱のサンプルは、シングル譜面をダブル譜面に変換するスクリプトになっており、

最終的にこのスクリプトをcharatbeatHDXに持っていくことで、その機能をゲーム中で

使用することが出来るようになります。

Custom Scriptsは、構文解析済みの図表（#RANDOM分岐などが剪定された後の図表）を任意に改竄するための拡張。五鍵盤図表を七鍵盤化したり、将来的にBeatmania IIDXに新登場するかもしれないHDX未実装OPTIONを模倣したり、いわゆる「RANDOM当たり配置」を再現したり、などの用途が想定されているものと思われる。

日本語locale Windowsの場合、HDX/IIDXvのDEBUG.TXTはShift_JIS (CP932) Encodingで出力される。同梱のcustom.luaはShift_JIS (CP932)で保存されているが、BOM (Byte Order Mark)を伴うUnicode (UTF-8, UTF-16)も使用は可能。Invalid UTF-8 byte sequencesは通ってしまう。実質CESU-8なのだろうとも思うが、そちらは未確認。

6.3.2. Obsolete: the ime-mode property (momdo氏による日本語訳)

私の用途において、ime-modeは大いに役立っていた。

* { ime-mode: inactive !important; }

このuser-styleは、Firefoxのaddress-barやsearch-barを含むあらゆるtext fieldにおいて、IMEの初期入力modeを半角英数字に固定することができていた。私はろくにtouch typingできないので、このCSSを知るまでは間抜けな誤入力を繰り返していた。

誤入力とはたとえば以下のようなpatternだ。①辞書と鍵盤を見比べながら必死こいて“Pneu­mo­no­ul­tra­mi­cro­scop­ic­sil­i­co­vol­ca­no­co­ni­o­sis”と入力する。②ようやく画面を見ると、実際は『せみいなもらみらなりかすちもにそすらとそらせにそとにりにそらひらりそちみらそらみにらとにと』と入力されている。⓪なぜならIMEがいつのまにか日本語入力modeになっており、そのことに私が気づかないまま鍵盤を叩きはじめたから。

ime-modeのおかげで、「日本語を入力する場合は、まず“Kana key”を叩く」という単純な習慣を覚えるだけで済んでいる。検索する程度なら“Half-width/Full-width key”を叩く必要がないのも嬉しい。

ime-modeが廃止されれば、IMEをCSSによって制御することはできなくなる。私にとっては不便になるが、「今までCSSでIMEを制御できていたのがおかしい」という意見は私もその通りだとは思うので、素直にuser scriptで代替するつもりでいる。いくつか問題がある。

• input要素のinputmode属性は現時点では実装が無い
• 仕様を見ても、「inputmodeの変更」が可能かどうかよく分からない（“fallback”がそれ？）
• userChrome.jsを今後も使い続けられるかどうか（Firefox 41以降はsigned add-onしか導入できない）

BMIIDXView2015 v3.01 (July 15, 2015)

#LNOBJを描画のみsupport。後述のBMS codeでは普通にkick.wavが鳴るべきだが、現時点では鳴らない。

#WAV11 kick.wav
#LNOBJ 22
#00111:1122

Windows Server 2003のsupport終了を受けてWindows XPの環境を点検す

「Windows XP用virus and spyware definition updates for Microsoft Security Essentialsの提供が、2015年7月15日に終了する」という告知を昨年どこかで見た気がする。さきほど確認したところ、配布所はJavaScriptなしでは表示されないように変更されていたが、update自体は提供が継続されていた。

Java Version 8 Update 51もWindows XPに導入できた。OSを新しくすべきだという警告が導入時に表示された。

Blink系browsersは、すくなくとも2015年末まではWindows XPをsupportするはず。

We will continue to provide regular updates and security patches to Chrome on XP through the end of 2015.

BMIIDXView2015 v3.00 (July 5, 2015)

• WASAPIに対応
• ツリービュー対応
• ウィンドウへのファイルドラッグ対応
• キーボードのLEDをインジケーターに設定可能
• キャッシュ機能の強化によりWAV書き出しを廃止

HDX/IIDXvのWASAPIはExclusive-Modeなので、音の遅延や劣化は最小限に抑えられるはず。

#RANDOMなどの分岐をoutline viewで閲覧できる。これが図表editorのように視覚化され編集可能になれば、と思わせる面白い機能。ただし“オートメーション工場”で応答しなくなる。もしかすると逐次読み込みや遅延読み込みが必要かもしれないが、そこまでする意味があるかどうかはよく分からない。余談として、次世代規格案の無限resource定義や無限小節数などに関しても、同様の問題が発生することは予想がつく。

OGG変換済みBMS再生時に大量のWAVを出力する挙動は廃止された。

HDX/IIDXvのUTF-8は実際にはCESU-8なので（根拠は1F3B9）、他のUTF-8対応BMS appsやWeb BMS Playerとは部分的にしか互換しない。Web browsersはinvalid byte sequencesをU+FFFDに置き換えるので、HDX Internet Rankingにおいて“#TITLE 𠮷野家”は「��野家」に化けるかもしれない。化けるくらいで済めばましだが。

異体字覚書

JISの異体字情報を持つのは日本語用書体のみ:

<span class="jis90">&#x845B; &#x845B;&#xE0100; &#x845B;&#xE0101;</span>

content: '\845B  \845B\E0100  \845B\E0101';

JIS字形を使い分けたい箇所には日本語用書体のみを当てるのが安全。日本語用書体を持たない環境に対して字形の違いを示すならWeb Fonts and/or Imagesを使うことになるだろうが、CSSが無効の環境でWeb Fontsは適用されないし、画像が無効の環境でstyled @alt textが描画される保証もない。

異体字ごとにUnicode codepointを持つのが確実だと思うが、認められないだろう。Codepointといえば、「あ゙い゙ゔえ゙お゙」のうち単独でcodepointを持つ文字は「ゔ (U+3094)」だけで、他は合成用濁点との組み合わせしかUnicodeに存在しない。Blink/WebKitは“-webkit-font-feature-settings: 'ccmp' 1;”がなければ合字にならない。

CSSを指定しても、著者の期待通りに描画されるかどうかは書体次第:

ゔあ゙い゙え゙お゙ (맑은 고딕 / Malgun Gothic) This font has no U+3094/3099 glyphs

ゔあ゙い゙え゙お゙ (微软雅黑 / Microsoft YaHei)

ゔあ゙い゙え゙お゙ (微軟正黑體 / Microsoft JhengHei)

ゔあ゙い゙え゙お゙ (Source Han Sans [CN/TW/JP/KR] / Noto Sans CJK [SC/TC/JP/KR]) 縦書きでも崩れない

葛󠄀城（かつらぎ）

航空母艦の葛󠄀城さんは、国立半蔵学院の葛󠄁城さんとは字形が異なる。冬木の葛󠄀木さんとは読みが異なる。MS-IME 2012の場合、「IVS (Ideographic Variation Sequence) を含む文字を制限する」を無効にすれば、いくつかの異体字を変換できるようになる。<845B E0100>は変換候補に現れるが、<845B E0101>は出てこない。

Blink/WebKitでも異体字を描画したい場合はfont-feature-settings (English / Japanese)を使う。IVSと併用すれば互換性を確保できるし、CSSが剥がれても著者の意図を伝えうる。Windows 8以上において、Firefox 39とInternet Explorer 10+は、IVSがfont-feature-settingsと競合したときIVSを優先する。

読み上げが「かつらじょう」「かつらしろ」に化けるなど、現状のIVSの機械処理には問題がある。名前に関するdatabaseなどは異体字をどうにかする必要があるはずなので、きっとどうにかしているに違いないが、HTMLではいまのところruby要素のruby-baseにaria-hiddenを適用するような方法しかなさそうに見える。

その方法で読み上げが制御できるなら、そうしても良いのだろうか。Ruby-textに対してdisplay:noneやvisibility:hiddenを適用すると、ruby-textが読み上げられなくなるので、とくに明示したいわけでない注釈は文字色を透明にする。一目瞭然で「悪い方法」だなあ。

ᄇ​ᅩ​ᆫ​〳〵ᄀ​ᅩ​디​ᆨ​

「본고딕」は「본 >보​ᆫ​> 고 >ᄀ​ᅩ​> 딕 >디​ᆨ​> 」を経て「ᄇ​ᅩ​ᆫ​ᄀ​ᅩ​ᄃ​ᅵ​ᆨ​」まで分解できるが、分解済み文字列はCSSには使えない。

본고딕 (\BCF8\ACE0\B515) (effective)

<dt style="font-family: '\BCF8\ACE0\B515  KR Heavy';">&#xBCF8;&#xACE0;&#xB515;</dt>

ᄇ​ᅩ​ᆫ​ᄀ​ᅩ​ᄃ​ᅵ​ᆨ​ (\1107\1169\11AB\1100\1169\1103\1175\11A8) (not effective)

<dt style="font-family: '\1107\1169\11AB\1100\1169\1103\1175\11A8  KR Heavy';"
    >&#x1107;&#x1169;&#x11AB;&#x1100;&#x1169;&#x1103;&#x1175;&#x11A8;</dt>

On Windows 8.1, if computer has SubsetOTF/SourceHanSansKR.zip:

Firefox 39 (disabled Direct2D), Iron 43, Internet Explorer 11 (System Locale: Korean), Opera 12.17 (System Locale: Korean) can display specified font, but decomposed string is not effective.

Midori 0.5.10 (WebKit)に対してはEnglish font-family namesを指定しなければならない。一方でWindows 8.1上のInternet Explorer 11とOpera 12.17の場合、Source Han Sansに関してはlocalized namesを指定しなければならない場合がある（System Locale: Japanese / Korean）。さらに、Direct2D/DirectWriteを使用可能な環境では、Gecko/Blink系は書体名やfont-weight指定に関して描画支援機能の影響を受ける（Direct2D: able / disable）。FirefoxのBug被害者やMacType使用者など案外いそうなので、静的な指定だけでは辛い。

CSS文字列としてdecomposed stringを使えるのかどうかに関しては、仕様を探しているがよくわからない。

CSS文字列において、escape sequenceの直後に空白が続く場合の注意点が、仕様に書いてある。

In fact, these two methods may be combined. Only one white space character is ignored after a hexadecimal escape. Note that this means that a "real" space after the escape sequence must be doubled.

Bad font-family:

'본고딕 KR Heavy'; /* codepoint <1107 1169 11AB 1100 1169 1103 1175 11A8> */

'\BCF8\ACE0\B515 KR Heavy'; /* W3Gにも類例があるが、無効。OS Xなどでは通るのだろうか？ */

'\BCF8\ACE0\00B515 KR Heavy'; /* but browsers don't know this [追記] 私は誤解していた。16進数escapeに後置される一個のU+0020は常に無視されるので、この指定が空振る実装は正しい。 */

Good font-family:

'본고딕 KR Heavy'; /* codepoint <BCF8 ACE0 B515> */

'\BCF8\ACE0\B515 KR Heavy'; /* doubled Space */

'\BCF8\ACE0\B515\20KR Heavy'; /* but "\20AF" is not " AF" (Afghanistan) but "₯" (U+20AF) */

'\BCF8\ACE0\B515 \20KR Heavy'; /* “Only one white space character is ignored after a hexadecimal escape.” */

'\BCF8\ACE0\00B515 KR Heavy'; /* ditto */

'\BCF8\ACE0\00B515 \20KR Heavy'; /* ditto */

'\00BCF8 \00ACE0 \00B515 \000020 KR Heavy'; /* ditto */

私はこのような事柄を覚えていたくない。macrosで全部escapeするほうが簡単だ:

'\BCF8\ACE0\B515\20\4B\52\20\48\65\61\76\79'; /* this is easiest and safest */

'\00BCF8 \00ACE0 \00B515 \000020 \00004B \000052 \000020 \000048 \000065 \000061 \000076 \000079 ';

そもそも源ノ角ゴシックやNoto Sans CJKは、普通は必要な分だけ切り出してWeb Fontsとして使うものなので、@font-faceで任意の英語名を定義すれば何も問題はなかった。

Mojibaked BMS Package — “LUMINOUS Pure White”

[2015年7月6日朝8時半追記] 現在はPackageはRAR形式に変更され、Encodingに関する問題（文字化け）は修正されました。この日記の内容は修正前のZIP形式に関するものです。

http://l-bms.com/2nd/

つい先日公開された LUMINOUS Pure White というBMSパッケージですが、これアーカイブ内のファイル名の文字コードおかしくね？

韓国ならおそらくEUC-KR、と思って想定して解凍し直したら今度は別の曲で文字化け起こしちゃう…気になるけどこれから夜勤でして

要は助けてHitkeyさーん！

解決法は二つ思いついたけど、まともな環境でRAR形式などに再圧縮していただくほうが、多くの人にとって幸せだと思います。CP949 filenamesとUnicode filenamesが混じって格納されてしまう原因は、おそらくNtleasなどの「System Localeを誤魔化す」という方法にあるのではないかな、とXyz氏の記事を読んで思いました。

• Windowsを韓国語Localeに変更してから解凍してみる。失敗したらさらにNtleasを導入して解凍してみる。
• または、downloaded ZIP filesのcopyを二個作成し、片方はUnicodeを指定して展開、もう片方はCP949などを指定して展開。失敗する場合は文字化け内容だけ消して再度展開。最後に、展開後の内容をmergeする。

Encodingを指定して展開できるsoftwareとしては、ZipExtractorなどがお手軽でしょうか（その場に展開するだけでinstallでき、folderを丸ごと消すだけでuninstallできるので）。私も今ちょいと時間がないので、駆け足で失礼しました。後日また書くかも。

[追記] 日本時間2015年7月6日1時39分29秒におけるTweetにおいて、問題が解決されたことが報告されました。

Nervous Cascading Style Sheet Rules for old Internet Explorers

Bad style:

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ja" lang="ja">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <title>
      Nervous Cascading Style Sheet Rules for old Internet Explorers
    </title>
    <style type="text/css"><!--/*--><![CDATA[/*><!--  */
      /* idea from https://w3g.jp/blog/iecss */
      #ID .target { /* style for Internet Explorer 5.5 or later */   color: blue;   }
      #ID .\74\61\72\67\65\74 {                      /* for IE6+  */ color: yellow; }
      #ID > .\74\61\72\67\65\74 {                    /* for IE7+  */ color: green;  }
      html:lang(ja) #ID > .\74\61\72\67\65\74 {      /* for IE8+  */ color: silver; }
      html:root:lang(ja) #ID > .\74\61\72\67\65\74 { /* for IE9+  */ color: lime;   }
      html:valid,
      html:root:lang(ja) #ID > .\74\61\72\67\65\74 { /* for IE10+ */ color: black;  }
      *::-ms-backdrop,
      html:root:lang(ja) #ID > .\74\61\72\67\65\74 { /* for IE11  */ color: maroon; }
      @media screen and ( max-width: 30em ) {
        #ID .target {                              /* not effective */ color: red;     }
        html:root:lang(ja) #ID > .\74\61\72\67\65\74 { /* for IE9+  */ color: red;     }
        html:valid,
        html:root:lang(ja) #ID > .\74\61\72\67\65\74 { /* for IE10+ */ color: aqua;    }
        *::-ms-backdrop,
        html:root:lang(ja) #ID > .\74\61\72\67\65\74 { /* for IE11  */ color: fuchsia; }
      }
    /*]]>*/--></style>
  </head>
  <body>
    <h1 id="ID">
      <span class="target">
        Nervous CSS Rules for old IE
      </span>
    </h1>
    <p>
      Nihongo de Okay
    </p>
  </body>
</html>

Internet Explorers (IETester v0.5.4):