ciguwerao

2017/04/04の記録:源ノ明朝 (Source Han Serif) を試す

という記事を読んだ。

この前ちょうどVL (P)Minchoもできてくれないものか、と、切に願っていると書いたのだが、この源ノ明朝はそのVL (P)Minchoに代わりうるものではないかと思われるので、早速試してみた。

環境はDebian LXDE。

最初、"OTCs" の "ExtraLight + Light + Regular + Medium" と "SemiBold + Bold + Heavy" を
/usr/local/share/fonts
に入れて、Libre Office Writerで試してみた。

フォントを選ぶところで見ると、 "Source Han Serif" にK(韓国語)やTC(繁体字)やSC(簡体字)がつくやつが各ウェイトで並んでいるが、JPはない。

下の方に「源ノ明朝」の各ウェイトが並んでいて、これがJPに当たると考えて良さそうだ。

しかし、ウェイトの表記のない無印の「源ノ明朝」にすると、なんか太い。

Boldとはなっていないが、Boldだと思われる。

かと言ってRegularは見つからない。

Writerの機能で太字をオンオフしてみたが、文字は変わらない。

なんだかよく分からんので、さっきのは削除したうえで、 "Region-specific Subset OTFs" のJapanを落としてきて入れてみた。

「源ノ明朝」が太いのは変わらず。

が、よく探してみると、"Source Han Serif JP" とローマ字表記になったやつがあって、これが「源ノ明朝」のRegularだと思われる。

そういうことならと、元のOTCsに戻してみた上でよく見てみると、KもTCもSCもつかない "Source Han Serif" というのがある。(Libre Officeだと後ろに「簡繁」と表記されるので、さっきは中国語のやつだと思って見過ごしていたらしい)

KやTCやSCにもBoldはなく、ほかの5つのウェイトに加えて無印がある。その意味ではJP代わりと思われる「源ノ明朝」と同じだが、KやTCやSCの無印は源ノ明朝の無印のようにぶっとくはない。

"Source Han Serif" が日本語専用のRegularで、それがおかしくなってるのか、すべてを含む汎用設定がこれ、ということなのか、よくわからない

日本語のだけが変なことになってるのは、環境が日本語環境だからなのか、バグなのかもよくわからない。

が、とりあえずこの "Source Han Serif" を使っとけばいいのだろうと思う。

念の為すべてがひとつのファイルになってるという "Super OTC" も試してみたが、7つのファイルに分かれる "OTCs" と変わりはないようだ。

(ちなみにこのSuper OTCはzipが二つに分けてあって、普通には解凍できないので、 "unar" というのとその関連パッケージをインストールした)

全部入ったこのSuper OTCを使おうかとも思ったが、ファイルサイズがでかいし、なにか起動しようとするといちいちやたらと時間がかかる。(よくは分からんがその都度フォントを読み込みに行くんでないかと想像する)

中国語や韓国語がちゃんと表示されるのは嬉しいが、ウェイトは別にいろいろいらないので、OTCsからRegularとBoldだけを入れておこうと思う。

また、確認してみると、ちゃんとエムダッシュもつながる

えらい。

ご努力に敬意を表して、しばらくこのブログの本文のところの第一フォントをSource Han Serifにしておこう。

(公式のサイトで使われている画像で、CSSの指定っぽいところが "source-han-serif-japanese" とハイフンでつなげてあるので、最初そのように僕のCSSにも書いてみたが、うまくいかなかった。Libre Officeでの表記に合わせて "Source Han Serif" と書いたらうまくいった)

こんな記事を書くと、この前の記事のこともあるし、アドビ大好きっ子かよ、と思われちゃうかもしれないが、そういうつもりはない。

| その他パソコン全般 | 18:31 | comments(0) | trackbacks(0) |

2017/03/14の記録:Flash Playerのバージョン確認ページなど

前に

という記事を書き、それぞれの記事にフラッシュプレーヤーのバージョン確認ページと、バージョンアップがあった場合に新しいバージョンを落としてくるところへのリンクをはっておいた。

その後誰よりも僕自身が、フラッシュプレーヤーに新しいバージョンが出ていないか確認するのにこのリンクを便利に使っていたのだが、記事が古くなってしまってトップページには出てこなくなった。

トップページには10本の記事が出るようにしている。

トップページからバージョン確認ができるように、10本記事を書くたびにFlash Playerの新しい記事をわざわざ立てるのもばからしいので、右のメニュー(ウインドウが狭い場合は下に来るようにしている)の下の方の "LINKS" の部分に、二つのリンクを付け加えておいた。

完全に自分自身のためだが、便利だと思うので、もしよろしければご活用いただきたい。

