萩さん日記
デジタル印刷と電子ドキュメントの新潮流
アウトラインフォントの歴史的背景

PostScript では、アウトラインフォントが採用(一部フォント、例えば Courier は、ストローク フォント)されたが、アウトラインフォントとは文字の輪郭情報をデータとして持つフォントのことだ。PostScript で最も多く用いられている Type 1 フォントは、この輪郭の表現に3次ベジェ曲線を使用している。 Type 1 フォントには暗号化が於かされており、当初この暗号化アルゴリズムを含め Type 1 フォント仕様が非公開であった為、MacOS や Windows 上でアウトラインフォントの対応が必用であった Apple 社と Microsoft 社は、共同で2次スプライン曲線を用いた TrueType 形式のフォントを開発した。やはり、OS で標準的にサポート (MacOS の Osaka や Windows の MS 明朝、MS ゴシック等)された意義は大きく、多くの TrueType 形式のフォントが市場に投入された。一方、Adobe 社は、Adobe Type Manager (ATM) という OS 上で Type 1 フォントをラスタライズするラスタライザを開発し、市場に投入した。そもそも、Type 1 形式をオープンな形式にしていたら、TrueType 形式は開発されなかったかもしれない。アウトラインフォントの実質的な標準が TrueType に移行する中、Adobe 社は Type 1 の仕様を公開しました。最近の OS では、標準で Type 1 ラスタライザを搭載しており、ATM をインストールする必要はなくなりました。



TrueType 形式は、初期の PostScript でサポートされていなかったこともあり、商業印刷のプロフェッショナル用途では Type 1 形式のフォントが主流となりました。日本語フォントはその字形の多さ故に、開発には莫大な開発投資が必要でした。そこで、多くの Type 1 日本語プリンタフォントは暗号化され、コピープロテクトが於かされておりました。コピープロテクトは、大変巧妙に作られており、印刷デバイス毎のユニークとなる要素を巧みに使い Key ファイルを構築し、そのプリンタでのみ動作するフォントとしてインストールされました。また 1200 DPI を超える高解像度用フォントとそれ以下の低解像度用フォントが異なる価格体系で販売されておりました。



当初の PostScript では、Type 1 と Type 3 というフォント形式がサポートされておりました。一番単純な Type 3 形式では、文字のグリフを記述するのに通常の PostScript のオペレータ (moveto や lineto 等) が使用できます。一方、Type 1 形式では、"Type 1 Charstring"と呼ばれる専用の輪郭記述用の専用言語で文字グリフを記述します。Type 1 Charstring は、バイナリ形式 (例えば、moveto は 21) であり、PostScript 言語に比較して、たいへん限られた機能しか持っておりませんが、文字グリフを少ない容量で表現することができます。またヒント情報を持つこともできます。Type 3 フォント形式は、ビットマップフォントをプリンタで印刷するときによく用いられております。また、Type 1 フォントの Type 1 Charastring 部分は、通常暗号化されてますが、暗号化アルゴリズム(標準)は公開されており、PostScript では CCRun オペレータにより複合化されます。しかしながら、公開されていない暗号化アルゴリズムも依然存在し、いくつかの日本語フォントは非公開の暗号化アルゴリズムを使用して暗号化されております。この暗号化されたグリフデータは、PostScript 上では eCCRun オペレータ(アルゴリズム非公開)を用いて複合化されます。更に輪郭表記以外の部分も CCRun と同じアルゴリズム(ただし暗号化キーは異なる)で暗号化することもあり、PostScript の eexec というオペレータを用いて複合化されます。



PostScript (Level 1) で採用された Type 3 と Type 1 フォント形式は、どちらも1フォント当り最大 256 文字にまでしか対応できませんでした。これでは、日本語に対応できません。そこで考案されたのが Type 0 フォントです。Type 0 フォントは複合フォント(コンポジットフォント)とも呼ばれ、複数のフォントを階層的に重ね、日本語の2バイト文字コードに対応しました。 Type 0 フォントは、更に他の Type 0 フォントを組み込むことも可能であり、入れ子の深さは最大5レベルまで対応することが可能です。階層構造の最上位にあるフォント辞書をルートフォントと呼び、それに従属するその他のフォントをディッセンダフォントと呼んでいます。PostScript (Level 1) では、この Type 0 形式を拡張機能としてサポートしておりましたが、その後 PostScript Level 2 言語仕様に取り込まれました。複合フォントは、 FMapType を通して設定される7種類のマッピング アルゴリズムに対応しており、JIS、シフトJIS、EUC などの日本語文字コード体系に柔軟に対応できます。特にシフトJIS の様に1バイト構成部分(ANK 部分)と2バイト構成部分(漢字等の部分)が1バイト目のコードにより自動的に切り替わるものがあり、これに対応するため SubsBector マッピングが考案されました。



