AD-810MX の方が処理スピード速いようです。ていうかTrueFlow の 売りのひとつ、PolishedInput ていうPitStop Server のプリフライト処理をしながら変換処理するものを使うと、生産性が激落ちてしまうそうな。（TrueFlow 利用者の意見希望）
まったくその通り、しかもPDF/Xで作ってあっても白紙のページがあるとエラーにされてしまう…（自分の所だけ？？）
Acrobat 8 ProfessionalのAcrobat Distller 8はsfnt-CID形式フォントのエンベットが出来なくなった。
Biblos外字はDistller 5まで。
ジョブオプションの設定の「フォント」の項目の中にある「埋め込めなかったときの処理」を「ジョブをキャンセルする」から「警告した後続行する」に変更してPDF変換をしてみてください。
一応半角スペースは¥s、 タブは¥t、リターンは¥r(Macなので改行コードCRで作業している。WinならCR/LFなので¥r¥nとする必要があるだろう)に置き換えた。
“disc”は、オーディオ CD、CD-ROM、DVD-ROM、DVD-RAM、DVD ビデオディスクなどの光学式メディアを指します。“disc”には読み出し専用のもの (ROM) と、一度だけコンテンツを作成する（ファイルに書き込む）ことができるもの（複数回にわたる作成操作を行わない場合の CD-R や DVD-R など）と、消去して何度でも書き換えられるもの（CD-RW、DVD-RW、および DVD-RAM ディスクなど）があります。
“disc”はすべて取り外し可能です。つまり、デスクトップや「Finder」からマウント解除またはイジェクトすると、コンピュータから物理的に取り出すことができます。
“disk”は、磁気媒体を指します。たとえばフロッピーディスクやコンピュータのハードドライブのディスク、外部ハードドライブ、iPod もこれに相当します。“disk”は、意図的にロックやライトプロテクト（書き込み禁止）をしない限り、常に書き込み可能です。1 つの“disk”を簡単に複数の小さなボリュームに分割（パーティション設定）することもできます。
御存知の通り、Excelが吐き出すHTMLは「汚い」。Excelでの見栄えをそのまま再現することに注力するあまり、全セルに適当なclass指定、ヘッダに長い埋め込みスタイルとから始まる独自スクリプト多数、全漢字にルビ(ただし非表示)。そのままでは編集も困難、しかしセル数がセル数だけに手動での移し替え作業も困難である*1。
特にリターン/タブを含めた表記になっているので、そのままでは移植できない部分もある。一応半角スペースは\s、 タブは\t、リターンは\r(Macなので改行コードCRで作業している。WinならCR/LFなので\r\nとする必要があるだろう)に置き換えた。
途中改行の削除
検索文字列
([^>])
置換文字列
Excel-HTMLは長い文字列を適当なところで改行する。その結果として、属性を含むタグの置換などの際、不規則に改行などが含まれ置換を困難にしている。ひとまずタグの区切り以外での改行をすべて削除した。
不可視属性の削除
検索文字列
<span[^(style)]*style='display:[^(none)]*none'>.*?
置換文字列
不可視にしている部分は不要なデータと判断、中身ごと削除する。
Table要素以外の削除
検索文字列
(<[^t][^>]*>)+([^<]*)(]*>)+
置換文字列
$2
つまり<t以外から始まり</t以外で終わるタグ部分だけを削除、間に挟まれた<以外の文字(即ちタグでない部分)を残す。
スタイル他、余分な属性の削除
検索文字列
((style)|(x:fmla)|(width)|(height))=[^>]*
置換文字列
様々な鬱陶しい属性、中心的には見栄え再現のためのインラインスタイルだが、そうした余分なものを切り落とす。
そして、CS2で新たに加わった、
「カラー値を保持（リンクされたプロファイルを無視）」（Illustrator CS 2）
「番号を保持（リンクされたプロファイルを無視）」（InDesign CS 2）です。
「Illustrator」「InDesign」では画像（オブジェクト）を配置（リンク）できますが、その「配置（リンク）された画像（オブジェクト）に埋め込まれたプロファイルは無視します」という事です。
なぜこの設定が必要であり、新たに「プリプレス用-日本2」の標準になったのかを考えてみます。
この設定の説明には、「CMYKドキュメントを開くとき、そのプロファイルを保持しますが、リンクされたコンテンツに含まれるCMYKプロファイルは無視します。RGBに読み込まれたカラーは数値よりもアピアランスを優先し、CMYKに読み込まれたカラーはアピアランスよりも数値を優先します。」
と書いてあります。
かなりわかり難い記述だと思います。
この記述を自分なりに解釈すると、
「CMYKドキュメントの場合、ドキュメントのプロファイルは生かし、配置された画像（オブジェクト）のプロファイルは無視します。」
「RGB画像（オブジェクト）を配置した場合、見え方（アピアランス、外観、Lab値）を優先させ、CMYK変換します。CMYK画像（オブジェクト）を配置した場合、CMYKの値は変化しません。（見え方は変わる場合があります）」
これは、adobeの説明によると「セーフCMYK」モードと言うのだそうです。
「セーフCMYK」モードとは、簡単に言うと、RGB、CMYK混在環境の中で、CMYKは値を変化させないで出力するという事です。
自分なりに解釈すると、「RGBはカラーマネージメント適用するが、CMYKは値を変えない＝カラーマネージメントを適用しない」と言う事だと思います。
CMYKからDICに変換
ここまでのTipは使用しているデザイナーさんも多いと思います。これとは逆に、まれにCMYKを1色ないし2色などで印刷したい場合があります。この時、CMYKからDICナンバーを割り出します。
ここでPhotoshopを使用します。[カラー]ウィンドウのカラーピッカーで先ほどの金赤[C:0 M:100 Y:95 K:0]を入力します。
このまま[カラーライブラリ]をクリックすると近似のDICナンバーが出ます。
上記のように[DIC565]と表示されました。画面上ではかなり違う色に見えますが、DICチップを比べると画面上ほど色の差はありません。[DIC565]をCMYK分解すると[C:0 M:90 Y:100 K:0]に分解されますので差は許容範囲と思います。あとはDICチップや印刷結果を見比べ微調整することになります。
以前、Linkstationのファンが故障してアクセスができなくなりました。
どうやら回転信号をLinkstationで拾っているらしく、
その信号を検出できない場合は起動しない仕組みになっているようです。
（試しにファンを指でまわしながら電源を入れたら起動しました。）
ファンが回らないとCPUが動作しないようになっているみたいですね。
File Juicer は PDF, Word, PowerPointなど各種書類からテキスト・画像・動画を抽出してくれるシェアウェア(€9.95)だ。
仕事でホームページの更新・作成を行うときに大いに力を発揮してくれる。
よくあることで、原稿をワードファイルやPDFで頂くことがある。
このときに書類に含まれている画像もページにアップして欲しいといわれる。
基本的には「その元の画像を下さい」とお願いするわけだが
原稿を作った人と窓口の人が異なっていると、簡単にはいかない場合がある。
窓口の人がよく分かっていなかったり、原稿作った人がまた別の会社だったりと、色々と大人の事情が出てくるわけである。
そういうときにはこの File Juicerだ。
もう手放せません。
操作は簡単で、「ここにファイルをドラッグ」と言うところにファイルをドラッグするだけ。
こうすることで、大体次のようにフォルダごとに抽出した画像・テキストなどを分類してくれるのだ。
（シェアウェア未登録時はたしか “File Juicer” の文字が入る画像などが全てにではないが入る）
自分の場合は、PDFからの抽出を大なうことが多い。
画像・テキストの抽出が主な目的。
ただ毎回注意しなければいけないことがあって
ここがどうにかならないかなーと常々思っている。
●全角スペースと半角スペース
PDFからの抽出しか試していないのだけど、全角スペースで入力されたものがテキスト抽出すると半角になっている。
これはMacのプレビューでファイルを開いてテキストをコピペしても半角になっているので、なんらか変換処理が入っているのか、Macの仕様なのか・・・よく分かりません。
素直に Acrobat Reader(全角スペースは全角スペースのままなのです)を使えと言うことか？
●日本語文字コード（UNICODE正規化）
まあ、これも Acrobat Readerからテキストコピペすればいいのだけど、File Juicerから抽出してテキストをたとえば、DreamWeaverにコピペをすると、濁点・半濁点などが１文字としてペーストされることがある。
なわけで、毎回 Cot Editor（この変換してくれるエディタはこれくらいだった）で UNICODE正規化ってのをやってからコピペしている。
お客様よりPDFで入稿がありました．
文書のプロパティでは
作成アプリは空欄
作成OSはMacOS 10
フォントは全て埋め込みサブセットとなっていますが
フォント名が
font 98640 など他の書体も同様で数字が変わっているだけ
TypeはTrueType
となっております．
テキスト選択をしてエディターにコピペしてもすべて文字化けしています．
どなたかテキストを取り出す方法をご存知の方，
いらっしゃいましたらお願い致します．
原因：これらの制限は、Mac OS X の PostScript ドライバが 2 バイトフォントを 1 バイトフォントに分割することにより、生じています。この問題は、Mac OS X に起因するものであり、Acrobat によるものではありません。
解決法
A. PDF ファイルの作成が可能なアプリケーションで PDF に変換します
この問題を回避するには、InDesign CS/CS2 または Illustrator CS/CS2 などの Acrobat Distiller を使用せずに直接 PDF を作成することが可能なアプリケーションで PDF に変換を行います。これにより、Mac OS X の PostScript ドライバを経由しないため、正しい文字情報で PDF に変換することが可能です。
Q14. 特定のTrueTypeフォントをエンベットできない。
この問題のほとんどの原因はフォントの著作権保護の制限によるものです。TrueTypeフォントは、内部で使用条件を設定することができます。その中には、ファイルへのエンベットを禁止する項目があります。
回避策としては、ライセンス制限のないバージョンのフォントを購入するか別のフォントを使用します。
先日、OSAKAと平成明朝だけで作られたイラレ張り込み有りの本文同じく平成明朝のQX3.3データが入稿しました。今迄ならトンでもデータなのですが、PDF でフォントエンベットして面付け出力致しました。PDFを積極的に出力方面で運用すると、TrueType FontをDTPにもっと有効に使えるように思います。
PIJの井上です。
Dynafontを供給しているDynaLabでは、現時点でTTフォントのPDFへの埋め込みを許可していないという情報しか私はもっておりません。結局この話はベンダーへ直接問い合わせていただくしかありません。その方がベンダーへも情報が入るという意味で有益だとおもいます。
2バイトフォントは、いろいろな方法で一見埋め込まれているという状態をつくることができます。先ほどメールであったように T1とかいうのもその一例です。これらはこれらは印刷や画面表示はうまくいく場合がありますが、きちんとした埋め込みではありません。Adobeが正式に埋め込みした状態であるとしている方法を実現するには、フォントのグリフがPSかTT（Type42）形式で組み込まれていること、エンコーディングが維持されていることが条件（つまり検索やコピー＆ペーストがきちんとできる）です。そのためには、フォントに埋め込み許可フラグが許可になっているか、 Acrobatにあるフォントデータベースに許可フォントとなっていることが必要です。MSゴシックやMS明朝は後者の例です。
欧文のフォント（1バイトのPS、TT）については、いずれも埋め込みが出来ますが、Acrobatのマニュアルにあるように、フォントベンダーが許可しているかどうかは直接ベンダーに問い合わせるしか方法がありません。つまり、許可していないフォントを埋め込んだ場合、違法な埋め込みが行われる（どんな法律に従っているかは別として）可能性があります。もちろん、和文フォントも同様です。フォントベンダーが埋め込みしていいといっているフォントしか埋め込んではいけないという認識が必要です。特に企業などが埋め込みを実施する場合は、それなりの調査を行い、使用フォントを絞る必要があるのではないでしょうか。
最近同様のご質問をいただきましたので、あらためて投稿させていただきました。
いつも参考にさせていただいてます。
MACOS10.4.10、InDesign4.0.5を使用しています。
今回、中国語を使う仕事がありました。
書体は元々OS10.4に付属していたもの（ライブラリーのフォントフォルダの中）で、STSong-regularを使用したのですが、InDesignのフォント検索の制限の所に「PDFに埋め込みできません」と出ていまして、実際にやってみましたが、やはりPDFに出来ませんでした。別の中国語のフォントでも、同じく制限がかかっていました。中国語のフォントに関しては、全て制限がかかっているみたいです。
この書体をPDFに埋め込むのは、完全に無理なのでしょうか？ 何かウラ技とか、あるのでしょうか。
あと方法としては、中国語のフォントを新たに買うとかしかないのでしょうか。
中国語の部分はそれ程は多くないので（20～30行くらいか）、InDesign上で、文字をグラフィックス化する方法とかも考えましたが、文字が太るとかの問題が考えられます。
何かご存知の方がいましたら、よろしくお願いします。
解決法：http://support.adobe.co.jp/faq/qadoc/spitz.nsf/1da99db8dc3aad9a492569fa002947de/ef82f9f88a0001474925703c002ae201?OpenDocument
【InDesign CS2】
何も選択していない状態で文字パレットを開き、オプションを表示（プルダウン）させると「合字機能」にチェックが入っているので、これを解除する。
【Illustrator CS2】
何も選択していない状態で文字パレットを開き、「OpenType」のタブをクリック。下のほうにfとiを組み合わせたような合字のアイコンがあり、それがONになっているのでクリックしてOFFにする。
http://mtlab.ecn.fpu.ac.jp/WSM_2001/010710145210.htmlより
随分と昔に、ルーターマシン（と呼んでおりました。）を何台か立てて、それらのルーターマシンにルーティングさせるソフトウエア（Apple純正だったと思うのですが、記憶が曖昧です。）をインストール、セットアップし、常にそれらのマシン、ソフトウエアを起動させたままでいたと思うのです。（当時はLocalTalkを張り巡らせて環境にゾーンを幾つか取っておりました。）
【回答】
現在アップルトークのゾーンをするにはUNIXサーバ＋Netatalkがよろしいでしょう。これ以外の選択肢は、現在ないんじゃないかな。
もう１つ思い出しました。Windows NT Serverでも可能でしょう。
マッキントッシュオプションを入れるとゾーンの指定ができます。
参考：http://www.adpico.co.jp/ac/jtwx/jtwx_00001.html
http://mtlab.ecn.fpu.ac.jp/WSM_2002/020626151727.htmlより
色々と探し回ったところ、結局アップルサポートページで、こんなのを見つけました。
これって、OSXに２枚のNICを挿してAppleTalkのルーターにするっていう事なんですか？
そうだとすれば、ファイルサーバーをOSXにする事で、両方から見られるAppleTalkのネットワークが完成するかもしれませんね。
Illustrator CS3に同じように、「グレー40％」濃度の画像やPDFを貼り込んで、プリンタから出力してみました。
IllustratorとInDesignは、CSのバージョンが同じです。Adobe Color Engineのバージョンも同じです。ということは、同じようにカラー変換されるということでしようか。実際にプリントして試してみましょう。
Illustrator CS3からカラーマネージメント出力するには、プリントウィンドウにある［カラーマネージメント］を設定してプリントアウトします。［カラーマネージメント］の［カラーの処理］で「Illustratorのカラー設定」を割り当てます。［プロファイル］にはプリンタプロファイルを適用します。
Illustratorのカラー設定は「プリプレス - 日本2」を割り当てていますので、カラーは「Japan Color 2001 Coated」からプリンタプロファイルに変換されます。IllustratorではCMYKからCMYKにカラー変換するためには、
CMYKカラー値を保持
のチェックボックスをオフにします。ここをオンにしてプリントすると、「グレー40％」はそのままグレースケールの40％のまま出力されます。
［プリンタ］で「PostScriptファイル」を選択し、［PPD］で「その他（AdobePDF 8.0J）」を選択しています。カラー処理をIllustratorで行い、プリンタのプロファイルを割り当てています。Illustratorでは［CMYKカラー値を保持］をチェックすると、CMYK to CMYK変換できません。
satoski- 2007年1月31日 07:04 (#3 of 8)
Illustrator CS2のEPSから完全にオーバープリントを除くことはできます。
EPS Options > Transparency > OverprintsポップアップリストでDiscardを選ぶと、EPSファイルのPostScript部分のOPを完全に取り除きます。その際、Illustrator編集データ部分のOPは保持されます。
つまり、このEPSをIllustrator CS2でオープンするとOPは残っていますが、他のドキュメントに配置して印刷するとOPは除かれています。
satoski- 2007年1月31日 13:34 (#5 of 8)
『透明』の設定をしていないオブジェクトに対しても有効なのでしょうか？
有効です。「透明」のところにありますが、実はEPSのOPは「透明」とは関係がありません。他のダイアログ等で「透明」と一緒に扱われることが多いので、そこにあるだけだと思います。
他のドキュメントとは…Illustratorの別のドキュメントのことでしょうか？それとも、Illustrator以外のアプリケーションと言うことでしょうか？
両方です。
Version 9以降のIllustrator EPSは二重構造になっていて、PostScript部分とIllustrator編集データ部分を含みます。EPS Optionsで設定するのはPostScript部分の構成です。OPの破棄を指定した場合、PostScript部分のOPが破棄されますが、Illustrator部分には影響しません。
Illustrator編集データはIllustratorでのみ利用可能です。Illustratorでファイルを開くと、PostScript部分を読み飛ばし、Illustrator編集データのみが読み込まれます。したがって、EPS OptionsでOPの破棄を指定していても、そのIllustrator EPSをIllustratorで「開く」とOPは保持されています。
Illustratorの新規書類にIllustrator EPSを配置すると、Illustrator編集データを読み飛ばし、PostScript部分のみが読み込まれます。Illustrator以外のアプリケーションでIllustrator EPSを配置しても同様です。Illustrator EPSのPostScript部分のみが利用されます。したがって、OPの破棄を指定して保存したIllustrator EPSをIllustratorや他のアプリで配置して印刷すると、EPS内のOPは破棄されています。
Illustratorからアートワークを印刷するときにもOPの破棄は指定できますが、そのアートワークが配置されたEPSを含む場合、EPS内部のOPには影響しません（例外はあります。そのEPSが「透明」と関わっている場合など）。
satoski- 2007年1月31日 18:27 (#7 of 8)
どういたしまして。
でも、オーバープリント適用・解除が期待通りに動作しないことのほうが問題ですよね。適用も解除もきっちり指定した％の塗りにしか作用しないようなので、使い勝手が悪いです。このフィルタを使ってK=100%以外の塗りにオーバープリントの適用・解除を繰り返すのは、あまり実用的ではないかと思います。かと言って、CS2だとSelect AllするとAttribute PaletteのOverprint Fillが不能の場合があるし、まずいですね。
残念ながら入力方法が切り替わるまさにその瞬間は目撃したことがないのですが、おそらく意識せずに切り替え操作をキーボードで行ってしまっているのだと思います。
▼操作方法：日本語入力方法を切り替える
［Alt］キー＋［カタカナひらがな］キーを押す
入力方法の切り替えはいくつか操作方法がありますが、おそらく上記の操作をしてしまっているのでしょう。日本語入力がOnの状態で、［Ａｌｔ］＋［カタカナひらがな］キーを押すたびにローマ字入力とかな入力とが切り替わります。
ちなみにこの［Alt］キーと［カタカナひらがな］キーを押すタイミングが、デリケートな場合もあるようです。
通常ショートカットキーは一方のキーを押した状態から他のキーを押すという操作をしてらっしゃる方が多いと思いますが、［Alt］キーを押しっぱなしにしておいて［カタカナひらがな］キーを押しても入力方法が切り替わらないときは、［Alt］キーと［カタカナひらがな］キーを同時に押してみてください。
ただし、同時に押せば100%切り替わると断言できないところが歯がゆいところで、同時に押して切り替わらないときは［Alt］キーを押しっぱなしにしておいてから［カタカナひらがな］キーを押してみてください。
もう一つ入力方法が切り替わる可能性はIMEツールバーです。
▼操作方法：日本語入力方法を切り替える
IMEツールバーの［KANA］ボタンをクリック
［KANA］ボタンはIMEツールバーの右の方に小さく表示されているので、［Alt］＋［カタカナひらがな］キーより可能性は低いでしょうが、何かの拍子にクリックしてしまったという方もいらっしゃるかもしれません。
IMEツールバーの［KANA］ボタンがOnの状態でかな入力、Offの状態でローマ字入力です。
入力方法を切り替える方法は他にもあります。
▼操作手順：日本語入力方法を切り替える
日本語入力がOnの状態で［Ctrl］キー＋［F10］キーを押す
↓
ショートカットメニューから［プロパティ］を選択
↓
［Microsoft IME スタンダードのプロパティ］ダイアログ－［全般］タブをクリック
↓
［入力設定］欄－［ローマ字入力/かな入力］欄から、
「ローマ字入力」「かな入力」いずれかを選択
↓
［Microsoft IME スタンダードのプロパティ］ダイアログ－［OK］ボタンをクリック
入力方法が変更されてしまった場合は上記いずれかの方法で直してください。
Mac OS Xでは、ファイルシステムでUnicodeが用いられています。いわゆるUTF-8なのですが、一般に言うところのUTF-8とは違います。 Macをお持ちの方は、「iconv -l」とTerminalからコマンドを実行してみてください。「UTF-8-MAC」という表示が見つかるかと思います。
一般的なUTF-8では、文字はNormalization Form C（NFC）で 符号化正規化されています。しかし、Mac OS Xのファイルシステムで用いられているUTF-8 （以下、便宜的にUTF-8-MACと呼びます）では、文字はNormalization Form D（NFD）で符号化正規化されます。日本語を扱う際にNFCとNFDでどこが違うかというと、ひらがな・カタカナの濁点・半濁点の扱いです。 UTF-8では「が」は「U+304C」（HIRAGANA LETTER GA）ですが、 UTF-8-MACでは「U+304B U+3099」（HIRAGANA LETTER KA、COMBINING KATAKANA-HIRAGANA VOICED SOUND MARK）となります。
（中略）
しかもややこしいことに、UTF-8で濁点をあらわすコードは「U+309B」（KATAKANA-HIRAGANA VOICED SOUND MARK）で、 UTF-8-MACから送信される「U+3099」（COMBINING KATAKANA-HIRAGANA VOICED SOUND MARK）とは別物です。サーバ側できちんと変換できればよいのですが、 PHPのmbstringモジュールはUTF-8-MACをサポートしていません。（Javaの場合、Java SE 6から導入された java.text.Normalizerクラス を使えば一発で変換できますね。）
また、Mac上で動作する他のブラウザの挙動を調査したところ（「サンバの季節」というファイルをタイトルを変更せずにアップロードした場合）、それぞれの挙動が異なることがわかりました。
ブラウザ フォーム上のタイトル表記 登録されたタイトル
Safari サンバの季節 サンハ
Firefox サンバの季節 サンバの季節
Opera サンハ゛の季節 サンハ
Firefoxは内部的に変換処理を行うようになっているようです。問題はSafariとOperaですね。選択されたファイルのパスからJavaScriptでファイル名を抜き出してタイトルに設定する部分で、正しく扱えるような文字コードに変換することにしたいと思います。
基本的な流れとしては、UTF-8-MAC特有の「U+3099」（COMBINING KATAKANA-HIRAGANA VOICED SOUND MARK）、「U+309A」（COMBINING KATAKANA-HIRAGANA SEMI-VOICED SOUND MARK）がファイル名に含まれている場合は、その前の文字と結合して濁音・半濁音の文字にしてあげればいいでしょう（ひらがな・カタカナのみの暫定的な対処に過ぎませんが）。
何のことを言っているか分からない人のために。
Unicode では、濁音/半濁音/アクセント記号(ウムラウト等)がついた文字を合成文字1文字(ガ(U+30AC))で表すことも、基底文字 + 結合文字(カ(U+30AB) + ゛(U+3099))で表すこともできる。前者の方法で正規化したものを NFC(Normalization Form Composition)、後者で正規化したものを NFD(Normalization Form Decomposition)という。他にも NFKC と NKFD があるが略。これは文字の表現形式の話で、エンコーディングとは違うレイヤの問題なんだけども、非 Unicode のエンコーディングには結合文字というのがないのが普通なので、NFD のままだとエンコーディングの変換に失敗したりする。
でまぁ、普通に入力するとたいてい NFC になっているので問題にならないが、Mac OS X のファイルシステムはファイル名を NFD で格納するので、Mac OS X のファイルを扱うと問題になったりするわけだ。Mac OS X も普通に入力したテキスト自体は NFC になっている。
Mac OS XからFinderで簡単にzipファイルを作れるようになりました。しかし、保存されるファイル名の文字コードがユニコードらしくてWindowsで解凍すると日本語ファイル名が文字化けしてしまいます。
これを解決する方法がここ、これに書いてあって試した所日本語でもちゃんと文字化けしなくて解凍できるzipができました。ただ手順が手作業でやるには面倒なのでこれを自動でやるAppleScriptを作ってみました。
■[excel] Firefoxやダブルクリックで開けなくなった
Firefoxから直接Excelファイルを開くとエラー、IEからも同様なので、どうもブラウザの問題ではなさげ。
おまけにFinder上でhoge.xlsをダブルクリックしてもExcelは起動するがファイルは開かない。
調べたら、「ツール／オプション／全般、他のアプリケーションを無視する」で直った、ガックシ。
先日、バランスのよさ気なグラデーションの比率を考えていたところ、以前このブログでご紹介しました、『身近にちらばる黄金比のデザイン』を思い出しました・・・
グラデーションの比率を黄金比（1：1.618...）に設定してみたら、しっくりくるかな？っと思いまして。。。
実際に試してみたところ、結構いい感じだったのでご紹介。。
上部から中央に、中央から下部に垂直にグラデーションを2段階に分けてかけてみました。で、上部と下部のグラデーションの比率を黄金比に設定してみました。。（といっても、38%と62%と大雑把ですが・・・）
ではCMYKの場合はどうなのでしょうか？CMYKのデータとは、すでに印刷条件に合わせたプロファイルによって分解されたデータということになります。つまりCMYKのデータとは、その印刷条件で印刷する上では、すでに正しいデータなのです。正しいデータであるので、この後変換をする必要がなく、プロファイルも必要ないわけです。というのは建前として、CMYKデータにプロファイルを埋め込んだ場合、もっと深刻な問題が生じます。データを受け取った側がプロファイルの扱いに慣れていればよいのでしょうが、そうでない場合CMYK → CMYKの変換をしてしまうと大変です。
話を単純にするために、Aとういプロファイルが埋め込まれた、CMYがすべて0％でKが100％のいわゆるスミベタのデータがあるとしましょう。これを別のCMYKプロファイルに変換したとしたらどうなると思いますか？実はこのような処理をすると見かけは似たような黒であっても、CMYKにすべてデータが乗った見かけ上の黒に変わってしまうのです。カラーマネージメントによる色変換はLabカラーを基準とします。そのため、実際にはCMYK → (Lab) → CMYK となり、いったんLabモードに変わったデータを再度CMYKで色を作り直すために、CMYKすべての版にデータが乗ってしまうのです。
これは黒だけの問題ではなく、グレーもそうですし、もちろん赤や青といったすべての色が再構築されてしまいます。RGBの場合もlabを仲介しますから、もちろん色が再構築されているわけですが、わずかのずれはRGBがそれほど気になりません。しかし、CMYKの場合、特にKで表現される黒やグレーといった色がCMYKすべての版で表現されると、色の見え方が変わってきてしまいます。また、Photoshopに直接関係ないかもしれませんが、InDeisgnやIllustratorでヌキやスミノセの指定をした場合、期待通りに仕上がらなくなってしまいます。
2次B-スプライン曲線は2次式となっていますが、ベジェ曲線は3次式となっています。
そのため、ベジェ曲線の方が複雑な曲線を表現できますが、処理に時間がかかります。
曲線を定義するためには、端点の間に、2次B-スプライン曲線は１点（オフカーブ点）あればよいですが、ベジェ曲線は２点（方向点）必要です。そのため、簡単な曲線では、ベジェ曲線の方が制御点は多く必要となります。
2次B-スプライン曲線で複雑な曲線を表現しようとすると、1つの曲線を短くしなければならないため、制御点は多くなります。
一概にどちらが優れているとはいえません。
「TTEdit」「OTEdit」など、数々のフォント関連ソフトをリリースされてる武蔵システムさんのサイトから引用。勿論、情報の正確さは言わずもがな。
表現する曲線によって制御点が多くなる＝データ量が多くなってしまう、という点ではスプライン曲線のほうが不利というのはあるんですが、それは曲線のクオリティとはまた別なので、そこを同じに語るとちょっと辛いモノがありますよ。
……という話。
そもそも「TrueType＝出力に使えない」という神話自体が、TrueTypeの出力に制限をかけていた旧MacOS時代の問題によるものが大きいのだけれども、未だに誤解してる人が多いのは困ったもんです。
Photoshop 6以上で、
ファイル＞読み込み＞PDF画像
そのなかで、一番感激していただいたのが、
Ｂ３くらいの手書きの絵をＡ４スキャナーで6分割してスキャンし、
フォトショップ上で力業で繋いでおられましたが、
上手く行かず断念され、仕方なく外注に出されました。
で、
なんか良い方法はありますか？
と言う質問。
勿論ですよ！(#^.^#)
そのスキャンしたファイルは未だありますか？
あったので、
ＣＳ２のフォトショップ（一本だけありました）で
自動処理のPhotomerge。
ファイルを選択してオーケーで終了。
僅か数秒で出来上がり。
ブログの画像からカメラ携帯の機種を調べてみるというエントリーより。
某チャンネルで「ブログにのってる写真のEXIFをみれば使ってる携帯機種わかるね」という感じで盛り上がったので、さくっとスクリプトかいてみました。みやーんことmiyagawa氏がブログに埋め込まれているJPEGのEXIFデータから、メーカー、機種名を抽出するためのスクリプト「What cameraphone do they use?」をさくっと書いていました。
実は、『MicrosoftOffice for Mac』には許容しがたいバグがあって、
クラシック環境（MacOS9）で使用していた一部の欧文フォントに対応していません。
これは、正直辛いです。
MacOSXでもパンサー（10.3）であれば、
エラーを出しながらでも無理矢理起動するんですが、
タイガー（10.4）になるとフォントをはずさないと起動すらしません。
外部入稿データが多く、
原稿が『MicrosoftOffice』データであることが圧倒的なだけに、
ＤＴＰのソフトと同時起動は避けては通れない道となっています（ウチだけかもしれませんが）。
というわけで、『MicrosoftOffice』データも開くことができ、
しかも、フォントの規制がない『NeoOffice』は重宝するというわけです。
さらに、個人的には、昨今クライアントから入る訳のわからない入稿形態の類、
『MicrosoftOffice』の書類に貼りついた写真原稿（笑）。
これも先日紹介した裏技。
ＯＤＦフォーマットで保存し、解凍ソフトで展開することにより、
劣化の全くない画像データ抜き出しができるメリットもあります。
あとは、Photoshopで開いて、リサイズして補正すればいいわけです。
以前は、『MicrosoftOffice』の書類に貼りついた写真原稿に本当に苦労させられたので、
これを思いついたときはあちこちで同じことを連呼しちゃったもんです（バカ）。
▼ 三項演算
・上記までに説明された、二項演算子、単項演算子の書式を記憶出来れば、残りのただ一つの例外を除いて演算子の意味を調べるだけで記述する事が出来る。だけどperlには一つだけ三項演算子があり、演算子っぽくないような複雑な処理を実現する。この演算子は「A」をブール値で評価した後、真だったならば「B」を評価して返す。偽だったら「C」を評価して返す。
$scalar = A ? B : C;
・実際には以下のように書く。
$scalar = $a ? $b : $c;
・上記の処理をif文を用いて表現すると以下のようになる。 if文に関しては [07/08.条件分岐] を参照。
if($a){
$scalar = $b;
}else{
$scalar = $c;
}
ココログのお客様から、ココログ出版に申し込みをいただいて、書籍をお届けするまでの大まかな流れは次のとおりです。
1. サービス提供会社であるニフティ様から該当のブログの申し込み指定期間分のXMLデータを受け取る。
2. 1.のデータをXSLFormatterで組版しPDF出力をする。
3. PDFをお客さまにご確認頂く。
4. OKが出れば、PDFを印刷し、製本・発送する。
あさひ高速印刷株式会社は、ブログ出版を開始する以前から、印刷会社としてxmlを何かに活用できるのではないかと考えていました。
そこへ、ブログのソースがXMLで記述されているということに目をつけ、かつ、XSLFormatterはPDF作成が容易でかつ高速であるということが、選定の大きな理由です。
最近知ったんですが、生年月日から年齢を計算する簡単な計算式というのがあるそうです。
(今日の日付-誕生日)/10000の小数点以下切捨て。
PHPで書くと
echo (int)((20070823 - 19850101)/10000);
Perlで書くと
print int ((20070823 - 19850101)/10000);
JAVAで書くと
System.out.println( (int)((20070823 - 19850101)/10000) );
という感じになります。
PDFに半透明の画像や透かしをつけると、本文の文字が太く表示されたり、カラーがくすんだりします。
この問題はAcrobat7/8（だけかどうか定かではありませんが）の表示の問題ですが、弊社の製品サポートによく質問が寄せられます。先週は1週間で2回もその手の問題がサポートに報告されました。
XSL FormatterでPDFを作成している客先から、PDFをAdobe Readerで表示すると、一部のページの文字が濃く表示されるというクレームがありました。これは、そのページにαプレーン(透明）がついたPNGがあるため、そのページの文字が他のページの文字よりも濃く表示されてしまいます。同じ現象をAcrobatで半透明の透かしを埋め込むことでも再現させることができます。
下の画像をご覧ください。これはPDFのページに「Acrobatで不透明度50%の透かしをつけたページ」と「すかしのないページ」をAcrobat8で表示して比較したものです。
オリジナルPDFはこちらです：ファイルをダウンロード
文字が太くなるだけではありません。
半透明の透かしを付けると、カラーもくすんでしまいます。
カラーの場合は、色にもよりますが、かなり激しくくすんでしまう色があります。下記の図をご覧ください。これは、1ページ目は透かしなし、2ページ目は1ページ目に不透明度50%の透かしを付加したものです。透かしの付加処理は、Acrobat 8.1 Professionalで行ったものです。わざとかなりくすみの激しい色を選んでみました。
オリジナルPDFはこちらです：ファイルをダウンロード
そんなわけで、不透明の色が付加されますとAcrobat8の表示が影響を受けてしまうのは、弊社の製品の問題ではなく、Adobeの責任なのです。
印刷は用紙の同じ位置に刷ります。
薄い紙だと、数百枚まとめて断裁するので
同じ位置でないと問題ですね。
その紙の位置を決めるのに
印刷機には前アテ二つと針一つが付いており、
この３点で一枚一枚位置合わせをします。
最近の印刷機はこのアテや針にはセンサーが付いており、
少しでもずれるとブザーが鳴ります。
鳴らないと言うことはずれていないと言うことですので、
問題なく印刷が出来でいることになります。
ところが、ずれていても鳴らないこともあります。
機械を過信してしまい、確認しないで次の行程に廻して気がつきました。
アテがずれていました。(..;)
ブザーが鳴っていないから大丈夫と言うことはありません。
Adobe Illustrator 7.x 以降のバージョンで
[保存]コマンドを使用した直後に[取り消し]コマンドを使うと、次に[保存]コマンドを使ったときに修正内容が保存されません。
Ctrl+S キー（Win）／Command+S キー（Mac）を押しても何も起こらず、また[保存]コマンドの表示が暗くなって選択することができません。
(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 検索するにしても、それぞれは異なる文字コードだから、別々に検索し直す必要がある。つまり、上記の４通りで、４回も検索する必要がある。検索時間が４倍になる。バカバカしいとしか言いようがない。
また、前にも述べたが、ファイル名を unicode にすると、古いＯＳ（Windows98など）ではファイルを扱えなくなる。ファイル内容を読み取ることもできないし、ファイルを開くことすらできなくなる。
また、HTMLファイルを書くときは、ソースで文字コードの指定を正しく指定する必要が出てくる。間違った文字コードを指定すると、HTML文書全体が読み取れなくなる、ということがある。特に、UTF-8 しかサポートしていないソフトで、JIS第３水準・第４水準の難読文字を入力すると、まったく漢字を扱えなくなる、という問題が生じることもある。
また、そもそもの話、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 にすれば、双方の文字エンコードが異なるので、いっしょに扱うのに不便だ。
