Solid Framework の FAQ

 

SOLID FRAMEWORK を使用したソフトウェアの開発

Solid Framework には 2つの種類があります。

Native Solid Framework

ネイティブ バージョンは、純粋な C ++ で、Windows および macOS で実行されます。

Solid Framework for .NET

.NET バージョンは、簡単に使用できます。 .NET Framework 4.0 以降が必要です。 Windows 9x はサポートされていません。Solid Framework は以下でテストされています:

  • Windows 10
  • Windows 8
  • Windows 7
  • Windows Server 2016
  • Windows Server 2012 R2 x64
  • Windows Server 2008 R2 x64

Solid Framework.dll は AnyCPU フレームワークとして構築され、それをロードするプロセスに応じて、x86 または x64 ネイティブを自動的に実行します。

ライブラリには、 2 つのバージョンがあります。 1 つは .NET ライブラリとして提供していますが、.NET なしで使用できるネイティブ C++ DLL も提供しています。

必要な .NET Framework の最小バージョンは 4.0 です。

.Net Framework の新しいバージョンも使用できます。

Solid Framework は、CLS 準拠のクラスライブラリです。 つまり、クラスライブラリは、すべての .NET 言語に共通の機能のみを公開します。 たとえば、これらの機能はサポートされているすべての言語で利用できるわけではないため、符号なしの型やオーバーロードされたメソッドは使用されません。

簡単にするために、すべてのサンプルとドキュメントは C# で記述されています。 他の一般的に使用される CLS 準拠言語は次のとおりです。

  • C#
  • Visual Basic .NET
  • J#

もちろんです。顧客の中には、Web ベースまたはアプリベースの製品に C++ を使用しているお客様もいます。

C++ を使用する場合、マシンで .NET を使用可能にする必要はありません。

Solid Framework ポータルのダウンロード部分で利用可能な C++ の使用を示すサンプルがいくつかあります。

Solid Framework には、.Net バージョンと C++ バージョンの 2つの異なるバージョンがあります。

このドキュメントでは、これらのバージョンの主な違いについて説明しています。

Solid Documents チームは VS 2013 および VS 2015 を使用して開発しており、現在 "v12" MSVC ランタイム (VS 2013に同梱されているバージョン) をターゲットにしています。

一部のお客様が VS 2017 を使用していることもわかっています。

簡単な答えは、試したことがないのでわからないということです。

詳細な答えは、2011年にC++ に追加された "Shared_Ptr" や "wstring" など、いくつかの言語機能を Solid Framework が使用しているということです。そのため、Solid Framework を VC++ 6 で使用すると問題が発生する可能性があると考えています。

ただし、特定のサードパーティライ ブラリバージョン (たとえば、MSVC ランタイムのバージョンなど) への依存を少なくするために、顧客アプリへの静的リンクを意図的に使用しません。 お客様が実際に SolidFramework.h および SolidFramework.cpp API インターフェース インクルードファイルに対してコンパイルできる場合、ライブラリが機能します (これらのインターフェース ファイルは、システムの残りのバージョンに依存しない動的ロードを実行します)。

Solid Framework SDK は、セルフサービスの Solid Framework Developer Portal を利用してダウンロードできます。

ポータルにアクセスするには、アカウントを作成する必要があります。

SDKのダウンロード方法に関するビデオチュートリアルを見るには、ここをクリックしてください。

ダウンロードが完了したら、プロジェクトのソースフォルダーに SolidFramework.dll を配置します。

プロジェクトからこのアセンブリへの参照を追加します。ここをクリックしてビデオチュートリアルをご覧ください。

Solid Framework は、本質的にスレッドセーフではありません。

並列処理が必要な場合は、"JobProcessor" クラスの使用をお勧めします。 このクラスは、各プロセスが単一の変換を実行する、多数の独立した JobHandler プロセスを起動します。

JobProcessor は、変換要求をキューに入れ、アイドル状態になったときに JobHandler プロセスに割り当てます。

