Closed doraTeX closed 8 years ago
まあ CUI 版はそうなるだろうなという印象です。「排他的」はすなわち「GUI で透過のチエックボックスがが有効でも背景色指定はグレーアウトしない;背景色のデフォルトは白」と合致しますね。Win と Mac の完全統一はまったく意図していないのですが、GUI と CUI が乖離してほしくないので賛成です。
色指定はFF00FFみたいな書式で良いような気がします.それとredとかいくつかの名前をデフォルトで入れておきたいですね.xcolorにあるのをと思ったけど,結構多いなぁ…….
「透明も背景色の一種」という扱いだとどうでしょう.--background-color=transparentという書式を用意して,--transaparentはこれと同等.--transparent-は互換性を考慮に入れると--background-color=whiteが妥当でしょうか. GUIの方もボタンに「透明」とか書いちゃう.
色指定はFF00FFみたいな書式で良いような気がします.それとredとかいくつかの名前をデフォルトで入れておきたいですね.xcolorにあるのをと思ったけど,結構多いなぁ…….
書式は小数だとわかりにくいので16進数に賛成です。デフォルトで名前があると助かりますね。とりあえず color.sty で使えるものから始めて、需要がありそうなら後から足してもよいのではないでしょうか。
透過も背景色の一種
まだ GUI が想像ついていないのでなんともいえません… 「透明」を選んだときに JPG は背景が何色になるのかがみえたほうがよいと思うのですが、「透明または白」みたいな表示にするのは収まりが悪いし。その点からは、今の「可能なら」は気に入っています。
--background-color FF00FF
の書式に加えて,Photoshop スタイルの
--background-color "255 119 225"
のような指定もできるようにしておくと分かりやすいのではと思いました。 クオート必須になってしまうのが難点ですが。
「透明」を選んだときに JPG は背景が何色になるのかがみえたほうがよいと思うのですが、
ボタンを白くして,「透明」とボタン名をつけるとか?設定は悩みますが,カラーダイアログに「透明」っていうチェックボックスを入れるのが良いでしょうか.
しかし,透明ってのは色の種類ではない(青い透明だってある)ので,概念的に良くない気もしてきました.
カラーダイアログに「透明」っていうチェックボックスを入れるのが良いでしょうか.
透過か非透過かは(私の場合は)設定を変える頻度が高い部類に入るので、カラーダイアログに入れ込まれるとちょっと面倒になります。(そういってしまうと既に「透明が色の一つ」とは相容れないわけですが…)
透明ってのは色の種類ではない(青い透明だってある)ので,概念的に良くない気もしてきました
「透過指定の有無」と「背景色指定」が独立だと“青い透明”と思われかねないので、色ボタンをグレーアウトさせるのはやっぱり正解でしょうね(Mac 版でこの解釈を避けるにはどうすればよいのだろう…)。全ての画像が透過可能なら話は簡単でいまの Win 版の状態で良いと思うのですが、JPG のわかりにくさがネックになっています。やっぱり GUI は色指定ボタンをグレーアウトさせる今の状態で「可能なら;不可能な場合は白」と書き加えるのが簡単だと思いました。
クオート必須になってしまうのが難点ですが。
これは既に --margins
がその書式を使っているのでアリだと思います(引数 1, 2, 4 個を許容し、2, 4 ならクオート必要)。16進数 00..FF より10進数 0..255 のほうがわかりやすい人もいると思いますし、案自体には賛成です。むしろ問題は「FF00FF のように16進数なら…」「10進数の3つの番号をクオートで渡せば…」という仕様をヘルプで説明する難しさでしょうか?
むしろ「青い透明」を避けるために,ユーザに「透明は色の一つ」と見なすようにさせよう,という意図でした.これが意識されれば「青」と「透明」は同時には存在し得ない野で,「青い透明」はあり得ません. とここまで書いて,「透明」じゃなくて「透過」だったことを思い出しました.「透過」ならば概念的にも良いかも?
--transparent --background-color
なら → --transparent は無効化され,指定された色で背景塗り
というのはそういう方向かなと思ったので.
透過か非透過かは(私の場合は)設定を変える頻度が高い部類に入るので、カラーダイアログに入れ込まれるとちょっと面倒になります。
これは別件といえば別件ですが,使用頻度が高そうなのはメニューにも表示させても良いかもしれません.といっても透過くらいかもしれませんが……
クオート必須になってしまうのが難点ですが。
これは既に --margins がその書式を使っているのでアリだと思います(引数 1, 2, 4 個を許容し、2, 4 ならクオート必要)。16進数 00..FF より10進数 0..255 のほうがわかりやすい人もいると思いますし、案自体には賛成です。むしろ問題は「FF00FF のように16進数なら…」「10進数の3つの番号をクオートで渡せば…」という仕様をヘルプで説明する難しさでしょうか?
こんな感じでどうでしょうか?
--background-color COLOR : set the background color (default: white)
*COLOR format examples:
FF00FF : CSS-style HEX format
"255 0 255" : RGB integers (0..255)
むしろ「青い透明」を避けるために,ユーザに「透明は色の一つ」と見なすようにさせよう,という意図でした.これが意識されれば「青」と「透明」は同時には存在しえないので,「青い透明」はあり得ません.
青と透過は同時に存在し得ないことを意識してもらうなら、確かに透過も色の一つとみなすのがよいですね(いまちょっと、青いセロハンを青い光だけ透過するような「物理的な透明」と、青を透過色に選択して PNG アルファチャネルを指定するような「画像処理的な色透過」の両方が頭をよぎったのですが、色の一つとみなす仕様だとどちらの誤解も起きないはず)。そのうえで「よく使うものを UI で表に出す」という案との両立ができたら良さそうです。
こんな感じでどうでしょうか?
おお、分かりやすいです。あとはデフォルトの色をどのくらい用意するかでしょうか?(white, red, etc. transparent も色の一つとして含めるか?)
「透過も色の一つ」というのに従い,内部では「背景色」のみを持っていると思ってください.
この流れだとGUIの透過ボタンをOFFにするのは--transparent-と同じが自然ですが,実際には「透過にする直前の色」を復帰させるようにしています.
「透過」「背景色」を分離させるよりいい気がしているのですが,GUIがどうしても透過用にチェックボックスを用意せざるを得ない以上,完全に統合しているようには見えないのが気になってはいます.コマンドラインオプションの方は--bagkcround-color=transparentの省略形ということで良いのですが.
もし分離させるならば,内部には「背景色」と「透過フラグ」があり,
となるでしょうか.
あとはデフォルトの色をどのくらい用意するかでしょうか?
HTML色を解釈できるようだったので,それに突っ込んでみました.たぶん https://ja.wikipedia.org/wiki/%E3%82%A6%E3%82%A7%E3%83%96%E3%82%AB%E3%83%A9%E3%83%BC#X11.E3.81.AE.E8.89.B2.E5.90.8D.E7.A7.B0 あたりのが使えるのではないかと思いますが.
TeX2img for Mac Ver. 2.1.2 beta 1 を作成しました。
--background-color
を追加 --background-color COLOR : set the background color (default: white)
*COLOR format examples:
magenta : CSS-style color name
FF00FF : CSS-style HEX format
"255 0 255" : RGB integers (0..255)
CSS-style color name
の名称は,CSS に規定された141種類の名称に対応。CSS-style color name
, CSS-style HEX format
いずれも,大文字・小文字は区別しない。--background-color
と --transparent
の競合時の対応は,上記仕様に従う。--workingdir
を追加 --workingdir DIR : set the working directory (tmp|file|current) (default: tmp)
*DIR values:
tmp : Standard user temporary directory ($TMPDIR)
file : The same directory as the input file
current : Current directory
作業ディレクトリとして $TMPDIR 以外を指定できるようになった結果,作業ディレクトリのパスにスペースが含まれる可能性が生じるようになりました。その場合の対策は不十分です。
「透過も色の一つ」というのに従い,内部では「背景色」のみを持っていると思ってください.
[...]
この流れだとGUIの透過ボタンをOFFにするのは--transparent-と同じが自然ですが,実際には「透過にする直前の色」を復帰させるようにしています.
Windows 版を動かしてみました。GUI はこれでわかりやすいです。
CUI 版について、「GUIの透過ボタンをOFFにするのは…」のところが若干気になります。--transparent-
を白に固定する必要はないかなと思います。そのほうが GUI とも相性がよいです。
Mac 版 beta 2.1.2 beta 1 を試しました。CUI 版で RGB の値を指定した場合に Abort trap: 6 で落ちました。色名で指定する (red, magenta) は設計どおりになっているようです。
$ tex2img --background-color "0 127 0" source.tex out.png
2015-11-24 12:26:54.038 tex2img[870:707] +[NSColor colorWithRed:green:blue:alpha:]: unrecognized selector sent to class 0x7fff7c974c10
2015-11-24 12:26:54.039 tex2img[870:707] An uncaught exception was raised
2015-11-24 12:26:54.040 tex2img[870:707] +[NSColor colorWithRed:green:blue:alpha:]: unrecognized selector sent to class 0x7fff7c974c10
2015-11-24 12:26:54.040 tex2img[870:707] (
0 CoreFoundation 0x00007fff96952f56 __exceptionPreprocess + 198
1 libobjc.A.dylib 0x00007fff8efa2d5e objc_exception_throw + 43
2 CoreFoundation 0x00007fff969df0fe +[NSObject doesNotRecognizeSelector:] + 190
3 CoreFoundation 0x00007fff9693fe23 ___forwarding___ + 371
4 CoreFoundation 0x00007fff9693fc38 _CF_forwarding_prep_0 + 232
5 tex2img 0x0000000106624afa generateConverter + 5709
6 tex2img 0x0000000106626276 main + 38
7 tex2img 0x00000001066136dc start + 52
)
2015-11-24 12:26:54.041 tex2img[870:707] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '+[NSColor colorWithRed:green:blue:alpha:]: unrecognized selector sent to class 0x7fff7c974c10'
*** First throw call stack:
(
0 CoreFoundation 0x00007fff96952f56 __exceptionPreprocess + 198
1 libobjc.A.dylib 0x00007fff8efa2d5e objc_exception_throw + 43
2 CoreFoundation 0x00007fff969df0fe +[NSObject doesNotRecognizeSelector:] + 190
3 CoreFoundation 0x00007fff9693fe23 ___forwarding___ + 371
4 CoreFoundation 0x00007fff9693fc38 _CF_forwarding_prep_0 + 232
5 tex2img 0x0000000106624afa generateConverter + 5709
6 tex2img 0x0000000106626276 main + 38
7 tex2img 0x00000001066136dc start + 52
)
terminate called throwing an exception
Abort trap: 6
0..255 の数値指定・16進数の FF00FF の指定の両方で Abort trap: 6 で落ちます。
ご指摘ありがとうございます。修正した Ver. 2.1.2 beta 2 を用意しました。
Ver. 2.1.2 beta 2 は動くようになりました。なんだかよくわからないのですが --background-color "60 120 180"
を指定すると Settings に
Background color: #4E8DBF (R=78, G=141, B=191)
と出ています。これでよいのかどうかよくわかりません…
これでよいのかどうかよくわかりません…
よくないですね……😓 Ver. 2.1.2 beta 3 を作りました。今度こそ大丈夫では。
Ver. 2.1.2 beta 3 は大丈夫でした。古い OS への対応、ありがとうございます。色指定の種類っていろいろあるのですね。
毎度で申し訳ないのですが、微妙に作業ディレクトリ指定の UI が切れています… あと、「コンパイル後処理」の画面の「作業フォルダを開く」が「一時フォルダを開く」のほうがよいと思います。
作業フォルダを選択するチェックボックスの配置場所が「変換ツール」タブにあることで、見つけやすくてよいと思いました。確かに「コンパイル後」でないのでそのほうが合致します。
Ver. 2.1.2 beta 4 を作りました。
Ver. 2.1.2 beta 4 は問題ないようです。「作業フォルダのパスにスペースが含まれる場合」も大丈夫でした。
--transparent-で白くするのは
--no-transparent 単独なら → 白色塗り
というのとあわせたのと,あまり御利益がないかなと思ったからです.むしろ--transparent-をしたときに何色になるのか予想できないケースの方が多いかと思いました.デメリットの方が多いかと思っています.白以外を指定したいときにはおとなしく--background-colorでやってもらえば良いかと.
CUI版 Ver. 2.1.2 beta 5 を作りました。
--background-color "#FF00FF"
のように,CSS風に #
付きでも受け付けるようにしました。(この場合はシェルに解釈されるのを防ぐためクオート必須)--background-color F0F
のようなCSSの16進3桁指定も受け付けるようにしました。CSSにならい,#F0F
は #FF00FF
と解釈されます。--transparent-で白くするのは
--no-transparent 単独なら → 白色塗り
というのとあわせたのと,あまり御利益がないかなと思ったからです.
Mac 版は CUI が別なので、単にそれは「デフォルト値の白」が出てくるだけなのだと思います。だからエイリアスでデフォルト値を変えれば、むしろ見た目上 Win 版の「設定ファイルに書かれている値が使われる」に対応します。
むしろ--transparent-をしたときに何色になるのか予想できないケース
は単に「現在:ナントカ」で出て解りますので、それで困れば --load-defaults
を使えます。むしろ「設定ファイルは赤背景+透過フラグ ON」の状態で、透過だけキャンセルする方法が欲しい場合が多いと予想しました。
前の実装は「内部には背景色のみがあり,透過はその色の一つ」という扱いだったので
単に「現在:ナントカ」で出て解りますので、
では「transparent」とか出るようにしていたと思いますが,
むしろ「設定ファイルは赤背景+透過フラグ ON」の状態で、透過だけキャンセルする方法が欲しい場合が多いと予想しました。
ということは,背景色+透過フラグでの管理が良いと言うことですね.だとすると
となるでしょうか.--background-colorの現在の値がFF00FF 透過とか出るのが判断に迷いそうではあります.
Ver.2.1.2b5 を確認しました。どちらの指定も正常でした。実行直後に出てくる {0, 6}
や {1, 6}
というのはデバッグコードですね。
Win 版は前におっしゃっていた
もし分離させるならば,内部には「背景色」と「透過フラグ」があり,
になったということですね。透過のチェックボックスがある以上、完全に統合するのは難しいように思えたので、別のフラグがあるほうが逆に自然です。今度は GUI と CUI が同じになった気がします。
CUI版 Ver. 2.1.6 beta 6 を作りました。
--background-color "255 255 255"
形式の指定において,指定された値のエラーチェックが不十分でしたので,0~255 以外の値が指定されたときにエラーを表示するようにしておきました。CUI版 Ver. 2.1.6 beta 6
error: --background-color is invalid. Each RGB value must be less than 256.
これでもう大丈夫ですね!
ではそろそろリリース作業に入りましょうかね!😏
--workingdir
)は追加し,背景色指定機能(--background-color
)は追加しないことにします。Win 版の 1.6.8 をダウンロードしたのですが、背景色がなぜか全く付かなくなっているみたいです。
ありゃ,失敗しました.こっそり直しました.
なんかそれでやってみたら,epsをPS_Viewで見たらでかく表示されてしまっているようです.BoundingBoxは正しく入っているように見えるのですが……
背景色塗り復活しました。
PS_View と GSview はバウンディングボックスの外側まで描画する仕組みになっているっぽいです(BoundingBox 行を無視してクロップ前の A4 サイズを表示したかのように塗る)。ちなみに Inkscape で開いてもまた違った見え方になります(これは左下だけバウンディングボックスに合わせて右上はだだっ広く A4 サイズ分塗って表示)。ビットマップ画像にすると正しくクロップされているのは、バウンディングボックスがちゃんと描かれている証拠だと思います。
そうすると塗る範囲をきちんと取得したBoundingBoxに併せておいた方が良さそうですね.後でやっておきます.
Windows 版は「TeX → … → PDF →[必要なら塗る (pdfTeX)]→ PDF →[gs or pdfTeX]→ …」になっているのですね。どこで塗っているのかよく分かっていませんでした… この塗る作業は現状では元サイズに合わせて 0 0 x y
で塗っているので、これを BoundingBox に合わせて x1 y1 x2 y2
にすればよいわけですね。なるほど。
一応今の段階のをtex2img_generate.pdfに書いてみました.(寺田くんのと違ってきれいでなくてすみません…….)
せっかくなので「透明の青」もやってみようかと思って次のようなソースをかけてみました.
%#! pdflatex
\documentclass{article}
\begin{document}
\pdfpageresources{/ExtGState<</TRP<</ca 0.5>>>>}
\pdfliteral{q 0 0 0 rg n /TRP gs 0 0 100 100 re f Q}
aiueo
\end{document}
なんだか変です……Ghostscriptがやたら遅いし,EPSを作るとPS_Viewで開いても変です.
Ghostscriptがやたら遅いし,EPSを作るとPS_Viewで開いても変です.
gs9.16 で試してみました。確かにアウトライン化されていませんね。TikZ の shadows ライブラリを含む場合にアウトライン化に失敗すると同じ現象が起きている気がします。TikZ の shadows ライブラリは影の部分を transparent に描画しますし、この「半透明」が Ghostscript が苦手とするパターンに共通しているようです。思わぬところから gs の不具合パターンがみえてきました。
どうやら gs9.15 以降で pdfwrite にも新設された -dNoOutputFonts
を使えば、半透明でもアウトライン化できるようです。eps(2)write はとにかく半透明が苦手な模様です。gs9.15 以上かつ eps2write を使わない画像化に絞れば「半透明の背景」をサポートできそうですが、多くのスキームを修正したり場合分けが増えたりと、あまり良くないと思います。
なるほど,TikZの shadows ライブラリを含む場合など,半透明のサポートを考えると,変換経路図 の右のエリアにある「途中に eps2write を経由しているが最終出力がEPSではない場合」については,pdfcrop類似処理 + pdfwrite + NoOutputFonts のコンボにするのがよいということになるでしょうかね。
変換経路図 の右のエリアにある「途中に eps2write を経由しているが最終出力がEPSではない場合」については,pdfcrop類似処理 + pdfwrite + NoOutputFonts のコンボにするのがよいということになるでしょうかね。
「gs9.15 以上」かつ「現状のスキームでは途中に eps2write でアウトライン化」かつ「最終出力が EPS ではない」の場合に pdfwrite の -dNoOutputFonts
で処理すると、処理が格段に速くなるのは確かです。「背景色を半透明にできるように」はさておき、TikZ の shadows がアウトライン化できない事態はなんとかしたいというのであれば、この方法を使えばよいのでしょうね。しかし、また大規模改修と大規模なテストが必要な予感…
60 の議論から分岐。
「
--transparent
と--background-color
は排他で,後から指定した方が先にあった方の効果を(可能な場合)上書きする」という挙動がよいのではないかと思います。CUI版はデフォルトで
--transparent
有効の設定ですので,--transparent
単独なら → 可能なら背景透過,そうでなければ白色塗り--no-transparent
単独なら → 白色塗り--background-color <r g b>
単独なら → 指定された背景塗り--transparent --background-color <r g b>
なら →--transparent
は無効化され,指定された色で背景塗り--background-color <r g b> --transparent
なら → 可能なら背景透過,そうでなければ指定された色で背景塗りいかがでしょう,直観的でしょうか?
あと,
<r g b>
の部分の指定の書式も詰める必要があります。などの指定法が考えられます。