その後、Type 3, Type 1, Type 0 以外に、Type 2, Type 4, Type 5, Type 32, Type 42 等のフォント形式が追加されました。Type 2 形式は、Compact Font Fomat (CFF) で使用されるフォント形式であり、より小さなサイズ、より良いレンダリング品質とパフォーマンスが得られます。Type 4 形式は、日本語コンポジットフォントのベースフォント用に開発されました。Type 4 形式は、Type 1 形式と異なり、Type 1 Charstring をインタプリターの VM 上ではなく、プリンターのファイルシステム(ハードディスクや ROM カートリッジ)上に格納します。これにより、印刷する文字の Type 1 Charstring だけがファイルシステムから読み込むことができるので、VM の消費を抑えることが可能となります。また最新の PostScript プリンタは TrueType のラスタライザを搭載しており、TrueType フォントのグリフデータをそのまま格納することが可能です。このフォント形式を Type 42 と呼んでおります。



この様に、初期の PostScript の2バイト文字の対応は、もともと1バイトにしか対応していないフォント形式をむりやり2バイト文字が扱えるように拡張したものでした。一つのフォントを様々な文字コード体系(JIS, EUC, シフトJIS) でサポートするのに、それぞれ異なるディッセンダフォントで構成される複合フォントを作成する必要があり、フォントの容量は大変大きいものでした。また1つの文字グリフデータにアクセスするのに2つ以上のフォント辞書にアクセスする必要があり、処理速度の問題がありました。この問題にアドレスしたのが Character IDentifier (CID) フォントです。 これに対して従来の日本語フォントは Original Composit Format (OCF) と呼ばれます。



CID フォントは、CID フォントファイルと、各フォント共通で使える CMap ファイルで構成されます。CID フォントファイルには、文字グリフデータ(Type 1 Charstring 形式)が CID (グリフ形式毎に固有値を持つ)をキーにして格納された文字グリフデザインファイルです。これにより、フォントベンダは、Adobe 社が規定した文字グリフセットの CID フォントファイルのみを開発すれば、すべてのエンコーディングに対応できるようになりました。これにより、フォントファイルの容量を低く抑えることが可能になりました



Adobe 社は、グリフセットを次第に拡張し、今日までに7種類のグリフセットの規格を世に送り出しました。そして、それらは、Adobe-Japan1-0 ~ 6 の名称で呼ばれております。最新の Adobe-Japan1-6 には 23,058 文字字形が収録されており、0-23057 の CID 番号が連番で割り振られております。CID フォントのグリフセットは、上位互換性があり、文字グリフが割り振られている限り、バージョンによらず同じ文字字形となります。



※ Adobe-Japan1 シリーズの CID 番号と概要



Adobe-Japan1-0:0-8283:OCFフォント
Adobe-Japan1-1:0-8358:漢字Talk7.1 対応等
Adobe-Japan1-2:0-8719:CIDフォント
Adobe-Japan1-3:0-9353:OpenType Std 書体
Adobe-Japan1-4:0-15443:OpenType Pro 書体
Adobe-Japan1-5:0-20316:JIS X 0213:2000 対応
Adobe-Japan1-6:0-23057:JIS X 0213:2004 対応



最近では、OpenType フォント (OTF) という新しいフォント形式が開発されました。この OpenType フォントは、Adobe 社と Microsoft 社が共同開発したものです (一部は Adobe, Microsoft, Apple 社の3社の共同開発)。OpenType フォントは、TrueType フォントの拡張形式であり、PostScript フォントデータへの対応が追加されたものです。したがって、OpenType 形式には、グリフデザインが TrueType アウトライン形式のものと、CFF (PostScript) アウトライン形式のものの両方が存在します。この OpenType フォントの最大の特徴は、ユニコード対応とWindows と MacOS のマルチプラットフォーム対応です。さらに解像度制限がなくなるとともに、ダイナミックダウンロード(プリンターやイメージセッター側に高価なプリンタフォントをインストールすることなく直接出力できること)が可能となり、多くの異体字に対応でき、さらに GSUB (Glyph Substitution) と呼ばれる字形切り替え用のテーブルを持っています。

Windows XP の正規 OEM ライセンス提供、2008 年 1 月 31 日で終了

マイクロソフトは 8 月 22 日、Windows XP の正規 OEM ライセンスの提供を 2008 年 1 月 31 日をもって終了し、PC メーカー各社からの Windows XP 搭載 PC の生産は、同日をもって終了することとなると発表した。 尚、マイクロソフト ボリューム ライセンスによる提供は、Windows Vista の企業向けライセンス販売を開始した 2006 年 11 月に既に終了しています。これにより、Windows Vista への移行が加速するものと思われます。



詳細は、以下の Microsoft Web サイトを参照してください。



http://www.microsoft.com/japan/presspass/detail.aspx?newsid=3165

ハーフトーンスクリーニング

PostScript のハーフトーンスクリーンは、スクリーン線数、角度、スポット関数で定義する場合と、ディバイス空間で直接マッピングできる「 Threshold array(しきい値配列)」を用いる場合の2通りがある。Threshold array には、様々なタイプが用意されている。ここでは、一番単純な HalftoneType が 3 の Threshold array を用いた、非常に面白いハーフトーンスクリーンを一つの例として紹介します。



