2013/12/28(土)IE8のtable表示バグメモ

2013/12/28 26:41 PC（プログラミング）
かなり以前に書いたメモから起こしてるので、ちょっとおぼろげ。

IE8において、特定の条件下でtableタグのレンダリングに以下の問題が発生する。
問題の内容は、
・表の外枠の上罫線が欠ける
・表の外枠の左罫線が欠ける

先にコードを提示する。
IE8で以下のようなコードをレンダリングすると発生する。
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
	<title>test</title>
	<style type="text/css">
		table{
			border-collapse: collapse;
		}
		td,th{
			border: solid 1px black;
		}
		div{
			overflow: hidden;
		}
	</style>
</head>
<body>
	<div>
		<table>
			<thead>
			</thead>
			<tbody>
				<tr>
					<td>a</td>
					<td>b</td>
					<td>c</td>
				</tr>
			</tbody>
		</table>
	</div>
</body>
</html>
条件は以下の通り。

・ブラウザ: IE8
・モード: 標準モード
・tableの親divで"overflow: visible"以外を指定
・border: collapse
・空のtheadタグがある

必要十分かどうかは不明。

主たる原因は、空のtheadタグがあるから。
これを消すと罫線が表示される。

バグという表現を使ったが空theadは元々validate通らないので、IE8が必ずしも悪いわけではない。ただし他のブラウザで線が欠けるものは発見できなかった。

空theadを使うなと言えばその通りだが、IE対応かつ表の固定ヘッダ(Excelのような)を作ろうとするとsampleなどにもちょいちょい出て来るコードなので多少留意をしておくこと。
コメント（0件）

2013/11/29(金)エディタ界隈

2013/11/29 22:22 PC（プログラミング）
久々に日本語テキストエディタをさらったので雑なメモだけ。

サクラエディタから乗り換え先を探すイメージで、出来れば機能包含＋軽い＋ライセンス緩いというのがよい。

まっとうな比較は
比較 - テキストエディタ・スクリーンショット Wiki*
を見てもらうとして。

自分として乗り換えられそうな使用感を得た物だけメモしておく。
フォント周りを調べたときの副産物なのでそこら辺も。

・WZ EDITOR
シェア。ちゃんと進化してた。保有機能はすごいが、インターフェースがちょっと雑然としている。明らかに一太郎になろうとしてるっぽい。フォントを文字コードごとにかなり細かく指定できる。VerUPごとに買うのはちょっと微妙。

・秀丸
シェア。ちゃんと進化してた。高機能だし、うまいことトレンドにシフトしてるとは思うのだが、ほんのちょっとが足りない感じはする。とはいえ最有力。DirectWrite対応でかなり調整できる。複数行正規表現もかなり健康。

・newQX
まさかのQXが新生。さらにまさかの高機能。見た目やI/Fは古臭い。サクラや秀丸のいいところを敢えて無視してる感じ。地味にASCIIだけフォント切り替えにも対応。

・xyzzy
生き残ってた。案外なんでも出来る。オプションが分かりづらい！(笑) Emacsの練習とかによい。地味にASCIIだけフォント切り替えにも対応。

・otbedit
複数行正規表現に強くてフリー。

・Epsaly
・Mery
今後に期待が持てる。

・Sublime Text
新進気鋭がついに3まできた。日本語入力インラインにならないのかな？

・Vim
慣れれば。

・NtEmacs
慣れれば。xyzzyでいいかも。

総合的には秀丸が最右翼。

秀丸がかなり進化しており、サクラの進化が止まってるのでシェアウェア分くらいの差は付いたかも知れない。

WZ EDITORは購入をためらわせる何かがある。整理されてないコンフィグ周りとあのインターフェース、そして何か…　方向性が違う。他と違うI/Fにしてる理由が、改善じゃなくて単に違うことをしたいだけのような……

OtbEditはサクラから乗り換えるのに必要十分な機能を持っている。が、乗り換えるに足る明確な動機がない。

newQXはさすがにインターフェースが古いか。機能面については十分な方向に行きそうだが、もうちょっとインターフェースを何とかして欲しい。

全ての開発・書き物を一本でやれるならVim, Emacsもアリだと思うのだが実際そうではないので慣らすモチベーションが出ない。IDE使ってるし。

