2007年7月31日火曜日

2色君

Illustrator ver.8までにしか対応してないのが難点なのだが、K版を別な色に手軽に置き換えるのは今のところこのツールしか見当たらない。

この「2色君」、Perlで動いている。
ということは、ResEditでIllustrator ver.9以降に対応するように書き換えれば何とかなるのかも知れない。

Illustrator ver.9以降はデータ部分と出力部分に分かれており、データ部分はPDFで記述され、出力部分はPSで記述されている。だからPerlで書き換えても書き換えられるのは出力部分のPSだけであり、出力結果は書き換えた通りになるものの、ファイルを開くと書き換える前の状態になっている。PDFをバイナリエディタで書き換えるのは現実問題として(現時点では)無理だろう。ただPDF作成時にK版を別な色に置き換えることはできるはず。

「2色君」の作者の方が、以降のツール開発していないのが残念!


で、今日気づいた問題。
会社ではDistiller4を使ってます(古~!)。
こいつで作成したPDFをOS-XのAcrobat7で開くとスミ1色のデータがなぜか4色のスミになっている。
原因は「すべてにカラーマネジメント用タグを作成」にチェックが入っていたから。
「カラーマネジメントタグにすべてタグ付け変換しない」にチェックを入れて解決。
プロファイル、カラーマネジメントを熟知しないとDTPアプリは怖くて使えない。

2007年7月30日月曜日

色の変更

C+Mで作成された2色データを特色の刷り色PDFにする時は
http://www.ognet.jp/bekkan/bbs/bbslog/2000/bbs00_5-2.html#356のやり方をしています。

作業には、データを作ったソフトの他に、
・Acrobat4.0
・PhotoShop5.0(4.0は不可)
が必要。

おおまかな手順は、
1.PhotoShop5.0で特色出力の設定データを作っておく。
2.各アプリケーションからPostScript(以下PS)ファイルを書き出す。
3.PSファイルをAcrobat Distillerにかけ、PDFファイルを作る。
4.PDFファイルをそのままカラープリンタから印字する。

1.と2.の詳細な手順は下記の通り。
1.PhotoShop5.0を立ち上げる。
2.カラーピッカーをダブルクリックして色選択ダイアログを出す。
3.右側の「カスタム」ボタンをクリックして、画面を切り替える。
4.左上の「カラーブック」から「DICカラーガイド」を選ぶ。
5.必要な特色番号を探してクリックする。
6.ダイアログを「OK」クリックで閉じる。
7.カラーピッカーに、探した特色が出てきているので、「色見本」
  パレットを画面に出し、何も色がない末尾の空白部分にカーソル
  を動かす。
  すると、カーソルがスポイトから「バケツ」に変わるので、そこ
  でクリックすると、色見本に特色が入り込む。
8.必要な色数だけ、2~7の手順を繰り返す。
9.「ファイル」メニューの「カラー設定」→「CMYK設定」を選び、
  「CMYKモデル」を「内蔵モデル」にし、
  「印刷インキ設定」を「カスタム」にする。
10.「インキの色特性」という画面が出るので、その中の右側に
   ある色サンプル部分をクリックする。
11.カラーピッカーが出るので、手順7で色見本パレットにセット
   した色をクリックし、「OK」で閉じる。
12.必要な色数だけ11を繰り返す。
13.画面下の「オーバープリントカラーの予測」をチェックする。
   ここで、もともとはCMYKそれぞれの掛け合わせで再現して
   いた他のサンプル色(例:CMやMY)が変わることを確認
   すること。
14.「OK」で閉じると、「CMYK設定」の画面に戻るので、
   そこで上のラジオボタンを「変換テーブル」に切り替え、
   右にある「保存」ボタンをクリックする。
15.「CMYK設定の保存」というダイアログが出るので、分かり
   易い名前をつけて保存する。
   保存先は、起動ディスクの「システムフォルダ:初期設定:
   ColorSync 特性」フォルダ。
16.保存が終わったら、必ず「キャンセル」すること。
   「保存」してしまうと、普通のCMYK画像の色が変わって
   しまう。

