オタク日記
(Mac と Linux, 2018Q3)

目次

2018-09-30 (Sun): 保守速報 (その 5)—GnuPG
2018-09-12 (Wed): 保守速報 (その 4)—EmacsMac
2018-08-22 (Wed): 保守速報 (その 3)—Django
2018-08-15 (Wed): 保守速報 (その 2)—EmacsMac
2018-08-08 (Wed): 保守速報 (その 1)

古い日記:
2018Q2   2018Q1  
2017Q4   2017Q3   2017Q2   2017Q1  
2016Q4   2016Q3   2016Q2   2016Q1  
2015Q4   2015Q3   2015Q2   2015Q1  
2014Q4   2014Q3   2014Q2   2014Q1  
2013Q4   2013Q3   2013Q2   2013Q1  
2012 年   2011 年   2010 年   2009 年   2008 年   2007 年  
2006 年   2005 年   2004 年   2003 年   2002 年   2001 年


2018-09-30 (Sun): 保守速報 (その 5)—GnuPG

Security に関しては、大昔から本質的なところはあまり変えていないが、 それで問題なく推移してきた (と信じている)。まあ、主に Linux (Ubuntu) と macOS なので、元々「脅威 (threats)」は少なく、あまり自慢にもならない。

ただ、2012 年頃、特に秘密を守りたいファイル (個人的な日記とか、 "key ring" とか) については、それらを rsync で複数のホストの間で共有している事もあり、特に保護したい、と思い立った。 つまり、何らかの方法で「ホスト内にログインを許してしまう」とか、「rsync の際に intercept される」等の場合でも、passphrase を知らない人にそれらのファイルを読まれないようにしたい、という事。

その前から、email を encrypt して……という試みはやっていたが、 結局立ち消えとなった。(数人の方々と public key を交換したような記憶があるものの、 今となっては、記憶の闇に……) その時に使っていた gnupg を流用した、 という事もあり、あまり熱心に記録を取ってないので、かなり時系列があいまいであるが……

ちょっと考えればわかる事だが、これでは、(GnuPG 導入の) 本来の目的を全々達成できていない。例えば、まんまと ssh で侵入したハッカー、 もしくは、電車内に忘れた MBA の前に座ったハッカー他は、 .gpg ファイルを、他のファイルと同様、 何の苦労もなく読めてしまう……

明らかに、gnupg2 のバグだと思えるが、当面は対策を取らず、gnupg2 のパッケージが改善するのを待つ事にした。下手に弄ろうとして、 平文の Text ファイルが拡散してしまうのが怖い、というのもあるし、 これまで侵入された事がないので、もうちょっと gnupg2 が改善されるのを待っても大丈夫だろう……などという甘い考えもある。


2018-09-12 (Wed): 保守速報 (その 4)—EmacsMac

このところ「帰省」したり他所へ出向いたりする事が増えたせいで、MBA (MacBook Air) を整備する必要が出てきた。やってる途中で、 これまでの「保守速報」で書き漏らした事がいくつか見つかったので、 新たにやった事も含めて書き足しておく。

Wanderlust

EmacsMac.app を立ち上げた直後に Wanderlust を起動すると、

Symbol’s function definition is void: find-coding-system

と言われる。ただし、これは、かなり古い「問題」で、 一年程前から悩んでいる。Elisp はよく分からないのだが、 分らないなりに、いろいろ「追及」した結果

Lookup

これは、lookup の立ち上げ時ではなくて、 辞書の検索結果を表示する段階で、

Symbol’s function definition is void: insert-string

とやられる。これはどうも、Emacs-26 では、関数 insert-string が定義されていない、という事のようで、 init.el の先頭近くに

(defalias 'insert-string 'insert)

という行を挿入する事で解決される。

Major-mode ごとにフォントを変える

前にも (何度か) 述べたように、EmacsMac のフォントとして長らく Lucida FAX (改) + Hiragino Mincho ProN を使ってきた。 これはつまり全ての Major mode で、これを使ってきた、という事。

少し前に、Major mode ごとにフォントを変更できる事を知り、Programming-mode や Dired, Term などで、Luxi Mono を使う事を試みている。これは、init.el に

