アリゾナ州フェニックス, オレゴン州ポートランド, 2010年 3月15日：　きたる ODAワールドカンファレンス 2010 にて、IntelliCAD技術コンソーシアム(ITC)が ODAプラットフォームをコアとして取込んだ新しい IntelliCAD7のプレゼンテーションをします。Open Design Alliance (ODA) は、この発表を大変嬉しく思います。カンファレンスでは、ITC開発マネージャ David Lorenzo によって 「IntelliCAD: An Open Source CAD Engine and Vertical Solutions Platform」 というタイトルでプレゼンテーションが行われる予定です。

ODA と ITC は、両者共に、コア技術とソースコードをそれぞれの組織のメンバーへ届ける独立した非営利組織です。この関係で、ODAはODAプラットホームをメンバーへ届け、ITCのようなODAメンバーが、技術系グラフィックス分野向けアプリケーションを作成することが可能となっています。

ITCは、ODAテクノロジーをIntelliCAD (エンジニア、デザイナーなどへ製品を届ける多くの会社によって使われているDWG互換CADプラットホーム) に取込んでいます。IntelliCAD 7 の新らしいアーキテクチャは、ODA プラットホームの性能、プログラミング機能の利点(アドバンテージ)をフルに使えるよう設計されています。全てのODAメンバーのうち、ごく少数のメンバーだけが ODAプラットホームの利点をフルに使って、完全なCADを開発しています。

ODA会長 Arnold van der Weide は、「ODAは、特にODAフラットホームのフル機能を使っているメンバーと有力な関係を作っています。コア技術の提供者として、ODAはエンドユーザーと直接コンタクトする機会がありませんので、エンドユーザーの要求をより良く理解するために、私達は我々のメンバーを協力しています。我々は学術機関になる余裕はありません。ITCの高品質な技術への献身は、ITCの絶え間ないソースコードの提供と、両者の開発/経営陣チーム間の密接な関係を通して、ODAプラットホームの前進を助けています」と述べています。

ITC会長 Robert McGill は、「ODAプラットホームの全てを IntelliCAD 7 へ取込む決断は、ITCにとっては非常に重要な戦略であり、ODAの開発チームと我々の開発チームが密接な関係を作ることが可能な唯一の手段でした。ODAは、その過去の栄冠にすがることなく、積極的にODAプラットホーム技術の発展を推し進めています。我々は、IntelliCADの成功に向け、長期的に大いなる貢献者としてODAフラットホームを支援し続けるでしょう」と述べています。

これに対し、ODA会長 Arnold van der Weide は、「IntelliCAD 7 Beta のリリースは、ITC と ODA そして ODAプラットホームの成果です。私達は、ITCが IntelliCADプロダクトを完成させ、より良いものにするために、ITCとの継続的な協力関係を楽しみにしています」と加えました。

http://www.opendesign.com/node/514

海外CAD事情のオリジナル著者である Ralph氏は、面白がって 「ODA and Bricscad form their own “ITC”」 などと書いてますが… (汗)

ODAは本来、そのメンバー会社と協力関係にあることが前提ですよね？ 「これまで協力する気はありませんでした… ごめんなさい」 とでも言いたいのだろうか？ ODA Arnold会長からすれば、 このニュースを出すことで、他のメンバーを牽制したい意図があったのかもしれません。

Deelip氏がブログで、わりと真相に近い事を語ってくれています。

http://www.deelip.com/?p=1561

現行 BricsCAD V10は、2010-DWGを読めません… なぜか？ BricsCADが使っているDWGdirectは、 2.6 （バージョンとしてはかなり古い） より分岐した独自のもので、ODAが現在提供している 2010-DWG に対応した DWGdirect 3.x 系 とは異なるからです。 2.x 系 の最終バージョンは、2.7 であるにも関わらず 2.6 を使い続けるのは、ODAのオリジナルソースとは乖離して戻せなくなってしまったのでしょう…  BricsCAD を 2010-DWG に対応させるには、3.x 系を採用しなければなりません。 舞台が ITC (IntelliCAD) から、ODAに移っただけとも… 独自路線を進めれば、末路はいつも同じ…

• これまで同様, オリジナルから分岐した独自ライブラリのメンテナンスを継続？
• ODAと協力して, 共用ライブラリのメンテナンスに貢献？

どちらを選ぶのか？

昨年４月に, Leiden (オランダ) で開催された 「ODA World Conference 2009」 が舞台でした。