以下の ハーフトーン辞書の例では、32x32 の Threshold array を使用している。この配列では、内部にあるハートマークの淵に先ずドットを配置し、その後ハートの内側をバランスよくドットで埋め、その後ハートマークの外側を周辺スクリーンセルとの関係を配慮しながらバランス良く、独自の FM スクリーニングのアルゴリズムで配置していく、その際ハートマークの際は、出来るだけ白く残すようにし、シャドー部分でもハートマークが浮き出るようにデザインされている。このハーフトーン辞書はプログラム的に作成されたものであるが、ハートマークだけでなく複雑な形状をしたものにも対応できるようにプログラムされている。



%%
%%     Halftone dictonary
%%  Copyright (c) 2007 by Y. Hagi.
%%     All rights reserved.
%%



/HeartHalftone <<
/HalftoneType 3
/HalftoneName /HeartHalftone
/Width 32
/Height 32
/Thresholds
<
19 83 64 4b 8e 57 6b 87 36 5a 81 48 6b 13 83 19 5d 82 16 44 7e 4d 84 3c 8a 25 8c 04 85 58 0c 91
93 31 92 03 7a 1c 8b 28 73 8a 02 86 33 80 2f 6a 7d 35 5a 85 29 88 11 67 56 77 43 90 47 92 6d 35
7c 53 68 89 3a 90 45 8e 17 40 7d 27 74 3e 70 55 0f 65 75 06 7a 38 70 8b 30 8f 6a 15 7f 21 8c 5e
10 94 1e 92 71 0e 82 54 67 87 4f 78 11 63 4c 22 45 2b 54 69 1f 81 50 09 83 1c 5c 91 51 93 40 94
8b 47 85 3d 5f 8f 30 8b 0a 75 1d 61 56 3a 05 fe ee 0b 3b 4a 6e 41 62 87 3e 8d 7b 2d 88 13 77 28
59 93 09 91 2c 79 63 4a 7f 2e 69 49 2c 1b f0 d7 de f5 1a 32 59 12 76 24 71 5a 01 8f 39 92 61 93
2f 6a 7c 50 8d 13 86 23 6d 5b 42 35 08 f9 d0 e4 c3 d5 fa 02 2d 52 5e 46 80 34 89 6c 55 80 06 86
91 23 8f 1a 61 81 42 72 18 53 26 14 ed d9 be ca e9 c7 db ec 18 3d 20 68 0f 79 4e 17 8d 25 90 3c
83 49 6f 89 37 74 08 5e 4d 38 00 fd e0 c4 f4 b4 b8 e1 ba cf fd 0c 37 4c 5f 1d 6f 84 45 64 7a 53
1c 8c 03 55 7e 20 66 46 29 0d f1 db bc cd b0 d1 ad c0 f2 c2 df f0 04 27 41 66 2b 74 30 8a 0e 8e
77 5c 84 33 6c 59 3f 31 16 fa d3 c2 eb ac e7 a4 fb a6 b1 d3 bc d8 f9 14 33 48 5d 0a 7e 57 70 35
88 15 43 73 12 4f 27 05 ef cb e5 b5 c8 b8 a7 d6 a9 e3 c9 aa e8 c5 d1 ee 07 29 4f 6b 42 21 86 4e
28 69 7b 2a 5b 39 10 ff ce dd b1 d7 a1 f7 9d c5 9f b6 a1 f7 af e1 bf dc ff 10 3b 17 62 78 06 7f
82 4b 0b 65 48 1d f4 d6 e8 ba f5 a4 a9 cf b2 99 ef 9b cc 9e b9 a7 f3 bb d7 eb 22 4b 5b 31 6e 3e
19 76 60 3d 30 02 e2 bf c5 ab b6 e3 c1 99 a5 e0 97 da a3 ad dd c6 ab e4 c4 f6 01 2e 3f 67 11 7d
45 6c 26 51 1f f8 c9 ec af da a0 9c ad f1 96 bc a0 b3 98 ec 9b a5 d2 b3 cb d5 e7 1b 51 24 72 54
7a 0f 5a 36 08 e6 d4 b3 cf a7 fc c8 97 9e d2 95 ff 95 d5 97 b4 fb a1 ae ef c1 fc 09 34 58 63 2c
3c 66 44 1b fe ce b8 f2 a3 c3 9a a2 de b7 94 aa 9a bf 9e a9 c9 9c be dc aa b7 d1 e9 1f 47 03 75
15 57 32 0c e0 bd d9 ac dd 9d e9 b1 96 9c ea ca 94 e5 95 f2 97 e6 9f a6 c7 e2 bd f8 0d 37 4d 68
71 4a 24 f4 c7 ed b2 a5 bf a8 bb 98 f5 bd 95 ad a5 98 d0 9b af 99 cd f6 a3 ae d8 c8 f2 18 5e 21
61 39 05 e4 d2 af ca f9 a1 ee 9c cc a4 98 d8 96 f8 ba 96 b5 eb c2 9d b1 ba ed b4 cf e3 28 52 40
13 56 2b fb c2 df b8 a6 c5 9f d3 9a e1 b5 9b c7 99 a2 e1 a0 9a a6 de a4 d4 ab df c0 fe 07 3a 6e
6a 43 0f dc ea b4 d5 ac e5 b3 aa fc 9e a3 ef 9f da b0 9d cc fd bb a0 f0 a8 c3 b7 ea db 2b 59 1d
2f 50 20 f6 cd c0 f1 bc a8 d8 a2 c6 b0 dd ab c0 a7 f4 c4 a8 a2 d7 ac c8 b2 fa d3 ca f7 16 46 74
66 5f 3d 02 e6 da b7 c9 f8 ae e8 b6 a9 cb b9 e3 d4 bd ae e8 b9 aa e4 b0 d9 bb cd e7 01 36 5d 0b
79 19 53 26 ff d0 eb c4 b9 cc b2 d6 ed c3 fc 01 0e ec d0 b6 ce f6 b5 c1 ee c6 de f3 23 4c 6d 42
31 71 5b 34 08 f5 e2 d4 df c1 f3 be ce e7 17 23 2c 14 fa d9 c6 be e0 cb d6 e5 fd 0e 40 64 1a 7c
84 11 48 69 41 22 0d fb e9 db d1 e2 f7 06 33 47 3b 27 04 f3 e6 dc d2 ea f9 0a 26 34 57 2d 80 4e
25 75 81 16 62 4d 32 1e 04 f0 fe 0c 20 2e 52 10 58 43 32 1e 0b ff f1 03 1f 3e 52 5c 6b 7b 05 6f
8a 60 38 78 2e 6e 56 46 39 2a 15 37 44 5c 3c 62 1c 4e 5f 38 49 14 2a 36 4b 65 18 76 12 49 87 3b
55 07 88 50 7f 12 76 5d 67 4c 60 51 65 09 6f 25 72 68 07 54 64 3f 60 55 6c 2f 82 3a 89 63 1e 8d
73 90 29 8c 24 85 3f 0a 7c 1a 70 21 79 58 41 7b 4a 2d 77 6d 22 73 1b 78 0d 7d 4f 72 2a 8e 7e 44
>
/TransferFunction {}
>> /Halftone defineresource pop