デフォルトでは、JobProcessor は、マシンのコア数と同数の JobHandler プロセスを起動します。 JobProcessor::WorkerCount を設定することにより、並列 JobHandler の数を制限できます。 

通常、ワーカーの数をマシン上のコアの数より少なく設定することをお勧めします。これにより、Solid Framework がファイルを変換している間、他のタスクを続行できるようになります。

現在、JobProcessor は .NET でのみ使用できます。 近い将来、ネイティブ C++ バージョンをリリースする予定です。

 

ライセンス

Solid Framework のライセンスは、Solid Framework がインストールされているマシンの ID に紐づけされます。

マシン ID を取得するには、solidframework.net の "My Account" ページからツールをダウンロードします。

ダウンロード方法を確認するには、"How do I get a Machine ID?" (マシンIDを取得するにはどうすればよいですか?) をクリックします。

マシン ID ジェネレータは最近、同じマシンにインストールされた仮想または複数のネットワークカードに関連する問題を解決するために更新されました。 新しいジェネレーターは、9.2.7514 より前のバージョンの Solid Framework と互換性のない長い ID を生成します。

2つの解決策があります。

  1. Solid Framework のバージョンを少なくとも 9.2.7514 に更新します。(推奨)

  2. 古いバージョンと互換性のあるマシン ID ジェネレーターのバージョンを使用します。 このツールへのアクセスをリクエストするには、support@soliddocuments.com にメールしてください (英語のみ) 。

Solid Framework の機能を使用するには、Solid Documents からのライセンスが必要です。 評価用ライセンスを含むライセンスは、セルフサービスの Solid Framework Developer Portal を利用して作成できます。 これらのライセンスはマシン固有の ID に依存し、これらの ID を生成するための Developer Portal で利用可能なユーティリティがあります。

Solid Framework の機能を使用するには、コードにライセンスの場所を埋め込む必要があります。ビデオチュートリアルを見るにはここをクリックしてください。

// Solid Framework (Professional) license
License.Import(new StreamReader(@"C:\Users\Joe\Documents\Visual Studio 2010\Projects\FrameworkProject\license.xml"));

ライセンスは通常、Solid Framework が使用されているマシンの ID に関連付けられています。 これは、Solid Framework がクラウドに展開されている場合に問題を引き起こす可能性があります。これは、マシン ID が随時変更される可能性があるためです。

Solid Framework にはこの問題に対処するメカニズムがありますので、詳細についてはメールでお問い合わせください。

クラウドへの展開は、ハイブリッド ライセンスまたはパブリックライセンスでのみ利用可能です。

 

画像処理と OCR 認識

SolidFramework は、主にビジネス ドキュメントの再構築を目的としています。

そのため、OCR そのような文書の内容を正確に認識することにフォーカスしています。

CGMは Color Grey Mono の略です。元々、画像処理はアーカイブ機能を対象としていました。PDF/A アーカイブファイル用の小さなスキャンページを作成し、ページの画像品質を可能な限り維持します。そのために、ページ画像のゾーンをその性質に基づいて認識し、ページを適切なコンポーネントに分割します。例えば:

  • カラー写真はページの残りから抽出され、ダウンサンプリング (通常は 150 dpi) され、JPEGとして圧縮されます

  • カラーグラフィックまたはテキストの見出し (パレット画像) の場合、色をより小さなパレット (16 または 256 色など) にリサンプリングし、ロスレス圧縮を使用します (GIF または PNG と考えてください)

  • モノクロテキストの場合、ピクセルあたり 1 または 2 ビット (アンチエイリアス テキスト) として抽出し、CCITT FAX 圧縮を使用してロスレスに保存します。

このセグメンテーション、ロッシーまたはロスレス圧縮の選択的使用、および選択的ダウンサンプリングにより、単一のスキャン画像ページよりもはるかに小さい複合画像ページを PDF で構築できます。