Arnold会長は, ODAとして始めて開催するカンファレンスにおいて 「Unity (団結)」を強調しておりました… Bricsys は, 自分達が行った莫大な不具合修正を, ODAへ提出することに対して難色を示していたのですが… Alliance のメンバーとしてODA規則に従う限り, 道は１つしかありません。

貢献はメンバーとしての責務です。より多くの貢献をした会社が、より多くの利益を得られるという点については、その通りだと思います… Bricsys は、紛れも無く DWG互換 ソフトウェアビジネス を牽引している会社であることは誰もが認めている事。

他のメンバーを蹴落とし1人勝ちを目指すような行動に出ることなく, コンソーシアム/アライアンスメンバーのお手本であって欲しいと願っています。

最後は、Deelip の結語を引用させて頂きましょう…

Bottom line, the ODA platform as a whole will be strengthened and the non-AutoCAD DWG community will benefit from this cooperation.

Arnold plans on getting other ODA members to follow Bricsys’ footsteps. I wish him luck. After all, strength lies in unity.

結局のところ… 団結は力なり！

http://www.melma.com/backnumber_14168/

この原文を執筆されている Ralph Grabowski 氏 は、ITC, ODA の会合などで、何度かお見かけしたことがあります。 Ralph 氏のブログ> WorldCAD Access

upFront.eZine （毎週月曜日に発行）は、英語圏で CADに関わるビジネスをされている人であれば、ほとんどの人が読んでいると思われ… 私も主たる情報源となっております。

特別に、AutoCAD関連の話題に偏っているわけでもなく、最近は、世の中の流れから… 3D CADの話題が多いのですが、このところ、AutoCAD互換CADの動きが少し活発になっており… ITCにおいても、今週は、Ralph に何を書かれるんだろ？としばしば話題にしています。

今週号 （Issue #634） は、まだ日本語に訳されておりませんが、なかなか面白かったです…

We no longer have the weird socialist-style marketplace of IntelliCAD members cooperating yet attempting to compete; we have three true capitalist competitors.

この部分（特に “weird socialist-style” ）は、どんな日本語に訳されるのだろう？ 資本主義 vs 社会主義？ 現在の世界経済における、アメリカと中国の対決を見るようです…

先週、ITCにおいて大きな規則改訂の決議がありました。

ITC理事会では、「ITCが会員活動へのもっと厳しい規制を行うべきである」という Ralph氏の意見 を聞くまでも無く… この数年、この問題に取り組んでおりました。今後は、IntelliCAD ソースの著作権保護を目的に、BricsCADのような派生製品に対して、厳重なる罰則が課されることになります。Bricsys 社に対する処遇は、今後、話し合われることになるでしょう…

ITCでは、特に、派生製品における 開発環境（API）の互換性について重視しており、IntelliCAD派生製品上で動作するアドオンアプリケーションは、全てのIntelliCAD派生製品で動作しなければならないことが義務つけらます。

どういうことになるかと言いますと… 近い将来、IJCAD において動作するアプリケーションは、ZwCAD においても動作しなければなりませんし、その逆もしかり… ということ… Zwsoft CEO は、「私達はITC会員として規則を遵守します」 と表明しています。

ITCとしては、「IntelliCAD」 ブランドを 「CAD Platform」として定着したい考えで、ITCが目指しているのは… IntelliCADをベースにした様々なCAD製品の上で動作する様々なプラグイン（アドオンアプリケーション）があるという状態こそが、IntelliCAD World！ITC会員(提供する側)は、均一なCADプラットホーム上で、それぞれのビジネスを構築する必要があり… 利用者からすれば、これによって様々な選択肢が可能になります。

社会主義？と言われれば、そうなのかな…
大きな資本を持った会社が勝つ資本主義とは明らかに違うことは確かです。

ITCにおける Bricsys のメンバーシップは停止されました。

ポートランド/オレゴン/米国、2010年2月10日、The IntelliCAD Technology Consortium (ITC) は、Bricsys CEO Erik de Keyser 氏より BricsCAD 10 ソースコードには一切 IntelliCAD ソフトウェアが含まれていないと記述された手紙を受け取り、ITCにおける Bricsys社 のメンバーシップを停止したことを発表しました。Bricsysは、2002年に（BricsCAD NV として）ITCに加わり、Erik de Keyser 氏は、2003年にITCの副会長を務め、2004年から2006年まではITCの議長を務めていました。