ここまでがPhotoShopの作業(大まかな作業区分けの1)。

17.各アプリケーションから、PostScriptファイルを書き出す。
   Distiller用の設定を使ったAdobePS8.5.2などが良いかと。
   用紙設定は任意でOK。

(大まかな作業区分けの2)

18.Acrobat Distillerを立ち上げる。
19.「設定」メニューから「ジョブオプション」を選ぶ。
20.「一般」タブをクリックし、解像度は「300」程度に。
   「圧縮」タブをクリックし、チェックが入っていれば
   全部外す。
   「フォント」タブをクリックし、「全てのフォントを
   埋め込む」にチェックが入っていた場合は外すこと。
   「カラー」タブをクリックし、
     「変換」の中は「すべてsRGBに変換」にする。
     「仮定のプロファイル」が変えられるようになったら、
     「sRGB」は特に変更の必要なし。
     「CMYK」を、手順15で保存したファイルにする。
     そこで保存したのと同じ名前の設定ファイルが、
     メニューの中にある。
   「詳細」タブをクリックし、下にある「デフォルトページ
   サイズ」の単位を「センチメートル」に変える。
   数字は出力したい紙のサイズを入力。
21.「保存」ボタンをクリックして、この特色変換の設定を
   保存する。これも分かり易い名前をつけたほうがよい。
22.「OK」で、Distillerが立ち上がった直後の画面に戻る。
   「ジョブオプション」が、手順21の名前になっている。
23.書き出したPSファイルをウインドウ内にドラッグする。
   PSをPDFに変換し始める。
24.変換が終わったらDistillerを終了。

25.出来上がったPDFをダブルクリックしてAcrobat4.0を立ち上げる。
   ここからカラープリンタに出力する。

備考
・墨版を特色に当てはめることはできない。
 (理由:PhotoShop5.0で、「CMYK設定」のK版の色を変えることが
 できないため)
・PDF化したときのフォントの状況など、まだ検証が完全に出来ていない
 部分もあるのでご了解を。

・出力の設定などは環境によってまちまちなので、このやり方でうまく
 いかない場合もあるかもしれませんがそういった時は試行錯誤してみて
 ください。
 そういった意味で手順20は固定的なものではないです。


で、今日の仕事はスミ一色のデータを刷り色特色のPDFを作成するというもの。
上記のやり方ではできません。

こんな時は2色君が助かります。でも、イラ8まででしょうね。
ver.9以上をどうするかは今後の課題。
Perlでなんとかなるか検証する価値はありそう。

2007年7月26日木曜日

どんなファイルも変換する無料ソフト

http://www.hotwebmagazine.com/31より

ウェブ作業に限らず、コンピュータで仕事をしていると何かとファイル形式を変えることが必要になってくる。

JPEGをGIFに変えたり、WAVをMP3に変えたりしなければならない。

そんな時、かなり使えるのがZAMZARの無料変換サービスである。ビデオ、画像、音楽ファイル、ワードソフトなど考えられるファイル形式はほとんど対応している。

STEP1がまずもとのファイルをアップロードをする。

STEP2が変換したいファイル形式を選択。

STEP3に自分のメール先を入力すると、変換したファイルをメール先に送ってくれる。

このソフトのうれしいところはデータを特定のファイル形式として保存したい場合、 変換ソフトが必要ない。またMACやWINDOWSのみでサポートされているファイル形式も変換の問題を解消してくれる。

2007年7月24日火曜日

Windows Media Playerで動画をキャプチャ

http://aozora60.at.webry.info/200707/article_20.htmlより

(略)

 今日、閲覧してくださった方から、Windows Media Playerでも動画のキャプチャができることを教えて頂き、早速、試してみました。

 ツール→オプション→パフォーマンス→ビデオアクセラレータの詳細設定の中にある「オーバーレイを使う」という所のチェックをすべて外し(ビデオ、DVD共に)ておき、後は、再生した上、キャプチャしたい場面まで移動させて、そこで、止めておく。

 後は、PrintScreen機能を使って、ペイントに貼り付けておき、jpeg画像で保存すれば完了である。

