ABBYY FineReader Sprintの次のバージョン（MFPおよびスキャナーに付属のテキスト認識プログラム）では、アラビア語のインターフェイス言語を追加する必要がありました。 そしてすべてをまとめて......



通常、「新しい」言語へのローカライズは単純な問題です（開発用）。1つまたは2つの定数を取得し、ビルドシステムを調整します。一般的にはそれだけです。 残りは技術者と翻訳者の肩にかかっています。 しかし、アラビア語では右から左に書くため、インターフェイスに多くの変更が必要になります。 この経験については記事で説明します。

すべてを展開する（実際にはそうではない）

アラビア語に翻訳された最初の行が翻訳から来るずっと前に、私はRTL（右から左へ：悲しいかな、この用語の良いロシア語の翻訳を思いつきませんでした）インターフェースを扱いました。 実際、ドーターウィンドウの位置は書き込みの方向に従います。ウィンドウを閉じる「クロス」とスクローラーを左に押し、メインメニューを右に押し、進行状況バーも右から左に実行します。 一般的に、すべてが逆さまです。 この動作を実現する最も簡単な方法は、初期化コードに次の呼び出しを挿入することです（最初のウィンドウを作成する前に）。



SetProcessDefaultLayout（LAYOUT_RTL）;



その後、現在のプロセスで作成されたすべてのトップレベルウィンドウがWS_EX_LAYOUTRTLスタイルで作成されます。 このスタイルは、すべての子ウィンドウにも継承されます（すべてではありませんが、最初の近似として継承されます）。 ところで、ミラー化された動作を実現する最も簡単な方法は、作成時にWS_EX_LAYOUTRTLをすべてのトップレベルウィンドウに設定することではありません。 いずれにしても、次のようになります。







すぐに対処する必要がある多くの問題を確認できます：ツールバーのミラーアイコン（1）とボタン（2）、拡張テキスト（3）、タスクの下の一致しない背景（4）見出し、句読点が間違った方法（5）およびt .p。



実際、WS_EX_LAYOUTRTLスタイルはクライアント座標（およびWM_NCPAINTで使用される座標）を拡張します。 これで、それらは右上点の始まりになり、横座標は右から左に増加します。 また、このウィンドウに関連付けられているすべてのデバイスコンテキスト（HDC）はLAYOUT_RTL（簡単な説明はこちら ）になります。

ウィンドウ座標を変換する

WindowsのRTLの世界では、 クライアント座標のみが展開されます。 ウィンドウ（デスクトップ）は通常のLTRの向きのままです。 この状況で最初に犠牲になるのは、ClientToScreenメソッドとScreenToClientメソッドです（この記事の「解説」セクション）。 これらのメソッドを直接使用しないため、RTLの状況を処理する方法をラッパーに教えるのに十分であることが判明しました。 Windows開発者が同じことができなかった理由を見つけるのが楽しいことがあります。 ところで、MSDNの推奨事項は、MapWindowPointsメソッドを使用することです。 新しく書かれたコードでは、そうすることが時々あったので、そうしました。



（プロジェクトでの単純な検索では検出されないため）さらに不愉快なのは、ウィンドウとクライアントの座標の計算に混同することです。 例は、マッピング座標セクションにあります。 幸いなことに、これは私たちのプロジェクトには当てはまりませんでした（すべての疑わしい場所を調べましたが、テストでは問題は見つかりませんでした）。 私は何を言うことができます：ちょうどそれをしないでください。

テキストがミラーリングされた理由の悲しい物語

フリッカーに対処するために、標準のバッファリング方法を使用します。すべての描画はメモリ内のBITMAPで行われ、最終的にはBitBltを使用してデバイスコンテキストに単純にコピーされます。 問題の原因は、いくつかのCreateCompatibleDCメソッドとSelectObjectメソッド（/*..*/、ビットマップ）で使用したラッパー、つまり、既定のパラメーターを持つコンストラクターを持つクラスにありました。



明示的なCBitmapDC（HBITMAPビットマップ、HDC compatibleWith = 0）;



