ラベル TeX の投稿を表示しています。 すべての投稿を表示
ラベル TeX の投稿を表示しています。 すべての投稿を表示

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年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": {}
        }
    ]
などとすればよいでしょう。

2018年6月21日木曜日

latexmk の設定ファイルとうまく付き合う

 latexmk にオプションとして -pdf などを与えるのではなく、主となる .texファイルが存在する作業ディレクトリに latexmkrc ファイルを置いたらどうだろう? という話。

 latexmk では、LaTeX文章のpdf化の手順を選択する方法として、latexmkrc 設定ファイルに変数 $pdf_mode を設定するか、 latexmk にオプションを与える方法があり、オプションのほうが優先されます。
 このオプションが一部のエディタや拡張機能で当然のごとく設定されていると、自分の望むpdf化手順と合わないとき、トラブルの原因となります。
†VisualStudio Code + LaTeX Workshop など。

 主となる .texファイルが存在する作業ディレクトリで、
% latexmk main.tex
とだけ入力すれば .pdf まで出来上がる、というのが理想的な動作ですし、エディタから呼び出すときもトラブルが減るのではないかな? と思うわけです。

 latexmk を呼び出す側には極力オプションを与えず、latexmkrc だけで動作を切り替えることは出来ないでしょうか? 実は、latexmkrc には、以下のように読み込み順が存在します。
       1) The system RC file, if it exists.
       2) The user's RC file, if it exists.
       3) The  RC  file  in  the current working directory.  This file can be named either "latexmkrc" or ".latexmkrc", and the first of these to  be found is used, if any.
       4) Any RC file(s) specified on the command line with the -r option.

 で、latexmkrc の $pdf_mode の数値、 pdf化の手順、 latexmk に与えるオプションとの関係は、以下の通りになります。
  • $pdf_mode = 0 と書くと、pdf を作りません。 (-pdf-)
    • $latex の確認が必要です。
    • $xelatex で .xdvだけを作る方法を確かめていません。-xelatex -pdf- とオプションをつけても、$latex が使われるような…? 
  • $pdf_mode = 1 と書くと、pdflatex を使うことを表します。 (-pdf)
    • $pdflatex の確認が必要です。
  • $pdf_mode = 2 と書くと、tex→ dvi → ps→ pdf とたどります。 (-pdfps)
    • $dvips の確認が必要です。
    • $ps2pdf の確認が必要です。
    • $latex の確認が必要です。
  • $pdf_mode = 3 と書くと、tex→ dvi → pdf となります。 (-pdfdvi)
    • $dvipdf の確認が必要です。
    • $latex の確認が必要です。
  • $pdf_mode=5だと xelatex, xdvipdfmx (-pdfxe ) を使うようです。 上記ドキュメントにはありませんが、 $pdf_mode=4 で lualatex (-pdflua ) を使うようです。
  • $pdf_mode={4,5} (-pdflua, -pdfxe も?)については、古い latexmk には含まれていないようです。 例えば Debian 9.x の latexmk (Ver. 4.41 texlive2016 相当?) には存在しません。texlive2018 の latexmk (Ver. 4.55) なら含まれています。
 というわけで、
  1. ~/.latexmkrc にはツールの設定だけ書いておく。
  2. 作業用ディレクトリ/latexmkrc には $pdf_mode の数値だけ書いておく。
    • ~/.latexmkrc で予め設定しておいてもよい。
    • platex や uplatex を使い分けたいなら、さらに $latex などを書いておく。
  3. latexmk を使うときは -pdf などのオプションを付けない。
という方針は有りなんじゃないかな、と思いました。

 ドキュメントごとにコンパイル方法やツールを変える、というのは、なかなかしんどいと思いますが、様々な LaTeX 環境を体験したい場合や、psfrag など dviware が決め打ちになってしまうパッケージを使う場合は、どうしても避けて通れませんね。(避けたいですけど…)
 そんなときでも、作業用ディレクトリの下に latexmkrc を書いておくという手段は、作業手順をメモする効果もあるので有効かな、と思ったのでした。

2016年7月1日金曜日

dvipdfmx で作成した pdf に印刷制限等をかけるとファイルが壊れる?

Windows 環境で LaTeX を扱っているのですが、 dvipdfmx で作成した pdf ファイルに、Adobe Acrobat Pro DCで権限パスワードを付与し、印刷制限をかけて保存すると、そのpdfファイルを Acrobat で開くことが出来なくなる。google docsやsumatra pdf readerなら開くことが出来る。……という謎めいたトラブルに見舞われました。