| その他パソコン全般 | 01:28 | comments(0) | trackbacks(0) |

2017/01/18の記録:電源付きのUSBハブでスマートフォンの充電ができる

考えてみれば当たり前のことなのでこいつは何を言ってるんだ、と思われる方もいらっしゃろうが、とりあえず僕は今までそのことに気づかずにいたので、ここにメモしておく。

表題の通り。

ずっと昔、貝殻型iBookが現役バリバリだった頃に、あれはUSBの穴が一つしかないこともあって八面六臂の活躍をさせていたAC電源付きのUSBハブがある。

が、USB1.1であることもあって最近は使っていなかった。

それはそれとして、スマートフォンだとかタブレットだとか、欲しいと思いながら実際にはまだ買っていないがラズベリーパイだとかは、USBから電源を取るようになっている。

もちろんタブレットやスマホには電源用のUSBのアダプタが付属していたので、それを使っているのだが、ラズベリーパイのように別売りのものもあるにはあるようだし、そういうのがいっぱいあるなら一つ一つ別のコンセントじゃなくて、いっぺんにまとめて充電(電力供給)できたほうがいい。

今直ちにその必要があるわけじゃあないが、ゆくゆくは、そういうやつ、つまりいくつかUSBの穴のあるアダプタを買う必要が出てくるかも、欲しくなるかも、と思っていてふと、電源付きUSBハブのことを思い出した。

そこで早速、どこ行ったかと思ったらiTunes専用くびふりiMacに空しく挿してあった件のハブとそれ用の電源アダプタを持ってきて、スマホをつなげて試してみた。


ハブは電源につなげてあるが、パソコンにはつなげていない。

真ん中に赤いランプがあるのだが、これはパソコンにつなげないと点かないようで、点いていない。

それでもしかしたら電気はスマホに行かないかもしれないと思ったのだが、まあ、ハブにそんなことを判断する能力はないようだ。

ちゃんとスマホの充電を示すランプは点いている(写真ではよくわからないが)。

このハブは穴が四つあるので、四つの機械を同時に充電(電力供給)できるはずだ。

ただし、スマホで確認すると現在20%弱でフル充電まで四時間と出ており、スマホに付いてきた電源アダプタ、これも決して充電が速くはないのだが、それと比べても遅いように思う。

四ついっぺんにつなげたら、その分なおさら遅くなるんだろうか。

ハブのACアダプタには出力5V=2.1Aと書いてあって、スマホ付属のが1アンペアなのに比べると大きい。

ハブの方が遅いというのは勘違いだろうか。

この辺、電源からハブを通してどういう風にスマホまで届くのか、よくわからない。

何れにしても容量は小さそうなので、最近のラズペリーパイなんかは必要電力が大きくなったそうだし、そういうものはこれではダメな可能性が高いと推測しておく。

とはいえ、一応使えないこともないことがわかったことは収穫としたい。

スマートフォンやタブレットをだらだら充電する分にはこれで十分だ。

== 追記 ==

Raspberry Pi 3 Model Bは必要電源容量が2.5Aだそうだから、そもそもダメのようです。

USB充電器をいくつかみてみると、4.8A二つ穴でそれぞれ最大2.4Aなどと書いてあったり、二つ穴合計1A、二つ挿したら各0.5Aなどと書いてあります。

僕のハブが四つ穴合計2.1A、穴一つにつき最大で2.1/4=0.525A、とかいう仕組みになってるとも思えないので、おそらくは一つしか挿してなければ2.1Aが全部そこに行くんじゃないか、つまり付属アダプタより遅いというのは勘違いなんじゃないかと思いますが、USBハブ、それもUSB黎明期のやつがどういう挙動をするのか、何れにしてもよくわかりません。

== さらに追記 ==

たびたびすみません。

さらに調べてみると、USBは2.0まで5V 500mAという給電規格になっているそうです。

それでは少なすぎるということで、その後容量を増やす動きがいろいろあったようですが、スマホ等の充電用のUSBがどの規格なのかは、もっと調べないといけません。

今日のネタに関していえば、給電問題がやかましくなる前のUSB初期のハブですから、規格に従って500mAという容量になってる可能性が高そうです。

とすると、上の追記で否定した、合計2Aほど、一つあたり0.5Aほど、というのが正解ということになります。

スマホ付属のアダプタより遅そうだ、という判断とも整合します。

ただ、ハブがそんな調整をできるようになっているのか、心もとない気も一方ではします。

取る方が0.5しか取らないというのを前提にしてつくってあるのであって、2.1をまるまる取ろうと思えば取れちゃうのかも、とも思います。

やっぱりホントのところはよくわかりません。

