自分用メモ。
xmlでタグ付け等をした後、タグのつけ忘れがないかチェックする時、今までalertでログを表示していたのだが、最近やたらログの量が多くなり、画面に収まりきらなくて困っていた。
scriptUIを使うとスクロールバー付きのウインドウを作れる。
var log //チェック結果のログ
var myDialog = new Window("window", "タグのチェック", [0,0,200,200]);
myDialog.add("edittext", [10,10,190,150],log,{multiline:true});
var myButton = myDialog.add("button", [120,270,180,290], "ok", {name: "ok"});
myDialog.center();
myDialog.show();
myButton.onClick = function(){
myDialog.close();
}
しかし、scriptUIのリファレンスはどこにあるんだろ。estkのヘルプもなんか不十分だし。。。と思ったら、JavaScript Tools Guideに詳しく書いてありますね。
2010/05/28
2010/05/21
まだまだeBook
来週にはiPad発売である。で状況がかなり変わるのかどうか。
で最近のAppleを見ていると、彼らの心境で右往左往するのは困るってわけで、appStore経由でのeBookてのはリスクがそれなりにありそうで、やはりとりあえずの結論としては、いかにHTMLで読みやすいものを作るかってところが目下の関心。
ページめくり機能とかは自然科学系の学術書ではどうでもいい話。教科書(参考書)であればいかに理解しやすいレイアウトか、構造かってことだなぁ。
HTMLを前提すると、XMLをベースにして、InDesignはレンダリングソフトウェア的に考えるのが至極まっとうではある。赤字校正もXMLで。
で最近のAppleを見ていると、彼らの心境で右往左往するのは困るってわけで、appStore経由でのeBookてのはリスクがそれなりにありそうで、やはりとりあえずの結論としては、いかにHTMLで読みやすいものを作るかってところが目下の関心。
ページめくり機能とかは自然科学系の学術書ではどうでもいい話。教科書(参考書)であればいかに理解しやすいレイアウトか、構造かってことだなぁ。
HTMLを前提すると、XMLをベースにして、InDesignはレンダリングソフトウェア的に考えるのが至極まっとうではある。赤字校正もXMLで。
2010/04/28
ebookその後
多くのサイトが競ってeBookの未来予測を立てるこの頃。
まぁ自分もそのうちの一人(ってほどのことでもないが)なのだが、appleのFlash締め出しとかを見るとなかなか動きづらい(出版社側では)。それよりも単純にしておくべきなのは、制作データの社内管理。
印刷会社と出版社の関係では、欧米では出版社が完全に印刷データ(組版データ、製版データ等)を完全にコントロールしている模様だが、日本ではそうでもない。ほんの数年前にも、製版データをめぐる訴訟が起きているし、印刷会社としては、印刷はしても組版データは渡さない、というところも多いのである(まぁここらへんは単純に権利関係の問題で契約を見直すことで解決できるのだが)。
図版や表が多い書籍の場合のeBookの作り方ってのは試行錯誤するしかない。当たり前だが。でも結局、HTML化(WEBアプリ化)するのが一番早いのだと思う。アプリとして売るとしてもHTMLをパッケージすればいいだけのことだし。
もちろん検索性は重要であるから、本の索引をうまく変換することが肝心。
とか考えてもiPad的なB5サイズのタブレットが主流になればPDFで問題ない気もするんだな、これが。
まぁ自分もそのうちの一人(ってほどのことでもないが)なのだが、appleのFlash締め出しとかを見るとなかなか動きづらい(出版社側では)。それよりも単純にしておくべきなのは、制作データの社内管理。
印刷会社と出版社の関係では、欧米では出版社が完全に印刷データ(組版データ、製版データ等)を完全にコントロールしている模様だが、日本ではそうでもない。ほんの数年前にも、製版データをめぐる訴訟が起きているし、印刷会社としては、印刷はしても組版データは渡さない、というところも多いのである(まぁここらへんは単純に権利関係の問題で契約を見直すことで解決できるのだが)。
図版や表が多い書籍の場合のeBookの作り方ってのは試行錯誤するしかない。当たり前だが。でも結局、HTML化(WEBアプリ化)するのが一番早いのだと思う。アプリとして売るとしてもHTMLをパッケージすればいいだけのことだし。
もちろん検索性は重要であるから、本の索引をうまく変換することが肝心。
とか考えてもiPad的なB5サイズのタブレットが主流になればPDFで問題ない気もするんだな、これが。
2010/03/23
e-book
電子書籍て呼び方に違和感があるのかもしれない、結局のところ。
例えば、WIREDやVIV MagのiPadデモを見て、未来の本!と騒ぐ気にはなれないのである。WEBとどーちがうの?というわけで。個人的には、FLASHサイトは鬱陶しかったのだが、それをタブレットで見ることで変わるのかもしれない、てところに期待はしている。
送り手からのメリットとしては、WEBコンテンツの切り売りが可能となり、しかもコピーの問題も多分クリア、てところだろうか。ただ、先のVIV Magのようなリッチなコンテンツを作るのであればそれなりにコストもかかるだろうしな。。。
例えば、WIREDやVIV MagのiPadデモを見て、未来の本!と騒ぐ気にはなれないのである。WEBとどーちがうの?というわけで。個人的には、FLASHサイトは鬱陶しかったのだが、それをタブレットで見ることで変わるのかもしれない、てところに期待はしている。
送り手からのメリットとしては、WEBコンテンツの切り売りが可能となり、しかもコピーの問題も多分クリア、てところだろうか。ただ、先のVIV Magのようなリッチなコンテンツを作るのであればそれなりにコストもかかるだろうしな。。。
2010/03/07
findGrep()で検索したとき
よく忘れるのでメモ。
findGrep()で検索したときの返り値はマッチした文字列の配列。で文字列がどの場所にあるのかを知りたい時は、配列をfor文とかで回してindexプロパティで親ストーリーの何番目のキャラクターなのかがわかる。
例えば次のように取得する。
app.findGrepPreferences.findWhat = "(?s)▲▲(.+?)▼▼";
var result = myStory.findGrep(true);
for(var i=0; i<result.length; i++) {
$.writeln(result[i].index);
$.writeln(result[i].toSpecifier());
}
indexで最初の▲の位置がわかる。toSpecifier()だと最初と最後がわかる。
単純にindexとな。ここで躓いてしまった。
何がしたかったというと、タグで囲まれた部分を吹き出し的なアンカーフレームにする、というもの。テキストフレーム作成→ライブラリ経由→カーソル位置に配置、と今までやってたんだけど、insertionPointがわかってれば直接insertionPoints[x].textFrames.add()、と出来るようなので。
findGrep()で検索したときの返り値はマッチした文字列の配列。で文字列がどの場所にあるのかを知りたい時は、配列をfor文とかで回してindexプロパティで親ストーリーの何番目のキャラクターなのかがわかる。
例えば次のように取得する。
app.findGrepPreferences.findWhat = "(?s)▲▲(.+?)▼▼";
var result = myStory.findGrep(true);
for(var i=0; i<result.length; i++) {
$.writeln(result[i].index);
$.writeln(result[i].toSpecifier());
}
indexで最初の▲の位置がわかる。toSpecifier()だと最初と最後がわかる。
単純にindexとな。ここで躓いてしまった。
何がしたかったというと、タグで囲まれた部分を吹き出し的なアンカーフレームにする、というもの。テキストフレーム作成→ライブラリ経由→カーソル位置に配置、と今までやってたんだけど、insertionPointがわかってれば直接insertionPoints[x].textFrames.add()、と出来るようなので。
登録:
投稿 (Atom)