Solid CGM には、スキャンしたページ画像を処理するために必要なすべての明らかな前処理機能も含まれています。

  • デスキュー

  • 自動回転 (支配的なページ テキストの方向を決定)

  • スペックル除去 (「塩」および「コショウ」ノイズ除去)

  • 動的なしきい値処理 (通常、OCR はモノクロ プロセスですが、それが機能するには、「紙」と「インク」の色合いと制限を設定する必要があります)

  • スキャナーのノイズ除去 (通常、ページの端にある黒いバー)

  • ホッチキス、パンチホール、折り返しコーナーノイズ除去

  • 90 度および 270 度のテキストコンポーネントの検出 (マイナーテキストコンポーネントはページの残りの部分と同じ方向ではありません)

  • ベクターテーブルの検出

  • ベクトル下線の削除と修復 (下線が「スライス」されている可能性があるテキスト文字を修正)

  • 逆テキストコンポーネントの検出 (ページ全体または小さなテキストコンポーネントのいずれか:通常は黒のテキストに白ですが、任意の色にできます)

SolidFramework は Tesseract を使用して、中国語、日本語、韓国語、ギリシャ語のドキュメントで OCR を実行します。

これを行う方法に関する情報は、Tesseract を使用した OCR の実行をご参照ください。

 

その他

列は、"Section" オブジェクトのプロパティです。

PdfOptions.ExposeTargetDocumentPagination を true に設定した CoreModel が作成されます。 一旦 CoreModel が作成されたら LayoutDocument を取得できます。

CoreModel.Topic 内の各オブジェクト (実行を除く) には、関連付けられた Layout オブジェクトがあります。 この layout オブジェクトには、ドキュメント内のオブジェクトの場所に関する情報が含まれています。

layout オブジェクトを取得するには、LayoutDocument.FindLayoutObject(ID) を検索します。IDは、SolidObject.GetID() を使用して検索できる SolidObject の識別子です。

CoreModel.Topic の各段落には、場所へのアクセスを提供する一致する LayoutParagraph があります。

ConversionStatus.PdfAError は、「ソースドキュメントに問題があり、PDF/A に準拠していないことを意味します」という意味です。

ただし、SolidFramework はこれらの問題を解決して準拠ドキュメントを作成できた場合があり、その場合は出力ファイルが生成されていました。

したがって、ConversionResults にファイルへのパスが含まれているかどうかを確認する必要があります。これは、変換ができたを示します。

典型的なコードは次のとおりです。

        
if (res == ConversionStatus.Success || res == ConversionStatus.PdfAError)
{
    // Get the location of the generated file
    if (conv.Results[0] != null)
    {
        if (conv.Results[0].Paths.Count == 1)
        {
            string path = conv.Results[0].Paths[0];
            //Do something with the file
        }
    }
}
      

タグは、一連の標準構造タイプを使用して、ページ コンテンツ (テキスト、グラフィックス、画像) を抽出し、他の目的に再利用できるようにします。

たとえば、Solid Frameworkは、タグが存在する場合は、タグを使用して PDF 内のテーブルを識別します。 これにより、PDF からテーブルデータをより正確に抽出できます。 これに関する問題は、タグがオプションであることです。

同じテキストデータは、タグが存在する場合はテーブルとして識別されますが、タグが存在しない場合は通常のテキストとして識別されます。 これは、一方がタグ付けされ、もう一方がタグ付けされていないように見える類似のファイルを比較しようとすると、問題を引き起こします。

Solid Framework では、次のコードを使用して PDF からタグを削除できます。

string taggedFile; //Path to PDF that contains tags
string untaggedFile; //Path to PDF that has had tags removed.

PdfDocument doc = new PdfDocument(taggedFile);
doc.Open();
doc.RemoveStructTreeRoot();
doc.SaveAs(untaggedFile, SolidFramework.Plumbing.OverwriteMode.ForceOverwrite, true);
      

Solid Framework は、PDF から Word 文書を再構築するのに非常に優れています。 ほとんどの場合、再構築されたドキュメントは PDF と同じページ数になりますが、Word の制限のためにそうでない主な状況が 2 つあります。

連続する奇数 (または偶数) ページフッターによるページジャンプ

