PDF　千夜一夜

2007年07月04日

電子帳簿保存法

先日、電子帳簿保存法について、国税局の担当者の説明会があって出席してみました。国税局の担当者の過激な発言がいろいろあって面白かったです。それにしてもビジネスの現実からはかけ離れたこともあります。

第一．見積書保存の問題
一番あきれたのは、法人税法施行規則（青色申告法人の決算）の第五十九条（帳簿書類の整理保存）についてのやり取りです。まず、第五十九条を紹介してみましょう。
第五十九条　青色申告法人は、次に掲げる帳簿書類を整理し、七年間、これを納税地に保存しなければならない。
一　第五十四条（取引に関する帳簿及び記載事項）に規定する帳簿並びに当該青色申告法人の資産、負債及び資本に影響を及ぼす一切の取引に関して作成されたその他の帳簿
二　棚卸し表、貸借対照表及び損益計算書並びに決算に関して作成されたその他の書類
三　取引に関して、相手方から受け取った注文書、契約書、送り状、領収書、見積書その他、これらに順ずる書類及び自己の作成したこれらの書類でその写しのあるものはその写し

上で挙げた書類を7年間保管しなければならないのですが、その中で、送り状や見積書を保存しなければならないというのは、会場の参加者からも疑問の声が上がっていました。

そこで、いろいろ質問しましたが、驚いたのは、成立しない取引の見積書も保存しなければいけない、という回答です。

当日配布された資料には次のように書かれています。
『平成16年度に定期的に行った国税庁とJIIMAやJBMIAなど関係4団体との協議会の中で、国税庁担当官から見積書を例に上げて、「採用されなかった見積書でも保存の義務があり、これを電子化した場合、検索できなければならない。採用しなかった見積書を電子化文書にして保存しない場合は、当該の見積書を受領した相手方に確実に返却しなければならない。」との説明を受けている。』

成立しない取引の見積書保存の問題は、単に聞かれたから、やむを得ず回答したわけではなく、確信犯ということになります。

取引の定義が法人税法のどこにあるか、調べてみていませんが、常識的に考えて取引は資材とお金をやり取りすることと考えられます。普通、お金をやり取りしたことのない相手を取引先とは言わないでしょう。従って、成立しない取引は通常の意味では取引とは看做さないと思います。値引き交渉のために他の会社から見積もりとったり、また、一旦見積をとったうえで、予算にあわないという理由で購入をあきらめることもあります。こうした、交渉事はビジネスの世界では日常茶飯事です。そのような単なる交渉のための言ってみれば引合レベルの見積もり書までも7年保管しなければならないということであれば、あまりにも非現実的です。

それに、上述のアンダーラインの部分は、自己矛盾を露呈しています。つまり、自己の手元にあれば保存しなければならないが、返却すれば保存しなくても良いということですが、これを抽象化して言えば、保存しても保存しなくてもどちらでも良いということになります。

で、こうした初歩的な事柄からスタートして、電子帳簿保存法はなかなか大変だということが良く分かりました。

第二．電子帳簿保存法のみなし承認とは

みなし承認とは、税法及び電子帳簿保存法の趣旨・要件を、それぞれの納税者が申請したシステムが遵守していることを納税者自身が宣言するものである。自ら宣言した内容に違反や誤りがあれば青色申告法人を取り消す方針で望む

とあります。

特に、スキャナは問題で、紙をスキャナーで取って電子化し、オリジナルの紙を廃棄してしまったあと、国税庁の調査でシステムが電子帳簿保存法の要件を満たさないことが判明した場合、電子データがあったとしても、上述の第五十九条の保存の要件をみたしていない、書類が保存されていないということになります。従って、青色申告法人取り消しだそうです。

こういう話を聞いて、ああ、日本では紙がなくなる日は来ない！と言う感想を持ちました。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年06月05日

日本語スタイルシート技術の検討のご紹介

日本印刷技術協会（JAGAT）の2006年度活動「縦組みスタイルシート作業部会」の報告が次のところに公開されています。

■日本語スタイルシート技術の検討

現在、W3CのCSSやXSL-FOなどのスタイルシート技術を使って電子ドキュメントを組版することが普及し始めています。その際、CSSやXSL-FOには日本語の組版に必要な機能が不足していることから、日本語組版に必要な機能を整理することを行っています。

JAGATのWebページでも説明されていますように、この作業部会の成果の一部は、昨年ドイツで行われたW3Cのプリントシンポジウムで報告されました。

○関連
2006年10月18日 W3C Print Symposium 2006 (1)
2006年10月19日 W3C Print Symposium 2006 (2)
2006年10月20日 W3C Print Symposium 2006 (3) XSL-FOとCSSの互換性
2006年10月21日 W3C Print Symposium 2006 (4) XSL-WG

2007年02月20日第22回多言語組版研究会 — 「縦組の組版方法と組版指定交換形
式」を開催しました
2007年02月23日日本語組版はグリッドベースで行うと言って良いのか？(1)
2007年02月24日日本語組版はグリッドベースで行うと言って良いのか？(2)
2007年02月25日日本語組版はグリッドベースで行うと言って良いのか？(3)
2007年02月26日日本語組版はグリッドベースで行うと言って良いのか？(4)
2007年02月27日日本語組版はグリッドベースで行うと言って良いのか？(5)
2007年03月03日日本語組版はグリッドベースで行うと言って良いのか？(6)
2007年03月04日日本語組版はグリッドベースで行うと言って良いのか？(7)

投稿者 koba : 08:00 | コメント (1) | トラックバック

2007年05月30日

「暗号解読 — ロゼッタストーンから量子暗号まで」

ここ1週間ほどで、サイモン・シンの「暗号解読 — ロゼッタストーンから量子暗号まで」新潮社刊　ISBN4-10-539302-2　を読みました。

暗号というと暗いイメージをもたれる方も多いと思います。実際、私も暗号なんて近づきたくない領域だと思っていましたが、この数ヶ月、公開鍵暗号方式を中心に少し勉強して、身近になりつつあるところで、この本を読んだのはグッドタイミングでした。

冒頭にスコットランド女王メアリー裁判の話があります。メアリーはのエリザベス女王暗殺を企てたかどで死刑になったのですが、その判決が下ったのは、メアリーと陰謀の計画者バビントンとの暗号による通信が解読されて証拠として提出されたため、というエピソードは、「弱い暗号を使うなら、使わない方が良い」という格言を強く印象付けてくれます。

また、第二次大戦前から大戦中にかけて、ドイツの「エニグマ暗号」解読についての、知恵を振り絞った戦いについても、単なる物語ではなく、エニグマ暗号機の仕組みまで技術的な面から分かりやすく解説されています。

日本の紫暗号についてもほんの少しですが、触れられています。日本海軍がミッドウエー海戦に大敗したのは、日本軍がアリューシャン列島を攻撃すると見せかけてアメリカ艦隊をひきつけておき、ミッドウエーを奇襲しようという計画が紫暗号を解読されたために、不意打ちを仕掛けた日本軍が逆に不意打ちにあった、という話です。

このあたりまでは、暗号の重要さはわかっても、既に過去の物語でもあり、現代の一般庶民には身近なものではないと感じる部分です。

