概要

Qt Quick Ultralite では、テキストは `Text ` および `StaticText ` アイテムを使用して画面にレンダリングされます。これらのアイテムには、選択された `font ` の設定を制御するための `font` プロパティがあります。利用可能な API やフォントエンジン固有の詳細については、font 型のドキュメントを参照してください。

Qt Quick Ultralite には、Monotype Spark および Static の 2 つのフォントエンジンオプションが用意されています。

Monotype フォントエンジン

• 幅広い文字を使用する国際化アプリケーションに対するサポートが強化されています。
• 正しいレイアウトを確保するためにテキストシェーピングを必要とする言語への対応が強化されています。
• パフォーマンスやテキストの品質を損なうことなく、テキストのスケーリングをランタイムでサポートします。

静的フォントエンジン

• 複雑なテキストを使用せず、メモリ使用量が少ないアプリケーションに対するサポートを強化しました。
• 静的な事前計算済みデータに基づいて動作するため、非常に高速な検索操作が可能です。
• ビルド時にフォントを処理するため、実行時のオーバーヘッドが発生しません。

2つのフォントエンジンの詳細な比較については、「機能比較表」を参照してください。

言語および文字体系

国際化対応の一環として、Qt Quick Ultraliteは、選択したエンジンがサポートするすべての表記体系に対応した入力コントロールおよびテキスト描画メソッドを内蔵しています。テキストサブシステムは、さまざまな表記体系の文字が混在するテキストを同時にレンダリングすることができます。

サポートされる言語、テキストシェーピング機能、およびフォントファイルの機能は、選択したフォントエンジンによって異なります。テキストシェーピングは、表示用のテキストを準備する上で不可欠な要素です。Unicodeでサポートされているすべての文字体系がテキストシェーピングを必要とするわけではありませんが、その他の文字体系（いわゆる「複雑な文字体系」）では、読みやすいテキストをレンダリングするためにテキストシェーピングが必要です。 アプリケーションが複雑な文字体系に依存する言語を使用しない場合は、MCU.Config.complexTextRenderingを使用して、テキスト整形エンジンをバイナリにリンクしないように設定できます。複雑な文字体系の例としては、アラビア文字やインド系文字体系などが挙げられます。

Unicode 準拠の双方向テキストもサポートされており、その正確な動作はUnicode 技術付属書 #9 に定義されています。ただし、「テキスト」アイテムは例外であり、アプリケーションが静的フォントエンジンを使用している場合、双方向テキストをサポートしません。

機能比較表

以下の表では、2つのテキスト処理オプションの主な違いをまとめており、適切なオプションを選択するのに役立ちます。

テキストの配置

テキスト項目の水平方向の配置が明示的に設定されていない場合、テキスト要素は自動的にテキストの自然な読み方向に合わせて配置されます。デフォルトでは、英語のような左から右へのテキストはテキスト領域の左側に、アラビア語のような右から左へのテキストはテキスト領域の右側に配置されます。

この暗黙的な配置は、テキスト要素の horizontalAlignment プロパティを設定することで上書きできます。

// automatically aligned to the left
Text {
    text: "Phone"
    width: 200
}

// automatically aligned to the right
Text {
    text: "خامل"
    width: 200
}

// aligned to the left
Text {
    text: "خامل"
    horizontalAlignment: Text.AlignLeft
    width: 200
}

静的フォントエンジン

フォントファイルの処理はアプリケーションのビルド時に実行され、fontcompilerによって行われます。fontcompilerツールは、QtのFreeTypeベースのフォントエンジンに依存しています。fontcompilerからの出力は、ラスタライズされたグリフとフォントメトリクスの事前計算済みデータです。 実行時にはこのデータに何も追加・削除されることはなく、利用可能なグリフのセットはビルド時に決定されます。このデータに対するすべての操作は O(1) または O(log n) です。このフォントエンジンは、constant font configurations のみをサポートしています。