ということで、秀丸買うか。

ここに挙がったソフトの動向はある程度注視しつつ併用で。非秀丸ならサクラかOTbEditかxyzzyをその時の気分・用途で。WZは特に秀丸になくWZにある機能が出てきたときにだけ考える。

Vimなー、出来ることと出来ないことを誰かに全部リストアップしてもらえると気軽に移行できるんだけどなあ。
コメント（0件）

2013/11/29(金)2013年後半のプログラミングフォント事情

2013/11/29 17:05 PC（プログラミング）
以前(4～7年前？)調べたときとだいぶ状況が変わってるようなので久々にさらってみた。

前提はWindows7 64bit、WUXGA(1920x1200)モニタ環境。

日本語入力有りという使用方法を考える。

■結論
以前の調査では、
・IPAフォント類ではJISカバー率が低すぎて無理(これは誤認だった？)
・悔しいけどMSゴシックは悪くない
・とりあえずこだわるならOsakaとか？

うろ覚えだがこんな結論だった。

で、先に今回の結論を書くと、
「よくわからないのでMSゴシックを使おう」

はい、そこ物を投げない。

もうちょっと詳しく書くと、

●gdipp, MacType環境下なら → Ricty
●ClearType(DirectWrite)環境下で、
・ライセンスが怪しくても良いなら → Consolas + MeiryoKE Console(フォント合成)
・それがダメなら → Migu 1M(好みでMigMix 1M, VLゴシック)
●標準アンチエイリアス環境下で、
・記号類が半角表示でも良いなら → Consolas + (MSゴシック or MeiryoKE)(FontLink)
・ライセンスが怪しくても良いなら → MeiryoKEゴシック or MeiryoKE Console
・どれもダメなら → MSゴシック

以下調査。

■レンダリング周り
Windows環境では厄介なことにフォント選びよりもレンダリング環境を先に考える必要がある。
大きく分けて3つ。まあ想像通り一長一短あるわけで。

●標準アンチエイリアス
Windows標準機能。
コントロールパネル -> ディスプレイ -> ClearTypeテキストの調整。
チェックボックスをOFF。

[メリット]
・標準

[デメリット]
・アルゴリズムが悪いのか、ビットマップフォント以外はかなりぼけやすい。視認性が悪い。

●ClearType(DirectWrite)
Windows標準機能。
コントロールパネル -> ディスプレイ -> ClearTypeテキストの調整。
チェックボックスをON。

もしくはDirectWriteを実装したアプリケーションを使う。

[メリット]
・標準アンチエイリアスより視認性が向上することが多い。
・DirectWriteは実装によってはかなり調整可能(秀丸, FireFoxなど)

[デメリット]
・ClearType Tunerの調整範囲ではgdipp, MacTypeより劣る
・標準ClearTypeはサブピクセル描画による偽色をかなり盛るため、背景色によっては目立つ・衝突する
・上記により目が疲れやすくなる可能性あり
・標準ClearTypeは縦方向にアンチエイリアスをかけないため、横線が多い文字(漢字とかだよ！)で恩恵が薄い。

●gdipp, MacType
いわゆるgdi乗っ取り系。

[メリット]
・OS全体に影響
・調整次第だがClearType系よりも綺麗？

[デメリット]
・アプリケーション(独自レンダリングを持つ)によっては反映されない
・アプリケーション(古いゲーム等)によっては文字描画が壊れる
・一部、標準アンチエイリアス環境下で視認性が高かったフォントがかえって悪化する可能性がある
・乗っ取り系なのでおそらくリソースを食う
・gdippはカスタマイズ性低い
・MacTypeはgdippよりカスタマイズ性が高いが、インストーラがadwareだし中国製で英語になりきれてないところがある

[参考]
フォントスムージングの比較 - かえでのWebログ


■フォント
フォントの話に移る。

●欧文
まず、欧文フォントでもっとも趣味に合うのはConsolasだ。視認性が高く、0がslashed、小サイズでも読みやすい。ほとんどの文字で見分けが付く。若干l(半角エル)と1(いち)の見分けがあやしいが、許容範囲内。標準アンチエイリアス下でも高い視認性を誇る。

よってConsolasを軸にする。

