HTMLメールを表示するボタンがありますので、それをクリックやタップして下さい。
というのを毎回言ってるんですが全く伝わらないので画像にしてみたんですよ。
PC版のボタン、今更地球とか書かれても意味分からないですね。
[HTML表示]とか文字で書いて。もう。
2020年6月17日水曜日
Active! mail で HTMLメールが表示出来ない？？
Active! mail で HTMLメールが表示出来ないので、googleアカウントや Microsoft アカウントのパスワードリセットメールが届いても、リンクボタンをクリック出来ません、という質問が時々来ます。
HTMLメールを表示するボタンがありますので、それをクリックやタップして下さい。
PC版のボタン、今更地球とか書かれても意味分からないですね。
HTMLメールを表示するボタンがありますので、それをクリックやタップして下さい。
PC版のボタン、今更地球とか書かれても意味分からないですね。
2019年11月29日金曜日
最小の makefile を作りたい
小さいCプログラムのための makefile を作りたい、という話。
カレントディレクトリに main.c という簡単な C プログラムがあったとき、これをコンパイルして main という実行ファイルを作ることを考えます。 まあ cc main.c -o main で終わり、なので、
てことになるわけですが、やれここでコンパイル時にデバッグフラグだの、数学関数をリンクするだの言い始めると途端にオプションが増えます。
そんなときによく使われるのが makefile に書かれる変数なのですが、これもまた雑に調べるとオプションを指定する環境変数がごちゃごちゃしていて分かりにくい。 特に LDFLAGS と LDLIBS の扱いで混乱してしまい、困ってしまいました。 リンクするライブラリ(-lmなど)はソースファイルの後に書かなければいけないのですが、 LDFLAGSに書けばいいよみたいな資料が若干見当たり、その通りに書くとコンパイルできない（リンクに失敗する）という…
こんなとき役に立つのが make のデフォルトルールの表示です。 Linux の make （GNU make） には オプション -p があるので、
であることが分かります。一方、FreeBSDのmake (BSD make) はオプションと挙動が違いまして、 となります。このデバッグ出力は標準エラー出力に吐き出されますので注意してください。
いずれにせよ「.c ルールはソースファイル foo.c から実行ファイル foo を作る、というルールなので、program: foo.c などとだけ makefile に書いてもルールに合致しないので何も起こらない」 「LDFLAGSはソースファイルより前に付く」「LDLIBSはソースファイルより後に付く」ことが分かりますから、
LDFLAGS にはライブラリの所在を表すパス(-L オプション)などを書き、
LDLIBS にはリンクしたいライブラリの実体なり -l オプションなりを書く、
という使い方であることが分かるわけです。
オブジェクトファイル .o を作る場合はどうなるのか？ については、上記ルールの表示から探してみて、CFLAGS の付けかたについて考えてみるとよいでしょう。例えば、プログラム中で自作関数などが呼び出された回数や処理時間を計測するプロファイラ gprof を用いる場合は、コンパイラとして gcc を想定し、コンパイル時とリンク時の両方に -pg オプションが必要なので、
という書き方になります。（FreeBSDでは cc が clang の時に -pg オプションを付けると、正しく動作しない実行ファイルが出来て困ったので、念のため。 ）
gmake には .c.out ルールが標準で備わっていなかったんですね。知らなかった……
カレントディレクトリに main.c という簡単な C プログラムがあったとき、これをコンパイルして main という実行ファイルを作ることを考えます。 まあ cc main.c -o main で終わり、なので、
てことになるわけですが、やれここでコンパイル時にデバッグフラグだの、数学関数をリンクするだの言い始めると途端にオプションが増えます。
そんなときによく使われるのが makefile に書かれる変数なのですが、これもまた雑に調べるとオプションを指定する環境変数がごちゃごちゃしていて分かりにくい。 特に LDFLAGS と LDLIBS の扱いで混乱してしまい、困ってしまいました。 リンクするライブラリ(-lmなど)はソースファイルの後に書かなければいけないのですが、 LDFLAGSに書けばいいよみたいな資料が若干見当たり、その通りに書くとコンパイルできない（リンクに失敗する）という…
こんなとき役に立つのが make のデフォルトルールの表示です。 Linux の make （GNU make） には オプション -p があるので、
であることが分かります。一方、FreeBSDのmake (BSD make) はオプションと挙動が違いまして、 となります。このデバッグ出力は標準エラー出力に吐き出されますので注意してください。
いずれにせよ「.c ルールはソースファイル foo.c から実行ファイル foo を作る、というルールなので、program: foo.c などとだけ makefile に書いてもルールに合致しないので何も起こらない」 「LDFLAGSはソースファイルより前に付く」「LDLIBSはソースファイルより後に付く」ことが分かりますから、
LDFLAGS にはライブラリの所在を表すパス(-L オプション)などを書き、
LDLIBS にはリンクしたいライブラリの実体なり -l オプションなりを書く、
という使い方であることが分かるわけです。
オブジェクトファイル .o を作る場合はどうなるのか？ については、上記ルールの表示から探してみて、CFLAGS の付けかたについて考えてみるとよいでしょう。例えば、プログラム中で自作関数などが呼び出された回数や処理時間を計測するプロファイラ gprof を用いる場合は、コンパイラとして gcc を想定し、コンパイル時とリンク時の両方に -pg オプションが必要なので、
という書き方になります。（FreeBSDでは cc が clang の時に -pg オプションを付けると、正しく動作しない実行ファイルが出来て困ったので、念のため。 ）
gmake には .c.out ルールが標準で備わっていなかったんですね。知らなかった……
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 という画像を１枚用意し、そこからjpeg画像への変換、ならびに imagemagick, graphicsmagick による eps 変換を行いました。(Ubuntu 18.04LTSで導入したものを使いました。バージョン表記略）
得られた結果はご覧の通り。
なんの指定もせずに変換したepsファイル、つまり Postscript Level 1 にしたものは、ファイルサイズが肥大することが分かります。 また、imagemagick では設定によっては変換することが出来ません。 PS Level2 と Level3 だけを取り出して表にします。
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 のファイル圧縮度合いはどれくらい影響するのか？
ピクセル画像ファイル(jpeg や png) を eps ファイルにしたとき、ファイルサイズが大きくなってしまいます。どうすればいいでしょう？ という件、一昔前なら『 sam2p で変換しとこう』ということにしていたのですが、Ubuntu 18.04 LTS を導入したところ、正式に sam2p が無くなっていました。そりゃあなあ…… debian package にすら既にないし、そもそも上流公式ページすら無くなってるしなあ（ソースはあるっぽい）
というわけで sam2p 無き令和の時代にあって、改めてepsファイルにどう変換するか問題を扱っていくわけですが、とりあえず下記のように testpng.png という画像を１枚用意し、そこから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 のファイル圧縮度合いはどれくらい影響するのか？
登録:
投稿 (Atom)