以下は、上記ハーフトーン辞書を用いて、1200 DPI の 1-bit で RIP した場合の例です。



一番左は、オリジナルのグレイ画像です。その右側3つはRIP後のイメージ画像です。拡大していくと、パートマークが見えてきます。



重要:本スクリーニングは、こんなことも出来る例として紹介させていたきました。このスクリーニングの使用にあたりましては、如何なる動作保障も行いません。また、本スクリーニングを使用した場合に発生する如何なる障害および事故等についても、一切の責任を負いませんのでご注意ください。



Original KaoMe Me2x



















スクリーニングの話

様々なページ記述言語(PDL) が存在するが、中間調を表現するための技術に替わりはない。一部の連続調 (コントーン)対応プリンタ(昇華熱転写式プリンタ、銀塩写真式プリンタ等)を除き、印刷デバイスがサポートするインク(含むトナー;便宜上以下インクとして総称)色(通常、シアン、マゼンタ、イエロー、ブラック)は、それ自身で階調を表現できないので、スクリーニングと呼ばれる面積階調方式で階調を表現している。スクリーニングの方式は、大別して AM スクリーニング方式、FM スクリーニング方式、そして AM と FM の両方の特性を兼ね備えたハイブリッド スクリーニング方式があります。



AM スクリーニングは、網点とよばれる小さなドットの大きさで階調を表現します。この小さなドットは規則的に並べられ、1 インチ当たりのドットの数をスクリーン線数と呼び、ドット並びの角度をスクリーン角度と呼びます。紙にインクを重ねて印刷する場合、インクが重なった部分は重ならない部分と色が異なります。そのために、もし複数の版で同じスクリーン角度を使用した場合、印刷時に版ズレがほんのわずかでも発生すると、重なり具合の違いによって、印刷結果はまったく異なったものとなってしまいます。また、同じスクリーン角度を複数の版で使用した場合、ほんのわずかな版の傾きにより、モアレ周波数の低いモアレを引き起こします。この問題を回避するために通常各版には異なる角度を設定します。しかしながら角度差を設けることにより、モアレ(干渉縞)が発生するようになります。このモアレ周波数を出来るだけ高くし、人間の目に認識されないレベルにする為に、出来るだけ各版の角度差を大きく設定する必用があります。通常、CMYK の中で人間が最も認識し易い色であるブラックのスクリーン角度を 45°に設定します。これは、この角度が人間の目にとって、最もパターン認識し難いのが理由です。そして、CMYK の中で人間が最も認識しずらい色であるイエローを、人間の目にとって一番鈍感である 0°に設定します。 そして、通常シアンとマゼンタのスクリーン角度をそれぞれ 15°と 75°に設定します。尚、各版のスクリーン角度は、印刷されるものの特質(白人の肌色が多く、黒い部分が少ない印刷物等)により入れ替えることがあります。角度差 30°と45°の部分で、ロゼットとよばれる、花の様な模様が現れます。ロゼットには、センタードットのロゼットとセンタークリアーのロゼットがあります。一つの版を編点距離の半分だけずらすことによりこれらロゼット形状は入れ替わります。印刷ではセンタークリアのロゼットがより好ましいとされておりますが、より大切なのは同じロゼットの形状が統一的に現れる事です。



