2019年9月17日火曜日

png や jpeg を epsにする話(2019)

『jpeg 画像なら gm convert で eps2 にして、 png 画像なら convert で eps3 にするとよい。』という話になりました。どっちかにまとまらなかった…

ピクセル画像ファイル(jpeg や png) を eps ファイルにしたとき、ファイルサイズが大きくなってしまいます。どうすればいいでしょう? という件、一昔前なら『 sam2p で変換しとこう』ということにしていたのですが、Ubuntu 18.04 LTS を導入したところ、正式に sam2p が無くなっていました。そりゃあなあ…… debian package にすら既にないし、そもそも上流公式ページすら無くなってるしなあ(ソースはあるっぽい)

というわけで sam2p 無き令和の時代にあって、改めてepsファイルにどう変換するか問題を扱っていくわけですが、とりあえず下記のように testpng.png という画像を1枚用意し、そこからjpeg画像への変換、ならびに imagemagick, graphicsmagick による eps 変換を行いました。(Ubuntu 18.04LTSで導入したものを使いました。バージョン表記略)
 
得られた結果はご覧の通り。  
なんの指定もせずに変換したepsファイル、つまり Postscript Level 1 にしたものは、ファイルサイズが肥大することが分かります。 また、imagemagick では設定によっては変換することが出来ません。 PS Level2 と Level3 だけを取り出して表にします。


jpg(im) jpg(gm) png(im) png(gm)
jpg/png 45039 39572
eps2 48968 48945 49651 49642
eps3 49424 61298 37030 45145

jpeg画像を最も小さく変換するのは graphicsmagick の Postscript Level 2 指定を行った変換 ( gm convert picture.jpg eps2:picture.eps ) となりました。
一方、png画像を最も小さく変換するのは imagemagick の Postscript Level 3 指定を行った変換 ( convert figure.png eps3:figure.eps ) となりました。
いったい何故このような差になったのか……

imagemagick の結果だけを比較してみます。  
jpeg の変換は eps3 より eps2 のほうがファイルサイズが小さく、逆に png の変換は eps2 より eps3 のほうが小さいことが分かります。png の eps3 への変換が、元の png 画像よりも小さくなっているのは、元の png 画像が低い圧縮度合いであったためと思われます。(元画像は gnuplot の term pngcairo で作成したものです。)

これに対し、graphicsmagick の結果だけを比較してみます。  
graphicsmagick が生成する PS Level 3 eps は、データストリームがASCII文字になっています。その影響を大きく受けるのは jpeg をPS Level 3 eps に変換するときのようで、imagemagick の場合以上に、PS Level 2 eps よりもファイルサイズが大きくなります。
また、graphicsmagick で png を変換すると、 imagemagick で変換したものより若干ファイルサイズが大きくなります。PS Level 3 eps が 元の png 画像のファイルサイズより大きいことから、imagemagick と違い、改めて圧縮するようなことはしていないようです。(そういえばgmのほうが処理が早かったような。)

表を眺めてみると、graphicsmagick で jpeg を eps3 に変換するのが最もファイルサイズが膨らむようなので、それだけは避ける。 gmなのかimなのか分からないなら「とりあえずeps3にすることだけ考える」でいいのかも知れません。つまり、

convert pixelpicture.jpg eps3:pixelpicture.eps

これだけ覚えておけ、でもいいのか……? PS Level 3 をうまく処理出来ないみたいな話が出てきたら諦めてeps2にしましょう。

誰かやってください:
・jpegファイルからpngファイルを作った場合、同じような結果になるのか?
・png や jpeg のファイル圧縮度合いはどれくらい影響するのか?

2019年8月2日金曜日

Debian 10.x (GNOME)でデスクトップにファイルアイコンが出ない

Debian 10(buster) GNOME版をインストールしたらデスクトップにアイコン(ファイル)が表示されないのは、ファイル(nautilus) 機能からデスクトップ描画機能が無くなったから、のようです。
https://kledgeb.blogspot.com/2018/01/ubuntu-1804-30-nautilus.html

