概要

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

Qt Quick Ultralite には 2 つのフォントエンジンオプションがあります：Monotype Spark と Static フォントエンジンです。

Monotype フォントエンジン

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

静的フォントエンジン

• 複雑なテキストを使用しないアプリケーションのサポートが向上し、フットプリントが小さくなりました。
• 静的な事前計算データで動作するため、非常に高速なルックアップ操作が可能。
• ビルド時にフォントを処理するため、実行時のオーバーヘッドがありません。

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

言語とライティングシステム

国際化サポートの一環として、Qt Quick Ultralite は、選択されたエンジンがサポートするすべての書記体系にビルトイン対応した入力コントロールとテキスト描画メソッドを提供します。テキストサブシステムは、さまざまな異なる書記体系の文字を含むテキストを同時にレンダリングすることができます。

対応言語、テ キ ス ト シ ェーピ ン グ機能、 フ ォ ン ト フ ァ イ ル機能は、 選択 し た フ ォ ン ト エン ジ ン に よ っ て異な り ます。テ キ ス ト シ ェーピ ン グは、 テ キ ス ト を表示す る ために必要不可欠な部分です。Unicode が対応す る すべての用字系でテ キ ス ト シ ェーピ ン グが必要なわけではあ り ませんが、 それ以外の用字系 （すなわち複雑な用字系） では、 読みやすいテ キ ス ト を表示す る ためにテ キ ス ト シ ェーピ ン グが必要です。アプリケーションが複雑なスクリプトに依存する言語を使用しない場合は、MCU.Config.complexTextRenderingを使用して、テキスト・シェーピング・エンジンをバイナリにリンクしないようにできます。複雑なスクリプトの例としては、アラビア文字やインド系スクリプトなどがあります。

Unicode 準拠の双方向テキストもサポートされており、正確な動作はUnicode Technical Annex #9 で定義されています。例外はテキスト項目で、アプリケーションで静的フォントエンジンが使われている場合は双方向テキストに対応していません。

機能比較表

次の表は、2 つのテ キ ス ト 処理オプシ ョ ンの主な相違点を示 し ますので、 適切な方を選ぶ こ と がで き ます。

テキス ト整列

テキストアイテムの水平アライメントが明示的に設定されていない場合、テキスト要素はテキストの自然な読書方向に自動的にアライメントされます。デフォルトでは、英語のような左から右へのテキストはテキストエリアの左側に揃えられ、アラビア語のような右から左へのテキストはテキストエリアの右側に揃えられます。

この暗黙のアライメントは、text要素の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
}

静的フォントエンジン

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

フォント

フォント エンジンは、FontFiles.filesQmlProject プロパティを使用してアプリケーションで使用されるフォントを見つけ、必要なフォント データを抽出します。

事前に計算されたデータ

デフ ォ ル ト では、 異な る フ ォ ン ト 設定の項目間でテ キ ス ト を割 り 当て る こ と をサポー ト す る ために、fontcompilerは、 アプ リ ケーシ ョ ン内で使用 さ れてい る すべての フ ォ ン ト 設定のすべてのキ ャ ラ ク タ を ラ ス タ 化 し ます。こ の例外はfont.unicodeCoverage とStaticText であ り 、 こ れは使用 さ れてい る フ ォ ン ト 設定に対 し てのみキ ャ ラ ク タ を登録 し ます。

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

こ の動作は、 メ モ リ フットプリ ン ト を削減す る ために、MCU.Config.autoGenerateGlyphs を用いて無効にする こ と がで き ます。この場合、font.unicodeCoverage で明示的に定義された文字だけがラスタライズされます。

事前計算されたデータは、テキストをレンダリングする必要があるすべてのもののための共有データソースです。これにはText とStaticText が含まれます。

このデータのランタイム保存の設定に関する詳細については、MCU.Config.glyphsCachePolicy、MCU.Config.glyphsStorageSection、およびMCU.Config.glyphsRuntimeAllocationTypeを参照してください。

グリフの埋め込み

MCU.Config.autoGenerateGlyphsの設定に応じて、フォントコンパイラは、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
        }
    }
}

フォントコンパイラはこのようなモデルデータに対してグリフを生成することができません。その結果、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 Spark 製品のページhttps://www.monotype.com/products/embedded-solutions/spark.

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

iType Spark フォントエンジン。

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

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

