ラベル DTP の投稿を表示しています。 すべての投稿を表示
ラベル DTP の投稿を表示しています。 すべての投稿を表示

2015年10月6日火曜日

FrameMakerスクリプトでFMObjectをTextFrameへ「キャスト」する

ニッチすぎて99.9999%の方には何言ってるか意味不明と思うが、スクリプティングガイドにもネット上にもまったく記述がなくあれこれ試行錯誤して2時間ほどハマったので吐き出したい。

FrameMaker 10のスクリプトで(whileループ内にいると思いねえ)、

2014年11月10日月曜日

InDesignスクリプトで配列要素オブジェクトを扱う際のハマり所

以下のInDesign CS3スクリプトのコード素片は、ものすごく間違いである。
どこが間違いか、ちゃんとわかってる方なら一瞬でわかるだろう。
一瞬でわからない方は、1分考えてみて、答えを読んでほしい。

...
var oRect = oPage.rectangles[iRect];
var oRect2 = oPage.rectangles.add();
oRect2.geometricBounds = [oRect.geometricBounds[0], 215, oRect.geometricBounds[2], oRect.geometricBounds[3] + 215 - oRect.geometricBounds[1]];


答えは…

配列要素を代入したこのoRectは、値ではなく、参照である。
従って、.add()した時点で、oRectは、当初とは異なるオブジェクトを指し示している可能性がある。

僕はここで20分ハマった。
今脱出したところだ。

これがJavaScriptの性質なのか、それともInDesign CS3のExtendScriptの性質なのか、ナンチャッテプログラマーの僕にはわかりましぇ~ん。

2014年11月7日金曜日

InDesignスクリプトで選択セル群を扱う際の注意

今日は、InDesign CS3で選択表列群のすべてのセルのすべての段落がセルに収まりかつセル先頭段落が1行になるよう長体をかける汎用スクリプトとか、列幅を広げる汎用スクリプトとかを作った。
もちろん純粋に趣味で作るプログラムなど意味はない。明日からの案件で使うのだ。それこそが僕の趣味である。
注意すべき点として、InDesign文書で複数のセルを選択している時、app.selection.length = 1となる。セル個数ではない。
そしてそのセルが属する表列がほしい時、oCell.parentColumnを直接取ると、それのindexプロパティとかconstructorを得ようとするとなぜかオブジェクトエラーとなることが多い。選択範囲由来のセルオブジェクトないし表列オブジェクトはちょっと何かが不完全らしい。セルのindexは選択範囲内で何番目という値が返されてくる。
セルIDは正しく取れたので、以下のように、上から目線でこのセルでしょというやり方(該当部分抜粋)でうまくいったが、もっとやりようないんですかねこれ…。

  // 選択されている各セルについて
  var oCells = oSelection.cells;
  var nCell = oCells.length;
  var iColumnBefore = -1;
  for (var iCell = 0; iCell < nCell; iCell++){
    var oCell = oCells.item(iCell);
    var qCell = oCell.id;
    var oTable = oCell.parent.parent;
    var oCellTables = oTable.cells;
    var nCellTable = oCellTables.length;
    for (var iCellTable = 0; iCellTable < nCellTable; iCellTable++){
      var oCellTable = oCellTables.item(iCellTable);
      var qCellTable = oCellTable.id;
      if (qCellTable == qCell){
        var oColumn = oCellTable.parentColumn;
        var iColumn = oColumn.index;
        if (iColumnBefore != iColumn){
          // 表列のすべてのセルのすべての段落がセルに収まり
          // かつセル先頭段落が1行になるよう長体をかける
          shrinkInCellsColumn(oColumn);
          iColumnBefore = iColumn;
        }
        break;
      }
    }
  }

2014年10月2日木曜日

イベントチラシで青海を青梅に誤記 おおぜいが青梅へ行ってしまう事案 これは胃が痛い

掲題のとおりであります。

【青梅?青海?】COLOR ME RADで衝撃的な誤植【大混乱・反応まとめ】 - NAVER まとめ
http://matome.naver.jp/odai/2141145149862770701

組んだ人間出てこい(笑)。

しかしくだんのチラシの画像を見ると、
誤記してるのは文字ばかりの案内の中じゃなくて、地図の中。
しかも、東京テレポート駅から近いですよみたいな地図なんですよねえ。

これ見て無批判に青梅へ行ってしまうひとというのも…。
なんというか…。

