昨日に続いて、TextPorter V5.2について、述べます。
　「V5.2の改訂情報」をみて、PDFが非常に多いことにお気づきと思います。
　これらは、前回のブログ担当だったときに書いた「PDFからのテキスト抽出で困っていること」に書いた、コマッタチャンなPDFによって発生したバグの修正です。
　ちゃんとしたソフトで、人間がPDFを作っていれば、異常な長さの文字列を含むPDFなどできないはずですが、いま、コンピュータがいろんな文章やデータをかき集めてPDFを生成したり、PDFをあれこれ加工するようになっています。
　その過程で使われているソフトにバグがあると、とんでもないPDFができてしまうのです。
　以前は、少しでも壊れていると思われるPDFは、テキストの抽出処理をやめて、エラーにしていました。そのころは、コンピュータがPDFを自動生成することも少なく、平和な時代でした。
　PDFが普及するにつれ、コンピュータによる自動生成も増えてきました。お客様から、すぐにエラーにするのではなく、少しでも中身を知りたいから、壊れたPDFからもテキストを抽出してくれないかという要望が出てくるようになりました。
　PDF乱世の時代です。
　そこで、なるべく処理を続行するようにしました。つまり、エラーとする制限をゆるくしたわけです。すると、こちらが想定していないPDFにも遭遇する確率が、一気に上がってしまったわけです。
　PDFの抽出エンジンは、バグが出尽くして、かなり枯れたと思っていましたが、PDF乱世に対応したことで、バグが出るようになってしまったのです。
　時代の要請とはいえ、苦労が絶えません。
　TextPorterについての詳しい説明は、
TextPorter
をご覧ください。
　TextPorterをはじめ、アンテナハウスのシステム製品につきましては、事前に技術相談会を行っております。お気軽にお問い合わせください。
　詳しくは、
アンテナハウス　システム製品技術相談会
をご覧の上、お申し込みください。

Tweet

　昨年10月のブログ担当の日から、今日までの間に、TextPorter V5.2を出荷しましたので、V5.2について、述べます。
　TextPorterをご存じない人のために説明すると、TextPorterは、クラウドコンピューティング時代のサーバ組込用テキスト抽出エンジンです。何ができるかを一言でいうと、Word, Excel, PDFなど色々なアプリケーションのファイルから文字列を抜き出してくるソフトです。
●　V5.2の機能追加は、以下の通りです。
・Outlook 2003のUnicodeに対応
・Outlook 2007/2010に対応
　　エンジンは、dmc_txmsg2007, dmc_txmsg2010
・OpenOffice.org 3.3に対応
　　識別文字列(DocFormat)は、従来と同じ。
・Libre Office 3.3/3.4に対応
　　識別文字列(DocFormat)は、OpenOffice.orgと同じ。
・Visio 2010に対応
　　識別文字列(DocFormat)は、”Visio 2003/2007/2010″に変更。
　Outlook 2003のUnicode対応は、これまで要望がなかったのですが、Outlook 2007/2010に対応する際に、Unicode対応もすることになり、そういう時期に、お客様からの要望も来ましたので、渡りに船とばかりに対応しました。
　OpenOffice.orgとLibre Officeの関係は、なかなか複雑です。
　ご存知の方もいらっしゃるでしょうが、OpenOffice.orgは、元々、米Sun Microsystems社(以下、Sun)が支援して、開発が進められてきたオフィスソフトで、Microsoft Officeの代わりになるものです。
　米Oracle社(以下、Oracle)がSunを買収したことによって、OpenOffice.orgの先行きが不透明になりました。Oracleは、オープンソースに積極的ではないと思われているからです。そのため、Oracleによる支配を嫌ったOpenOffice.orgの開発者たちがスピンアウトして、立ち上げたプロジェクトが、Libre Officeです。
　Oracleは、OpenOffice.orgのソースコードなどを、オープンソース開発の一大拠点であるApache Software Foundationに寄贈することになりましたが、Libre Officeとの関係が今度どうなるか、注目です。
　OpenOffice.orgは、地方自治体、公共機関などでよく使われており、TextPorterもサポートしているのですが、まだ日が浅いLibre Officeもすでに採用を始めている地方自治体があり、V5.2でサポートすることになりました。
　弊社としては、OpenOffice.orgもLibre Officeも、お客様のご要望があれば対応していくスタンスです。
　なお、Libre Officeのサポートは、V5.2からになります。
　古いバージョンをお持ちの方は、バージョンアップをお願いします。
関連：
http://iiyu.asablo.jp/blog/2011/12/10/6238858
JA福岡市がLibreOffice導入、MS Officeから移行で約840万円削減見込む
　TextPorterについての詳しい説明は、
TextPorter
をご覧ください。
　TextPorterをはじめ、アンテナハウスのシステム製品につきましては、事前に技術相談会を行っております。お気軽にお問い合わせください。
　詳しくは、
アンテナハウス　システム製品技術相談会
をご覧の上、お申し込みください。

Tweet