フォント

このフォントエンジンは、QmlProjectのプロパティである`FontFiles.files`を使用して、アプリケーションで使用されるフォントを特定し、必要なフォントデータを抽出します。

事前計算済みデータ

異なるフォント設定を持つアイテム間でテキストを割り当てることをサポートするため、デフォルトでは、fontcompilerはアプリケーションで使用されるすべてのフォント構成において、使用されるすべての文字をラスタライズします。ただし、font.unicodeCoverage およびStaticText は例外であり、これらは使用されるフォント構成の文字のみを登録します。

さらに、fontcompiler はデフォルトで、数字など、よく使用されるグリフの小さなセットを含んでいます。

メモリ使用量を削減するために、MCU.Config.autoGenerateGlyphs を使用してこの動作を無効にすることができます。その場合、font.unicodeCoverage で明示的に定義された文字のみがラスタライズされます。

事前計算されたデータは、テキストのレンダリングを必要とするあらゆる機能（Text やStaticText など）で共有されるデータソースとなります。

このデータの実行時ストレージの設定に関する詳細については、MCU.Config.glyphsCachePolicy、MCU.Config.glyphsStorageSection、およびMCU.Config.glyphsRuntimeAllocationType を参照してください。

グリフの埋め込み

MCU.Config.autoGenerateGlyphsの設定に応じて、fontcompilerは、QMLの文字列リテラルで使用されるすべての文字およびすべてのフォント設定に対応するグリフを、生成されるバイナリに埋め込むことができます。font.unicodeCoverage プロパティを使用することで、文字の選択範囲を拡張できます。これは、文字列が動的に生成され、コンパイル時に未知であるようなシナリオで必要となります。

MCU.Config.autoGenerateGlyphs が`false ` に設定されている場合、font.unicodeCoverage を使用して定義されたグリフのみが埋め込まれます。アプリケーションを慎重に設計することで、この手法によりメモリ使用量を大幅に削減できます。

font.unicodeCoverage プロパティの設定は、同じフォント設定を使用するすべてのQMLアイテムに影響を与えます。

QML での動的文字列のレンダリング

C++モデルからの文字列

C++モデルは、コンパイル時には未知の動的な文字列を生成することができます。次の例を考えてみましょう：

// MyModel.h
struct MyModelData
{
    std::string stringField;
};

inline bool operator==(const MyModelData &lhs, const MyModelData &rhs)
{
    return lhs.stringField == rhs.stringField;
}

struct MyModel : public Qul::ListModel<MyModelData>
{
    int count() const override { return 10; };
    MyModelData data(int index) const override
    {
        std::string data;
        for (int i = 0; i <= index; ++i) {
            data += 'a' + i;
        }
        return {data};
    }
};
// MyView.qml
Item {
    ListView {
        anchors.fill: parent
        model: MyModel { }
        delegate: Text {
            height: 20
            text: model.stringField
        }
    }
}

fontcompilerは、どのグリフが必要になるかを予測できないため、このようなモデルデータに対してグリフを生成することができません。その結果、QMLコンテンツのレンダリング時にグリフが欠落してしまいます。

モデルによって生成可能な文字範囲や、生成が必要なグリフをfontcompiler に指定するには、デリゲートで使用されるフォントの `font.unicodeCoverage ` プロパティを使用します。

Item {
    ListView {
        anchors.fill: parent
        model: MyModel { }
        delegate: Text {
            height: 20
            font: Qt.font({
                unicodeCoverage: [Font.UnicodeBlock_BasicLatin] // << define character set
            })
            text: model.stringField
        }
    }
}

C++関数からの文字列

文字列を返す C++ 関数は、C++ モデルと同じルールに従います。次の例を考えてみましょう。