スマホ付属のアダプタがどういう規格になってるかも調べてみたく思いますが、今日はもう疲れました。

== 翌日なおも追記 ==

こういうのが見つかりました。

これを読んで一旦は納得しかけたんですが、考えているうちにまたわからなくなってきました。

とりあえずここの回答者さんに従うと、上の二つ目の追記の後半の判断が正しそうに思われます。

まず、

出力側に対して「最低は500mAが可能なこと」と、負荷側に対しては「最大500mA」を既定しているだけ。

は、よくわかります。そうなのだろうと思いました。

3. 本来USBハブはバスパワー負荷を保証しておらず、メーカーの自己防衛です。

その観点からは、「各々必要分が配分され、合計が500mAまで」と言う動作となります。

という記述からすると、やっぱりそれぞれの穴に最大Aを定めているものもあるのは専門の充電器だからで、ハブは穴ひとつごとに電流の調節をする仕組みは組み込んでいないと考えてよいのか、と、一旦は納得しました。

しかし、ここではパソコンの穴に電源のないハブを挿して500を二つに分ける状況を想定しており、500以上を流した場合のことは書いてありません。

上の引用部からすると規格は500は出せよ、とは言ってるけど、500しか出すな、とは言ってないということになります。

僕のハブの場合、本文に書いたようにACアダプタが容量2100になってるので、ひとつしか挿さなければまるまる全部そこに出すんだろうと判断したわけですが、2100というのは、各穴ごとに500取られることを想定して500x4、自分の消費もあることだし余裕を見て+100、ということでしょう。

欲しがるやつに500を超えて渡してしまったら、他の穴に500が保証できなくなります。

「最低は500mAが可能なこと」という規格に抵触しないんでしょうか?

電源なしのハブならいざ知らず、いやしくも電源をつけている以上は、それぞれの穴に500を保障するために最大電流を各穴ごとに設けていても、おかしくはないようにも思えてきました。

この辺は、全くあてずっぽうにすぎませんが、ハブの品質によるのかと思います。

安っぽいハブならそういうことは考えないでしょう。

それなりに真面目なハブは、合計が最大2100である以上、各穴ごとに500ちょっとでリミットをかけてあったとしてもおかしくはなさそうです。

もっと優れたものなら、いくつつながっているか、それぞれいくら欲しがっているか、を判断して、合計2100の範囲内で適切に分配するでしょう。(そんなハブが本当に存在するかは怪しく思いますが。)

で、僕のハブはどうなんだ、ということですが、これもあてずっぽうですが、500までしか欲しがっちゃダメ、という決まりになってた頃のものだし、いくらで買ったか忘れましたが僕が買ったものなのでどうせ安物に違いないし、何も手を打ってない、つまり流せるだけ流すようになってる、と、推測しておきます。

確認する手段は、スマホの充電時間で推測する以外に、今のところ思いつきませんが。

それにしても、ブログを書くということは、自分の無知をさらけ出すいかにも恥ずかしい行為であるということを、今回改めて思い知りました。

この何年か主に書いているリナックスのことなら知らなくても別にどうでもいいことですが、今回の電流みたいな話について基本的なことも何もわかっていないのはかなり情けないことだと、いろいろ調べているうちに自覚させられました。

| その他パソコン全般 | 21:13 | comments(0) | trackbacks(0) |

2016/09/22の記録:LibreOfficeの「PDFとしてエクスポート」

今日現在、LibreOfficeの最新版は5.2.1、安定版は5.1.5のようだが、そのどちらでも、書類を「PDFとしてエクスポート」をする際、JPEG圧縮が機能しない。

一つ前の5.0.6.3ならば機能する。

これはマック版でもリナックス版でも同様であり、試してないがおそらくウインドウズ版でも同じだろうと思う。

LibreOfficeでは、WriterでもCalcでもなんでも、書類をPDFとして書き出すことができる。

「ファイル」メニューから「PDFとしてエクスポート」をするだけで良いので簡単だ。

それをやると次のようなウインドウが出る。

この写真の赤枠はもちろん僕がつけたのだが、その赤枠のところで、これは基本的に画像を使用している書類にのみ関わることなのだろうが、画像のJPEG圧縮の設定ができる。

画像をJPEG圧縮すると、画質が落ちるが、その分ファイルサイズを小さくできる。

パーセンテージを下げれば下げるだけ画質が悪くなる一方、ファイルサイズは小さくなる。

「ロスレス圧縮」を選べば、画質が落ちないが、ファイルサイズは大きくなる。

もちろん使用している元の写真によるのだが、例えば僕が作った書類だと、ロスレスで22.3MBのものが、90%のJPEG圧縮で1.8MBにまで小さくできた。

