環境にないフォント

最近，フォント環境に関する話題を耳にする機会がちらほらあったので，編集現場とDTP現場やデザイン現場におけるフォントについて，書いてみようと思います。

誌面デザインをする際に，InDesingデータをデザイナーに渡してデザイン案を出してもらうというケースがあります。その際に，本文フォントがすべてゴシック体に置き換わる場合があります。

この原因は，基本的にフォントがMac環境(Windowsでも同じです)に無いと，デフォルトのフォント（小塚とかヒラギノとか）に置き換えられることによります。

しかし，よく編集現場で，「一般的なフォントしか使っていないのに，どうしてフォントが無いのだろう」という声も聞きます。

このケースの多くが，合成フォントによる影響だと想像できます。

合成フォントを設定したInDesignデータを開くと，合成フォントに利用されたフォントが１つでも無いと，その合成フォントがすべてデフォルトに置き換えられます。

例えば，「リュウミンR，新ゴR，ヒラギノ角ゴW3」を使って合成フォントを作ったとします。
最も使われる標準のフォントですが，最近ではWindowsでDTPを行っているところもあります。
しかしWindowsでは，ヒラギノが標準搭載されていないので，この合成フォントは環境に無いフォントとなり，すべてデフォルトで置き換えられてしまいます。

もちろん，標準的でないフォントを用いて合成フォントを作っていると，こうなるケースはさらに増えます。

また，同じ名前でも，モリサワのフォントではStd，Pro，Pro5，Pro6，Pro6Nなどのバージョンがあるので，これらも該当するバージョンを持っていないと，環境に無いフォントとみなされてしまいます。

ところで，最近の若い編集者は，モリサワパスポートなどの年間契約しか知らない人も多いのですが，パスポートを導入していない人も多いということを，まずは押さえておくべきでしょう。

そもそもフォントは買い切りが基本で，パスポートは比較的新しいサービスです。
モリサワの例でいうと，モリサワパスポートが開始したのは2005年からです。
それ以前は，みんな必要なフォントをMacの台数分購入していました。金額にすればかなりの額だったと思います。

フォントの歴史を見れば，OCFからCIDになり，そして2002年にOTFが発売となりました。写研などの汎用機からMacに切り替え，フォントもOCF→CIDと高い費用を捻出して買い足してきたDTP各社も，InDesign＋OTFが主流となると，再度費用を捻出してOTFをを買い揃えました。

そして2002年〜2004年にかけてOTFをMacの台数分購入したのに，いくら年間５万円で全フォント使用できるといっても日常使用するフォントは限られているわけで，滅多に使用しない多くのフォントのために，わざわざお金を毎年払うというのは理にかないません。
（感覚的には，購入済みのフォントに対して，わざわざお金を払い続けているとなるでしょう。）

しかし2005年以降，Macの台数を増やす際であれば，必要なフォントを一式購入するよりもパスポートのほうがハードルが低いので，パスポートにしようというようになってきました。
とはいえ，Macの台数が変わっていないのであれば，パスポートにする意味は皆無です。

なお，個人のデザイナーやイラストレーターさんなどは，投資としてOTFを初期から導入する人もいましたが，しばらくはOCFやCIDを使い続けている人も多々いました。

今ではOTFを持っている個人のデザイナーやイラストレーターさんも多くいますが，いまだにOCFを使用している人もいると聞きます。

以上を踏まえると，たとえば「リュウミンR，新ゴR」のみを使っているといっても，何も知らずにパスポートに入っている「リュウミンR Pro6，新ゴR Pro6」を使っており，そのデータを「リュウミンR Pro，新ゴR Pro」しか持っていないデザイナーさんに渡せば，バージョンが異なるのでデフォルトのゴシック体に置き換わってしまいます。
（もちろん，気を利かせて変換してくださる方もいらっしゃいます。）