しかし、第VI章「アリスとボブは鍵を公開する」という節で、コンピュータによる大量情報処理にとって鍵の配送が死活問題になっているというあたりから、急に身近な話になります。共通鍵暗号方式では、鍵の配送が最大の弱点。1970年代の米合衆国政府の鍵の管理、配送にあたったCOMSECという組織が運搬した暗号の鍵は日々何トンにものぼった、という生々しい話もあります。

公開鍵交換による鍵配送問題の解決を考案したディフィーとヘルマンの実話、RSAの公開鍵暗号方式の誕生の実話などが詳しく紹介されています。二千年以上にわたる暗号の歴史上画期的な、公開鍵暗号方式は、1970年代後半から現在にいたるインターネットの爆発に時機を一にしているということに深い感動を覚えました。必要は発明の母といいますか、見えざる神の手に導かれるようにして公開鍵暗号方式が誕生したことがよく分かります。

「暗号解読 — ロゼッタストーンから量子暗号まで」こそは、インターネット時代における暗号の重要さを認識する上でも、多くの人にお薦めしたい本です。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2007年05月07日

ビジネス用の書式を集めたWebページのご紹介

アンテナハウスでは、「書けまっせ!!PDF2」用のPDF書式集「書けまっせ!!フォーム」を用意しています。

書けまっせ!!フォームのページはこちらです。
http://www.antenna.co.jp/form/

「書けまっせ!!フォーム」は、PDF形式に特化した書式ページですが、PDFに限定しなければ、書式を集めて無償で使用可能にしているWebページは沢山あります。次に幾つか紹介してみます。

○書式の王様　http://www.bizocean.jp/
　社内文書1,494種類、社外文書481種類、個人文書277種類、法定文書1344種類、英文文書97種類　合計3,717書式が登録されています。
　ダウンロードのランキングが公開されています。こちらです。
　上位を見ますと、　

1位　領収書
2位　出勤簿
3位　FAX送付状
4位　時候のあいさつ
5位　失態の詫び状
などとなっていて、かなり一般的な社内書式に人気があるようです。

ファイル形式には、PDF形式もあります。しかし、上位30位以内は、ExcelかWord形式ばかりですのでPDFは人気がないのかな？ちょっと残念ですね。「書けまっせ!!PDF2」のようなPDFへの記入ソフトが普及すれば、PDF書式にもっと人気が出ると思います。

○テンプレートバンク　http://www.templatebank.com/
パーソナル、ビジネス、素材と分かれています。Webサイトの名称はテンプレート（様式）になっていますが、内容はWebページ用の素材などがかなり多くなっているようです。
ビジネスの分野に、「伝票・帳票・届出用紙」という分類がありますが、このあたりに書式が登録されています。PDFの書式もありますが、有償のものが多いようです。

○B-Form.biz　http://www.businessform.biz/
ビジネス文書のポータルサイト。1000種類と言っていますので、「書式の王様」より少ないですね。Word、ExcelとならんでPDF形式のものもありますが、PDFは比較的少ないようです。

○ビジネス文書の森　http://www.jusnet.co.jp/business/
有償と無償の雛形があります。100種類の無償のビジネス文書の雛形がありますが、書式として形が整っているものではなく、文章の雛形中心のようです。PDF形式のものはありません。

○ハート封筒のオリジナルテンプレート　http://www.heart-group.co.jp/download/index.html
このWebページには同社のオリジナルのテンプレートが公開されています。Word文書になっているようです。PDFでも十分使えそうなものもありますが、残念ながらPDFは用意されていません。

こうしてみますと、PDF形式に絞って簡単に使える書式を用意している民間のWebページは比較的少ないように思います。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年11月22日

電子行政とPDF (3)

「オンライン利用促進のための行動計画」の各省庁のデータを見ていまして、もうひとつ気が付いたことは、電子申請の際に、本人認証の手段として、電子署名を要求しているものの利用度合いが少ない、ということです。

逆に、よく使われているものは、ほとんどパスワード認証方式になっています。

昨日の、オンライン化率の高い、上位10位はすべて、パスワード方式の認証方法になっています。それに対して、利用されていないとした、税務、保険・年金、自動車関係の手続きは、すべて本人認証に、電子署名を要求しています。

行動計画に上がっている申請手続きは全部で169項目あります。この中で、私が分類した限りでは、オンラインによる申請で電子署名を必要とするものが134項目、必要としないものが29項目、その他（よく分からないもの含む）が6項目となっています。

それぞれについて、オンラインの利用状況を集計しますと、次の表のようになります。これを見ますと、電子署名を必要とする申請の利用率が非常に低くなっていて、電子署名が大きな障害になっているのではないかと思われます。

分類	手続きの数	年間処理件数	オンライン利用実績	オンライン利用率
電子署名を必要とする申請手続き	134	239,263,300	480,647	0.2%
電子署名を必要としない	29	342,466,000	73,457,230	21.4%
両方または不明	6	78,273,000	7,074,572	9.0%
合計	169	660,002,300	81,012,449	12.3%

ところで、電子署名を必要としない申請手続きの中では、法務省の「不動産登記に係る登記事項証明書等の交付請求手続等」が年間利用件数2億84百万件と83%を占めているのですが、このオンライン申請の利用は21百万件、利用率7.6%となっています。この利用率を高めさえすれば、電子署名を必要としない手続きは、軽く50%を超えると思います。そうしますと、この対策が目標達成のひとつの鍵になりそうです。

法務省のWebページオンラインによる登記事項証明書の送付請求（不動産登記関係）についてには、その手続きが書いてあります。

ですが、この説明の中に、電子申請の準備には、電子署名が必要と書いてあります。

ご利用方法　事前準備のステップ4

で、ステップ４　電子署名（デジタル署名）に必要な申請者の電子証明書の取得を見ますと、

不動産登記関係手続、商業・法人登記関係手続、債権譲渡登記関係手続および情報公開関係手続の一部については、電子署名を行うことなく、オンラインによる申請が可能です。

と書いてあります。う～～ん。電子署名が必要なのか必要でないのか、良く分かりませんね。もう少し分かりやすくできないものでしょうか。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年11月21日

電子行政とPDF (2)

さて、この行政における申請の電子化の状況の表を眺めていまして、幾つか、気が付きました。

１．オンライン化率が高いのは物品の取り扱いに関する許可申請の類である。
手続きがオンラインで行われている比率が高いものを上位から10位を並べますと次のようになります。

省庁名	対象手続き	年間平均申請件数	オンライン利用件数	利用率
財務省	№ 12 輸出申告	13,535,000	13,359,000	98.7%
財務省	№ 11 輸入（納税）申告（輸入許可前引取り承認申請を含む。）	31,721,000	30,898,000	97.4%
農林水産省	№ 3 採補数量等の報告	231,000	215,000	93.1%
財務省	№ 10 保税運送（包括）承認	767,000	700,000	91.3%
財務省	№ 3 貨物の積卸しについての書類の呈示	1,819,000	1,597,000	87.8%
農林水産省	№ 2 輸入植物等の検査の申請	335,000	285,000	85.1%
厚生労働省	№ 1 食品等の輸入の届出	1,716,000	1,425,400	83.1%
財務省	№ 6 外国貨物仮陸揚の届出	630,000	521,000	82.7%
財務省	№ 14 積卸コンテナー一覧表の提出	203,000	151,000	74.4%
農林水産省	№ 1 指定検疫物の輸入届出	206,000	151,000	73.3%

