search

texjporg / platex

pLaTeX community edition
BSD 3-Clause "New" or "Revised" License
49 stars 8 forks source link

jclasses のトンボと用紙サイズ（案） #12

Closed aminophen closed 8 years ago

aminophen commented 8 years ago

texjporg/jsclasses#4 で加えたのと類似のパッチを、jclasses にも加えようと考えています。papersize special を jclasses 自身が挿入するわけではないですが、graphicx に任せてしまう方針です。たとえば

\documentclass[a5paper,tombow]{jarticle}
\usepackage{graphicx}
\begin{document}
テスト
\end{document}

こんなソースで自動的に用紙サイズが「a5 + トンボ」に切り替わります。いまのままだと、graphicx を読み込んだ場合に「a5」になってしまって右下が途切れてしまいます。

--- jclasses.dtx.1~ Fri Jul 08 01:17:06 2016
+++ jclasses.dtx    Tue Jul 12 23:20:29 2016
@@ -10,7 +10,7 @@
 %
 % \fi
 %
-% \CheckSum{4410}
+% \CheckSum{4426}
 %% \CharacterTable
 %%  {Upper-case    \A\B\C\D\E\F\G\H\I\J\K\L\M\N\O\P\Q\R\S\T\U\V\W\X\Y\Z
 %%   Lower-case    \a\b\c\d\e\f\g\h\i\j\k\l\m\n\o\p\q\r\s\t\u\v\w\x\y\z
@@ -75,6 +75,8 @@
 %   \cs{section},\cs{subsection},\cs{subsubsection}の前後空きの伸縮幅を修正。
 %   (ありがとうございます、鈴木た＠MILNさん)}
 % \changes{v1.6}{2006/06/27}{フォントコマンドを修正。ありがとう、ymtさん。}
+% \changes{v1.7}{2016/07/12}{トンボを含めた用紙サイズを
+%   \cs{stockwidth}、\cs{stockheight}と定義}
 % \fi
 %
 % \iffalse
@@ -104,7 +106,7 @@
 %<11pt&bk>\ProvidesFile{tbk11.clo}
 %<12pt&bk>\ProvidesFile{tbk12.clo}
 %</tate>
-  [2006/06/27 v1.6
+  [2016/07/12 v1.7
 %<article|report|book> Standard pLaTeX class]
 %<10pt|11pt|12pt>  Standard pLaTeX file (size option)]
 %<*driver>
@@ -727,6 +729,29 @@
   \setlength\columnsep{10\p@}
 \fi
 \setlength\columnseprule{0\p@}
+%    \end{macrocode}
+% \end{macro}
+% \end{macro}
+%
+% \begin{macro}{\stockwidth}
+% \begin{macro}{\stockheight}
+% トンボを含めた用紙の寸法を|\stockwidth|、|\stockheight|と定義します。
+% これはmemoirクラスのマニュアルに合わせてあります。
+% |tombow|が偽のときは|\paperwidth|と|\paperheight|そのまま、
+% |tombow|が真のときは2インチ足しておきます。
+% graphicx/colorパッケージを読み込んでいて、かつsetpagesizeオプションが
+% 有効になっている場合、出力の用紙サイズが自動で設定されます。
+% \changes{v1.7}{2016/07/12}{トンボを含めた用紙サイズを
+%   \cs{stockwidth}、\cs{stockheight}と定義}
+%    \begin{macrocode}
+\newlength{\stockwidth}
+\newlength{\stockheight}
+\setlength{\stockwidth}{\paperwidth}
+\setlength{\stockheight}{\paperheight}
+\iftombow
+  \advance \stockwidth 2in
+  \advance \stockheight 2in
+\fi
 %    \end{macrocode}
 % \end{macro}
 % \end{macro}

uplatex の ujclasses も同じです。

yuw commented 8 years ago

jclassesへのこの変更には反対します． 特定の，しかも自動的にロードされるわけでもないパッケージを用いたときに起る現象への対処は，クラスファイルレベルで行うべきでないと考えます．

okumuralab commented 8 years ago

