本来USBハブはバスパワー負荷を保証しておらず、メーカーの自己防衛です。その観点からは、「各々必要分が配分され、合計が500mAまで」と言う動作となります。いう記述からすると、やっぱりそれぞれの穴に最大Aを定めているものもあるのは専門の充電器だからで、ハブは穴ひとつごとに電流の調節をする仕組みは組み込んでいないと考えてよいのか、と、一旦は納得しました。ここではパソコンの穴に電源のないハブを挿して500を二つに分ける状況を想定しており、500以上を流した場合のことは書いてありません。上の引用部からすると規格は500は出せよ、とは言ってるけど、500しか出すな、とは言ってないということになります。僕のハブの場合、本文に書いたようにACアダプタが容量2100になってるので、ひとつしか挿さなければまるまる全部そこに出すんだろうと判断したわけですが、2100というのは、各穴ごとに500取られることを想定して500x4、自分の消費もあることだし余裕を見て+100、ということでしょう。欲しがるやつに500を超えて渡してしまったら、他の穴に500が保証できなくなります。「最低は500mAが可能なこと」という規格に抵触しないんでしょうか?電源なしのハブならいざ知らず、いやしくも電源をつけている以上は、それぞれの穴に500を保障するために最大電流を各穴ごとに設けていても、おかしくはないようにも思えてきました。この辺は、全くあてずっぽうにすぎませんが、ハブの品質によるのかと思います。安っぽいハブならそういうことは考えないでしょう。それなりに真面目なハブは、合計が最大2100である以上、各穴ごとに500ちょっとでリミットをかけてあったとしてもおかしくはなさそうです。優れたものなら、いくつつながっているか、それぞれいくら欲しがっているか、を判断して、合計2100の範囲内で適切に分配するでしょう。(そんなハブが本当に存在するかは怪しく思いますが。)で、僕のハブはどうなんだ、ということですが、これもあてずっぽうですが、500までしか欲しがっちゃダメ、という決まりになってた頃のものだし、いくらで買ったか忘れましたが僕が買ったものなのでどうせ安物に違いないし、何も手を打ってない、つまり流せるだけ流すようになってる、と、推測しておきます。確認する手段は、スマホの充電時間で推測する以外に、今のところ思いつきませんが。それにしても、ブログを書くということは、自分の無知をさらけ出すいかにも恥ずかしい行為であるということを、今回改めて思い知りました。この何年か主に書いているリナックスのことなら知らなくても別にどうでもいいことですが、今回の電流みたいな話について基本的なことも何もわかっていないのはかなり情けないことだと、いろいろ調べているうちに自覚させられました。今日現在、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圧縮しておいた画像を使用すればいいわけではあるが、すでに作っちゃった書類(それも一枚ならともかく何枚も画像が入ってる)を作りなおすのは面倒である。miniではアップデートを怠っていたおかげで5.0.5.2が入っていて、それでは問題なく画像をJPEG圧縮したPDFが作れた。そこで、新しいのを入れちゃった機械のためには、5.0.いくつならいけるだろ、という判断でその中では最新の5.0.6.3を下記のLibreOfficeの古いバージョンを置いてあるところから落としてきて、インストールしなおした。これならば問題は出ない。http://downloadarchive.documentfoundation.org/libreoffice/old/(ここ、ダウンロードにかなり時間がかかる。速く落とせるところもあるかもしれないが、とりあえず僕が知ってるのはここ)というわけで、PDFエクスポートのJPEG圧縮に関する限り、現時点では5.0.6.3を使うのがベストと思われる。ちなみにLibreOfficeのPDFエクスポートに関しては、4.3.3.2にも別の問題があることを一昨日の記事で書いたので、興味のある方はご参照のこと。ciguwerao2016/06/15の記録:2015/12/17は42355メモ。エクセルを使い慣れている人にとっては常識か知らんが、書式を日付にして適当に数字を入れると、その数字に対応した日付になる。僕はエクセルじゃなくてLibreOfficeのCalcだけど、2015年末についてちょっとした表を作っていて、いちいち日付を打っていくのが面倒なので、上の仕組みを利用することにした。あたりから始めて狭めていった。何回目かに入れた42000が思いの外惜しい2014/12/27になったので、——頭のいい人ならここまでわかれば計算できるのだろうが僕は頭が悪いので——大体一年分の360を足して2015/12/22、その次に目指す42355を探し当てた。部分はそのセルの番号に合わせる)と、ちゃんと2015/12/18になった。そのあとは計算式じゃなくてその(12/18の)セルをコピーして、その下に続くセルを適当にばばっと選択してペーストしたら、ちゃんと選んだセルの分だけ連続した日付になった。嬉しいので来年分くらいまでずっと日付を入れてやった。必要なのはこの年末年始だけ。ikedat16さん、ありがとうございます。2015/12/17が42355などという知識は、今日の僕の作業には実は必要のないものでした。セルの書式を日付に設定したうえで、指定した書式通り(僕の場合は何度も書いてるような年月日をスラッシュで区切るやり方)に日付を自分で打ち込むと、データ上は自動でその日付に対応した数字になるようです。書いて、その次のセルからは上に書いたようなやり方をすれば、2015/12/18以下の日付になってくれます。いうわけで、上で書いたことの半分くらいは、今日の目的からはどうでもよかったんですが、それはそれとして、2015/12/17が42355というのは面白いデータかと思います。ciguwerao2015/11/11の記録:新しいOpera先ほど2015/11/05の記録に、Opera関連の追記をした。Windows10以外の環境ではOperaは古いのを使っていると書いたのだが、その後、古いオペラの最終版であるところの12.16は脆弱性があるため使えないという記事を見つけたこともあり、葛藤はあったがMacOSXのオペラを最新版にアップデートするという決断をした。慣れ親しんだ旧版の動作をWindows10上の最新版Operaでは再現できないでいたため。言っても、ちょっと設定画面をいじってみただけで真面目に検討したわけではない。今回OSXでアップデートするにあたり、もう少し検討してみたところ一応の成果を見たので、以下に記録しておく。気に入らなかったのは、新しいタブでリンク先を開いた際に、そのタブが選択された状態(アクティブな状態)にならない点。「以前の操作性を再現!?最新版Opera向け拡張機能(アドオン)まとめ」というページで、それを実現する機能拡張を二つ紹介してくれている。TabsSimpleTabOrder前者の方が設定できることが多いが、僕の求める設定はどちらでもできる。次に書くことから、後者を使うことにした。旧版でできたことの中で再現したいもう一つの設定は、ブックマークを新しいタブで開けるようにすること。この点、検索してみると、それを望む人はちらほらいるものの、現時点では実現方法がわからなかった。menu?というやり取りが見つかった。そこで試しにブックマークツールバー内やブックマークメニューのブックマークの適当なのを選択した状態でマウスのカリカリボタン(真ん中ボタンというかホイール)を押してみたら、確かに新しいタブで開いた。Tabsを使った状態では、ブックマークは選択された状態ではなくバックグラウンドで開いた。一つのSimpleTabOrderでも試してみたら、こちらではブックマークも選択された状態の新しいタブで開けた。ボタンではなく普通のクリックでブックマークを選んでも新しいタブで選択された状態で開けるようにしたいのだが、それを実現する方法が見当たらなかったので、今日のところはこれでいいことにする。==Windows10でも試してみたがOSXの場合と同じように動作した。当然のことと思うが、念のため追記しておく。Linux用は古い(WebKit移行前の)12.16が安定版としてはいまだに最新のようだ。ciguwerao2015/08/21の記録:ベトベトするマウスについて上の写真(トリミングしてるので光の加減が変)はこの前追記で愚痴を書いたベトベトするマウスだが、あの後指と固く絞った雑巾で根気よくこすったら、表面のベトベトをあらかた落とすことができた。こすってもベトベトを取り去ることはできないんでないかと思っていたが、案に違って結構ちゃんと落とせた。裏の一部にまだベトベトは残っているが、マウスパッドに引っかかるということもないし、手で触れることはない部分だし、使う分には全く気にならない。素材自体が劣化するとベトベトになるもの(ラバーとか)だったらこうはいかないだろうが、表面に貼るだか塗るだかしてあっただけだったのが幸いした。最初っからこれで良かったのに。6€くらいで買った安物なのでポインタの挙動とかクリックの反応だとかに多少不安定なところはあるが、使用に耐えないというほどではない。僕の使い方だとどうも手に馴染まないのが残念だが、思ったよりは悪くない。iTunes専用機に左遷したエレコムのマウスの方は、そっちではホイールの挙動に特に問題がなさそうなのも良かった。この体制でいこうと思う。関係ないが、昨日今日で色々試して、文字色と追記・注記部分の色使いを変えてみた。例(exemple)右のカレンダーとかがある部分の色をもとに明るくしたり暗くしたりして試してみたわけなんだが、そういう理屈を先立てたこともあり、僕のセンスの問題もあり、特に注記部分の色なんかが好ましい色にならなかった。全体に色の調和がなく汚らしいような気もするが、パソコンというかモニターによってはそんなに悪くもない場合もあるので、これでしばらく行く。