注意: この FAQ は、開発元である Solid Documents 社の FAQ ページの日本語参考訳です。日本語参考訳と原文に齟齬がある場合は、常に原文が適用されるものとします。
Solid Framework には 2つの種類があります。
Native Solid Framework
ネイティブ バージョンは、純粋な C ++ で、Windows および macOS で実行されます。
Solid Framework for .NET
.NET バージョンは、簡単に使用できます。 .NET Framework 4.0 以降が必要です。 Windows 9x はサポートされていません。Solid Framework は以下でテストされています:
Solid Framework.dll は AnyCPU フレームワークとして構築され、それをロードするプロセスに応じて、x86 または x64 ネイティブを自動的に実行します。
ライブラリには、 2 つのバージョンがあります。 1 つは .NET ライブラリとして提供していますが、.NET なしで使用できるネイティブ C++ DLL も提供しています。
必要な .NET Framework の最小バージョンは 4.0 です。
.Net Framework の新しいバージョンも使用できます。
Solid Framework は、CLS 準拠のクラスライブラリです。 つまり、クラスライブラリは、すべての .NET 言語に共通の機能のみを公開します。 たとえば、これらの機能はサポートされているすべての言語で利用できるわけではないため、符号なしの型やオーバーロードされたメソッドは使用されません。
簡単にするために、すべてのサンプルとドキュメントは C# で記述されています。 他の一般的に使用される CLS 準拠言語は次のとおりです。
もちろんです。顧客の中には、Web ベースまたはアプリベースの製品に C++ を使用しているお客様もいます。
C++ を使用する場合、マシンで .NET を使用可能にする必要はありません。
Solid Framework ポータルのダウンロード部分で利用可能な C++ の使用を示すサンプルがいくつかあります。
Solid Framework には、.NET バージョンと C++ バージョンの 2つの異なるバージョンがあります。
このドキュメントでは、これらのバージョンの主な違いについて説明しています。
Solid Documents チームは VS 2019 を使用して開発しており、現在 "v14" MSVC ランタイム (VS 2015 に同梱されているバージョン) をターゲットにしています。
簡単な答えは、試したことがないのでわからないということです。
詳細な答えは、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 はマルチスレッド実行を利用して変換パフォーマンスを向上させていますが、1 つのプロセスにつき 1 つの同時変換しかサポートしていません。このアーキテクチャの選択の主な理由は、安定性とジョブの分離です。
JobProcessor を使用すると、同じマシン上で、異なるプロセス内での同時変換が可能になります。
同時接続の数が非常に多くなる可能性があるサービス環境では、発生する同時変換の数を管理および制限し、キューイングシステムを使用して要求を管理することは理にかなっています。これは、JobProcessor アーキテクチャが Windows (C# 実装) で行うことです。このアーキテクチャは、次の目的で元の Apache Webサーバー MPM アーキテクチャを強く意識しています。
– 利用可能なリソースを活用するためのスケーリング (調整可能だが制約されたワーカープロセス数)
– リクエストのキューの管理 (トラフィックが多い期間にサービスがダウンすることを決して許可しないため、1 回のコンバージョンあたりの平均時間のみが増加します)
– メインプロセスから独立してワーカープロセスのヘルスを管理します (ワーカープロセスのクラッシュまたはハング/タイムアウトは単一のジョブにのみ影響します - クラッシュまたはハングの原因となったジョブ、ワーカーは「健全性のリサイクル」を行います - デフォルトでは、これは 100 ジョブごとに発生するため、長期的なリソースリークの問題はありません)
このアーキテクチャは安定しており、十分にテストされています。当社の www.simplypdf.com 変換サービスもこのアーキテクチャを採用しています。一度に数か月間実行され、クラッシュ、リーク、再起動なしで数万回の変換を実行します。
Solid Framework は本質的にスレッドセーフではありません。
並列処理が必要な場合は、"JobProcessor" クラスの使用をお勧めします。このクラスはいくつかの独立した JobHandler プロセスを起動し、各プロセスが 1 つの変換を行います。
JobProcessor は変換要求をキューに入れ、アイドル状態になると JobHandler プロセスに割り当てます。
デフォルトでは、JobProcessor はマシンのコア数と同じ数のJobHandler プロセスを同時に起動します。JobProcessor::WorkerCount を設定することで、並行する JobHandler の数を制限することができます。
通常、ワーカーの数はマシン上のコア数より少なく設定することをお勧めします。これは、Solid Framework がファイルを変換している間、他のタスクを続行できるからです。
JobProcessor クラスは、SolidFramework の .NET バージョンでのみ利用可能です。
しかし、SolidFramework の C++ バージョンで動作する Python ベースの実装があり、Windows と Linux の両方のマシンで使用することができます。
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つの解決策があります。
Solid Framework のバージョンを少なくとも 9.2.7514 に更新します。(推奨)
古いバージョンと互換性のあるマシン 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 にはこの問題に対処するメカニズムがありますので、詳細についてはメールでお問い合わせください。
クラウドへの展開は、ハイブリッド ライセンスまたはパブリックライセンスでのみ利用可能です。
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 の実行をご参照ください。
Solid OCR は、以下の 17 言語を直接サポートします。
Tesseract を使用して、さらに 6 つの言語をサポートしています。
「SolidFrameworkを使って、中国語、日本語、韓国語、ギリシャ語、ヘブライ語のドキュメントのOCRを行う。」には、こちらの PDF を参照してください。
その他の技術情報は、こちら。
列は、"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 ビットを優先" をオフにします。
「SolidFrameworkを使って、中国語、日本語、韓国語、ギリシャ語、ヘブライ語のドキュメントのOCRを行う。」には、こちらの PDF を参照してください。
その他の技術情報は、こちら。