TextKit 2について

TextKit 2について

TextKit 2について: Appleの次世代テキストエンジンであり、設計の見直しによって正確性、安全性、性能が向上しています。TextKit 2を使用することで、世界各国のユーザにより優れたテキスト体験を提供し、テキストコンテンツとビジュアルコンテンツを組み合わせることでレイアウトを多様化して、スムーズなスクロール操作を実現する方法を紹介します。最新のAPIを紹介して、いくつかの実用的な事例を詳しく検証して、Appを最新化するための指針を提示します。

リソース
関連ビデオ

WWDC22
- TextKitおよびテキストビューの最新情報
WWDC21
- AppKitの新機能
- UIKitの新機能
ダウンロード

Donna: こんにちは TextKitエンジニアのDonna Tomです同僚のChris Willmoreものちほど登場しますこれからTextKit 2を紹介します Appleの次世代テキストエンジンです
TextKit 2を理解する上でまずオリジナルのTextKitを振り返りましょうここではTextKit 1と呼びます TextKit 1はテキストエンジンです Appleの全プラットフォームにテキストのレイアウトや表示を行います UIKitとAppKitのテキストコントロールはストレージ管理とテキストのレイアウト制御に TextKit 1を使用します
TextKit 1はOpenStepのシステム上で初登場しました 20年以上前のことです以来年月を重ね私たちと共に進化しました macOS 10.0から iOS 7 そしてmacOS 11やiOS 14まで
素晴らしいのは TextKit 1が今でも Appleの全デバイスの基本的機能の土台であることですテクノロジーデザインとエンジニアリングの原則は年月を重ね大きく変化しました TextKit 1はオリジナルの原則に基づいているため高水準のパフォーマンスを維持しつつ最新技術に適合するAPIを提供することが年月の経過とともに難しくなりました
そこで TextKit 2を開発しました TextKit 2は前進的なデザインの原則にに基づいた Appleの次世代テキストエンジンです実はあなたもすでにそのMacで TextKit 2を使っています Big Surでは OS内の多くのテキスト要素が更新され TextKit 2がバックグラウンドで利用されています TextKit 2は実は macOS 11から提供されていたのですこれを可能にするアーキテクチャを簡潔に振り返りましょう
TextKit 2は TextKit 1と共存し
先代と同様 TextKit 2はFoundation QuartzそしてCore Textの上位に構築されています UIKitとAppKitのテキスト制御は TextKit 2の上部に構築されていますまたTextKit 2は先代のMVCデザインをゆるい形で継承しています ”View"には UIKitと AppKitフレームワークのオブジェクトをそのまま配置一方おなじみの NSTextStorageと NSLayoutManagerの最新バージョンも搭載しています
これらの最新バージョンに加えて新しいクラスとプロトコルを多数 ModelとControlのレイヤーに追加していますかなり多数ありますがご安心をこの新しいコンポーネントはとてもシンプルで相互にパワフルに作用します
テキストの表現がより簡単になりシステムの動作について心配する必要もありません
システムの全体像を確認したところで詳細を見ていきましょう
TextKit 2のコアデザイン原則を見てみましょうまずこれらの原則がAppのストレージやレイアウトテキスト表示のカスタマイズにいかに変化を及ぼすか
その後 Chrisが TextKit 2のサンプルAppでレシピ本の事例を紹介します
このAppは新しい TextKit 2クラスで CALayersでのテキストのレイアウトや表示に用いますではこれからデザインの原則の実践方法を学びましょう
最後に TextKit 2に向けた Appの最新化における重要な技術的な詳細についてお話します
ではデザインの原則から始めましょう
TextKit 2のハイレベルなコアデザインの原則は正確さと安全性そしてパフォーマンスですバランスのあるアプローチを取りましたこれら３つの原則はそれぞれ重要で優先順はありません
これらのハイレベルなデザインの原則がシステム内の特定のデザイン変更を規定します
正確さにおいて TextKit 2はグリフ処理を抽象化し
安全性においては TextKit 2は値セマンティクスをより重視し
パフォーマンスではビューポートベースのレイアウトとレンダリングを採用しました
まず正確性についてはグリフ処理を抽象化しました各言語のテキストで一貫性のある体験を担保するためです Appleのデバイスは世界中で使われているため各言語とスクリプトにおけるレイアウトやレンダリングテキストとのインタラクションが正確に提供されることがとても重要です
誰もが自分のデバイスでテキストを読み操作できる環境を提供することです TextKit 1 APIのいくつかのデザインでは言語によっては作業が困難でグローバルな正確性を担保できない場合があります
原因を理解するためにはまずグリフとは何かを理解する必要がありますグリフは様々なタイプの文字の変数を視覚的に表します
多くの西洋言語では１つのグリフは通常１つの文字を示しますしかし常にそうであるとは限りません
１つの文字に複数のグリフがある場合やその逆もありますつまり１つのグリフで複数の文字を表すパターンです
このように複数の文字を表す単一グリフは合字と呼ばれます
西欧言語には合字は多くありませんそして文章の読みやすさにも影響は与えません合字なしでも十分に読むことができます
しかし全ての言語がそういうわけではありませんアラビア文字やデーヴァナーガリーなどは多くの合字を使用しテキストの読みやすさに影響を与えますアラビア文字表記を見てみましょう
これはウルドゥー語で ”瞬間"を意味しますここでこの２つのレンダリングを比較してみましょう
右側が合字で表示したもの左側が個別の文字で表示したものです差は歴然で
ネイティブの読み手にとって左側は判読不可でしょう
TextKit 1の多くのAPIではグリフのインデックスまたは範囲が重要です例えばテキストの境界矩形を確保するにはテキストのグリフ範囲の確認が必要です
テキストが西洋言語の場合グリフ範囲の判定は比較的簡単です
英語で見てみるとテキスト冒頭の４文字に係るグリフ範囲はすぐにわかりますね
次にカンナダ語を見て見ましょうインドで 100万人に話されている言語です
多くの合字が必要なだけでなく様々な形のグリフの順番の入れ替えや結合があります
カンナダ語で"10月"を意味するこの言葉では４つ目の文字インデックスの分割母音でグリフが２つに分割し
１と２の文字の合字が適用される前に左側でこの二文字を表すグリフの順番が変わります
インデックス３の文字を表すグリフは結合型に代替されます
最終的な言葉では分離した母音のグリフの１つの下に配置されますさて今お話しした内容が理解できなかったとしても全く問題ありません
このフレームワークがこれらの処理をしてくれるのでデベロッパはApp構築に集中できます
つまりこのようなテキストの最初の４文字のグリフ範囲を把握するのは不可能ですこの４文字を表すグリフ範囲は存在しません
多くのTextKit 1 APIではグリフ範囲が要求されるためこれらのAPIを使用すると複雑な文字群に対してレイアウトやレンダリングを崩してしまう可能性がありますこのため TextKit 2ではグリフ処理を抽象化します TextKit 2はCore Textで全テキストをレンダリングし複雑な文字でも正しいレンダリングが自動的に得られます
TextKit 2ではグリフの管理は一才必要がありませんその代わりテキストのレイアウトやインタラクションには高レベルのオブジェクトを使用します
NSTextSelectionはこの高レベルオブジェクトの１つです
テキストの選択に必要な粒度や類似性　および選択を構成するテキスト範囲の分割といったすべてのコンテクスト情報を含みます
こうしたNSTextSelection のプロパティは読み出し専用です選択オブジェクトのインスタンスは変更できませんただし NSTextSelectionNavigation のインスタンスを使い選択の結果を表す NSTextSelectionの新しいインスタンスを受けてテキスト選択のアクションを実行します
ナビゲーションオブジェクトに照会して画面のポイント上のタップやマウスダウンによる選択の結果を得たり前後のナビゲーションで得られる新しい選択を入手することもできますこれで言葉１つ分で選択を拡大したり右から左の言語での双方向のテキストに対応して正しい結果を得たりするなどさまざまな作業を容易にできます
これらの新しい選択APIについて興味深い話を紹介しますこの方法には NSTextLocationを使用しますこれもTextKit 2に搭載の新しいオブジェクトです
ではNSTextLocationと NSTextRangeを紹介します
この２つはUIKitのUITextPositionと UITextRangeクラスによく似ていますただしどちらもサブクラス化する必要はありません通常 TextKit 2ではデフォルトの場所と範囲オブジェクトを使用します
整数の代わりにオブジェクトを利用するのでより豊かなドキュメントモデルが可能です互いとの相対的な場所に基づき範囲が決まるからです HTMLドキュメントオブジェクトモデルはこの良い例ですネスト化された要素を持つため場所はドキュメント内の絶対的ポジションと目に見えるテキストのポジションの両方を表す必要があります単一の数値化したインデックスではこれは表現できません
ここまで正確性についてお話ししましたここからは安全性についてです
TextKit 2は値セマンティクスに重点を置いてデザインしました SwiftやSwiftUIのテクノロジーの目的との整合性を改善するためです
”値セマンティクス”というのは値のタイプのことではありません私たちはNSLayoutManager を構造に含めませんでした
値のタイプはデータの変化を防止するデータのユニークコピーを維持します意図せぬ共有を防いだり関連する副作用をなくしコードを安定かつ安全にするものですでも値のタイプはこの目的を達成する唯一の方法ではありません
不変クラスは初期化後に変更不可のプロパティを保持するのでデータの改変を防止します
これらのクラスは値のタイプと同じ挙動をするため値セマンティクスとして参照しますあるオブジェクトのデータを変更したい場合オリジナルを置き換える新しいインスタンスの作成が必要です TextKit 2に含まれる多くのクラスはこのようにデザインされています
このデザイン変更による恩恵を理解するため TextKit 1のデザインについて記憶を新たにしましょうストレージからスクリーンへのテキストのフローは以前はこのような仕組みでした
テキストストレージへの更新がレイアウトマネージャに通知されレイアウトマネージャはこれを受けグリフを生成しグリフをビューへ直接配置し描きます
このようにビューへ直接グリフを描くアプローチではカスタム描画のスペース生成でテキストを分離する箇所がわかりにくいという問題がありました
これを理解するためにこの画像を見て下さいサンプル用Appです私がレシピにコメントを残しました
コメントがレシピの下の目立つバブル型の青い背景に白字のテキストで表示されます
コメントを正しい場所に配置して残りのテキストと差別化するにはどうすれば良いでしょうか
このようなアプローチを考えられるかもしれませんレシピテキストを意味あるまとまりごとまたは要素ごとに分けそれぞれのコメントをそれぞれの要素に収め関連するレシピの後に配置しコメントの表示方法に関する指示を提供するといった方法です TextKit 1では実際の運用は大分異なります心配すべき事項が数々ありますグリフインデックスを探したりグリフが書記素クラスタの中にないことを確認したりもし中にあればグリフインデックスを修正し行間を変更したり行フラグメントのジオメトリをカスタマイズするなど
これらの詳細は本来の目的にあまり関係ありませんそこでTextKit 2ではこれらの期待を現実にしこうしたアプローチを可能にするためシステム内のテキストのフローを変更しました
TextKit 2のフローを紹介します
テキストストレージへのアップデートはコンテンツマネージャという新オブジェクトを経由します
コンテンツマネージャはテキストを要素に分解しそれらを追跡しますレイアウトの際にはテキストレイアウトマネージャがコンテンツマネージャに要素を照会します
テキストレイアウトマネージャはテキストコンテナへ要素を配置しそしてレイアウトと配置の情報を含むレイアウトフラグメントを生成します
表示の段階ではレイアウトフラグメントが ViewportLayoutControllerへ送られビューかレイヤーかのレンダリングサーフェスに従いフラグメントのレイアウトと配置を調整します
ご覧のようにこのプロセスには多くの新しいオブジェクトが関わりますここで値セマンティクスの出番です
正しいポイントでシステムにアクセスしテキストのレイアウトと表示をコントロールし値セマンティクスを利用するオブジェクトから必要な情報を取得します
変更する場合まず希望する変更を値オブジェクトの新しいインスタンスで作成しますそしてそれをシステムに戻しますシステムはその置換オブジェクトの値を利用しレイアウトとディスプレイに反映します
では新しいオブジェクトとこれらオブジェクトの受信や置き換えが発生するシステム内の異なるポイントを把握しましょうまずはストレージオブジェクトの
NSTextElementです要素はドキュメントを構成するものですそれぞれの要素はコンテンツの一部分を示しドキュメント内の場所を表す範囲を含みます要素は値セマンティクスを含みます範囲を含むこれらのプロパティは不変で要素作成以降は変更不可能です
文字の連続でなく要素の連続としてドキュメントを形作る場合よりパワフルな操作が可能になります与えられた要素がどのようなコンテンツに対応するのかすぐ判別が可能になりますテキスト段落添付ファイルあるいはその他のカスタムタイプかこれらのタイプによって要素の配置を決定できます
次に NSTextContentManagerです
コンテンツマネージャはテキストコンテンツから要素を生成しドキュメント全体の中で各要素の範囲を確認しますまたバッキングストアとも連携しバッキングストア内のコンテンツに変更があると更新された範囲で新しい要素を生成します
コンテンツマネージャはバッキングストアをまとめたものであるとみなせます
コンテンツマネージャは生データを要素へと翻訳するインターフェイスを提供します
NSTextContentManagerと NSTextElementは共に抽象型ですカスタムのドキュメントモデルやバッキングストア使用時にこれらをサブクラス化することができますヘッダーと文書化が良い例ですですが通常は TextKit 2のデフォルトを利用できます
次にNSTextContentStorageと NSTextParagraphですこれらはデフォルトのコンテンツマネージャと要素タイプです NSTextContentStorageはコンテンツマネージャで NSTextStorageをバッキングストアとして利用します
テキストストレージのコンテンツ分割を担い段落の要素つまりNSTextParagraphのインスタンスに分けることができます NSTextContentStorageはまたテキストストレージ内のテキストが変更した時更新された段落の要素を生成しますここが重要なポイントですが
下層のテキストストレージに変更を加える時 performEditingTransaction メソッドで更新内容をラップしますこれであなたが行った変更について TextKit 2の他の部分が通知されます
コンテンツストレージのデリゲートで NSTextContentManagerサブクラスをフル実装する必要がなく様々なことが実現できます
後ほどコンテンツデリゲートでテキストストレージを変更せずコメントのフォントや色を変更する方法やコメントをすべて非表示にする方法を Chrisが説明しますこの後もお楽しみに
では TextKit 2がテキストコンテンツから要素を生成する流れが理解できたので新しいアプローチの最初の２つのステップをカバーできます
コンテンツストレージは自動的にテキストを段落ごとに分解し新しいコメントに新しい段落を作成します
次に最後の２つのステップについてお話しますコメントの位置と表示ですこのフローに戻りましょうコメント要素に関するレイアウト情報を入手しますこのタスクのための新しいレイアウトオブジェクトがありますでは見てみましょう
NSTextLayoutManagerですこのマネージャはテキストレイアウトの処理を管理します NSTextLayoutManagerは TextKit 1の NSLayoutManagerに似ていますが大きな違いが１つあります NSTextLayoutManagerはグリフを扱いません
その代わり NSTextLayoutManagerはテキスト要素をテキストコンテナに並べてこれら要素のレイアウトフラグメントを生成します
あなたもテキスト要素のレイアウト情報の取得にフラグメントを使いますねではレイアウトフラグメントについて学びましょう
NSTextLayoutFragmentですレイアウトフラグメントは１つ以上のテキスト要素のレイアウト情報を含みます要素同様に値セマンティクスを使用しプロパティは不変です
テキストレイアウトマネージャは各コメント要素に対してレイアウトフラグメントを作成しレイアウトフラグメントの情報を基にコメントを配置し表示します
レイアウトフラグメントはレイアウト情報を３つのプロパティを通して伝達します textLineFragmentsの配列 layoutFragmentFrame そしてrenderingSurfaceBoundsです
レイアウトを変更またはカスタマイズする場合各プロパティから得る情報を理解する必要がありますそれをこれから見ていきます
最初のプロパティは NSTextLineFragmentですラインフラグメントはレイアウトフラグメント内のテキストの各行の測定情報を含みます
これらは特定の行の幾何学的情報の取得やレイアウトフラグメント内の行数のカウントに役立ちます
第２のプロパティレイアウトフラグメントフレームはレイアウトフラグメントのテキストがどのようにテキストコンテナ内での配置されるか規定します TextKit 2ではテキストレイアウトは基本的にコンテナ内のレイアウトフラグメントフレームをスタックしますこれらのフレームをタイルとして捉えてみましょうシステムはテキストコンテナのエリアをタイルに分割します各レイアウトフラグメントは１つのタイルと捉えられます
この表のように空の行はそれぞれレイアウトフラグメントフレームを有します一般的にレイアウトフラグメントフレームは UIの他のビューをフラグメントコンテンツの近くに配置したりテキストコンテンツ全体の高さを計測するのに役立ちます
このフレームはテキストの配置に必要なスペースを正確に表していませんその情報は第３のプロパティから得られますレンダリングの表面の境界はテキストを描写するエリアを示していますこの長方形を使ってビューの座標空間でのテキストのサイズを取得しますこれはレイアウトフラグメントフレームとは異りますというのもテキストはフラグメントフレームの端を超える場合があるからですこれは発音区別符号やイタリックフォントの下部が長い場合に発生します ”J"の左端を見てくださいフレームからほんのわずかですが突き出ていますもっと極端な例では
”Zapfino”などのフォントではタイポグラフィの枠を大きくはみ出るグリフを持つ場合がありますレンダリングの表面の境界がレイアウトフラグメントフレームよりかなり大きくなる場合がありますさて
レイアウトフラグメントが提供するレイアウト情報について理解できたところで少し戻ってみましょうこの情報の使ったテキストレイアウトのカスタマイズについて話しましょう
レイアウトフラグメントは不変なのでフラグメント上でレイアウト情報を直接変更できません
このフローに戻りますレイアウトプロセスを使い変更したい情報で NSTextLayoutFragmentの新しいインスタンスを作成します
NSTextLayoutManagerのデリゲートメソッドを使いレイアウトプロセスを組みますレイアウトマネージャが要素からレイアウトフラグメントを生成する時このメソッドが呼び出されますここで要素について独自のレイアウトフラグメントを作成することができます
これでコメントに関する問題へのアプローチで最後の２つのステップが解決します NSTextLayoutFragmentのサブクラスを使ってコメントのレイアウトフラグメントの配置とカスタム描写に対処しレイアウトマネージャのデリゲートでカスタムフラグメントのインスタンスを提供します
ビデオの後半では ChrisがサンプルAppのデモでこの方法を紹介します
以上が安全性についてです次にパフォーマンスです
パフォーマンスはどのテキストエンジンでも最も難しい課題の１つです TextKit 2は非常に高速で幅広いシナリオに対応していますそれぞれ数行ずつのラベルを即時にレンダリングしたり数百メガバイトのドキュメントをスムーズにスクロールできるようにしたりこれらのシナリオで非常に大きなドキュメントを様々なレートで扱う場合不連続のテキストレイアウトが優良なパフォーマンスには不可欠です
ここで連続と不連続のレイアウトの違いを振り返りましょう
この図を見てください黄色い四角は画面上で表示されたコンテンツを示します
連続レイアウトはドキュメントの最初から最後まで順番に進みます
ドキュメントの中央にスクロールする場合連続レイアウトはスクロールしたポイントよりも前の全てのテキストに対してもレイアウトを実行します
つまり画面外のテキストも含み冒頭からスクロールされたテキスト全てですもしテキストが大量の場合パフォーマンスが遅くなりアニメーションがあればスクロール時に問題が発生したり最悪の場合フリーズする可能性もあります
一方で不連続レイアウトではドキュメント内のどの箇所でもテキストの一部をレイアウトできそれ以前のテキストのレイアウトは不要です
ドキュメントの中央までスクロールした場合現在画面に表示される部分がすぐにレイアウトされます
表示部分のテキストだけにレイアウトが実施されるのでパフォーマンスが向上しますオーバースクロールの域でもスムーズなスクロールが実現します TextKit 2でのレイアウトは常に不連続です
一方TextKit 1では不連続レイアウトはオプトインで
NSLayoutManagerのブール型プロパティで有効化されますこのAPIはシンプルですがそれゆえにレイアウト情報のリクエスト時にレイアウトの状態を表現できません
不連続のレイアウトはドキュメントの別の部分がレイアウトされた時点で変わり得る予測に基づいています TextKit 1では非連続レイアウトのオンオフしか設定できませんドキュメントがレイアウトされる部分について一切管理できずレイアウトが終了したかまたは正しい値に更新されたかなどを確認できません
TextKit 2のAPIはより豊かで表現の幅も広がります
TextKit 2では表示されるコンテンツ領域内の要素のレイアウト情報を常時提供しこの表示領域にレイアウトアップデートがあれば通知します
このエリアをビューポートと呼びます自分でビューポートを管理し調整や移動ができますビューポートレイアウトの前や途中そして後にコールバックを受け取れます
最適なパフォーマンスのためにあなたのコードはビューポート領域内のレイアウト情報に集中すると良いでしょうビューポート外部の要素についてはレイアウト情報のリクエストを避けましょう
ビューポート外部の要素のビューポートレイアウト情報はテキスト範囲のレイアウトがこれらの要素にマッチしていることを明示的に確認しない限り正確ではない可能性がありますドキュメントのボリュームが大きければコストも高くなります
先程のフローに戻りますビューポートの管理に利用できるもう１つの新しいコントローラクラス
NSTextViewportLayoutController がありますこれがビューポートのレイアウト情報の正確な情報のソースですビューポート内の要素のレイアウトフラグメントを取得するためテキストレイアウトマネージャに照会しますビューポートレイアウトコントローラへはテキストレイアウトマネージャのプロパティからアクセスできます
ビューポートレイアウトコントローラについて見たところでビューポートレイアウトプロセスについて話します
ビューポートレイアウトコントローラはビューポートレイアウトプロセスの間デリゲートで３つの重要なメソッドを呼び出します TextViewportLayoutController WillLayout textViewportController configureRenderingSurface FortextLayoutFragment textViewportLayoutController DidLayoutです
まずビューポートに要素を配置する前にレイアウトコントローラが willLayoutメソッドを呼び出しますここでビューまたはレイヤーのコンテンツをクリアにするなどレイアウトの準備のための設定を行います
次にビューポートで表示される全レイアウトフラグメントに対しレイアウトコントローラがconfigure RenderingSurfaceを呼び出しますここで各フラグメントビューまたはレイヤーのジオメトリをアップデートします
最後にビューポートで表示される全レイアウトフラグメントのレイアウト完了後にビューポートレイアウトコントローラが didLayout methodを呼び出します
ビューポートレイアウト完了後に変更の必要があればここでアップデートを行います例えば最後の要素を画面でフル表示させるためビューポートを調整したい場合などに該当します以上パフォーマンスについてお話ししましたここからChrisにバトンタッチして TextKit 2の使用方法を紹介しますありがとうDonna これから私たちが作成したサンプルAppを例に TextKit 2を使った App内のテキストレイアウトや操作の方法を紹介しますここで紹介するサンプルコードはダウンロードできるので入手して実践してみてくださいこのコラボAppで今日のランチに何を作るか決めるのにレシピ本をチェックします期待通りレシピをスクロールできますこの時バックグラウンドでは特別なことが起きていますビューポートで目視可能なパラグラフのみここに表示されています全パラグラフが画面全体にレンダリングされる代わりに各パラグラフがそれぞれのレイヤーにレンダリングされます
ツールバーの「Show Bounds」ボタンをクリックすると色付きの長方形が表示されますオレンジ色の長方形は各レイヤーの境界を示しますテキストを各レイヤーに個別に描画するとレシピにコメントを書く機能を実装できますエッグサンドが美味しそうなのでこのパラグラフをダブルクリックし「すごく美味しそう」とタイプしてみます Enterキーでコメントが挿入されました
これで今このドキュメント内に新しいパラグラフを挿入したことになりますバブルの背景は NSTextLayoutFragmentのカスタムサブクラスで描かれたもので BubbleLayoutFragment と呼びます後で詳しくお話しします
ドキュメントにコメントを挿入すると挿入箇所以降のパラグラフがコメントに必要なスペースを確保できるよう移動します最初見てわからなかった場合はツールバーのこの亀のボタンをクリックするとスローモードに変わります
別のコメントを追加してみましょう「今日ランチでも一緒に」そしてEnterを押すとドキュメントの下に挿入されそれ以降の全てのバラグラフがゆっくりアニメで移動しますもし全てのコメントを非表示にするなら ”Toggle Comments"ボタンをクリックしますツールバーにありますこれはベースドキュメントを編集するものではなくテキスト要素をレイアウトにenumerateする際テキストコンテンツマネージャに対してコメントをスキップするようリクエストするものです
TextKit 2はmacOS同様 iOSにもよく対応していますつまりTextKit 2で作成した macOS Appの一部を iOS版でも利用できます iPadで見てみましょう
コラボAppのiOS版で同じ機能を実装するコードを使用しましたコメントを残すため文を長押しますそして「それいいね」と入力してそして「Enter」します
macOS版と同様にコメントの「表示／非表示」ボタンをタップしコメントを全て非表示にできます
TextKit 2を利用した Appを通じてテキスト操作とレイアウトを実践してきましたこのサンプルAppを例にコードと TextKit 2の役割を確認しましょう
このAppではTextKit 2が提供する数々の機能を実現していますがここでは２つの点に焦点を当てます NSViewportLayoutController によるビューポートでのテキストレイアウトそしてカスタム設定したコメントの非表示設定とレンダリングの実装です
ドキュメントに変更があったかコンテナのサイズが変更したかまたはそれまで未表示だったドキュメントの部分がビューポートに移動したかいずれかの理由でレイアウトマネージャがドキュメントをレイアウトする際 textViewportLayout ControllerWillLayoutをビューポートレイアウトデリゲートに呼びますここではテキストサブレイヤーを全て解除しアニメーショントランザクションを起動するために使います
テキストレイアウトマネージャが担当する各テキスト要素について textViewportLayoutController configureRenderingSurfaceFor textLayoutFragment を呼び出しますここではジオメトリの更新や新しい位置へのアニメーションそして可能であればビューのサブレイヤーへの追加のためにテキストレイアウトフラグメントを表示するレイヤーを取得します描画もそれをサブレイヤーとして加える
レイアウトマネージャはレイアウト完了後 textViewportLayout ControllerDidLayoutを呼びますアニメーションの移行をコミットしセレクションのハイライトを更新そしてコンテンツサイズも更新し Scroll Thumbが正しく配置されるようにします
コメントについて話しましょう TextKit 2はレイアウト要素のカスタマイズとレイアウトフラグメントの生成に利用できる複数のフックを提供しています今からドキュメントからコメントを抽出しフォントやカラー等のカスタム属性を設定したりその背後のバブルを描画する方法を紹介します
ドキュメントの各パラグラフではテキストコンテンツストレージがそのパラグラフの属性をカスタマイズするための機会をデリゲートに与えますこの実装では基層のテキストストレージのフォントやカラーを変えることなくコメントのフォントやカラーだけをカスタマイズできる設定です
またテキストコンテンツマネージャはレイアウト時どのテキスト要素をテキストレイアウトマネージャに提示するかを判断するチャンスをデリゲートに与えます
テキスト要素に対し Falseを返すとその要素の表示を防ぎますコメントをenumerateしないことで基層のテキストストレージから削除せずにコメントを非表示にすることができます
テキストレイアウトマネージャにもデリゲートがあります textElementに textLayoutManager textLayoutFragmentFor location を実装することでデリゲートは特定のNSTextElementに対してデフォルトの NSTextLayoutFragment インスタンスではなくカスタムテキストレイアウトフラグメントを生成できますこの場合コメントを司る NSTextElementに遭遇すると NSTextLayoutFragment のサブクラスである BubbleLayoutFragment を作成します
BubbleLayoutFragmentは NSTextLayoutFragmentの描画メソッドをオーバーライドしベースクラスの実装を呼び出す前にテキストを背景バブルに重ねて描画しますまたテキストはそして先程設定したカスタムフォントとテキストカラーでレンダリングされます
ここまでサンプルAppを通じて TextKit 2でのビューポートベースのテキストのアニメーションレイアウトとカラフルなバブルのコメントのレンダリングをテキストストレージのカスタム属性からカスタム描画まで確認してきましたサンプルコードには他にも TextKit 2の新しいAPIの利点を活用するための内容が豊富に含まれていますテキスト選択を決定するマウスの動きの解釈やテキスト選択ハイライトのレンダリングまた特定のパラグラフへのコメントポップオーバーの配置そしてドキュメントの高さの推定などこれらのトピックの詳しい情報をサンプルコード内で確認できますではDonnaから TextKit 2に向けたAppの準備方法を紹介してもらいますありがとうChris TextKit 2の実装例のとても良い紹介でした TextKit 2の魅力について理解したところで Appの最新化へのアプローチについて話します
ここまでお話した内容は一般的なビューやレイヤーに使う独自のTextKit 2スタックの作成に適用します iOS 15のUIKitまたは macOS 12のAppKitで新しいクラスの全てが入手可能ですこのアプローチを選ぶ場合は今すぐTextKit 2で新しいコードを書き始められます
一方多くのAppはテキストビューなどのテキストコントロールを使っておりアクセシビリティサポートや選択・編集サービスなどの優れた機能を無料で利用できますこれらのコントロールの一部は TextKit 2向けに既にアップデートされています Appでビルトインコントロールを採用するなら下記のような追加の詳細に注意してください互換性の維持は Appleにとっても皆さんにとっても重要です TextKit 1はビルトインコントロールの重要な要素だったことを踏まえこれを使用しているAppでの互換性の維持に注力する必要があります iOS 15とmacOS 12で一部のコントールだけが自動的にTextKit 2を利用するのはこのためです
さらに一部のコントロールがこれらの OSバージョンでTextKit 2を使うには追加のステップが必要です AppKitデベロッパに関して NSTextViewはTextKit 2を自動的に使用しません
NSTextViewに対応したTextKit 2を使いたい場合は作成時にコード上でオプトインする必要があります
以下がその方法ですまずテキストレイアウトマネージャを作成します次にテキストコンテナを作成しますそしてテキストコンテナを NSTextLayoutManagerの textContainerプロパティを使ってテキストレイアウトマネージャに関連付けます最後にここでテキストコンテナの指定イニシャライザを使って NSTextViewを作成しますこれでTextKit 2を使用したテキストビューができます
NSTextViewでの新しいプロパティでテキストレイアウトマネージャとテキストコンテンツストレージにアクセスできますでも1つ注意が必要です
NSTextViewには NSLayoutManagerの取得と設定を許可する layoutManagerプロパティがあります
NSLayoutManagerは TextKit 1のオブジェクトで TextKit 2スタックとの互換性はありません
テキストビューではレイアウトマネージャとテキストレイアウトマネージャを同時に利用できません
そのため必要な場面で TextKit 1に切り替えるための特別な互換性モードを NSTextViewに追加しましたテキストビューはこのモードが必要な場面を自動的に検知し NSTextLayoutManagerを NSLayoutManagerに置き換えますパフォーマンスの最適化のためにその後のテキストビューは互換性モードを維持します
仮にTextKit 2をオプトインしてもテキストビューやテキストコンテナに layoutManagerプロパティを明示的に呼び出す場合テキストビューは自動的に TextKit 1に切り替わります
テキストが未対応だったり TextKit 1が必要な条件が検知されたりした場合もテキストビューが切り替わります
同様のことがフィールドエディタでも起こります NSTextFieldのフィールドエディタはデフォルトでTextKit 2を使いますがテキストフィールドのサブクラスがフィールドエディタのレイアウトマネージャからレイアウト情報をリクエストするとフィールドエディタはウィンドウ内の全テキストフィールドで TextKit 1に切り替わります
TextKit 1に切り替わる前と後にシステムが通知しますこれらの通知に含まれる情報も確認できます
この通知オブジェクトにはモード変更の対象となるテキストビューへのレファレンスが含まれます
AppKitの TextKit 1互換性モードに関する完全な詳細情報は Apple Developerポータルのドキュメントを参照してください
UIKitデベロッパの場合 UITextFieldはiOS 15で自動的にTextKit 2を使います
TextKit 2のUITextViewは iOS 15では利用できません
Appleでは UITextViewを使う数々のAppすべてに関してできる限りの互換性を保証できるよう努めていますその間デベロッパ側では UITextViewの layoutManagerプロパティについて既存のコードを確認しつつ TextKit 2でのインテントの表現方法を検討してくださいそうすれば TextKit 2に合わせてスムーズに移行できるでしょう
では以上になります Appleが未来へ導く最新テキストエンジン TextKit 2についてご理解いただけたと思います皆さんがこれから TextKit 2で構築するAppを楽しみにしていますありがとうございました [陽気な音楽]