が、冒頭に書いたように、最近のバージョンではこれが機能しない。

JPEG圧縮で何%を選んでも、ロスレスの場合と同じファイルサイズのPDFができる。

画質も、僕の見た限りでは、違いが出ない。

JPEG圧縮を選んでもロスレス圧縮になると考えていいと思う。

対処としてはあらかじめ自分でJPEG圧縮しておいた画像を使用すればいいわけではあるが、すでに作っちゃった書類(それも一枚ならともかく何枚も画像が入ってる)を作りなおすのは面倒である。

たまたま、自宅で使っているMac miniではアップデートを怠っていたおかげで5.0.5.2が入っていて、それでは問題なく画像をJPEG圧縮したPDFが作れた。

そこで、新しいのを入れちゃった機械のためには、5.0.いくつならいけるだろ、という判断でその中では最新の5.0.6.3を下記のLibreOfficeの古いバージョンを置いてあるところから落としてきて、インストールしなおした。これならば問題は出ない。

(ここ、ダウンロードにかなり時間がかかる。もっと速く落とせるところもあるかもしれないが、とりあえず僕が知ってるのはここ)

というわけで、PDFエクスポートのJPEG圧縮に関する限り、現時点では5.0.6.3を使うのがベストと思われる。

ちなみにLibreOfficeのPDFエクスポートに関しては、4.3.3.2にも別の問題があることを一昨日の記事で書いたので、興味のある方はご参照のこと。

| その他パソコン全般 | 15:22 | comments(0) | trackbacks(0) |

2016/06/15の記録:2015/12/17は42355

メモ。

エクセルを使い慣れている人にとっては常識か知らんが、書式を日付にして適当に数字を入れると、その数字に対応した日付になる。

僕はエクセルじゃなくてLibreOfficeのCalcだけど、2015年末についてちょっとした表を作っていて、いちいち日付を打っていくのが面倒なので、上の仕組みを利用することにした。

1は1899/12/31になるが、それからちょうど打とうと思ってた日付であるところの2015/12/17まで何日経ったのか見当もつかないので、適当に50000 (2036/11/21) あたりから始めて狭めていった。

で、何回目かに入れた42000が思いの外惜しい2014/12/27になったので、——頭のいい人ならここまでわかれば計算できるのだろうが僕は頭が悪いので——大体一年分の360を足して2015/12/22、その次に目指す42355を探し当てた。

あとはQiitaikedat16さんという方の

という記事を参考に、その4番目に紹介されている計算式

=N(OFFSET(A3, -1, 0))+1

を下の翌日のセルに入れる("A3" の部分はそのセルの番号に合わせる)と、ちゃんと2015/12/18になった。

素晴らしい。

で、そのあとは計算式じゃなくてその(12/18の)セルをコピーして、その下に続くセルを適当にばばっと選択してペーストしたら、ちゃんと選んだセルの分だけ連続した日付になった。

すげー。

で、嬉しいので来年分くらいまでずっと日付を入れてやった。

必要ないけど。

必要なのはこの年末年始だけ。

ikedat16さん、ありがとうございます。

== 追記 ==

上述の通り僕は頭が悪いので今頃になって気づきましたが、 2015/12/17が42355などという知識は、今日の僕の作業には実は必要のないものでした。

セルの書式を日付に設定したうえで、指定した書式通り(僕の場合は何度も書いてるような年月日をスラッシュで区切るやり方)に日付を自分で打ち込むと、データ上は自動でその日付に対応した数字になるようです。

だから対応した数字がいくつかはわからなくとも "2015/12/17" と書いて、その次のセルからは上に書いたようなやり方をすれば、2015/12/18以下の日付になってくれます。

というわけで、上で書いたことの半分くらいは、今日の目的からはどうでもよかったんですが、それはそれとして、2015/12/17が42355というのは面白いデータかと思います。

| その他パソコン全般 | 19:00 | comments(0) | trackbacks(0) |

2015/11/11の記録:新しいOpera

先ほど2015/11/05の記録に、Opera関連の追記をした。

Windows10以外の環境ではOperaは古いのを使っていると書いたのだが、その後、古いオペラの最終版であるところの12.16は脆弱性があるため使えないという記事を見つけたこともあり、葛藤はあったがMacOSXのオペラを最新版にアップデートするという決断をした。

これまでアップデートしなかったのは 慣れ親しんだ旧版の動作をWindows10上の最新版Operaでは再現できないでいたため。と言っても、ちょっと設定画面をいじってみただけで真面目に検討したわけではない。

今回OSXでアップデートするにあたり、もう少し検討してみたところ一応の成果を見たので、以下に記録しておく。