何も知らずに現状の環境だけを学んで仕事をしていると，このようなケースに遭遇して二度手間，三度手間となってしまいます。しかし歴史を少し知っておくだけで，効率よく，そして気分よく，よりよいものが仕上がっていくと思います。

計算式用 英数字フォント

さて，久し振りの投稿です。
前回の投稿が昨年の11月21日なので，かれこれ３か月振りです。

さて，今は理科だけでなく，数学の編集もしております。
理科の場合はWordを使用した原稿が多いのですが，数学は手書きの人も多いですね。

Wordで計算式を入力するのはなかなか大変なのと，入力に気を取られて原稿を間違うリスクも考えると，手書きで書いたほうがよいというのもすごく実感しております。

とはいっても，Wordで綺麗に簡単に計算式を入力したいなという声は，数学の編集をしているとときどき耳に届きますし，私のようにパソコンで原稿を書くほうが好きなタイプにとっては，何とかして綺麗な数式を入力してやろうと，多少頑張ってしまう場合もございます。

でも，どうしたら簡単に，そして綺麗に計算式を入力できないものか。
そうだ，あんなフォントがあったら，絶対綺麗に入力できる。
とはいっても，そんなフォントはあるわけ無いしなぁ…ということで，オリジナルのフォントをデザインし，そしてフォントにしてしまいました。

以下のサイトで配布しているので，よければご利用してみてください。
「計算式用 英数字フォント」
https://sites.google.com/site/fontforword/

研究発表会

先日，ある理科関係の研究発表会に行ってきました。

理科の仕事をしているとはいえ，所詮書籍教材編集ですので，実験や観察に直に触れ合う機会は殆どありません。

そのため，どうしても知識面では文献頼りになりがちです。

その文献も，義務教育の仕事をしていると，どうしても教科書に沿うことが前提となります。

とはいえ，その教科書も，教科書会社によって微妙に表現や科学的見解に違いがありますし，小学生の教科書，中学生の教科書，高校生の教科書を見比べると，それぞれ表現の仕方や，学齢に応じたグレーゾーンなども多くあるため，いろいろと違う部分が多々あります。

それらを踏まえつつ，さらに教科書の指導書や教授資料を参考文献として教材を制作するのですが，研究会に参加すると，やはり机上の勉強だけでは限界を感じさせられます。

「教科書通りには実験はうまくいかないからこうしたほうがよい」とか，「実験がうまくいかない場合の理由を指導書にはこう書かれているが，おそらくこっちのほうが可能性が高い」とか，そういうのは実際に実験を行っている先生たちだからこそ分かることであり，実験ができない立場としては，研究会は間接的に疑似体験させてもらえる貴重な機会でもあります。

机の上ばかりで編集していると，思い込みに陥りやすくなるので，ときどき研究発表会のようなところに参加するのは，偏った知識をリセットする意味でも，とても勉強になります。

時間の取れるときは，積極的に参加したいものです。

プルーフチェック

今日はプルーフチェックについて書いてみようと思います。

今回のプルーフとは，DDCPによって出力された出力紙を指して話します。
（人や会社によっては，DTPの初校出力紙や再校出力紙のことを初校プルーフや再校プルーフというところもありますからね。）

さて，過去から現在への流れで展開していこうか，それとも現在から過去へと展開していこうか迷いますが，前者でいこうと思います。

とはいっても，私の場合は版下時代までしか遡れませんが…。


アナログの版下時代は，その名の通り，１ページ１ページごとのアナログの版下ですので，それを職人さんが面付けして，フィルムに焼き付け，そして感光紙に焼き付けた青焼きが製版さんから渡されます。

当時の版下は，文字はイメージセッタから印画紙に書き出されたものでしたが，図版は手貼りなので，図版と印画紙の間で影ができることもありました。なので，青焼きではそういう図版とそれ以外の部分との境目あたりも，慎重にチェックしました。