別の理由ですが，もうjclassesのほうは仕様凍結のほうがいいのではないかと思います。古い出版物の再版時にちょっとでも動作が変わるとまずいですし。

aminophen commented 8 years ago

特定の，しかも自動的にロードされるわけでもないパッケージを用いたときに起る現象への対処は，クラスファイルレベルで行うべきでないと考えます．

これはちょっと納得です。

古い出版物の再版時にちょっとでも動作が変わるとまずいですし。

古い出版物の人はそもそも TeX を更新しない（依存パッケージの仕様を含めて何も変わってはいけないので）と思っているのであまり納得しないです。

もうjclassesのほうは仕様凍結のほうがいいのではないかと思います。

たとえば jclasses は abstract 環境のインデントが変とか、見苦しい点がいくつか指摘されていますが、こういう部分の修正「だけ」をまとめたパッケージかなにかを作ることになるでしょうか。少なくともいまの jsclasses は縦組クラスがないので tarticle などは未だに使われ続けている状態です。

okumuralab commented 8 years ago

そもそもjclassesはそのままではmin10等を使うので「ちょっと」のょとっが詰まるとかいろいろ今となっては見苦しいところがありますけれど，それらはすべて凍結しないと，組版結果が変わってしまいます。 tarticleのほうも仕様変更するのではなく，tsarticle（仮称）を作っていただければありがたいです。

aminophen commented 8 years ago

仕様凍結

10 でも話題に上がっている「\underline 前後の \xkanjiskip アキ削除」がコミュニティ版 pLaTeX カーネルで取り入れた唯一の仕様変更です。これもまずかったでしょうか。あのときは（ちゃんと forum で告知していませんでしたが）、GitHub にいらっしゃた方からは異論が出ませんでしたが。

aminophen commented 8 years ago

古い出版物の人はそもそも TeX を更新しない（依存パッケージの仕様を含めて何も変わってはいけないので）と思っているのであまり納得しないです。

\underline に限るつもりはないので、なにをいおうとしているかというと

なのがダブルスタンダードな気がしている、ということです。

okumuralab commented 8 years ago

pTeXカーネルでの\xkanjiskipの挙動は今までも何度か仕様変更（バグフィックス）が行われてきたのでそのおそらく最後のステップとしてあれは価値があったと思います。たった1点で，わかりやすいことですし，周知もしやすいことだと思います。 一方，jclassesのほうは，特に要望があるわけでもないですし，今さらいじるくらいなら，そのエネルギーをtsarticle（仮称）の開発に充てたほうがいいように思いました。 たった一人の意見ですので，お気になさらないでください。

h-kitagawa commented 8 years ago

pTeX エンジンの挙動は変えても良い（例：forum:913）

ちょっと話題が発散してしまいますが，ここで． 現行の TeX Live, W32TeX では，pTeX のチェンジファイル ptex-base.ch を他のエンジン (e-pTeX, upTeX, e-upTeX) でも共用しています． そのため，pTeX ですでに実装されている機能の挙動を変更する場合，新たにチェンジファイルを起こすより，ptex-base.ch を変更するのがラクな状態になっていました．

今後，pTeX エンジンを本当に凍結するのであれば，ptex-base.ch を pTeX (, upTeX?) 用のものと e-(u)pTeX 用のものと 2 つ用意するのが望ましいと個人的には思います．

okumuralab commented 8 years ago

北川さん，ありがとうございます。 言葉足らずだったかもしれませんが，さっき書いたのはあくまでもjclassesの凍結の話で，pTeXのほうは，\xkanjiskipの改善は賛成ですし，それ以外についても今後もバグフィックスには賛成です。

aminophen commented 8 years ago

一方，jclassesのほうは，特に要望があるわけでもないですし，今さらいじるくらいなら，そのエネルギーをtsarticle（仮称）の開発に充てたほうがいいように思いました。

ということであれば了解しました。

特定の，しかも自動的にロードされるわけでもないパッケージを用いたときに起る現象への対処は，クラスファイルレベルで行うべきでないと考えます．