一番気に入らなかったのは、新しいタブでリンク先を開いた際に、そのタブが選択された状態(アクティブな状態)にならない点。

以前の操作性を再現!?最新版Opera向け拡張機能(アドオン)まとめ」というページで、それを実現する機能拡張を二つ紹介してくれている。

前者の方が設定できることが多いが、僕の求める設定はどちらでもできる。次に書くことから、後者を使うことにした。

旧版でできたことの中で再現したいもう一つの設定は、ブックマークを新しいタブで開けるようにすること。

この点、検索してみると、それを望む人はちらほらいるものの、現時点では実現方法がわからなかった。

しかし、「Disqus - Update to Opera developer 30.0.1833.0」というページに

—Someday, the option to open bookmarks from the bookmarks bar within a new tab will be available.

—Have you tried middle mouse button click? Or context menu?

というやり取りが見つかった。

そこで試しにブックマークツールバー内やブックマークメニューのブックマークの適当なのを選択した状態でマウスのカリカリボタン(真ん中ボタンというかホイール)を押してみたら、確かに新しいタブで開いた。

ただし、上に書いたリンクを新しいタブで選択された状態で開くアドオンのうち、 Classic Tabsを使った状態では、ブックマークは選択された状態ではなくバックグラウンドで開いた。

もう一つのSimpleTabOrderでも試してみたら、こちらではブックマークも選択された状態の新しいタブで開けた。

カリカリボタンではなく普通のクリックでブックマークを選んでも新しいタブで選択された状態で開けるようにしたいのだが、それを実現する方法が見当たらなかったので、今日のところはこれでいいことにする。

== 追記 ==

Windows10でも試してみたがOSXの場合と同じように動作した。当然のことと思うが、念のため追記しておく。

なお、Linux用は古い(WebKit移行前の)12.16が安定版としてはいまだに最新のようだ。

| その他パソコン全般 | 22:42 | comments(0) | trackbacks(0) |

2015/08/21の記録:ベトベトするマウスについて


上の写真(トリミングしてるので光の加減が変)はこの前追記で愚痴を書いたベトベトするマウスだが、あの後指と固く絞った雑巾で根気よくこすったら、表面のベトベトをあらかた落とすことができた。

こすってもベトベトを取り去ることはできないんでないかと思っていたが、案に違って結構ちゃんと落とせた。裏の一部にまだベトベトは残っているが、マウスパッドに引っかかるということもないし、手で触れることはない部分だし、使う分には全く気にならない。素材自体が劣化するとベトベトになるもの(ラバーとか)だったらこうはいかないだろうが、表面に貼るだか塗るだかしてあっただけだったのが幸いした。



最初っからこれで良かったのに。

もともと6€くらいで買った安物なのでポインタの挙動とかクリックの反応だとかに多少不安定なところはあるが、使用に耐えないというほどではない。

僕の使い方だとどうも手に馴染まないのが残念だが、思ったよりは悪くない。

iTunes専用機に左遷したエレコムのマウスの方は、そっちではホイールの挙動に特に問題がなさそうなのも良かった。

さしあたりはこの体制でいこうと思う。

全然関係ないが、昨日今日で色々試して、文字色と追記・注記部分の色使いを変えてみた。

(例)

(exemple)

== 例 ==

(例)

(exemple)

右のカレンダーとかがある部分の色をもとに明るくしたり暗くしたりして試してみたわけなんだが、そういう理屈を先立てたこともあり、僕のセンスの問題もあり、特に注記部分の色なんかが好ましい色にならなかった。全体に色の調和がなく汚らしいような気もするが、パソコンというかモニターによってはそんなに悪くもない場合もあるので、これでしばらく行く。

| その他パソコン全般 | 20:42 | comments(0) | trackbacks(0) |

2015/08/04の記録:mdashはつながるか

日本語の文章の中でダッシュを使うとき、これはウィキペディアにも書いてあることだが、棒線の長さをふた文字分にするのが通例になっているようだ。

棒線はエムダッシュかホリゾンタルバーを使う。

これを倍角にするのが本当だろうが、面倒なので二つ並べることで済ませたい。

そうなると、二つ並べた際に間に空白ができないか、つまりつながるかどうかが大事になってくるが、フォントによってつながったりつながらなかったりする。

いまどきの日本語文ではダッシュの使用はありふれたことになっているのだから、少なくとも日本語フォントにおいてはエムダッシュかホリゾンタルバーのどちらかでいいので、つながるようにするのがコンセンサスになってほしいところだが、そうはなっていないようだ。

以下、思いつく限りのフォントで、つながるか否かを試して見ることにした。スペース (emsp) の左がエムダッシュ、右がホリゾンタルバー。