ITCは、会員企業がIntelliCADソースコードにアクセスすることができるソフトウェア共同体（コンソーシアム）です。会員企業がITCを去る場合、その会社は、ITCの知的所有権が保護されていることを保証するため、定められた方法に従います。ITCは、その知的所有権がBricsys社によって不適切に使われていないことを保証するために、いくつかの手順を踏むことになるでしょう。ITCは、IntelliCAD開発に10年以上携わっており、先日、IntelliCADベースソースコードのとても重要な更新版である IntelliCAD 7 Beta2 リリースをアナウンスしたばかりです。

40社以上のITC会員会社がIntelliCAD開発プラットホームの作成に一緒に取り組んでおり、それぞれが相当なる資源を提供しています。会員各社のIntelliCADソフトウェアに対する所有権が保護され、そのソースコードが他製品の作成に不適切に利用されないことが保障されています。

• \ と / が使えます。（\ は、日本語OSでは￥で表示されます。ちなみに、韓国語OSでは₩）
• API（LISP, ADS, ARX等）の文字列定数の中（” ” で囲む）では、\ を \\ と書く必要があります。これを嫌って、/ を使う人が多いようです。
• 文字図形 (MTEXT, TEXT) において、\U+xxxx, \M+Nxxxx と16進数表記することで Unicode文字、マルチバイト文字を記入できます。
• MTEXTでは、\ は制御文字（\a1; 中央あわせ, \c30; オレンジ色, \2x; 高さ2倍など） として特別な意味を持ちます。\ そのものを表示したい場合は\\ とします。
• メニューマクロ中の \ は、ユーザー入力待ちになります。

IntelliCADにおける問題…

InteliCADスクリプト処理は、スクリプトファイル（.src）中の文字列 \ を / に置き換えてから、メニューマクロの解析処理へ渡されるようにプログラムされています。その結果、制御文字を含んだMTEXT図形を作成しようとすると失敗するなどの問題が発生しています。

その背景を説明します。

現在、IntelliCAD に含まれている DIESEL式サポートは、残念ながら皆さんが期待するメニューマクロのサポートには、ならないと思っております。

これは、AutoCAD2005以降のDWGに含まれるフィールド（FIELD）文字図形をサポートするために ODAによって作成されたもので、その構文解析処理をメニュー文字列に適用したら、そこそこ動いてしまいました…

そこそこ動くんですが、完全ではない… このあたりは、昔から変わらず、とてもIntelliCAD らしいのですが…  大変、心苦しく感じております。

FIELDは、AutoCAD 2005 (LTは、2009)でサポートされた図形で 「可変文字列」とでも呼べば判りやすいのかな？ MTEXT図形として扱われますが、入力文字がそのまま図面に描かれるのではなく、「なんらか処理した結果」生成される文字列が図面に記入されます。その 「なんらかの処理」 を記述するのに、DIESEL 式を使うことが出来ます。

従来、DIESEL式はメニューマクロとして利用されていたので、それが図面に保存されることはありませんでしたが、DIESEL式がFIELDオブジェクトに使用されるようになったため、AutoCADと互換性のあるDWGを作成するためにDIESEL式をサポートする必要があった… ということになります。

例えば… フィールドを使えば、図面の「最終保存日時」、「図面ファイル名」 などを自動で図面に記入することができます。

ファイル名： $(getvar DWGNAME)
→ “Drawing1.dwg”

保存日付： $(edtime, $(getvar,date) , YY/MO/DD HH:MM:SS)
→ “09/10/02 13:36:10″

図面保存時、これらの式が更新されて保存されます。

2005以降の DWG/DXFは、このような用法で DIESEL式を図面に保存することができますので、AutoCADで作成した図面にフィールドが含まれる場合、それを開いて再保存した場合、その値が更新されなければなりません。

互換CADの対応はどうか？

1. AutoCADでフィールド（図面保存時間）を含んだ図面を作成。
2. IntelliCADで図面を開いて図面に変更を行う。（IntelliCADでフィールドを作成＆編集する手法は用意されておりません> フィールド図形は変更しない）
3. IntelliCADで別名保存 (新しい図面を作成)
4. AutoCADで開く＞フィールドを更新
5. 値が正しく更新されました。（図形をフィールドのまま保持しています）

IntelliCADは、DWGの読み書きを DWGdirectライブラリに任せていますので、これは、DWGdirectの性能ということになります。

互換CADにとって、図面の互換性は最優先の課題となります。このような背景から、DIESEL式のサポートはFIELD図形における発生頻度が高いものほど良くテストされており、国内のLT-メニューカスタマイズで多様されている、$(getvar LASTPOINT) による座標取得のテクニックなどは、レアなケースとして扱われているようです。（そもそもODAにとっては、図面に保持される可能性のないDIESEL式の解釈は、どうでもよいことなのでしょう…）