2007年7月22日日曜日

PDF関連のエラーの一例

http://river-p.jp/blog/blog.php?ID=121より

下記は今までに起こったエラーの一部とその対応例です。
弊社環境におけるエラーと対応策であり、全ての環境に対応するものではありません。

PhotoshopCS2で保存した画像を配置したIllustrator epsがDistiller5でエラー
⇒配置画像をPhoshop6にて再保存で改善

Illustrator9、10のeps、Distillerでエラー終了。
⇒書類設定の「コンバチブルグラデーション&グラデーションメッシュプリント」のチェックを外したら改善

Distiller7のフォントの場所で指定した古い作字フォント、Distiller7でエラーも出ずに文字化け
⇒OSのFont Bookで追加で改善

InDesignにPDFを配置し更にPDF書き出し、Trueflow(CPSI)で2値のtiffの体裁が変わった
⇒InDesign→EPS→Distiller→PDF→Trueflowで改善

PDFを配置したInDesignCS2でeps書き出し、Distillerでエラー
⇒InDesignCS2からPDF書き出しで対処

Trueflowで問題のなかったPDFが他社RIP(CPSI)でグラデーションの体裁が崩れた
⇒Trueflowから書き出したアウトラインPDFで改善

Windows「いきなりPDF」で作成されたPDFがTrueflowで半角スペースが空いてしまう
⇒原因分らず、アウトラインPDFを修正して対応

Illustrator8のepsをQuarkXPressに配置し書き出したepsがDistillerでエラー
⇒配置画像のファイル名を全て半角欧文に変更したら解決

関連不明なのだが

「需溘、涙がでちゃう―」 丸旋戍溘氏(36)、衆院議員に抱きつき号泣…
の見出しのニュースサイトがあった。
http://newsing.jp/entry?url=haialfa.blog111.fc2.com%2Fblog-entry-137.html

見てみると
「珠代、涙がでちゃう―」 丸川珠代氏(36)、片山さつき衆院議員に抱きつき、号泣…武蔵小山駅前
となっている。

意図的なのか? 文字コード絡みでこうなったのか?
 

勉強不足ゆえによくわからない(残念!)

2007年7月18日水曜日

InDesign CSの出力

http://pocketdtp.blog16.fc2.com/blog-entry-138.htmlより

CS、CS2でも問題はあったのね。滅多に入稿しないから気づきませんでした。

制作会社にいた時はInDesignを使いたくても出力先が対応していないため使えず、
InDesign対応OKの印刷会社なのに入稿せず。。。

2007年7月16日月曜日

2004JIS の死

http://openblog.meblog.biz/article/57292.htmlより

 「 Vista で採用されたのは、JIS2004ではない」
 このことは、重要だ。マイクロソフトは「Vista では JIS2004 が採用された」と述べているが、それは嘘(もしくは間違い)なのだ。では、なぜか?
 先日も述べたとおり、第3水準・第4水準の文字は、シフトJISで符号化がされていない。文字はあるが、その符号化は、 unicode による符号化であって、シフトJISによる符号化ではない。とすれば、この文字規格は、unicode の規格であって、JIS2004の規格ではない。
 たとえば、(01月28日の例で取り上げたが)「騨」という文字がある。この文字の正字である「馬單」は、シフトJISでは「EFB0」という符合位置に符号化される。では、シフトJISで「EFB0」という符合位置の文字を出力すると、その正字が出力されるか? 否。出力されるのは、「?」または「・」というような文字だ。つまり、「エラー」である。
 これは当然だ。その正字は、シフトJISでは符号化されていないのだから、符号化されていない文字が出力されるはずがない。「エラー」となるに決まっている。
 要するに、Vista においてシフトJISで出力される文字は、JIS90で出力される文字集合と
、まったく同じである。字形の差はあるが、文字集合としてはまったく同じである。字数の総数も同じだ。出力されない符合位置も同じだ。とすればVista において採用されたのは、JIS90 の規格(X 0208)であって、JIS2004 の規格(X 0213)ではないのだ。


中略