このコンストラクターはコードのあらゆる場所で使用され、これがまさにデフォルトパラメーターで発生したことです。 結果として、結果のデバイスコンテキストはデスクトップと互換性があり（デスクトップ座標と同様にLTRのままです）、ペイントしたウィンドウとは互換性がありませんでした。 デフォルトのオプションが好きではなかった。 この誤解を修正した後、はるかに良くなりました。







ところで、テキストを配置するためのフラグを変更しなかったにもかかわらず（DT_LEFTを使用）、テキストは右にプッシュされます。 うまくいくだけで、それは素晴らしいことです。

絵を描く。 なぜ彼らは好転した

前のスクリーンショットからわかるように、イメージのミラーリングに関する問題は未解決のままです。 実際には、このセクションを「イメージリスト-気にしないように」と呼ぶ方が正しいでしょう。 実際、製品内の問題のあるグラフィックはすべてHIMAGELISTの形式で表示されます。 そして、ここでの問題は1つにはほど遠い。



描画中にイメージリストのアイコンが拡大しないように、MSDNはイメージリストの作成時にILC_MIRRORおよびILC_PERITEMMIRRORフラグを使用することをお勧めします。 Windows XP（Windows XP SP3の最小サポートバージョンはシステム要件で指定されています）以降、ILC_MIRRORフラグの動作とこれらのフラグの結合の動作に違いは見られませんでした。 いずれにせよ、このフラグを追加してもほとんど問題は解決しませんでした。



製品のほとんどすべてのグラフィックスには、システムパレットの8ビットとアルファチャンネルの32ビットの2つのバージョンがあります。 これは、他のすべての人の「美しさ」を維持しながら、それを必要とする人のための低色モードでの通常の操作に対して行われます。 また、上記のミラーリングの処理方法は、8ビットアイコンでのみ機能しました。 それは、システムメソッドImageList_Drawを使用して半透明のアイコンを描画するのではなく、独自の実装であるため、デバイスコンテキスト表現をDIBに直接描画するためです。 ちなみに、DIBはRTLについて何も認識しておらず、その中のピクセルは通常どおり左から右にインデックス付けされています。 したがって、問題はないはずです。 将来のRTLに備えて、共有ライブラリを担当するチームが悪名高いミラーリングを描画コードに追加していなければ、それらは起こりませんでした。 私が理解しているように、その理由は、RTLでグラフィックを操作する方法がまだ理解されていなかったためです（この問題の解決策の1つとしてのMSDNは、画像エディタでグラフィックをミラーリングして、再ミラーリング後に正しく表示されることを提案しています） 。 さて、私たちのグラフィックの作者の意見を述べます-この二重ミラーリングなしで作業する方がはるかに便利です。 グラフィックに3番目の問題があるためです。

RTL用に個別のグラフィックスが必要ですか？

一般的な場合、答えは「はい、必要です」です。 同じスクリーンショットに戻りましょう。 Wが逆になっているにもかかわらず、アイコンには1つの重要な利点があります。矢印は右方向（RTLの場合）に見えます。 はい、アラブ人（およびイスラエル人）にとって、「前方」の方向は右ではなく左です。 たとえば、比較用の英語（左）とアラビア語（右）UIを備えたWindows上のInternet Explorer：







矢印に加えて、非対称句読点が画像内にある場合、それらをミラーリングする必要があります。 ほとんどの場合、これは疑問符にのみ適用されます。







ちなみに、最初のスクリーンショットのタスクヘッダーの背景には、別のグラフィック（または描画時のミラーリング）が必要です。

ダイアログやその他のポップアップはどうですか？

前述したように、SetProcessDefaultLayoutを呼び出すだけで、ウィンドウを拡張できます。 ただし、最上位ウィンドウ（つまり、祖先として0を持つWS_POPUPウィンドウ）に加えて、他のポップアップウィンドウがあります。 たとえば、ダイアログ。 彼らは自動的にWS_EX_LAYOUTRTLを受け取りません。 しかし、ここではすべてがシンプルです。リソースでこのスタイルを指定するだけでよいか、リソースからポップアップ（WS_POPUP）ウィンドウが作成されない場合は、作成時にこのフラグを追加します。 たとえば、そのようなスタイルが親ウィンドウに存在するという条件の下で。 なぜマイクロソフトも途中で停止したのかと思うことがありますか？