他人が与えている情報はすべて百%正確であるはず!
正確であらねばならない!
ということに無条件で慣らされてしまっているのでしょうか。

日本にひきこもっていた頃は僕もそうだったなぁ。

カンボジアにいると、これとは真逆の発想になってしまいますね。
これはこれで、疲れるわけですけど…。

2014年9月28日日曜日

XmlLite:軽量なXMLパーサ

くっ!
くるっ!
ドムが!!

ということでXMLいじるにはDOMかSAXというのが僕らオヤジの定番です。

しかし昨今は、軽量なXmlLiteというものがあるらしいです。

それについての記事があったのでちょっと読んでみました。

2014年8月21日木曜日

だからなんで電子書籍を画面で読もうとするわけ?

画面での読書は時系列があやふやになるという実験結果

私は古い人間なんで、電子書籍のオンデマンドプリント&装丁&製本サービスがコンビニにあればいいとおもっているんですが。

頒布の利便性において、紙の書籍は電子書籍にかなうべくもありません。

紙の書籍は運送のエネルギーを大量消費しますので、環境にも優しくありません。

また、紙の書籍はあらかじめ印刷するため、返本というむだが生じ、環境に優しくありません。

しかし、頒布を電子的に行うということは、閲覧も電子的に行わねばならないということを意味しません。

プリントしてしっかり製本して読むほうが、ブラウジング(ペラペラめくって目的の箇所をすばやく見つけ出す)も楽だし、拡大表示も楽だし(目的の箇所に目を近づけるだけ)、目にも優しいとおもうし、水濡れや乱暴な扱いにも耐えます。

もちろんせっかくなんで多少のバリアブルプリント要素ありで。

名入れとかだけでなく、登場人物の名前を変えることができるとかすれば、 妄想やプレゼントに最適です。

2014年8月7日木曜日

巷の記事の「Redmineこんなことができない」がすでにほぼ標準実装済みな件

bitnamiのRedmineスタックをWindowsにインストールしました。



まずはDTPの、しっちゃかめっちゃかになりがちな、進捗管理に便利に使う予定です。これについてはほとんど標準機能で。

ちなみに巷のあちこちのページに「Redmineってどうしてこんな簡単なことができないの?」という記事があるので、そのへんは運用でなんとかすんべとおもっていましたが…。

ほとんど、できるように標準実装済みとなっていました。

あとは、納期に時刻まで設定したいので、そのカスタムフィールドを追加したときに、チケットの画面で納期の日付の隣に表示されてほしいということがあるのだけど、これはたぶんテーマとかでできるのだろうな。(追記:テーマはCSSカスタマイズと若干のJS追加をできるだけだそうです)

さらに研究研究…。

ゆくゆくは、刻一刻流れる切り抜きとかの粒度の細かい作業の生産管理のプラットフォームとしても使いたい考えです。RailsでRESTfulな何かを書いて、あとたぶんLimeChatのスクリプトを書きます。これについては過去のいくつかの記事で研究過程を掲載してあります。

経営とはシステム構築なり。

2014年7月29日火曜日

簡単なチラシをプロに頼まず自作できるサイト

フェンリルからリリース。

約5万点の素材からドラッグするだけで、プロ並みのデザインが仕上がる新サービス “Picky-Pics (ピッキーピックス)”、本日リリースです!
本日、ブラウザ上でプロ並みのチラシや名刺をデザインする新サービス “Picky-Pics (ピッキーピックス)” をリリースしました。
サンプルを見るかぎり「プロ並み」はちょっと言いすぎ。

しかしこの程度の品質の仕事でかまわない案件が膨大にあるのも確かだろうとおもう。

もちろん私はデザイナーではないのでこんなこと言うのは僭越なのですが。

プロはプロの仕事に専念するという方向性は決して逆戻りすることはありませんね。

2014年7月19日土曜日

.psdカンプからCSSやパーツ画像をゲットできるサイト「プロジェクト パルフェ」

Adobeが、.psdカンプからCSSやパーツ画像をゲットできるサイトを公開しています。

project Parfait beta

このページにアクセスして、Photoshopファイルをブラウザにドラッグ&ドロップすると、画像の中の各パーツの位置・サイズや、パーツ間の距離などを、簡単に確認することができます。
また、各パーツごとに各種画像ファイル形式でダウンロードすることも可能です。