DITA コンソーシアムジャパン主催のDITA Festa 2012が、1月25日と26日二日間開催され、盛況のうちに終了しました。
今回のDITA Festaでは、従来に比べてさらに実践的な内容が多く報告されました。現在、日立で日米同時進行で進んでいるソフトウェアマニュアルのDITA化の中間報告は、まさにマニュアル制作現場の熱い戦いを臨場感をもって伝えるものでしたし、DITA ヨーロッパ2011の視察報告も、報告者の深い経験に基づく考察を踏まえたもので、単なる視察報告の域を超えたものでした。
しかし、それにもまして、強い印象をうけたのは日本企業の急速なグローバル展開と、マニュアル制作の危機とも言える現状です。
藤枝さんの市場分析の中で「DITA化したいドキュメントの展開言語数」のグラフに典型的に表れていましたが、2010年11月時点では「36言語以上」はゼロなのに対して、2011年6月の時点では、「36言語～40言語」が5社、「41言語以上」が2社となっています。多言語展開が大きな課題になっているのは明らかです。
技術的な製品であれば、ドキュメントは日本語と英語だけでもなんとかなりますが、コンシューマ製品になれば、現地の言葉でドキュメントを作るのは必須です。このため日本企業がコンシューマ製品を世界に展開していくときには、企業のグローバル化のスピードにあわせて同時に説明書の多言語化が必要となります。
「DITAユーザー交流会」の報告は、日本企業のマニュアル制作が総括されました。とりわけ、オムロンヘルスケア社のDITA検討状況の報告は、企業のグローバル展開が急速に進んでいるのに、ドキュメント制作体制が伴っていないために起きる状況を典型的に伝えています。同社は製品のグローバル展開を急速に進めていますが、その製品説明書はDTPで制作する体制をとっています。日本語だけであれば特に問題がないのでしょうが、DTP制作体制のままで内容をコピー＆ペースト方式で多言語化していったためにドキュメントの保守ができなくなり始めているようです。具体的には、本社の移転に伴う住所表記の変更作業が大きな日数とコストを要する作業になっているということがその一例です。この一例はDTPと手作業のままでマニュアルの多言語展開をしていくことの限界を象徴しています。
そういえば、DITAヨーロッパの視察報告の中で、SAPが企業を買収して製品群を自社の中に融合していく際にマニュアル制作方式の統一が必要になったという事例が報告されていました。
今回のDITA Festaでは、企業活動とマニュアル制作は密接な関係をもっていること、そして、グローバル化とM&Aという激しい流れに対応できるマニュアル制作体制の確立が必須になっている、ということに強い印象を受けました。
○DITA Festa2012

Tweet

サーバベース・コンバーター　V4よりMicrosoft Office(Word:docx/Excel:xlsx/Powerpoint:pptx、以下　Office) 2007/2010で読込パスワード設定したファイルの変換を対応します。
読込パスワードの対応に関しては、以前から国内外よりお問い合わせをいただいておりましたが、他の優先事項を差し置いて対応するには、あまりにも多くの期間が必要となることが予想され躊躇しておりました。
対応の契機としては、Microsoft社よりその情報が公開されたことが大きいです。その公開情報を使用することにより、弊社にて自力で対応する遙かに短期間で対応することができますので。

続きを読む →

Tweet

サーバベース・コンバーター　V4よりMicrosoft Word（以下、Word）が出力するRTF形式のファイルに対応します。
この機能は、主に海外からの要望が多かったのですが、国内においても社内で数種類のバージョンを使用している場合には、ル-ルとしてRTF形式に保存する場合や、Wordのバージョンによっては、拡張子がdocのままで中身がRTF形式と言ったように作成者側が意図しない形でRTF形式が使用されている場合も見られるとの報告を受けたために開発、実装に踏み切りました。

続きを読む →

Tweet

本日は、サーバベース・コンバーター　V4で対応するWindows 64bit版に関して情報をお出ししようかと考えておりましたが、それよりもMicrosoft Excel（以降、Excel）ファイルの読込に関しての機能強化の方が重要、且つ有用かと思い予定を変更してお伝えいたします。
今までのサーバベース・コンバーターでは、Excelファイルを読み込む際に変換先がどのような形式であれ、そのファイル内容を全て読込したからでないと変換が完了しませんでした。
*****
全て読込処理をしなければならないと言うことは、例えば、サムネイル用の画像ファイルが1ページ分だけ欲しい場合でも、全て読込を完了してから変換処理をおこなわざるを得ませんでした。
これは、Excelファイルのフォーマット形式（データの配置方法）に起因する問題で今までは、解決の術がありませんでした。
*****

続きを読む →

Tweet

