私は、何らかの理由で、すべての開発ドキュメントをMSWord形式にする必要があると主張する会社で働いています。これは、バイナリ形式であるため、次のことができないことを意味します。
ドキュメントを書くために何を使用しますか、またその理由は何ですか？
この状況を変えるための弾薬もください...
最近、DocBook XML を使用してドキュメントを作成し始めました。
利点として、これは純粋なテキスト形式です。大きなドキュメントを複数のファイルに分割し、ノードを使用してそれらをすべて 1 つのブックにまとめることができます。目次と索引は自動生成されます。ドキュメント内リンク (任意のテキスト内、章またはセクションを指す) は非常に簡単です。ボタンを押すだけで、単一の html ファイル バージョン、チャンク化された html バージョン (章ごとに 1 つのファイル)、および PDF バージョンを作成できます。
微調整とカスタマイズを行った後、出力に非常に満足しています。ドキュメントは見栄えがします!!
DocBook は実際の出版社 (特に O'Reilly) によって広く使用されており、15 年以上にわたって使用されているため、ある程度の成熟度に達しています。
一方、すべての処理は XSLT で実行され、ツールのアドホック コレクションが使用されます。(私自身の docbook パイプラインには、Python、Java、Xerces、Xalan、Apache FOP、および PDF-SAM が含まれています。さらに、公式の XSLT スタイルシートの配布と、私自身の XSLT カスタマイズも含まれています。)
DocBook はターンキー ソリューションではありません。説明書を読まずに、すぐに始めることはできません。また、XSLT について何も知らない場合は、学ぶ必要があります。
一方、文書を作成するために実際に知っておく必要がある XML タグは 12 つか 2 つしかありません。(実際の専門知識は、XML ソースからドキュメントを生成するときに発揮されます。) チームの 1 人がドキュメント ビルド スクリプトの作成を担当することを厭わない場合、チームの他の全員が DTD を学び、まともな仕事をすることができます。貢献しています。
とにかく... DocBook には間違いなく欠点があります。これは、技術オーサーシップにとって最も簡単なシステムではありません。しかし、これは私が知っている最高のオープン ソース ツールです。
「Subversion Book」はDocBookで書かれています。これは、さまざまな本のバージョン (single-html、chunked-html、および PDF) へのリンクを含むページです。
最初の章の DocBook XML ソースへのリンクは次のとおりです。
http://sourceforge.net/p/svnbook/source/HEAD/tree/branches/1.7/en/book/ch01-fundamental-concepts.xml
弾薬については、信頼できる古い Pragmatic Programmer の第 14 章: The Power of Plain Text があります。
Pragmatic Programmer として、私たちの基本的な素材は木や鉄ではなく、知識です。要件を知識として収集し、その知識を設計、実装、テスト、およびドキュメントで表現します。また、知識を永続的に保存するための最適な形式は プレーン テキストであると考えています。プレーン テキストを使用すると、ほぼすべてのツールを自由に使用して、手動でもプログラムでも知識を操作できるようになります。
あなたが言及した2つの理由から、wiki（特にTracが提供するもの）を使用しています。さらに、本当に必要な場合は、マークアップのテキスト バージョンを取得して、テキストのみの環境で操作することもできます (たとえば、コミット中の svn コメントの一部として)。
テキストのみ (非バイナリ) に簡単に縮小できる形式は、間違いなく必須です。それを PDF のようなきれいな形式にアップコンバートする機能を持つことは、私たちにとってそれほど重要ではありません。
Word にはドキュメントの変更追跡機能があり (変更を受け入れるまでしか機能しませんが)、それらを grep することもできます (テキストは暗号化されません)。ですから、あなたの主張のどちらが精査されても支持されるかどうかはわかりません。これを変えるための弾薬をあなたにあげたいのですが、私は年齢とともにうんざりして冷笑的になりました.
私たちはドキュメントに MS Word を使用しています (これは、以前の選択 (Lotus WordPro - うわー!) よりも大幅に改善されています)。
Dylan の組織と同様に、優れたConfluence wikiも使用しています。Wiki is my word-processor という、これがより良いアプローチである理由についての記事を書きました。
内部文書にWiki を使用する利点には、次のようなものがあります。
これよりも多くの弾薬が必要な場合は、The Atlassian Blogで多くの wiki プロモーションがあります。
ウィキ、特にAtlassian の Confluenceを使用しています。
それは商用製品であり、素晴らしいです。フリー/オープンな wiki エンジンよりもこの wiki エンジンを選んだ理由の 1 つは、本格的な WYSIWYG エディターと、Word に慣れているユーザーがより簡単にアクセスできるようにするその他のさまざまな機能を備えていることです。
また、画像、デザイン、ワイヤーフレームなどを Subversion に保存し、Apache/SVN Web インターフェース モジュールを介してこれらのリソース URL へのリンクを wiki ドキュメントに埋め込むという巧妙なトリックも考え出しました。興味がある場合は、これをどのように行うかについてのメモがここにあります。
テキスト形式を使用すると、ドキュメントをJavaDoc、APIリファレンス、データディクショナリなどの生成されたアイテムと簡単にマージできます。また、大きなドキュメントには使用しにくい単語よりもはるかに優れたスケーリングを実現します。最後に、インクルードを許可する形式では、複数の作成者がドキュメントで同時に作業できます。
LaTeXとFrameMaker（これに使用した2つのシステム）はどちらも非常に優れたインデックス作成機能と相互参照機能を備えており、ネイティブテキスト形式またはネイティブ形式のテキストバージョンを含めることができます（Framemakerの場合はMIF）。 。また、どちらも言葉よりもはるかに安定しています。
私は、データディクショナリを読み取り、安定したインデックス作成と双方向の相互参照を使用してより大きなドキュメントに含めることができるドキュメントを生成するツールを構築しました。この製品 の機能仕様は、このようにLaTeXで行われ、会社との別のギグを取得しました。私もFrameMakerで同様のプロセスを開発しました。
ドキュメントを OOXML ( .docxWord の場合は ) 形式にするように依頼できます。私の意見では、ODT を使用するほど理想的ではありませんが、それでも内部に多数の XML ファイルを含む単なる zip ファイルです。:-)
開発チーム全体がこの要件に反対していますか、それとも小さなグループですか? チーム全体の場合は、義務を無視してテキストベースの形式を使用してください。従業員がばかげたルールを無視したのはこれが初めてではありません。過去に大騒ぎしたことがない場合は特にうまく機能します。をお持ちの場合、経営陣はあなたのドキュメントを特に厳しくチェックする可能性があります。
MS Word は、ドキュメントの変更追跡とピア レビューをサポートしています。
新しい MS Office 形式は完全に XML ベースです (これを確認するには、MS Word .docx ファイルの名前を .zip に変更してから、解凍して確認してください)。
Office 2007 は、あなたの会社の要件と懸念事項の両方に適合するのではないでしょうか?
少なくとも Word 文書を比較したり、[Extra] メニューの [Track changes] コマンドを表示したり、DeltaViewなどのソフトウェアを使用したりできます。lifehacker.comの Google 検索の最初のリンクで見つかりました。Word 文書の検索は、Google デスクトップ サーチや、読み取り可能なすべてのファイルをインデックス化する他の同様のプログラムを使用して実行できるはずです。
彼らはあなたがそれをWordで書くことを主張しますか、それともWord形式で利用できることだけを主張しますか? テキスト形式で書いて、Word に自動的に変換できます。
ドキュメンテーション ファイルを、理想的にはソース コードと一緒に、ある種のバージョン管理システムに保存していませんか? これを行うことをお勧めします (古いソフトウェア リリースのドキュメントを簡単に入手できます)。
また、ドキュメントを VCS に保存する場合は、差分を取得できるため、プレーン テキストまたは XML ベースのファイルの方がはるかに優れていることに気付くでしょう。また、通常、テキスト ファイル間の変更は、バイナリ ファイル間の変更よりも効率的に保存されます。
ここで MS 製品を擁護するつもりはありませんが、MS Word はドキュメントを比較できます。
DocBookの推奨ツールチェーンも参照してください。
Word ドキュメントからすべてのテキストをテキスト ファイルに抽出する Word を自動化するのは簡単です。したがって、Word ドキュメントからテキスト ファイルを作成するスクリプトを作成し、grep、比較、バージョン管理、これらのテキスト ファイルのレビューを行うことができます。
もちろん、きれいな書式設定が失われるため、これは理想的なソリューションではありませんが、機能するはずです。
Beyond Compareをソース管理システムの差分ツールとして使用すると (Perforce と同様に)、Word ドキュメントのリビジョン間の違いが表示されます。確かに、これはテキストの違いだけを示しています - フォーマットの変更は表示されていません - しかし、通常はこれで何が変更されたかを確認するのに十分です.
これは、Beyond Compare に投資するもう 1 つの理由です。これは、私が今まで使用した中で最も洗練されたソフトウェアの 1 つであり、ソフトウェアに費やした最高の 30 ドルです (複数購入する場合は少なくなります)。
Word 文書を比較するためのツールは多数あります。現在、Word の組み込みの比較およびマージ機能にコマンド ラインを配置する Python スクリプトを使用しています。
Word文書をプレーンテキストに変換するプログラムがあると思います。そのうちの 1 つを使用して doc という単語をプレーン テキストに変換し、diff、grep などを使用します。