権限パスワードを付与して印刷、コピー、編集の制限をかける方法はこちら。
https://helpx.adobe.com/jp/acrobat/using/securing-pdfs-passwords.html

理由は分かりませんが、解決方法としては、
『dvipdfmxで作成したpdfファイルをAdobe Acrobat Pro DCで開き、その他の形式で保存→最適化されたPDFで別名保存してから、そのファイルを開き直して制限をかける』ということで落ち着きました。

dvipdfmxで作成したpdfファイルを直接Acrobat で操作しないほうがいい、ということなのでしょうか。不思議ですね。例によって細かい追究はしていません。

dvipdfmx の機能で直接制限つきのpdfを作ろうとしたのですが、
This is dvipdfmx Version 20160307 by the DVIPDFMx project team,
modified for TeX Live,
an extended version of dvipdfm-0.13.2c developed by Mark A. Wicks.
このバージョン(w32tex)ではうまくいかなかった……残念。

2014年9月26日金曜日

latexmkの最も敷居の低い使い方

makefile を作ります。

all:
clean:
        latexmk -c hoge.tex

latexmk を設定しなくても make clean を簡単に作れます。おわり。 

……これ地味に見えるんですが、rmとアスタリスクの組み合わせが招く不幸を防げるという点でとてもありがたいと思いました。-c にするか -C にするかはお好みで。

2014年6月23日月曜日

スマフォの写真を LaTeX で書いてるレポートにepsで貼りたい人

簡単に言うと「スマフォの写真画像は大きすぎるので縮小しましょう。そしてepsにしたいなら convert (ImageMagick) ではなく sam2p を使いましょう」という話。
説明はいいからコマンド寄越せって人向けに、picture.jpg を figure.eps に変換するにはこうしろ!と書いておきます。例によって% はプロンプトです。画像は横長と仮定します。

% convert -resize 640x picture.jpg figure.jpg
% sam2p figure.jpg figure.eps

ファイルが複数ある場合はいろいろ仕掛けを考えて下さい。(説明を読まない人向けの数値設定にしてみました。)


以下解説。


まず貼りたい写真の素性を明らかにしておきましょう。とりあえず横長の画像であることを前提にしておきます。 ImageMagick が入っているなら identify もあるはず。

% identify picture.jpg
picture.jpg JPEG 2112x1500 2112x1500+0+0 8-bit DirectClass 401KB 0.000u 0:00.000

最近のスマフォの写真は解像度が高いので、必然的に写真のファイルサイズも大きくなりがちです。 が、そんなに大きくなくていいんじゃないですか? 本当にそんな解像度要りますか? 横幅2112pixelって、300dpiなら確かに17.9センチとA4縦のレポートに1枚貼るには程よいサイズですけど、 その写真、そんな印刷品質で出さないと内容が伝わらないほど細かい情報、ありますか?

例えばこれくらいのサイズでいかがでしょうか。

% convert -resize 800x picture.jpg figure.jpg

横長の画像を前提にしていますが、もし縦長なら -resize x800 でしょうか。 72dpiでも21.1cm程度の画像になりますから、これくらいでも十分に思えます。
pdfにするときも、縮小したものを貼るほうが何かとトラブルが少なくてよいでしょう。 
で、これをepsに変換するわけですから、convertを使えばコマンド1つで、例えば

% convert -resize 800x picture.jpg eps2:figure.eps

とすれば良さそうなものなのですが、どうもこのconvertが作るepsファイルがいまいちプリンタとの相性が良くないのです。 プリンタとの相性が悪いのかプリンタドライバとの相性が悪いのか、とにかく RICOH Ridoc IOGate (RHEL版) で管理されているプリンタでよく印刷が止まります。大学などの演習室で利用実績のあるプリンタ管理ソフトウェアですので、 たとえば演習室でレポートがうまく印刷出来ない場合はこれを疑ってよいと思います。

というわけで代案は、sam2pコマンドを使うことです。入ってなければ入れてもらいましょう。 sam2p はリサイズ機能を持っていませんので、convertで縮小してから、

% sam2p figure.jpg figure.eps

これで変換した figure.eps を貼ることをお勧めします。

いまどきepsもないだろう、と思われる方でも、せめてjpg画像のサイズには気を遣った方がいいと思います。 スマフォの写真を何も考えずに貼ると、pdfファイルのサイズが肥大化します。気をつけましょう。