また，平成14年度の指導要領の改訂では，抵抗の電気用図記号が変わったりしたので，版下流用で修正したものなどは，両面テープで抵抗の電気用図記号を上から貼り直したりもしました。

もちろん，用語が変わるなどした場合は，テキストだけ印画紙に打ち出して，同じく両面テープで貼りました。

それ以外にもいっぱい細かい修正を加えたりしましたので，切り貼り修正だらけのアナログ版下をフィルムに焼き付けると，ごくたまに切り貼りした部分がめくれていたり，文字落ちしていたりと，細かいトラブルが起こりました。なので，そのようなミスが起こっていないかどうか，青焼きチェックはかなり慎重にやっていました。

また，アナログで面付けしてるので，面付けが間違っていないかどうかも，金尺で裁ち切り線を引いたり，手でちゃんと折って折状にして確認したりと，青焼きのチェックではいろいろと見ることが多かった印象です。


これが，DTPデータから直接イメージセッタでフィルムが出力できるようになると，だいぶ楽になりました。

もちろん，先の投稿で書いたように，フォントやプラグインによるトラブルは多々ありましたが，面付け間違いは少なかった印象です。
とはいっても，中綴じで…といったのにノドにドブがあったり，地袋で…といったのに天袋になっていたりと，全ページ出力し直しのトラブルはときどきありました。

それもこれも，今はプロダクションやDTP会社が作成したデータを印刷する会社がRIP処理することが多いようですが，当時はデータを制作したプロダクションやDTP会社がフィルムまで書き出してから，印刷会社にフィルムを渡すということがよくありました。
そのため，印刷会社によって仕様が異なるのに，納品先とは違う印刷会社の仕様に合わせて出力してしまったりといったトラブルがときどきありました。

もちろん，面付けや綴じなどが間違っていたら全ページ出力し直しですが，小さなミスを青焼き段階で見つけた場合は，ストリップ修正ができていたので，職人さんがその場所だけうまく修正してくれたり，フィルムを削れば対応できるようなミスであれば，自分でカッターで削り落とすなど，アナログ的な修正が可能でした。

しかし，ストリップ修正ができなくなると，１ページ単位や，折り単位でのフィルム再出力が必要になりました。こうなると，再度一からチェックのし直しなので，これまた大変でした。

そういえば，一般にフィルムには，書籍名や何折の表か裏かなどを記すと思いますが，それを入れ忘れて，全フィルムにマジックで手書きしたということもありました…。

しばらく上記のようなトラブルが続いたのはQuarkXPress3.3Jや4.1Jの時代ですが，InDesign2.0が出た頃から，InDesign2.0でのネイティブデータ入稿が始まりました。
その頃は，それこそフォントの有無でトラブルが起こりました。当時はまだ，InDeignのネイティブデータ入稿も安定していなかったためか，フォントが置き換わったり，丸付き数字が反転したりと，原因不明のトラブルが起こっていました。まだまだOTFも出始めた頃で，CIDとOTFが混在していたりと，いろいろとDTP制作会社と印刷会社との間で環境が統一されておらず，大変でした。

それこそ，印刷する会社でDTPも行っている場合はそんなトラブルも少なかったのですが，DTPを行う会社と印刷をする会社が別の場合は，事前にDTP環境のすり合わせが何かと必要不可欠でした。

しかし，いくら環境をすりあわせておいても，何故かネイティブデータ入稿ではトラブルが起こってしまいました。未だに原因はよく知りませんが，InDesingCS2以降あたりからは，ネイティブデータ入稿でもだいぶ安定してきたような印象です。（あくまで私がやってきた仕事の範囲内の話ですが…）

さて，現在はというと，私の現場では，別の投稿でも記した通り，PDF入稿がほとんどです。
フォントがエンベットされたPDF/X-4をRIP処理しますが，InDesignからPDF/X-4への出力で問題が起こっていなければ，99％ほどの確率でRIP処理でのトラブルは起こっていません。
（まれに，PDF書き出しの段階で何かしら原因不明のトラブルが起こることがあったり，１色のはずなのにどこかに４色データが隠れていたり，写真などがRGBのままだったり，印刷物の一部をスキャンして用いた部分でモアレが起こったりといったトラブルはあります。）