// MyObject.h
struct MyObject : public Qul::Object
{
    std::string getDynamicString() const
    {
        std::string data;
        for (int i = 0; i < 26; ++i) {
            data += 'A' + i;
        }
        return data;
    }
};
// MyView.qml
Item {
    MyObject { id: myObject }
    Text {
        text: myObject.getDynamicString()
    }
}

動的文字列を使用する「Text」アイテムに対して、font.unicodeCoverage プロパティが設定されていない限り、前述のサンプルコードではグリフを正しく表示できません：

Item {
    MyObject { id: myobject }
    Text {
        text: myobject.getDynamicString()
        font: Qt.font({
            unicodeCoverage: [Font.UnicodeBlock_BasicLatin] // << define character set
        })
    }
}

Monotype

Monotype Spark 製品のページhttps://www.monotype.com/products/embedded-solutions/spark。

ドキュメントは<QT_INSTALL_PATH>\QtMCUs\<VERSION>\docs\monotype\ にインストールされています。これにはFAQを含むドキュメントも含まれています。

iType Spark フォントエンジン。

Monotype社のSparkフォントエンジンは、業界標準のTrueTypeフォント規格に基づいた、スケーラブルなフォントレンダリングサブシステムです。 このエンジンは、自動車用ディスプレイ、医療機器、白物家電、ウェアラブルデバイス、テレビ用セットトップボックス、ポータブルメディアプレーヤー、制御パネルなど、リソースに制約のある環境向けに設計されています。これにより、スケーラブルな書体と高品質な多言語フォント表示の利点を、組み込み環境にもたらします。

スペース効率と速度の両方に最適化された高性能アーキテクチャ。 Sparkは、数千文字を必要とする東アジア言語をサポートするアプリケーションやデバイスを含め、多くのアプリケーションやデバイスが求める厳しいサイズ要件を満たしています。Monotypeの最適化されたフォントと組み合わせることで、Monotype Sparkソリューションは、メモリの制約、複雑さ、またはプラットフォームのコストなどの理由で、これまでスケーラブルフォントの利用が困難だった状況においても、その利点を活用できるようにします。

Monotypeは、メモリ要件を削減し、処理速度を最適化するためにフォントファイルに適用できるさまざまな技術を提供しています。これらの技術の一部は、以下のセクションに記載されています。Monotype Sparkライブラリは高度にカスタマイズ可能です。最適なパフォーマンスとメモリ使用量を実現するには、詳細なパフォーマンスガイドを含むSparkのドキュメントをご参照ください。

WorldType Shaper Sparkエンジン。

WorldType Shaper Sparkは、複雑な言語の文字体系を用いたテキストのシェーピングを行うためのライブラリです。ウェアラブル端末などの小型デバイスでのシェーピング処理に最適化されています。

WorldType Shaper Sparkは、OpenTypeテーブル、すなわちGSUBおよびGPOSには対応していません。 AppleのAdvanced Typographyフォーマットである「morx」/「kerx」テーブルを持つフォント、またはアラビア語、ヘブライ語、タイ語のUnicode間シェーピングをサポートするように設計されたフォント（つまり、すべての表示形式に対応するグリフを持つフォント）でのみ動作します。 有限状態マシンを採用することで、「morx」テーブルを比較的小さく抑え、処理も比較的迅速に行うことが可能になっています。

また、テキストの順序変更を含め、双方向スクリプトに必要なすべての処理にも対応しています。WorldType Shaper Sparkは、Unicode 12.1.0仕様に完全に準拠しています。

このライブラリは、アプリケーションでフォントエンジンとして Spark フォントエンジンが選択された場合に、テキストシェーピングエンジンによって使用されます。

有効にする方法

デフォルトでは、Qt Quick のUltraliteアプリケーションは静的フォントエンジンを使用します。Monotype Sparkフォントエンジンを選択するには、MCU.Config.fontEngineターゲットプロパティを「Spark」に設定してください。サポートされているフォントエンジンの一覧については、「サポートされているフォントエンジン」を参照してください。このQmlProjectプロパティを設定すると、アプリケーションはMonotypeライブラリとリンクされます。