デスクトップ機能はファイルブラウザじゃなくてgnome-shellに持たせようという、上記Webページで説明されている方針(3)の方向に向かっているようで、Debian 10 では
gnome-shell-extension-desktop-icons
パッケージを入れ、gnome-shell の拡張機能として使うと良いようです。

で、ここで個人的に困ったんですが、これ gnome-shell の拡張機能なので、gnome-session-flashback で古いセッションを使っている場合は機能しません。

そのため、昔のようなプルダウンメニューも使いたいし、デスクトップアイコンも表示させたい、という場合は、gnomeの標準セッション(gnome-shell)で、

 (1) gnome-shell-extension-desktop-icons パッケージを入れる。
 (2) gnome-shell-extensions パッケージの依存関係で gir1.2-gmenu-3.0 が入っているることを確認する。無ければ入れる。

とすれば、gnome-tweaks コマンドの「拡張機能」の中に「Applications menu」が表示されるので、これを on にすると、左上に『アプリケーション』から始まるプルダウンメニューが表示され、階層化されたメニューが使えるようになります。
さらに「Desktop icons」をonにすれば、デスクトップフォルダの中身とゴミ箱と何故かホームディレクトリのアイコンが、デスクトップに表示されます。表示したいものを選びたい場合は、歯車アイコンを押して微調整するとよいでしょう。

Linuxデスクトップ環境においても、少しずつ新しい操作感覚に慣れる必要がありますね。

2019年7月16日火曜日

dia で図に日本語を入力出来ない?(ubuntu 18.04LTS)

Ubuntu 18.04 LTSに入れた dia で日本語が入力出来ないときは、 dia --classic というオプションをつけて起動すると、入力出来るようになるかも、という話。

Ubuntu 18.04 LTS を使っていて、dia で日本語を入力しようとしても出来ない、という相談を受けました。検索してみると、dia-normal を使うといい、とか、オプションに -integrated をつけるといい、とかいろいろ出てくるのですが、/usr/bin の下には dia しかないしなあ…… と思ったら、どうも最近(2017年以降)は無いようですね。理由はこれ。

https://metadata.ftp-master.debian.org/changelogs//main/d/dia/dia_0.97.3+git20160930-8.1_changelog
というわけで、 当面はこれでしのぎつつ、なんで classic じゃないのは日本語通らないんだろう、というのを追求したいところですが誰か代わりにやってほしい……

2019年6月17日月曜日

UTF-8で書かれた日本語テキスト, テキストファイルをPostScriptに変換する方法(2019/11)

gnome-u2ps があったのですが開発が停滞しており、debianからはパッケージがREMOVEDになってしまい、その後……(2019/11/4 gnome-u2psに関する追記あり)

・gedit からファイルに印刷する

geditでテキストファイルを表示してファイルに印刷する、という方法があります。 CLI操作が苦手って方がよくやるようです。 psもpdfも作れるようですので、重宝している方も結構いらっしゃるのかも?

・paps (+nkf)

UTF-8で書かれたテキストファイルを pango ライブラリ を用いてレンダリングし、 PostScriptファイルにするフィルタです。 debian のパッケージにはUTF-8で書かれた多言語テキストファイルの例(/usr/share/doc/paps/examples/small-hello.utf8)があり、これを変換してみると便利さがよく分かります。

sample-hello.utf8 には日本語の半角カナが含まれるのですが、これがきちんと半角カナのまま変換されるのは、なかなか強力ですね。
レンダリングをpapsがやり、元となる文字列が何であったかという情報を含みません。そのため、ps2txtでテキスト部分だけ引っ張り出す、みたいなことも出来ません。pdfもにおいても、本文をpdfリーダーで取り出せないものが出来ます。

印字フォントを変更するには、fontconfig で認識しているものを使いますが、文字サイズの変更だけでも受け付けるようです。デフォルトは "Monospace 12"となっていますが、実体はシステムによって微妙に違うでしょう。