というわけで，ラスターデータにちゃんとラスタライズされているかというのは，かなりざっくりとチェックするだけで，たいがい問題ありません。
面付けもコンピュータで行われているので，ミスが起こったこともありません。
そのため，プルーフチェックは，かなり楽になりました。


このように，これまでどのようなトラブルが起こってきたかを知っておくと，現在のプルーフチェックではどのような観点でチェックしたらよいかというのが，はっきりと見えてきます。
ときどき，版下時代と同じようなチェックを未だにしている人もいるようですが，時代に合わせたチェックの仕方を知っておくと，作業量はだいぶ減ると思います。


あっ，そうえいば，Illustratorで透明機能が付いたIllustrator9のときは，透明機能によるトラブルもよく耳にしました。そういうことも知っておくと，何かの役に立つかもしれませんね。


まとまりのない話になりましたが，PDFでの入稿以降しか知らない若い編集者の勉強にでもなれば幸いです。

割り付けとレイアウト

業界用語の違いについて，今回も書いておこうと思う。

今回は，「割り付け」と「レイアウト」である。

私がこの業界に入ったきっかけは，印刷会社でのオペレーターアルバイトとしてである。

その当時アルバイトをしていた印刷会社では，１ページにどのようの文字を配置するかということを「割り付け」と呼び，その設定を「割り付け設定」などと呼んだ。

大学卒業後にプロダクションに入ると，ちょうど版下や写研，DTPなどが入り混じる時代であり，「割り付け」と同意で「レイアウト」という言葉がよく耳に入るようになってきた。

いまでも「均等割付」などはよく聞くし，InDesign上にも「割付」という用語は用いられていた記憶があるので，完全に消えた用語ではないが，若い編集者からはあまり聞かなくなった用語であるのは確かな気がする。

まあ，雑誌などのように，割り付けなど関係なく，見栄え良く情報を紙面に配置していくようなものが増えてくると，そもそも割り付けではなく，それはレイアウトであるので，今となってはレイアウトのほうがしっくりくる用語かもしれない。

特に若いデザイナーさんなどは，割り付けなどという感覚は持ちあわせていない方も多くいるようで，古い頭の私などがデザイン案を見たりすると，テキストが綺麗に割り付けられておらず，すごく気持ち悪い感覚を覚えたりすることもある。

いずれにしても，いまとなっては「レイアウト」のほうが主流なので，主流に流されるしかないのが現状である。

台割とプロット

印刷物を制作する上では，当たり前であるが「折り」を考える必要がある。

このことは，一般書籍とか学習教材とかのジャンルによって異なることはなく，版を用いて印刷するであれば，どんな印刷物でも同じだと思う。

さて，文芸書にしろ教材にしろ雑誌にしろ，折りを意識しなければならないのであれば，台割を検討しなければならない。

見開き構成を意識したり，折りや綴じ方によって刷り色を検討したりするのは，この台割での作業になる。

つまり，１冊の本の設計図とも言えるものが台割である。

先の投稿のオフ入の話題になるが，印刷会社によっては，カンプとともに台割も合わせて用意して欲しいというところも多々ある。

さて，15年の経験の中で，いまの会社は５年目であるが，入社して驚いたのが，台割という用語を使用していないことである。

それまでの11年でお付き合いしていた会社のほとんどが台割という表現を用いていたものを，今の会社ではプロットと呼んでる。

プロットというと，私の中では台割の前の工程である。
ざっくりと１冊の本の構成を考えて，何章立てにしようかとか，単元数はいくつにするとか，コラムを入れようかとか，内容をどうしようかとか，物語であればどんな話の展開にしようかとか，そんな１冊の本の概要を，台割に落としこむ前のたたき台となったり，物語（原稿）を書き始める前に構成をまとめたりしたものが，プロットのイメージである。