RT スクリーニングにおける網点は、ハーフトーンセル(網点セル)で構成されます。例えば、16 x 16 のハーフトーンセルの場合、257 (16 x 16 + 1)通りの階調表現が可能となり、2400 DPI でスクリーン角度が 0°の場合のスクリーン線数(1インチ当りのハーフトーンセルの個数)は、150 線 (2400/16) となります。勿論、スクリーン角度が 0°以外の場合は、事情が異なります。133 線 15°の RT スクリーンを指定した場合、現実的に設定可能なスクリーン線数と角度は、135.44 線、16.3895°となります。



RT スクリーニングの悩ましい点は、ハーフトーンセルのマトリクス サイズを大きくすると人間の目に網点が見えてくる。逆に小さくすると階調数が少なくなり、選択できるスクリーン角度も理想的な角度が取りずらくなります。スクリーン角度が理想的な角度から外れてくると、均一なロゼットパターンが得られず、モアレ(干渉縞)が発生します。



より理想的なスクリーン角度を得るために、スーパーセルが考案されました。1 つのスーパーセル内部に複数の異なる形状のハーフトーンセルを持つ巨大セルを構築することにより、より理想に近いスクリーン角度を得ています。セルサイズは巨大にはなりますが、その中の網点のサイズは十分小さくできます。例えば、 133.33 線 15 °のハーフトーンセルを 9 個 (3 x 3) 持つスーパーセルを要求した場合、133.701 線 15.0685 °のスクリーニングを実現できます。これは、前に説明した RT スクリーニングにおける線数、角度に比較し、より理想に近い角度です。実際にはもっと巨大なスーパーセルを構成するので、さらに理想の角度に近いスクリーニングを実現できます。



しかしながら、どんなに理想に近いスクリーン角度を達成できたとしても、イエロー(0°)とシアン(15°)そしてイエロー(0°)とマジェンダ(75°)の版のスクリーン角度の差である 15°のモアレは確実に発生します。この目障りなモアレを解消するために、イエロー線数のみを変えることもあります。モアレの問題を軽減するには、少なくともそれぞれの版の間で 30°以上のスクリーン周波数の差があることが理想です。しかしながら、3 版ならば、30°x 3 = 90°で実現が可能ですが、4 (CMYK) 版以上の場合には、30°の角度を得ることは不可能です。



網点の形状は、スポット関数を入れ替えることにより、単純円形、幾何学形状混成、ダイアモンド型、反転円形、反転楕円形、菱形等、様々な網点の形状を選択できます。単純円形ドットは、中間調のドットゲインを抑える上で好ましい形状ではありますが、シャドー部分の表現力が乏しく、また 78.5% の階調で、隣接する 4 方向の網点が同時に接触し、トーンジャンプを引き起こしてしまいます。ここでは説明しませんが、それぞれの網点形状には一長一短があり、印刷するものの特質に合わせて、最適な網点形状を選択する必要があります。



AM スクリーニングは、フラットなトーンでスムーズな中間調のトーンが得られる。一方、ディテイルの再現性に難があり、モアレやトーン ジャンプの注意が必要だ。基本的に4色 (CMYK) 用のスクリーニングといえます。



最近の印刷デバイスでは、より広いガモットを得る為に、4 色以上のカラーをサポート(CMYK + オレンジ + 緑 + 青紫 の 7 色インクを使うハイファイ印刷や、PANTONE の CMYK + オレンジ + 緑 の 6 色インクを使用したヘキサクローム印刷)する印刷デバイスがあります。通常、CMY の中の 2 色を混ぜる場合、色が濁り、彩度が低くなるが、CMY の補色を備えることにより、2 色を混合する必要が無くなり、結果としてガモットを格段に広くすることが可能になります。しかしながら、色版数が増えるに伴い、各カラー版間のスクリーン角度の差を十分大きく取れなくなり、モアレの問題に直面します。一方、CTP 機器の普及(CTP はフィルムを使用せず、刷版を直接出力する)により、ドットゲインを低く抑え、制御することができるようになりました。このような背景により、モアレの発生しない FM スクリーニングが脚光を浴びました。 結果、画像のディーテイルを精細に表現でき、ランダムに配置されるドットにより異なるインク同士の重なりを抑制できることにより彩度を高くすることができ、ドットが不規則に並ぶのでモアレが発生しなく、そしてインク量を減らす(10 %~ 20%)ことが出来る、FM スクリーニングが広く用いられるようになりました。



代表的な FM スクリーニングとして Global Graphics が特許を有する Harlequin Dispersed Screening (HDS) があります。同社の HDS は多くの印刷機器メーカーにライセンスされております。FM スクリーニングを用い、最良の品質を得るためには、FM スクリーニングとターゲットの印刷デバイスが共に最適化されていることがとても重要です。



FM スクリーニングは、機器との最適化が得られていない場合、平網で少しざらつく感じがありますが、現在ではスクリーニングの改善により序所に改善されてきております。ディテイルの再現性に優れており、モアレやトーン ジャンプが発生せず、4 色 以上に対応可能なスクリーニング技術です。一方、ドットゲインが大きいのが特徴です。逆に言うとトーンカーブの補正によりインクを節約(10% ~ 20%) できる方式です。また方式的に彩度を高くすることができ、ハイファイ印刷やヘキサクローム印刷との組み合わせで、更に広いガモットに対応できます。