ODA / ITCが発表した DWGdirect / IntelliCAD の更新履歴に 「DIESEL Support」 を見たとき、私もとても期待してしまいましたが…

DIESEL式の本来の目的が  「なんらか処理した結果の文字列」を生成するマクロ式のことなので…  私達が期待するメニューマクロのサポートとは、少し意味合いが異なっていたようです。

最新 IJCAD7 へのバージョンアップが 最大 44%OFF など…
キャンペーンを始めました。

詳しくは、こちらをご覧下さい…
→ 不況に勝つ！IJCAD ３大スペシャル・キャンペーンのご案内！

これまで、「いずれは…」いう曖昧な回答を繰り返しておりました （実際、いずれ対応することになるだろうと思っておりました） が… 最近になって、いろいろな判断材料が整ってきました。

ここ最近の OpenDesign Alliance (ODA)  と、IntelliCAD Technology Consortium (ITC) の動きを見る限り…

IntelliCADのARX対応は「ない」 と思っておいたほうが、よさそうです…

現在、書き直しが行なわれている「次世代IntelliCAD」は、その大部分がDWGdirectに依存しており、ITCとしては、DWGdirectによって提供されるAPI（DRX-API）をもって「ObjectARX対応」とする構想でした。

ですが、最近のODAは、DWGdirectライブラリを 「ObjectARX互換」 と表現することを明確に避けるようになりました。（Autodesk社との要らぬ法廷抗争を避けたいということが大きな理由の１つだと考えられます）

DWGdirect (DRX API) は、ObjectARX に非常に良く似たクラスライブラリですが、関数名はもちろんのこと、関数の使い方などがObjectARXとは異なっておりますので、ソースの互換性はありません。（AutoCAD上で動作しているARXアプリケーションの移植は、リコンパイルレベルではなく、ソースの書き直し作業が必要となります）

BricsCADなど、InteliCADより派生した製品の中には「ARX対応」 を宣伝しているものがありますが… ObjectARXが膨大なクラスライブラリでかつ、基本的には、対応するAutoCADバージョンに依存するライブラリとなっていますので、どこまで互換性があるのか？という点では、かなり疑問…  多大な期待はしないほうが賢明という気がします。

実は、BricsysのCTO(開発責任者)とは面識がありまして… 先日、オランダのODAカンファレンズで再会しました。 「実際、どうなの？」 と、尋ねたところ、「優先順位が高いと思われる関数から順次実装しています。単純に今のペースで作業を進めていけば、数年後には作業を完了できます」 ということだったのですが、その間もAutoCAD(ObjectARX)は、進化しているわけで…