Monotype Spark フォントエンジンに切り替える際は、FontFiles.filesに、サポートされている形式のフォントファイルを指すエントリが 1 つだけ含まれていることを確認することが重要です。

MCU.Config {
    fontEngine: "Spark"
}
FontFiles {
    files: ["fonts/SampleFontmap.fmp"]
}

アプリケーションのフォントファイルのランタイムストレージの設定に関する詳細については、MCU.Config.fontFilesCachePolicy、MCU.Config.fontFilesStorageSection、およびMCU.Config.fontFilesRuntimeAllocationType を参照してください。

フォントとフォント形式

Monotypeの最適化済みフォントファイルは、<QT_INSTALL_PATH>\QtMCUs\<VERSION>\src\3rdparty\monotype\fonts\ にインストールされます。

TrueTypeフォント

あらゆるTrueTypeフォントがサポートされていますが、TrueTypeのヒンティング指示は無視される点に注意してください。「sparkヒンティング」および「自動ヒンティング」のセクションを参照してください。

フォントマップ

フォントマップとは、複数のフォントファイルを1つのフォントマップファイルに統合できる仕組みです。フォントマップコンポーネントで使用できるのはTTFファイルのみです。さらに、フォントマップでは、Unicode範囲、Unicodeスクリプト、およびフォントクラスに基づいたフォント選択が可能です。フォントマップにおいて、Unicodeスクリプトのエントリは「言語」と呼ばれます。

Fontmapエディタは、Fontmapファイルの作成や編集に使用できるアプリケーションです。 エディタは、<QT_INSTALL_PATH>\QtMCUs\<VERSION>\bin\ に展開されます。エディタはインストーラファイルとして提供され、ユーザーによる手動でのインストールが必要です。Qt for MCUs 2.8以降のバージョンには、Fontmapエディタv3.1.1以降が同梱されており、Fontmapファイルから未使用のグリフを削除して、アプリケーションへの負荷を軽減することも可能です。 このツールのドキュメントは、Fontmapエディタのメニュー「Help -> HelpTopics 」からアクセスできます。フォント選択アルゴリズムやパフォーマンスに関するヒントの詳細については、<QT_INSTALL_PATH>\QtMCUs\<VERSION>\docs\monotype\ をご覧ください。

CCC 圧縮フォント

CCCフォントは、Monotypeのフォント形式の一つであり、CCCと呼ばれるロスレス圧縮アルゴリズムを使用して、大容量のフォントテーブルを圧縮します。解凍時のオーバーヘッドがほとんどないため、圧縮率とリソースのバランスに優れています。すべてのTTFフォントをCCC形式に変換することができます。

エンジンの設定

フォントエンジンは、以下の QmlProject プロパティを通じて設定できます：

ヒープサイズとキャッシュサイズの最適な値は、入念なテストと調整が必要です。

Sparkは、外部で割り当てられたヒープメモリやキャッシュメモリでも動作します。

フォントクラスのマッピング

Fontmapファイルからのフォント選択に影響を与える要素の一つに、フォントクラス名があります。フォント選択の仕組みについては、Fontmapのドキュメントを参照してください。サポートされているフォントクラスの命名形式は「"<font.family> <font.weight> <font.italic>" 」であり、ここで：

• font.family - 設定されていない場合は、MCU.Config.defaultFontFamilyターゲットプロパティの値が使用されます。設定されている場合は、指定された文字列がそのまま使用されます。
• font.weight - 列挙型を文字列にマッピングします。例えば、Font.ExtraLight は "Extralight" になります。ただし、Font.Normal は例外で、空の文字列にマッピングされます。
• font.bold - これはfont.weight: Font.Bold
• font.italic - 設定されている場合は「Italic」にマッピングされ、そうでない場合は空の文字列にマッピングされます。