これは、輸出入などの物品の取り扱いを行う企業(業者)と、役所との間でのオンライン化が進んでいることを示しているものと思います。

２．多くの国民に関係が深いと思われる、税務、保険・年金、自動車は、まったくオンライン化が進んでいない。

・財務省の国税電子申告・納税システム（e-Tax)のオンライン化率は0.2%
・厚生労働省電子申請・届出システム（No.2～No.4）のオンライン化率は0.0%
・厚生労働省 労働保険適用徴収・電子申請システムのオンライン化率は0.0%
・厚生労働省 労働保険適用徴収・電子申請システム、厚生労働省電子申請・届出システム（グループ申請）のオンライン化率は0.2%
・厚生労働省電子申請・届出システム（No.10～No.77）のオンライン化率は0.0%
・自動車保有関係手続のワンストップサービスシステムのオンライン化率は0.0%

と、まったく、目を覆いたくなるような惨敗といえるような数字です。この状態ではこれらの申請オンライン・サービスの利用率はどう考えても、2010年に50%達成は無理ではないかと思ってしまいます。

昨日、松下幸之助の「商売は真剣勝負」（PHP文庫）という本を読んでいましたら、最初に立てた目標を達成できない、”こと志に反する”のは、自ら省みて自己認識ができてないからだ、という一文がありました (pp.163 ～169) 。「税務、保険・年金、自動車」関係のオンライン申請のケースでは、目標自体に無理があるか、あるいは、本当に目標が重大ならば、やり方を抜本的に変更しないと目標を達成することができないんじゃないでしょうか。政府は業者に対しては権力を振りかざして強制・指導はできても、一般国民まで強制はできない、ということについて自己認識が足りないのではないでしょうか。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年11月20日

電子行政とPDF

さて、PDFとは電子の紙、そうなりますと、行政システムの申請書などが紙から電子化される際にも、PDFが大きな役割を果たすことが期待されます。そこで、実際のところ、いま、どんな状況なのかを少し調べてみることにしました。

政府は「ＩＴ新改革戦略」として「世界一便利で効率的な電子行政」をスローガンに掲げています。「利便性・サービス向上が実感できる電子政府・電子自治体を実現するとして、国・地方公共団体に対する申請・届出等手続におけるオンライン利用率を2010年度までに50％以上とするという目標を定めていることはご存知の方も多いと思います。

総務省のホームページに行きますと、「オンライン利用促進のための行動計画」が公開されています。

「オンライン利用促進のための行動計画」について

PDFファイルで、主要な省庁の行動計画が出ています。

この中でまず、各省庁の電子申請に関するシステムとその利用状況がでていますので、私なりに、これをまとめてみました。

省庁名	システム名	年間平均申請件数(合計)	利用実績(合計)	利用率
金融庁	電子申請・届出システム	437,000	209,000	47.8%
総務省	総務省電波利用 電子申請・届出システム	178,000	15,989	9.0%
総務省	行政相談の申出	185,000	720	0.4%
法務省	オンライン手続のサービス、登記情報提供サービス	380,078,000	28,637,673	7.5%
法務省	乗員上陸許可支援システム	1,200,000	304,000	25.3%
財務省	ＮＡＣＣＳ、ＣｕＰＥＳ	50,440,000	47,795,200	94.8%
財務省	国税電子申告・納税システム（e-Tax)ホームページ	69,234,000	148,637	0.2%
厚生労働省	輸入食品監視支援システム	1,716,000	1,425,400	83.1%
厚生労働省	厚生労働省電子申請・届出システム（№ 2 就業規則（変更）届出、№ 3 1年単位の変形労働制に関する協定届、 № 4 時間外・休日労働に関する協定届）	1,303,000	376	0.0%
厚生労働省	労働保険適用徴収・電子申請システム	4,114,000	1,887	0.0%
厚生労働省	労働保険適用徴収・電子申請システム、厚生労働省電子申請・届出システム（グループ申請）	486,000	796	0.2%
厚生労働省	厚生労働省電子申請・届出システム（No.10～No.77）	141,743,800	10,620	0.0%
農林水産省	動物検疫検査手続電算処理システム（ANIPAS）	206,000	151,000	73.3%
農林水産省	輸入植物検査手続電算処理システム(PQ-NETWORK)	335,000	285,000	85.1%
農林水産省	漁獲管理情報処理システム	231,000	215,000	93.1%
経済産業省	オンライン手続のサービス（新世代統計システム）	500,000	148,000	29.6%
経済産業省	オンライン手続のサービス（汎用電子申請システム）	102,000	0	0.0%
経済産業省	オンライン手続のサービス（電子出願システム）	2,400,000	1,300,000	54.2%
国土交通省	特殊車両オンライン申請システム	127,000	7,990	6.3%
国土交通省	自動車保有関係手続のワンストップサービスシステム	3,500,000	159	0.0%
国土交通省	汎用受付等システム	282,500	2	0.0%
国土交通省	港湾ＥＤＩシステム	1,204,000	355,000	29.5%
合計		660,002,300	81,012,449	12.3%

上の表は中央省庁の主な申請の年間処理件数が出ていますが、これらを合計しますと、1年間に6億6千万件になります。この中で、システムの利用実績（すなわち電子申請処理されているもの）は、8,137万件となります。これは、各省庁の報告にある平成17年の利用実績データを合計したものですが、期間が1年分に満たない項目もあります。そうしますと、ざっくりいって、現在、1年間の申請処理件数の中で、平均15%弱が電子申請を利用して行われているということになります。

※2006/11/20　財務省の数字の転記ミスを発見・訂正。ほんのわずか変更になりました。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年03月10日

ヤンキー・グループのFlash調査報告

もう半年近く前のものなの（2005年10月）で新しい資料とは言えませんが、Flash導入3年目のNTTドコモという調査レポートがあります。

この手の米国調査会社のレポートは大抵、ベンダがスポンサーになっていて、販売促進資料として配布しているもので、このレポートもMacromediaがスポンサーになってまとめたものです。そういう意味では、Flashの販促用ということもできますけれど。

レポート（本文はPDF英文10ページ）のポイントを紹介します。
---ここから---
・NTTドコモは、2003年の早い時期にFlash Liteをi-mode端末に搭載して出荷を始めたが、2005年秋時点でNTTドコモの契約者の中で2000万（全i-modeの45%）がFlash Liteを利用可能な電話機をもっている。2005年末には2500万台になる見込み。
・第3世代（３G）電話機FOMAのユーザの90%にあたる約1400万台がFlash Liteを利用可能。
・i-modeの公式サイトは、2005年9月時点で4600あるが、その中で2000がFlash Lite対応になっている。非公式サイトは87,000以上で推定20%がFlash Lite対応。

KDDIのauは、1年ほど遅れてFlash Lite1.1を採用し、1年遅れでドコモを追撃している。
---ここまで---

この数字をみますと、Flash Liteが随分普及しているという印象がありますね。私は、auなのであまり普段見てませんでしたが。