32:22 - Responding to layout updates: textViewportLayoutControllerWillLayout()

func textViewportLayoutControllerWillLayout(_ controller: NSTextViewportLayoutController) {
    contentLayer.sublayers = nil
    CATransaction.begin()
}

32:47 - Responding to layout updates: textViewportLayoutController(_:configureRenderingSurfaceFor:)

private func animate(_ layer: CALayer, from source: CGPoint, to destination: CGPoint) {
    let animation = CABasicAnimation(keyPath: "position")
    animation.fromValue = source
    animation.toValue = destination
    animation.duration = slowAnimations ? 2.0 : 0.3
    layer.add(animation, forKey: nil)
}

private func findOrCreateLayer(_ textLayoutFragment: NSTextLayoutFragment) -> (TextLayoutFragmentLayer, Bool) {
    if let layer = fragmentLayerMap.object(forKey: textLayoutFragment) as? TextLayoutFragmentLayer {
        return (layer, false)
    } else {
        let layer = TextLayoutFragmentLayer(layoutFragment: textLayoutFragment, padding: padding)
        fragmentLayerMap.setObject(layer, forKey: textLayoutFragment)
        return (layer, true)
    }
}

func textViewportLayoutController(_ controller: NSTextViewportLayoutController,
                                  configureRenderingSurfaceFor textLayoutFragment: NSTextLayoutFragment) {
    let (layer, layerIsNew) = findOrCreateLayer(textLayoutFragment)
    if !layerIsNew {
        let oldPosition = layer.position
        let oldBounds = layer.bounds
        layer.updateGeometry()
        if oldBounds != layer.bounds {
            layer.setNeedsDisplay()
        }
        if oldPosition != layer.position {
            animate(layer, from: oldPosition, to: layer.position)
        }
    }
    if layer.showLayerFrames != showLayerFrames {
        layer.showLayerFrames = showLayerFrames
        layer.setNeedsDisplay()
    }
    
    contentLayer.addSublayer(layer)
}

