用語のイメージに起因する誤解 06/02
「字詰め」という用語と「文字詰め」という用語があります。
非常に似ていますが、異なるものではないかと思います。
確証はありませんが、本来異なる物だったはずだと私は思っています。
前者にはリンクを張ったとおり、日本語組版において1行を何文字分にするかを決めるための用語です。
それとは違って、後者はカーニングやトラッキングを意味する用語だと思っていたのですが……。
検索すると、両者とも区別なく、両方の意味で使われているようですね。
いずれにせよ、この「詰め」という言葉のイメージによる誤解だと思うのですが、「文字がぱらぱらするのは悪!」という風潮が高まっているようで、それなりに以前から組版の仕事をしてきた身としては受け入れがたいものがあります。
組版規則の中に、「分割禁止」および「分離禁止」というものがあります。
前者は、たとえば数字とそれに続く単位記号をひとつの意味をなすかたまりと見做し、行の上下(縦組なら左右)に泣き別れになることを禁止する規則です。
さて、文字間には分割禁止に限らず、禁則処理による延ばし処理が発生する場合が有り得ます。
後者の言葉「分離禁止」は上記の例で言えば数字と数字の間、および数字と単位記号の間に、延ばし処理によるアキ量を入れることを禁止する規則です。
このように、禁則処理とは本来、文章の意味をとりづらくするのを避けるためにあるものでした。
そのためには文字間を広げることも厭わない。
※活字や初期の電算写植は詰めるのが苦手(ほぼムリ)だったこともありますけれども。
しかし最近、禁則処理よりも見た目を重視する傾向が強まりつつあります。
曰く、「文字間がぱらぱらすると読みづらい」と。
そんなことはないでしょう。たしかに、美しくはないかもしれない。でも、決して読みづらくはない。
逆に、文字を詰めすぎて意味のとりづらい文章の方が、読んでいて疲れるはずです。
嘘だと思うなら、文字間を無闇に詰めて組んだ文章を読み返してごらんなさい。
……え? 読みやすい?
時代は変わったのかも知れません……orz

←ぽちっと押していただけると管理人が喜びます。
非常に似ていますが、異なるものではないかと思います。
確証はありませんが、本来異なる物だったはずだと私は思っています。
前者にはリンクを張ったとおり、日本語組版において1行を何文字分にするかを決めるための用語です。
それとは違って、後者はカーニングやトラッキングを意味する用語だと思っていたのですが……。
検索すると、両者とも区別なく、両方の意味で使われているようですね。
いずれにせよ、この「詰め」という言葉のイメージによる誤解だと思うのですが、「文字がぱらぱらするのは悪!」という風潮が高まっているようで、それなりに以前から組版の仕事をしてきた身としては受け入れがたいものがあります。
組版規則の中に、「分割禁止」および「分離禁止」というものがあります。
前者は、たとえば数字とそれに続く単位記号をひとつの意味をなすかたまりと見做し、行の上下(縦組なら左右)に泣き別れになることを禁止する規則です。
さて、文字間には分割禁止に限らず、禁則処理による延ばし処理が発生する場合が有り得ます。
後者の言葉「分離禁止」は上記の例で言えば数字と数字の間、および数字と単位記号の間に、延ばし処理によるアキ量を入れることを禁止する規則です。
このように、禁則処理とは本来、文章の意味をとりづらくするのを避けるためにあるものでした。
そのためには文字間を広げることも厭わない。
※活字や初期の電算写植は詰めるのが苦手(ほぼムリ)だったこともありますけれども。
しかし最近、禁則処理よりも見た目を重視する傾向が強まりつつあります。
曰く、「文字間がぱらぱらすると読みづらい」と。
そんなことはないでしょう。たしかに、美しくはないかもしれない。でも、決して読みづらくはない。
逆に、文字を詰めすぎて意味のとりづらい文章の方が、読んでいて疲れるはずです。
嘘だと思うなら、文字間を無闇に詰めて組んだ文章を読み返してごらんなさい。
……え? 読みやすい?
時代は変わったのかも知れません……orz

ぶら下がり 11/07
縦組のぶら下がりのある組版で、「強制」にすべきか「標準」にすべきかで迷った。
そこでEDIANの設定を確認したところ、InDesignで言うところの「強制」にあたる選択肢がない。
というわけで、弊社では原則として「強制」を封印することに決定。
考えてみれば、文字間を広げてまで句読点をぶら下げるのは、ちょっと変だと思う。
蛇足:
念のため。
冒頭で「縦組の」と書いたけど、横組においてはぶら下がりのある組版を行ってはならないという意味ではない。
ウチでは、滅多に横組でぶら下がりのある組版をしないだけ。

←ぽちっと押していただけると管理人が喜びます。
続きを読む »
そこでEDIANの設定を確認したところ、InDesignで言うところの「強制」にあたる選択肢がない。
というわけで、弊社では原則として「強制」を封印することに決定。
考えてみれば、文字間を広げてまで句読点をぶら下げるのは、ちょっと変だと思う。
蛇足:
念のため。
冒頭で「縦組の」と書いたけど、横組においてはぶら下がりのある組版を行ってはならないという意味ではない。
ウチでは、滅多に横組でぶら下がりのある組版をしないだけ。