AM と FM を組みあわせたハイブリッド スクリーニングが実用化されております。通常、ドットゲインの影響の大きい中間調に AM 的スクリーニングを用い、ハイライトやシャドー部分には FM 的スクリーニングを用いる方式です。それぞれのハイブリッド スクリーニングには、それぞれ異なる特徴があり、ハイブリッド スクリーニングの一般的な特徴を総評するのはとても困難です。



また CMYK については AM スクリーニングを用い、Orange や Green に FM スクリーニングを使うヘキサクローム印刷が用いられることもあります。



スクリーニングにより高い品質を得るには、スクリーニングと印刷デバイスの両方において最適化が欠かせません。

帳票ソリューションで XPS 形式を採用

帳票マーケットで業界をリードする、ウイングアーク テクノロジーズ株式会社は、Windows Vista よりネイティブでサポートされ、次世代の電子ドキュメントフォーマットとして注目を集めている XPS ファイル形式に対応した業務帳票出力を実現する生成エンジン「SVF for XPS」を開発し、7月末より出荷すると、2007 年 4 月 12 日に発表したが、その後、2007 年 8 月 6 日に同日より同ソフトを出荷開始すると発表した。



@ITのニュースサイトにて、ウイングアーク マーケティング部長の谷口功氏が XPS をサポートした理由と、その将来展望についてコメントしている。



http://www.atmarkit.co.jp/news/200704/12/wing.html



以下は、ウイングアーク テクノロジーズ(株)のプレスリリースドキュメントは、以下から入手可能。



2007 年 4 月 12 日
http://www.wingarc.com/public/detail.php?f_id=44
2007 年 8 月 6 日
http://www.wingarc.com/public/detail.php?f_id=162

JIS X 0213:2004 (JIS2004) の問題

Windows Vista では、MS ゴシックと MS 明朝のアップデート (以後 Version 5.0 フォント) が行われ、JIS X 0213:2004 (以後 JIS2004) に対応した日本語 OpenType フォント;MS ゴシック 3 書体(MS ゴシック、MSP ゴシック、MS UI Gothic)、MS 明朝 2 書体(MS 明朝、MSP 明朝)、そして日本語 Clear Type フォントのメイリオ(語源は「明瞭」とのこと)の都合 6 書体を搭載している。



この JIS2004 規格は、「印刷標準字体」と「新人名用漢字」の両方に対応するものだ。Windows Vista 以前の Windows では、JIS 第 1 および第 2 水準漢字の漢字 (JIS X 0208-1997 で規定の第 1、第 2 水準漢字部分 6,355 文字)に加え、1990 年に制定された JIS X 0212 の補助漢字の 5,801 文字を加えた 12,156 文字の漢字セットを標準フォント (以後 Version 2.3 フォント)としていた。字体に関しては、1990 年に改定された JIS90 規格の例示字体を基本的に採用していた。長い間、表外漢字(常用漢字表に定めの無い漢字)の字体に関する標準がなかったが、2000 年 12 月の国語審議会答申で「表外漢字字体表」が制定されたのを受け、2004 年に JIS2004 として表外漢字字体表に対する「印刷標準字体」が規定された。



2004 年 9 月には戸籍法施行規則の一部が改正され、子供の名前に用いることができる漢字が大幅に拡張され、「新人名用漢字」として公示された。追加された漢字の字種は JIS2004 の中から選定され、字体に関しては「印刷標準字体」が採用された。したがって、官公庁などで「新人名漢字」のすべてに対応しなければならない業務では、JIS2004 に対するフォントを搭載した Windows Vista は、魅力的だ。



この様に、Version 5.0 フォントは、新世代のフォントではあるが、幾つか互換性の問題が発生する。1つ目の問題は、Version 5.0 フォントでは、一部の文字字体が JIS2004 の「印刷標準字体」に対応するために変更 (以前の Version 2.3 フォントでは、JIS90 の例示字体)されていることだ。これにより、たとえ同じアプリケーションのデーターを用いても、Windows Vista 上とそれ以前の Windows 上では、表示される一部の文字の字体が変わってしまうという問題が発生する。またホストベースのプリンタでは、印刷する PC 上のフォントにより、印刷結果が異なってしまう問題が発生する。また PDF を作成する場合、フォントを埋め込まない設定で PDF 生成した場合には、PDF を表示する PC プラットフォームのフォント環境によって文字字体が変わってしまうという問題が発生する。尚、XPS ドキュメントの場合には、フォントの埋め込みが基本となるため、開く環境により表示される字体が変わる問題は発生しない。



2つ目の問題は、Windows Vista 上で作成されたデーターを Windows Vista 以前の Windows 上で開くと、Version 5.0 フォントで新たに追加された文字が表示できない問題が発生する。特に、CJK extension B に属する文字では問題が深刻だ。 CJK extension B(CJK統合漢字拡張B領域)とは、Unicode の符号範囲で U+20000 から U+2A6DF の第 2 面にマッピングされている文字である。上記コードは Windows 上では UTF-16 のサロゲートペア (Surrogate pair) (2 つの 16-bit 符号単位で 1 つの文字を表す)としてでサポートされる。(JIS2004 には CJK extension B に属する文字が 303 文字存在する。)アプリケーションが、UTF-16 コードを処理できない (UCS2 のみに対応する)場合、もしくは Version 2.3 フォントを使用している場合、これらのサロゲートペアの文字は「??」もしくは「□□」などで表示されてしまうことがある。これは、単なる文字化けではく、1 つの文字が 2 つの文字スペースになるので問題は更に深刻だ。