Consolasライクな欧文フォントを探すと、
・Consolasオマージュでラインセンスが緩いInconsolata
・#が低いGoogle製Anonymous Pro
・MacのMenlo
・MenloライクなMeslo LG M

あたりを見つけた。ただし、MenloはWindowsに入れようがないので除外。

What are the best programming fonts? - Slant
Top 10 Programming Fonts

これらは日本語フォントとどうにかしてくっつけないといけない。

●日本語
またこれに近い欧文を備えるなり組み込んだりした日本語フォントとして、以下の物を見つけた。
・Ricty
プログラミング用フォント Ricty
・MigMix 1M, Migu 1M
M+とIPAの合成フォント
・VLゴシック
VL Gothic Font Family

M+に不足部分を補う物がトレンド。M+すごい。

最後にライセンスがあやしいメイリオ改造手段と、
MeiryoKe
Windows で見やすくて綺麗なフォント表示 ? MeiryoKe に変更し、MacType で滑らかにする | すぐに忘れる脳みそのためのメモ

さらにそれにConsolasを合成しちまえというもの。もうここら辺はライセンス的にはかなり怪しい。
MeiryoKe_ConsoleとConsolasの合成方法 - GONE WITH THE MEDICINE

●ライセンス
ライセンスを確認する。

欧文ではライセンスが緩い(改造・合成が出来る)のが、Inconsolata, Anonymous Pro, Meslo LG M。詳細は各Webを確認。

日本語系ではM+がまだ字体が足りてないためIPAで補完している物が多く、だいたいがIPAのライセンスに依存。

●欧文フォントの合成方法
欧文フォントはどうにかして日本語とくっつける必要がある。

フォント自体を合成して新しい一つのフォントを作る方法と、WindowsのFontlink機能を使う方法がある。またもや一長一短。

○合成
FontForge
unofficial fontforge-cygwin
等を使用する。

ASCII部(U+0021～U+007e)をはめ込むだけならさして難しくない。が、フォントの特性を理解し、綺麗に、違和感なく仕上げるのは難しい。ビットマップ絡むとさらに難解。先に上げたMeiryoKe + Consolasの合成方法なんかを参照。

合成する方はフォントのライセンスに注意。基本的にOS付属の物はたぶんライセンス×。

○FontLink
FontLinkについては
Windows 7 で日本語フォントを Segoe UI に合わせて調整
FontLink SystemLink の設定値の数字について

を参照。

レジストリをいじって、対象フォントに参照のない文字はリレー方式で次のフォントを見に行くようにする。

結果を確認するのにいちいちOSの再起動が必要。すごくめんどくさい。

Consolasなどの欧文フォントではU+25CF("●")等一部の記号が含まれている。このため、記号等で欧文フォントで描画される物と日本語フォントで描画されるものがあり表示がイマイチになる。"●"は半角、"◎"は全角とか言うことになりかねない。

●評価
自分の評価が高い順に挙げていく。
ただし、どうしても環境依存。
書体記号類一部欧文gdipp/MacTypeClearType標準アンチエイリアスライセンス
Ricty◎○○△×○
Consolas + MeiryoKE Console(フォント合成)○(合成によるズレ)○○○△×
Migu 1M(好みでMigMix 1M, VLゴシック)○○○○△○
Consolas + (MSゴシック or MeiryoKE)(FontLink)◎×○○○○(MSゴシック) ×(MeiryoKE)
MeiryoKEゴシック or MeiryoKE Console△○○○○×
MSゴシック△○○○◎○
○Ricty
ConsolasオマージュのInconsolata + Migu 1Mという理想型。
書体そのものは可読性が高く決定版とも言えるようなフォントだが……

実質、gdipp or MacType必須。

Inconsolata自体が標準アンチエイリアス環境下ではアンチエイリアスが強く出てしまう書体のため、Rictyもそれを引き継いでボケボケ・欠け欠けでかなり厳しい。

標準ClearType環境下でもちょっと厳しい。DirectWriteなら調整によっては。

gdipp, MacTypeはデメリットがいくつかあり、これに踏み切れない場合は別のフォントを考える必要がある。

○Consolas + MeiryoKE Console(フォント合成)
gdipp, MacTypeでなくともClearType系で十分な視認性を得る。
しかし、二重にライセンスがあやしい。