続きを読む »
組版ルールについて その2 11/02
2001年発行の日本エディタースクール編「文字の組み方ルールブック ― ヨコ組編」によると、「横組の句読点は,原則としてコンマ(,)とピリオド(.)を用いる.」と書かれている。
理由として、横組においては和欧混植の機会が多く、和欧混植時に句読点の文字種が混在するのは好ましくないという趣旨の文章が、注釈欄に簡単に記載されている。
しかし近年、印刷会社に持ち込まれる文字データのほとんどは(、)と(。)で入力されている。
かくいう私もWEB上の日記などは全て(、)と(。)で入力している。
一方、2004年(平成16年)改正の「日本語文書の組版方法 JIS X 4051:2004」においては、横組の読点については明確に言及していない。
ただし、この規格書自体の本文は(,)と(。)で組まれており、例示される横組の文章も読点はすべて(,)で組まれている。
ウチでの仕事においては、基本的にはお客様からいただくデータはそのまま利用してきたが、今後は了解がとれるものについては読点をすべて(,)で統一する方向で検討中。
しかし、今や多くの商業印刷物において(、)と(。)を採用している。
「どちらが正しいの?」と聞かれると、思わず口ごもってしまう。
本来はカンマ(,)とピリオド(.)を推奨したいところだが、お客様のご希望に合わせます、というなんともグレーな答えしか用意できない自分がちょっと情けない(苦笑)
関連エントリ:組版ルールについて その1

←ぽちっと押していただけると管理人が喜びます。
理由として、横組においては和欧混植の機会が多く、和欧混植時に句読点の文字種が混在するのは好ましくないという趣旨の文章が、注釈欄に簡単に記載されている。
しかし近年、印刷会社に持ち込まれる文字データのほとんどは(、)と(。)で入力されている。
かくいう私もWEB上の日記などは全て(、)と(。)で入力している。
一方、2004年(平成16年)改正の「日本語文書の組版方法 JIS X 4051:2004」においては、横組の読点については明確に言及していない。
ただし、この規格書自体の本文は(,)と(。)で組まれており、例示される横組の文章も読点はすべて(,)で組まれている。
ウチでの仕事においては、基本的にはお客様からいただくデータはそのまま利用してきたが、今後は了解がとれるものについては読点をすべて(,)で統一する方向で検討中。
しかし、今や多くの商業印刷物において(、)と(。)を採用している。
「どちらが正しいの?」と聞かれると、思わず口ごもってしまう。
本来はカンマ(,)とピリオド(.)を推奨したいところだが、お客様のご希望に合わせます、というなんともグレーな答えしか用意できない自分がちょっと情けない(苦笑)
関連エントリ:組版ルールについて その1

組版ルールについて その1 10/12
# タイトルに「その1」をつけたのは、もしかしたら今後もこのテーマでエントリを書くかもしれないから。
手許に「JIS X 4051: 2004 日本語文書の組版方法」がある。
平成16年3月20日改正分、6700円(税別)。もちろん会社で買ってもらったモノ(笑)
この本、実はわずか200ページ程度で、巻末の附属書(もちろん附属書も本文と解釈することはできるが)や解説を除くと正味120ページ程度なのだ。
従って、当然と言うべきか、これを読んでも組版の現場では「こういう場合はどうすんのー?」という場面に遭遇することが多い。
例えば、縦組みの本文中に、前後が数字などでないにかかわらず“≠”や“≒”などの記号を使って欲しい、とクライアントから要求された場合など。
これは、冒頭で紹介した規格書の中には記載されていない。
組版ルールは、「こうしてはいけない(こうしなければならない)」ものと「こうした方がいい」ものに大別できるように思う。
この例は、後者にあたるだろう。
欧文を組む要領で、算術記号のみをマイナス90度(文字の天が右に向くように)回転させるのが良いと思われる。
少なくとも、「使ってはいけない」というルールは存在しない。

←ぽちっと押していただけると管理人が喜びます。
手許に「JIS X 4051: 2004 日本語文書の組版方法」がある。
平成16年3月20日改正分、6700円(税別)。もちろん会社で買ってもらったモノ(笑)
この本、実はわずか200ページ程度で、巻末の附属書(もちろん附属書も本文と解釈することはできるが)や解説を除くと正味120ページ程度なのだ。
従って、当然と言うべきか、これを読んでも組版の現場では「こういう場合はどうすんのー?」という場面に遭遇することが多い。
例えば、縦組みの本文中に、前後が数字などでないにかかわらず“≠”や“≒”などの記号を使って欲しい、とクライアントから要求された場合など。
これは、冒頭で紹介した規格書の中には記載されていない。
組版ルールは、「こうしてはいけない(こうしなければならない)」ものと「こうした方がいい」ものに大別できるように思う。
この例は、後者にあたるだろう。
欧文を組む要領で、算術記号のみをマイナス90度(文字の天が右に向くように)回転させるのが良いと思われる。
少なくとも、「使ってはいけない」というルールは存在しない。