ここで、(1)(2) の点をまとめると、こうなる。
 「JIS2004 という規格は、欠陥規格である。MS版の JIS90に対して上位互換でない(文字化けが発生する)せいで、Windows では採用されない規格となった。また、文字集合としてみても、秀英明朝では正されている 20字以上の文字が正されていない(つまり誤字のままである)。
 要するに、JIS2004 という規格は欠陥規格であり、それゆえに、使われない規格なのだ。実際に使われるのは、JIS97(正字版)であって、JIS2004ではない。JIS2004 は、誰も使わない規格である。JIS2004 は死んだ。」

関連:http://yoshihashi.blogspot.com/2007/07/2004jis.html

シフトJIS と unicode

シフトJIS と unicodeより

(3) unicode
 一方、 unicode には問題が山積みだ。だいたい、素人は unicode という言葉を使っているが、 unicode というものは一種類しかないわけではない。UTF-8,UTF-16BE,UTF-16LE,UTF-32 などが混在している。

     【 追記 】
    このことを理解しない人が多いので、実例として、
    次の三つのファイルを示す。
      → UTF-8.txt ,UTF-16BE.txt ,UTF-16LE.txt
    ※ ブラウザによっては、文字化けします。その場合は、
      いったん保存してから、メモ帳で開いてください。

 極端に言えば、 unicode という文字コードはない、とすら言える。 unicode の文字セットは存在するが、 unicode という単一の文字エンコードはないわけだ。( UTF-8,UTF-16BE,UTF-16LE,UTF-32 ならばある。)
 そして、これらの文字エンコードには互換性がない。(部分的な互換性はあるが、まともな互換性はない。)
 その弊害は?
 たとえば、検索しても、まともに検索できない、ということがある。GREP 検索するにしても、それぞれは異なる文字コードだから、別々に検索し直す必要がある。つまり、上記の4通りで、4回も検索する必要がある。検索時間が4倍になる。バカバカしいとしか言いようがない。
 また、前にも述べたが、ファイル名を unicode にすると、古いOS(Windows98など)ではファイルを扱えなくなる。ファイル内容を読み取ることもできないし、ファイルを開くことすらできなくなる。
 また、HTMLファイルを書くときは、ソースで文字コードの指定を正しく指定する必要が出てくる。間違った文字コードを指定すると、HTML文書全体が読み取れなくなる、ということがある。特に、UTF-8 しかサポートしていないソフトで、JIS第3水準・第4水準の難読文字を入力すると、まったく漢字を扱えなくなる、という問題が生じることもある。

 また、そもそもの話、Windows は UTF-8 を採用していない。Windows がOSとして採用しているのは、UTF-16LE である。だからWindowsにおける「ユニコード・テキスト」とは UTF-16LE のことである。というわけで、「 UTF-8 への統一」なんて、ハナから無理だ。
 まとめて言おう。 unicode については、次のように言える。
  ・ ネット   では UTF-8 が圧倒的に優勢。(UTF-16 は通用しにくい。)
  ・ Windows では UTF-16 が圧倒的に優勢。(UTF-8 は通用しにくい。)
 そして、双方(UTF-8とUTF-16)には、まともな互換性はない。どっちかに統一することなど無理である。だから、「 unicode に統一する」というのは、文字エンコードとしては無意味であるわけだ。(文字セットとしてならば意味はあるが。)

 ※ ついでだが、従来はシフトJISでエンコードしていた人が、新たに 「 UTF-8 への統一」という方針を取ると、従来の シフトJISの文書または新規の unicode のどちらか一方が grep 検索の対象にならなくなる。両方をいっぺんに grep 検索することはできないからだ。……したがって、エディタを使っている人だと、非常に不便になる。
 ※ HTMLの作成も同様だ。HTML を UTF-8 にして、テキストファイルを UTF-16LE にすれば、双方の文字エンコードが異なるので、いっしょに扱うのに不便だ。

APPE

せうぞーさんのとこより

