①入力欄上「ランダムにセット」
②入力欄左上「下記内容で実行」
発車標部分をクリック(タップ)で全画面表示/解除ができます
あとは、各自さわって試してみてください
2026.1.26更新 Ver.2.0
2025.6.16更新 Ver.1.1
2024.6.20公開 Ver.1.0
フォントのソースは下記の通り。ドットフォントの漢字はjis第一水準まで対応しています
| フォント | ソース |
|---|---|
| 筐体フォント | Noto Sans JP(日本語)／Heebo(英数字) |
| 24ドットフォント（ゴシック） | 縁架ドットゴシック24 Ver.1.1／左記に収録されていない漢字のみNoto Sans Mediumを24dotで二値化したもの |
| 24ドットフォント（明朝） | 縁架ドット明朝24 Ver.1.1／左記に収録されていない漢字のみJFドットjiskan24h（全角文字はパブリックドメイン） |
| 16ドットフォント | JFドット東雲ゴシック16（パブリックドメイン） |
| 英数字 | オリジナル |
発車標Ver.2.0(と方向幕Ver.2.0)からLED部の描画処理を大きく変更した。スクロール処理の抜本的改良はこれで2回目である
発車標Ver1では生成した画像をimgタグに投入しcssでスクロールを実現していた。この方法で描画負荷を大幅に下げることができたが、以下の弱点があった。
これらの問題を解消するため、今回は全てcanvasでの描画とした。一見退化したように見えるが、LED風画像生成後の画像を予め用意した上で描画ループを回すことによって、大きな負荷増加はなく済んでいる
描画の流れはこんな感じである
スクロールは毎フレームでなく2フレームごと(30fps)の描画としている
変化のある処理を全てrequestAnimationFrameループ内に収めたのでsetIntervalは使用しなくなった。また1つのcanvasでの描画となったのでimg要素が廃止され、cssアニメーションから解放されただけでなく、画面横幅に応じて伸縮ができるようになった。
画像同士のドットのズレについては、1ドットあたりの変換後px数を計算してあげることで防ぐことができるが、発車標くらいのサイズになると目立たないので実装は見送っている
大分改良されたスクロール処理であるが、以下の欠点が残る
今回、筐体の描画もcanvasでプログラム的に行っている。
筐体の描画で特別難しいことはしていないが、時計部分の影のインセット（凹んでいる表現）だけはネット上に情報がなかったのでメモしておく
canvasではドロップシャドウを付けることができるが、おそらく影のインセットを行うオプションがない。なので、回りくどい方法でインセットに見えるような画像を作っていく
まずメインキャンバスの他に別途作業キャンバスを用意する。作業キャンバスのギリギリ外でストロークを描き、それにドロップシャドウを付ける。この作業キャンバスを、メインキャンパスにdrawImageで貼り付ける
線の太さを意識して座標を考えるのが面倒である。デメリットとして、角Rをつけていると角にストロークの色がついてしまう。ストロークの色を透明にすれば良いと思ってしまうが、そうすると、そもそもシャドウが付かない。今のところ改善策なし
今回独自に色タグ（㈹赤など）を実装した。本当はxml的なタグにしたかったが断念し簡易的な実装である
1文字分の描画を行う関数内の最初で文字判定が実行される。㈹/㈵が来れば描画を中断し、次の文字（赤/青/黄…）を解釈する。その次の文字から描画が再開される。
つまり㈹/㈵がトリガーであり、㈹/㈵が付かない赤/青/黄…は普通の文字として描画される。
コピペするのも面倒なので追加ボタンを設置した。青枠のテキストボックスのカーソル位置を取得し、文章中に挿入できるようにした。
前回のled方向幕シミュレータに引き続き、今回のシミュレータの表示画像は動的に生成される。そのために入力エリアはできるだけ自由に入力できるようにしたい（例<input type=”text”>）。しかし反対に決まった内容を入力したいときは自由すぎる入力は不便・面倒であり、選択肢があった方がよい（例<form><select>）。今回は<input type=”text”>ベースとし、(＋)メニューから予め用意したテキストを追加できるようにした
前回の方向幕シミュレータでは、スクロールがある場合毎フレーム描画を行っていたが、当然のように重い処理となり致命的な問題となっていた
今回は抜本的対策を行いcssアニメーションにて実現した。例えば幅200pxのエリアでスクロールを行いたい場合、下記のような画像を生成する。
これを200pxを超える部分は隠した上で横にスライドすることで、スクロールしているように見せることができる。前回の方式と比べると描画処理が一回で済み、スクロールがカクつくことはなくなった
実際のcss（1行目備考欄）
このままではうまく動作しない。単にアニメーション範囲を0%から100%にすると、画像が完全に見切れる（画像右端が描画範囲左端まで達する）までスライドしてしまう。うまく動作しているように見せるためには、画像右端が描画範囲右端に達した時点でアニメーションをとめるようにしなければならない
つまり、上記cssの/*変更部分１*/をjavascriptで動的に計算する必要がある
次にアニメーション時間を変更する（/*変更部分２*/）
さて、javascriptからcssを変更したいときは、個別のhtml要素の.styleプロパティからアクセスすることが普通だが、今回変更したいのはキーフレームである。個別のhtml要素からアクセスすることはできない。どうするか？javascriptから”直接” “地の”cssを変更していく。
そのためにdocument.styleSheetsやcssRulesといったプロパティがあるのだが、これが曲者かつ不便で、スタイルシートやその中のcssルールを指定する方法が”順番”しかない。
cssルールは上から数えていけば分かるが、スタイルシートの順番というのが分からない。
MDN webdocsによれば、document.styleSheetsは次の順でリストが返されるとある。
ということらしい。とりあえずこれで目的のスタイルシートを探すことができる。分からなくても、0から順番に試していけばいい。
しかし、これはつまり、何かあれば簡単に順番が変わってしまうということでもある。
例えば<head>内の<link>を増やせば、<body>内の<style>の順番は後ろになるし、ローカル環境からwordpress等の環境に上げればプラグイン等の<link>が増え、順番が変わる。
このことからdocument.styleSheetsやcssRulesを使うときの注意↓
・スタイルシートの場合は、読み込まれるスタイルシートの数が変わるときはエラーが起きないか確認を行う
・cssルールの場合は、予め順番で指定されることを予想して書く。操作したいルールは上の方に置き、順番を固定する
前回は画像だったフォント情報をテキストに変更した。詳細は以下の通り
↑「黒なら0」「白なら1」で二値化し8ビットごとに16進数に変換。
24*24dotなら1文字につき144桁の文字列となる
この文字列を幅情報や高さ情報と一緒にcsvに統合。csv化によってフォントデータが増えても管理がしやすくなった