33:10 - Responding to layout updates: textViewportLayoutControllerDidLayout()

func textViewportLayoutControllerDidLayout(_ controller: NSTextViewportLayoutController) {
    CATransaction.commit()
    updateSelectionHighlights()
    updateContentSizeIfNeeded()
    adjustViewportOffsetIfNeeded()
}

33:47 - Overriding text attributes for comments

func textContentStorage(_ textContentStorage: NSTextContentStorage, textParagraphWith range: NSRange) -> NSTextParagraph? {
    // In this method, we'll inject some attributes for display, without modifying the text storage directly.
    var paragraphWithDisplayAttributes: NSTextParagraph? = nil
    
    // First, get a copy of the paragraph from the original text storage.
    let originalText = textContentStorage.textStorage!.attributedSubstring(from: range)
    if originalText.attribute(.commentDepth, at: 0, effectiveRange: nil) != nil {
        // Use white colored text to make our comments visible against the bright background.
        let displayAttributes: [NSAttributedString.Key: AnyObject] = [.font: commentFont, .foregroundColor: commentColor]
        let textWithDisplayAttributes = NSMutableAttributedString(attributedString: originalText)
        // Use the display attributes for the text of the comment itself, without the reaction.
        // The last character is the newline, second to last is the attachment character for the reaction.
        let rangeForDisplayAttributes = NSRange(location: 0, length: textWithDisplayAttributes.length - 2)
        textWithDisplayAttributes.addAttributes(displayAttributes, range: rangeForDisplayAttributes)
        
        // Create our new paragraph with our display attributes.
        paragraphWithDisplayAttributes = NSTextParagraph(attributedString: textWithDisplayAttributes)
    } else {
        return nil
    }
    // If the original paragraph wasn't a comment, this return value will be nil.
    // The text content storage will use the original paragraph in this case.
    return paragraphWithDisplayAttributes
}

