[HOME]  [現在掲示板へもどる]     [全部表示 会議室風]  [最新100]  [最新50]   [新着40]    [全部表示 保存用]
番号順 最新50記事     FGALVZ  

10160/10158 BQO00549  konno            Re^2: 新着情報の更新
( 1) 22/01/25 00:04 10159:としきさんへのコメント
> この問題、ご紹介いただくまで、私も全く知りませんでした。一部ではかなり古く
> から有名だったようで、6年前とかの記事が検索でヒットしたりもしました。

私も別窓ジャンプがやりたくて検索して、初めて知ったのです。
としきさんは知っているものだとばかり思っていました。(^^;

> で、まぁ、対処するのは悪いことではないというか、ぜひやるべきだと思うところ
> ではありますが、ここwforum.cgiでもこのコードはいくつも使われているはず。
> ま、スクリプトを検索していちいち書き換えれば済むことではありますが。

あう、気が付きませんでした。(^^;
検索すると、自動リンクのルーチンで一か所
 target='_blank'
	  ↓
 target='_blank' rel='noopener noreferrer'

 target=\"_blank\" が、5箇所
	↓
 target=\"_blank\" rel=\"noopener noreferrer\" 

直してみました。夜中にテストしてみようかな。

> でも、以前、たった5ヶ所ばかり検索して書き換えるだけで導入可能なスパム対応
> のプレビュー反転をにも二の足をふまれていたkonnoさんのことですから、

うう、そ、それは、そのうち・・・・;;;


10161/10158 DGF01024  めざら           Re: 新着情報の更新
( 1) 22/01/25 22:21 10158:konnoさんへのコメント コメント数:1
参照先:http://mezala.la.coocan.jp/
脆弱性以前に,アクセシビリティの問題って話も…
(まぁ,好きずきですけど.)

10162/10158 CXB00940  としき           Re^2: 新着情報の更新
( 1) 22/01/26 00:21 10161:めざらさんへのコメント コメント数:1
参照先:http://toshiki.la.coocan.jp/
> 脆弱性以前に,アクセシビリティの問題って話も…

うふふふふ〜
konnoさんにとっては、それは論外、いや眼中外。
だと思う。過去の経緯から。


10163/10158 BQO00549  konno            Re^3: 新着情報の更新
( 1) 22/01/27 00:47 10162:としきさんへのコメント コメント数:1
> > 脆弱性以前に,アクセシビリティの問題って話も…
>
> うふふふふ〜
> konnoさんにとっては、それは論外、いや眼中外。
> だと思う。過去の経緯から。

うう、たぶん私、この単語を理解できていないのかもしれません。

#何を言っているか分からない状態


10164/10158 CXB00940  としき           Re^4: 新着情報の更新
( 1) 22/01/30 03:14 10163:konnoさんへのコメント コメント数:1
参照先:http://toshiki.la.coocan.jp/
> うう、たぶん私、この単語を理解できていないのかもしれません。

単語の意味は大した事はないのですよ。
直訳すれば、接近しやすさ、ということ。
ここでは、情報への接近のしやすさ、ということですかね。
目の不自由な人だろうと手の不自由な人だろうと、同じ情報にアクセスできるように
しよう、というくらいの意味合いです。
で、一応、target='_blank'を使うというか、新しいウィンドウを開く形のリンクは
アクセシビリティ上よろしくない、というのが業界の定説。
なぜそういわれているかというと、業界の標準が確立されつつある21世紀初頭、
または20世紀末かもしれませんが、いろいろな調査が行われたわけですよ。その
結果、初心者とか高齢者は新しいウィンドウが開かれたということを認識しづらい、
ということがわかった。
また、新しいウィンドウだと、当然ながら戻るボタンが効かない。そして、ウェブ
の利用者は、結構な頻度で戻るボタンを使う。
これらのことから、新しいウィンドウを開くのはアクセシビリティにおいてよろしく
ない、ということになりました。
私自身はタブブラウザのない当時から、リンクを右クリックして別ウィンドウで開く
ようなことを普通にやっていましたから、新しいウィンドウが自動で開かれるのが
初心者向きでない、ということを全く知りませんでした。その代わり、リソースが
たりないだのなんだの、という話になっていったりしたわけです。

それから20年くらいたった現在。
当時とはウェブ環境もだいぶ異なっております。
まず考える必要があるのは、スマホでのアクセス。
target='_blank'ってスマホのブラウザではどうなるでしょうか。
というのが最大の論点のひとつ。
一方で、パソコンからのアクセスの場合。
戻るボタンが効かない、というのは全く変わっていません。
ところが、新しいウィンドウが開かれたことの認識、という点は大きく変わった。
当時はパソコンの解像度が低かったため、ブラウザを全画面で使っている人が多く、
そのため、新しいウィンドウが開かれたことに気づきにくかったりしたわけです。
でも、最近では、パソコンの解像度の向上でブラウザをウィンドウ表示で使う人が
増えて新しいウィンドウが開かれたことに気づきやすくなっただとか、そもそも
タブブラウザが普及して、新しいウィンドウではなく新しいタブで開くようになった
といった変化があるわけです。
さらに、初心者というのは常に一定数いるわけですが、当時の高齢者と違い今の
高齢者はそれなりにパソコンに触れてきているわけで、パソコンに不慣れなことに
よる操作性の低下というのは当たらなくなってきているわけです。
こういったことから、昔に比べれば、いささかではあるものの、新しいウィンドウを
開くことによるアクセシビリティの低下度は少なくなったはず。
とはいえ、アクセシビリティが下がるのは間違いないことだから、新しいウィンドウ
を開くコードは極力取り除くべし、という考え方はそれなりに尊重したい。
ただ、上にも書いたとおり、私自身が新しいウィンドウを開きまくる人だから、私の
サイトではあまり気にしていません。ということを自覚しています。
自覚的に気にしていないというのも変かもしれませんが。

確か、めざらさんのサイトは、推奨されているほとんどのアクセシビリティ標準を
守っているのではなかったかな。掲示板は、WebForumのシステム上、どうしても
クリアできない部分があったような気もするけど、たぶん、99%以上の準拠率
だと思う。もしかしたら100%かもしれないし90%かもしれないけど。
一方で、うちのやしきは、60〜80%くらいの準拠率ではないかなぁ。
ぎりぎり及第点というか。
もっとも、世界的な大企業のサイトでも100%満足していなかったりするわけで、
とりあえず自己満足というか、これ以上の向上心はない。

ひるがえって、konnoさんのサイト。
きちんと全部を見たわけではないけれど、ざっくりいって、準拠率は20〜40%
くらいではないかなぁ。すなわち、大いに改善の余地がある、ということ。
だけど、konnoさんは、この手の話は嫌いだったよな〜、という気がしなくもない。
だって、アクセシビリティを本当に向上させるなら、ここの掲示板だけを取ってみても、
やるべきことは山のようにある、と思う。
でも、やる気はないでしょ?

10165/10158 BQO00549  konno            Re^5: 新着情報の更新
( 1) 22/02/01 00:31 10164:としきさんへのコメント コメント数:1
> ひるがえって、konnoさんのサイト。
> きちんと全部を見たわけではないけれど、ざっくりいって、準拠率は20〜40%
> くらいではないかなぁ。すなわち、大いに改善の余地がある、ということ。

うう、そんなに低いんですか。

> だって、アクセシビリティを本当に向上させるなら、ここの掲示板だけを取ってみても、
> やるべきことは山のようにある、と思う。
> でも、やる気はないでしょ?

うーん、やる気がないというより、やる必要を感じないのでしょうね。
私の個人掲示板なので、私が使いやすいようにするのが優先しています。
そもそもこういう話は個人ではスキルの問題もあって無理がありますし。

今はブラウザが文字や画像も拡大縮小サポートしているので、この方向でいいのでは。
別窓表示も今どきのスマホはほぼ対応しているらしいですね。


10166/10158 CXB00940  としき           Re^6: 新着情報の更新
( 1) 22/02/01 13:26 10165:konnoさんへのコメント コメント数:1
参照先:http://toshiki.la.coocan.jp/
> 私の個人掲示板なので、私が使いやすいようにするのが優先しています。

ここが重要な点なのでしょうね。
一瞬、マーケットインよりもプロダクトアウトを志向するkonnoさん、という妄想も
頭をよぎりましたが、最大の需要家にリーチするサービス展開というのは、考え方
として非常によく理解できます。
うちのサイトの場合、最大の利用者が自分だという事実はありますが、でも、私の
書いたものを他のお客様に読んでもらいたいとか、掲示板では、他のお客様が書いた
ものを私が読みたい、という欲求があるものですから、できるだけ多くのお客様を
呼び込もうとしているわけですよ。そして、場合によっては、私の手から離れた
お客様同士でのコミュニケーションを眺めていたい、だとか。
めざらさんの場合は、それこそ、もっと先を見ているかのよう。
メタバースほどではないにしろ、機械可読性というか、自分のサイトをコンピュータ
で加工されてもいいから、最終的には他の人々へ最大限のサービスを提供する、と
いう感じに私には見て取れる。要は、最終目的地は他の人々。
結局のところ、最終目的地が自分である私やkonnoさんとは次元が違う、というか。

ただ、konnoさん、自分だけで使うというのなら、別にオープンな掲示板でなくても
いいのではないでしょうか。もちろん、自分専用の完全なクローズの掲示板システム
でもいいし、例えばgoogleをはじめとした検索システムに引っかからないような細工
を施した半クローズなシステムというのも、ほんの1行、数十バイト追記するだけで
容易に構築できるわけだし。

> そもそもこういう話は個人ではスキルの問題もあって無理がありますし。

そこまで高スキルは必要ではありません。
WEB技術者でもなんでもない一般人のめざらさんが容易に実装できているわけです。
というか、今までここの掲示板を「日々改造」してきたkonnoさんのスキルレベル
からしたら、容易というレベルではないはず。
「朝飯前」とか「おちゃのこさいさい」という形容詞が適切だと思う。
もちろん、必要なら、私からもサポートや提案はさせていただきます。

ま、最終的には、スキルの問題はなく必要性の問題でしょう。
そして、公開するのであれば、JIS規格を始め様々な標準には準拠していたほうが
良い、ということで。

> 今はブラウザが文字や画像も拡大縮小サポートしているので、この方向でいいのでは。

悪くはないでしょう。
メジャーな複数のブラウザでの表示の確認を怠らなければ。
ただ、

> 別窓表示も今どきのスマホはほぼ対応しているらしいですね。

最初に戻りますが、別窓表示になるがゆえにアクセシビリティが下がる、という問題
は、やはり厳然として存在していそうな気がする。気のせいかも。


10167/10158 BQO00549  konno            Re^7: 新着情報の更新
( 1) 22/02/01 23:54 10166:としきさんへのコメント
> ただ、konnoさん、自分だけで使うというのなら、別にオープンな掲示板でなくても
> いいのではないでしょうか。もちろん、自分専用の完全なクローズの掲示板システム
> でもいいし、例えばgoogleをはじめとした検索システムに引っかからないような細工
> を施した半クローズなシステムというのも、ほんの1行、数十バイト追記するだけで
> 容易に構築できるわけだし。

アクセスが欲しいのになんでわざわざ検索に引っかからないようにするんですか。(^^;
まあ、アクセスが欲しいならアクセシビリティ対応しろって話にはなりそうですが。(^^;

> ま、最終的には、スキルの問題はなく必要性の問題でしょう。
> そして、公開するのであれば、JIS規格を始め様々な標準には準拠していたほうが
> 良い、ということで。

どうも私は必要を感じた時だけ火事場のバカ力的な集中力を発揮することがあったようです(過去形)

# 全集中、火事場の呼吸、脳活性の型!!

ということで、今の私には過度な期待をしてはいけません。

> 最初に戻りますが、別窓表示になるがゆえにアクセシビリティが下がる、という問題
> は、やはり厳然として存在していそうな気がする。気のせいかも。

これはありそうですね。



10168/10168 BQO00549  konno            V_csr.def Ver07
( 1) 22/02/02 01:04 コメント数:1
V_csr.def Ver07 を VZマクロの部屋に置きました。

2018に V_cursor.def Ver06 としてUPした縦カーソルマクロです。
 #8583: V_cursor.def Ver06 投稿者: konno   2018/11/11(日) 

今回は、今までよりも常駐レベルのアップが出来ました。
今までは、ファイルオープンなどの操作のたびに常駐解除されて使い勝手が悪いと感じていました。
常駐終了時に変数 gv の初期化もしてなかったので、それも直しました。

数日前、目が覚めたら、目からうろこが落ちたのです。
「&c 常駐って、編集モード以外でも動くんじゃね?
 そうだ、V_cursor マクロを直そう!」

;	(s)?.				; 編集モード意外で終了

これをコメントにして

	(s)??&>				;★変更 2 編集モードのみ縦線を引く

編集モード意外なら縦線を引かないようにしたら、割と問題なく動くんですね。
ただ、このままでは一部のマクロを実行後カーソル位置などがおかしくなります。

試行錯誤した結果、ネストの変るマクロ実行の後は不具合が出ることが分かりました。
「それなら、ネストを監視して、その数値が変わった時だけ常駐解除すればいいんじゃね?」
と思って、変数 uu をネスト監視用に追加して、大体下記のようにしました。

:c
	&05				;★変更 縦ラインの色変更(パッチ当て)
;	(mi==2)?cc$A0,?cc$90, m=mi,	; INS key ON青/OFF緑
;	&04 r.0=cc,			; 縦ラインの色変更(パッチ当て)
;	c=vp.8,				; c使いまわし

:r
;	(s)?.				; 編集モード意外で終了
	uu=sp-pu,			;★追加 ネスト監視用
;	(mi!=m)?>c			; INS key ON/OFF
	(mi!=m)?&05			;★変更 INS key ON/OFF
;	&>				; 2 縦線を引く
	(s)??&>				;★変更 2 編集モードのみ縦線を引く
	&c				; === 入力待ち ====
	(uu!=sp-pu)?{gv0,&d .}		;★追加 ネストが変ったら終了

STKHLP で問題が出る変数 v も vv に変更して、問題無くなりました。
ちなみに、ネストの変わるマクロとは、自作のヘボマクロです。(;_;)
 F06 を置き換える tagl.def v.05 とか
うーん、何が悪いんだろう。バグかも。

和生さんも最近お見掛けしないし、このマクロのユーザーはもう私一人かも。(;_;)
ダウンロードカウンターでユーザー数確認するために、マクロ部屋に置いています。
どなたか、これはマズイとか、もっとうまい方法をご存じでしたらご教示ください。m(__)m

# 夢の呼吸、幻の型!!
# おのれは善逸か? 寝ている時に脳が活性化するとか?


2022-02-02 Ver07 V_csr.def に変更 常駐レベルアップ 変数 v を vv に 変数 uu ネスト監視用
2018-11-11 Ver06 V_cursor.def に変更 [INS]キーのON/OFF で縦カーソルの色を変更
2016-03-31 Ver5 三太クロス合体(^^;  ほぼ完全版
2016-03-28 Ver4 縦分割の右対策 その他
2016-03-26 Ver3 v:縦ラインの長さちょい変更(v0=wy)v1=1行 v2=上下プラスの3行 以降は同様
		  フリーカーソル完全対応 縦ラインの色変更 by wanama★
2016-03-25 Ver2 v:縦ラインの長さ(v0=wy)可変でスピードUP フリーカーソル対応
2016-03-22 Ver1 V_line.def wanama氏とEPI氏二つのマクロを悪魔合体!!


10169/10168 BQO00549  konno            Re: V_csr.def Ver07a に差し替え
( 1) 22/02/05 18:18 10168:konnoさんへのコメント コメント数:1
V_csr.def 起動中にファイラーからファイルを読み込もうとすると

"〇〇〇〇"は入力できません

と表示されてファイルが開けない時がありました。
キー入力のループに問題があるのではと考え

:r
;	(s)?.				; 編集モード意外で終了
	uu=sp-pu,			;★追加 ネスト監視用
;	(mi!=m)?>c			; INS key ON/OFF
	(mi!=m)?&05			;★変更 INS key ON/OFF
;	&>				; 2 縦線を引く
	(s)??&>				;★変更 2 編集モードのみ縦線を引く
	&c				; === 入力待ち ====
	(uu!=sp-pu)?{gv0,cm0,&d .}		;★追加 ネストが変ったら終了

これを ↓ のように

:c	&05				; 縦ラインの色変更(パッチ当て)
	uu=sp-pu,			; ネスト監視用

:r	(s)?>L				; 編集モード意外なら&cにループ
	(mi!=m)?&05			; INS key ON/OFF
	(s)??&>				; 2 編集モードのみ縦線を引く
:L	&c				; === 入力待ち ====
	(uu!=sp-pu)?{gv0,cm0,&d .}	; ネストが変ったら終了
	(s)?>L				; 編集モード意外なら&cにループ

このように変更したらファイルは開けるようになりました。
VZマクロの部屋のマクロは、Ver07a に差し替えました。

http://tamaneko.world.coocan.jp/vzmac.htm



10170/10168 BQO00549  konno            Re^2: V_csr.def Ver07b に、再差し替え
( 1) 22/02/06 21:49 10169:konnoさんへのコメント
今度は外部マクロが実行できない? だったかな?
違う不具合が出てきました。
キー入力のループに問題があるのではと考え

> :L	&c				; === 入力待ち ====
> 	(uu!=sp-pu)?{gv0,cm0,&d .}	; ネストが変ったら終了
> 	(s)?>L				; 編集モード意外なら&cにループ

これを ↓ のように

:L	&c				; === 入力待ち ====
	(uu!=sp-pu)?{gv0,cm0,&d .}	; ネストが変ったら終了
;	(s)?>L				; 編集モード意外なら&cにループ

このように変更したら問題無くなったようです。
VZマクロの部屋のマクロを、Ver07b に差し替えました。

http://tamaneko.world.coocan.jp/vzmac.htm


# 日替わりの呼吸、変転流転の型!


# いいえ、蟲と共に生きる定めなのです。



10171/10171 CXB00940  としき           掲示板スクリプトのバグ
( 1) 22/02/14 13:48 コメント数:2
参照先:http://toshiki.la.coocan.jp/
ここの掲示板、これはちょっとまずいかな、というバグに気がつきました。

どれでもいいのですが、2発言以上でツリーを構成している個別発言を表示すると、
返信フォームの上に関連一覧ツリーが表示されますよね。これ、1発言だけのツリー
では表示されないはずです。
で、このツリーの表示が乱れる、というのは以前から指摘済みの、いわゆる既知の
バグです。今回、新たに気がついたのは、このツリーのルートの発言のリンクが
正しくない、という問題。なんか、過去ログを開こうとしてこけているような感じの
表示になっています。

ちょっとこの辺、ツリー表示を含めて、そろそろ本腰を入れられたほうがよろしい
のではないかと愚考する次第。


10172/10171 BQO00549  konno            Re: 掲示板スクリプトのバグ
( 1) 22/02/14 21:14 10171:としきさんへのコメント コメント数:1
> どれでもいいのですが、2発言以上でツリーを構成している個別発言を表示すると、
> 返信フォームの上に関連一覧ツリーが表示されますよね。これ、1発言だけのツリー
> では表示されないはずです。
> で、このツリーの表示が乱れる、というのは以前から指摘済みの、いわゆる既知の
> バグです。今回、新たに気がついたのは、このツリーのルートの発言のリンクが
> 正しくない、という問題。なんか、過去ログを開こうとしてこけているような感じの
> 表示になっています。

うーん、言わんとしていることが分からないです。
野ざらし言#4415 も、板塀#3744 も同じように見える気がするのですが。



10173/10171 CXB00940  としき           Re^2: 掲示板スクリプトのバグ
( 1) 22/02/15 00:22 10172:konnoさんへのコメント コメント数:1
参照先:http://toshiki.la.coocan.jp/
> うーん、言わんとしていることが分からないです。

適切な表現ができず申し訳ない。
今回、話題の対象としているのは、mode=msgviewでの表示のことです。

> > どれでもいいのですが、2発言以上でツリーを構成している個別発言を表示すると、
> > 返信フォームの上に関連一覧ツリーが表示されますよね。これ、1発言だけのツリー
> > では表示されないはずです。

例えば#10172、このリンクをそのまま開くとmode=allreadになりますよね。
そうではなく、mode=msgviewで開くと、返信フォームの上に関連一覧ツリーという
のが表示されます。よね?
一方で、例えば#10153、こちらはmode=msgviewで開いても、返信フォームの上に
関連一覧ツリーは表示されないはず。
まず、ここまでよろしいでしょうか。
もしここが違っているとなると、私のほうの環境に問題があるということになります。
と、こんな7行にもなるようなことを適当に略した結果が、上記3行の引用部分です。
つまり、私の表現力が足りないということで。

そしてさらに次。

> > バグです。今回、新たに気がついたのは、このツリーのルートの発言のリンクが
> > 正しくない、という問題。なんか、過去ログを開こうとしてこけているような感じの
> > 表示になっています。

上記で触れた関連一覧ツリーの部分の話です。
下三角印をクリックすると、mode=allreadでツリー一括表示になるかと思います。
その右隣、ツリーのルート発言の部分、ここをクリックした場合の挙動がおかしい、
ということに気がつきました。実際にクリックしてみると、なんか過去ログを開く
ような感じの動作となります。
ということでお分かりいただけます?
あぁ、ここも、きちんと書こうとすると6行にもなることを、あまりにも適当に
書いたからたった3行になってしまったんだな。
やはり、私の修行が足りない模様。

ということで、もしまだ私の書いたことがわからなければ、ご指摘ください。
なんとかkonnoさんにご理解いただけるべく、さらにブラッシュアップを心がけたい
と思います。
でも、そろそろ私の表現力も限界。
森林限界を抜けて、頂上が見えつつあったりします。
#なんのこっちゃ


10174/10171 BQO00549  konno            Re^3: 掲示板スクリプトのバグ
( 1) 22/02/17 01:17 10173:としきさんへのコメント
> 一方で、例えば#10153、こちらはmode=msgviewで開いても、返信フォームの上に
> 関連一覧ツリーは表示されないはず。
> まず、ここまでよろしいでしょうか。

これは理解したつもりですが、最初の話では

> どれでもいいのですが、2発言以上でツリーを構成している個別発言を表示すると、
> 返信フォームの上に関連一覧ツリーが表示されますよね。これ、1発言だけのツリー
> では表示されないはずです。
> で、このツリーの表示が乱れる、というのは以前から指摘済みの、いわゆる既知の
> バグです。

こう書かれていたので、この動作が既知のバグだとの指摘だと思いました。
でも、この動作は、

> 野ざらし言#4415 も、板塀#3744 も同じように見える気がするのですが。

と返答したように、私には全部同じ動作に見えるのです。
だから、これはベースのKENT掲示板の仕様だろうと思ったのです。

> 上記で触れた関連一覧ツリーの部分の話です。
> 下三角印をクリックすると、mode=allreadでツリー一括表示になるかと思います。
> その右隣、ツリーのルート発言の部分、ここをクリックした場合の挙動がおかしい、
> ということに気がつきました。実際にクリックしてみると、なんか過去ログを開く
> ような感じの動作となります。

ああ、やっとわかりました。
前半の話で混乱して、キチンと理解できていませんでした。

> 今回、話題の対象としているのは、mode=msgviewでの表示のことです。

これですね。
確かに、ツリーのルート発言の部分をクリックすると、表示に失敗していますね。
完全なバグです。
これは返信の記事を書く時はクリックしないので、実用上は問題ないかと思いましたが
この記事を書くときにルートの発言を参照しようとして罠にはまりました。(>_<)

なるべく早急に対処します。
ご指摘ありがとうございました。m(__)m


10175/10171 BQO00549  konno            掲示板スクリプトのバグ 修正しました
( 1) 22/02/17 19:30 10171:としきさんへのコメント コメント数:1
> どれでもいいのですが、2発言以上でツリーを構成している個別発言を表示すると、
> 返信フォームの上に関連一覧ツリーが表示されますよね。
> 今回、新たに気がついたのは、このツリーのルートの発言のリンクが
> 正しくない、という問題。なんか、過去ログを開こうとしてこけているような感じの
> 表示になっています。

私の読解力が落ちていて、理解するのに時間がかかってしまいましたが
#10099 で指摘されて修正した時に、間違って過去ログへのリンクにしていました。
親記事のはずが、過去記事のコメントになっていたので気が付きました。
過去ログでは返信できないので当然エラーになりますね。(問題はそこじゃない?)

リンク先のミスは修正しました。
ご指摘ありがとうございました。

# 限界集落は過疎化よりボケが問題?



10176/10171 CXB00940  としき           Re: 掲示板スクリプトのバグ 修正しました
( 1) 22/02/17 20:47 10175:konnoさんへのコメント
参照先:http://toshiki.la.coocan.jp/
> リンク先のミスは修正しました。

直っていますね。
どうも私の表現力が稚拙だったために、余計な混乱を招いてしまったようです。
申し訳ありませんでした。

あとはツリー表示の改善。もう一息、がんばってください。


10177/10177 BQO00549  konno            VTDOSで[ESC]I "カーソル位置へ挿入"不具合
( 1) 22/02/21 22:10 コメント数:2
めざらさんの掲示板 野ざらし言#4609 で今話題になっていますが
VZの [ESC]I "カーソル位置へ挿入"マクロで不具合の事例があるようです。
私も手持ちの生ログで実験してみましたが、VTDOS環境で不具合が再現しました。

以下、野ざらし言の書き込みを再掲します。

--------------------------------------------

> > VZ(184B) 184B:149A 'REPNE SCASB 命令ラップアラウンド'
> > アプリケーションでエラーが発生しました。VTDOS を復帰します
> VTDOSでこれが出ると VZは強制終了になっています。
> 特定のマクロなどでたまに出るんですが、MSDOS Pleyer では動いたりするんですよね。
> 私も今回の実験で一度出ていました。

これ、VTDOS.CFG を見たら
SCASB_MODE=0 になっていました。

SCASB_MODE=1 にしたら、エラーは出なくなりましたが、動作に異常があります。
挿入ファイルが途中までしか入っていません。改行で区切られてはいますが。
381081byteのファイルに380844byteのファイルを挿入して、761925byte になるはずが
759882byte になっています。2043byte が失われました。

VTDOSでは、試した全てのVZで同じ状態になりました。
MSDOS Player や DOSVAXJ3 は問題ないです。

&t でトレースしてみたら、ブロック移動ループの途中で挿入ブロックが切れてきました。
つまり、ファイル末までブロックがかからなくなってきたということです。
そして、何回目かの #y の行削除でVTDOSが落ちました。

SCASB_MODE=1 にしても、同じ個所までしかファイル挿入されずに終了しています。
その直前の行が、1行で 4551byte ありました。

試しに、EMS無しで、XMSだけでVZ起動してやってみたら正常に終了しました。
試した全てのVZでこのマクロが正常に動作したのです。

これは、VTDOSの EMS とVZの間に問題があるということでしょうか。
この問題は、これ以降は私の掲示板で続けます。

としきさんの場合も何か参考になれば幸いです。

--------------------------------------------

わかりにくいかと思うので、もう一度現時点での結論を書くと

> VTDOSの EMS とVZの間で問題が出ることがある

と思われるということです。

これから色々検証してみたいと思います。



10178/10177 BQO00549  konno            VTDOSとXP(NTVDM)の共通点?
( 1) 22/02/26 19:34 10177:konnoさんへのコメント コメント数:1
探してみたら、こんなものがありました。

> 05665/05668 xxxxxxxx  Emmett           VZBUG(2) サイレントモード関連のバグ
> (15)   97/04/15 10:58

> ■ VZバグ大全(2):サイレントモード関連のバグ

> (A)サイレントモードでの #k または #y の反復
>  サイレントモードで、非ブロックモードでの行記憶またはカット(#k、#y)を連
>   続して実行すると、ある特定の点までくると、テキストスタックに格納される文
>   字列の最後が化けることがあります。


これは非ブロックモードの話なので、今回は違うかもしれませんが

> (B)サイレントモードでの #_
>   どうやらサイレントで実行された #_ は、特定の条件下でカーソル位置ポインタを
>   算出しまちがえるらしい。

>  このトラブルは、 #_ 直後に #? などで最終行を一度表示してやれば回避するこ
>   とができます。これは #_ 直後でなければ駄目で、#38 のあとでは遅すぎます。
 
>   ・サイレントでの #_ のあとには #? &s
>  と習慣づけておくといいでしょう。


どうやらこれが関係ありそうです。
高橋版でもこのバグは潰しきれなかったような気がします。

 [ESC]I @I "I カーソル位置へ挿入" のマクロを

;	#b #_ (ct)?{ #> #m #x }
	#b #_ #? &s (ct)?{ #> #m #x }

このようにするか、&s を取ってしまうと、改善がみられました。

前回と同じ条件で実行して、ファイルサイズが一致するようになりました。
ただし、中身はおかしくなっているようです。
これはおそらく VTDOS の EMS がらみの不具合と思われます。

この実験で、榊原版VZだけは、ファイルサイズが小さくなりました。
ファイル挿入が途中で終わっているのか、それとも?


今まで実験に使用した生ログファイルは

 280,386 wf_log.cgi
 380,844 wf_log130407.cgi
 381,081 wf_log130408.cgi

このうちの 381k のファイルの途中に 380k のファイルを挿入していました。
挿入する 380k のファイルに問題があるのか確認のため、今度は
 280k のファイルの途中に 380k のファイルを挿入する実験をしました。

そうしたら、榊原版以外の VZ は正常に終了しました。
榊原版VZだけは、ファイルサイズが2バイト大きくなりました。
改行が1つよけいに入っていました。

この現象について、野ざらし言#4651 で、めざらさんの発言

> テキストスタックに複写する際に,テキストバッファサイズの境界付近に
> たまたまラインバッファサイズを超える長い行が存在した場合の振る舞い
> (結構レア?)に係ることかもしれないですね。「新発見」かも。

これが関係しているかもしれないと私も思いました。

ただ、MSDOS Player と DOSVAXJ3 では正常に動作しているのが謎なのです。
プラットフォームのメモリ管理とVZの相性で不具合が出ているのではないかと感じるのです。
VTDOSとXP(NTVDM)の共通点は、32ビットのメモリ管理で16ビットのVZを動かしているところ?


10179/10177 BQO00549  konno            もしかして ia32 の問題絡み?
( 1) 22/02/27 15:23 10178:konnoさんへのコメント コメント数:1
前回の書き込みで

> ただ、MSDOS Player と DOSVAXJ3 では正常に動作しているのが謎なのです。
> プラットフォームのメモリ管理とVZの相性で不具合が出ているのではないかと感じるのです。
> VTDOSとXP(NTVDM)の共通点は、32ビットのメモリ管理で16ビットのVZを動かしているところ?

このように書きましたが、32ビットのメモリ管理で、ふと思ったことがあります。
ちょっと前の記事ですが

#10145:MS-DOS Player 12/30版  投稿者:konno   2021/12/31(金) 

> さっそく使ってみましたが、ia32版では、自作のアプリでエラーが出ます。
> 自作アプリとは、turbo basic の古いプログラムで、VGAでないと動きません。
> 
> 実は、今までの MS-DOS Player では、エラーが出て使えませんでした。
> 軟式さんの DOSVAXJ3 では使えていました。
> 
> ia32_x86	数字4桁の入力で、OE+2?? (??は数字によって変わる)エラーで止まる
> ia32_x64	数字4桁の入力で、OE+2?? (??は数字によって変わる)エラーで止まる


MS-DOS Player でも ia32版では16ビットのアプリでエラーが出ます。
なので、今は ia32版は使っていません。
VTDOS も、ia32 を使っているとしたら、ここに共通の問題があるのではないかと感じました。


#10157:turbo basic は VTDOSで動かない  投稿者:konno   2022/01/15

> このプログラムを、VTDOS で動かしてみましたが、動きませんでした。
> エラーログを見てみると、ログが残っていました。
> 
> 2022-01-15 16:28:00 AISYO(17BA) 17CA:0EC8 'Out Byte 0043 34'
> 
> AX=2534 BX=0006 CX=0004 DX=1F10 SI=703A DI=7070 BP=17BA DS=17CA ES=0040 FLAGS=0046
> 
> CS:IP=17CA:0EC8
> 17CA:0EB8 2E F6 06 6E 34 40 75 13 50 E8 6D 27 B0 34 E6 43 
> 17CA:0EC8 EB 00 32 C0 E6 40 EB 00 E6 40 58 CF 50 FB 32 C0 
> 
> SS:SP=17CA:0072
> 17CA:0062 00 00 00 00 40 36 CA 17 46 00 CA 17 10 1F C4 0E 
> 17CA:0072 00 01 7B 03 CA 17 06 02 F6 01 CB 01 00 00 00 00 
> 
> 2022-01-15 16:28:00 AISYO(17BA) 17CA:0EDA 'Out Byte 0043 00'
> 
> AX=0100 BX=0006 CX=0004 DX=1F10 SI=703A DI=7070 BP=17BA DS=17CA ES=0040 FLAGS=0246
> 
> CS:IP=17CA:0EDA
> 17CA:0ECA 32 C0 E6 40 EB 00 E6 40 58 CF 50 FB 32 C0 E6 43 
> 17CA:0EDA FA EB 00 E4 40 8A E0 EB 00 E4 40 86 C4 F7 D8 40 
> 
> SS:SP=17CA:0072
> 17CA:0062 00 00 00 00 40 36 CA 17 46 00 CA 17 CA 17 BA 17 
> 17CA:0072 00 01 7E 03 CA 17 06 02 F6 01 CB 01 00 00 00 00 
> 
> 'Out Byte 0043 34' と、'Out Byte 0043 00' の2つのエラーがあるみたいです。

このエラーが16ビットメモリ操作の裏技に由来するとしたら?
VZはメモリの裏技をバンバン使っているようですし。
 ia32 のメモリ管理は16ビットアプリの使用には問題があるとか?
メモリの自己書き換えなどを許さない仕様とか?

VTDOS では ia32 は使っていないというのであれば私の思い違いということで。m(__)m


10180/10177 BQO00549  konno            製品版 [ESC]I マクロのバグは、#B だった
( 1) 22/02/28 18:06 10177:konnoさんへのコメント
野ざらし言#4654 に書きましたが、ここにも再掲します。

insfile.def を見てみると、ループ中に #B を使っていません。
としきさんが、#B が怪しいとにらんでいるのは正解かもと思い
製品版の [ESC]I マクロを修正してみました。


= esci.def =

製品版の [ESC]I マクロのバグ回避は、#B を使わないこと

*m


8  [ESC]I @I "I カーソル位置へ挿入"
	?. (mr==$80)?{ &m(36) . }
	&m("カーソル位置へファイルを読み込みます")
	n=wn, c=wc,
;	#R
	#R #m					;★ 直接ファイラーへ
:A	(s)?{ &c >A }
	(wc==c)? >Z
	mr=-1,
	&s
	#W &#T(n)
:B	#W &#T(c+1)
	#b #_ (ct)?{ #> #m #x }
;	#b #_ (ct|lh)?{ #> #m }		; #x は不要  T.Tanomura 94/01/05 15:48
:C
;	#y (mb)?{ #W #< #i (ek)?? #B #W >C }
	#y (mb)??>D				;★ ブロックでなければループを抜ける
	#W #< ek[+, #i ek], #W >C		;★ #B を使わない
:D	#C &#T(n)
	#< #i (ek)?? #B
	(wc>c)? >B
 	&d
:Z	&m("")

*


これで、今まで VTDOS153 で異常が出ていたファイルも正常に処理出来ました。
サイレントのままでも、試した全てのVZで問題なく動作しました。

結論として、#B にはバグがあるということですね。
そのバグは、VTDOS や NTVDM で出やすいようだというのが今の状況です。



10181/10181 BQO00549  konno            PATHMENU.DEF の不具合修正
( 1) 22/03/02 00:05
更新した V_csr.def を使っていたら、PATHMENU.DEF に不具合が出てきました。
起動するたびにマクロバッファに新しく読み込まれる、つまり
多重起動状態になってしまったのです。

これは、V_csr.def の問題というより、PATHMENU.DEF の呼び出しの問題と思われます。
現在、VZ.DEF で

* E その他

1	vzfl+Extrmac+exmenu+vz2+PATHMENU

このようにインクルードしているのですが
VZFL.DEF では、コマンド部分に

	Q	>Q	;Pathmenu

として、マクロ呼び出しは

.:Q	&z("pathmenu") pn..37~.0-, >*	; pathbufクリア

このようになっていて、今まではこれで問題が無いと思っていたのですが
V_csr.def のような&c常駐マクロを使っていると、多重に起動してしまうようです。

そこで、以下のように修正しました。

;.:Q	&z("pathmenu") pn..37~.0-, >*	; pathbufクリア
.:Q	&Zs("pathmenu") (r)?? &z("pathmenu") pn..37~.0-, >*	; pathbufクリア
	
これで問題が無くなりました。
これが本来の呼び出し方なので、これからは手抜きをしないように心がけます。

追記
今まではインクルードしないとなにか問題があった気がしますが
この修正で、インクルードしなくて済むようになりました。


10182/10182 BQO00549  konno            ノートPCが壊れた
( 1) 22/03/31 00:25 コメント数:1
流行りのウイルスに感染したのか
はたまたロシア辺りから飛んできた流れ弾に当たったか
ノートPCが壊れてしまいました。

ブータブルドライブを入れてください的なメッセージで止まってしまいます。
MBRが壊れたのでしょうか。
SSDを外してデスクトップにUSBアダプタで繋いでも、予約領域としか読めません。

復旧できるか判らないので、とりあえず古いノートPCを使うことにしました。

・・・うう、遅いし動画も見れない、こんな環境でよくやっていたもんだ。(>_<)

# 人生シクシク、諸行無常の響きあり


10183/10183 DGF01024  めざら           DOSVAXJ3 build JP220408
( 1) 22/04/11 07:55 コメント数:1
参照先:http://mezala.la.coocan.jp/
DOSVAXJ3の新板が発表されていますね.
表示系の拡張対応というところでしょうか.

10184/10182 DGF01024  めざら           Re: ノートPCが壊れた
( 1) 22/04/11 08:38 10182:konnoさんへのコメント コメント数:1
参照先:http://mezala.la.coocan.jp/
先日,ヤフーオークションでノートPCを調達しました。
ThinkPad X280 と中古としては比較的新しい部類になります。ほぼピカピカ。

従来,会議の記録を取るのに十年くらい前に中古で調達した ThinkPad X61s を使っていたのですが,三月に会議のときに名機の誉れ高い X61s も内蔵HDDがぼわーと異音を発するようになっていましたので,そろそろ危ないと思っていました。

と言っても,再任用期間満了する三月で完全卒業だし,昨年 MicroPC を調達したばかりだし,もう携帯用PCを買うことはないと思っていたのですが,四月から始めたボランティアの休憩中に調べ物をするときに MicroPC だと能率に問題があり,B5級を調達することになったという次第です。

でも,やはり,週2回の昼休み小一時間のためには,ちとオーバースペックでしたね。
買った以上はうまく活用できればと思います。

古いのを引っ張り出してくると確かに,その「遅さ」に辟易しますね。
(遅いと感じる要因は,ページのレンダリングが追いつかないのかな,と。)

10185/10183 BQO00549  konno            Re: DOSVAXJ3 build JP220408
( 1) 22/04/11 19:32 10183:めざらさんへのコメント
> DOSVAXJ3の新板が発表されていますね.
> 表示系の拡張対応というところでしょうか.

めざらさん、どうもです。
結構変更点が多いようですね。
軟式さんのサイトから変更点を引用します。


●変更履歴
 build JP220330 (2022/3/30)

言語設定が日本語以外となっている Windows 上でも日本語ファイル名が使用できるように修正しました。
DOSBox SVN r4473 までの更新分を適用しました。ただし DOSVAXJ3 独自の修正(LFN やシェル、CON デバイス等)と干渉して修正が難しい項目については適用していません。
DOSVAX の Build 4467AX13 の一部の修正を適用しました。PS/55 関連については対応の予定はありません。

 build JP220408 (2022/4/8)

ビデオカードが S3 の設定でも XGA/SXGA の V-Text モードが使用可能になるよう修正しました。vtext/vtext2 で xga/sxga/xga24/sxga24 が指定可能になります。 それに伴い machine=dosv の設定の場合、ビデオカードは S3 となるよう変更しました。
J-3100 モードで起動した際に V-Text でのスクロール行数がおかしくなっていたのを修正しました。


古いノートPCには、そもそも入れていなかったのですよね。
早速入れてみました。
今回は、Cドライブをそのままマウントしました。
以前の環境が無いので環境を整えるのに時間が掛かりそうです。



10186/10182 BQO00549  konno            Re^2: ノートPCが壊れた
( 1) 22/04/11 21:23 10184:めざらさんへのコメント
> 先日,ヤフーオークションでノートPCを調達しました。
> ThinkPad X280 と中古としては比較的新しい部類になります。ほぼピカピカ。

おお、いいですね、うらやま。(^^;

> 従来,会議の記録を取るのに十年くらい前に中古で調達した ThinkPad X61s を使っていたのですが,三月に会議のときに名機の誉れ高い X61s も内蔵HDDがぼわーと異音を発するようになっていましたので,そろそろ危ないと思っていました。

10年持つってなかなか無いですよね、私の場合、200LX くらいですね。

> 古いのを引っ張り出してくると確かに,その「遅さ」に辟易しますね。
> (遅いと感じる要因は,ページのレンダリングが追いつかないのかな,と。)

仮想メモリ(HDD)のページングで長く待たされている感じです。
以前はわりと普通に使えていたような気がします。
OSの更新で更に重くなったのではないかと。
やはり、メモリ3ギガではもう限界のように思います。

そう思いながらも、修理か更新か、全然進展がないです。(^^;



10187/10177 BQO00549  konno            VTDOSでTPAEXT=1 は危険かも
( 1) 22/05/28 00:36 10179:konnoさんへのコメント
先日5月11日の野ざらし言#4714 の発言でVTDOS関連の情報を書きました。
こちらにも転載します。

-----------------------------------------

"> WinXP(32),VTDOS1.22(ckwvなし)"
"> 以下略。"
"> cmd+command.comのところをVTDOSに変えただけですが、結果、VZの挙動は全く変わらず。"

ええっ、VTDOS1.22 では、OK になるんですか!
私の所では、VTDOSは今まで NG だったんですよ。

それで、VTDOS1.22 を引っ張り出して、何度か試行錯誤していたら出来ました。

VTDOS122 恐らく全てのVZ共通
Bl1024*4 OK
Bl1024*5 OK

Bl がこの範囲以外では NG になります。
としきさんの場合はこれ以外でも OK ということですか。


あと、VTDOS1.53 では、エラーで落ちてしまいました。
VTDOS1.22 と何かが違うのでしょうか。
取り敢えず、メモリ関連オプションを全部コメントにしてみたら

Bl1024*4 OK
Bl1024*5 OK

OK になりました! \(^^)/ ヤッタ-
なので、今度はメモリ関連オプションを一つづつコメント外してみたら

TPAEXT=1 NG

このオプションが駄目だったようです。なので
TPALOW=1
は問題なさそうなので設定しました。

-----------------------------------------

これで大分安定しましたが、まだ何かあるかもしれません。


10188/10188 BQO00549  konno            アセンブラを1行づつ註釈(comment)
( 1) 22/06/14 23:00 コメント数:1
気分転換に「VZエディタ」で検索していたら、下記の記事を見つけました。

VZエディタ移植に当たって実施したことと成果。仮説(115) 
https://qiita.com/kaizen_nagoya/items/5551be98dcbed8f41949

ここの記事の中に

> NEC N5200というオフコンのDOS用に移植しました。

という VZを移植する話がありました。
有名な方なのでしょうが、お名前がわからなくて。

で、この方の移植の手法が、

> アセンブラを1行づつ註釈(comment)

> 画面の表示まで一応できた時点で、試験の意味を兼ねて、アセンブラのソースコードを1行づつ註釈にして、アセンブルし、リンクし、実行するという作業を繰り返しました。

これにはビックリしました。
それで私も初心に帰って、これを実践することにしました。


ソースの中で、add 命令後にキャリーオーバー処理をしていないと思える所

	add	[bp+si],cx
	jmps	tadj3

こういう所を

	add	[bp+si],cx
	jnc	cflg99			;★;; test
	mov	byte ptr [bp].atrtxt1,1	;★;; 変数 vn
cflg99:					;★;;
	jmps	tadj3

このように、キャリーオーバーなら 変数 vn を 1 にするよう追加しました。
これでアセンブル、テストデータ実行して、vn が1になるまで繰り返しました。

数十箇所試して、vn が1になる所を見つけました。
ただ、ここは正常終了時にも1になることがあり、現在追試中です。

今後の課題は、もし原因箇所が特定できても、どう対策するか、かな。(^^;




追記


お名前がわかりました。

@kaizen_nagoya(Dr. Kiyoshi Ogawa)

小川清(おがわきよし) さんですね。
 VZ倶楽部 に記事を書かれているようです。

> SF作家 高千穂遙、プログラマ 中村正三郎、マニュアル作家 西田雅明らとの連名。
> 出版記念パーティで初サインを有名人の関係者から求められた。
> 社長、著者、マクロ担当、マニュアル担当が、それぞれ3つ以上の筆名で書いている。
> 一つの筆名で書いているのでページ数が一人だけ多いように見えるのは誤解。

Wikipediaにもありました。
https://ja.wikipedia.org/wiki/VZ_Editor
^ NECのN5200への移植を書いたのは名古屋工業大学出身の小川清。 


チャレンジ精神の忍耐と勇気を頂きました、感謝します。m(__)m


10189/10188 DGF01024  めざら           Re: アセンブラを1行づつ註釈(comment)
( 1) 22/06/15 13:19 10188:konnoさんへのコメント コメント数:1
参照先:http://mezala.la.coocan.jp/
あ,調べているうちに追記が……

こちらにもプロフィールがあります.
https://researchmap.jp/kaizen


10190/10188 BQO00549  konno            Re^2: アセンブラを1行づつ註釈(comment)
( 1) 22/06/15 22:56 10189:めざらさんへのコメント コメント数:1
> あ,調べているうちに追記が……

あ、すみません、私もアップした後で検索したら出てきましたので。(^^;

> こちらにもプロフィールがあります.
> https://researchmap.jp/kaizen

こちらは仕事関連のみのようですね。VZ関係は見当たりませんね。

せっかくなので私も腐海からVZ倶楽部を引っ張り出して見てみました。
本名は載ってないようですが、タイトルでそれっぽい所を開いたら当たりでした。
「健全なソフトウエア市場を確立するために」です。(こんなんで分かるか?)
「ふな」さんがそうみたいですね、N5200 の移植話が載っているし。

30年ぶりに読んだら、まあ、懐かしいこと、 昔を思い出しますねぇ。
私もこのころパソピア16にVZを移植(英語表示のみ)してたんだなぁ。



10191/10188 DGF01024  めざら           Re^3: アセンブラを1行づつ註釈(comment)
( 1) 22/07/30 07:46 10190:konnoさんへのコメント コメント数:2
参照先:http://mezala.la.coocan.jp/
> 私もこのころパソピア16にVZを移植(英語表示のみ)してたんだなぁ。

そんな昔から移植を!?
……と思ったけど,十年くらい使い込んだ頃なのでしょうかね。
ひょっとして konno さんて T系の方だったのでしょうか。いや Dynabook 使ってると聞いたことはないものなぁ……

パソピアは最初に買う PC の候補のひとつだったのですが,嫌いな漫才師親子が CM やっていたので候補から落としたんですよね。当時は 8ビットマシンがまだ多くて,それは MSX のだったかな。いずれにせよ買わなくてよかったのですが,16は手が出なかったなぁ……。

ところで,その漫才師がタクシー運転手に訴えられたことがあって,「昔で言えば『駕籠かき』やないか」という言動が差別発言だということだったのですが,『雲助』と言ったら差別なんだろうけど,『駕籠かき』は差別用語なんだろうか……と思ったものです。まぁ,どうせ後部から運転席を蹴り飛ばすくらいのことはやっただろうから,【言動】全般の問題だったのでしょうけど。


10192/10188 CXB00940  としき           Re^4: アセンブラを1行づつ註釈(comment)
( 1) 22/07/30 11:35 10191:めざらさんへのコメント コメント数:1
参照先:http://toshiki.la.coocan.jp/
私は、パソピアは8ビットのころには候補の一つでしたが、16ビットのころは
全く食指が動きませんでしたね。ちなみに、あの漫才師親子、決して好きでは
ありませんでしたが嫌いというほどでもなく。つ〜か、CMに出てくるタレントの
好悪に影響されて何かを選んだという記憶はほとんどない。

差別発言問題は、人によって基準も違うところがあって。
私も「駕籠かき」なんて言葉が差別発言だとは全く思えない。
一方、同じく私には差別発言だとは思えない「百姓」という言葉。
うちが百姓の家系だというせいもあるのかもしれませんがね。
でも、うちの会社だと差別用語認定されていて、会社では使えない。
ちょっと不便。


10193/10188 BQO00549  konno            Re^4: アセンブラを1行づつ註釈(雑談)
( 1) 22/07/30 22:37 10191:めざらさんへのコメント
> そんな昔から移植を!?
> ……と思ったけど,十年くらい使い込んだ頃なのでしょうかね。

パソピア16用に改造したソースの日付は
1990/03/10  01:53             9,782 KEYIBM.ASM
1991/12/26  07:07            25,907 SCRNIBM.ASM

keyibm の変更はキーコードの入れ替えなので、90年ごろから弄り始めたのかな。
と思ったら、これは Ver1.53 のオリジナルソースのまま使えたようです。(^^;
1年半くらいで動く程度には移植できたようですね。

過去ログ #8486:Vz昔話  投稿者:konno   2018/11/03
で詳しく語っていました。(^^;

> ひょっとして konno さんて T系の方だったのでしょうか。いや Dynabook 使ってると聞いたことはないものなぁ……

あれ? J31 とは言っていたんですが、Dynabook とは言ってなかったかも。(^^;
職場でパソピア16を使っていたので、互換性を考えて、PC98 よりも J3100 を選んだような。

> パソピアは最初に買うPCの候補のひとつだったのですが,嫌いな漫才師親子がCMやっていたので候補から落としたんですよね。当時は8ビットマシンがまだ多くて,それはMSXのだったかな。いずれにせよ買わなくてよかったのですが,16は手が出なかったなぁ……。

ああ、思い出しました。私はCM関係なく、パソピア16のBASIC と互換性があると思ってパソピア7買いました。
互換性はあったんですが、プログラムのやり取りは外付け5インチFDDが必要で、高かったなぁ。(;_;)

> ところで,その漫才師がタクシー運転手に訴えられたことがあって,「昔で言えば『籠かき』やないか」という言動が差別発言だということだったのですが,『雲助』と言ったら差別なんだろうけど,『籠かき』は差別用語なんだろうか……と思ったものです。まぁ,どうせ後部から運転席を蹴り飛ばすくらいのことはやっただろうから,【言動】全般の問題だったのでしょうけど。

うーん、差別用語って、差別と考える人の頭の中に差別意識があるのかなと思っています。
まあ、悪意があってそういう言葉を使うから差別だと思うんでしょうね。



10194/10188 BQO00549  konno            Re^5: アセンブラを1行づつ註釈(雑談)
( 1) 22/07/30 22:45 10192:としきさんへのコメント
> でも、うちの会社だと差別用語認定されていて、会社では使えない。
> ちょっと不便。

げげ、会社で使えないとは、厳格なんですねぇ。
それで言ったら、うちの職場は、超ブラックだったかも。(>_<)
世代の違いもあるでしょうが。(^^;



10195/10195 BQO00549  konno            掲示板のメンテナンス 2022
( 1) 22/07/30 23:32 コメント数:2
スパム掃除のついでに掲示板のメンテナンスをしました。

クロム系のブラウザで、記事本文が小さく表示されるのを改善しました。

ヘッダーで、
# 本文の文字サイズ
#$b_size = '17px'; オリジナル
#$b_size = '100%'; 今までこれだった。
$b_size = '120%';  少し大きくした。

こうしたら記事本文の文字が大きくなりました。
今後も気づいたところから直していきます。


10196/10195 DGF01024  めざら           Re: 掲示板のメンテナンス 2022
( 1) 22/07/31 08:37 10195:konnoさんへのコメント コメント数:2
参照先:http://mezala.la.coocan.jp/
個人の感想(一般的なウェブアクセシビリティの観点から大きく外れていないと思いますが)を述べさせていただきますと,
特定のWWWブラウザの見え方に依存する変更は「改善」とは言わないと思います。

クロム以外のブラウザでは,とんでもなく(…という程でもないですが)大きな文字で表示されるようになりますよね。
つまり,クロム以外のユーザは排除する方向(…という程でもないですが)と言うか,少なくとも従来の感覚に変更を強いるものですね。

取り敢えず試していただきたいのが,クロムの設定→デザイン→フォントサイズを確認してみることです。
フォントサイズが「中(推奨)」となっているのが普通かと思いますが,ここを調整して手元の環境に合わせるとよいと思います。

もう十年以上経つかと思いますが,その頃から小さなフォントで表示するのが「クール」とされる時代が始まり,
年配者の反感を大いに買ったと思われるわけですが,近年,ディスプレイの解像度が高く(細かく)なり,
逆に文字が小さすぎて若者ですら読みにくいという現象も一部の環境で見られるようです。


10197/10195 BQO00549  konno            Re^2: 掲示板のメンテナンス 2022
( 1) 22/07/31 22:03 10196:めざらさんへのコメント
> クロム以外のブラウザでは,とんでもなく(…という程でもないですが)大きな文字で表示されるようになりますよね。つまり,クロム以外のユーザは排除する方向(…という程でもないですが)と言うか,少なくとも従来の感覚に変更を強いるものですね。

えっ、そんなに違って見えますか・・・
クロム系とファイヤーフォックスで確認してますが、他にチェックすべきブラウザはありますか。

> 取り敢えず試していただきたいのが,クロムの設定→デザイン→フォントサイズを確認してみることです。フォントサイズが「中(推奨)」となっているのが普通かと思いますが,ここを調整して手元の環境に合わせるとよいと思います。

なるほど、「中(推奨)」だと小さく見えるんですね。
「特大」だと大きすぎるので、「大」にしました。
$b_size = '125%'; にしていたので、110% に変えてみました。

> もう十年以上経つかと思いますが,その頃から小さなフォントで表示するのが「クール」とされる時代が始まり,年配者の反感を大いに買ったと思われるわけですが,近年,ディスプレイの解像度が高く(細かく)なり,逆に文字が小さすぎて若者ですら読みにくいという現象も一部の環境で見られるようです。

最近文字が見えにくくなって、拡大表示することが増えました。
テレビもパソコンもLEDバックライトで眩しくなったのも一因かと(いや観すぎだろ)。


10198/10195 CXB00940  としき           Re^2: 掲示板のメンテナンス 2022
( 1) 22/08/01 01:06 10196:めざらさんへのコメント コメント数:2
参照先:http://toshiki.la.coocan.jp/
会社のいつも使っている端末の、いつものFirefoxのいつもの常用環境でここを
開いたら、なんかいきなり文字が大きくてちょっとびっくり。
[CTRL]を押しながらマウスのぐりぐりを前後させて縮尺を80%にしたらちょうど
いい感じ。それから#10195を読んで、あぁなるほど、そういうことか、と。
それなら、Chromeならどうなるんだろうと、普段はあまり使っていないChromeで
ここの掲示板を見たら、確かにいい感じの大きさ。なるほど。
だけど、同じく職場にあって、普段は別の人が使っている、解像度は同じだけど
インチが小さいディスプレイに私の端末をつないで表示させてみたら、Chrome
でもやっぱりちょっと小さい。むしろ、Firefoxだと、元の設定に戻してちょうど
いいくらいの大きさ。

自宅に戻って、Firefoxからここを開いたら、職場ほど極端に大きくない。
むしろ、一回り大きくなっただけで、目の弱ってきた私にはいい感じ。
あれっ、と思ったら、#10197なのね。
ということで、

> 特定のWWWブラウザの見え方に依存する変更は「改善」とは言わないと思います。

めざらさんのこのご意見には、私もおおむね同意です。
ま、あれだ、フォントサイズを絶対指定にしてブラウザ側で表示サイズを変えられ
ないような極悪なシステムも散見される世の中にあって、サーバ側で指定する値を
どうするか、というのはある意味悩ましいものもあります。
そういう意味では、めざらさんのところの掲示板のフォント指定というかCSSでの
指定方法は、なかなかいいのではないか、と思う今日この頃。

さておき、クライアント側の設定は無限にあるわけでして、サーバ側はそんなもの
にいちいち関与することはできない、と割り切るのも一案。
この場合、本文に対するフォントサイズ設定は一切やめる。
そして、その他の文字サイズ指定は基本的に相対指定。つまり、-1とか-2を使う。
こうすれば、おおよそ万人というか閲覧者側に全ての責任を押し付けられる上に、
HTML側でfontタグを大幅に削減できるため掲示板スクリプトのメンテナンスが楽
になるし、副作用というか、HTMLの転送時間ならびにブラウザでのレンダリング
時間の縮減も図れるという副作用もあって、サーバ側もブラウザ側もみんな幸せ、
というのがちょっと前の世の中のトレンドでした。
今はどうなのかわかりませんが。

ところで、掲示板正面玄関というか、タイトル文字右側にある[-]とか[+]で文字
サイズが変えられるようになっているわけですが、それを倍率を換えるように変更
していただけないでしょうか。現状では、なかなか浮かばれないというか、扱いが
かわいそうな気がする。
もちろん、ガッツリ削除、というのが私のお勧め。
めざらさんはまた違ったご意見があるかもしれないけど。

10199/10195 BQO00549  konno            Re^3: 掲示板のメンテナンス 2022
( 1) 22/08/03 00:58 10198:としきさんへのコメント コメント数:1
> > 特定のWWWブラウザの見え方に依存する変更は「改善」とは言わないと思います。
> めざらさんのこのご意見には、私もおおむね同意です。

どうやらとしきさんにも不評のようですね。(^^;

> この場合、本文に対するフォントサイズ設定は一切やめる。
> そして、その他の文字サイズ指定は基本的に相対指定。つまり、-1とか-2を使う。
> こうすれば、おおよそ万人というか閲覧者側に全ての責任を押し付けられる上に、
> HTML側でfontタグを大幅に削減できるため掲示板スクリプトのメンテナンスが楽

そうしたかったんですが、ソースを表示するための等幅フォントがネックだったのです。
<pre>や<tt>を指定すると、既定のフォントとは違うフォントに切り替わるのです。
うちの掲示板は記事本文に<pre>や<tt>を使用しているので、記事本文だけ文字が小さく見えます。
そのフォントが小さいうえに読みづらいフォントだなと感じていたのでした。
それで、バランスを取るために記事本文のフォントサイズを変えたのです。
CSS を使えば全部解決できるかもですが、私は勉強不足なもので。

> ところで、掲示板正面玄関というか、タイトル文字右側にある[-]とか[+]で文字
> サイズが変えられるようになっているわけですが、それを倍率を換えるように変更
> していただけないでしょうか。現状では、なかなか浮かばれないというか、扱いが
> かわいそうな気がする。

現状ではリストのツリー表示だけ拡大縮小になってますね。
これはこれで面白そうですが。(^^;
色々バグもあるので、時間が取れたら直してみたいと思います。


10200/10195 DGF01024  めざら           Re^4: 掲示板のメンテナンス 2022
( 1) 22/08/03 10:36 10199:konnoさんへのコメント コメント数:2
参照先:http://mezala.la.coocan.jp/
「不評」と言いますか,突然変わると先ず手元の環境を疑うところから始めるので,
その確認が正直めんどくさいというだけの話なので,管理者の自由ではあるのですが,
「改善」という意識にちょっとだけ引っかかっただけです。(^-^)

> <pre>や<tt>を指定すると、既定のフォントとは違うフォントに切り替わるのです。

あくまでもソースなどの「みやすさ」のために,ブラウザが monospace フォントに変えますね。
一般的な印刷物でも明示的に consolas とか courier にしていると思います。
インデントの位置がずれると格好悪いですからね。ウェブでも同じです。サイズも本文より少し小さく。

> それで、バランスを取るために記事本文のフォントサイズを変えたのです。

全体のフォントサイズを変えても,preも連動するように本文に対して相対的に小さいままです。
なので,たぶんお望みのようにはなっていない可能性が高いですね。

> CSS を使えば全部解決できるかもですが、私は勉強不足なもので。

全部とはいかないかもしれませんが,取り敢えず試していただきたいのが wf_init.cgi の出力指定です。

掲示板を表示している状態で,Ctrl+U などでHTMLのソースを表示してみてください。
現状のソースの9行目に STYLE 指定がありますよね。閉じるまでが CSS の指定です。
この部分に,例えば【pre,tt { font-size:100%; }】のように出力できればよいわけです。

CGIのバージョンが違いますが,「HTMLヘッダ」という見出しを探してみてください。
「<style type="text/css">」という行を探してもよいです。ここに
pre,tt { font-size: 100%; } とか,
pre,tt { font-size: medium; } とか,
pre,tt { font-size: 1em; } とか指定すれば,pre指定時も本文とほぼ同じサイズになります。

なぜ「ほぼ」かというと,preに対して使われるフォントが異なるからです。
(本文は MS UI Gothic が優先表示で,pre に使われると思われる MS ゴシックと字形も違う。)

いずれにしても,掲示板の管理者たる konnno さんの指定次第です。

ただ,#10197 で 110% にしたと仰るが,HTMLソースでは 100% と表示されているので,
どこか別のところで何か変な指定をしている可能性も疑われます。
こういうのは,ご自身で解決していただくしかないと思われます。


10202/10195 DGF01024  めざら           Re^3: 掲示板のメンテナンス 2022
( 1) 22/08/03 17:48 10198:としきさんへのコメント コメント数:1
参照先:http://mezala.la.coocan.jp/
> この場合、本文に対するフォントサイズ設定は一切やめる。

自分のところでは,フォントサイズの絶対指定は一切排除しているわけなのです。ところが……

自分のサイトの他のページは,ブラウザごとに大きく表示が異なるということはないのに,
何故か掲示板だけ明らかに Chrome と Firefox とでフォントサイズが異なっているわけです。
一応,Edge なんかで表示しても少し違う。サイズは Chrome に近いけれど違うところもある。

ここが謎なんですね。

なので,Konno さんのお悩みの点は,本来自分(たち)の問題でもあったわけなのですよ。

…と言っても,フォントサイズの絶対指定はしていないし,本来変わらないはず。
Chrome と言えば,あるバージョンでデフォルトのフォントをメイリオにした関係で,
色々表示上のメンテナンスを各サイト管理者に強いたということはあったけれど,
ごく普通のサイトは特段の影響はなかったのではないかと思われるわけなので,
それが関係するとは思えない。

唯一思いつくのは,MS系のレガシーなフォントを優先表示フォントとして設定している場合。
Chrome でフォントごとにサイズの指定を無視するというのは考えにくいですが,
多少の調整をするという可能性はもしかするとあるのかもしれない。

CSS も万能じゃなくて,ブラウザごとに対応状況が異なっていますからね。

少しずつ実験してみたいと思います。
これが konnno さんのお悩み解決につながればよいのですけど。


ところで,BBS新着情報のページなのですが,かなり小さなフォントで行間もないので,
だいぶぎゅぎゅっと表示されているのですけど,少し大きくしていただけないでしょうか。
フォントサイズ 80% になっていて,Chromeだといよいよ縮小表示されて見えます。
あー,そうするとまた Fx でデカく表示されてしまうのか……悩ましいなぁ……

動的ページだけなのか……何だろう(?_?)


10203/10195 DGF01024  めざら           Re^5: 掲示板のメンテナンス 2022
( 1) 22/08/03 21:44 10200:めざらさんへのコメント
参照先:http://mezala.la.coocan.jp/
どうやら,Chrome の font-family 指定におけるバグっぽいものらしく,
対症療法を示す,それっぽい記載が見つかりました。
monospaceの指定だけだとフォントサイズが小さくなるらしいです。
#10202の予測は外しました。

2015-07-02
font-family: monospace;だと文字が小さくなる
https://silight.hatenablog.jp/entry/2015/07/02/214601

まだ実験中ですが,Chrome には依然として適用できていません。
そのかわり,Edge では想定に近い表示になりました。
なんでかな?

10204/10195 BQO00549  konno            CSSで pre,tt の指定
( 1) 22/08/03 22:41 10200:めざらさんへのコメント コメント数:1
> あくまでもソースなどの「みやすさ」のために,ブラウザが monospace フォントに変えますね。
> 一般的な印刷物でも明示的に consolas とか courier にしていると思います。
> インデントの位置がずれると格好悪いですからね。ウェブでも同じです。サイズも本文より少し小さく。

なるほどそうなんですか、等倍にすると横幅が伸びる分フォントが少し小さくなるのだと思っていました。

> 現状のソースの9行目に STYLE 指定がありますよね。閉じるまでが CSS の指定です。
> この部分に,例えば【pre,tt { font-size:100%; }】のように出力できればよいわけです。
>
> CGIのバージョンが違いますが,「HTMLヘッダ」という見出しを探してみてください。
> 「<style type="text/css">」という行を探してもよいです。ここに
> pre,tt { font-size: 100%; } とか,
> pre,tt { font-size: medium; } とか,
> pre,tt { font-size: 1em; } とか指定すれば,pre指定時も本文とほぼ同じサイズになります。

これは勉強になります、試してみます。


10205/10195 BQO00549  konno            Re^4: 掲示板のメンテナンス 2022
( 1) 22/08/03 22:49 10202:めざらさんへのコメント
> ところで,BBS新着情報のページなのですが,かなり小さなフォントで行間もないので,
> だいぶぎゅぎゅっと表示されているのですけど,少し大きくしていただけないでしょうか。
> フォントサイズ 80% になっていて,Chromeだといよいよ縮小表示されて見えます。

ちょっと見栄えを変えてみたんですが、フォントが小さすぎましたか。(^^;
Fx で確認していませんでした。(^^;;
調整します。m(__)m

> あー,そうするとまた Fx でデカく表示されてしまうのか……悩ましいなぁ……

あれ? うちでは、クロムの方が大きくなる・・・ 設定変えたせいか。
とりあえず大きくしてみました。


10206/10195 BQO00549  konno            BBS新着情報のページを更新 Ver0.82
( 1) 22/08/03 23:10 10195:konnoさんへのコメント
BBS新着情報のページを見栄えなど更新しました。

今回は、クロムのフォントサイズを大きくしたらBBS新着情報が大きすぎる気がしたもので
フォントを小さめにして行間も詰めてみましたが、小さすぎるとのご指摘で再調整しました。


備忘録として

・全体を <tt> </tt> で囲うとテーブル枠内の文字も一緒に少し小さくなります。

・テーブル枠内の文字サイズなどを調整するには

 <table border=1 ><tbody style='font-size:$tbsize'><tr><th>

 このような指定で出来ました。


10207/10195 DGF01024  めざら           Chrome の monospace フォントに関する指定(確定版)
( 1) 22/08/05 13:25 10204:konnoさんへのコメント コメント数:1
参照先:http://mezala.la.coocan.jp/
Chrome の monospace フォントに関するバグを回避する方法を,下記のサイト様で学びまして,
https://silight.hatenablog.jp/entry/2015/07/02/214601
うちの掲示板で試してみていたのですが,ようやく反映を確認できました。

monospaceフォントが使われることの多い要素に以下のような指定をすると,反映されます。

tt, code, kbd, samp, pre, xmp, plaintext, listing {
    font-family: monospace, serif;
}

うちの掲示板では,念のため以下のように明示的なサイズ指定も加えました。
tt, code, kbd, samp, pre, xmp, plaintext, listing {
	font-family: monospace, serif;
	font-size: medium; 
} /* Chromeはmonospaceのみの指定だとサイズが小さくなる */

うちの掲示板では,preを指定したアーティクルの背景色(薄墨)をつけているので,
Chromeで見比べてみてください。

これにより,個々の掲示板のソースでいちいちサイズ指定する必要はなくなります。
としきさんの仰るように,固定サイズ指定をバッサリ削ると自然な表示になると思います。

副作用のない指定方法を公開している,しらいと様に感謝。


なお,過去のブラウザの初期設定では,pre 要素などで小さなフォントが使われるのがふつうで,
これまでは特に疑問を感じていなかったのですが,konno さんのおかげで〈きっかけ〉ができ,
ブラウザ間の違いを改善することができました。

以前から,code や kbd などを指定した要素の表示がよろしくなくて気にはなってましたが,
おいおい解決していきたいと思います。

ありがとうございました。


10208/10195 BQO00549  konno            Re: Chrome の monospace フォントに関する指定(確定版)
( 1) 22/08/06 02:14 10207:めざらさんへのコメント コメント数:1
> Chrome の monospace フォントに関するバグを回避する方法を,下記のサイト様で学びまして,
> https://silight.hatenablog.jp/entry/2015/07/02/214601
> うちの掲示板で試してみていたのですが,ようやく反映を確認できました。

このサイトを覗いてみたら理屈が判りました。

-------------------------------------------------
等幅フォントも可変幅フォントと同じサイズで表示したい時は次のように指定します。

font-family: monospace, serif;
これはmonospaceフォントで表示できない文字はserifフォントで表示するという意味ですが、そうなることは稀です。そして、このように等幅フォントと可変幅フォントを混在させた場合、可変幅フォントのデフォルトサイズが優先されます。(つまり可変幅フォントならserif以外でも良いです。単純に一番短いserifを選んだだけなので。)
-------------------------------------------------

なるほど納得です。

> うちの掲示板では,念のため以下のように明示的なサイズ指定も加えました。
> tt, code, kbd, samp, pre, xmp, plaintext, listing {
> 	font-family: monospace, serif;
> 	font-size: medium; 
> } /* Chromeはmonospaceのみの指定だとサイズが小さくなる */

これを入れてみたら丁度良い見栄えになりました。

> これにより,個々の掲示板のソースでいちいちサイズ指定する必要はなくなります。
> としきさんの仰るように,固定サイズ指定をバッサリ削ると自然な表示になると思います。
> 
> 副作用のない指定方法を公開している,しらいと様に感謝。

掲示板の全面改修は直ぐにはできませんが、本当に感謝ですね。

> なお,過去のブラウザの初期設定では,pre 要素などで小さなフォントが使われるのがふつうで,
> これまでは特に疑問を感じていなかったのですが,konno さんのおかげで〈きっかけ〉ができ,
> ブラウザ間の違いを改善することができました。

ブラウザ間の違いをほぼ無くせるとはまるで魔法のようですね。
私が気になっていたのは、等幅フォントのMSゴシックが線が細くて見えにくい
文字が読みにくいと感じたからです。そうとう目が悪くなったようです。
なので、等幅フォントはメイリオに変えました。


10209/10195 DGF01024  めざら           Re^2: Chrome の monospace フォントに関する指定(確定版)
( 1) 22/08/06 08:38 10208:konnoさんへのコメント コメント数:1
参照先:http://mezala.la.coocan.jp/
もう黙っていようかと思ったのですが,自分の精神衛生上よろしくないので……

メイリオを指定しても所期の表示にはならないと思います。
なぜなら,メイリオはプロポーショナルフォントだから。

むりやり等幅にした Meiryo_KE とか有るようですが,
表示する人の環境になければ意味がないですし。

monospace 用に具体的なフォント名を指定するのはナンセンスかもです。

もしかすると MSゴシックも使われていないかもしれません。
調べてないからわかんないけど。(^^;

10210/10195 BQO00549  konno            Re^3: Chrome の monospace フォントに関する指定(確定版)
( 1) 22/08/07 00:58 10209:めざらさんへのコメント
> もう黙っていようかと思ったのですが,自分の精神衛生上よろしくないので……
> メイリオを指定しても所期の表示にはならないと思います。
> なぜなら,メイリオはプロポーショナルフォントだから。

言葉足らずでした。
メイリオを指定したのはブラウザのフォント設定です。

答倍フォントの設定で、一覧にゴシック系のフォントが並んでいるので色々試してみました。
見栄えが変わるので一応効いているのかと思いました。

その中で MSゴシックよりも見やすく思えたのがメイリオだったのです。
私が良く使う顔文字の記号 (^^; の「^」だけは違和感がありますが。(^^;

> 表示する人の環境になければ意味がないですし。

ブラウザの設定なので、自己満足でいいのではないかと思っています。
実際に変わっているかはわかりません。(^^;