(defun my-buffer-face-mode-fixed ()
   "Sets a fixed width (monospace) font in current buffer"
   (interactive)
   ;;   (setq buffer-face-mode-face '(:family "Inconsolata" :height 140))
   (setq buffer-face-mode-face '(:family "Luxi Mono" :height 190))
   (buffer-face-mode))

(add-hook 'python-mode-hook 'my-buffer-face-mode-fixed)
(add-hook 'lisp-mode-hook 'my-buffer-face-mode-fixed)
(add-hook 'emacs-lisp-mode-hook 'my-buffer-face-mode-fixed)
(add-hook 'term-mode-hook 'my-buffer-face-mode-fixed)
(add-hook 'dired-mode-hook 'my-buffer-face-mode-fixed) 

と書く事で実現される。首尾は上々で、

Python, Lisp などのソースコードは見易くなった。

elisp code in Lucida FAX
Lucida FAX (改) による elisp code
elisp code in Luxi Mono
Luxi Mono による elisp code

Python code in Lucida FAX
Lucida FAX (改) による Python code
Python code in Luxi Mono
Luxi Mono による Python code

(クリックして拡大可) ただまあ、Lucida FAX (改) の「改」は、空白や記号の幅をやや大きくして、 コードを表示した時の違和感を減らすための「改造」なので、 この程度の規模では然程差は出ないかも。(Python で、インデントが深くなり、 かつ、if 文の条件式が複雑になった場合には有効。)

Dired, Term などでは効果大

しかし、Term mode や Dired などでは、歴然とした差が出る。

Term mode in Lucida FAX
Lucida FAX (改) による Term mode
Term code in Luxi Mono
Luxi Mono による Term mode

早速、Term mode を再び使い始めてみたが、見た目が大きく改善された事と、 「コマンド出力を他のバッファへコピーする」等の操作が大幅に改善されたが、 そうするためには、やはり Term の char-mode と line-mode の間を行ったり来たりせねばならず、これがかなり面倒な事、また、 zsh の動作が時々おかしくなる等の困難はやはり残っており、 程なく EmacsMac.app と Terminal.app の両方を使う従来のやり方に戻ってしまった。


2018-08-22 (Wed): 保守速報 (その 3)—Django

Django が 2.x になり、これまで書き溜めてきた App 達を、この際「Django-2 対応にしてから公開しよう」 なんて思ったのが間違いの始まり。 いや、そこまでは「間違い」というより「殊勝な心掛け」というべきか。 間違いは、"Class-base View" に興味を持った事かも。 これには往生している……

それでも、ずっと使っている DMS (Document Management System) <http://dms.waremo.com> はそんな悠長に構えているわけには行かないので、Django 2.x 対応のみを急いて、とりあえず動くようにした。目立った (必須の) 変更は、

途中、dict の「代入」が copy でない事を失念している箇所のせいで、 微妙な問題が露になってくる、なんて事も有ったが、とりあえず動くようにできて、 実稼働しているサイトに投入した。

その後は、Django や WSGI のアップデートの度に、(ちょっとだけ) ヒヤヒヤしながら、でも結局は何事もなく、 MacPorts のアップデートをやってきた。

今回、Django が 2.0.7 から 2.1 になる際も、1.11.x から 2.0 になるより時よりはインパクトは少ないだろうと高を括って、 いきなり公開サーバで Django をアップグレードする等という無謀な事をやったら、 見事に Error 500 (Internal Server Error) が出た T_T;

少々焦ったが、こういう時に PyVenv は便利で、requirements.in の中で、

.....
django==2.0.7
.....

として、pip-compile/pip-sync するだけで元に戻せた。

これで、ちょっと余裕が出たので、Log を調べてみると、 views.py の中で、

from django.contrib.auth.views import password_change 

が Import Error になっている。 何でこんな事になったか、ちょっと顧みると……

  1. Django-1.11 で、django.contrib.auth.viewschange_password() を含む多くの関数が deprecate になっている。
  2. が、無視して使ってきた。
  3. -2.0 になる時に、さすがにヤバそう、という事で、 これを使わない方向でコードを改訂。 が、この import 文だけ、消去するのを忘れていた。
  4. 2.0 ではなく、2.1 になって、deprecate から、 removed (「使用不可」) となって、Error: 500 に!

という事らしい。なんで、2.0 でなくて 2.1 で「誤り」にしちゃうかなぁ…… というボヤキは飲み込んで、falcon 側で views.py のこの行を消去して

fukuda@falcon:~/wrm_dms2% git commit -a -m "removing deprecated func, change_password()"
fukuda@falcon:~/wrm_dms2% git push origin master --tag

digoc02 側で、required.in で、django==2.0.7 のバージョンの縛りを取り払い、

fukuda@digoc02:~/wrm_dms2% git pull origin master --tag
fukuda@digoc02:~/wrm_dms2% sudo service apache2 reload

とする事で、通常の「運転」に戻す事ができた。

wrm_dms with Django-2.1
Waremo DMS with Django-2.1

2018-08-15 (Wed): 保守速報 (その 2)—EmacsMac

例によってあまり注意を払わず MacPorts の EmacsMac.app をアップグレードしたら、いきなり 7.1 となった。基になった Emacs のバージョンは 26.1。

fukuda@falcon:~% port installed emacs-mac-app
The following ports are currently installed:
  emacs-mac-app @7.1_0 (active) 

少し前までなら、「わーい、ワクワク、ドキドキ」だったろうけど、 今はさすがに「大丈夫かなぁ」と心配に…… (トシのせいか :-))

が、しかし、「案ずるより……」で、emacs-mac-app-6.8 ? まで使ってきた ~/.emacs.d/{init.el,.emacs-custom.el} のままで、 -7.1_0 がとりあえず 立ち上がった。あとは、package.el がうまく動いてくれれば、 あまり互換性の心配はしなくて良い筈……

Package (package.el)

果して、package.el は M-x package-list-packages で立ち上がってくれた。 例によってアップグレード可能なパッケージをしばらく捜した後、 'U' ('Upgrade') をキーインすると、「全部アップグレードするべし」と。 (つまり、installed package の頭に 'D' がつけられた……) 言いなり、で 'X' ('eXecute'?) をキーインすると、しばらくかかった後、 殆んど問題無く全部のパッケージがアップデートされた模様。

ただ、package.el 自体も相当変わったようで、

これらによって、結局以下のような表示が得られる。

EmacsMac Pakcages
EmacsMac 7.1 での list-packages

どうやら、'dependency' は、依存性解決のために package.el が自動で入れた package, 'incompat' は、新 Emacs に対しては、 互換性の有るバージョンが得られなかった package, という事らしい。

Lookup/EBlook

辞書を引くためも「コマンド」 'eb', 'eblook' は MacPorts に入っている。 が、開発が止まってしまったのか、インストールして随分経つが、 まだ、アップグレードされる気配は無さそうだ。

fukuda@falcon:~% port list | grep eblook
eblook                         @1.6.1-media-20150724 textproc/eblook
fukuda@falcon:~% port list | grep -e '^eb '
eb                             @4.4.3-20130920 textproc/eb
fukuda@falcon:~% port installed eb eblook
The following ports are currently installed:
  eb @4.4.3-20130920_0 (active)
fukuda@falcon:~% which eblook
/opt/local/bin/eblook

うーむ、eblook は有るのに、port は認識していない……。 ここはちゃんとしておきたい。

fukuda@falcon:~% sudo port install eblook
.....
--->  Installing eblook @1.6.1-media-20150724_1
--->  Activating eblook @1.6.1-media-20150724_1
Error: Failed to activate eblook: Image error: /opt/local/bin/eblook already exists and does not belong to a registered port.
.....
fukuda@falcon:~% sudo port -f activate eblook
fukuda@falcon:~% port installed eblook eblook
The following ports are currently installed:
  eb @4.4.3-20130920_0 (active)
  eblook @1.6.1-media-20150724_1 (active)

肝心の lookup (eblook への emacs API) は、emacs package に入っていず、 手で入れていた (lookup-1.4+media-20170115)。 それでも、Emacs が 26.1 になっても、問題無く動いた (Kazuhiro Ito さん、凄い!感謝!)。 が、2018年版が出ていたので、この際アップグレードする事にした。

いつもの Kazuhiro Ito さん のところから、 lookup-1.4+media-20180325.tar.gz をダウンロード

これを展開して configure/compile/install する。

fukuda@falcon:~/build/lookup-1.4+media-20180325% ./configure \
   --with-lispdir=/Applications/MacPorts/EmacsMac.app/Contents/Resources/site-lisp \
   --infodir=/Applications/MacPorts/EmacsMac.app/Contents/Resources/info
fukuda@falcon:~/build/lookup-1.4+media-20180325% make
fukuda@falcon:~/build/lookup-1.4+media-20180325% sudo make install	  

'defer' を OALD で引いてみた。ちゃんと動いているようだ。

Lookup on EmacsMac-7.1
Lookup on EmacsMac-7.1

Wanderlust/W3m

Wanderlust (以下 'WL') はこれまでも色々問題が有って、「Mac でハック」がいつまでも完成しないのはこのせいだぁ、 などと言ってきたけど、実はこの半年程はとても安定している。 実際、EmacsMac を 7.1 に上げた時点では、他の App と同様問題無く動いていた。 但し、

等の問題は従来通り。

その後、apel, flim, semi, w3m, wanderlust 等の package が upgradable になる度に「言いなり」でアップグレードしていたが、 ある日突然、'WL' が立ち上がらなくなった……。debug-on-error で、messaeg を取ったが、あまり参考にならない。

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  signal(wrong-type-argument (stringp nil))
  wl(nil)
  funcall-interactively(wl nil)
  call-interactively(wl record nil)
  command-execute(wl record)
  execute-extended-command(nil "wl" "wl")
  funcall-interactively(execute-extended-command nil "wl" "wl")
  call-interactively(execute-extended-command nil nil)
  command-execute(execute-extended-command) 

幸いにも、もう一つの High Sierra マシンでは、これらの package のアップグレードをサボっているので、まだ問題なく動いている。 なので、それらの古いパッケージと置き換えるなど、色々四苦八苦してみたが、 原因は不明のまま。ふと思いついて、.folders から、Shimbun Folder (下のリスト参照) を外してみたら、これが大正解。

News{
# 	@asahi.editorial
# 	@asahi.tenjin
#	@asahi/
  	@bbc.news
}

朝日新聞の記事は疾に読めなくなっていたので、新たに諦めるのは bbc.news だけだが、これはちょっと辛かったな。

ともあれ、これで一安心、と思ったがちょっと甘かった……。 'WL' は立ち上がり、Folder も開けるのに、その中の message に開けないものがある……。しかも沢山。よく見たら、HTML ソースを含むメールが開けないという事のようだ。

当然 (emacs-)w3m を疑うべきだが ('WL' は、HTML の部分を emacs-w3m を使って表示している) 、今まで問題になった事が無かったので、 なかなか思い至らなかった。 が、まさか、と思いながら 'M-x w3m' とやったら、エラーになった。debug-on-error で取れたメッセージは、

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  string-match("/" nil 0)
  split-string(nil "/")
  mailcap-mime-info("desc=\"ltspice")
  (setq viewer (mailcap-mime-info type)) .....
  (if (= 0 (length ext)) nil (setq exts (list ext)) ....
  (while (setq elem (car-safe (prog1 extensions ....
  (let ((additions '(("text/sgml" "\\.sgml?\\'" nil "text/plain") ....
  (defvar w3m-content-type-alist (let ((additions '(("text/sgml" "\\.sgml?\\'" ....
  eval-buffer(#<buffer  *load*> nil "/Users/fukuda/.emacs.d/elpa/w3m-20180404.2220/w3m.el" nil t)  ; Reading at buffer position 48001
	  load-with-code-conversion("/Users/fukuda/.emacs.d/elpa/w3m-20180404.2220/w3m.el" "/Users/fukuda/.emacs.d/elpa/w3m-20180404.2220/w3m.el" nil t)
	  autoload-do-load((autoload "w3m" "Visit World Wide Web pages using the external w3m command.\n\n".....
	  command-execute(w3m record)
	  execute-extended-command(nil "w3m" "w3m")
	  funcall-interactively(execute-extended-command nil "w3m" "w3m")
	  call-interactively(execute-extended-command nil nil)
	  command-execute(execute-extended-command)

うーむ、mailcap-mime-info() の引数 (type?) に、なんで ltspice 云々が入るのか分らん……ていうか、そもそも自分には「elisp は謎」なので、w3m package が新しくなるのを待つしかない?

**** 2018-08-20 (Mon): 追記 (ここから) ****

といいつつ、ちょこちょこ触っていたが、package.el でインストールした w3m をどうしても動くようにできないので、 仕方なく、個別にインストールした emacs-w3m を使う事にした。まず、package.el で w3m を 'D' (delete) して、 隠していた既存の (emacs-)w3msite-lisp に戻す……

fukuda@falcon:/Applications/MacPorts/EmacsMac.app/Contents/Resources% \
    sudo mv hide/w3m site-lisp/
fukuda@falcon:/Applications/MacPorts/EmacsMac.app/Contents/Resources% \
    ls -l site-lisp/w3m
total 5124
-rw-r--r-- 1 root wheel 404758 Jan 27  2015 ChangeLog
-rw-r--r-- 1 root wheel 246138 Jan 27  2015 ChangeLog.1
-rw-r--r-- 1 root wheel   3318 Jan 27  2015 bookmark-w3m.el
-rw-r--r-- 1 root wheel   1285 Jan 27  2015 bookmark-w3m.elc
-rw-r--r-- 1 root wheel  36825 Jan 27  2015 mew-shimbun.el
	....

なんと、2015 年のだったか……

load-path を更新するために、EmacsMac を再起動 (もっとスマートなやり方が有ったように思うが)。 すると、emacs-w3m が立ち上がった。

気をよくして、Wanderlust を立ち上げて、html part を持つメールを開いてみたが、問題なく読める……。 さらに、上で駄目だと思って消してしまった、shimbun folder (@bbc.news) さえ読めるようになった…… うーむ、全ての問題は、w3m の、パッケージ・ミスが原因だったかぁ。

w3m            20180405.520  available  melpa      an Emacs interface to w3m
w3m            20180404.2220  available  melpa      an Emacs interface to w3m

上が最新版、下が MBA でたまたま残っていて、問題無く動くもの。 たった一日違いで……しかも、その後 4 ヶ月も放置か。悲しいねぇ。

**** 2018-08-21 (Tue): 追記 (ここから) ****

が、偶々別件で自分の日記 を見返していると、wl で w3m の代りに eww を使う、という記述を見付けた。 (厳密には、semi が MIME-View でどちらかを使う、という意味。) 加えて、semi(-epg) が、「w3m が無ければ eww を使う」という事も。 で、

  1. せっかく元に戻した (古い) w3m だけど、また site-lisp/../hide/ に戻して、
  2. .folders で、shimbun folder ('@' で始まる) を消して、
  3. init.el で w3m を load しているところを全部コメントアウトして、

emacs をリスタート。なんと、これだけで、殆んど全ての HTML part を持つメールを開けるようになった。

正直に言うと、「'WL' は、衰亡の一途か?」なんて思い始めていて、 「Mail.app だけで何とか凌ぐ方法」を模索し始めていたけど、 w3m (とその shimbun) を捨てる事で、まだまだ 'WL' でやれる! という気がしてきた——なんだかまた元気が出てきたぞ。


2018-08-08 (Wed): 保守速報 (その 1)

(ちなみに、ネトウヨ様御用達の「保守速報」とは関係ありません。 こっちは、保守 = maintenance です。:-p)

このところ、Otaku_comm の更新が滞っている。 実は、面目を一新しよう等と大それた事を目論だのは良かったのだが、 案の定大幅に予定が遅れている…… なので、ごちゃごちゃやってる事を態々ウェブに上げる事もないか、と思った訣。 でも、半年もサボると (つまり、やった事を曲がり形にもこのページ程度には整理しておかないと)、 後でわけわかになる、って事を痛感しはじめたのでした。

AquaSKK

つい最近まで、どこかから最新の dmg ファイルを見付けてきて、 それをインストールする、で何とかなっていたんだけど、 どこか不安だった。「ここだけ見ていればいい」というサイトが無いように思えたし、 MacPorts の一部になる動きもないようだし……

-4.4.5 へは、macOS を High Sierra に上げた時に、アップグレードしたのだった。 (「ついで」だったか、半強制的に上げざるを得なかったか、憶えていない。) それはもう 5ヶ月も前の話なので、もうそろそろ上がっているのではないかな、 とちょっと捜してみたけど、それらしいパッケージは見付からない。

-4.5.0 へのアップグレード

でも、github では、遠の昔に -4.5.0 にアップグレードされている…… という事で、無謀かな、と思いつつ、github のソースから make/install してみる事にした。

実は、ちょっと前から同 github は使っていて、リポジトリはできている (コンパイルがうまく行かなかった) …… 多分以下のようにやったのだろう

fukuda@falcon:~/Git% git clone https://github.com/codefirst/aquaskk.git

それから日も経っているので、git pull から始める……

fukuda@falcon:~/Git/aquaskk% git pull origin master
fukuda@falcon:~/Git/aquaskk% cd platform/mac
fukuda@falcon:~/Git/aquaskk/platform/mac% ls
Makefile  pkg/  plist/  proj/  src/
fukuda@falcon:~/Git/aquaskk/platform/mac% make install-rc

コンパイルにもリンクにも結構時間がかかるし、ワーニングも出まくりだけど、 なんと、これだけでインストールまで完了してしまった! ('install-rc' は、dmg ファイルをビルドして、 それをインストールする、というターゲットらしい。)

へぇーっ、とつかのま感心したけど、考えてみれば、変更してある config file をディフォルトのファイルで上書きしてしまった、 という事でもある。何度目かの失敗で「またやっちまった」と少々がっかりしたけど、 気を取り直して、Time Machine から kana-rule.conf と keymap.conf を掘り出して、 /Library/Input Methods/AquaSKK.app/Contents/Resource/ の下に置く事で、元に戻せた。(次節で、このあたりの対策について触れる。)

辞書と設定ファイル

アップグレードの度に思い出さないといけない事項のまとめ:

現在の「設定」

AquaSKK は随分と長く使わせて頂いているが、途中 「AquaSKK 日本語を快適に」 のページがアップデートされなくなったという事もあり、 設定についてはかなり「わけわか」になっていた。で、この際、 ちょっと整理しておこう、と。

とは言え、もう自分が正字正假名を使わなくなった事もあり、 既に相当単純になっていた。 (何度かうっかりディフォルトで上書きしてしまった後、 元に戻すのをサボった、という事。)

結論

という程の事でもないが、今後は、github で upgrade があれば、 それを pull して build/install するだけで、OK となる (筈)。一歩前進。

Fonts

私にとっての macOS の最大のメリットは、フォントが美しい事。Mac に出戻ってからこちら (もう、10 年以上?) 'Luxi Mono', 'Lucida Fax (改)', 'Hiragino Mincho {Pro|ProN}' でやってきた。

Hiragino Sans

逆に言うと、これらのフォントはそれくらい古い、という事なのだが、 その間、これらを凌ぐものが出て来なかった、という事でもある。が、 High Sierra になって、若干事態が動いた。'Hiragino Kaku Gothic ProN' の構成が変わって、W0 から W9 まで完備するようになり、名前も 'Hiragino Sans' と変わった。 これがまたとっても具合が良い——特に W1, W2 のあたりが。

Hiragino Sans (W2)
Hiragino Sans (W2)

Firefox Fonts

早速これを使ったディフォルト・フォントの設定にしてみた。 例えば、Firefox では

Firefox Font Latin
Firefox Font (Latin)
Firefox Font Latin
Firefox Font (Japanese)

残念ながら、上記設定画面では、Hiragino Sans の W (weight) を選べないのだが、見たところ W3 がディフォルトの模様 (従来通り)。

Terminal.app

Terminal.app は今 -2.8.2 であるが、Preference -> Profiles -> Font (Change) -> Fonts の画面で、collection として、all を選べば、Hiragino Sans を選ぶ事はできるが、 そうやっても、従来と同様、フォント間隔が大きくなりすぎて使い物にならない。

なので、collection として、'Fixed' か 'English' を選び、そこで Luxi Mono を選ぶしか選択肢は無い。この場合、2 byte code には Hiragino Kaku Gothic ProN W3 が従来通り選ばれている模様。(早い話が、Hiragino Sans は何の影響も与えていない。)

HTML

今のところ、Hiragino Sans の weight を明示的に選ぶのは、HTML の CSS でのみ可能なようだ。とりあえず

body {
    font-family: "Hiragino Kaku Gothic ProN"; 
    font-size: 18px; 
    line-height: 150%  
}
body {
    font-family: "Hiragino Sans"; 
    font-weight: 300; 
    font-size: 18px; 
    line-height: 150%  
} 

が、Firefox と Chrome の上でそれぞれ略同じになる事が確認できた。 (Firefox で設定やってみての「予想」が正しかった。) その上で、 font-weight を 100 や 200 にしてみたが、これはすっかり期待外れ—— 'font-weight: 300' の方がずっと見易い。

かつて、Kaku Gothic ProN W3 を「地の文」に適用したのでは「暑苦しいなぁ」と思ったが、 今ではこれが最適に思える。フォントの側が変わったのか、私の趣味 (もしくは視力) が変わったのか……。 ('Font Book' で、W2 の方が美しく見えたのは、フォントサイズが大きかったせいかも知れない。)

という事で、この方面においても、「大勢に影響なし」という事になってしまった。


362/1,294,543 Valid CSS! Valid HTML 5.0
Taka Fukuda
Last modified: 2018-10-04 (Thu) 15:49:42 JST