34:06 - Hiding comments

func textContentManager(_ textContentManager: NSTextContentManager,
                        shouldEnumerate textElement: NSTextElement,
                        with options: NSTextElementProviderEnumerationOptions) -> Bool {
    // The text content manager calls this method to determine whether each text element should be enumerated for layout.
    // To hide comments, tell the text content manager not to enumerate this element if it's a comment.
    if !showComments {
        if let paragraph = textElement as? NSTextParagraph {
            let commentDepthValue = paragraph.attributedString.attribute(.commentDepth, at: 0, effectiveRange: nil)
            if commentDepthValue != nil {
                return false
            }
        }
    }
    return true
}

34:28 - Generating special layout fragments for comments

func textLayoutManager(_ textLayoutManager: NSTextLayoutManager,
                       textLayoutFragmentFor location: NSTextLocation,
                       in textElement: NSTextElement) -> NSTextLayoutFragment {
    let index = textLayoutManager.offset(from: textLayoutManager.documentRange.location, to: location)
    // swiftlint:disable force_cast
    let commentDepthValue = textContentStorage!.textStorage!.attribute(.commentDepth, at: index, effectiveRange: nil) as! NSNumber?
    if commentDepthValue != nil {
        let layoutFragment = BubbleLayoutFragment(textElement: textElement, range: textElement.elementRange)
        layoutFragment.commentDepth = commentDepthValue!.uintValue
        return layoutFragment
    } else {
        return NSTextLayoutFragment(textElement: textElement, range: textElement.elementRange)
    }
}