Adobe CS2からDistillerも他のCSアプリケーションもPDF Libは同じものを使うようになりました。ですからエンジンそのものは等価だといえると思います。
しかしCPSIベースだと、結局はPSに落とし込まれてからレンダリングされるのでしょうから
アプリケーション→PDF→CPIS→PS→レンダリング
という処理になります。一方、アプリケーションからPSを書き出してDistillerを通す場合には、PPDを指定でます。
アプリケーション→PPD+PS→ Distiller→PDF→ CPSI→PS→レンダリング
かつ、一旦PSになった状態からPDFを生成するわけですから(さらにPSにしたときの)可逆性もいいはずです。

別に常識にこだわっているわけではありません。
CPSIにもいろいろな種類がありますから、すべてのCPSIがアプリケーションからのダイレクトPDFをスムーズにレンダリングするとは限らないと思います。
ベンダーさんなんかがアプリケーションからのダイレクトPDFに対していまひとつ歯切れが悪いのも仕方がないかな、とは思います。

>APPEのように最終出力が直接PDFをレンダリングできるなら、Distillerは過去のものですね。
という発言は、先ほど書いたようにPDF Libが同じになったのが第一点。
それからAPPEではPDFをPSにすることなくレンダリングしますので、むしろPSに落とし込むこと自体が透明処理を破壊してしまい、むしろ悪い結果になるであろうという点です。
何度もいいますが、別に常識がどうのこうので、Distillerにこだわってるわけではないです。

2007年7月15日日曜日

タグ付きテキストの反映

プリンターが印刷する隠し追跡コードの問題
より

タグ付きテキストがどこまでできるかをテスト^^

設定
書体:明朝、文字色:金赤、文字サイズ:大きい、太さ:太い


で、この問題について突っ込んで、某SNSのコミュから締め出されたそうな
[mixi]DTP完全データへの道コミュBANされる

こっちは書体をやや小さいにしたけど、小さくなったのは欧文だけみたい。
ps.RSSで見ると小さくなっていた。

blogspotの使い方

なんでgoogle blogにしたのか? 

通販生活ならぬgoogle生活がやってくるかな?と、なんとなく思ったから。
日本国内ではマイナーなblogだろうとも思った。
blogを始めたことは1人にしか知らせていない。
正直、多くの人から見られたくない(未熟だから)。

そんなわけで、このblogの使い方もよく分かっていない。
偶然、htmlタグが使えることを知ったぐらいである。

初心者にもやさしいリンクHTMLタグ作成を使ってタグの勉強にもなるかも知れない。

で解説ページが見つかった。
http://www.boraro.gozaru.jp/blog/blogger.html

読んだ後の感想なのだが、結果的に自分好みのblogサイトだとも思っている。

同じblogspotユーザーが見つかったので、彼のblogを読みつつ、このblogの作り方を勉強してみようとも思っている。
I saw seashells.

で、読み進めていくうちにPICASAを使わない画像の投稿方法も載っていた。
Google DocsからBloggerへ投稿。

2007年7月14日土曜日

チルダ

windows版のsafariが出たわけだが、
http://d.hatena.ne.jp/NAOI/20060623/1151049226の問題は解決されたのだろうか?

解決法はあるのだが
http://islandmac.exblog.jp/4723400/より

SafariでBBS等に〜(チルダ)の入ったアドレスを書き込むと、半角チルダが全角に置き変わってしまいリンクが行えなくなります。
その場合は〜(チルダ)のかわりに %7E を入力しましょう。

例 http://www.ds-island.jp/〜fukuhara/ (チルダの場合)
例 http://www.ds-island.jp/%7Efukuhara/ (%7Eの場合)
↑架空のページです。

%7Eが半角チルダと認識されてリンクが正常に行われます。


CLさんが以前こんなようなものを作ったのだが、よーわからん。
http://blog.dtpwiki.jp/dtp/2007/05/dtpsafarigrease_4bc5.html
ググったらFireFox用だったのね。。。
IE7に慣れているだけに。。。

2007年7月11日水曜日

天才の引きこもり作業

以前、読んだことのあるネタなのだが、雑談の中で妙に思い出されたのでメモ。
http://blog.antenna.co.jp/PDFTool/archives/2006/02/27/