さらに、合成のやり方次第だが、
・文字の水平位置ずれが生じる
・Consolasが持っていた標準アンチエイリアス下での視認性を失う
等の問題がある。

ライセンスあやしいのはダメという場合、別のフォントを考える必要がある。

○Migu 1M(好みでMigMix 1M, VLゴシック)
gdipp, MacTypeでなくともClearType系で十分な視認性を得る。

Consolasよりは欧文書体が好みではない("*"が浮く)。

標準アンチエイリアス下ではアンチエイリアスが強く出てボケボケになる。

ClearTypeの描画が気に入らない場合、別のフォントを考える必要がある。

○Consolas + (MSゴシック or MeiryoKE)(FontLink)
Consolas部はビットマップでないはずだが、標準アンチエイリアス下で高い視認性を得る。MSゴシック, MeiryoKEは好み次第。MeiryoKEはゴシックでもConsoleでも。当然ライセンスあやしいのがダメならMSゴシック。

ちなみにMeiryoKEをリンクする場合は横長になる問題が知られている。レジストリの値を好みで、
"meiryoKe_602r1.ttc,MeiryoKe_Console,128,85"
や
"meiryoKe_602r1.ttc,MeiryoKe_Console,128,100"
などとして、比率を調整した方が良さそうだ。

一部の記号類(ex.U+25CF("●"))がConsolas側に含まれるため半角描画される。この際の挙動はソフトによって違いキャレットの移動も半角に成るケース・全角になるケースと様々。

これが許容できない場合、別のフォントを考える必要がある。

○MeiryoKEゴシック or MeiryoKE Console
標準アンチエイリアス下で高い視認性を得る。

0にスラッシュもドットも入っていないので、Oと見分けが付きづらい。

ライセンスあやしいのはダメという場合、別のフォントを考える必要がある。

○MSゴシック
最後に行き着いたのはやはりここ。
標準アンチエイリアス下で高い視認性を……　得る。

ビットマップを大量に持っているのが強く、やはり100dpi程度までのモニタだとビットマップフォントが光る場面はある。漢字類の罫線の太さの調整はさすが謹製といったあたり。

○おまけ
アプリケーション上でASCII部とそれ以外でフォントを変えられるものがあればそれを使うとよい。Consolas+MeiryoKE(MSゴシック)で幸せになれそう。日本語テキストエディタだと、newQX, WZ EDITOR, xyzzyあたり。もちろん汎用性はナッシング。

●総括
結局自分の使い方だが、M+に期待しつつエディタを選んでソフト合成するか、Consolas＋MSゴシック(FontLink)でしのぐといった感じになりそう。DirectWrite調整でRictyが使えないかどうかも継続的に検討してみる。

前回調べたときは発芽レベルだったはずのM+が成長して、日本語プログラミングフォント界隈の幹のようになってきた。M+で足りない文字をどうやって補うかが今のテーマで、その主役がIPA。今後M+が充実してくると、そこも意味のない議論になってくる。これがラインセンス緩いとは……　M+すごい。感謝。

また、Inconsolata, Meslo LG M, Anonymous Pro, Source Code Proと欧文でライセンスが緩く素晴らしいフォントが揃ってきた。後ろ２つはちょっと趣味ではないが、書体そのものは手が足りた感じがある。

なお、以前はOsaka(等幅)を好意的に受け止めていたがOsakaはa,o や 1,lの判別が難しく、プログラミング向きではなかった(そもそもWindowsで使うにはライセンスがダメ)。文章を読むにはいいフォントではある。

Windowsのレンダリングはいまいちだ。古くからある標準アンチエイリアスの品質は致し方なかったにしても、比較的新しいClearTypeで調整幅が少ない。DirectWriteはかなりいじれる感じだが、ClearTypeそのものに手を入れれば良かった気がする……

そんなこんなで、どうしても現時点でのWindows7の世界では、環境を意識して使うフォントを考える必要がある。