34:58 - Drawing the comment bubble

var commentDepth: UInt = 0

private var tightTextBounds: CGRect {
    var fragmentTextBounds = CGRect.null
    for lineFragment in textLineFragments {
        let lineFragmentBounds = lineFragment.typographicBounds
        if fragmentTextBounds.isNull {
            fragmentTextBounds = lineFragmentBounds
        } else {
            fragmentTextBounds = fragmentTextBounds.union(lineFragmentBounds)
        }
    }
    return fragmentTextBounds
}

// Return the bounding rect of the chat bubble, in the space of the first line fragment.
private var bubbleRect: CGRect { return tightTextBounds.insetBy(dx: -3, dy: -3) }

private var bubbleCornerRadius: CGFloat { return 20 }

private var bubbleColor: Color { return .systemIndigo }

private func createBubblePath(with ctx: CGContext) -> CGPath {
    let bubbleRect = self.bubbleRect
    let rect = min(bubbleCornerRadius, bubbleRect.size.height / 2, bubbleRect.size.width / 2)
    return CGPath(roundedRect: bubbleRect, cornerWidth: rect, cornerHeight: rect, transform: nil)
}

override var renderingSurfaceBounds: CGRect {
    return bubbleRect.union(super.renderingSurfaceBounds)
}

override func draw(at renderingOrigin: CGPoint, in ctx: CGContext) {
    // Draw the bubble and debug outline.
    ctx.saveGState()
    let bubblePath = createBubblePath(with: ctx)
    ctx.addPath(bubblePath)
    ctx.setFillColor(bubbleColor.cgColor)
    ctx.fillPath()
    ctx.restoreGState()
    
    // Draw the text on top.
    super.draw(at: renderingOrigin, in: ctx)
}