Word は、奇数ページと偶数ページで異なるヘッダーとフッターをサポートしています。 ただし、Word では、1 ページの奇数フッターに続くページの別の奇数フッター (または実際には 2 つの連続する偶数ページフッター) がサポートされていません。 そうしようとすると、Word は Word 内に表示されない可能性がある追加のページを静かに挿入しますが、ページ数が増え、ページ間を移動するときにページ番号がジャンプします。

ドキュメントの最後のアイテムとしてのテーブル

Word では、テーブルをページの最後のアイテムにすることはできません。 その後に改行が必要です。

テーブルがページの一番下で終わる場合、新しい行は余分なページを作成する可能性があります。

この問題は、ドキュメントを編集し、改行文字に非常に小さなフォントサイズを設定することで解決できます。 Solid Framework がドキュメントを再構築したときに自動的にそれを行うこともできましたが、それは Word ドキュメントの編集が困難になることがわかったため、選択しませんでした。

PDF ファイル構造には、ファイル内のすべてのオブジェクトまたは要素へのリンクを含み、ファイルのナビゲートに役立つ相互参照 (または Xref) テーブルが含まれています。

以下の画像は、PDF バージョン 1.7 のドキュメントを含む PDF ファイルの Xref テーブルの開始を示しています。

ユーザーが PDF からフォント、画像、ページなどのアイテムへのすべての参照を削除する場合、XRef テーブルは引き続き参照を保持します。 ファイルには、使用されなくなってもそのアイテムが含まれ続けます。 これにより、必要以上に大きな PDF ファイルが作成されます。

PdfDocument.SaveOptimizedAs() - これらの破棄されたオブジェクトへのリンクとコンテンツを削除します。 これにより、ファイルのサイズを縮小できる可能性があります。

破棄されたオブジェクトがファイル内に存在する場合、ファイルサイズの大幅な削減を実現できます。 破棄されたオブジェクトが存在しない場合、このメソッドはファイルサイズにわずかな影響を及ぼし、ファイルサイズがわずかに増加することさえあります。

 

問題の解決

Solid Frameworkは、処理中に詳細なテキストファイルログを出力できます。 これは、Solid Documentsが問題が発生している場所を特定できるようにするのに非常に役立ちます。

デフォルトでは、ログファイルは作成されません。 いずれかが指定されている場合、処理が行われると書き込まれます。

追加のログファイルは、使用される場合、個々の JobHandler プロセスによって作成されます。 これらのファイルには、ファイル名に "jh" という文字と ID が含まれます。

注意: 9.2.8284 以前のバージョンでは、ログファイル名が ".txt" で終わらない場合、すべての JobHandler プロセスが同じログファイルを使用するため、ファイルアクセスの競合や変換エラーが発生する可能性があります。

C# でログを使用するパターンは通常、次のようなものです。

string logPath = @"c:\test\solidframework.txt";
if (System.IO.File.Exists(logPath)) {
System.IO.File.Delete(logPath);
}

SolidFramework.Plumbing.Logging.Instance.Path = logPath;
      

同様に、C++ では次のコードを使用できます。

LPCWSTR p = L"c:/test/solidframework.txt";
SolidFramework::Platform::Plumbing::Logging::getInstance().setLogPath(p);
      

SolidFramework.dll の 3 つのバージョンが .NET で利用可能です。

1 つは 32 ビット専用、2 つめは 64 ビット専用、3つめは "AnyCPU" です。

Visual Studio プロジェクトが、参照される SolidFramework.dll と異なるビット数を持っている場合、次のメッセージが表示されます。

この問題は、64 ビットバージョンの SolidFramework.dll がダウンロードされた場合に最も頻繁に発生します。"AnyCPU" Visual Studio プロジェクトのデフォルトのビット数は、直感的には 32 ビットであるためです。

解決策

1. (推奨)。 SolidFramework.dll の AnyCPU バージョンをダウンロードして使用します。

2. Visual Studio プロジェクト オプションを変更して、デフォルトの "32 ビットを優先" をオフにします。

 


 

ページトップへ