Flash LiteとSVG Tiny
ところで、Flash Lite 1.1からSVG Tiny の表示をサポートしています。だから携帯電話にFlash Lite 1.1が普及すれば、自動的にSVG Tinyも普及するという構図になるはずです。

MacromediaのFlash Lite サポート対象の携帯デバイスには、NTTドコモの機種が、40機種掲載されています。（ざっと数えたのみなので間違いがあるかもしれません。大筋でみてください）。
・富士通　9機種
・三菱　5機種
・NEC　8機種
・松下　7機種
・シャープ　6機種
・ソニーエリクソン　5機種
-----------
合計　40機種

この中で、富士通の4機種だけが、Flash Lite 1.0で他の機種はすべてFlash Lite 1.0とFlash Lite 1.1に対応しています。

ドコモのFOMAのFlash対応機種は、ほとんどFlash Lite 1.1になっているようです。こうみますと、SVG Tiny を表示できる携帯電話って1500万台以上はあるのではないでしょうか。

そうしますと、2006年03月07日SVGの行方は？で紹介しましたスウエーデンのIkivo AB社の950万台という推定は少なすぎるように思いますね。Ikivio ABはFlash Liteを計算に入れてないのかな？

但し、Flash LiteFAQの、なぜSVG Tinyをサポートしたかというところを見ますと、
・SVG-Tを組み込む決定の理由
・FlashはSVG-Tをサポートしますか？
・FlashはSVG-T仕様に準拠していますか？
の３つの質問への回答は、SVG Tinyに対してあまり前向きとは言えないようです。

投稿者 koba : 08:00 | コメント (3) | トラックバック

2006年03月05日

文字符号の歴史　「欧米と日本編」

「文字符号の歴史　欧米と日本編」　（安岡孝一・安岡素子著、6,000円＋税、共立出版、ISBN4-320-12102-3、2006年2月1日発行）が発行されたことは、文字のメーリングリストで紹介されていましたので、知っていましたが、たまたま神田に行く用事があったので書泉で買ってきました。

このブログでも何回か紹介しました、「文字符号の歴史　アジア編」（三上　喜貴著、共立出版、2002年、ISBN4-320-12040-X、2002年3月20日発行 ）と並べてみますと、2冊が姉妹書として企画されたことが良くわかります。

※左がアジア編、右が欧米と日本編

アジア編は、各国の文字コードについての情報がものすごく豊富でさすが、という本でした。

欧米と日本編は、まだ詳しく読んでいないのですが、資料がいろいろ載っているのは将来のために参考になりそうです。なにはともあれ、こういう本をまとめた安岡ご夫妻にご苦労様と申し上げたいです。

こういう2冊の本が、文字コードがUnicodeの時代に大きく変わって行こうとする今の時点ででたことは大きな意義があると思います。いづれも大体2000年頃までの話になっていますので、20x0年頃に続きがでることも期待しましょう。

特に、アジアの文字については、次回は、誰かKen Lundeに負けない本を出してもらいたいものです。

投稿者 koba : 08:00 | コメント (4) | トラックバック

2006年02月25日

iTextのPDF直接出力機能

いままで、iTextの高級オブジェクトをかい摘んで紹介しました。こういう高級オブジェクトを使うと、PDFについての知識を持っていなくても、PDF出力が簡単にできるというメリットがあります。

これに加えて、iTextの特長は、PDFの中に記述する命令を直接出力する機能があります。PDFの低レベルの命令を直接扱うだけに、この機能を使うには、PDF Referenceの第4章グラフィックス、第5章テキストあたりを最初に読む必要があります。

具体的には次のような命令です。
Part IV: Direct Content

５．iTextで直接扱えるPDF描画命令
・Graphics state オペレータ
・座標変換行列
・カラー
・クリッピング・パス
・形状の定義をするパス設定オペレータ
・パスの塗り潰しなどのオペレータ
・PDFのオブジェクトであるImageXObject、FormXObjectなど
※PostScriptXObjectの例もありますが、これは廃止予定があるとされているもので使うべきではありません。
・テキスト・オペレータでフォントのグリフ記述
・オプション・コンテンツ

XSL-FO組版エンジンは、これらのPDFの描画命令をユーザには通常開放していません。アンテナハウスのXSL Formatterの場合、これらのPDF描画命令は、PDF生成ライブラリーを使ってPDFに出力しています。