そして，そのプロットをもとに台割に落とし込んだのち，固定費や変動費なども含めて試算し，採算ライン等を検討した上で，最終の台割が完成する。

とはいっても，教材とはちがい，文芸書や単行本の類などは，プロットで概要を固めたのち，著者から上がった原稿の分量によって最終的な台割が確定することも多いかもしれない。

いずれにしても，いろいろな印刷物があることを考えると，プロットと台割は使い分けたほうがよさそうな気がするが，いまの私の仕事上では，台割のことをすべてプロットと呼んでいる。ややこしい上に，協力いただいている会社やフリーの方には，皆さんが使い慣れない用語で話を進めなければならないので，ある意味申し訳ない…。まあ，私一人で打ち合わせをする場合は，台割と呼んでいるので問題ないかもしれないが…。

ネイティブデータ入稿時代

先の投稿で，現状はPDF入稿が多くを占めていることを書いたが，ネイティブデータ入稿時代のことも，少し書いておこうと思う。

私の場合は，12年ほど前からInDesignが出るまでの数年間は，QuarkXPress3.3Jないしは4.1Jの出力トラブルの洗礼を受けた人間である。

オフ入以降の話に絞ると，QuarkXPressのデータを印刷会社に入稿して，フィルム出力，および青焼きを出してもらうのだが，ここで何度もトラブルが起こったものだ。

まずはフォント。欧文フォントは同じ名前でも別物といったものが多々あるので，必ず入稿の際には，ネイティブデータと一緒に欧文フォントも印刷会社に入れる必要がある。しかし，オペレータさんがしょっちゅう入れ忘れる。以前同じフォントを渡したことがあるから大丈夫だと思って…というパターンがほとんどだったが，印刷会社からは不安だから，毎回入れて欲しいといわれる。（これは今でもそうだが…。）

次に多かったのが，サードパーティのプラグイン。最も被害を被ったのが下線革命というプラグインだったかな。
QuarkXPress上で下線を表現するのは面倒なのでプラグインを使用するのだが，オフ入時に印刷会社に渡し忘れたり，渡したのに印刷会社のほうで反映し忘れたりで，下線が入った部分以降すべての出力がおかしくなってしまったということが，何度かあった。
そのほか，記憶上では丸付き数字とか上付きや下付き文字だったかな。QuaekXPressのプラグインはあまり知らないが，初出の丸付き数字以降がすべておかしくなったことや，初出の下付き文字以降がすべて下付き文字サイズになってしまったりと，青焼きを見て愕然としたことは数度あった。
InDesignが出てこの不安から開放されるかと思いきや，初期のころは意外とトラブルがあった。記憶が正しいかどうか分からないが，丸付き数字でトラブルが出たことがある。その影響だと思うが，PDF入稿が常となった今でも，何となくプルーフチェックのときに丸付き数字に目が行ってしまう。

他にもいろいろとトラブルは起こっているはずだが，QuaekXPressから逃れられて既に６年以上も経つので，どんなトラブルが起こっていたかはほとんど忘れてしまった。

Illustratorで作ったリンクファイルのバージョンに伴うエラーもあったようななかったような…。記憶がだいぶ曖昧だ。

とりあえず，フォントがエンベットできるPDFで入稿できるようになったことで，フォントによるトラブルはだいぶなくなり，今は幸せ。
とはいっても，PDF入稿初期の頃は，PDFにフォントがエンベットできないというトラブルが時々あり，何度もPDFを出し直したこともあった。（今でも稀にそんな話を聞くが…）

いずれにしても，当時と比べれば，現状はトラブルがかなり少なくなったので，オフ入以降の作業は大幅に減ったが，どこかが楽になれば，楽だったはずのところが大変になるというのは世の常である。

機会があればそんな話題も書いてみようと思う。