37:26 - Opting NSTextView in to TextKit 2

var scrollView: NSScrollView!
var containerSize = CGSize.zero
var textContainer = NSTextContainer()

// Important: Keep a reference to text storage since NSTextView weakly references it.
var textContentStorage = NSTextContentStorage()

override func viewDidLoad() {
    super.viewDidLoad()
    
    scrollView =
        NSScrollView(frame: NSRect(origin: CGPoint(),
                                   size: CGSize(width: view.bounds.width, height: view.bounds.height)))
    scrollView.translatesAutoresizingMaskIntoConstraints = false
    view.addSubview(scrollView)
    
    NSLayoutConstraint.activate([
        scrollView.leadingAnchor.constraint(equalTo: (view.leadingAnchor)),
        scrollView.trailingAnchor.constraint(equalTo: (view.trailingAnchor)),
        scrollView.topAnchor.constraint(equalTo: (view.topAnchor)),
        scrollView.bottomAnchor.constraint(equalTo: (view.bottomAnchor))
        ])
    
    setUpScrollView(scrollsHorizontally: false)
}

func setUpScrollView(scrollsHorizontally: Bool) {
    scrollView.borderType = .noBorder
    scrollView.hasVerticalScroller = true
    scrollView.hasHorizontalScroller = scrollsHorizontally
    
    setUpTextContainer(scrollsHorizontally: scrollsHorizontally)
    setUpTextView(scrollsHorizontally: scrollsHorizontally)
}