2008年7月4日金曜日

calc2latex

ここ数週間Excel&OOo Calcとにらめっこする日々を過ごしている私ですが、なんと世の中には
Calcの表をLaTeXのそれに変換してくれるすばらしいマクロがあるというじゃないですか。

http://calc2latex.sourceforge.net/indexj.html

これはすばらしい・・・早速使ってみよう。

2008年5月9日金曜日

pTeXパッケージ関係のメモ(2008年5月)

FreeBSD, Debian, Ubuntu について日本語TeX環境(ptex)パッケージの状況を整理しておくメモ。自分で適当に調べたものなので、事実誤認や調べ不足があったらごめんなさい。
予備知識はTeXディストリビューションあたりを見ていただくとして。
FreeBSD ports:
ptex(japanese/ptex)を入れておけばOK。teTeX(print/teTeX-base)に依存。
tgifなどlocaleにja_JP.eucJPを要求するものがあるので locale も ja_JP.eucJP でいい気がする?
FreeBSDのドキュメントプロジェクト用メタポート (textproj/docproj) で jadetex (print/jadetex) を用いる場合、これも teTeXを参照する。jadatexにも日本語対応版 (japanese/jadetex-ptex)がある。

とにかく TeX関係の ports が teTeX ベースになっているため、(p)texlive を手で入れると、portsからTeXまわりに依存しているものを入れようとしたとき不都合が起こる場合がある。
(例:http://d.hatena.ne.jp/isano/20080404/1207240012
teTeX→texlive関係の議論はportsのMLで話し合われているようだ。
http://groups.google.com/group/mailing.freebsd.ports/browse_thread/thread/5f8d90bcfc0f3822/

ports 側が texlive の移行に踏み切らないと、ptexliveの動作検証は進めづらいのかもしれない。

Debian stable(etch):
Debian系列はtetexからtexliveに移行している。etchは古いためtetexが残っているようだ。
ptex-base は tetex-basetexlive-base のどちらかに依存しているが、とりあえずptex-baseを入れて、あとは任せてしまうのがいい、かも?
http://packages.debian.org/ja/etch/tex/ptex-base
localeがja_JP.UTF-8で、ptexがtexliveに依存していても、texファイルの文字コードはptex(platex)を使う限り EUC などが期待される?
参考:http://d.hatena.ne.jp/n314/20080419/1208582479

Debian testing(lenny):

ptex-baseが基本であることに変わりははない。tetex-baseがtransitionalになっており、事実上 texlive-base への移行を完了しているようだ。

Ubuntu 8.04 LTS(hardy):
Debian testing(2008/5)と同じく ptex-base が基本。こちらもtexlive-baseに依存している。
日本語での作業環境を整えるため、メタパッケージの開発が進んでいる模様。

ptexメインで使うことを想定している限りtexファイルの文字コードはlocaleに関わらずEUCなどで安定ということか。(-kanji=euc|jis|sjis を使うってことで)

texファイルもUTF-8で書きたいという場合、処理方法が2種類あるようです。

ptexlive/ptetex3を使う。
UTF-8で書いたtexファイルをEUC?などに変換して処理するタイプ。日本語 ASCII pTeX をベースに tetex/texlive の一部としてptexを使うのが目標。日本語特化と見なして差し支えなし? ディストロに対するパッケージ化の進捗はあまりよろしくない、ようなので難易度は高め。動作報告を募集中みたいですよ。
本家:http://tutimura.ath.cx/ptexlive/
Debianパッケージ:http://www1.pm.tokushima-u.ac.jp/~kohda/tex/ptexlive.html

xetexなどを使う。
UTF-8の多言語文章として処理することになる。使ったことがないので分からないが、このような処理系があるようだ。 xetex自体はMacOS X用に開発されたそうだが、texlive-xetexという名前でDebian/Ubuntuにパッケージがある。texソースとしてUTF-8文章が混在するときには候補にしてもいいのかも。ただ日本語処理部分がまだ弱い? dvi関係の周辺ツールの対応状況は確認する必要あり?(ptex環境で使っていたものとは違う?)


余談:TeXの周辺アプリケーションを一括導入するパッケージの話と、TeXの処理系の話がごっちゃになっていて分かりづらい。これをすっきり理解することが『TeX利用のレディネス』のひとつなのか。敷居が高いよなあ……

おまけ:いずれはまること間違いなしの PDF絡みの話。あと学会関連のスタイルファイル。