マッピングの例

フォントのバインディングの例を参照してください。

既存のアプリケーションの移植

次の例のように、sans-serifフォントファミリーを使用している QML アプリケーションがあると仮定しましょう：

Text {
    font.family: "sans-serif"
}

上記の例に合わせてフォントマップを設計するには、フォントファイル（TTF）をsans-serifフォントクラス名にマッピングする必要があります。これは、FontmapEditor GUI ツールを使用すれば簡単に実行できます。 QMLソースを変更したくないが、SansSerif.ttfとは異なるフォントファイルを使用したい場合は、Fontmapファイル内で「sans-serif」を「FrutigerOTS_S12-29g.ttf」にマッピングすれば問題ありません。 あるいは、ソースコード内の「sans-serif」という記述をすべて、例えば「FrutigerOTS」などに置き換えることもできます。その後、FontmapEditorで「FrutigerOTS」を「FrutigerOTS_S12-29g.ttf」にマッピングします。

フォントのヒンティング

Spark ヒンティング

Sparkのヒンティング命令は、メモリ要件を極限まで抑え、パフォーマンスを向上させるように設計されています。なお、フォントに従来のTrueTypeヒンティングが含まれている場合、Sparkはそれらを処理しません。新しいヒンティング命令に加え、Sparkは独自のヒンティング技術を適用することで、フォントサイズを大幅に縮小します。Sparkのヒンティングは、オプションで圧縮することができ、これによりメモリ使用量をさらに削減できます。

自動ヒンティング

実行時のメモリを節約するため、TrueTypeフォントのヒント処理はサポートされていないため、自動ヒント処理がSparkフォントエンジンに組み込まれています。システムフォントにSparkヒントが含まれていない場合、Sparkは自動ヒント処理を実行します。 自動ヒント処理のみでは、特に小さな文字サイズにおいて、Sparkヒントと組み合わせた自動ヒント処理と同等の高品質な結果は得られません。

グリフキャッシュ

グリフを初めてレンダリングする際、Sparkはそのグリフを作成し、キャッシュに保存します。その後、そのグリフを再度レンダリングしようとする場合、再作成することなくキャッシュから直接取得されるため、パフォーマンスが向上します。 グリフキャッシュに加え、SparkはCMAPキャッシュおよびアドバンスキャッシュもサポートしています。これにより、TrueTypeフォントの「CMAP」テーブルや「HMTX」テーブルをそれぞれ解析する場合に比べ、グリフIDやグリフアドバンスの取得が高速化されます。キャッシュが満杯になると、Sparkは使用頻度の低いエントリをキャッシュから削除します。

その他のキャッシュ設定として、Sparkでは、決して削除されないキャッシュエントリや、キャッシュに追加すべきでないグリフのサイズ閾値などを設定できます。これらの機能の一部は、Qt for MCUs ではまだ利用できません。

詳細については、MCU.Config.fontCacheSizeのドキュメントを参照してください。

キャッシュの初期化

パフォーマンスをさらに向上させるために、キャッシュにデータを事前に読み込んでおくことが役立つ場合があります。これにより、特にテキスト量が多いアプリケーションの場合、起動時間が大幅に短縮されます。

font.unicodeCoverage プロパティを使用すると、アプリケーションのビルド時にキャッシュプリミングデータに含める文字を選択できます。アプリケーションの実行時に初めてフォントエンジンにアクセスされると、キャッシュプリミングデータがMCU.Config.glyphsStorageSectionからSparkのキャッシュメモリにコピーされます。

詳細については、MCU.Config.fontCachePrimingのドキュメントを参照してください。

キャッシュプライミング処理において、StaticText 用に保存されているグリフと共通するグリフが検出された場合、実行時にSparkのキャッシュを初期化する際、StaticText データからそれらのグリフを取得することで最適化が行われます。この最適化により、必要なフラッシュメモリの容量を節約できます。