標準アンチエイリアスでの見栄えを良くするには、ビットマップを埋め込むか、Windowsの仕様を意識したフォントデザインにする必要がある。当然面倒なので、世のフォント作者はWindowsの標準アンチエイリアスを置いていく。ビットマップについてはIPAが打ち切ったことからも分かるように、切るか極小サイズにのみ残すのが主流のようだ。確かにディスプレイが(特にモバイルで)高精細化していることもあって、ビットマップはどんどん不要になる。M+は一応ビットマップを別配布しているが、これも極小サイズのみのようだ。

今後PCのディスプレイも高精細化するだろうし、Windowsのレンダリングにも手が入るだろう。こういうのはたぶん昔話になっていく。が、目下は何かしら工夫が要る段階だ。

ソフトを作る方からすると、DirectWriteを頑張ってるソフトだけ見た目が優位になる。テキスト周りを扱うソフトが競争やるなら、もうDirectWriteは必須という状況らしい。

そしてMicrosoftがWindows9でテーブルをひっくり返す。この世界ってそういう風に出来てるのよね。

なお、決まり文句ですが全て自己責任でお願いします。
コメント（1件）

2013/02/21(木)RubyでUTF-8ファイル名＆外部コマンド実行

2013/02/21 16:33 PC（プログラミング）
[2017/05/02 追記有り]
Rubyの``やsystemで外部コマンド実行するときに、実行ファイル自体や引数にUTF-8文字(SJISマッピング無し)が渡せないのであれこれ悩んだ問題。

確認はWindows7 64bit & Ruby1.9.3p0(ActiveScriptRuby)

前提。WindowsはファイルシステムがNTFSならUTF-8ファイル名を命名できる。内部コードもUTF-8になっている(はず)。しかし古いAPIを触ったり、INPUT/OUTPUT周りを見るとまだShiftJIS(Windows-31J)が多い。このズレは厄介で、ハマりどころのA代表。特にRubyの場合、UNIX寄りでWindows特有処理のケアはやっぱり甘い…

閑話休題。Windows&UTF-8の扱いが比較的良くなっているRuby1.9系(Dir.globの引数に.encode('utf-8')などでUTF-8文字列を渡すとUTF-8ファイル名が取れる)でも、マジックコメント入れてUTF-8保存しただけだと外部実行が出来ない。
# -*- encoding: utf-8 -*-
# -*- coding: utf-8 -*-

`utf8_filename`
どうにも通らない。SJISマッピング出来るファイルなら、SJISでやればいいだけの話なのだがUTF-8にあってSJISにない文字(U+2661(はーと)とか)が混ざってると動かない。


で、とりあえず色々やってみたのだが、結論から言うと綺麗に書くのは諦めた。

ちゃんと調べるべきなのだが(やってない)、どうもRubyが叩いてるAPI自体が古いんじゃないかという。

unicode - Ruby system() doesn't accept UTF-8? - Stack Overflow

なので、苦肉の策。
バッチファイルを作成して、それを実行する。
# -*- encoding: utf-8 -*-
# -*- coding: utf-8 -*-

open("tmp.bat", "w"){ |fp|
	fp.write("chcp 65001\n")
	fp.write("utf8_filename\n")
}

out = `tmp.bat`
Windowsのバッチ実行ではコードページが合えば、UTF-8ファイル名も通るのでそれを利用する。引数にファイル名を指定するときも同様。\\の数とかダブルクオート囲いとか先頭に./が必要な場合は適切にすること。

うーん、汚すぎて死にそう。

[参考]
Rubyで外部コマンドを実行して結果を受け取る方法あれこれ #Ruby - Qiita

systemuは知らなかった。

[2017/05/02 追記]
やはりきれいには書けていないが、さすがにbatを吐き出すのは汚すぎるということで苦肉の策第二段。小改善してみた。今回はnyagosを使用している。
	out = ""
	Open3.popen3("c:/********/nyagos.exe"){ |stdin, stdout, stderr, thread|
		stdin.puts("chcp 65001")
		stdin.puts("#{COMMAND} \"#{utf8_filename}\"")
		stdin.close
		out = stdout.read
	}
nyagosでなくても良いのだが、cmd.exeやnyaos.exeだとchcp 65001したあとにUTF-8を流し込めない。
ここらへんは、chcp後に貼り付けが出来るかどうかで確認する。

Windows APIを直接叩けば済むような問題に見えるんだよなあ。
ここはまた次回。
コメント（1件）
OK キャンセル 確認 その他