に同意して、本 Issue の変更はとりさげようと思います。「tsarticle（仮称）の開発」か「修正用の新パッケージ」かわかりませんが、別の方向性の TODO としてしばらく残しておきます。

okumuralab commented 8 years ago

（承前）切れてしまいましたが，その上でさらに大きな変更がカーネルにあるんでしたら，北川さんのおっしゃるようにe-拡張のほうだけに取り入れるという手はありそうですね。

kbhonda commented 8 years ago

話を最初に戻してしまいますが，そもそも「トンボ」って 実際には「現在では」どのように使われているのかご存知でしょうか？ 使われ方が明確でないと何を議論してもあんまり意味がないと思います．

yuw commented 8 years ago

実際には「現在では」どのように使われているのか

編集工程と印刷工程で変りますが，共通してあまり知られていないと思います． Adobe関連のDTP界隈でも実際の編集／印刷を知らない方々にしばしば混乱が観測されます．

aminophen commented 8 years ago

ド素人の私の認識を確認させていただきたいのですが、トンボは印刷工程での用紙ズレなどに起因する余白などが生じないように、実際に現れてほしいモノだけでなく、編集者側が意図した仕上がりのサイズを一緒に表示するもの、ということでよろしいでしょうか。「現在」と「過去」で異なるのかどうか、ということまではわかりません。

kbhonda commented 8 years ago

Adobe関連のDTP界隈でも実際の編集／印刷を知らない方々にしばしば混乱が観測されます．

どんな混乱がありますか？ 逆にこういうのが分からないのでご教示いただければ． 私の立場だとトンボとか間違えるとお客さんからクレームだわ､ 製版から問い合わせがくるわでいいことなしです．

編集・組版段階では ・用紙サイズと版面の位置の確認 ・断ち落としなどの外側の要素の「はみ出し」の確認 といったあたりで使われます． デザイン的に要素が強いものだと､見開きのトンボとかいろいろありますが､ TeX界隈に限定すれば，tombo(w)オプションのトンボで「一応」十分です． 「一応」というのは・・・組版の次の工程に関して含みがあります．

細かいこと言えば3mmではまずいケースとか､いろいろですが もう昔の話で，気にしないでいいです．

まずは，前半「編集・組版」部分での認識の摺合せです．

yuw commented 8 years ago

どんな混乱

極端なものですと，“デジタルだからどんなときでもトンボは不要”というものがありました．

kbhonda commented 8 years ago