Monotype 社では、フォントファイルにさまざまなテクニックを適用して、必要なメモリを削減し、処理速度を最適化することができます。その一部を次のセクションで紹介します。Monotype Spark ライブラリーは高度に設定可能です。最適なパフォーマンスとメモリ使用量については、徹底したパフォーマンスガイドを含む Spark のドキュメントをお読みください。

WorldType Shaper Spark エンジン。

WorldType Shaper Sparkは、複雑な言語スクリプトからテキストをシェーピングするためのライブラリです。ウェアラブルのような小型デバイスでシェーピングを行うために高度に最適化されている。

WorldType Shaper SparkはOpenTypeテーブル、つまりGSUBとGPOSをサポートしていない。AppleのAdvanced Typographyフォーマットである'morx'/'kerx'テーブルを持つフォント、またはアラビア語、ヘブライ語、タイ語のUnicode to Unicodeシェーピングに対応するように設計されたフォント、つまりすべての表示形式のグリフを持つフォントでのみ動作する。有限状態機械を使うことで、'morx'テーブルは比較的小さく、比較的速く処理することができる。

また、テキストの並べ替えを含め、双方向スクリプトに必要なすべての処理を行う。WorldType Shaper SparkはUnicode 12.1.0仕様に完全準拠しています。

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

有効にする方法

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

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

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 ヒンティング命令は無視されることに注意してください。スパークヒンティングと 自動ヒンティングの項を参照。

フォントマップ

フォントマップは、複数のフォントファイルを1つのフォントマップファイルにまとめることができる概念です。Fontmap コンポーネントで使用できるのは TTF ファイルのみです。さらに、フォントマップは、Unicode範囲、Unicodeスクリプト、フォントクラスに基づいてフォントを選択することができます。Fontmap では、Unicode Script エントリはlanguage と呼ばれます。

Fontmapエディタは、Fontmapファイルを作成および/または修正するために使用できるアプリケーションです。エディタは<QT_INSTALL_PATH>\QtMCUs\<VERSION>\bin\ に解凍されます。 エディタはインストーラファイルとして提供され、ユーザーによる手動インストールが必要です。 Qt for MCUs 2.8 以降のバージョンでは、Fontmap エディタ v3.1.1 が同梱されており、Fontmap ファイルから未使用のグリフを削除して、アプリケーション上のフットプリントを減らすこともできます。このツールのドキュメントは Fontmap editor のメニュー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 - enum を文字列にマップします。例えば、Font.ExtraLight は "Extralight" になります。Font.Normalこ れは空文字列にマ ッ プ さ れます。
• font.bold - の同義語。font.weight: Font.Bold
• font.italic - セットされている場合、"Italic" にマップされ、セットされていない場合は空文字列にマップされる。

マッピング例

フ ォ ン ト バ イ ンデ ィ ン グの例を参照。

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

次の例のように、サンセリフフォントファミリーを使う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 のヒンティング命令は、必要なメモリが非常に少なく、パフォーマンスが向上するように設計されています。従来の TrueType ヒントがフォント内に存在する場合、Spark はそれを処理しないことに注意してください。新しいヒンティング命令の他にも、Spark は独自のヒンティング技術を適用してフォントサイズを大幅に縮小します。Spark のヒントは、メモリ使用量をさらに削減するために、オプションで圧縮することができます。

自動ヒンティング

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

グリフキャッシュ

グリフを初めてレンダリングする際、Sparkはグリフを作成し、キャッシュに保存します。その後、そのグリフを再度レンダリングしようとすると、再作成することなくキャッシュから直接フェッチされるため、パフォーマンスが向上します。グリフキャッシュの他に、SparkはCMAPとAdvanceキャッシュもサポートしている。これにより、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 に従って保存されます。キャッシュがメモリ不足になると、テキストレンダリングは次のフレームまでデフォルトの動作に戻ります。

フ ォ ン ト コ ンパ イ ラツールは--mergeStaticTextGlyphs オプシ ョ ンでStaticText アイテムのグ リ フ を 1 個の画像に結合す る こ と がで き る ので、 テ キ ス ト キ ャ ッ シ ュ はStaticText ア イ テ ムに対 し ては用い ら れません。こ のオプシ ョ ン を利用す る には、 プ ラ ッ ト フ ォームはBoardDefaults.qmlprojectconfig のMCU.Config ノ ー ド の下でMCU.Config.mergeStaticTextGlyphsを有効にす る 必要があ り ます：

MCU.Config {
    mergeStaticTextGlyphs: true
}

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

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

アプリケーションで使用されるテキストキャッシュのサイズは、パフォーマンスログを見ればわかる。

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

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

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