実際には、作成のウィンドウフラグを常に制御するとは限りません。 また、プロパティページとウィザードの場合、すべてが単純な場合、レイアウトの方向は追加された最初のページによって決まり、メッセージウィンドウと標準ダイアログではより複雑になります。



まず、MessageBoxメソッドによって表示されるメッセージボックスについて。 反転するには、フラグの組み合わせを使用するだけで十分ですMB_RIGHT | MB_RTLREADING。 そのように。 もちろん、システムコールを直接ではなく、ラッパーを使用して使用すれば簡単です。 それ以外の場合は、これらのフラグを各MessageBox呼び出しに追加する必要があります（そして、アラビア語とヘブライ語が唯一のローカライズ言語ではない場合、特定の条件でこれを行います）。



標準のダイアログでは、すべてがより複雑でシンプルです。 レイアウトがオペレーティングシステムのローカライズのみに依存するため、より簡単です。 もっと難しい-同じ理由で。 何らかの理由でアプリケーション全体がRTLであることが重要な場合、松葉杖はこれなしでは実行できません。 ちなみに、同じことが「新しい」ファイルダイアログ（IFileDialog）にも当てはまります。 私たちのケースでは、問題がないことを考慮して、これをそのままにしました。

子ウィンドウ（WS_CHILD）がWS_EX_LAYOUTRTLフラグを必要としない場合の対処方法

前に言ったように、子ウィンドウは親からこのフラグを継承します。 ただし、これは必要ではない場合があります（たとえば、ABBYY FineReader Sprintでは、これは画像エディターウィンドウです-画像の出力、特にトリミング、ページングなどの選択フレームをミラーリングしても意味がありません）。 2つの方法があります-作成直後にこのフラグをクリアするか、親ウィンドウを作成するときにWS_EX_NOINHERITLAYOUTフラグを使用します。 ほとんどの場合、最初の方法がより合理的です。



ところで、私が言ったように、すべてのウィンドウが親からWS_EX_LAYOUTRTLスタイルを継承するわけではありません。 多くの一般的なコントロールは、他のコントロールに置き換えられます（RTLの方法で動作するため）。 たとえば、編集の場合、静的はフラグWS_EX_RIGHTの組み合わせになります| WS_EX_RTLREADING。



私が出会った最も珍しい間違いが関連しているのはこれです。 言語選択コンボボックスには、入力時にヒントの機能があります。







ご覧のとおり、キャレット位置にツールチップがポップアップします。 GetCaretPosメソッドを使用してキャリッジ位置を取得します。このメソッドは、クライアント座標でそれを返します。 次に、（MapWindowPointsを使用して）キャリッジのウィンドウ座標を取得し、そこにツールチップを配置します。RTLの場合、コンボボックスの反対側の端にツールチップが表示されます。







このエラーの理由は、キャリッジ位置を取得するクライアント座標がコンボボックスの座標ではなく、その子の編集コントロールだからです。 上記で述べたように、これは（コンボボックスとは異なり）WS_EX_LAYOUTRTLフラグを継承しません。 それぞれ修正は明らかです。MapWindowPoints呼び出しのウィンドウを正しいウィンドウに変更するだけです。

描画についての詳細。 今GDI +

MSDNは、RTL環境でのGDI +の使用を推奨していません。 つまり、GDI +メソッドは、それらが描画されるデバイスコンテキストのLAYOUT_RTLプロパティを考慮しません。 それにもかかわらず、試してみることができます-描画するときに座標を自分で変換するだけです。 次の方法が最も便利でした。LAYOUT_RTLプロパティが設定されたデバイスコンテキスト（HDC）を使用して、LPToDPメソッドを呼び出して座標を転送します。

ただし、これらの編集後、GDI +の描画コードはやや混乱することが判明したため、GDI +をまったく使用せずにこの製品を使用する方法を見つけました。



ミハイル・ヴァシルチェンコ、

テキスト認識製品部門