以下のようにするとテーブルの幅を固定しつつ、表示領域の幅による折り返しを抑制できます。
||200|c |自由幅|固定幅| |>|&nobr{つっかえ棒～～～～～～～～～～～～～～～～～～～～～～～};|f
この件は基本的にはtablesortと関係がありません。 しかしtablesortが話に出てる来る背景は、列数が多いテーブルでtablesortを使うと▲ソートボタンがテーブル幅を押し広げるためテーブルが画面領域に収まらなくなるからだと思います。同種のトピック
また類似の件として、flex_containerでflex_boxで表を横並びにしたときに、テーブルの配列が折り返されたり、テーブルの中身が押しつぶされてしまう場合があります。
スレ建てした者です。今更ですが、改めて確認したところ直っていました。ご対応ありがとうございました。
上記のプラグイン（kanateko氏製作・公開）はGPLv3準拠なので、 そのまま実装しても、カスタマイズして実装しても、 ライセンスの問題は生じないと思います。
追伸 上記の書き方は#fold()でも通用します。 一方#accordion()では使えません。
以下のようにダブルクォーテーションで囲めば上手くいきます。
#shadowheader(1,"&attachref(image.png,nolink,20x20,見出し1);");
これは勘で書いて結果的に上手くいったのですが、 たぶん動作としてはダブルクォーテーションで囲むことにより、attachref内のカンマ区切りをshadowheaderの配列区切りに解釈しないようになったと思います。
shadowheaderを使いたい背景がわかりませんが、 contensのリストに出したくない見出しを制御したいならcontentsxを使う方法もあります。
除外したい見出しが"見出し1"のとき #contentsx(except=見出し1)
ただし部分一致で作用するので上記の書き方だと"見出し10"も除外されます。 正規表現で詳細に指定できます。 あるいは逆に"filter=リストしたい見出しの文字列"という方法もあります。
#skin(default_black01) でブラックにできますよ 編集画面はできないので要望してみるといいと思います
私もこういう機能が欲しいですね。 複数の画像を領域固定で一まとめにしておけるのでページ構成の自由度が上がります。
プラグインという形で対策いただき、一応解決しました。 （詳細はコチラ）
どうもありがとうございました。
SEOにも影響するから、SEOに熱心なWIKIWIKI運営も取り合ってくれるかも知れないですね。
確かに14は小さいかもしれません。 とりあえず応急処置として、全ページの一番上に#size(16){{{{{ 一番下に}}}}}を追加するのはどうです？ いらなくなったら コントロールパネルから一括で消せますので。
現在wikiwikiにテーブル内での折りたたみが可能なプラグインはありません。 foldがインライン型(\&fold(タイトル,開/閉){内容};)に対応されればテーブル内でも記述が可能になると思います。 メリットとしては高さ方向の圧縮もそうですが、foldで折りたたんでいるうちはそれに合わせて横方向の伸張も抑制されるのではないかと思います。例えばテーブルの右端に備考列を付けたとき説明が長くなると表が横に伸びるか、幅の限界で折り返しが発生します。幅の狭いスマホなどを考慮したいときは、インライン型のfoldが対策になるかもしれません。
同じく、Sliderプラグインの導入を希望します。 他のWikiサイトのプラグイン導入が権利的に難しいのであれば、WikiWiki様独自でslickのようなプラグインを開発していただきたいです。 一つの項目に対して複数の画像を提示しながら多角的に説明できるようにしたいので、「画像(ファイル)＋テキスト」を可能としていただけると嬉しいです。 ご検討をお願いします。
そうなんですね。特に不便を感じていないので、現状でも構いません。 WIKIWIKIが運営するWIKIWIKIとzawazawaのみに対応するというのもありかなとは思います。
対応しない方がいいです。 外部リンクが対応していない理由は、恐らくスパムや対立荒らしがあるからだと思います。 例えば、FrontPageに「引っ越しました。新wikiはこちら」と書いて誘導し、広告収入を得る業者がいます。 ちゃんと管理人が管理されているwikiならば大丈夫だと思いますが、全部のwikiに適用されるのは危険ですね。
賛成です。
既存のtable_editは別ページの用意が必要で一手間あったのですが、それが解消されます。 また別ページ呼び出し系でなくなるので、キャッシュの問題も解消します。 編集機能も十分で、さらに表計算機能もあるようで、従来スプレッドシートで計算して転記してたケースが楽になるかもしれません。
既存のtable_editも含め編集可能テーブルは、wiki記述に不慣れな人でも編集に参加しやすいのが良いところです。 例えば自分で表の埋められるところは埋めて、わからないところは他の人にお願いしたりすることがあるのですが、table_editにしておくと編集に参加してくれたりします。 テーブルに限らず閲覧者の多くがwiki記述を理解しておらず、コメントはするけど編集方法を調べたり勉強したりしてまではやらない人が多い気がします。また失敗を恐れて手を出さない人も多いと思います。 table_editはある意味メニュー形式なのでその辺のハードルが下がります。 スマホ画面でも編集しやすいと思います。
wikiを分かってる人間でも巨大な表を直接編集するとき、||||||||こんな風に並んでるとどこが何列目かわからなくなりプレビューと編集を行ったり来たりします。table_editを使うと編集したい行と列の位置が明確になるのが良いのです。 ただ従来のtable_editは編集列が追加されて横幅が広がり折り返しになったり、用もないの編集ボタンをアピールしたくなかったり、予め別ページで作り込まなければならなかったりとデメリットも多かったです。これがtable_edit2になればオプション記述で編集ボタンのOff/On表示を選択できたり、あるいは使わないときは//コメントアウトでプラグインを無効したりできるようになるので使いやすくなると思います。
文字置き換えの最終チェックをしていたところ、 最初の一文字目に空白がある場合、&size(20){●};となってしまいました。
(空白)口口口 (空白)口●口 (空白)口口口 ↓文字置き換え後、 (空白)口口口 (空白)口&size(20){●};口 (空白)口口口
当Wikiのような攻略サイトで最初の一文字目に「空白」を利用しているページが有る場合に&font(monospace)や&sizeを使ったフォントサイズ変更には要注意ですね。
最初の一文字目に「空白」を使用した場合であれば、「○」「●」「□」「■」は通常文字と同程度の大きさになるので、改善してほしいです。
さらなるご提案ありがとうございます。
1つ目ですが、サイト全体のフォント設定を"デフォルト"→"等幅"に変更してみました。モバイル閲覧時は文字の見やすさに全く影響がなく、特定文字の○や□も通常文字と同じ大きさで大変良かったです。ご指摘どおり、PC閲覧時の文字が見にくくなっており、あえなく却下となりました。PC閲覧時でもモバイル閲覧時と同様の影響であれば、採用していました。
2つ目ですが、膨大なページ数のため、お伝えいただいたとおり変換中にタイムアウトで中断する可能性が大いにありました。有志者によって「◯」を使用するページも所々ありましたので、文字列置き換え機能を使って「○」→「◯」に変換しました。案の定、タイムアウトしましたが、すべて置き換えることに成功しました。 しかし、「□」などは機種依存文字「⬜」（正確には代替になっていない）になってしまい、閲覧環境によって、文字化けするので置き換えできませんでした。当Wikiは日本語サイトですがAnalyticsにより、毎月70か国以上から多種多様のブラウザ・利用OSでアクセスが有ることを確認しているためです。 そこで、「□」→「&size(20){□};」で文字の大きさを変更して、無理やり問題を解決することといたしました。その他文字の小さい文字についても同様です。
運営へのお願い 根本的な解決に至っていませんが、どのWIKIでも使用頻度が多いと思われる通常表示が小さくなる特定文字「○」「●」「×」などは編集時に予め、通常文字と同じ大きさにサイズ変更される仕組みがあると良いのではないでしょうか。 >> 5のように欧文フォントを削って、新たなfont-familyを新設されることにも期待したいです。
こちらの機能は、閲覧者側でカスタマイズ出来て良いですね。同じく、あると嬉しいです。
この件はサイト全体のフォント設定の選択肢をwikiwikiに増やしてもらうのが良いと思います。
現在選択できるfont-familyは以下。
ゴシック(sans-serifデフォルト)、 タイトゴシック(sans-serif-tight) 明朝(serif) 等幅(monospace) レガシー(legacy-ui-gothic)
このうちmonospaceのみが和文フォント優先で、他は全部欧文優先です。 ただmonospaceについては等幅に特化したデザインになっており文章に適してません。monospaceが有用なのは表やプログラムソースのような表現です。よってmonospace以外にも和文を優先した選択肢が欲しいところです。
例えば、現在のデフォルトのゴシックは以下の設定になってるのですが。
Verdana, Arial, Hiragino Kaku Gothic ProN, Hiragino Sans, Meiryo, sans-serif
これの欧文フォントを削って新たに以下のようなfont-familyを新設すれば、○●×などの記号も和文フォントで表示されるようになります。
Hiragino Kaku Gothic ProN, Hiragino Sans, Meiryo, sans-serif
どのように見えるかは実験的に以下の方法で確認できます。
適当なページを表示してブラウザのページをhtmlとして保存。 htmlをメモ帳などのテキストエディタで開く。 "font-family:"の行を検索して、Verdana, Arial,の部分を削除して保存。 編集したhtmlをブラウザーで開く。
VerdanaとArialを削ってしまうと何かしらの問題があるならば、削除せずに和文フォントより優先位置を下げる対応でもよいです。
もしあるならば、欧文フォントで記号文字コードを持ってないフォントを優先位置にセットしてもらうでも良いと思います。 ただ以前調べたときは適当ものは見つけられませんでした。
Windows10のMicrosoft IMEが古いバージョンだと、『Ctrl』+『BackSpace』ショートカットキーを使った再変換は出来たようです。Windows10の最新バージョンでも『以前のバージョンのMicrosoft IMEを使う』設定を有効化することで行えるようになるようです。参考リンク
サイト全体を一括で変える方法は二つあります。 どちらも管理者権限が必要ですが。
一つは管理メニューのコントロール→デザイン サイト全体のフォント設定を"デフォルト"→"等幅"に変更。 まずはこれで切り替えてみて文章を含めた全体の表示を確認してみるのがよいのではないでしょうか。 ただ、テキストエディターで表示してるような見た目になり、文章は見にくいかもしれません。
もう一つは置換機能で置換する手があります。 文字列置き換え ただし使えるケースは限定的で、例えば表などで|○| → |&font(monospace){○};|とか決まった表現のときです。
もしサイト全体の単独の"○"を全部置換しようとすると、ページが多いときに変換中にタイムアウトで中断する可能性があります。中断されるまでの変換は行われるのですが、もう一度実行して変換不足を行おうとすると"&font(monospace){○}"で変換済みのところが、"&font(monospace){"&font(monospace){○}"}"みたいに二重に変換されます。この機能は正規表現に対応してないのでこういった対応が面倒です。
そうなんですね、教えていただきありがとうございます。
>> 1 こちらの症状は入力方法をMicrosoft IMEに変更して同環境で行ったところ、再現いたしました。編集中の文字が下線がついている状態から編集エリア内外問わず、クリックした時点でフリーズします。エラーコードも>> 6と一緒です。
私の環境ではCtrl+BSしてもフリーズはしません。 ただし、例えば"めにゅー"→変換"メニュー"で確定して、Ctrl+BSすると"メニュー"の下には下線が再表示されません。 下線は表示されませんがスペースキーで再変換はできるようになります。 一般のテキストエディターや構文ハイライトではない従来のエディターでは、Ctrl+BSで下線が表示され未確定状態が明示されます。
環境 Windows10 (2004) Firefox (93.0)、 Microsoft IME ブラウザーの設定で広告やJavaScriptは一部抑制してます。
［CTRL］＋［BackSpace］キーで直前の確定を取り消す こちらの動作はGoogle日本語入力または、旧OSのMS-IME/MS-IME 2007になります。Windows10に搭載しているMicrosoft IMEにそのショートカットキーはありません。参考リンク
私のPCではCTRL+BSのショートカットがなぜか使えない？のですが、その代替になる「変換」キーを使ってみたところこちらでもフリーズを確認しました。
私の環境ではフリーズはしませんが、おかしな動作を確認しました。 Windows10 (2004) Firefox (93.0)、 Microsoft IME ブラウザーの設定で広告やJavaScriptは一部抑制してます。
状況 何も書いてない白紙の状態から以下の操作 1行目に"めにゅー"とローマ字式で入力、まだ未確定状態で下線付き。 このとき2行目は以降は存在してない。
この未確定状態で編集エリアの適当な場所をクリック。 入力中の文字上や、文字のない右や下の領域をクリックしてもなにも起きない。 一見問題が無いように見えるが、クリック動作をしても"めにゅー"の下の下線が消えず未確定状態を維持してる。 通常テキストエディターなどでは、入力中の未確定状態からクリック動作をすると確定される。何か怪しい。 また、編集エリアの外の領域やブラウザー以外のWindowをクリックした場合は確定状態となり下線が消える。これは一般的な動作と一致してる。
同様の状態からダブルクリックしたとき 未確定状態の"めにゅー"の文字が消える。ふつうはクリックで確定され消えたりはしない。 しかし、文字列が消えた状態からスペースキーを押すと"メニュー"と変換された文字が再表示される。 さらにスペースキーを押し続けると、IMEの検索候補一覧が表示されると同時に、編集エリアに検索候補の一部が勝手にコピペされる。さらにスペースキーを押し続けると、どんどんコピペが増殖される。
>> 4 こちらの情報を基に同じ行為を行ったところ、構文ハイライト (β版 ver 0.1.4）にて再現され、フリーズしました。
行った内容 編集中に確定した文字列に対して、カーソル位置の直前で確定した変換をやり直すため、［Ctrl］＋［Backspace］を押した時点で該当のタブのみハングする。 chrome通常モード/シークレットモードともに同症状が発生する。
症状 スレッド元の画像と同じ「ページが応答しません」が表示されました。「ページを離れる」ボタンを押すと「エラー コード: RESULT_CODE_HUNG」が表示されました。その他のタブなどは問題なく操作できています。
環境情報 PC閲覧 Windows10Pro 20H2 Chrome93.0.4577.82（Official Build） （64 ビット） Google日本語入力
私の場合、編集中に確定した文字列を再変換しようとCtrl+BSを押した瞬間にフリーズします。 変換中のクリックではフリーズしません。 環境はWindows10 Pro、Firefox93.0 (64 ビット)、Google日本語入力です。
返信ありがとうございます。スクショと環境情報を追記しました。
丁寧にご説明された返信ありがとうございます。 当サイトは、老舗のゲーム攻略サイトでして閲覧者の見やすさを重視してご提案いただいた方法を行いたいところですが、検索した結果、数百ページとさらに複数の該当箇所と表があります。現在、別の長期メンテナンス作業を行っています。膨大な時間を要して、とてもとても出来そうにありません。
1ページまるまるマルチラインで括ってしまうと逆に見にくくなる箇所が出てしまいます。 例： 変更前→変更後 5000～→5000~
目に止まったページのときに見つけて手が空いていたら、該当箇所に対してご提案の方法で行うか、エクセルなどに貼り付けて一括置換をしようと思います。どうもありがとうございます。
私の環境下では同様の動作を行いましたが、問題が再現されませんでした。フリーズ時のスクリーンショットや環境情報があると運営側および、サポーターにとって助かるかもしれません。
一部の記号フォントが小さくなる問題は、以下の方法で対応ができます。
インライン &font(monospace){0123ABCDabcd○●×△▲◇◆□■☆★↑↓→←あいうえおoO01lIij!/\~^-+*=%,.;:[](){}}; マルチライン #font(monospace) {{ 0123ABCDabcd○●×△▲◇◆□■☆★↑↓→←あいうえおoO01lIij!/\~^-+*=%,.;:[](){}}; }}
ただこのmonospaceは記号表記の統一感は出ますが、日本語フォントとしての見栄えは今一つかもしれません。 こだわるならインラインで部分的にフォントを変えるなど手を掛ける必要があります。
一部の記号が小さく表示される問題は、私が理解してる範囲では、wikiwikiで設定してるfont-famliyの優先順によるものです。 例えばフォントを特に指定しないときは、以下の並びの左から順に使われるフォントが決まります。
概ね半角の英数字はVerdana, Arialなどの欧文フォントが使われ、日本語などの全角文字は欧文フォントで表示できないのでHiragino系やMeiryoなどの日本語文字コードに対応したものが使われます。 複数候補の内どれが使われるかはそれぞの環境により異なり、先頭から読み込んでいって自身のOSにインストールされてるフォントが自動で選ばれます。
記号については扱いが複雑で、例えば "●"はVerdana内に存在するのでこれが使われます。欧文フォントなので小さく表示されます。 "○"はVerdana内は存在しないがArialにはあるのでこれが使われます。これも欧文フォントなので小さくなります。 "△"は上記いずれも持ってなく、Hiragino(Mac系)かMeiryo(Win系)の日本語フォントで表示さるため大きくなります。 日本語環境では全角記号は全角で表示して貰いたいところですが、欧文フォントが中途半端に文字コードに対応してるために日本語フォントが食われた形になってます。
monospaceで記号が意図したように表示されるのは、monospaceのfont-famliyが以下のように設定されてるからです。
MS Gothic, Osaka-mono, Osaka, Meiryo, Hiragino Kaku Gothic ProN, Hiragino Sans, Menlo, Monaco, Courier New, Courier, monospace
先頭に並んでるMS GothicやOsakaは日本語に対応してるため基本的にこれらが使われます。ただmono系は等幅のフォントなので、記号は良いかもしれませんが文章表現には向いてないかもしれません。
関連リンク
参考画像を貼っておきます。 PC閲覧時 モバイル閲覧時
いただいたヒント先とwikiwikiのhtml出力を見て推定できました。おそらく以下の機能ではないかと。 tablesorter 詳細な説明があります。CtlrとShiftキーの説明も載ってました。 そしてソートをリセットする機能も書かれており以下です。 sortReset 表の外にボタンを埋め込む感じなりますが、たとえばwikiwikiで表現するなら以下のようでしょうか。 表外にResetボタンが出現し、押すと表全体がリセットされる感じです。これならスマホでも操作できます。
#tablesort(sortReset){{表}}
欲を言えばShiftで複数列ソートができることが分かったので、列毎にリセットしたいところですが機能本体にそういったものはなさそうです。
そしてこのtablesorterは単なるソート機能ではなくテーブル機能をかなり拡張できるようです。 例えばフィルターとかヘッダー固定とか、accordionのように行をまとめたりとか。 Option指定で機能をOnにすればいいだけのやつは使えるようにしたいです。
WIKIWIKIの方には特に記述を見つけられませんでした。 自分はsWIKI（別のレンタルWiki）のページでShiftクリックを知り、WIKIWIKIの方でも試してみたらできた、という感じです。Ctrlクリックは他にも何かできないかなーと、いじっていて発見しました。
これは気づきませんでした。ありがとうございます。 tablesortってどこかで仕様が公開されてるのでしょうか。
ついでにShiftキーを押しながらだと複数列ソートできますが、これも携帯端末だとできないので欲しいです。
Windowsなら、Ctrlキーを押しながらソートボタンをクリックでリセットされます。 でも携帯端末ではできないようなので欲しいですね。
縦スクロールバーが2重表示される件について、当方の環境でも改善されました。 ご対応いただきましてありがとうございます。
以下のようにするとテーブルの幅を固定しつつ、表示領域の幅による折り返しを抑制できます。
この件は基本的にはtablesortと関係がありません。
しかしtablesortが話に出てる来る背景は、列数が多いテーブルでtablesortを使うと▲ソートボタンがテーブル幅を押し広げるためテーブルが画面領域に収まらなくなるからだと思います。同種のトピック
また類似の件として、flex_containerでflex_boxで表を横並びにしたときに、テーブルの配列が折り返されたり、テーブルの中身が押しつぶされてしまう場合があります。
スレ建てした者です。今更ですが、改めて確認したところ直っていました。ご対応ありがとうございました。
上記のプラグイン（kanateko氏製作・公開）はGPLv3準拠なので、
そのまま実装しても、カスタマイズして実装しても、
ライセンスの問題は生じないと思います。
追伸
上記の書き方は#fold()でも通用します。
一方#accordion()では使えません。
以下のようにダブルクォーテーションで囲めば上手くいきます。
これは勘で書いて結果的に上手くいったのですが、
たぶん動作としてはダブルクォーテーションで囲むことにより、attachref内のカンマ区切りをshadowheaderの配列区切りに解釈しないようになったと思います。
shadowheaderを使いたい背景がわかりませんが、
contensのリストに出したくない見出しを制御したいならcontentsxを使う方法もあります。
ただし部分一致で作用するので上記の書き方だと"見出し10"も除外されます。
正規表現で詳細に指定できます。
あるいは逆に"filter=リストしたい見出しの文字列"という方法もあります。
#skin(default_black01)
でブラックにできますよ
編集画面はできないので要望してみるといいと思います
私もこういう機能が欲しいですね。
複数の画像を領域固定で一まとめにしておけるのでページ構成の自由度が上がります。
プラグインという形で対策いただき、一応解決しました。
（詳細はコチラ）
どうもありがとうございました。
SEOにも影響するから、SEOに熱心なWIKIWIKI運営も取り合ってくれるかも知れないですね。
確かに14は小さいかもしれません。
とりあえず応急処置として、全ページの一番上に#size(16){{{{{
一番下に}}}}}を追加するのはどうです？
いらなくなったら コントロールパネルから一括で消せますので。
現在wikiwikiにテーブル内での折りたたみが可能なプラグインはありません。
foldがインライン型(\&fold(タイトル,開/閉){内容};)に対応されればテーブル内でも記述が可能になると思います。
メリットとしては高さ方向の圧縮もそうですが、foldで折りたたんでいるうちはそれに合わせて横方向の伸張も抑制されるのではないかと思います。例えばテーブルの右端に備考列を付けたとき説明が長くなると表が横に伸びるか、幅の限界で折り返しが発生します。幅の狭いスマホなどを考慮したいときは、インライン型のfoldが対策になるかもしれません。
同じく、Sliderプラグインの導入を希望します。
他のWikiサイトのプラグイン導入が権利的に難しいのであれば、WikiWiki様独自でslickのようなプラグインを開発していただきたいです。
一つの項目に対して複数の画像を提示しながら多角的に説明できるようにしたいので、「画像(ファイル)＋テキスト」を可能としていただけると嬉しいです。
ご検討をお願いします。
そうなんですね。特に不便を感じていないので、現状でも構いません。
WIKIWIKIが運営するWIKIWIKIとzawazawaのみに対応するというのもありかなとは思います。
対応しない方がいいです。
外部リンクが対応していない理由は、恐らくスパムや対立荒らしがあるからだと思います。
例えば、FrontPageに「引っ越しました。新wikiはこちら」と書いて誘導し、広告収入を得る業者がいます。
ちゃんと管理人が管理されているwikiならば大丈夫だと思いますが、全部のwikiに適用されるのは危険ですね。
賛成です。
既存のtable_editは別ページの用意が必要で一手間あったのですが、それが解消されます。
また別ページ呼び出し系でなくなるので、キャッシュの問題も解消します。
編集機能も十分で、さらに表計算機能もあるようで、従来スプレッドシートで計算して転記してたケースが楽になるかもしれません。
既存のtable_editも含め編集可能テーブルは、wiki記述に不慣れな人でも編集に参加しやすいのが良いところです。
例えば自分で表の埋められるところは埋めて、わからないところは他の人にお願いしたりすることがあるのですが、table_editにしておくと編集に参加してくれたりします。
テーブルに限らず閲覧者の多くがwiki記述を理解しておらず、コメントはするけど編集方法を調べたり勉強したりしてまではやらない人が多い気がします。また失敗を恐れて手を出さない人も多いと思います。
table_editはある意味メニュー形式なのでその辺のハードルが下がります。
スマホ画面でも編集しやすいと思います。
wikiを分かってる人間でも巨大な表を直接編集するとき、||||||||こんな風に並んでるとどこが何列目かわからなくなりプレビューと編集を行ったり来たりします。table_editを使うと編集したい行と列の位置が明確になるのが良いのです。
ただ従来のtable_editは編集列が追加されて横幅が広がり折り返しになったり、用もないの編集ボタンをアピールしたくなかったり、予め別ページで作り込まなければならなかったりとデメリットも多かったです。これがtable_edit2になればオプション記述で編集ボタンのOff/On表示を選択できたり、あるいは使わないときは//コメントアウトでプラグインを無効したりできるようになるので使いやすくなると思います。
文字置き換えの最終チェックをしていたところ、
最初の一文字目に空白がある場合、&size(20){●};となってしまいました。
(空白)口口口
(空白)口●口
(空白)口口口
↓文字置き換え後、
(空白)口口口
(空白)口&size(20){●};口
(空白)口口口
当Wikiのような攻略サイトで最初の一文字目に「空白」を利用しているページが有る場合に&font(monospace)や&sizeを使ったフォントサイズ変更には要注意ですね。
最初の一文字目に「空白」を使用した場合であれば、「○」「●」「□」「■」は通常文字と同程度の大きさになるので、改善してほしいです。
さらなるご提案ありがとうございます。
1つ目ですが、サイト全体のフォント設定を"デフォルト"→"等幅"に変更してみました。モバイル閲覧時は文字の見やすさに全く影響がなく、特定文字の○や□も通常文字と同じ大きさで大変良かったです。ご指摘どおり、PC閲覧時の文字が見にくくなっており、あえなく却下となりました。PC閲覧時でもモバイル閲覧時と同様の影響であれば、採用していました。
2つ目ですが、膨大なページ数のため、お伝えいただいたとおり変換中にタイムアウトで中断する可能性が大いにありました。有志者によって「◯」を使用するページも所々ありましたので、文字列置き換え機能を使って「○」→「◯」に変換しました。案の定、タイムアウトしましたが、すべて置き換えることに成功しました。
しかし、「□」などは機種依存文字「⬜」（正確には代替になっていない）になってしまい、閲覧環境によって、文字化けするので置き換えできませんでした。当Wikiは日本語サイトですがAnalyticsにより、毎月70か国以上から多種多様のブラウザ・利用OSでアクセスが有ることを確認しているためです。
そこで、「□」→「&size(20){□};」で文字の大きさを変更して、無理やり問題を解決することといたしました。その他文字の小さい文字についても同様です。
運営へのお願い
根本的な解決に至っていませんが、どのWIKIでも使用頻度が多いと思われる通常表示が小さくなる特定文字「○」「●」「×」などは編集時に予め、通常文字と同じ大きさにサイズ変更される仕組みがあると良いのではないでしょうか。
>> 5のように欧文フォントを削って、新たなfont-familyを新設されることにも期待したいです。
こちらの機能は、閲覧者側でカスタマイズ出来て良いですね。同じく、あると嬉しいです。
この件はサイト全体のフォント設定の選択肢をwikiwikiに増やしてもらうのが良いと思います。
和文フォント優先のfont-family。
現在選択できるfont-familyは以下。
このうちmonospaceのみが和文フォント優先で、他は全部欧文優先です。
ただmonospaceについては等幅に特化したデザインになっており文章に適してません。monospaceが有用なのは表やプログラムソースのような表現です。よってmonospace以外にも和文を優先した選択肢が欲しいところです。
例えば、現在のデフォルトのゴシックは以下の設定になってるのですが。
これの欧文フォントを削って新たに以下のようなfont-familyを新設すれば、○●×などの記号も和文フォントで表示されるようになります。
どのように見えるかは実験的に以下の方法で確認できます。
VerdanaとArialを削ってしまうと何かしらの問題があるならば、削除せずに和文フォントより優先位置を下げる対応でもよいです。
欧文フォントで記号文字コードを持ってないフォントをセット
もしあるならば、欧文フォントで記号文字コードを持ってないフォントを優先位置にセットしてもらうでも良いと思います。
ただ以前調べたときは適当ものは見つけられませんでした。
Windows10のMicrosoft IMEが古いバージョンだと、『Ctrl』+『BackSpace』ショートカットキーを使った再変換は出来たようです。Windows10の最新バージョンでも『以前のバージョンのMicrosoft IMEを使う』設定を有効化することで行えるようになるようです。参考リンク
サイト全体を一括で変える方法は二つあります。
どちらも管理者権限が必要ですが。
一つは管理メニューのコントロール→デザイン
サイト全体のフォント設定を"デフォルト"→"等幅"に変更。
まずはこれで切り替えてみて文章を含めた全体の表示を確認してみるのがよいのではないでしょうか。
ただ、テキストエディターで表示してるような見た目になり、文章は見にくいかもしれません。
もう一つは置換機能で置換する手があります。
文字列置き換え
ただし使えるケースは限定的で、例えば表などで|○| → |&font(monospace){○};|とか決まった表現のときです。
もしサイト全体の単独の"○"を全部置換しようとすると、ページが多いときに変換中にタイムアウトで中断する可能性があります。中断されるまでの変換は行われるのですが、もう一度実行して変換不足を行おうとすると"&font(monospace){○}"で変換済みのところが、"&font(monospace){"&font(monospace){○}"}"みたいに二重に変換されます。この機能は正規表現に対応してないのでこういった対応が面倒です。
そうなんですね、教えていただきありがとうございます。
>> 1 こちらの症状は入力方法をMicrosoft IMEに変更して同環境で行ったところ、再現いたしました。編集中の文字が下線がついている状態から編集エリア内外問わず、クリックした時点でフリーズします。エラーコードも>> 6と一緒です。
私の環境ではCtrl+BSしてもフリーズはしません。
ただし、例えば"めにゅー"→変換"メニュー"で確定して、Ctrl+BSすると"メニュー"の下には下線が再表示されません。
下線は表示されませんがスペースキーで再変換はできるようになります。
一般のテキストエディターや構文ハイライトではない従来のエディターでは、Ctrl+BSで下線が表示され未確定状態が明示されます。
環境
Windows10 (2004) Firefox (93.0)、 Microsoft IME
ブラウザーの設定で広告やJavaScriptは一部抑制してます。
［CTRL］＋［BackSpace］キーで直前の確定を取り消す
こちらの動作はGoogle日本語入力または、旧OSのMS-IME/MS-IME 2007になります。Windows10に搭載しているMicrosoft IMEにそのショートカットキーはありません。参考リンク
私のPCではCTRL+BSのショートカットがなぜか使えない？のですが、その代替になる「変換」キーを使ってみたところこちらでもフリーズを確認しました。
私の環境ではフリーズはしませんが、おかしな動作を確認しました。
Windows10 (2004) Firefox (93.0)、 Microsoft IME
ブラウザーの設定で広告やJavaScriptは一部抑制してます。
状況
何も書いてない白紙の状態から以下の操作
1行目に"めにゅー"とローマ字式で入力、まだ未確定状態で下線付き。
このとき2行目は以降は存在してない。
この未確定状態で編集エリアの適当な場所をクリック。
入力中の文字上や、文字のない右や下の領域をクリックしてもなにも起きない。
一見問題が無いように見えるが、クリック動作をしても"めにゅー"の下の下線が消えず未確定状態を維持してる。
通常テキストエディターなどでは、入力中の未確定状態からクリック動作をすると確定される。何か怪しい。
また、編集エリアの外の領域やブラウザー以外のWindowをクリックした場合は確定状態となり下線が消える。これは一般的な動作と一致してる。
同様の状態からダブルクリックしたとき
未確定状態の"めにゅー"の文字が消える。ふつうはクリックで確定され消えたりはしない。
しかし、文字列が消えた状態からスペースキーを押すと"メニュー"と変換された文字が再表示される。
さらにスペースキーを押し続けると、IMEの検索候補一覧が表示されると同時に、編集エリアに検索候補の一部が勝手にコピペされる。さらにスペースキーを押し続けると、どんどんコピペが増殖される。
>> 4 こちらの情報を基に同じ行為を行ったところ、構文ハイライト (β版 ver 0.1.4）にて再現され、フリーズしました。
行った内容
編集中に確定した文字列に対して、カーソル位置の直前で確定した変換をやり直すため、［Ctrl］＋［Backspace］を押した時点で該当のタブのみハングする。
chrome通常モード/シークレットモードともに同症状が発生する。
症状
スレッド元の画像と同じ「ページが応答しません」が表示されました。「ページを離れる」ボタンを押すと「エラー コード: RESULT_CODE_HUNG」が表示されました。その他のタブなどは問題なく操作できています。
環境情報
PC閲覧
Windows10Pro 20H2
Chrome93.0.4577.82（Official Build） （64 ビット）
Google日本語入力
私の場合、編集中に確定した文字列を再変換しようとCtrl+BSを押した瞬間にフリーズします。
変換中のクリックではフリーズしません。
環境はWindows10 Pro、Firefox93.0 (64 ビット)、Google日本語入力です。
返信ありがとうございます。スクショと環境情報を追記しました。
丁寧にご説明された返信ありがとうございます。
当サイトは、老舗のゲーム攻略サイトでして閲覧者の見やすさを重視してご提案いただいた方法を行いたいところですが、検索した結果、数百ページとさらに複数の該当箇所と表があります。現在、別の長期メンテナンス作業を行っています。膨大な時間を要して、とてもとても出来そうにありません。
1ページまるまるマルチラインで括ってしまうと逆に見にくくなる箇所が出てしまいます。
例：
変更前→変更後
5000～→5000~
目に止まったページのときに見つけて手が空いていたら、該当箇所に対してご提案の方法で行うか、エクセルなどに貼り付けて一括置換をしようと思います。どうもありがとうございます。
私の環境下では同様の動作を行いましたが、問題が再現されませんでした。フリーズ時のスクリーンショットや環境情報があると運営側および、サポーターにとって助かるかもしれません。
一部の記号フォントが小さくなる問題は、以下の方法で対応ができます。
ただこのmonospaceは記号表記の統一感は出ますが、日本語フォントとしての見栄えは今一つかもしれません。
こだわるならインラインで部分的にフォントを変えるなど手を掛ける必要があります。
一部の記号が小さく表示される問題は、私が理解してる範囲では、wikiwikiで設定してるfont-famliyの優先順によるものです。
例えばフォントを特に指定しないときは、以下の並びの左から順に使われるフォントが決まります。
概ね半角の英数字はVerdana, Arialなどの欧文フォントが使われ、日本語などの全角文字は欧文フォントで表示できないのでHiragino系やMeiryoなどの日本語文字コードに対応したものが使われます。
複数候補の内どれが使われるかはそれぞの環境により異なり、先頭から読み込んでいって自身のOSにインストールされてるフォントが自動で選ばれます。
記号については扱いが複雑で、例えば
"●"はVerdana内に存在するのでこれが使われます。欧文フォントなので小さく表示されます。
"○"はVerdana内は存在しないがArialにはあるのでこれが使われます。これも欧文フォントなので小さくなります。
"△"は上記いずれも持ってなく、Hiragino(Mac系)かMeiryo(Win系)の日本語フォントで表示さるため大きくなります。
日本語環境では全角記号は全角で表示して貰いたいところですが、欧文フォントが中途半端に文字コードに対応してるために日本語フォントが食われた形になってます。
monospaceで記号が意図したように表示されるのは、monospaceのfont-famliyが以下のように設定されてるからです。
先頭に並んでるMS GothicやOsakaは日本語に対応してるため基本的にこれらが使われます。ただmono系は等幅のフォントなので、記号は良いかもしれませんが文章表現には向いてないかもしれません。
関連リンク
参考画像を貼っておきます。
PC閲覧時
モバイル閲覧時
いただいたヒント先とwikiwikiのhtml出力を見て推定できました。おそらく以下の機能ではないかと。
tablesorter
詳細な説明があります。CtlrとShiftキーの説明も載ってました。
そしてソートをリセットする機能も書かれており以下です。
sortReset
表の外にボタンを埋め込む感じなりますが、たとえばwikiwikiで表現するなら以下のようでしょうか。
表外にResetボタンが出現し、押すと表全体がリセットされる感じです。これならスマホでも操作できます。
欲を言えばShiftで複数列ソートができることが分かったので、列毎にリセットしたいところですが機能本体にそういったものはなさそうです。
そしてこのtablesorterは単なるソート機能ではなくテーブル機能をかなり拡張できるようです。
例えばフィルターとかヘッダー固定とか、accordionのように行をまとめたりとか。
Option指定で機能をOnにすればいいだけのやつは使えるようにしたいです。
WIKIWIKIの方には特に記述を見つけられませんでした。
自分はsWIKI（別のレンタルWiki）のページでShiftクリックを知り、WIKIWIKIの方でも試してみたらできた、という感じです。Ctrlクリックは他にも何かできないかなーと、いじっていて発見しました。
これは気づきませんでした。ありがとうございます。
tablesortってどこかで仕様が公開されてるのでしょうか。
ついでにShiftキーを押しながらだと複数列ソートできますが、これも携帯端末だとできないので欲しいです。
Windowsなら、Ctrlキーを押しながらソートボタンをクリックでリセットされます。
でも携帯端末ではできないようなので欲しいですね。
縦スクロールバーが2重表示される件について、当方の環境でも改善されました。
ご対応いただきましてありがとうございます。