その「優先順位」がどうやって決まるのか？というのは、Bricsysが１企業であることを考えれば、容易に想像できますよね… （お金を積めば、優先的に対応してくれるかもれません (汗;）

彼は、「AutoCADアドオンソフトメーカーの皆様から送られてくるソースコードは、酷いものが多くて…. そもそも、何でこれがAutoCADで動作しているのかが不思議！というものが少なくない」 とも言っておりました。判る気がする… 大いに納得。

IntelliCADのLISP関数群も同じで… マニュアル(関数リファレンス)の記述通りに100%互換性のある関数ライブラリを作ったとしても、それが、どのようにプログラム側から呼び出されるのか？について想定できないケースが多いので、「実際に動作するかどうか？」は別問題。

安価なAutoCAD互換CADを使いたい…  ARXを使いたい…  というのは、残念ながら、両立しそうにありません。Bricsysのアプローチは、AutoCADアプリケーションを取り込むという点で、素晴らしいアイディアだとは思いますが… 実際には、それほど簡単ではないでしょう。

ObjectARXのソースコードに固執する限り、現実的には、AutoCAD以外の選択肢は 「ない」 と考えたほうが賢明かもしれません。

なぜなら、仮に、Bricsysが 「ARX互換」 で成功したら？今度は、LT-Extenderと同じ運命を辿るのではないか？という心配が出てきます…

ARX に固執しなければ、様々な選択肢があるのですが、 「AutoCAD互換CADを使う」 と決意するには、 「ARXを諦める」というのが条件になるのかもしれません。

「ARXで開発を続けたい」という開発者の皆様には、 「AutoCAD を使い続けてください」 と提案したほうが親切なんだろうな… と思うようになりました。

これは、個人的には、とても心待ちにしていた開発環境となります。

DWGdirect は、とても素晴らしいライブラリなのですが、C++ による開発は敷居が高く、なかなな手が出せなかったという人達には最適な開発環境になると思います。

従来より、Visual Basic / Delphi プログラマ向けに ActiveX版 – DWGdirectX が提供されておりましたが、今回、新たにリリースされた、DWGdirect.NET は、さらなる拡張性を考えて設計されており、ネイティブなC++ DWGdirect開発環境でしか出来なかったような事が出来るようになります。

例えば… DWGファイルを扱う単体アプリケーション(.exe)はもちろん、ASP.NETを利用した Webアプリケーション、また、DRX-APIをサポートするホストCADシステム（IntelliCADなど）にロード可能な拡張するモジュール（アドオン機能）を開発することができます。

http://www.intellicad.net/profiles/blogs/mesh-to-solid-for-bricscad

訳文

本日 SYCODE は Bricscad 向けの「Mesh->Solid変換」をリリースしました。Bricscadにて、多角形メッシュを3Dソリッドに変換する機能を加える DRX プラグインです。

今まで、このブログを読んでいたのであれば、私が、ずっとDRXアプリケーションの開発に躍起になっていることを知っているかと思います。

皆様の何人かは、私達が何故 BRX-SDK（ObjectARXとソース互換性がある）を使って、AutoCADプラグインを再コンパイルするというアプローチを取らなかったのか？と不思議に思っているかもしれません。確かにそれは、DRX-SDK を使って大部分を書き直す方法よりも、もっと短期間に Bricscad プラグインを作成できたのかもしれません。

一番の理由は、IntelliCAD７がリリースされれば、それをサポートするためにいずれにせよ DRX-APIで書き直す必要があったことです。加えて、他のDWGdirect ホストアプリケーションで動作させることも視野に入れていることと、私たち自身もまた真面目に私達自身の DWGdirect ホストアプリケーションを開発することを考えているということもあって、DRX-APIによるアプローチを取ることにしました。 心配しないでくださいね… さらに別のAutoCADクローンを開発するつもりではありません。 私たちは、プラグイン開発とともに、スタンドアローンで動作するアプリケーションも開発しておりますので、これらをDWGdirect SDK を使って書き直すことを考えています。そうすれば、Bricscad用に開発したDRXプラグインは無駄になりませんし、自分達のスタンドアローン製品上でも動作させることが出来るでしょう。

ODA が CAD 業界において最も重要な組織になるであろう… という Ralph Grabowski の最近のコメントは私にとって大いに意味をなします。私は常に ODAは、単に DWGファイルを読み書きするライブラリを提供しているわけではない！と提言してきました。彼らは、それよりも遥かに多くのものを提供していて、今や、プロフェッショナルアプリケーションを書くデベロッパーがCADソフトウェアを開発するための、ほぼ完全なコンポーネントになりつつあります。

想像してみてください… ODA会員が DWGdirect SDK を使ってCAD製品(ホストアプリケーション)を作成します。私のようなプロのサードパーティーデベロッパー、企業内のプログラマー、フリーランスのプログラマー、学生たちは誰でも、それら全ての DWGdirect ホストアプリケーションで働く DRX プラグインを無料の DRX SDK を使って作成することができるのです。

私の会社では、たくさんのCADシステム向けのプラグインを開発していますが、サポートするホスト(CAD製品)によって、その開発方法とソースコードが大幅に変わります。例えば… 私たちは SketchUp SKP ファイルのインポート機能を 11の異なるCAD向けに提供していますが、そのソースコードは全く違うものです。なので、もし私たちが 異なるCADで動作する１つのプラグインを作ることができるのなら、それは、とても素晴らしい事です。もちろん、現在は１つの標準的な CAD プラットホームがないので、それはできません… ですが、DWGdirect SDK はこのような理想的な状況になりそうなのです。

CADプラットホームを開発するリソースも時間もお金もない私のような小さな会社が、DWGdirect プラットホームをベースとして、自分達のプロダクトを構築するために使うことができます。会社で自社システムを開発している場合も同様です。そして、さらにDWGdirectホストアプリケーションで開発されたDRXプラグインは、他の様々なホストアプリケーションと共有できるのです。

私がずっと思い描いている理想像と同じ… 図面を扱うソフトウェアを作成している皆様に 「このような環境を提供したい」… と活動を続けております。 どのCADでも動けば, 開発者の皆様が作成したソフトウェアがより多くの方に利用して頂けるようになりますし、プラットホームの選択においても選択の幅が広がります。

どこか１社独占… というのは、結果的には、歴史を繰り返すだけという気がします…