- pdftkPDFファイルのページを操作する
- pdf2psPDFファイルをPSに変換する
- ghostscriptPostScript全般
メモ：PDF関連のスクリプトなど
返信
「PostScript」カテゴリーアーカイブ
ImageMagickでEPSに変換したファイルをIllustrator CS5で開くとフリーズする問題
ImageMagickのconvertコマンドでJPEG形式の画像ファイルををEPSファイルに変換したものを、Illustrator（イラストレータ） CS5で開くと、CS5が固まる問題を調査しました。
この現象を確認したのは、CentOS上で変換したJEPGファイルです。
昔はこんなことは無かった気がしますが、いつの間にかこの問題が発生していたので調査しました。
開発環境：
Windows7(64bit)
mageMagick 6.8.3-0 2013-02-13 Q16
Illustrator CS5
本番環境：
CentOS Linux 5.11
ImageMagick 6.2.8 05/07/12 Q16
CentOS上のImageMagickでJPEGファイルをEPSファイルにconvertしたものをイラレCS5で開くとイラレが固まって強制終了するしかなくなります。
単純に変換するときのコマンドです。
convert a.jpg a.eps
環境それぞれで生成されたEPSファイルを比較しました。
本番環境で生成したファイルにはヘッダ情報に
%begin_xml_code
<?xpacket begin="" id="W5M0MpCehiHzreSzNTczkc9d"?> <x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 5.0-c061 64.140949, 2010/12/07-10:57:01 "> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <rdf:Description rdf:about="" xmlns:xmpMM="http://ns.adobe.com/xap/1.0/mm/" xmlns:stRef="http://ns.adobe.com/xap/1.0/sType/ResourceRef#" xmlns:xmp="http://ns.adobe.com/xap/1.0/" xmpMM:OriginalDocumentID="xmp.did:A379835BBF2068118A6DF5258C3E39CC" xmpMM:DocumentID="xmp.did:660D7D5C2F0F11E3A9DB9D247D1C6687" xmpMM:InstanceID="xmp.iid:660D7D5B2F0F11E3A9DB9D247D1C6687" xmp:CreatorTool="Adobe Photoshop CS5.1 Macintosh"> <xmpMM:DerivedFrom stRef:instanceID="xmp.iid:A56F4D9AC92068118A6DF5258C3E39CC" stRef:documentID="xmp.did:A379835BBF2068118A6DF5258C3E39CC"/> </rdf:Description> </rdf:RDF> </x:xmpmeta> <?xpacket end="r"?>
%end_xml_codeというものが追加されていました。
MACのフォトショCS5.1で保存されたとの記載を確認できます。
簡単に言うとファイル情報ですね。
これを削除するとイラレは固まらずにファイルを開けます。
よ～くソースを見ると、
「%begin_xml_code」と「%end_xml_code」に挟まれた行、XMLで言うところの「<?xpacket />」がベタで書かれていました。
この行、ソースとしてはベタで書かれていてちょっと引っかかったので、行をコメントアウト、つまり先頭に「%」を追加すると、イラレで固まらなくなりました。
XMLをPostScriptにベタで書いているので構文エラーで固まっていたようです。
PostScriptにはヒアドキュメントはなかった気がするので、stremaとしてデータとして埋め込むか、1行ずつコメントアウトしてやらないとだめなのでしょう。
XML情報は特に必要がないので、除去するオプション「-strip」を追加してconvertしてみます。
convert a.jpg -strip a.eps
これでファイル情報が格納されなくなり、イラレで無事開けるようになりました。
ファイル情報が埋め込まれるかどうかはコンパイル時のスイッチ設定だとは思うのですが、そこまでガッツリ調べるのが面倒なので、回避方法を確認したところで良しとします。
でめたしでめたし。
TCPDFで縦書きテキストをフォント埋め込みに対応させる
TCPDFで縦書きを実現するには、フォント設定ファイルの書き換えで実現するのが一般的です。
※ IPA明朝の場合
$type = 'cidfont0';
$dw = 1000;
$enc = 'UniJIS-UFT16-V';
$diff='';
//$file='ipam.z';
//$ctg='ipam.ctg.z';
$cidinfo=array('Registry'=>'Adobe', 'Ordering'=>'Japan1','Supplement'=>5);
include(dirname(__FILE__).'/uni2cid_aj16.php');
この方法ではAdobe ReaderまたはAdobe Acrobatでは、PostScriptで印刷ができません。
「文章を印刷できません。」
「印刷するページが選択されていません。」
と表示されて出力できません。
画像として印刷することはできますが、今一つな感じです。
Illustratorに読み込ませればアウトライン化されるので印刷に使用できるようになりますが、
ページが複数ある場合は現実的ではありません。
ちなみに、「Foxit」ではPostScriptのままで出力できるので、こちらを使用するのも手です。
要は、TCPDFで縦書きテキストを生成する際に指定するCIDフォントは非埋め込みであり、
これがPostScriptで印刷する場合に問題となるというわけです。
では、埋め込んで縦書きを実現してみる方法を探してみましょう。
まず、TCPDFの標準エンコードは「Identity-H」です。
この形式でないとフォントを埋め込めないというか、フォント埋め込み用の独自エンコードかもしれません。
PostScriptを弄っている人なら、末尾の「-H」が気になりますね。
これを変更するには、本体の「tcpdf.php」ファイルを書き換える必要があります。
メソッド「AddFont」に
} elseif ($type == 'TrueTypeUnicode') {
$enc = 'Identity-H';
というコードがあるので、「’Identity-V’」に書き換えてみましょう。
すると、なんということでしょう。
テキストが縦書きになりました。
もちろん、フォント設定ファイルは何も弄りません。
ただし、フォントは埋め込みの状態にしておきます。
非埋め込みでは化けます。
しかしよく見ると括弧やハイフンなどが横書き用のままです。
CIDフォントでは「uni2cid_aj16.php」をincludeすることでマッピングを変更しているのですが、
Identityでマッピングをしているところがまだよくわかりません。
おそらく、これを調整でいれば完全な縦書きを実現できるはずです。
もし参考頂き、対応方法を見つけられましたらご一報いただければ幸いです。
また、余裕があれば調査します。
IllustratorやInkscapeもいいけれど、ブラウザでデザインしてみない？
Illustratorのような高価なアプリにはかないません。
Inkscapeのような自由なアプリにはかないません。
だけど、ブラウザ上でちょこちょこっと弄るだけで印刷の注文ができたら良いですよね？
ということで、少し前からですがプリントライで公開しています。
印刷用レイアウト編集クラウド、Printing Layout Editor Cloud、略してPLEC。プレクとでも呼びましょうか。しっくりきませんが。
フォントの都合上少しバランスがおかしかったりしてます。
でも縦書きのようなこともできます。
自分の持ってる画像をアップロードすればデザインに使えます。
使い勝手はラベル屋さんを参考にしてあります。
データを保存すると、印刷用のPostScriptでファイルを作りますので、IllustratorやInkscapeで作ったのものと同じになります。
保存したレイアウトを公開する機能もあるので、素材やキャラクターを使用ごとに課金などもできるといいですね。
例によって、レビューしてもらえれば名刺100枚を無料でお作りします。
この記事では、期限を2013年4月中とします。
twitterなどで、お気軽に声をかけてくださいね。
TCPDFでOTFフォントを使用する
PHPでPDFを扱うためのライブラリにTCPDFがあります。
TCPDFでOTFフォントを使用すると、AcrobatReaderでは正常に読めても、Illustratorで正常に読めず、テキストがラスタライズされて少々気持ちの悪い事態に遭遇することとなります。
Illutratorで開くことを想定しているなら、TCPDFで扱うフォントには少々の工夫が必要なので、ここに残しておきます。
まず、TCPDFで扱うフォントはTTFフォントで統一します。フォント名が同じであればTTFで作成したPDFでも、OTFフォントがインストールされた環境のIllustratorでも問題なく読むことが出来ます。
OTFフォントをTTFフォントに変換するにはFontForgeを使用します。
インストール方法を検索すると、Windowsのcygwin環境下でのインストール方法が沢山ヒットしますが、個人的にはうまくいかなかったので、LinuxのCentOS5を使用しました。アプリケーションはGUIでx11環境が必要なので、デスクトップ版を用意しましょう。
パッケージはhttp://sourceforge.net/projects/fontforge/files/fontforge-executables/から「fontforge-20090923-1.i386.rpm」をダウンロードします。少々古いものですが、特に問題ありません。ダウンロードが終わると、ファイルをダブルクリックするだけでインストールが始まり、あっさりと完了します。
アプリケーションはGUIなのですが、メニューには登録されませんのでファイルを直接起動するか、ターミナルから起動する必要があります。ターミナルで「fontforge」と入力して起動すると、読み込むファイルを要求されるのでTTFフォントに変換したいOTFフォントを選択します。
選択したOTFファイルの内容によってはCIDマップファイルが必要と言われるかもしれません。CIDマップファイルはhttp://fontforge.sourceforge.net/cidmaps.tgzにありますので、ダウンロードして展開したファイルを「/usr/share/fontforge/」にコピーします。
しばらくして読み込みが完了すると文字コード表が表示されるので、メニューより「CID＞単一化」を選択してファイルを統合します。
そしてメニューより「ファイル＞フォントを保存」を選択して、保存形式を「TrueType」に設定し、保存ファイル名を入力して保存すれば完了です。
これで変換作業は完了です。作成されたTTFファイルを開いて正常に読み込むことができれば成功です。
フォントファイルをTCPDFで扱える状態にする方法は、ライブラリ内のtcpdf/fonts/utils/README.TXTにある通りで問題ありません。むしろ他に方法がありません。
「$ ttf2ufm -a -F myfont.ttf」
「$ php -q makefont.php myfont.ttf myfont.ufm」
これで作成されたファイルをfontsディレクトリにコピーし、TCPDFよりPDFを作成すればAcrobatReaderでもIllustratorでも問題なく開くことが出来るPDFファイルの完成です。
いまいち文章が推敲されていないのでまとめます。
TCPDFはPDF作成ライブラリですごい
TCPDFのPDFはOTFフォントを使うとIllustratorでは読めない（ラスタライズされる）ことがある
TCPDFのPDFをＩｌｌｕｓｔｒａｔｏｒで読む可能性があるならOTFフォントをTTFフォントに変換しておく
OTFフォントをTTFフォントに変換するにはFontForgeを利用する
CIDマップがないとOTFファイルを展開できない（ことがあるかもしれない）
ActionScriptの記法（コーディングスタイル）に馴染めない
ActoinScriptをいじり始めて半年ぐらいになりますが、まだまだ記法に馴染めません。
特にイベントをいちいち追加しなければならないところなどもどかしく、ボタンなんてクリックするためにあるんだからクリックイベントのメソッドぐらい用意して置けよなんて思うわけです。
btn.addEventListener( MouseEvent.CLICK, btn_onClick );
function btn_onClick( e:MouseEvent ):void{
trace( e.target.name );
}
一般的なマニュアルではこうなっていますが、いちいち関数名を考える身にもなってくれと、どの道、このイベント以外からは参照しない処理だと、いちいち分けないといけない意味がわからないのです。
つまりこういうこと。
btn.addEventListener(
MouseEvent.CLICK,
function( e:MouseEvent ):void{ trace( e.target.name ); }
);
関数名の重複を怖がる必要はなくなりました。
JavaScriptが頭にあると、スクリプトは外部ファイルに置くべきという理屈から、いちいち関数を用意していたと思うのですが、パブリッシュが前提のActionScriptでは不要の作業。
よく考えればどうってこと無いのですが、解説サイトによっては「関数名の重複を避けるためにパッケージ化」しますなどと、むだな手間を掛けているのを見るとうんざり。
無名関数をもっと使いこなしたほうがいい気がします。
それに、処理速度とか、オブジェクト指向だとかそっちのけで、Perl使いとしてはこっちのほうが見やすいのです。
でめたしでめたし。
RGBをCMYKに変換する
結論から言うと失敗作というか、最小値と最大とのみを考慮して作られた式です。
はっきりいって使い物になりませんが、フリーソフトではつかっちゃっているようです。
動作確認用に作ったものなので、細かいエラーチェックは抜きです。
#===============================================================================
# RGB => CMYK（cmyが同じ値の場合kに割り振る）
#-------------------------------------------------------------------------------
sub rgb2cmyk {
my $rgb = shift;
$rgb =~ /^#?(..)(..)(..)$/;
my %color = (
'r' => hex( $1 ),
'g' => hex( $2 ),
'b' => hex( $3 ),
);
$color{'c'} = 1 - ( $color{'r'} / 255 );
$color{'m'} = 1 - ( $color{'g'} / 255 );
$color{'y'} = 1 - ( $color{'b'} / 255 );
$color{'k'} = 0;
if(
$color{'c'} == $color{'m'}
|| $color{'m'} == $color{'k'}
){
$color{'k'} = $color{'c'};
$color{'c'} = $color{'m'} = $color{'y'} = 0;
}
return %color;
}
結局、色を絞って変換テーブルを自作することになりましたけどね。
EPSファイルのリンク配置でつまづく
細かい構文は別の機会に。
EPSファイルを作るには、ImageMagickで画像をEPS化したものを、PerlのPostScript::Simpleでデータ毎埋め込んでいましたが、1つのデータでは特に問題がなくても、面付けまで自動的にやろうと思った場合、ファイルサイズがとんでもないことになってしまいます。
そこで、画像のEPSファイルをリンクで指定できれば面付けしてもファイルサイズはぜんぜん問題になりません。
そこで、いろいろ調べて見つけたものを試してみました。
しかし、GSViewでは問題なく表示されても、イラストレータで開けません。
いろいろ試してみると、ファイルパスの指定方法に問題があるとわかりました。厳密にいうと、イラストレータのファイルパスの扱いに問題があるのですが。
リンク先の画像EPSを特定の場所におこうとした場合、ドライブを含む、若しくはドライブ以下の絶対パスが必要です。
そのパスを指定したくない場合は、ドライブの直下に置けばいいことがわかりました。
つまり・・・
Cドライブの直下に置けば、
%%BeginDocument: image.eps (image.eps) run %%EndDocument
となります。
仮にC:/eps/に置くとすれば、
%%BeginDocument: image.eps (C://image.eps) run %%EndDocument
となります。
ファイルパスを指定するのは面倒なので、ドライブを1つつぶしてその直下に置いたほうが断然楽でしょう。
イラストレーターのEPSデータを考察
イラストレータといっても、手持ちのは古いままで7でのお話です。
EPSで保存すると、プレビューとサムネールを保存するかどうかの確認がありますが、これはいったいどのように格納されているかを調べてみました。
調べるといっても、サムネイルもプレビューも含まないで保存したEPSファイルと、サムネイルまたはプレビューを含んだEPSファイルを比較しただけです。
保存したファイル名と保存日時のデータは無視して、それ以外を比較します。
まず、サムネイルを含んだEPSファイルを比較しました。
違っていたのは、以下のとおりです。
46行目にある
%AI7_Thumbnail: 128 128 8
から
%%EndData
これが、サムネイルデータのようです。
バイナリが16進で格納されているようです。
どの画像形式かはわかりませんが、おそらくTIFFではないでしょうか。
次に、プレビューを含んだEPSファイルを比較しました。
違っていたのは、以下のとおりです。
1行目の先頭にバイナリデータが含まれています。
その後に通常のEPSデータが始まります。
%!PS-Adobe-3.0 EPSF-3.0
そして34行目に、
プレビューを含まないEPSファイルでは
%AI3_DocumentPreview: Header
となっているところが、
プレビューを含むEPSファイルでは
%AI3_DocumentPreview: PC_ColorTIFF
となっいます。
そして一番最後にまたバイナリデータが含まれています。
通常のEPSデータの末尾である
%%EOF
の後に、バイナリデータが追加されています。
他のイラストレータのバージョンでは、また違うかもしれません。
比較に使用したファイルをおいておきます。
サムネイルもプレビューも含まないEPSファイル
サムネイルを含むEPSファイル
プレビューを含むEPSファイル
イラレと同じ大きさの画像を作る
ImageMagickでEPSを背景なしのpngにする方法があったけど、やり方をすっかり忘れてしまったので、GostScriptにお願いすることに。
・イラストレータで見た大きさと同じ画像に変換するには「-r72」のおまじない
・背景を透明にするには「-sDEVICE=pngalpha」のおまじない
を唱えよう
gs -q -dSAFER -dNOPAUSE -dBATCH -sDEVICE=pngalpha -dEPSCrop -r72 -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -sOutputFile=output.png input.eps
Windowsの場合はgsではなくgswin32cになります。