== 2016/06/21追記 ==

罫線素片のU+2500(─)を使う場合もあるということなので、それも付け加えてみた。一番右。

—— ―― ── (Alfios)
—— ―― ── (Andale Mono)
—— ―― ── (Arial)
—— ―― ── (Bitstream Vera Sans)
—— ―― ── (Bitstream Vera Sans Mono)
—— ―― ── (Bitstream Vera Serif)
—— ―― ── (Century)
—— ―― ── (Century Schoolbook)
—— ―― ── (ChicagoFLF)
—— ―― ── (Comic Sans MS)
—— ―― ── (Courier)
—— ―― ── (Courier New)
—— ―― ── (Courier Prime)
—— ―― ── (DejaVu Sans)
—— ―― ── (DejaVu Sans Mono)
—— ―― ── (DejaVu Serif)
—— ―― ── (Droid Sans)
—— ―― ── (Droid Sans Mono)
—— ―― ── (Droid Serif)
—— ―― ── (FreeMono)
—— ―― ── (FreeSans)
—— ―― ── (FreeSerif)
—— ―― ── (Gelasio)
—— ―― ── (Georgia)
—— ―― ── (Helvetica)
—— ―― ── (Hoefler Text)
—— ―― ── (Impact)
—— ―― ── (Inconsolata)
—— ―― ── (Liberation Mono)
—— ―― ── (Liberation Sans)
—— ―― ── (Liberation Serif)
—— ―― ── (Linux Biolinum)
—— ―― ── (Linux Libertine)
—— ―― ── (Lucida Grande)
—— ―― ── (Menlo)
—— ―― ── (Merriweather)
—— ―― ── (Merriweather Light)
—— ―― ── (Merriweather Sans)
—— ―― ── (Monaco)
—— ―― ── (Noto Sans)
—— ―― ── (Noto Serif)
—— ―― ── (Playfair Display)
—— ―― ── (PT Mono)
—— ―― ── (PT Sans)
—— ―― ── (PT Serif)
—— ―― ── (Roboto)
—— ―― ── (Tahoma)
—— ―― ── (Times)
—— ―― ── (Times New Roman)
—— ―― ── (Trebuchect MS)
—— ―― ── (Ubuntu)
—— ―― ── (Ubuntu Condensed)
—— ―― ── (Ubuntu Mono)
—— ―― ── (Verdana)

考えてみれば日本語の文章の問題だから日本語フォントのほうが重要だった。以下日本語フォント。

—— ―― ── (Source Han Serif)
あいうえおかきく

—— ―― ── (TakaoMincho)
あいうえおかきく

—— ―― ── (TakaoPMincho)
あいうえおかきく

—— ―― ── (TakaoExMincho)
あいうえおかきく

—— ―― ── (TakaoGothic)
あいうえおかきく

—— ―― ── (TakaoPGothic)
あいうえおかきく

—— ―― ── (TakaoExGothic)
あいうえおかきく

—— ―― ── (IPAMincho)
あいうえおかきく

—— ―― ── (IPAPMincho)
あいうえおかきく

—— ―― ── (IPAExMincho)
あいうえおかきく

—— ―― ── (IPAGothic)
あいうえおかきく

—— ―― ── (IPAPGothic)
あいうえおかきく

—— ―― ── (IPAExGothic)
あいうえおかきく

—— ―― ── (VL Gothic)
あいうえおかきく

—— ―― ── (VL PGothic)
あいうえおかきく

—— ―― ── (Osaka)
あいうえおかきく

—— ―― ── (Osaka−等幅)
あいうえおかきく

—— ―― ── (Hiragino Kaku Gothic ProN)
あいうえおかきく

—— ―― ── (Hiragino Kaku Gothic Pro)
あいうえおかきく

—— ―― ── (Hiragino Maru Gothic ProN)
あいうえおかきく

—— ―― ── (Hiragino Maru Gothic Pro)
あいうえおかきく

—— ―― ── (Hiragino Mincho ProN)
あいうえおかきく

—— ―― ── (Hiragino Mincho Pro)
あいうえおかきく

—— ―― ── (Yu Mincho)
あいうえおかきく

—— ―― ── (Yu Gothic)
あいうえおかきく

—— ―― ── (MS Mincho)
あいうえおかきく

—— ―― ── (MS PMincho)
あいうえおかきく

—— ―― ── (MS Gothic)
あいうえおかきく

—— ―― ── (MS PGothic)
あいうえおかきく

—— ―― ── (Meiryo)
あいうえおかきく

—— ―― ── (源真ゴシック)
あいうえおかきく

—— ―― ── (源真ゴシックP)
あいうえおかきく