長文です．一気にいきます(^^;

デジタルだからどんなときでもトンボは不要

うわ，これはひどい． えーと，本を分解してみればきっちりトンボの痕跡がわかります．

トンボの話ですが，組版が終わって次の工程，印刷ではなく， 面付けというのに入ります． 昔の話をするとややこしいので現在の主流な工程を念頭に置きます．

多くの場合は16ページごとですが，これを一枚の紙の両面に特定の規則で配置します． A5の場合はA2の両面で8ページx2になります． この作業を面付けといいます．

じつは実際のところ， 組版工程でトンボがついてても，面付けの段階で外すことがほとんどだと思います． トンボがあってもなくても，要は正寸の正しい位置でカットしてそれを面付けするんです． その際に重要なのは，ツメなどの裁ち落としのような 「用紙外への必要なはみ出し」をカットしない ことです．さらに実際の面付けは，製本の際の裁断も考慮して， 面付けの段階で適切なマークなどの情報をつけます

また，「ドブ」という用語があります．その裁断誤差とかを考慮して 仕上がりの外側にどれくらいのマージンを取るのか，そのマージンのことをドブといいます． pLaTeX2eのドブは3mmということになります． ものによってはこのドブが3mmではないですし， 天ドブ・地ドブとか違うケースもあります．用紙にも影響をうけるケースがあります． 極端な話，ものすごい高価な用紙に刷る場合， ドブでコストが大きく変わります．

こうやってできた8ページ両面のものを「折」と言います． 本を分解したらでてくる一束が折です． この折の背表紙側には，その本の書名や出版社名，折番号，その折内のページ番号などが 書かれています．製本段階での誤りを防ぐためのものですが，これを「背丁」といいます． 背丁にトンボの痕跡がある場合があります．

ということで，印刷屋に依存すると思いますが， 実はユーザが明示的にトンボをつける必要性はないんです． つけてもカットされます． それよりも仕上がりサイズのデータで 版面が正しく位置していることが最重要です． たぶんこのあたりが「トンボ不要論」の原因でしょうね．

ただし，裁ち落としがある場合は別です． データの作り方がまずいと裁ち落としまでカットされてしまって， ドブへの塗り足しがないものができてしまいます． これは絶対にＮＧです． うっかり正寸でPDFを作るとカットされることがあります． 実際私も数年前にやらかしたことがあって， PSで裁ち落としの塗り足ししててもDistillerがカットされたPDFを生成されていました． おそらくほかのInDesignとかのアプリでも設定次第ではないでしょうか．

そういう場合は，組版段階でトンボをつけて， そのままトンボ付きで面付けに送って，明示的にトンボのカットをしてもらいます． こうすると間違いなく裁ち落としも問題なくできます． ただし，ドブこみでくりぬく工程が追加されることになります．

この工程を自動化する方策があります． 印刷屋から 「A5トンボ付きでトンボ込み領域をA4用紙の天地左右中央に」 と言われた方がいらっしゃると思います． これは「裁ち落とし（の有無に関わらず）がカットされる」ことを防止して， 自動的に「ドブを含んでページをカット」して面付けするための要求です． こうするとリスクがものすごく減ります（経験上，この形で事故になったことはありません）．

ですので，このissueの始まりの，用紙サイズ＋天地左右1inch， いわゆる「ノビ」のサイズは規格があるわけでもないので 印刷屋目線では却って混乱を起こすと思います． トンボがあるなら 「一回り上の正寸用紙サイズの天地左右中央にトンボ込みで存在」 が一番うれしいのです．

さらにトンボがある場合に大事なことがあります． 多色刷りの場合にですが．この場合，ＣＭＹＫの四つの色の版に分かれる （色数がすくなければ分版数はへります）ます．しかし， トンボがKだけ（いまのpLaTeX2eのトンボはこれ）場合は Kの版にしかトンボがないのです． 実務上は，色があるならその色の版にもトンボがあるほうがいいです． どのタイミングでカットしたり分版するのかという話にはなりますが， すべての版の同じ位置に同じトンボがあるほうがいいのです．

そういうわけで，色付きトンボとかトンボ付きの位置調整は きっとTeXを使う印刷屋もしくは組版屋はマクロ化して持ってると思います． もしくは面付けでうまくできるように工夫をしてると思います．

ところで，面付けは簡単に試せます．興味がある方はぜひやってみてください． Ａ4の両面が白い紙を一枚準備して，長い辺で半分に， つぎも長い辺で半分，もう一回長い辺で半分にします． そうするすと1/8になります．この段階で開いているほうを右，短辺で折り目になっている方を上にします． 右開きの本みたいになってます． そこで，上の折り目を二か所きってください．奥の方をすこしだけカットしないで残します． また，二つ縦に袋とじのようになっているところがあるなので そこを上のほうをすこし残してカットします． 本のようになりますよね． 1ページ目にそうとうする部分の上の方に 「上表」とかいて，真ん中に「1」と書きます． 1ページめくって，上の方に「上裏」，真ん中に「2」と書きます． あとはちょっとめくりにくい部分もありますが，きってしまわないように注意して， 各ページに順番に3, 4, 5, 6,・・・と16までページを振ります． そうしたら，慎重に開いてください． A4が8つに区切られて，両面に表裏・上・番号がついています． これが面付けです． これにあうようにページを上下も考慮して配置すると効率的です． ドブとか裁断も考えると，どういうことになっているのかが わかると思います．

aminophen commented 8 years ago

詳しい説明ありがとうございます。「面付け」の工程は知識として持ってはいましたが、少なくとも pLaTeX クラスのトンボとは共存しなそうな印象を持っていて、意識していませんでした。

さて… pLaTeX としてはどうすればよいのでしょうか。現状では

です。これは以下の点に反しています。

実務上は，色があるならその色の版にもトンボがあるほうがいいです． どのタイミングでカットしたり分版するのかという話にはなりますが， すべての版の同じ位置に同じトンボがあるほうがいいのです．

トンボがあるなら 「一回り上の正寸用紙サイズの天地左右中央にトンボ込みで存在」 が一番うれしいのです．

色の版については今はおいておいて、サイズのほうが今回の issue です。「天地左右 1 インチ」はもう pLaTeX kernel が“歴史”的にそうしているのでしょうがないとして、今回 issue を立てた理由は

2016 年 6 月の graphics パッケージの仕様変更により、従来は存在しなかった papersize special が自動的に発行されてしまう。しかも、それは「ノビ」を知らないので、“歴史”にも“実務上”にも反するマチガッタ special を発行してしまう

からです。少なくとも「DVI に埋め込まれた special」は dvipdfmx において「-p オプション」よりも強制力を持つので、従来 special を一切使わずに -p オプションを使っていた人にとっては悪化している、と思います。もう「jclasses の tombo を使う時は graphicx に nosetpagesize オプションを付けましょう」を公式仕様にしてしまうというのならばそれでいいですが、これを今さら主張するのは無理があるのではないか、ということです。

kbhonda commented 8 years ago

すさまじく間があいてしまいました．すみません．

私の書き込みはまずは，印刷屋に入稿し， データを加工する工程を一切通すことなく，印刷製本する場合に

正直言うと，今までもそうでしたが，pLaTeXのカーネル側で対処できる事項ではなく， データを作る側がどういうことをしたいのかを理解して対処すべき部分だと思います． -pの動作がいわば改悪されたならそれはそれで仕方なく対処するしかないですよね． ＃今のdvipdfmxの作るＰＤＦのなんちゃららボックス達の仕様を理解していないので ＃実際のところどうなるかよくわかってないというのが本音で，ちょっといろいろ詰めないとまずそうです

これらのことは，印刷屋に直接入れる（データ加工なし）ような場合には， pLaTeXやLaTeXの仕様に一切関係なく，その印刷屋の設備などに依存した流儀があるので， きちんと話を詰めてから進行するのが，問題を避けるポイントだと考えます．

ノビのトンボで出しても，手間暇をかけてくれる印刷屋なら 説明すれば処置できると思います． ただそうではないケースもあるので このあたりの知識は印刷屋を使うことを考える人には すこしでも知っていてほしいのです． 人間が介在せず，ただ流すだけだと， 最悪のケース「トンボがみえてずれている本」ができますんで。。。。

なんか・・・まとまりなくてすみません

aminophen commented 8 years ago

なんだか話がかみ合っていない気がするので…

私は「印刷屋に直接入れる（データ加工なし）ような場合」を想定してまで、pLaTeX をどうこうするつもりはありませんでした。私の意図を明言できていなかった気がするので、改めて書きます。

現在の問題点

2016年6月に graphics/color の仕様が変わってトンボの挙動が困ったことになった。具体的には、TeX Live 2015 と TeX Live 2016 で

\documentclass[a5paper,tombow]{jarticle}
\usepackage{graphicx}
\usepackage{lipsum}
\begin{document}
テスト：\lipsum[1-10]
\end{document}

を platex + dvipdfmx で処理した場合に、2016 だけページの右下が切れてしまう（2016 では A5 縦になってしまうため；2015 では A4 縦のままなので、左上に寄って全体が写る）。つまり、昔書いた原稿を 2016 で処理すると、右下が切れてしまう。

対処法の案

なお、今回のトンボの議論は dvipdfmx のヤヤコシイ Box の理解は一切無関係です。

＃ よく巷でヤヤコシイと言われている話は、\includegraphics で PDF をインポートするときの話であって、いま議論しているのは PDF をエクスポートする話です。dvipdfmx がエクスポートする PDF には、今も昔も /MediaBox（＝非専門的な印刷行程でも広く用いられている、クロップされていない物理的な印刷領域の全体サイズ）しか発生しません。DVI に \special という形で「ページサイズ指定」が埋め込まれた場合、dvipdfmx はこの値を /MediaBox に採用し、もし \special がなければ常に「A4縦」の値が /MediaBox に採用されます。

munepi commented 8 years ago

案1に +1。 一般の「pLaTeX トンボユーザ」です！ 現時点で、案1 が妥当だと思います。

以下、余談です。 個人的には、物理的なトンボ（trim mark, crop mark）をわざわざ plcore.ltx のような核に無くてもよいかと思っています。つまり、物理的なトンボを提供するのは、別パッケージ（特殊なクラスファイル）であってもよいかと思っています。（もちろん、トンボが核から提供されていて、そのトンボを利用できるなら、それを利用します。） もっとも、見開きページ対応トンボ、カラートンボなどなど、欲しい機能が備わった物理的なトンボを実装すればよいだけですから。

また、最近は、POD（Publishing on Demand）で出したりすることもあって、物理的なトンボでなくて、いわゆるデジタルトンボ（PDFの各種Media boxes）のみで十分なところもあります。実際に、裁ち落とし幅が3.17mmということがあったり、物理的なトンボとデジタルトンボを両方つけたPDFを出したりしたことがありました。 デジタルトンボも必要に応じて、見開きページ対応デジタルトンボなり、なんなりと欲しい機能を実装すればよいですね。

商業印刷や特別な印刷用途（コミケ :D とか）などで、何か特別なトンボが必要であれば、必要な人がそれを実装すれば十分と思いますよ。

aminophen commented 8 years ago

ちなみに私は「pLaTeX 標準のトンボ」を使ったことが無いので、案1と案2のどちらが妥当なのか判断できる立場にありません。そこで気になっているのが「ソレをいままで使っていた方がどのような認識だったか」です。それに合わせて決定するのが妥当だと思います。

「商業印刷や特別な印刷用途（コミケ :D とか）などで、何か特別なトンボが必要」な人は、いままでもずっと pLaTeX に頼らずにそうしていたでしょう。そうでなくて、長らく pLaTeX のトンボを使っていた方々（← ここで意味するのは「忠実に pLaTeX に頼り切っていたユーザ」で、「1インチのノビをもつ虫のトンボの形のもの」をそのまま使っている場合を想定）の意見がないと決めようがない、と思っています。（おそらく、そういう方々は互換性をとるのではないかという個人的な想像が、この issue の背景にあったわけですが、想像で話をすすめるのはよくなかったと今になって反省し、改めて「pLaTeX トンボユーザ」の意見をききたいです）

munepi さんの「余談」に対して：

一般の「pLaTeX トンボユーザ」です！

「トンボが核から提供されていて、そのトンボを利用できるなら、」というのがよくわからないのですが、「虫のトンボの形をしていて、1インチのノビを持つ」を全部込みで利用するということでしょうか、それとも「虫のトンボの形」だけ流用することでしょうか？（私が気にしているのは「1インチのノビ」と「新しくなった graphpics/color」の相性の悪さなので、はっきりさせておきたいです。）

aminophen commented 8 years ago

pLaTeX カーネルのトンボと新 graphics パッケージを併用したソースを処理すると 2016 だけページの右下が切れてしまう。 つまり、2015 以前で昔書いた原稿を 2016 で処理すると、右下が切れてしまう。

この現象への対応は、pLaTeX カーネル及び標準ドキュメントクラスで提供するのは筋が悪い、という結論に至ったと思われるので、「外部パッケージを読み込むことで対処する」という方法を提供することにしました。ただし、「天地左右1inのトンボを加味して papersize special を吐く」というパッケージが私の調べた限りでは皆無でした。

そこで、最もゴールに近そうだった（かつ10年以上にわたり利用実績が見込まれる）井上浩一氏の bounddvi.sty を fork してトンボをサポートできるようにし、CTAN に出しました。

これで、困ったユーザは \usepackage{bounddvi} をソースに追加するという対策が可能です。

トンボの形がどうのとか、1in というのはどうなのかとかは、本件（＝期待ハズレな papersize special が埋め込まれてしまう件）とは全くの別問題だと考えています。