げしげし人海戦術で力仕事を安くやるのが途上国、とりわけカンボジアのような最後発途上国の売りです。
しかし人件費は当然年々上がっていきます。

こうした効率化をどれだけ積極的に学んで取り入れていくかで、正確さ・迅速さ・廉価さにおいて、他社とのさらなる差別化が図れます。

人件費が上がらないまでも同じことです。

社内IT部門はつねに技術研究と現場連携を怠ってはならない。

DTP自動化を専門とする者として、これはDTPでも同じだとおもっています。

なお、parfait(パルフェ)はフランス語で「完全な」という形容詞だそうです。お菓子の名前にもなっています。日本の「パフェ」というお菓子は、パルフェの魔改造形だそうです。

2014年7月14日月曜日

イラレCS3では重すぎて処理できないファイル、CS5ではOK



CS3というご指定のAdobe Illustratorのお仕事で、うっかり、データをチョー重たく作ってしまいました。

具体的には、1ファイル数十MBの.psdを貼りまくり(リンク)…。

今更.epsに差し替えるのも、事故が恐ろしいですし…。

PDF化しようとすると、「メモリが足りません」という無慈悲なエラーで、止まってしまいます。

CS3 (J)のあのトホホなバグの回避法は適用済です。

むむ~!


しかし、ふと思い立って、このファイルをCS5で開き、PDF化したところ…。

時間はかかりましたが、.pdfが無事できました!

時代はCCですが、現場はこんなもんです、というお話でした。

2014年7月3日木曜日

InDesignファイル内のテキストを全書き出ししてくれるプラグイン「TextExporter」

DTP屋として日々生活していると、InDesignファイル内のテキストをまとめて全書き出ししたい、といった気持ちになることが多々あるものですが、InDesignの標準機能では、ストーリーごとの書き出ししかできません。

しかし当然こういうありがちな要望に対しては、すでにどこかのどなたかが有難いプラグインを作成してくださっているわけです。

この「TextExporter」は、Win・Macの各バージョンのInDesign・InCopy対応のプラグインで、英語ですが、実際にCS3とCS5(ともにWin版)で試したところ、和文もなんら問題なく書き出しすることができました。

書き出しの設定は、ダイアログボックスでかなり細かくいろいろ指定することができます。プレーンテキストへ書き出すだけでなく、RTF・InDesignタグ形式への書き出しが可能です。

TextExporterの操作画面

https://www.rorohiko.com/wordpress/indesign-downloads/text-exporter/

この手の、スクリプトでちょちょっと作ってみました的全テキスト書き出しツールでは、えてして、順序がぐちゃぐちゃになってしまいがちです(たぶん内部ID順)。本当はやはり、上から下へ、左から右へ、書き出されてほしいものです。このプラグインはさすがそこもちゃんとしています。かつ、「上から下へ」と「左から右へ」のどちらを優先するのかも指定することができます(ダイアログボックスのいちばん上)。

ただ、文書ファイルによってはエラーが出たり、InDesignが落ちたりします…。CS3からの書き出しが失敗した文書ファイルについては、CS5で開いてもやはり失敗します。
どういうときにそうなるのかは、調べきれていません。

よって、このプラグインで書き出しできなかった文書ファイルについてのみ、このプラグインを利用せず、従来どおりストーリーごとに書き出しまたはコピー・ペーストが必要となります。

また、テキスト書き出しすると、一部のテキストフレームの内容が抜けたりします。これは、RTF書き出ししたときにRTF上で別テキストフレームとなるようなテキストフレームについて起こります。アンカーしているテキストフレームすべてについて起こるというわけでもなく、これも正確な条件を調べきれていません。

よって、書き出し後、ヌケがないかどうかを目視でチェックし、ヌケがあったら、そのストーリーについてのみ手作業で書き出しまたはコピー・ペーストする工程が必要となります。

しかし多くの文書ファイルは問題なく書き出しができますので、たいへん便利であります。

日本語圏では紹介されている様子がないので、紹介しておきます。

なお、.txtのエンコーディングはSJISとなります。

2014年6月24日火曜日

がっつりDTPとがっかりDTP

DTPにも体裁的にさまざまなレベルの案件があり、カンボジアの当社でも昨今はWordに毛が生えたようなコンテントドリブンなものから、ギッシリ組まれたガチガチレイアウトドリブンなものまでやっておりますが、もちろん前者も奥が深いのですが、後者は後者で人力であれこれ解決しないといけない部分が大きいのでカンボジアに向いておるわけです。