func setUpTextContainer(scrollsHorizontally: Bool) {
    let contentSize = scrollView.contentSize
    if scrollsHorizontally {
        containerSize = NSSize(width: CGFloat.greatestFiniteMagnitude, height: CGFloat.greatestFiniteMagnitude)
        textContainer.containerSize = containerSize
        textContainer.widthTracksTextView = false
    }
    else {
        containerSize = NSSize(width: contentSize.width, height: CGFloat.greatestFiniteMagnitude)
        textContainer.containerSize = containerSize
        textContainer.widthTracksTextView = true
    }
}

func setUpTextView(scrollsHorizontally: Bool) {
    let textLayoutManager = NSTextLayoutManager()
    textLayoutManager.textContainer = textContainer

    textContentStorage.addTextLayoutManager(textLayoutManager)

    // Workaround: Pass textLayoutManager.textContainer to the NSTextView initializer
    let textView = NSTextView(frame: scrollView.contentView.bounds, textContainer: textLayoutManager.textContainer)

    textView.isEditable = true
    textView.isSelectable = true
    textView.minSize = CGSize()
    textView.maxSize = containerSize
    textView.isVerticallyResizable = true
    textView.isHorizontallyResizable = scrollsHorizontally
    textContentStorage.performEditingTransaction {
        textView.textStorage?.append(NSAttributedString(string: "Text content..."))
    }
    scrollView.documentView = textView
}

特定のトピックをお探しの場合は、上にトピックを入力すると、関連するトピックにすばやく移動できます。

クエリの送信中にエラーが発生しました。インターネット接続を確認して、もう一度お試しください。

リソース

関連ビデオ

WWDC22

WWDC21