—— ―― ── (源真ゴシック等幅)
あいうえおかきく

—— ―― ── (源柔ゴシック)
あいうえおかきく

—— ―― ── (源柔ゴシックP)
あいうえおかきく

—— ―― ── (源柔ゴシック等幅)
あいうえおかきく

—— ―― ── (源柔ゴシックX)
あいうえおかきく

—— ―― ── (源柔ゴシックXP)
あいうえおかきく

—— ―― ── (源柔ゴシックX等幅)
あいうえおかきく

—— ―― ── (源ノ角ゴシック)
あいうえおかきく

—— ―― ── (源ノ角ゴシック等幅)
あいうえおかきく

—— ―― ── (梅明朝)
あいうえおかきく

—— ―― ── (梅P明朝)
あいうえおかきく

—— ―― ── (梅ゴシック)
あいうえおかきく

—— ―― ── (梅Pゴシック)
あいうえおかきく

—— ―― ── (衡山毛筆フォント)
あいうえおかきく

—— ―― ── (衡山毛筆フォント OTF)
あいうえおかきく

—— ―― ── (UnBatang)
あいうえおかきく

—— ―― ── (TTEdit鏡文字明朝)
あいうえおかきく

—— ―― ── (TTEdit鏡文字ゴシック)
あいうえおかきく

—— ―― ── (Dejima)
あいうえおかきく

—— ―― ── (Noto Sans CJK JP)
あいうえおかきく

—— ―― ── (Noto Sans Mono CJK JP)
あいうえおかきく

—— ―― ── (SourceHanCodeJP-Normal)
あいうえおかきく

—— ―― ── (SourceHanCodeJP-Light)
あいうえおかきく

もちろん、パソコンにそれぞれのフォントがインストールされていないとそのフォントでは表示されない。僕自身、今書いてみたものの、このパソコンには入ってないのであとで入ってるパソコンで確認しないといけないのもある。

HTML・CSSの記述の仕方で間違って、うまくいかないのもあるかもしれない。その点はご容赦願いたい。

ほかに思いついたらまた追加する。

そのフォントがインストールされていない場合、もしくはそのフォントにエムダッシュ・ホリゾンタルバーが用意されていない場合にはCourier New Impactで表示されるようにしてみました。Courier New Impactは大抵の環境でインストールされており、かつ、他と見分けが比較的つけやすいと判断したためです。 Courier New Impactもインストールされていない場合、それ以外の等幅フォントで表示されるはずです。【Courier Newよりさらに見分けのつきやすいImpactにしました。(2016/01/08)】

== 08/10追記 ==

うれしいことと悲しいことがあった。

うれしいことは本文と関係があるが悲しいことは関係ない、ただの愚痴なので、まずうれしいことから。

僕の主力日本語フォントであるところのTakaoExMincho、これまで気づかなかったのが迂闊なことだが、この記事の実験をやってみて、特にそのフォントに用意されていない場合にCourier Newで表示されるようにして、初めて気づいた、エムダッシュが用意されていなかった。

これはえらいことだと思い、僕のタカオフォントへの信頼が揺らぐところだったのだが、さっき、僕のパソコンに入ってるフォントのバージョンが古いのではないか、と気づいた。
(しらべてみたらバージョンは "001.01.01" だった)

そこで早速公式のところ(多分。リンク先間違ってたらごめんなさい)に行って、今年の3月に更新されたらしい最新の "002.01.01" を落としてきて、インストールした。

最初にやった環境はMac OSX on Mac Miniで、続けてLubuntu on EeePCでもやってみた。

Lubuntuではフォントも自動更新されるはずだと思っていたが、パッケージマネージャで見ると "fonts-takao" のバージョンは "003.02.01" (Ex単独のバージョンナンバーとは別立て)。これは、上のリンク先で確認すると2010年更新の古いもののようだ。実際/usr/share/fonts/truetype/に入っているフォントのファイルそのもののプロパティを確認しても、2010年が最終更新となっている。まあ、パッケージマネージャでインストールできるもののバージョンが古いのはよくあることではある。【この辺、情報収集が不十分で不確かな書き様になっていたので08/11に修正した】

そこでマックと同様リンク先からダウンロードしてきて手動でインストールした。

ともあれ、リンク先から落としてきたのをインストールすると、これまでCourier Newの長さの表示になってたのが、ちゃんと仮名二文字分のつながるエムダッシュで表示された。

バージョンが上がって、ちゃんとエムダッシュを用意してくれたんだと考えてよかろうと思う。

よかった。

ただ、今「仮名二文字分」と書いたところで気になって確認してみたのだが、実際には二文字分より心もち短くなっている。 TakaoPMinchoと同じになっているようだ。これは残念だ。人によってはアウト判定するかもしれない。(この点、わかりやすくするために改行してひらがなをつけてみた)