ところで、話を伺っていて、このHarlequin RIPを開発した人の方に関心をもってしまいました。なにしろ、PostScriptを処理するプログラムを作るのは、恐ろしく大変、と以前からいろんな開発者に聞いています。私の知っている限りでは、PostScriptインタープリタの開発はソフトウェア開発者が誰もやりたがらない仕事の一つです。Harlequin RIPというのは、PostScriptを読み込むこともできますし、PDFを読み込んで処理することもできます。で、PostScriptインタープリタのコア部分の開発は大勢でやるものではなく、やはり天才が一人で作るものなんだそうです。Harlequin RIPのコアを作った人は、英国のケンブリッジで、一人で部屋にこもって作ったのだそうです。こんなすごいものを一人で作るとは、一体、どんな天才なんでしょうか。

2007年7月9日月曜日

期間限定のblog

タイトルからして年内には終了すると思うが、内容が濃いだけに要チェック。

Mac OS Xの文字コード問題に関するメモ

2007年7月7日土曜日

PDFとAdobeメモ

PDFフォントについて
http://www.antenna.co.jp/PDF/reference/FontEmbedding.htmより
これを理解せんことにゃ、先に進めんわな。

Adobe Podcast
http://www.adobe.com/jp/special/podcast/

AdobeスゴロクCS3
http://sugorock.net/

当分、仕事で使えそうもないだけにこいつで練習。期間限定なのが辛い(>_<)

無料自動デザインソフト

http://bookdesign.blog95.fc2.com/blog-entry-2.htmlより

最近「n_Gen」というソフトがあることを知った。
n_Genは自動的にCDジャケットなどのデザインを作成するデザインソフトだ。あらかじめ選んだ複数の写真やロゴを自動的にレイアウトしてくれるらしい。ボタンをクリックするだけで次々と無限に異なるデザイン・バリエーションを生成してくれるので、ユーザーはその中から気に入ったデザインを選んで保存すればいいだけだ。おまけにこのソフトはウエブサイトから無料ダウンロードできるという。プロのデザイナーからすればたまったものではない。

全員がデザイナーになれる時代なのだ。
オールド・デザイナーはもはや引退するしかないのだろうか?
(幸いにも)このソフトのサイトは現在では閉鎖されているようだ。
まあ、アナログ時代からのオールド・デザイナーとしては、DTP自体がすでに自動デザインソフトのようなものだが…。


ダウンロードが再開されたら使ってみたいのだが。。。

2004JISへの対応

m_ogawaさんのBBSを読み直してみたら、2004JISの提唱者のサイトが紹介されていた。
http://www005.upp.so-net.ne.jp/greentree/koizumi/75_moji.htm

以下の指摘のとおり誤解してました。
 [ 付記5 ]
 なお、誤解が広く見られるので、指摘しておく。それは、次の誤解だ。
 “ 新JISでは、字形の変更がなされ、略字から正字へと変更された。だから、略字の代表格である「鴎」は、「区鳥」から「區鳥」に変わった。”
 これは間違いである。正しくは、次の通り。
 “ 新JISでは、字形の変更がなされ、略字から正字へと変更された。ただしそれは原則であり、例外がある。略字の代表格である「鴎」は、この例外に該当する。ゆえに、「区鳥」から「區鳥」に変わることは、ない。「鴎」のコードポイントの文字は、略字の「区鳥」のままであり、正字の「區鳥」は、新たなコードポイントに追加された。つまり、従来の「鴎」という文字は、新JISでも、略字のままである。”
 具体的にコードポイントを述べると、次の通り ( → 文字コード表 )
    区鳥 …… シフトJIS: 89a8
    區鳥 …… シフトJIS: efe3
 では、なぜ、そうなったか? それは、文字コードの歴史と関係する。簡単に言えば、正字の「區鳥」と略字の「区鳥」はもともと unicode に存在するので、混乱を防ぐためだ。仮に、字形の変更をすると、「區鳥」という文字コードポイントが二つ存在することになってしまう。
 なお、同様の文字は、次の19字であるらしい。(出典は このサイト )
     侠 倶 呑 填 掴 焔 痩 祷 箪 繋 繍 莱 蒋 蝉 蝋 醤 頬 顛 鴎
 これらの19字は、前述の通り、「 unicode にすでに正字と略字があるので、正字と略字がそのまま残る文字」と見なしていいだろう。全部チェックしたわけではないが、任意に7個チェックしたら、7個とも正字と略字がすでに unicode に入っていた。残りも同様だろう。