日本語のテキストファイルを印字する場合は nkf を併用します。nkf --guessを使って UTF-8(LF)などと返ってくるなら、そのまま変換すればよいですが、それ以外の場合はパイプを使ってしまえばよいでしょう。

DebianにもUbuntuにもパッケージがあり、これが一番安定しているようです。RHELのナレッジベースでも紹介されていますね。


・nkf + e2ps

 e2psにはバグが多いのですが、それでもdebianパッケージなどに入っていることから利用者が若干いらっしゃるようです。e2ps は EUC-JP を受け付けて PostScript を作るものなのでnkf -edなどとした変換が必要になります。

・nkf + a2ps-j (Perl版a2ps)

 日本語テキストファイルをPostScriptにするプログラムには他にも a2ps-j (a2ps perl版) がありますが、perl 4時代のスクリプトなので、MacPortsや各種BSDパッケージなどではパッチを当てたり、色々対応しながらやってらっしゃる方もおられるようです。

https://svnweb.freebsd.org/ports/head/japanese/a2ps/
https://www.uconst.org/blog/archives/437

 個人的に注目しているのが、a2ps-j をUTF-8対応させる、以下のブログのパッチです。開発者さんにおかれましては、このパッチのライセンスを再利用しやすいものに設定していただけますと、各OSでのパッケージとして採用が進むと思いますので、何卒よろしくお願いしたいです。

a2ps Japanese UTF-8 patch (日本語 UTF-8 パッチ)
http://zyushimatsu.cocolog-nifty.com/blog/2014/12/a2ps-japanese-u.html

 なお、GNU a2ps や GNU enscript は日本語がダメそうなままです。つらい。

 (2019/11/4) コメントいただいておりました。
gnome-u2ps が gitlab で復活しているようです。
https://gitlab.com/gnomify/u2ps

で、この記事では紹介していませんでしたが、実は u2ps には数年前に同じ名前で別の人が作ったものがあるんです。
https://gitlab.com/arsv/u2ps

そう考えると、gnome-u2ps は u2ps-gtk とかにしたほうがいいような気もしますね。(ngraph-gtk 的なネーミングセンス……)

2019年6月15日土曜日

nkfのマニュアルを読み違えていた

nkfのマニュアルには、改行コードを変換するオプションの指定方法として、こんなふうに書かれています。
で、これを見て、 こうやって使うのかなあ、なんで -d が必要なんだろうなあ、と思っていたのですが…… という意味だったのですね。 nkf --helpで表示されるメッセージには、-d-cの記載がなく、 実際-Luに併記しなくても問題なく動作したので、あれ? と思ってソースコードを確認したら……
https://osdn.net/projects/nkf/scm/git/nkf/blobs/master/nkf.c 同じだこれ!? という話。 もしかしたら、こう書いてあれば誤解はなかったかもしれない… 他にも何箇所かありそうでつらい。

なお、この1文字オプションは他のものと併用できるので、 つまり、なんかわからんテキストファイルを、 Linux風(UTF-8, LF)にしたいならオプションは -wd とする、 Windows風(Shift_JIS, CRLF)にしたいならオプションは -sc とする、 みたいな形で覚えてしまってもいいのかもしれません。

2019年6月10日月曜日