とはいえ、これまでよりは進歩したので、そのことはそのこととして寿ぎたく思う。

もしTakaoExMinchoをインストールしていて、上のエムダッシュの方(左側)の長さが短くがぶっとく(=Courier NewサイズImpactで)表示されてる方は、上のリンク先から最新バージョンを落としてインストールされることをお勧めします。【2016/01/08修正】

あとは愚痴。

悲しいこと。

これはもう半月ほどに前のことなるが、 Mac miniでサファリとファイアフォックスの両方を行ったり来たりしながら動画かなんかを見てて、ふと、機械が忙しそうに動いてるなあ、苦しそうだなあ、と思ったところでプン、とか言ってマウスもキーボードも効かなくなった。

そのときMac miniにつなげていたのは、モニタを除くと外付けハードディスクを直接一つ、電源つきハブを通してマウスとキーボード、もう一つの電源つきハブだったと思う。

一旦全部Mac miniから外して、電源も抜いたりして、つなげ直してみたら、ほかのは回復したのだが、フランスにいた頃にカルフールで10ユーロ弱で買って、大変愛用し、もう本当に手によくなじんで、これがなくなったら悪夢だな、これがなくなったときのことなど想像できないな、と思っていたマウスだけは回復しなかった。

(真ん中のやつ)

壊れてすぐはLubuntuのEeePCにつなげれば動いたので、なんかよくわからんがほとぼりが冷めたらMac miniでも動くようになるだろう、とタカをくくっていたのだが、そのうちEeePCでも動かなくなった。

僕がいじれる全ての機械で試してみたが、動かなかった。

お陀仏確定である。

痛恨の極みであったが、まあその痛みはもう乗り越えた。

マウスが一個足りなくなったので、電器屋でELECOMのを600円くらいで買ってきた。上の写真の左のやつである。

これ、写真でわかるように顔のマークがついてるが、それに惹かれたのではなく、その上に写ってるOM印のキーボードに色を合わせるために選んだのだが(ちなみに壊れたカルフールのやつも同様)、多少色が違って、あんまり揃えた感じにはならなかった。

が、それが悲しいのではない。

今日、Firefoxが更新された。その更新されたファイアフォックスでニュースとかを見ていたが、どうもホイールを回した際の動きがおかしい。

ゆっくり回すとほとんど動かず、急に回すと一気に動く。普通に回すと動くときと動かないときがある。

どうにもコントロールが効かない。

最初、ファイアフォックスが更新でいらんことしたせいかな、と思い、ついでOSXのいらん仕組みのせいかな、と疑ったが、試しにほかのマウスをつないでみたら、特別おかしなことはない。

このマウスの特性のようだ。

そういえば、このマウスにしてから一週間くらい経ったかと思うが、その間スクロールに苛立ったことがなんどもあったような気がしてきた。

新品のマウスだし、マウスを疑うことをしなかっただけで、不具合はとうに出ていたのだろうと思う。

今日、マウスのせいだということがはっきりした。

新品マウスでうれしいな、と、多少うきうきしていたのに、裏切られた思いである。がっかりである。

仕方なく新品マウスはiTunes専用の首振りiMac用に降格し、それにつながってたヴォトロオルの電器屋で買った聞いたこともないブランドの安物マウスをMac mini用で使うことにした。上の写真の右のやつ。

これ、表面がざらざらな感じに加工してあるんだけど、そういうのでよくあるように、経年劣化でベトベトする。

この時間が経つとベトベトするの、やめてほしい。ベトベトするくらいなら別にざらざらじゃなくて、つるつるでいい。というか、ベトベト云々に関わらず、そもそもつるつるで構わない。そういうの買うのが悪いんだけど。

それでも、ホイールでのスクロールがうまくいかないのに比べれば、ベトベトする方がマシだ、と、僕は判断する。

くやしいので、ダメだったマウスの型番を書いておく。 ELECOMの "MY-7UR" というやつ。Mac mini以外なら変じゃないかもしれないが、まだ試してない。また、この型の製品全てが悪いのではなく、僕のやつだけが悪いのかもしれない。とりあえず、僕の買ったやつは、僕のMac miniとはあわなかった。

| その他パソコン全般 | 13:59 | comments(0) | trackbacks(0) |
  | 1/1 pages |  
ciguwerao
CALENDAR
S M T W T F S
 123456
78910111213
14151617181920
21222324252627
28293031   
<< May 2017 >>
LATEST ENTRIES
SELECTED ENTRIES
CATEGORIES
ARCHIVES
SPONSORED LINKS
qrcode