( ※ 実は、この種の例外は、私は5字ぐらいしかないだろうと予想したのだが、思ったよりはたくさんあったわけだ。……なお、これらの文字は、「補助漢字」のうちに「正字体」として組み込まれたもの。略字主義者が徹底的に排除しようとしたのだが、うまく19字をもぐりこませたわけだ。それは「正字を救うための処置」であったが、今となっては逆に「略字を救うための処置」になっている。歴史の皮肉。)

ご丁寧に対処策まで紹介してくれている^^

 新JISを受けて、企業や個人がどうするべきかを、示しておこう。

 [ 参考1 ] 企業の場合
 企業は今後、どう対処するべきか? 
 字形の変更があると、「人名の混同などでトラブルが起こる」という混乱が予想される。それで企業は「大変だ、大変だ」と騒ぐかもしれない。そこで、対処策を示しておこう。最善の対策は、こうだ。
 「何もしないこと」
 ただし、まったく何もしないのではなくて、頭だけは下げるといい。つまり、「一点が二点になった」と文句を言う顧客(クレーマー)がいくらか出るだろうから、これらの顧客に対する苦情受付の窓口を用意しておくといい。たぶん相手はしつこくネチネチと文句を言ってくるだろう。だが、JISやマイクロソフトが決めたことに対して、自社としてはどうしようもない。だから、こういう顧客に対しては、ひたすら頭を下げるしかない。
 なお、頭を下げるだけでなく、何らかの対処をすると、とんでもないことになる。たとえば、「システムを書き換えて、これまでの一点しんにょうの略字を別のコードポイントの文字に自動的に置換する」というような措置を取ると、コードポイントが変更されるから、同一人物に二つの文字コードが割り当てられることになる。こんなことをやれば、必ず、どこかで大問題が発生する。
 ここでは、原則を理解しておこう。今回の「字形の変更」では、字形が変更されるだけであり、コードポイントそのものが移動するわけではない。現在の「辻」さんを、新たなコードポイントの略字の「辻」さんに移動すれば、問題が起こるが、現在の「辻」さんを、字形では正字にするだけ(コードポイントを変えない)のであれば、何も問題は起こらない。── コンピュータのシステムでは、コードポイントだけが大事であり、字形の差などは内部処理には使われないからだ。
 なお、どうしても「略字の辻にしろ」と文句を言う顧客もいるだろうから、そういう顧客に対しては、「コードポイントの変更の手続き」を取ってもらえばいい。それは、通常の「氏名変更の手続き」と同じである。結婚後に「改姓」があるように、今回も同じく「改姓」と同様の手続きを取ってもらえばいい。これはこれで、特に問題はない。
 とにかく、「自動処理で一挙にコードポイントを変更する」ということだけは、やめた方がいい。そんなことをすれば、トラブル続出は目に見えている。余計なことは、やらない方がいい。── そして、問題は、それだけだ。
 要するに、企業がやるべきことは、「顧客対応」の窓口にいる女の子をたくさん雇用することだけだ。それ以外には、何もやらなければいい。それで万事解決。
 ついでに言えば、マスコミがあらかじめ「こうなりますよ」と世間に情報提供しておけば、いちいち文句を言う顧客もいなくなる。その場合は、まったく何一つしなくていいことになる。
( ※ ただし、文句を言う顧客だけは、「改姓」と同じ手続きが必要となる。これらの顧客だけは、少しだけ、余分な手間がかかる。……これらの顧客は、手続きをするか? たぶん、しないでしょう。ぶつくさと文句をたくさん言うのは大好きだが、手続きをしてまで訂正したがる人は、たいしていないはずだ。要するに、一点か二点かの違いなんて、言っている本人だって、本当はたいして気にしないのだ。)