またフォント搭載型のプリンタに印刷する場合にも注意が必要だ。通常プリンタには JIS2004 で追加された文字が搭載されているとは思えないので、これら新しい文字を含む可能性のあるドキュメントを印刷する場合には注意が必要だ。たとえ、Version 2.3 フォントにも存在する範囲の文字だけを使っていても、文字字体が異なる問題が発生することが予測される。葛飾区の「葛」や「辻」等の漢字をテスト印刷することにより印刷結果を確認するのが良いかもしれない。勿論、ダイナミックダウンロードで、文字グリフデーターを印刷ジョブ内に埋め込む場合には、表示と印刷の違いは発生しない。



マイクロソフトでは、幾つかのフォント移行シナリオを用意しているようであり、幾つかのフォントセットをマイクロソフトはダウンロード提供している。詳細は、マイクロソフトの Web ページを参照されたい。

JPEG 2000 vs. HD Photo

JPEG 2000 形式は、画像符号化の標準化を行う ISO と ITU-TS の共同組織である Joint Photographic Experts Group (JPEG) により、2001 年 1 月に規格化された静止画像圧縮方式である。圧縮方式に関しては、JPEG が離散コサイン変換方式 (DCT: Discrete Consine Transform) を用いていたのに対し、JPEG 2000 は離散ウェーブレット変換方式 (DWT: Discrete Wavelet Transfor) を用いている。JPEG と JPEG 2000 の間では圧縮方式に関する互換性がないため、両圧縮方式をサポートするためには、それぞれ異なる Codec が必要となる。



JPEG 2000 は、JPEG に比較し、高い圧縮率を達成可能で、圧縮率を高めた時に発生するブロックノイズやモスキートノイズが発生しないのが特徴である。また、ロッシー/ロスレスの両圧縮方式に対応でき、16 ビットに対応でき、デジタルカメラの CCD 情報をロス無く保存できる能力を持っている。



発表当初は、JPEG 2000 形式は急速に普及するものと期待されたが、現在に至るも、デジタルカメラへの実装は進んでおらず、Internet Explorer への対応も進んでいないのが実情だ。理由は、圧縮時の計算コストが高く、圧縮/伸張処理に多くの時間がかかるためだ。また Windows が OS レベルでサポートしていないのも致命的だ。



一方、Microsoft が Windows Vista と共にリリースした HD Photo 形式も、高い画像品質と圧縮率を両立できる(詳細は、私のブログの"HD Photo とは ?"を参照)。 HD Photo 形式は、Windows の OS レベルのサポートがあるばかりでなく、XPS (XML Paper Specification) ドキュメントの中にも直接埋め込むことが可能だ。現時点で、HD Photo は Internet Explorer でサポートされていないが、Microsoft は、将来サポートすることを明らかにしている。さらに、HD Photo を含む XPS ドキュメントを Internet Explorer で直接表示できる。 現時点では HD Photo 形式も JPEG 2000 同様に、まだデジタルカメラで直接サポートされていないが、Microsoft は、カメラメーカーをパートナーに取り込んでおり、2007 年 3 月時点で 12 ~ 18 ヶ月以内に HD Photo 形式で出力できるカメラの出現を予測した。また、2007 年 3 月に Photoshop (CS2/CS3) 用プラグインをリリースしており、Photoshop に入力されるデジタルカメラの RAW イメージ画像を、HD Photo 形式に変換できるので、当面はこれで事足りる。また Microsoft は HD Photo 形式の仕様を JPEG に提出し、「JPEG XR」 として標準化することを提案している。また、XPS 形式が一つのイメージ形式として HD Photo 形式をサポートしているため、WPF (Windows Presentatin Foundation) 対応のアプリケーションは HD Photo 形式のイメージ画像をそのまま XPS ドキュメントに埋め込むことができる。



Internet Explorer で HD Photo 形式がサポートされると、高いイメージ品質と高い圧縮率を両立するイメージ形式が Web 上で使用できるようになる。これは、Web の世界にとっては画期的なことだ。

WCS とは何か

Windows の Windows Color System (WCS) は、Windows Vista で採用された次世代の Color Management System (CMS) だ。WCS は、カラーに Appearance Modeling アプローチを採用し、現在殆んどの CMS で採用されている ICC プロファイル ベースのカラー マネージメントに対抗するものだ。WCS は、キヤノンの「Kyuanos(キュアノス)」というカラー マネージメント技術をベースに開発されたものだが、具体的にどの部分を使用したかについては公表されていない。Windows 2000 と XP では、Image Color Management (ICM) と呼ばれる「ライノタイプ社」からライセンスされた色変換エンジンを使用し、ICC プロファイルをベースにした CMS を搭載しているが、理解の難しさ、期待される結果を得るための ICC プロファイルを作成することの難しさ、そしてなかなか改修されなかったバグの為に、あまり普及していない。その結果、プロフェッショナル アプリケーションは独自の CMS を使用したり、その他多くのアプリケーションでは、業界標準の sRGB を暗黙のディフォルトカラースペースとして運営してていた。WCS は、この状況を打破しその他の問題点を解消する目的で開発されたものと思われる。一方で、マイクロソフトは、従来の ICM2 のバグを改修し、ICM version 3 にアップグレードし、ICC version 4 プロファイルを使えるようにした。