PDFの変換に関しては、「PDFから（入力）」「PDFへ（出力）」共に非常に多くお問い合わせ、及び引き合いをいただいております。
PDFは、Adobe社のソフトウエアにより作成されることが有名ですが、2008年7月にはISO 32000-1として標準化され様々なソフトウエアより作成されるようになってきました。
（2008年7月以前にも弊社製品を含む様々ソフトウエアで作成されてはおりましたが）
様々なソフトウエアで作成されるということは、中には特殊な作り方で作成している場合や一部欠損している場合などが見受けられるようになり、サーバベースコンバータでも、その処理に苦労することが有りました。
また、「PDFから（入力）」「PDFへ（出力）」共にその再現性に関しても、時が立つに連れより高いレベルでのご要望をいただくことが多くなってきました。
そこで、弊社社内のエースに「PDFから（入力）」に関しての見直しをアサインし、「より正確に」「より高速に」「より安定した」ライブラリを作成することに成功しました。
サーバベースコンバータは、その名のとおり、サーバマシン上のシステム、及びアプリケーションにご採用される場合が多く、また大規模システムなどでは、高速性も求められております。
今回の新ライブラリの採用により、今までよりもさらにその性能をご評価いただけると確信しております。
３月にリリースする「サーバベースコンバータ　V4」にてその性能をお試しいただけますようお願いいたします。
・現行製品　
　「サーバベースコンバータ　V3.1」です。
　評価版もご用意しております。
　
・デモサイト
　変換結果をメール返信、及びサムネイルの作成がお試しいただけます

Tweet

サーバベース・コンバーターに関しての第3回目です。
今回は、次期V4で実装予定の機能に関してご紹介いたします。
V4に関しては、2012/3月中旬にリリースを予定しており、以下の機能を実装するために取り組んでおります。
＜実装予定機能＞
1.PDF処理に関しての最適化
2.Windows 64bit版モジュール
3.Microsoft RTF読込対応
4.Office パスワード付きファイルに関するエラー情報変更
5.Office 2007/2010 読み取りパスワード設定ファイル読込対応
上記の内「4.」「5.」に関しては、関連性が高いため1つの事項と考え、4回に分けてご紹介してゆきます。

Tweet

PDFに繰り返し同じ色の図形を描いたり、同じフォントサイズの文字を繰り返し記入したいとき、「書けまっせPDF5」では記入後に設定値を変更する方法と、記入する前に設定値（初期値）を変更して記入する方法があります。
「書けまっせPDF」ではテキストボックス（文字を入力する）やさまざまな図形、写真などの画像、印影などを張り付けることができます。それらを作成する際、文字ならサイズやフォントの種類、図形なら線の色や太さといった設定値が必要になります。
そうした設定情報の初期値が「書けまっせPDF」では事前に設定されていますので、「書けまっせPDF」を初めて使うときには、それらの初期値が使われます。
文字を入力した後や図形を描画した後に、自由に設定情報を変更することもできますが、毎度変更するのも面倒ですね。書く前（描画する前）に事前に初期値を変更できれば、次からはその設定値が使われるので便利です。
「書けまっせPDF5」では、ツールバー上で追記したいオブジェクトのボタンをクリックしてツールを選択した時点で、そのオブジェクトの初期設定を変更することができます。たとえば、ツールバーで「四角」を選択するとプロパティーペインでは「四角」の初期値（初期設定値）
の変更ができます。その後、四角を描画すると、変更した初期値で四角が表示されます。
描画直後は四角形が選択された状態になっています。その時のプロパティペインは、選択した四角形の設定値が表示されています。つまり、オブジェクトを選択しているときのプロパティペインはその選択しているオブジェクトの情報を表示し、オブジェクトの設定を変更することができます。
オブジェクトボタンを押しただけで、オブジェクトが選択されていない状態では、オブジェクトの初期値がプロパティペインに表示され、初期値が変更できる仕組みになっています。
「書けまっせPDF5」の詳細はこちらをご覧ください。

Tweet

数字や日付、番号などを記入する用紙には、文字を記入するための一文字ごとの記入枠（升目）が書かれています。確定申告の申請用紙はその代表的な例でしょう。郵便番号やクレジットカード番号の記入枠などにもよく使われます。
「記入枠をどのようにして作成するか」はPDFへの追記ツールの良し悪し、要ということができます。「書けまっせPDF」は、記入枠を作りたいところでクリックして自動生成するなど簡単に追記枠を作ることができます。ところが、確定申告の数字の枠や郵便番号などの枠をひとつずつ記入枠（テキストボックス）に置き換えてしまうと、数字を一枠一文字として入力しなければなりません。
そこで、手動で記入枠を作り、それぞれの枠をひとまとめにして一回で入力（ひとつづりの数字として入力する）するようにするようにしたらどうでしょう。
実は、ひとつの枠で記入枠の中心に文字がきちんと配置されるような処理は、ワープロや表計算ソフトなどでも簡単には実現できません。
ところが、「書けまっせPDF」を使うとこの処理がとても簡単に実現できます。

上図のように、作成した記入枠を選択して、必要な桁数をプロパティペインの「桁割」欄に入力します。
上の例では、枠にピタリと配置するために余白をゼロにして、フォントのサイズを自動で調整するようにしています。フォントの種類も自由に選択できます。
「書けまっせPDF5」の詳細はこちらをご覧ください。

Tweet