ネタ的には、出版界の恥を晒してしまった書籍「アインシュタイン その生涯と宇宙 下」が機械翻訳だったため回収へ - GIGAZINEという記事について制作という立場から思うことを書いていたら、8月4日に発生した東海テレビのテロップ表示の放送事故、同日開催されたグラフィックコミュニケーションズ工業組合の電子書籍セミナーが本題に関わるのでまとめてみる。 まず、機械翻訳で出版したものが後で発覚して自主回収という、なんだそれ、状態の話。別に糾弾するつもりはない。 これは謝罪文によると7月1日となっていて、発行されたのは6月末頃らしい。ネットで機械翻訳の噂がというか、もうあからさまなんだけど、いろいろと盛り上がって、ここ数日前に投稿された多くの記事でそのひどさについて書かれている。 書籍を制作している自分の立場から考えても「？」が多いこの話。出版社内部で制作してんのかな。 普通だと著者（今回は翻訳者）

現在、開発中のWikiからepub,idmlを書き出すWebシステムの紹介をする。 このエントリーをそのまま紹介のショットにしてしまおうと企んでいることは、内緒にして「CPub」について書く。っていうか前置きいいから早く書けと。 文章を最近よく目にするようになってきたマークダウン記法で書く機能と、その文章を各種データにコンバートする機能を提供するWebアプリケーション。JavaベースのWebアプリケーション構築プラットフォーム（オープンソースのフレームワーク）であるGrailsを使用して開発したもの。 Wikiの（簡単な）解説 その前に、「Wikiってナニ？」「マークダウンってウマいの？」という人のために簡単に解説する。Wikiは極めて広義なので、詳細は控える。Wikiの説明には、Wikipedia先生による解説があるが、読んでいると難しいので、Wiki自体が難しいと思われると嫌なので、ち

記念すべき第1回から３ヶ月（？）…2010年6月26日「第2回テクニカルDTP勉強会」が開催されましたとさ。 この記事は、今回の内容についてというより、主催者的立場で今回の開催を振り返った内容です。技術情報については期待しないように。あしからず。 何をやるのか、タイトルさえも決めてない勉強会は珍しいかもしれないですが、決まってないからこそ、自分が勉強会に持ち込んだ期待は、実は自分への期待だということに終わった後に気付かされる。 それが、後味が良いという感触の理由かもしれない。 これは参加してみないと分からないもの。 …と、ずぼらな主催者は思うわけです。 設立当初、集まって10人ぐらいでしょう、コソコソやりましょう、という軽いノリで始まったのですが、1回目に引き続き2回目も20名を軽くオーバー！ いいですねえ、だんだん訳が分からなくなる。 先日「DTPの勉強部屋」が名古屋で開催されましたが、

前回の価格編から、早々と続けます、、、 うちの場合は、DTPはもうコレ一本でいこう、とかいう無茶なことはしない方針で、そもそもDTPアプリはツール（道具）なので、どれを使うかは用途に合わせるべきだと考えています。 今回の比較は、ソフトウェアに対しての「慣れ」という視点を外さないと成り立たないので、そこは注意したつもりですが、いやいやこう使えばいいんだよ、とかあれば、優しくつっこんでください。 昔、組版とDTPの違いなんてのをブログに書いた気がしますが、おさらいすると、 ・枠を置いてから位置を合わせる（数値とか整列とかで）→DTP的 ・数値を決めてから枠を置く→組版的 な感じです。 先日、うちの開発部長O氏と話していてもう一つ気付いたのですが、 ・一度置いた枠は、全体のバランスを調整するために、移動するのは当然→DTP的 ・一度置いた枠は、計算して配置したのだから原則移動しない→組版的 とい

「学参の波」は、じわじわと忍び寄ってますが、実際どうなるんだろうということで、現時点でちょっとまとめてみます。 １．「学参」とは… 「学参」は、「学習参考書」の略。多分。 教科書を元にして作られる本です。本屋さんに並んでいたり、学校で配られたりする本です。 教科書の内容は、文部科学省による学習指導要領が何年かおきに改訂されます。 それに伴って、学参書籍も改訂したり、新しく作ったりします。 ２．「白表紙」について 教科書を巡る問題は度々報道されたりしていますが、その中でも白表紙問題というあります。「白表紙」とは、教科書検定に申請する申請本のことを意味しています。 参考書や問題集などは、教科書と一緒のタイミングで必要となります。 以前は、この白表紙をもとにして、学参書籍の本作りを進めて、その教科書が検定に通って、多分そこからちょこちょこと修正が入って完成するわけですが、それに合わせて、学参書籍

印刷物や出版物をXMLにすることを考えたとき、 どこでつまずくかというと、DTPデータの中で、構造化されない、しにくい部分があるから。 そもそもXMLがレイアウト情報などの一過性の情報をできるだけ排除したデータ重視であることに対して、DTPはレイアウトを含んだデータでこそ意味があり、その性格が違う。 DTPデータを無理矢理構造化しても手数が増えるだけで、生産性が上がらない。 生産性の低いDTPは、コストが増加するからやってはいけない。そして無理矢理の構造化はその場限りであって意味を持たない。意味の無いことは仕事としてやってはいけない。お互いの損になる。 印刷物や出版物は構造化されない部分が多い。むしろ構造化されている方が少ない。 上記の理由からも同等に見ることはできない。 DTPのデータを何らかの形で吸い出して、保持したいのであれば、 構造化されたXMLで考えるよりも、平面的に考えて、その

この関係は、一度、忘れてしまった方がいいと思う。 InDesignを使って、エレメントとオブジェクトをマッピングするときぐらいにしかXMLは必要ないように思う。 現存するDTPアプリケーションにXMLを取り込みたいときには、大半はXSLTやDOM操作でそれぞれのアプリが取り込める形式のデータに変換している。これはXML以外のタグ付きテキストでも同じです。ということはXMLである必要がない。 変換するときのことを考えるとXMLの方が面倒だと思う。 閉じタグがしっかり入っているから間違いなく引っこ抜けるよね、というぐらいかなと。 それよりも、XMLであるということは、そのXMLの仕様を決めたり、実際データを作る作業が大変だと思う。だったら、簡易タグでよいです。 汎用的に使うために作ったXMLならいいんですが、まず、手作業でXMLを作るのは、なんだかわざと回りくどいことをしているように見える。