ウィドウ/オーファン 気になるのはどっち? 07/24
ウィドウとは未亡人のこと。
段落の末尾数行がページの先頭にぽつんと孤立している様子を未亡人になぞらえてウィドウと言う。
オーファンとは孤児のこと。
段落の先頭数行がページの末尾にぽつんと孤立している様子を孤児になぞらえてオーファンと言う。
おそらくはお客様によるのだろうが、我が社の営業担当の中には、オーファンについてはたとえ1行だけ孤立していても気にしない人がいる。
その逆に、ウィドウについては3行くらいはみ出していると、無理矢理にでも詰めてくれ、と指示してくることがある。
しかも、特定のページのみこっそりと(苦笑)版面を増やしたり、行送りを狭めたりすることは御法度。
どうするのかと言えば、ひたすら文字間を詰めるだけ。
最終行が数文字の段落がいくつもあれば簡単だけど、1行30文字くらいある文章で、どの段落も最終行までほぼ30文字ぎっしりだったりするとどうしようもない。
そういう場合は逆に文字間をあけることによりいずれかの段落の行数を増やして、ウィドウの制限を回避する方向に持っていくべきなのだが、それはそれで気に入らないらしい。
それはもちろん、デザイン重視のカタログだったりチラシだったりすれば、様々なテクニックを駆使して【ごまかし】もするが(^^;;
文章物において、文字とは情報。可視性も大事だけど、可読性こそが大事。
極端な文字ツメは結局のところ可読性を犠牲にする……と思うのだけれども。
妥協大事(結局この文章の結論はソレかい……)

←ぽちっと押していただけると管理人が喜びます。
段落の末尾数行がページの先頭にぽつんと孤立している様子を未亡人になぞらえてウィドウと言う。
オーファンとは孤児のこと。
段落の先頭数行がページの末尾にぽつんと孤立している様子を孤児になぞらえてオーファンと言う。
おそらくはお客様によるのだろうが、我が社の営業担当の中には、オーファンについてはたとえ1行だけ孤立していても気にしない人がいる。
その逆に、ウィドウについては3行くらいはみ出していると、無理矢理にでも詰めてくれ、と指示してくることがある。
しかも、特定のページのみこっそりと(苦笑)版面を増やしたり、行送りを狭めたりすることは御法度。
どうするのかと言えば、ひたすら文字間を詰めるだけ。
最終行が数文字の段落がいくつもあれば簡単だけど、1行30文字くらいある文章で、どの段落も最終行までほぼ30文字ぎっしりだったりするとどうしようもない。
そういう場合は逆に文字間をあけることによりいずれかの段落の行数を増やして、ウィドウの制限を回避する方向に持っていくべきなのだが、それはそれで気に入らないらしい。
それはもちろん、デザイン重視のカタログだったりチラシだったりすれば、様々なテクニックを駆使して【ごまかし】もするが(^^;;
文章物において、文字とは情報。可視性も大事だけど、可読性こそが大事。
極端な文字ツメは結局のところ可読性を犠牲にする……と思うのだけれども。
妥協大事(結局この文章の結論はソレかい……)

無い物ねだりで済ませるには 06/05
なんでやねんDTP:ルビかけ処理 その後02を拝読した。
同サイトの「ルビかけ処理のなんでやねん」からいくつかのエントリに分けて続いている記事である。
管理人さん及び、質問に回答なさった方の文章は大変勉強になる。
“JIS X 4051”が絶対的なルールでないことは承知しているし、InDesignなどのソフトウェアに全ての組版ルールに対応するエンジンを積むことが不可能なことも承知している。
しかし、常にメーカーに要望していく姿勢は必要だと思う。
まだ見ぬCS3の日本語組版エンジンにどの程度手が加えられているかわからないが、おそらくCS2と大差ないものと思われる。
少なくとも、文字クラスのグループ分けをユーザーサイドでカスタマイズできるような仕組みを搭載してもらえると有難いのだが。
色々考えてみて、まとまったら要望を出すことにしようと思う。

←ぽちっと押していただけると管理人が喜びます。
同サイトの「ルビかけ処理のなんでやねん」からいくつかのエントリに分けて続いている記事である。
管理人さん及び、質問に回答なさった方の文章は大変勉強になる。
“JIS X 4051”が絶対的なルールでないことは承知しているし、InDesignなどのソフトウェアに全ての組版ルールに対応するエンジンを積むことが不可能なことも承知している。
しかし、常にメーカーに要望していく姿勢は必要だと思う。
まだ見ぬCS3の日本語組版エンジンにどの程度手が加えられているかわからないが、おそらくCS2と大差ないものと思われる。
少なくとも、文字クラスのグループ分けをユーザーサイドでカスタマイズできるような仕組みを搭載してもらえると有難いのだが。
色々考えてみて、まとまったら要望を出すことにしようと思う。