論理的に、Apperance Modeling を採用することにより、改善されたカラー レンディションを商業印刷にもたらすことができ、たとえばカラーが他のガモットに変換されトーン スケールの圧縮が発生する場合、または CMYK から CMYK への変換において黒チャネルを保持しなければならない場合などにおける幾つかの不確実性を排除できる。しかしながら、現行の WCS には、プロフェッショナルな印刷と、家庭でポピュラーになりつつある写真印刷におけるカラー印刷出力品質を求める部分で、幾つかの問題がある。



■ 多くのプロフェッショナルな印刷現場では、印刷時のインクの Total Area Coverage (TAC) は、コストを削減する目的で、もしくは用紙の伸びなどの物理的な問題を回避するために意図的的に制限される。これは、多くのインク色を混合しなければならない箇所においてインクの流れの問題を引き起こすインクジェット プリンタで特に重要なことだ。WCS では、このインクの制限を加えることは対応できていないようだ。



■ たとえば、パッケージング用の印刷デバイス、高品質プロフェッショナル印刷機 (Hexachrome)、多くのデジタルプロダクション印刷機、もしくは家庭の写真印刷用のインクジェットプリンタ (N-Color) など、4 色以上のインクを使用するディバイスを制御することができないようだ。



WCS プロファイルは ICC プロファイルとファイル形式上の互換性はない。WCS プロファイルは、XML ベースであり、よりシンプルな形式だ。Vista の実装においては、WCS プロファイルは ICC プロファイルに変換することができ、WcsProfilesTag (Windows color spece profiles tag) と呼ばれる Microsoft ICC プライベート タグ (タグ シグネチャーは、"MS00") を用いて ICC プロファイルの中に埋め込むことができる。このようにして、WCS プロファイルを埋め込んで使用することにより、殆んどの場合同等の出力結果を得ることができる。これは、WCS を直接サポートしていない製品でも品質的に許容できるレベルの出力品質を得ることができるという利便性をもたらす。その一方で、異なるツールそしてプリンター間で、違いが発生するかもしれない。



WCS には、大変有能なカラー マネージメント上の利益がある。また、従来の ICM ベースのワークフローにフィットさせる能力や、迅速に WCS モードに切り替える変換機能がある。WCS は、将来性に期待が持てる形式ではあるが、しばらくの間はコンシューマーレベルのディバイスに限られそうだ。



以下 Web サイトに、有用な情報があります。
www.colorwiki.com/wiki/Vista's_New_Color_Management_System_-_WCS



HD Photo 形式、JPEG XR として標準化へ

マイクロソフトの Aiddy の Blog によると、マイクロソフトが開発した高い圧縮率を提供しながら、高いイメージ品質を提供する HD Photo 形式が "JPEG XR" として標準化することを検討するために、その仕様が Joint Photographic Expert Group (JPEG) に提出されたようだ。 以下は、Aiddy ブログの要約です。詳細は、Aiddy のブログ (http://blogs.msdn.com/adrianford/archive/2007/07/31/hd-photo.aspx) を参照ください。



HD Photo 形式 (以前、WM Photo もしくは Windows Media Photo と呼ばれていた)は、XML Paper Specification (XPS) の 1 つのイメージ形式としてサポートされております。HD Photo 形式は、リッチなカラーをサポートしつつ、優れた圧縮(ロスレス、ロッシー、ビジュアル的にロスレス)を提供できます。たとえば、XPS は、HD Photo を使用することにより圧縮を提供しつつ、scRGB カラースペースにおいてラスターイメージコンテンツをサポートできます。



本日、JPEG と Microsoft は、HD Photo 仕様が "JPEG XR" として標準化することを検討するために JPEG に提出されたと発表しました。XR は "Extended Range" の約です。提案された JPEG ワークアイテムには、"JPEG Systems" におけるワークも含まれ、JPEG と JPEG 2000 に関連して開発された多くの技術の統合と調和が含まれますので、これらはコーディングとメタデーター標準の広い範囲に適用できます。



Aiddy は以下の様に述べています。「HD Photo と XPS の両方にとって、とても重要なステップです。HD PHoto の標準化は、相互運用性と多くのアプリケーションやソリューションが HD Photo 形式の利益を得るための、我々のコミットメントのその他の例です。」



関連情報は、以下のニュースサイトからも得られます。



http://www.eweek.com/article2/0,1895,2164299,00.asp
http://news.com.com/Microsoft+photo+standard+comes+into+focus/2100-1041_3-6199840.html

copyright © 2017 萩さん日記 all rights reserved.
Powered by FC2ブログ.