iTextでは、内部的に各ページを4つのレイヤに分けています。その内2つのレイヤは高級オブジェクト用でiTextのプログラム内部専用です。残りの２つにはgetDirectContent()、getDirectContentUnder()を使って直接出力できます。例えばウオーター･マークなどを出すのに使えます。
(このレイヤは、iTextのプログラム内部のレイヤで、PDF Referenceの「オプション内容グループ」（後述）とは別のものです。）

JAVAプログラマが直接PDFの描画命令を使うのは、あまり生産性が高いとは思えません。しかし、汎用ソフトのオブジェクト経由では実現できないことを行うために、プログラマに開放したレイヤがあるというのは便利な場合もあるように思います。

６．PDFのオプション内容グループ（Optional Content Group）
PDF 1.5(Acrobatのバージョンでは6)で、オプション内容グループ（Optional Content Groupという機能が追加になりました。この機能は、PDFの内容を多層化して作成しておき、各層を表示するかしないかを選択できます。

iTextでは、PdfLayerオブジェクトを使って、この機能を使ったPDF出力もできるようになっています。チュートリアルで幾つかサンプルが紹介されていますが、その中で一つだけ次に紹介します。

PdfLayerで出力する層を指定して、各レイヤに別の文字列を出力します。すると、このような３層のPDFが出来ます。
３層のPDFの例

Adobe ReaderのLayersタブで各レイヤを表示するかどうかを選択できます。

さて、このようにiTextの機能のあらましを紹介し、iTextのオブジェクトについては、XSL-FOと簡単に比較してみました。実際のところiTextはPDF出力専用の低レベルなJAVAライブラリーと言えます。その範囲で、PDF専用の機能についてはかなり強力な部分を持つ優れたライブラリーのようです。

しかし、XSL-FOのような高度な組版機能を提供するものではありません。サーバ上で作成しようとするレイアウトにもよりますが、Webページをさらに精密にするような高度なレイアウトであれば、XSL-FOの方が生産性が高くなると思います。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年02月24日

iTextとXSL-FOでのテキスト出力比較

一昨日に続いて、iTextとXSL-FOのオブジェクトの比較をしてみます。

４．テキストの出力
（１）iTextでテキストを出力するオブジェクト
・iTextでPDFにテキストを書き出すには、主にChunkオブジェクトまたはParagraphオブジェクトを使います。Chunkオブジェクトとは、すべてのテキスト・オブジェクトの原子であって、その内容はフォント名、フォントのサイズ、スタイル、色が同じ文字列です。

　Chunk単位で、アンダーラインを付けたり、文字の位置を上下に移動したり、バックグラウンド・カラーを付けたりの様々な処理ができます。
　Paragraphオブジェクトは段落に相当しますので、行間の空きや、段落単位でのフォントの指定ができます。

(2)XSL-FOでは、テキストを出力する時は、fo:inlineやfo:blockなどのオブジェクトを使います。fo:inlineが、iTextのChunkオブジェクトに、fo:blockがiTextのParagraphオブジェクトに相当します。
XSL-FOではフォント名、フォントのサイズ、スタイルなどはfo:inlineやfo:blockの属性として指定します。例えば次のようになります。

<fo:block text-align="center" font-size="15pt" font-weight="bold" background-color="black" color="white">Extension for Line Numbering</fo:block>

さて、iTextでできて、現在のXSL-FOの組版エンジンでできないのは、PageEventでしょう。
iTextのチュートリアルには次のような例が載っています。
public void onGenericTag(PdfWriter writer, Document document, Rectangle rect, String text) {
if ("ellipse".equals(text)) {
.... }
else if ("box".equals(text)) {
... }
}
これは、渡される文字列の内容を見て処理を変更する例です。
また、w = c.getWidthPoint();という関数で文字列の幅を取得して、プログラムの中で計算する例も出ています。

このような組版対象オブジェクトのコンテンツの内容をみてダイナミックに処理を変更するプログラミングは現在のXSL-FOではできません。iTextの良いところは、XSL-FOでも積極的に取り入れて、将来の拡張を検討しなければならないと思います。

５．表の出力
次に表の出力を見てみます。
(1) iTextでの表は、PdfTabke、PdfCellオブジェクトを使って出力します。
チュートリアルの一番簡単な例を見ましょう。

PdfPTable table = new PdfPTable(3);
PdfPCell cell =
new PdfPCell(new Paragraph("header with colspan 3"));
cell.setColspan(3);
table.addCell(cell);
table.addCell("1.1");
table.addCell("2.1");
table.addCell("3.1");
table.addCell("1.2");
table.addCell("2.2");
table.addCell("3.2");
document.add(table);

としますと、次のような簡単な表ができます。

この方法はシンプルですが、例えば、複数のセルを行方向で結合するのは困難になります。行方向のセル結合は、テーブルの入れ子機能を使うようです。

(2)XSL-FOでの表は次のようになります。

<fo:table-and-caption>
<fo:table>
<fo:table-body>
<fo:table-row>
<fo:table-cell number-columns-spanned="3" border-style="solid" border-width="0.5mm" ><fo:block>header with colspan 3</fo:block></fo:table-cell>
</fo:table-row>
<fo:table-row>
<fo:table-cell border-style="solid" border-width="0.5mm" ><fo:block>1.1</fo:block></fo:table-cell>
<fo:table-cell border-style="solid" border-width="0.5mm" ><fo:block>2.1</fo:block></fo:table-cell>
<fo:table-cell border-style="solid" border-width="0.5mm" ><fo:block>3.1</fo:block></fo:table-cell>
</fo:table-row>
<fo:table-row>
<fo:table-cell border-style="solid" border-width="0.5mm" ><fo:block>1.2</fo:block></fo:table-cell>
<fo:table-cell border-style="solid" border-width="0.5mm" ><fo:block>2.2</fo:block></fo:table-cell><fo:table-cell border-style="solid" border-width="0.5mm" ><fo:block>3.2</fo:block></fo:table-cell>
</fo:table-row>
</fo:table-body>
</fo:table></fo:table-and-caption>

XSL-FOの方はHTMLと同じように表全部を予め作っておくことになります。この作り方から見ますと、複雑なレイアウトの表をiTextで作るのは相当に難しいのではないかと予想します。

投稿者 koba : 08:00 | コメント (1) | トラックバック

2006年02月23日

XSL-FO仕様が勧告仕様になりました

W3Cが、現在、仕様の改訂作業を行っているExtensible Stylesheet Language V1.1 が2月21日(日本時間)に勧告候補（CR）になりました。

CR仕様書は、下記に公開されています。

Extensible Stylesheet Language (XSL) Version 1.1
W3C Candidate Recommendation 20 February 2006
http://www.w3.org/TR/xsl11/

今回の改訂では、次のような項目が新しく仕様として盛り込まれました。
* Change marks
　チェンジ・バーとも言います。改訂箇所を示すために使われるもので、アメリカの軍のドキュメントの規格がベースになっているようです。日本の法律文書などは、新旧対照表を作って管理するようですが、米国では新旧対照表を作るという習慣はないと聞いています。
* "Back of the book" index.
　書籍等の巻末索引を作成するための仕様です。この巻末索引の仕様は非常に重要なもので、XSL-FO組版エンジンの主要ベンダは巻末索引を独自に拡張していましたが、V1.1で標準化されることになります。(但し、縦書の上、中、下段なんてのはないですね。これは提案しないといけないでしょう。）
* Bookmarks.
　PDFのしおりを作成するための機能です。実際のところ、XSL-FO組版エンジンの出力は殆どPDFです。XSL-FO V1.0ではしおりを定義する機能がなかったため、PDFのしおり作成機能をXSL-FO組版主要エンジンが独自拡張していたのですが、V1.1で標準化されます。
* "Markers"
　マーカー機能が拡張されます。
　XSL-FOにはfo:marker/fo:retrieve-markerという機能があり、ページ単位でのランニング・ヘッダやランニング・フッタ作成、等のために使うことができました。表が次のページ/段に続く、前のページ/段から続くとか、あるいは、小計の表示をする機能などが欲しい、という要望が多く寄せられています。V1.1でマーカーの機能が強化されて、表の継続を示す用途などに使えるようになります。
* Multiple flows.
　これまで、内容オブジェクトのフローは単一で、流し込む領域はfo:region-bodyという本文領域のみでした。V1.1から複数のフローを定義可能になりました。

図　マルチフローの例

上の図のように、用紙マスターに複数の領域を定義しておき、内容オブジェクトのフローを複数用意し、各々流し込みする領域を対応つけることができます。この機能は、FrameMakerから持ってきたものと思いますが、かなり複雑なレイアウトが可能になるでしょう。

　この他、次のオブジェクトが追加になっています。
* fo:page-sequence-wrapper.
* fo:page-number-citation-last.

　また、プロパティの拡張も幾つかあります。
* graphic の拡大縮小の条件付け.
* page-position の属性に新しく "only" という値を追加
* clear、floatの属性に "inside" と "outside" を追加
* ページ番号に、接頭辞、接尾辞を指定可能に
　ページ番号は、folio-numberに変更になりました。

CRは仕様として安定した状態で、ベンダーに対して実装を呼びかけるステップです。
W3Cの仕様策定ステップ

CRの予定期間は5月31日までとなっています。W3Cは、この間に、ベンダーの実装レポートの提出を求めています。
現時点での予備的な実装レポート

追加された仕様の項目毎に最低２つのベンダが実装することが必要です。
アンテナハウスは世界で唯一、すでにXSL-FO V1.1 追加仕様の実装をすべて完了しています。

本日、XSL Formatter V4.0 Alpha2 版を公開しました。α版としていますのは、リリースまでにいろいろと改良予定があるためです。XSL-FOの実装については問題なく評価していただくことができますので、ぜひお試しになってみてください。

また、アンテナハウスでは、2月27日（月曜日）16:00より多言語組版研究会を開催します。ここで、XSL-FO V1.1 で追加された仕様についての勉強会を行なう予定です。まだ、席の余裕がありますので、ぜひご参加くださいますよう。

お申し込みはこちらからどうぞ。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年02月22日

iTextとXSL-FOのページ生成方法を比較する

iTextとXSL-FOの比較を続けてみます。

２．ドキュメントの用紙サイズとマージン設定
(1)iTextでは、次のようにドキュメント・コンストラクタで文書のページを指定します。
public Document(Rectangle pageSize,
int marginLeft,
int marginRight,
int marginTop,
int marginBottom);

ページサイズは、標準形式（A0-A10）など、あるいは寸法で指定します。標準はポートレイトですが、回転してランドスケープにすることができます。

マージンは省略すると36ポイントになります。
document.setMargins(180, 108, 72, 36);
のように直接指定もできます。

document.setMarginMirroring(true);
で左右対称マージンの指定ができます。

(2)XSL-FOではページは、fo:simple-page-masterで指定します。
fo:simple-page-masterはページの中に本文領域fo:region-bodyをもち、ここに文章が配置されます。マージンは、fo:simple-page-masterとfo:region-bodyの両方に属性として指定します。

図 fo:simple-page-master

マージンを変更するにはfo:simple-page-masterを別のものに切り替えます。左右ページのマージンを対称にするには、右ページ用のマージンを定義したfo:simple-page-masterと左ページ用のマージンを定義したfo:simple-page-masterを用意し、その出現順序を指定したfo:page-sequence-masterというものを定義して用紙マスターとして使います。

３．ページの生成
(1)iTextでは、ページに章、節、段落、表などのコンテンツをプログラムで出力していきます。内容がページの中で一杯になるとiTextが自動的に新しいページを生成します。
document.setPageSize();
でページの大きさを変えたり、
document.setMargins();
でページに対して、明示的にマージンを指定すると自動的に改ページされ新しいページができます。
また、document.newPage().
で強制的に新しいページを作り出すことができます。

この他、新しい章や節を作るときに改ページすることもできるようです。いずれにしても、プログラムの中で比較的直接的にページを作成したり改ページする制御を行います。

(2)XSL-FOでは、用紙マスターを定義するfo:layout-master-setのツリーとページの中に配置する内容オブジェクトfo:page-sequenceのツリーを用意して、各内容の枝に対して、それを流し込む用紙マスターを関連付けておきます。

XSL-FO組版エンジンは、fo:page-sequenceの内容オブジェクトをページの中に流し込むことでレイアウト済みのページを作り出します。

例えば、左右ページのマージンを対称にするには、左右ページ用のfo:simple-page-masterをもつfo:page-sequence-masterを用紙マスターとして使います。この用紙マスターに、内容オブジェクトを流し込んでいくと、生成されるページが奇数ページ、偶数ページかで用紙が切り替わります。これによって、左右マージンが対称になる、という仕組みです。

こうしてみますと、ページを作り出す仕組みは２つのソフトでまったく違っていることが分かります。iTextの方法は直感的・直接的ですが、複雑なページ・レイアウトやページ・シーケンスを内容オブジェクトと独立に定義していくのが難しいように思います。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年02月20日

iTextの機能概要

次に、iTextでできることを調べてみます。

iTextは、オンラインのチュートリアルが充実していることが特徴です。機能説明のみでなく、簡単なJavaのサンプル・プログラムでできあがったPDFのサンプルが多数提供されています：
Tutorial: iText by Example

これは良い点で、チュートリアルを見てますと直ぐにできそうに思えてきますし、大いに学ぶべきところです。

(1) iTextの基本機能はPdfWriterです。
Documentオブジェクトにテキストやイメージをセットして、PDFを生成します。この時、ページの大きさをセットしたり、ランドスケープとポートレートの切り替えができます。ページの背景色、マージンの設定、マージンの左右対称指定、PDFのメタデータ設定、セキュリティ設定ができます。但し、これらの機能は基本的なもので、あまり見るべきものはありません。

ちょっと面白いのは、PDF、RTF、HTMLのWriterをもっていてひとつのソースから同時に3種類の出力ができることでしょう。

(2) 既存PDFを読み込んでコピーしたり、ページ番号やウオーターマークを付加する。
・PdfWriterには、既存PDFのページを取り込む(Importする)機能があります。但し、Importされたページの注釈、しおりなどの対話機能は失われます。
・PdfStamperで、既存PDFにページ番号やウオーターマークを付加したり、フォーム・フィールドに記入したり、フォームフィールドを平坦化して書き込めなくしたり、PDFに署名を追加、暗号化などができます。
・PdfCopyでは、既存のPDFの結合ができます。異なるAcroFormをもつPDFを結合するにはPdfCopyFileldを使います。

iTextのオブジェクト
iTextのPDF出力はチャンク（文字の塊）、パラグラフ、フレーズ、リスト、フォント、アンカー、しおり、イメージ、表、カラムなどのオブジェクト単位で設定します。
・チャンク—同じフォント、フォントサイズ、色などの属性をもつ文字列。チャンク単位で、アンダーラインを指定したり、上付・下付指定したり、背景色を指定などができる。
・パラグラフ—段落の文字列。異なる属性をもつチャンクをつなげて作ることもできる。
・リスト—HTMLの箇条書き同様なオブジェクトです。
・アンカー—PDFでのリモート/ローカルのジャンプ先、ジャンプ先でのアクションなどを指定する。
・表—表の行やセルをPDFに出力するオブジェクト。

こういうオブジェクトを使って、JAVAのプログラムを記述すると、iTextがオブジェクトをページの上に適切に配置してPDFを生成します。

ざっと見たところ、XSL-FOにも同じようなオブジェクトがありますが、XSL-FOのオブジェクトは組版という観点から設計されているのに対して、iTextのオブジェクトはPDFから、つまり出力するデータから設計されているように思います。つまり両者のオブジェクトの設計思想には根本的な違いがあり、iTextの方が低レベル（インテリジェンスが低い、あるいは組版エンジンが初歩的という表現が良いかもしれません）のオブジェクトのようです。このあたりは、別途検討してみたいところです。

ただし、PDFに近いだけに、アンカー・オブジェクトなどはXSL-FOよりは機能が多くなっているようです。（XSL Formatter の場合は、XSL-FO仕様を独自拡張して、同様の機能を追加しています）。

直接的なコンテント
iTextは、PdfContentByteクラスを使って、PDFのページの中の指定した位置に、グラフィックス、テキストをに直接データを書き込むことができます。但し、この機能を扱うにはPDF Referenceを理解している必要があるようです。

RTFとHTMLの出力
ページの内容をPDFに出力するだけではなく、RTFとHTMLにも出力できます。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年02月19日

Java用PDF生成ライブラリー iTextの調査

WebサイトでPDFをダイレクトに生成するライブラリーはいろいろあります。2005年11月12日 PDFの作成方法（9） – PDF出力ライブラリーで取り上げたPDFLibは有名なものですが、Java用のライブラリーとしてiTextも時々名前を聞きます。オープンソースなので使っている人が多いかもしれません。

XSL Formatterも50%以上のユーザがWebサイトでXMLからPDF生成に使っています。

ある航空機メーカでは、現在、ASPサービスにXSL Formatterを使っています。そこではFormatterで作成したPDFに対してiTextでさらに加工を加えてからPDFを配信しているようです。しかし、パーフォーマンを上げるために、iTextでやっていることをFormatterに吸収できないかという話がありました。

一般論として、メンテナンスやパーフォーマンスを問わなければ、Formatterの出力をiTextに入力するという2段階で良いことになるのでしょうが、やはりパーフォーマンスを上げていこうとすると一つのツールに統合したくなります。

こう考えるとミドルウェアも高機能が求められるということになります。そうするとツール・メーカとしては、どんどん投資して他のツールの機能を吸収していかないとだめってことになります。

そんなわけで、iTextについてチェックしてみました。iTextの機能の中で、吸収するべき部分があるのでしょうか。

iTextとはなに？
iTextは、JavaでPDFを生成するためのライブラリーです。オリジナル開発者は、Bruno Lowagie（35歳、オランダ人らしい）、現在、もっとも積極的に活動している開発者はPaulo Soaresです。他に2人の開発者がいます。

SourceForgeにホームページがあります。2000年11月から始まっていますので、既に5年を経過しています。
・現在のバージョンは、iText 1.3.6 (2005/12/12リリース）
・その前のバージョンは、iText 1.3.5 (2005/10/20リリース)
・もう一つ前が、iText 1.3.4 (2005/09/22リリース)
・2005/07/29には、iText 1.3.2 をリリース、Bruno LowagieはManning Publications社と契約して、'iText in Action'という本を書き始めたというニュースが出ています。
※最後の0.0.1のアップグレードはメンテナンス・リリース（主としてバグ修正）のようです。

こういうリリース経過、内容、バグフィックス、CVSへのコミットの記録をみると結構積極的に活動しているようです。オープン・ソース・プロジェクトは、最初は活動が活発でもだんだんしぼんでしまうものが多いですが、5年経過して積極的にやっているのは立派なものです。但し、2000年に始まって、2003年6月にV1.0が出ていますので、商業ソフトと比べると足が遅いと思います。商業ソフトならば、このスピードでは生きていけないでしょう。

iTextで興味深いのは、.NET版であるiTextSharpがあるということです。これは、J#を使ってJAVAから移植したものです。

iTextのホームページのPeopleでは、日本の氏原 一哉さんが、iText.NETの著者として紹介されています。iTextSharpとiText.NETの関係は良くわかりません。

バックグラウンドについての紹介はこの位にして、次に機能を見てみましょう。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年02月12日

もっともsuckでないソフト

YahooのXSL-FOグループのメーリング・リストにShameless Self Promotionという風変わりなメッセージが投稿されました。投稿者を見ますと、Eliot KimberさんというTexasのXMLドキュメントの仕事をしているコンサルタントです。

こんど、XMLとそれに関連する技術的な話題についての個人ブログをはじめたので、見てくれという投稿です。ブログはこちらです：
http://drmacros-xml-rants.blogspot.com/

タイトルが面白い。

DR. MACRO'S XML RANTS

Rantという単語は知りませんでしたが、辞書を引くと「どなること・大言壮語」ってあります。なるほど。納得です。数年前、シカゴの同業のコンサルタントの事務所を訪問したのですが、その人に、Kimberさんってどんな人？と聞きましたら、曰く「丘の上にのぼって叫ぶ人だよ」とのこと。

このブログはまさしくその形容が当てはまります。

Kimberさんのプロフィールによりますと、大学を卒業後、IBMのリサーチ・トライアングルでテクニカル・ライターの仕事を始めてから、25年間マークアップ言語をベースとする執筆と出版 — この日本語は、あまり適切ではないかもしれません。テクニカルライティングというとマニュアル類の制作が多いのだろうと思います。— に携わった。SGMLやXML関係の仕様の制定にも数多く関与し、現在は、XSL-FOのV1.1仕様のサブ・ワーキンググループのメンバーとしても積極的に参加している人です。

すべてのツールはsuck

このsuckって単語は、私の使っている35年前の三省堂の辞書には載っていませんが、Webで調べると、むかつくほどひどいという意味です。

彼によると、標準をサポートするソフトウェアで、標準が要求することを完全にサポートしているものはなく、また、大抵のソフトウェアにはバグがあり、パフォーマンスが悪いなどの問題があるので、必然的に、すべてのソフトウェア製品はむかつくほどひどいってことになるとのこと。

その中で、suckでない（ひどくない）製品の基準は、

(1) 標準をどれだけサポートしているか。特にユーザにとって必要な要求をサポートしている程度が高ければ高いほどsuckじゃない。

(2) ソフトウエアの工学的にみて優れていて、パーフォーマンスが高く、バグが少なく、コストパーフォーマンスが良く、サポートが良く、ドキュメンテーションが良く、インテグレーションがし易いほどsuckじゃない。

で、その次の記事は：
比較的suckじゃない、幾つかのツール

ここで、トップに彼が出会ったツールの中で最もsuckじゃないツールとしてAntenna House XSL Formatterを紹介してくれました。

言い換えますと、Antenna House XSL Formatterが最も良いツールだと言ってくれたわけです。

XSL-FOは標準仕様になってから、満4年半が経過して、20種類近くの実装が出てきています（2006年02月08日 XSL V1.1 仕様についての多言語組版研究会開催を参照）。

その中で世界NO.1というのは、自分で言うのもなんですが、オリンピックの金メダルに相当すると言っても良いと思います。ちょうど、今、トリノ・オリンピックですが。

オリンピックの金メダルと違って、ビジネスの金メダルは、毎日が戦いです。チャンピオン・シップを過去のものにしないように、今後も、さらに精進したいものです。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2006年01月08日

日本語の表記は世界で最も難しい？

”The Story of Writing” (Andrew Robinson著、Thames & Hudson Ltd.、ISBN0-500-28156-4, 1995年発行)と言う本は、考古学の対象になる古代の文字から、現代の主な文字と表記法について、350点の写真を交えて解説しているとても楽しい本です。

その中で、第12章が日本の表記法の説明になっています。10数ページに渡る説明がなされているのですが、その中で、日本の表記法が「世界で最も複雑」という表題が付いています。

日本語表記が世界で一番複雑という見出し

※The Story of Writing, p.205より

この中では、次のような日本語の表記の特徴を挙げています。

①日本語は中国語とはまったく違う言語なのに、表記に中国から渡ってきた漢字を応用している。

②漢字には、日本独自の音読みと、中国伝来の訓読みがあり、二通りの読みを使い分けている。

③日本人は漢字をもとに、50音を表記するひらがなを発明した。その上で西欧の言語が、アルファベットで表記するように、ひらがなだけで書けば良いのにわざわざ、漢字かな混じり文で表記している。

④ひらがなとカタカナの2種類の音節文字表をもっている。そして日本人は、用途に応じて、ひらがなとカタカナを使い分けている。

⑤1980年代には、ローマ字表記のアルファベットが、広告を通じて日本の表記法に広がった。最近の日本人は、ローマ字表記も使い分けている。

⑥普通の日本人は2,000種類の漢字を覚えているが、5,000種類もの漢字を覚えないと教育レベルの高い人とは言えない。

などなど。

日本語の表記の難しさを説明した上で、コンピュータ化の必要性が高まるにつれて、いつの日か漢字を捨てるに違いない、などと書いています。

外国人から見ますと、このように日本語では様々な文字を混在させ、しかも同じことを表記するのに、用途に応じて複数の文字を使い分けた表記ができるのは奇跡的に見えるようです。

投稿者 koba : 08:00 | コメント (5) | トラックバック

2005年12月05日

PDFの書籍一覧

現在、国内で販売されているPDFに関する書籍についてまとめてみました。

一覧は以下のように記述しています。
　書籍名（Amazon.co.jpにリンクしています）
　（著者、税込価格、出版社、ISBN、発売日）

【基本・入門】
はじめてのAcrobat 7.0
（大沢 文孝、1,995円、工学社、4777511413、2005/06）

ビジネスで活用するAcrobat 7.0入門
（Professional DTP編集部、2,415円、工学社、4777510980、2005/01）

WindowsユーザーのためのPDF＆Acrobat7.0入門
（福田 良一、2,310円、オーム社、4274500209、2005/04/25）

事例引きPDF「作成・編集」ハンドブック
（森里 悠、1,680円、新紀元社、4775300458、2002/01）

【DTP】
Word+Acrobat DTP出力実践ガイドブック
（山木 大志、2,940円、毎日コミュニケーションズ、4839918392、2005/10）

クロスメディアパブリッシング FrameMaker7.0/Windows版
（臼井 理栄、4,200円、九天社、4901676415、2003/06）

最新WindowsDTP標準テキスト
（黒田 聡、永山 嘉昭、2,940円、日経BP社、4822281361、2002/05）

pdf+print2.0―PDFプリプレス読本
（Bernd Zipper、2,625円、工学社、4875934297、2003/06）

Acrobat6.0+PDF パワー・クリエイターズ・ガイド
（諌山 研一、チバ ヒデトシ、大橋 幸二、2,520円、アスペクト、4757209924、2003/09）

最新WindowsDTP標準テキスト
（黒田 聡、永山 嘉昭、2,940円、日経BP社、4822281361、2002/05）

DTP実務者のためのAcrobat PDF活用ガイド
（上高地 仁、2,940円、毎日コミュニケーションズ、483990698X、2002/03）

【仕様】
PDFリファレンス第2版 - Adobe Portable Document Format Version 1.3
（アドビシステムズ、7,140円、ピアソンエデュケーション、4894713381、2001/09）

【その他】
PDF Hacks
（Sid Steward、2,520円、オライリー・ジャパン、4873112222、2005/03）

PDFでスッキリ!情報アイデア整理術
（宝島社、1,155円、宝島社、4796648259、2005/08/29）

図解でわかるAcrobat・PDFのすべて
（山名 一郎、蛭田 龍郎、2,100円、日本実業出版社、4534030509、2000/03）

TEX+PHP+データベースによるPDF自動生成サーバの構築/運用
（ミッチー@rootbox、3,129円、技術評論社、4774121754、2004/11）

ユビキタスドキュメントがビジネスを超速化する!
（中島 洋、ユビキタスドキュメント研究会、1,260円、実業之日本社、4408106321、2005/07）

PostScript & Acrobat/PDF
（Thomas Merz、5,775円、東京電機大学出版局、4501528907、1998/11）

投稿者 numata : 08:00 | トラックバック

2005年11月13日

PDF on the flyを1996年に考えた！

PDFLibの創業者　ThomasMerz氏の著書を調べてみました。英語で書かれているものは2冊のようです。

最初の著書は1996年ですから、日本語のAcrobatが出る前というかなり早い時期に書かれています。

今年の12月に同じタイトルの本が出る予定になっています。内容が改訂されるのでしょうか？興味ありますね。

2冊とも、広田　健一郎氏が翻訳して、東京電機大学から出版されています。

【和書】
ＰｏｓｔＳｃｒｉｐｔ＆Ａｃｒｏｂａｔ／ＰＤＦ
トーマス・マーツ 著 / 広田　健一郎 訳
B5変 488頁
定価5,775円（本体＋税）
ISBN4-501-52890-7
発行元：東京電機大学出版局

インターネットのためのＡｃｒｏｂａｔ／ＰＤＦ
トーマス・マーツ 著 / 広田　健一郎 訳
B5変 288頁
定価3,675円（本体＋税）
ISBN4-501-53020-0
発行元：東京電機大学出版局

【洋書(英語）】
Postscript & Acrobat/Pdf: Applications, Troubleshooting, and Cross-Platform Publishing
Thomas Merz (著)
発行年月：1996年10月
発行元：Springer-Verlag

Postscript and Acrobat/Pdf Bible: Applications, Troubleshooting and Cross-Platform Publishing
Thomas Merz (著)
発行年月：2005年12月31日（予定)
発行元：Springer-Verlag

Web Publishing With Acrobat/Pdf
Thomas Merz (著)
ペーパーバック
発行年：1998年03月30日
発行元：Springer Verlag

ドイツ語の本は他にもあるようですが、省略します。

また、PlanetPDFにインタビュー（2004年9月8日）が載っています。
PDF Master: Thomas Merz's Take on PDF and Acrobat

○ポイント
・引用(1)：
In 1996 I started working on a software library called PDFlib, and created the slogan "PDF on the fly"

1996年にPDFLibの開発を開始、PDF on the flyというスローガンを創造した。

・引用(2)：
I believe that the ability to store document structure information within PDF (Tagged PDF) will be perceived as the most significant change in the long term.

TaggedPDFが、長期的にみて最も重要になるだろうと考えている。

う～ん。それにしても、PDF on the fly というコンセプトを1996年に考えるというのはたいしたものですね。

投稿者 koba : 08:00 | コメント (0) | トラックバック

2005年11月11日

PDF資料の紹介

PDFの資料　2点のご紹介です。

１．新しい書籍
　　「Word+Acrobat DTP出力実践ガイドブック」毎日コミュニケーションズ刊
　　（山木大志著、2,940円（税込）、B5変型判　272ページ、ISBN4-8399-1839-2　2005年10月21日発売）

2．PDFConferenceのプレゼンテーション資料
PlanetPDFに公開されてます。

・「Word+Acrobat DTP出力実践ガイドブック」　については、 MYCOMBOOKS立ち読みコーナーにあらましがあります。

Microsoft Wordで作成した文書を、そのまま印刷にもっていきたい、という人のための本だそうです。このようなことを考えている人は多いと思いますが、読んでみたい本です。

・2005年9月に米国ワシントンDCで開かれた「PDF Conference」のプレゼンテーション資料は、参加者には、9月下旬にオリジナル資料のURLを送ってきたのですが、PDF ConferenceのWebページには公開されてないので、てっきり、非公開と思っていました。最近、PlanetPDFのWebページに一部が公開されているのを見つけました。PlanetPDFは、PDF ConferenceのGold Sponsorですものね。

"Adobe Acrobat 7 PDF Bible" 、"Adobe Reader 7 Revealed"の著者 Ted Padovaさん（この人は会議での講演者の主演級）の資料など、貴重な資料です。

投稿者 koba : 08:00 | コメント (0) | トラックバック