array環境と角括弧(ブラケット)

 もうarrayは行列の中に線を引くとか例外的なときにだけ使い、基本 matrix (amsmathパッケージ)にしたい、という話。

 行列の記述方法としての是非はちょっと置いておくとして、例えばこんな行列を組版しようとしました。  ところがこれはエラーになり、組版できません。  面白い? ことに、これはエラーになりません。  2 行目以降の 1 列目の要素、が、[ で始まっている場合、 エラーとなるようです。なにかのオプション記述と勘違いしているのでしょうか。

 対処方法は、\hspace*{0pt}[0] のように、 ゼロ幅スペースや空白文字を頭に置く、か、 \left[ 0 \right] などとすることです。
大きくならないことが分かっているのに \left[ - \right]を書くのもなあ、と思っちゃいますね。空白文字なら ~ で1文字ですが当然謎の空間が生まれてしまいます。\hspace*{0pt}もちょい長いですね。複数行あったとき投げ出したくなるでしょう。

 ちなみに amsmath パッケージの matrix 系の環境を使えば、これだけで済みます。
とても、楽。

 array環境は行列の中に縦横線を引くときにだけ使い、基本的には amsmath の matrix 系で済ませていいと思います。

余談:もしかしてtabularもダメかな? と思って試してみたらやっぱりダメでした。 ゼロ幅スペースを入れてエラーを回避していますが、お試しの際は \hspace*{0mm}を省いてみてください。 array のときと同様に、 Missing number, treated as zero.などと、 何かのオプションと勘違いしたエラーを出してきます。

2019年5月28日火曜日

エディタから latexmk を使うと何故か pdflatex を呼び出される

去年ほぼ同じ内容をまとめていたので要約

Q: エディタの拡張機能とかで latexmk を使ってコンパイルすると、latexmkrc の記述を無視して pdflatex が使われてしまうのは何故?
A: (1) エディタが付加している latexmk のオプションに -pdf が含まれていたから (2) latexmkrc の問題(正しく読み込まれていない、実はうっかり別のファイルで $pdf_mode やオプションを指定してしまっていた、など)
Q: 作業ディレクトリをカレントディレクトリとして動作させたシェル(cmd, PowerShellなど含む)で latexmk を実行したらうまくいくのに、エディタの拡張機能とかで latexmk を使ってコンパイルすると失敗するのは何故?
A: ディレクトリのパスやファイル名に、漢字や空白文字が含まれていたり、ネットワークパス(Windowsの場合)だったりするとうまくいかないときがあります。

Visual Studio Code + LaTeX Workshop ではまっていたのです

texファイルのホームディレクトリに latexmkrc を作って、

$pdf_mode = 3;
$latex = 'platex -synctex=1 -halt-on-error %O %S';
$dvipdf = 'dvipdfmx %O -o %D %S';
$bibtex = 'pbibtex %O %B';
$max_repeat = 5;

とか書いておけば、 platex と dvipdfmx を使って良い感じに仕上げてくれるはず、なのですが、 vscode と latex拡張の組み合わせでは、何故かpdflatex が実行されてしまいます。何故? latexmkrc が読まれてないのか? と思ったのですが、 理由は package.json で設定されている latex-workshop.latex.tools にありました。
https://github.com/James-Yu/LaTeX-Workshop/blob/v7.0.1/package.json
            {
              "name": "latexmk",
              "command": "latexmk",
              "args": [
                "-synctex=1",
                "-interaction=nonstopmode",
                "-file-line-error",
                "-pdf",
                "-outdir=%OUTDIR%",
                "%DOC%"
              ],
              "env": {

              }
            },
そこに-pdfが書いてあるせいです。これを書かれてしまうと latexmkrc が $pdf_mode を指定しても無視するんですよね…勘弁してほしいなあ…

(2021年12月追記:最近では "latexmk(latexmkrc)"というものが追加されており、argsに何も設定されていないモードが追加されていましたので、これを使うとよいでしょう。)  

対策は、latexmk のツールの設定を上書きし、 -pdf オプションを外すことです。
ファイル→基本設定→設定、を選び、latex-workshop.latex.tools を検索し、settings.json をクリックします。
表示されるjsonファイルに "latex-workshop.latex.tools" 要素を入れてしまいましょう。 補完入力に乗っかると全部書かれてしまいますが、latexmk の args(引数)に該当する部分をよく見て、
    "latex-workshop.latex.tools": [
        {
            "name": "latexmk",
            "command": "latexmk",
            "args": [
                "-synctex=1",
                "-interaction=nonstopmode",
                "-file-line-error",
                "-outdir=%OUTDIR%",
                "%DOC%"
            ],
            "env": {}
        }
    ]
などとすればよいでしょう。

2019年5月13日月曜日

e2ps の修正パッチを一段落させた

 Linux などで日本語テキストファイルをPostScript形式に変換するソフトウェアの一つに e2ps があるのですが、いろいろバグが多くて困っており、一昨年くらいからちまちまと直したりしていました。
http://taraijpn.blogspot.com/2017/06/e2pspatch.html

 とりあえず Debian BTS で公開されているバグを直すところまで出来たので改めて紹介します。修正点は以下の通り。
  • フォントリストの文字型配列がコンパイル不能な書き方だった点を修正。
    • 各ディストリビューションで対応されています。
  • 用紙サイズのポイント数を PostScript の仕様で使われている数に合わせて修正。
    • 一部ディストリビューションで対応されています。
  • 生成される PostScript が EPS だった問題などを修正。
    • これでようやく fixps に怒られずに済みます。
  • 出力したページ数が誤っていた問題を修正。
    • ja_JP.EUC-JP 環境以外で動いているときに起こる問題でした。
  • ヌル文字から始まるテキストファイルが与えられるとクラッシュする問題を修正。
    • これは  https://bugs.debian.org/715852 で報告されていたものです。ヌル文字しかない、もしくはヌル文字から始まる(という意地の悪い)テキストファイルを印刷しようとすると起こる問題です。
  • 複数のファイルをまとめて変換すると、他のファイルの印刷末尾に余計な文字列が含まれる問題を修正。malloc を全て calloc に書き換えた。
    • e2ps README.euc README.english などとして出来たファイルを見たとき気づきました。環境依存?
  • Letterサイズで2面付け(-p2, -l2)を行うと用紙をオーバーする問題を修正。
    • 用紙のアスペクト比を維持するか、アスペクト比を歪めて紙面を広く使うか、どちらか悩んだ結果、前者を取りました。本来であればマージンを調整すべきところなのですが、それは全ての用紙サイズで考えないといけないことなので棚上げ。
  • PostScript の作者 ( %%Creator: ) は e2ps であるものとした。
    • CREATOR は help で使ってたので手を入れました。

 以上の内容を、patch1 として公開しました。(2019/5/14 patch1タグを打ってあります。
https://gist.githubusercontent.com/taraijpn/ea10ff9e908befafab7cff719f26dd20/raw/9a4a6fd502958a0e87db364174cbc331d07055be/e2ps-4.34.patch


 実はもう少しやらないといけないことがあって、
  • 変数の型を整理する。
    • unsigned char を使わないようにする。そもそも string.h で読んでいる関数と合わず warning が出ます。
    • unsigned char や signed char といった型は使わないようにして、コンパイラの警告をなくす。
  • 読み込めるファイルサイズを制限する。(2GB程度の予定)
    • unsigned long を size_t に直したらえらいことになったので。
 機械的な置き換えで問題ないかと思ったのですが、そんなに甘くなかった。sjisの変換に失敗する、とか、READMEにある他アーキテクチャ対応に悪影響が及びそうな気がするので、ちょっと止めてあります。とりあえず patch1 の上流での採用を目指したいところ。

 なお上流への連絡は、WebページにあるCGIで掲示板への書き込みやメールの送信を試みましたがいずれもエラーで動かず、2015年に公開されていたWindowsのプログラムにあるreadmeにメールアドレスが掲載されていたので、そこに送っています。果たして無事届いていますでしょうか……

bloggerにログイン出来なかった…

しばらく使っていなかったのですが、一般ユーザー向けgoogle+との兼ね合いかなにかで、2019年4月以降、 bloggerへのログインがうまくいかない場合が起こるようです。

ログインをクリックして自分のgoogleアカウントを選択しても、
https://www.blogger.com/about/?hl=ja
何度もこのログインページに戻される、という状況。

で、解決方法が以下。
https://support.google.com/blogger/thread/3471576?hl=en

ブラウザから google のサービスにログインしている状態で、
https://www.blogger.com/switch-profile.g
にアクセスし、blogger用のプロフィール(要は名前?)を付けなおすことで、自分のblogger投稿ページに進むことが出来、それ以降は自分のbloggerページからログインすることが出来るようになってます。

意外と見つからなかった…