テキストのキャッシュ

Qt Quick Ultraliteは、テキスト内の各グリフや文字を個別に描画します。このデフォルトの動作では、描画エンジンへの頻繁な呼び出しにより、パフォーマンス上のオーバーヘッドが発生します。この動作によってパフォーマンスが低下するプラットフォームでは、テキストキャッシュの代替方式に切り替えてください。これにより、各テキスト要素をCPU側で個別の画像としてキャッシュできるようになり、描画エンジンへの呼び出し回数が削減されます。

さらに、MCU.Config.fontVectorOutlinesDrawing が有効になっている場合、テキストのアウトラインもキャッシュされます。これにより、テキスト要素が描画されるたびに、対応するPathData を再計算する必要がなくなります。

アプリケーションでテキストキャッシュを有効にするには、Qul::Application クラスの代替コンストラクタを実装してください。このコンストラクタは、次の例に示すように、Qul::ApplicationConfiguration インスタンスを受け入れる必要があります。

Qul::initHardware();
Qul::initPlatform();

Qul::ApplicationConfiguration appConfig;
appConfig.setTextCacheEnabled(true);
appConfig.setTextCacheSize(128 * 1024);
Qul::Application app(appConfig);

static MainScreen item;
app.setRootItem(&item);
while (true) {
    uint64_t now = Qul::Platform::getPlatformInstance()->currentTimestamp();
    // <handle timers>
    uint64_t nextUpdate = app.update();
    if (nextUpdate > now) {
        // Device can go to sleep until next update is due

        // enterLowPowerMode(nextUpdate - now);
    }
}

テキストキャッシュのサイズが設定されていない場合、Qt Quick Ultraliteは、プラットフォームのメインCMakeLists.txt で設定されたデフォルトサイズである24KBを使用します。サイズを変更するには、プラットフォームのCMakeLists.txt ファイルに、QUL_PLATFORM_DEFAULT_TEXT_CACHE_SIZE用のPlatform ターゲットプロパティを追加してください。

テキストキャッシュ用のメモリは、Qul::PlatformInterface::MemoryAllocator::TextCache を通じてプラットフォーム層から割り当てられます。単一のメモリバッファが事前に割り当てられ、テキストキャッシュによって内部的に管理されます。内部的な管理処理を考慮するため、実際のバッファサイズはアプリケーションが要求した値よりわずかに大きくなる場合があります。

テキストキャッシュはこのバッファ内でキャッシュエントリの割り当てを管理し、LRU戦略を用いてエントリを再利用します。エントリはQUL_PLATFORM_DEFAULT_NUM_FRAMES_TO_PRESERVE_ASSETS に従って保持される場合があります。キャッシュのメモリが不足した場合、テキストのレンダリングは次のフレームまでデフォルトの動作に切り替わります。

StaticText 項目については、textキャッシュは使用されません。これは、fontcompilerツールが--mergeStaticTextGlyphs オプションを使用して、StaticText 項目のグリフを単一の画像に結合できるためです。このオプションを使用するには、プラットフォームがBoardDefaults.qmlprojectconfig 内のMCU.Config ノードでMCU.Config.mergeStaticTextGlyphsを有効にする必要があります：

MCU.Config {
    mergeStaticTextGlyphs: true
}

mergeStaticTextGlyphs これは実験的なAPIであり、以下の制限があります：

• テキストは常に左揃えとなり、実行時に設定されたプロパティは無視されます。
• Monotype Spark フォントエンジンはサポートされていません。
• QtQuick::Text::textFormat はサポートされていません。

アプリケーションが使用するテキストキャッシュのサイズは、パフォーマンスログを確認することで確認できます。

適切なキャッシュサイズの選択に関するヒントについては、「リソースキャッシュ」を参照してください。

グリフレイアウトのキャッシュ

詳細については、MCU.Config.glyphsLayoutCacheSize を参照してください。