Closed doraTeX closed 8 years ago
どうやらWindows版ではベクター形式の出力でも背景塗りをする機能があるようなので
Win 版は EMF 限定です。元はといえば pdfiumdraw 最初は EMF 白塗りしかできない状態で、透過をサポートするように少し後に改良しただけです。探してみるとここですね。
Ver. 2.1.1 beta 1 を作成しました。
塗る背景色を指定するUIを考えるのは将来のバージョンで再度考えることとし,ひとまずこの Ver. 2.1.1 では,背景色は白塗り固定ということにしようと思います。
なるほど… Quartz 強い。とりあえず簡単な例では“黄色塗り”が成功しているようです。
背景塗りONでかつ和文文字を用いた場合,テキスト保持PDFおよびSVG出力において,文字情報が欠落します。
というのがよくわかっていません。こちら (Lion) では「あいうえお」で黄色塗りの PDF から「あいうえお」の文字列がコピーできました。
Ghostscript で似たようなことができないか遊んでみました(あくまで遊び)。かなり変態な方法ですが、なんとなくそれらしいものができたような気がします。ブログに載せてあります。
%!PS-Adobe-3.0
0.4 0.8 1.0 setrgbcolor
clippath fill
showpage
のようにして「一面色塗りの背景用 PostScript ファイル」を用意し、PostScript 命令を走らせて背景の上に目的の EPS ファイルを overlay するというものです。
Ver. 2.1.1 beta 1 では,余白付きEPSを出力したときに,黄色い余白を増やした上にさらにBB編集で透明な余白を増やしてしまうというバグがありましたので,修正して Ver. 2.1.1 beta 2 としました。
変換経路図もアップデート。 ますます複雑になってきました……。
こちら (Lion) では「あいうえお」で黄色塗りの PDF から「あいうえお」の文字列がコピーできました。
実験ありがとうございます。こちらでも追試してみたところ,確かに Yosemite でも大丈夫でした。 ということは,これは El Capitan の Quartz API のバグっぽいですね……。
- 塗る背景色を指定するUIを考えるのは将来のバージョンで再度考えることとし,ひとまずこの Ver. 2.1.1 では,背景色は白塗り固定ということにしようと思います。(従来の非透過ビットマップ画像と同様。)これでUI上の変化は最小限で済みます。
意外と簡単に実現できてしまいましたので,背景色選択機能も搭載しました。 「共通設定」の中に追加しました。
ちなみに、Preview.app って縦書き PDF からの文字のコピペが苦手なのですね… 縦書き複数行からコピーすると文字の順序が滅茶苦茶になります。
そのあたりは,OSのバージョンアップでどんどん改善されています。 縦書きPDFの選択や検索は,確か 10.9 Mavericks で対応したのではなかったかと思います。
こちらでも追試してみたところ,確かに Yosemite でも大丈夫でした。 ということは,これは El Capitan の Quartz API のバグっぽいですね……。
El Capitan でも,マシンを変えてみたらうまく行きました。 どうやらマシン固有の問題だったようです。お騒がせしました。
その後色々見つかったバグを一通り潰せたので,Ver. 2.1.1 / 1.11.1 としてリリースしておきました。 新機能は以下の通りです。
なお,コマンドラインから色を指定するインターフェースを設けるのが面倒ですので,CUIからは 2. の機能にアクセスする手段を用意しておりません。(白に固定になります。) 将来のバージョンで再度検討しましょう。
pdftexで速攻でやってしまうのが実装的に楽ですかね.ぱっと見背景直接描けるのはなさげ?\pdfliteralあたりで直に書けばいいんだろうか……そのうちやってみます.
pdftexで速攻でやってしまうのが実装的に楽ですかね.
ちょうど pdfTeX での実験が終わったところでした!→ブログ
なるほど,やはり pdfTeX は偉大ですね……!
何となくやってみました. https://onedrive.live.com/redir?resid=4FABCB4EC4FA1E70!16825&authkey=!ANYoMX5Yq7PLXU4&ithint=folder%2cemf
UI作っていないので全てを無視して真っ青固定です.こんな感じのソースを作ってみています.見ればわかる通り余計に塗っていますが……(割り算面倒)
\def\targetpdffilename{input.pdf}\relax
\def\colorrgb{0 0 1}\relax
\pdfoutput=1\relax
\def\space{ }\relax
\newdimen\zero \zero=0pt\relax
\begingroup\catcode`P = 12\relax\catcode`T = 12\relax
\lowercase{\def\x{\def\rempt##1.##2PT{##1\ifnum##2>\zero.##2\fi}}}\relax
\expandafter\endgroup\x
\def\strippt{\expandafter\rempt\the}\relax
\newcount\totalpage\newcount\pagecount
\pdfhorigin=0bp\relax
\pdfvorigin=0bp\relax
\pdfximage{\targetpdffilename}\relax
\totalpage=\pdflastximagepages
\advance\totalpage by 1\relax
\pagecount=1\relax
\loop\ifnum\pagecount<\totalpage
\pdfximage page \pagecount mediabox{\targetpdffilename}\relax
\setbox0=\hbox{\pdfrefximage\pdflastximage}\relax
\setbox1=\hbox{\pdfliteral{q \colorrgb \space rg 0 0 \strippt\wd0 \space \strippt\ht0 \space re f Q}\box0}\relax
\pdfpageheight=\ht0\relax
\pdfpagewidth=\wd0\relax
\shipout\box1\relax
\advance\pagecount by 1\relax
\repeat
\bye
Ver. 2.1.1 / 1.11.1 としてリリースしておきました。
ありがとうございます。UI もわかりやすいですし、意図どおりに塗れているようです。
見ればわかる通り余計に塗っていますが
まだ Win 版は動かしていませんが、ソースを見る限り pt 単位になっている分だけ余分という意味でしょうか? たいして気にならなかったのと、足りないよりは安心なのでこのままでよいと思います。
意外と簡単に実現できてしまいましたので,背景色選択機能も搭載しました。
背景色の選択ボタンと「透過かどうか」のチェックボックス,近い方が良いかなぁと思うのですがどうですか?
とりあえずUIもつけました.
「透過の指定がされていなかったらば背景色を塗る」,としています.(つまりJPEGで背景色青の指定の場合,透過指定がされていれば白,そうでなければ青で塗る.)設定画面はこんな感じ.上述の指定を意識させるために「透過」にチェックが入っているときはボタンが無効化されます.(ただ手元の環境では無効化された感じがよくわからない…….)
遅くなりましたが、Windows 版を動かしてみました。背景色塗りは A4 サイズ丸ごと塗っているっぽいですが、先述のとおり大は小を兼ねるので全然気にならないです。
ただ手元の環境では無効化された感じがよくわからない…….
確かに比べてもあまりわからないですが、これで十分だと思います。透過できない画像形式のほうがもはや少数派なので、「可能なら」でスッキリさせて正解だと思いました。なので、「透過処理を共通設定に入れてあげて背景色指定と近づける」は分かりやすくて良いと思います。
そして、作業ディレクトリ指定の UI に今日初めて気づきました… CUI 版も既にあったのか…
TEXINPUTS
にカレントディレクトリを加えても効果は限定的だったことを考えると、選択肢があることは嬉しいかもしれません。どうもありがとうございます。
/workingdir=<VAL> 作業ディレクトリ(tmp/file)(現在:tmp)
ああ,忘れていました.フォルダのは1.6.7にはついていないです.実は自分でデバッグ用にほしかった(一時ファイルをTMPから探し出すのが辛いので)のですが,一般的にあってもよいかなとつけてみました.一瞬/workingdir=currentを実装したのでbool形式ではないスイッチになっています.(特にGUIの場合「カレントフォルダ」の認識は辛いのでやめました.)
一瞬/workingdir=currentを実装したのでbool形式ではないスイッチになっています.(特にGUIの場合「カレントフォルダ」の認識は辛いのでやめました.)
普通に current もあってよいのではないでしょうか? GUI 版にはカレントという概念が存在しないので「tmp/file」でよいですが、CUI では tmp/file/current が独立な気がします。GUI と CUI で選択肢が同じである必要はないというつもりです(実際 kanji=no も GUI と CUI で違いますし)。対応付けは「CUI の tmp ⇔ GUI の tmp」「CUI の file ⇔ GUI の file」「CUI の current ⇒ GUI の file」で良いと思います。
ではつけておきましょう.
GUI 版にはカレントという概念が存在しない
カレントディレクトリは存在するので,そっちで処理した方が一貫性はとれますね.ショートカットだと指定できたりもするので,それを活用する,という使い方もあるかもしれません.
しかしそうなると「exeのあるフォルダ」とか「フォルダが指定できる」とかいろいろとあり得てしまいますね……まぁ増やしても仕方ないか.
将来的に CUI で背景色塗りを指定できるようにする場合(Mac 版は計画がありそうな気がするので)のことをちょっと考えてみました。たとえば背景色指定を
--background-color <r g b>
などで実装した場合、--[no-]transparent
との兼ね合い(順序も含めて)がどうあるべきかというところが論点になると思います。
--transparent
単独なら?--background-color <r g b>
単独なら?--transparent --background-color <r g b>
なら?--background-color <r g b> --transparent
なら?ということも意見が分かれると思います。#62 でも挙がっていますが、CUI とあまりにもかけ離れないように GUI 検討の段階で UI 整理の方向性を決めたほうがよいのかもしれませんね。
いまの Windows 版の「可能なら」だと、可能でなかった場合の背景色は何なのかわかりにくい気もしてきたので、ボタンをグレーアウトさせないほうがよかったのかもしれないです。
可能でなかった場合の背景色は何なのかわかりにくい
Win 版ですが、「色ボタンを無効化しない」のほかに「可能なら;不可能な場合は白」と書いてしまうのもアリですね。
どうやらWindows版ではベクター形式の出力でも背景塗りをする機能があるようなので,Mac版でも検討しよう。
メリット
PowerPoint や KeyNote に数式画像を貼り込む際,ベクター形式だと背景が透過になる。 だが,スライドの背景色によっては,数式画像の背景が透明だと見づらい場合がある。 「背景を白くしたいがためにビットマップ形式を用いる」というのは馬鹿げている。 ベクター形式でも背景を白塗り(あるいは指定した別の色による塗り)できる機能があると便利だろう。
実装法のアイデア
検討課題