LOとMSOを友達にする方法。 パート2：docxおよびodtの自動テスト生成

読者の皆さん、こんにちは！ 約束どおり 、MS Office 2010およびLibreOffice 3.5でさまざまなドキュメント形式をテストし続けています。 この投稿の執筆中に、作業中のodtおよびdocx形式を確認することができました-残念ながら、失望しました。 しかし、自分より先に進まないでください。 これらの形式がMSOおよびLOでどのように処理されるかについてのネコの下で、テスターに​​とってちょっとした驚き：ドキュメント形式などの異常なフィールドのテスト生成プロセスを自動化する方法。

期待

最後の投稿へのコメントでは、インターネット上の他の場所と同様に、docx形式とodt形式について、古い文書の置き換えについて（そして最終的には非常に良くない文書について）多くのことが述べられました。 彼らはdoc標準について多くのことを話し、odtの数式の品質について多くのことを思い出しました。これらの形式を実際にテストしないのは罪です。 正直なところ、私はodtがあちこちで問題なく開くことを期待していました。docxはodtよりも悪い結果を表示しますが、docよりもはるかに良い結果を示します。 しかし、夢は実現する運命ではなかった...

テストジェネレーター

ドキュメントのテストを約1日間準備しました。 ロジックによると、docxに必要な量とodtに別の日が必要です。 同じテストを異なる形式で記述するのに3日かかります！ これはどのようなプログラマーに適していますか？ 私の考えの基礎は次の観察にあります：LOの下のodtにコンポーネントを保存する場合、LOで再度開いてもコンポーネントは変更されません。 つまり、最初はすべてのテストをodt形式で記述する必要があり、その後はdocおよびdocx形式でのみ保存する必要があり、1つではなく3つのテストが提供されます。 幸いなことに、sofficeには--convert-toオプションがあり、自動化に使用していました。



したがって、テストの作成はどのように自動化されますか？

1. すべてのテストをodtで書く
2. odtを任意の形式に変換するための小さなshの作成
   
   
   converter.sh

   soffice --headless --convert-to $2 $1
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   
   
   
3. 使用可能なすべてのodtテストを変換するプロセスを自動化する別のshを作成しています
   
   
   create.sh

    for i in `seq 12`; do cd $i; ../converter.sh "*.odt" doc; ../converter.sh "*.odt" docx; cd .. done
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   
   
   
4. 念のため、すべてのdocとdocxを削除するためにshを作成します
   
   
   clean.sh

    for i in `seq 12`; do rm $i/*.doc* $i/*/*.doc*; rm $i/*.docx* $i/*/*.docx*; done;
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   
   
   

その結果、テストジェネレーターをodtからdocおよびdocxに変換し、1日で3つの形式すべてのテストを完全に書き直しました！

フォーマットに加えて

新しいフォーマットは良いですが、読者のリクエストを忘れず、テストに式と脚注を追加しました。 結局のところ、物事は彼らが言ったほど悪くはありません。 ほとんどのコンポーネントは正しく表示されます。



雑誌も少し変わった。 ほとんどの場合、両方のエディターで適切に表示される最も「良い」フォーマットを見つけるために、いくつかの統計を追加しました。

結果

Pages

すべての形式は、ページサイズ、向き、マージン、境界線で正しく機能します。 ページの背景色はまったく使用せず、境界線からのインデント（マージンまたは段落のインデントに置き換えられます）を使用しないことをお勧めします。

ヘッダーとフッター

ヘッダーの高さ（LO-間隔）を指定するか、ページ番号を追加する必要がある場合、どの形式でも問題は発生しません。 しかし、ボーダーとサイドマージンはあまりうまく処理されず、docx形式のヘッダーのテーブルは同様に処理が不十分で、LOで削除されます（奇妙な、削除されたものもMSOに表示されます）。

スピーカー

どこでも問題ありません。

段落

インデント、間隔、および配置は、さまざまな選択の色と同様に、すべての形式およびエディターで同じように表示されます。 境界線も恐れることなく使用できますが、ベースラインに対する垂直方向の配置など、エキゾチックなことは忘れてください。MSOはそれについて知りません。 「段落を分割しない」および「次の段落を切り離さない」というパラメーターも、すべての形式およびエディターで正しく表示されます。

キャラクター

2つを除いて問題はありません。

• 上書きを忘れることができます
• MSOを介してODTを開くと、ハイパーリンクが削除されます

リスト

docおよびdocxでもすべて問題ありません。 odtでは、インデントされたリストがシフトされます。

画像

要するに、ドキュメントを使用します。 文書の画像に問題はありません。

テーブル

前の段落と同様-ここでもdocが最高であることが証明されました。

ピアレビュー

odtが好きなら、移植性を忘れることができます！ MSOは、お客様の同意なしにドキュメントからすべての変更データを削除します。

フィールド

どこでもすべてが正しいように思えますが、長いテストの後、結論に至りました-文書内の特別なフィールドを使用しないでください（もちろん、ページ数とページ数を除く）。

フォーミュラ

ここで、docxは競合を超えています。 数式の優れた表示と編集機能（左側のインデックスはあまりありませんが、単にそうではありません）。

脚注

すべての形式がうまく表示され、脚注の文字番号付けに数字を使用することに決めたのはdocxだけですが、それは怖くないですよね？

私の評決

契約書、手紙などのビジネス文書が必要な場合は、docを使用してください。 テキストの書式設定とさまざまな挿入（式を除く）の両方が完全に処理されます。



報告書、論文または学期論文を書く必要がありますか？ docxを使用すると、数式に問題はありません。



あなたはLinuxoidの赤い目をしていて、カーソルを「嫌い」に向かって考えています-「いつまでも!!!」？ odtが他の人よりも悪いことを示したのは私のせいではありません。 何らかの理由で、すべてのodtファイルはMSOで正常に開くことを望まず、「ドキュメントの復元」を要求しました。 何が関係しているのか-わからない、規則に従ってドキュメントを作成した、使用したLOの上にタンバリンでダンスをアレンジしなかった 多分それはバージョンにあります（LO 3.5があります）？