ただし人力といっても、単純作業の部分と、デザインとかのスキルが必要な人力とに大別することができ、後者は日本人相手なら日本人の好みというものもあって、カンボジアのマンパワーで単純に解決はできないわけです(その意味では、中国でもさんさん苦労話を聞いた)。

がっつりDTP、うっかりするとがっかりDTP

一字違いで大違い…。

私個人の専門は、こういうレイアウトドリブンなDTP案件の中に必ず存在するコンテントドリブンな部分(スペックとかコマとか呼ばれる所)をいかに自動化して速度と正確さと可用性と再利用性と可搬性を担保するかという提案と開発にあるので、デザインとかは私にとってもギブンなのです。

開発部分を除いた本作業部分を簡単なフロー図にするとこういうことです。

基本デザイン→(1) 自動組版→(2) スペック以外及びイレギュラー対応のDTP(人海戦術)→(3) デザイン的手直し

基本デザインは基本お客様から支給ですので、こちらでやることはありませんので、(1)と(2)と(3)の三種の神器がひとつになれば最強の組版チームが組成されるのだ。

いかにこの3つを揃えるかは、中国でも皆さん苦労されてる部分でした。というかそもそも(1)を含めようという発想がオフショア現場の場合はなかなかないかもしれません。私は逆にもともと日本にいて(1)側からオフショア現場との連携を図ってきた立場ですので、(1)と(2)を一緒にしたいというのがカンボジア大六創業の動機となっているわけです。

なぜなら、人力のみに頼っていたのでは、上述の速度と正確さと可用性と再利用性と可搬性を担保できないからです。

DTPでGitは使えるんでしょうか

デザイナーのための…と銘打って冒頭いきなり「コマンドなどは出てきません」でクスッとなった。
デザイナーがコマンドできちゃいかんのかw
http://www.slideshare.net/dsuket/git-16343460

まあもし立場逆で「プログラマーのためのデザインtips」とかのスライドだったら、冒頭「補色の話とか出てきません」とか書いてくれてたらかなり安心するので、もちろんこの1行の意義を理解はできる。

じゃあなんでクスッとなるか、自分の中を掘ってみると、たぶんこれは僕が、昔若かりし頃は
「プログラマーなのにデザインもできたらカッケー」
「勉強できるのに絵もうまかったらカッケー」
というのに憧れており、かつ頑張れば僕にもそれが実現可能という幻想を抱いていたが、今は現実を認識し、天才ならぬ身にはそれは無理ということを受け入れつつあるからじゃないかなとおもいますた。

同類相憐れむってこういう時使うってことで間違ってないですか?

なお、「オレオレバージョン管理!」でさらにクスクスッとなった。
この「!」の勢い!
まさに俺!

同類相憐れむってこういう時使うってことで間違ってないですか?

DTP(バイナリ)でGitは使えるんでしょうか?
という僕の素朴な疑問に答えてくれるスライド…かと思ったらそうでもなかった。
使えないことはないけど、ちょっと工夫がいりそうだよね、ということでしょうか。


追記
これの後半で言ってらっしゃることがたぶん僕の知りたいことにかなり肉薄しているんだろうけど、
http://japan.blogs.atlassian.com/2014/05/handle-big-repositories-git/
理解できない\(^o^)/
もっと勉強しないと/(^o^)\

追記
http://git-scm.com/book/ja/Git-%E3%81%AE%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%9E%E3%82%A4%E3%82%BA-Git-%E3%81%AE%E5%B1%9E%E6%80%A7
これのPNG画像のメタデータについて言っている箇所がかなりドンピシャリっぽい。
.epsだったらASCII85エンコーディングの場合はいけるのかな。
問題は.inddや.psdのフィルタはあるんでしょうかってことですが…、さらに要調査。

追記
http://en.wikipedia.org/wiki/ExifTool
Exifツールって言いながら.inddのXMPも読み取れちゃうのか。.psdとかもOK。.aiもOK。

追記10:53
あっちゃこっちゃさまよった結果、
http://blog.wktk.co.jp/archives/293
このひとが

画像ファイルなど、巨大かつ大量なバイナリファイルの管理はどうするか。

のセクションで言っていることが俺を最も深くうなずかせ納得させた。かつ、このセクションの内容ぐらいなら100%意味がわかる程度にはこの半日で学習が進んだでござるよ。