フォント管理とテキストスケーリング

(音楽)

(拍手) 私は Type Engineeringチームの フリオです 今日は進化したiOSの テキストとフォントについて 解説します まず アプリケーションで利用できる 新しいシステムフォントを紹介します

次にフォントの利用を可能にする アプリケーションの構築に フォントへのアクセス方法を 説明します それとフォントを選択する 新しいメカニズムです 最後にiPad AppをMacに 移植する時の― テキストスケーリングについて お話しします

始めましょう ３つの新しい システムフォントがあります １つはRoundedフォントで このリマインダー Appの 一番上のラベルがそうです

また Serifフォントも利用できます Apple Booksで よく見るフォントですね そして等幅フォントがあります Swift Playgroundsでおなじみです アプリケーションのUIでの これらの使用は Human Interface Guidelinesを 参照してください アクセスは 新APIの UIFontDescriptorを使います 定数は４つあります １つはdefaultで 標準システムの Sans-serifフォントです あと３つは 新しいシステムフォントの定数です この定数と新メソッドのwithDesignで Font Descriptorの デザインを変換します この例では インスタンス化した Boldシステムフォントから Font Descriptorを取得します Roundedフォントにしたいので rounded定数で withDesignを呼び出します これでRounded Boldフォントを インスタンス化できます 今 高レベルAPIで インスタンス化しました つまりフォント名では インスタンス化していません それが次のトピックです フォント名でインスタンス化する アプリケーションも多いですが これは 以前から推奨していません 新リリースから それはエラーになります インスタンス化には 高レベルのシステムコールが必要です 名前でのインスタンス化は ドットで始まるフォント名を使います つまりAppleのプライベートネームを 使っています 名前を使う理由はたくさんあります カスタムシステムフォントへの アクセスや ドキュメントのパースで 必要なフォントがある時です 名前でのインスタンス化を 適切に行えていないものが多く 時にはクラッシュします インスタンスの戻り値を見ずに 大丈夫と思い込むからです OSにあるフォントが変更されたり 削除されると そのフォントは存在しません アプリケーションはフォントが 別バージョンにあると推測できません インスタンス化の結果に注意し 必要に応じて別フォントに 置き換える必要があります

次は 開発者の私が ユーザとしても待ち望んでいた機能で アプリケーションでOSにフォントを インストールできます

Font Provider Appと呼びます 基本的にApp Storeに送信して OSで利用可能なフォントを提供します シンプルなUI設定も用意しました ユーザはインストールした フォントを閲覧し 不要なフォントを削除できます このアプリケーションの作成で 必要なことは エンタイトルメントの取得 さらにApp Storeへ送信する時― OSで使用可能にする 全フォントを送信することです フォントはバンドルするか Asset Catalogに入れます つまりOSは Font Provider Appに 勝手にインストールさせません App Storeにフォントを送信すると macOSのFont Bookと 同様の検証が実行されます １つはフォントの フォーマットタイプのチェックです サポートするのはttf otf ttcと その異体字です フォントスーツケースや PostScriptはサポートしません

エンタイトルメントの取得は簡単で Xcodeの新機能 Fontsで ２つのオプションから選べます １つはInstall Fontsです システム全体で利用可能なフォントを 提供できます もう１つはUse Installed Fontsです デフォルトではアプリケーションは― ユーザインストールのフォントに アクセスできません フォントの利用には これを選択する必要があります

そこで ユーザが アプリケーションに期待すること １つは フォントの参照や インストールや削除ができる― UIの提供です フォントをインストールできる アプリケーションが iOSにはなかったからです

また システムフォント変更通知に 応答が必要です なぜなら ユーザは設定で フォントを削除できるので それを把握し UIを更新する必要があります 大量のフォントを提供する― フォントメーカーの方にお願いします パッケージ化し Asset Catalogに入れ オンデマンドリソースを利用しましょう 必要なフォントを効率的に届けられます ユーザは フォントの一部を使うために 大きなフォントライブラリを ダウンロードしなくて済みます では デモマシンで この機能をお見せします

ドキュメントを閲覧する アプリケーションを App Storeから ダウンロードしたとします これをFont Consumer Appと 呼びましょう 左に ドキュメントの一覧があり 右に 内容を表示しています リロードすると シートが表示されます アプリケーションではなく OSが出しています アプリケーションで利用できない ３つのフォントに アクセスしようとしたからです 今 アプリケーションは フォントを置き換え Helveticaで表示しています そこで ユーザはApp Storeで― フォントをOSで使用可能にする アプリケーションを入手 それをFont Provider Appと 呼ぶことにします 左に フォントの一覧があり 右に プレビューが表示されます フォントを登録する時 再びシートが現れます アプリケーションでなく OSが出しています これが必要なのは 勝手にフォントを インストールさせないためです ユーザの同意が必要で そのためのダイアログです 同意しましょう

すべてのフォント名が黒になり フォントが登録されたことを 示しています 確認しましょう 設定から“一般”の “フォント”を開きます これは新項目です Font Provider Appによる― 全フォントが表示されます Century Schoolbookを選びます プレビューが表示されました では ここで フォントを削除しましょう Century Schoolbookは削除され リストから消えました ここで アプリケーションは フォントが削除されたことに気付き フォント変更通知を受け UIを更新し 赤で表示します 全フォントを再登録してみます

Font Consumer Appに戻ると Helveticaではなくなっています フォント変更通知を受け取り 全フォントが利用可能になったからです 他のドキュメントを見ても 利用可能になったフォントに 更新されました これらのアプリケーションをビルドする コードをお見せします CoreTextのCTFontManager.hで 新しいAPIを導入しました これらのAPIはすべて ヘッダファイルにあります フォントの登録方法は３つです １つは フォントファイルを指す FontURLsを使う方法 ２つ目は FontDescriptorを使う方法 ３つ目は Asset Catalogで 登録する方法です 大きなフォントライブラリの場合は Asset Catalogを作成し オンデマンドリソースで配信します この最後のAPIは お持ちのシードにはありませんが 次のシードで使用できます

またFont Provider Appが 登録済みのフォントに アクセスできるAPIもあります

最後は どのアプリケーションからでも フォントを確認できるAPIです さきほど見たエンタイトルメントで Use Installed Fontsを選択します ２つのデモ用Appで見てみましょう これはFont Provider Appで 約20個のフォントを持ちます ファミリで登録するため 全フォントファイルと そのURLを集めています そして登録APIを呼び出し 必要に応じてUIを更新します UIを更新するコードを見てみましょう Font Consumer Appと Font Provider Appの両方が 通知により UIを更新しています 同じ方法をこのデモで使います 通知を知る方法は簡単で NotificationCenterに監視させます kCTFontManagerRegistered FontsChangedNotificationです その通知を受け取ると 登録されたフォントを更新します あとでコードをお見せします 次に Font Provider Appの UIを更新します 登録済のフォントファミリは黒で 未登録は赤で表示されます フォントの登録には そのファミリを代表する― フォントファイルを集めます 新APIのCTFontManagerRegister FontURLsを呼び出し フォントURLのリストと 登録スコープのpersistentを渡します フォントをシステムワイドにする iOS 13の新機能です またブールフラグが有効で OSは全フォントが見られます APIはクロージャを使用します なぜなら 非同期APIだからです フォントの登録では クロージャが何回か呼び出され ここでエラーも発見されます 完了するとクロージャの Doneパラメータをtrueにします このデモでは クロージャはエラーを探すだけです UIは更新せず 更新については 通知メカニズムに任せます 通知で このメソッドが呼び出されます 新API CTFontManager CopyRegisteredFontDescriptorsで 利用可能フォントが分かります あとは Font Descriptorのリストを ログに記録し モデルを更新し そこからUIを更新します Font Consumer Appは ドキュメントをパースするだけです この種のアプリケーションで重要な点は パース中にインスタンス化できる フォントを把握し 欠けているフォントの 実行リストを保持することです フォントがないのは 未インストールか 使用可能になっていないのでしょう 新APIでこれらのフォントを OSから要求します そして UIやドキュメントを 更新します アプリケーションがパースするのは JSONというリッチテキスト形式の ドキュメントです フォントをインスタンス化し できなければHelveticaで置き換えます しかし置き換えたフォント名の 実行タブは保持しています そのフォント名のリスト つまりFont Descriptorの配列を作成し CTFontManagerRequestFontsに 渡します 新APIは そのフォントが Font Provider Appで インストール済みか確認します その後 App上で インスタンス化できます フォントがない場合は― 不足フォントのダイアログが 表示されます APIはクロージャを使用します そして このAppのために 利用可能になった フォントを更新します 他のアプリケーションから入手した フォントの利用は簡単です

次は― Font Provider Appで 重要なことがあります Font Provider Appは 自身のフォント以外は操作できません 例えば他のアプリケーションが登録した フォントの登録解除です 同様に 他のアプリケーションや システムがインストールした― フォントの上書きもできません 登録フォント数はOSに制限されますが 具体的な数字はなく インストールされた フォントのタイプによります 各フォントは 異なる量のリソースを消費します

ユーザフォントは フォールバックに使われません あなたのフォントが あるフォントの 唯一の代替と判断されても システムは自動的に 置き換えをしないということです 使用可能にする唯一の方法は フォント名での参照です そしてFont Provider Appは 自身のフォントを所有します ユーザがそのAppを削除すると フォントも削除されます そのようなAppを削除する時は システムが警告するので ユーザはバックアウトもできます 私の話は以上です 新機能について 私たちの興奮が 伝わったでしょうか OSに様々なフォントを インストールできることは 優れたコンテンツ作成に不可欠です そして この機能は 特にiPadプラットフォームで 力を発揮します 次は フォント選択の 新テクニックについて エリック･デュディアックが 解説します (拍手) ありがとう フリオ 私はUIKitチームのエリックです 先ほどはフォントの インストール方法でした 次は利用する方法です ユーザがアプリケーションで フォントを選択する方法を説明します

アプリケーションは最初に 使用可能な全フォントを ユーザに提示します そして １つを選択させます しかし表示されるのは システムフォントだけで カスタムフォントはありません プライバシーを考慮してです

代わりにインストールしたフォントを 選択するための 新しいView Controllerが UIKitにあります UIFontPickerViewControllerです

iOS 13の新しいシートで モーダルとして表示できます インスペクタ付きの 仕事効率化Appなどでは サイドバーに埋め込めます フォントピッカーがサポートします

UIFontPickerViewControllerを 見てみましょう アプリケーションとは 別のプロセスで実行されます

デフォルトは システムフォントだけの表示です ユーザフォントの表示には エンタイトルメントが必要です

ユーザがフォントピッカーで フォントを選択すると 通常のフォントAPIにより 使用可能になります しかしユーザが選択するまでは 使用できません

そして UIFontPickerViewControllerには カスタマイズオプションがあります

例えば 特定のフォントフェイスの 表示です デフォルトは フォントファミリのみが表示されます メールアプリケーションに似ています アプリケーションによっては Semi Boldなど 太さの表示が必要です それもオプションで表示できます さらに フォントをWYSIWYGで表示か デフォルトのシステムフォントで表示か 選択できます

また フォントの フィルタリングもできます 方法は２つです その１つは Traitによるフィルタリングです 例えばソースコードの表示は 等幅フォントが より自然な表示になります その時 等幅という特性で フィルタリングします

また 特定の言語の表示には その言語をサポートする 特定のフォントが必要です Filter Predicate APIを使い １つ あるいは組み合わせた言語で 必要なフォントをフィルタリングします この例では 中国語のフォントだけ 表示されています

macOSにもUIKit App用の フォントピッカーがあります 先ほど見た モーダル表示のシートの代わりに 従来のMacのメニューのような表示です

ユーザがボタンをクリックした時の 表示位置を制御するために UIPopoverPresentationControllerで 表示するビューを選択します

メニューの動作は 基本的にView Controllerと似ています

メニューの外をクリックすると閉じます フォントを選択すると― View Controllerのように デリゲートAPIを自動送信し メニューを閉じます

ユーザがMacと同様に フォント選択ができるよう 従来のmacOSエクスペリエンスを 提供しています

macOSでは 他にもオプションがあります これはmacOSと同じ フォントパネルで UIKit Appでサポートされます デフォルトの メニューバーオプションです いつでもオンとオフを切り替え アプリケーションの実行中も フォントを変更できます

フォントパネルの表示は プログラムで制御でき UITextFormattingCoordinatorで アクセスします パネルの表示の確認と オンとオフの切り替えができます

フォントパネルはモーダルではないため macOS上のアプリケーションでは 考慮が必要です フォントパネルからの変更は レスポンダチェーンをたどります 標準UIKitコントロールが UITextFormattingCoordinatorを 通して自動処理します 実際 UITextFormattingCoordinatorは フォントピッカーのデリゲートにでき レスポンダチェーンを通る変更の ルーティングもできます

ただし カスタムUIレスポンダが ある場合は UIResponseerStandardEditActions protcolメソッドで フォントパネルからの変更通知を 受け取る必要があります

それでカスタムUIレスポンダは 表示を更新できます

ではデモで見てみましょう

Font Consumer Appで カスタムフォントを使用しています このアプリケーションの優れた点は ユーザがフォントを選択できることです 簡単に変更できます “Change Title”をクリックします フォントピッカーが表示されます 一番上が 最近使用したもので 目的のフォントをここで探せます

フォントフェイスの表示を 追加しているので いくつでも表示できます スクロールしてフォントを探します Papyrusにしましょう タイトルのフォントが変わりました これは どのiOS Appでも 利用できる― 標準コントロールです

これはiPad Appですが macOS用にもビルドできます これは 先ほどの iPadOSと同じアプリケーションを macOS上で開いています タイトルメニューのフォントピッカーは まだカスタマイズしていません コードは変更せず 同じボタンをクリックします iPadOSで見たフォントピッカーでなく 代わりにメニューが現れます iPadOSのフォントピッカーと 機能は同じです 最近使ったものがトップで フォントフェイスも選べます WYSIWYGにしているので フォントの見え方が正確に分かります Comic Sansを選びます

macOS上では追加の カスタマイズができます フォントパネルを使って― さらに加えた変更を 本文を更新して反映させます macOSで実行中は “Change Body”ボタンでも フォントピッカーでなく フォントパネルが表示されます

ここで変更ができます フォントピッカーができる以上の カスタマイズがmacOSでは可能です 例えばサイズや色を変更できます

長年のMacユーザには 満足のゆく操作性です

このサンプルで起きたことを コードで見てみます

最初はフォントピッカーです まずコンフィギュレーションを 作成します コンフィギュレーション オブジェクトを初期化 表示にフォントフェイスを含めます

コンフィギュレーションを先に作るのは それがフォントピッカーの 動作を決めるからです コールバック取得のため 自身を フォントピッカーのデリゲートにします

そしてフォントピッカーを表示します

デリゲートコールバックによって― ユーザが選択したフォントが分かります フォントが選択されました フォントピッカーで選択された フォント情報を アプリケーションの 属性付き文字列に送ります

ユーザがキャンセルすると― その通知を受け取り 変更をキャンセルします

次は カスタムレスポンダコードで macOS上のフォントパネルの 処理を見ます フォントに変更が加えられた時― それを知らせるメソッドを実装しました 変更した属性ではなく 現在の属性を得る 便利なクロージャを使います ユーザの変更を適用した属性を セットで渡します その理由は 変更された場合と 同じままの場合があるためです 例えば下線があるテキストの 前景の色を変更する時 下線を変更してはいけません この場合はconversionHandlerが 処理します

では 最後にまとめます 全フォントでなく 必要なユーザフォントを表示するため iOSとiPadOSそしてmacOSで UIFontPickerViewControllerが使えます macOSのUIKit Appでは フォントパネルが使えます そこでApp実行中も カスタムレスポンダは 属性変更を処理する必要があります 標準Text Viewは 自動的に処理します

次はドナが テキストスケーリングを 解説します

(拍手) ありがとう エリック

テキストスケーリングは iOS 13と macOS Catalinaでの新概念です アプリケーションのテキストサイズの 一貫性を保つ方法を説明します

この表は Human Interface Guidelinesにある― デフォルトのフォントサイズです UIKit Appのテキスト本文は 17ポイントです

iPadで読みやすい大きさですね

しかしMac上では少し違って見えます

２つを並べて比較してみると Mac上で17ポイントは大きすぎます

これはMacのデフォルト フォントサイズが― 13ポイントほどだからです

しかし iPadで13ポイントを見ると

小さすぎて読めません この問題は以前からありました iOSではベースサイズとして 17ポイントを選択 読みやすく タッチ操作にも適しています

しかし今後は クロスプラットフォームが 重要になります iPad AppをMacで使う時― AppKit Appとの 文字サイズの違いに気付きます App間のコピー＆ペーストや 並べて表示した時です

一貫性を保つには どうすればいいでしょう 同じフォントとサイズで 同じテキストを見る時― ビジュアルスケーリングを 合わせるのが理想です ここに２つを並べました

iOSとiPadOSでデフォルトの 17ポイント表示を iOSテキストスケーリングと呼びます

macOSや他のプラットフォームで デフォルトの13ポイントは 標準テキストスケーリングと呼びます

開発者は２つの違いを認識し クロスプラットフォームでは― 標準テキストスケーリングを 使ってください 実際の例を見てみます

まず MacでのiPad Appです

UITextViewは 大量のテキストを表示するため 違いが目立ちますね 簡単な解決法があります

iOS 13で UITextViewに追加されたのが usesStandardTextScalingです オンにすると UIKitは自動的に 標準テキストスケーリングに合わせます

今は スケーリングが 少しズレていますね usesStandardTextScalingを オンにします

ずっといいですね 標準テキストスケーリング表示のための 優れたプロパティです

ただし デフォルトでは オフになっています Text Viewのカスタム変換のコードと 不具合があり得るためです 各Text Viewでオンにしてください

次はコピー＆ペーストです UIKitとAppKit App間の コピー＆ペーストは 文字の大きさに差がありました ユニバーサルクリップボードで ご存じですね

でも何もしなくて大丈夫 新OSでは このサイズ差がなくなります

仕組みはこうです iOSとmacOS間で コピー＆ペーストすると―

システム上の２つのレイヤー間を テキストが移動します 走る人はランタイムレイヤー ディスクは永続レイヤーです

ランタイムレイヤーに 属性付き文字列があります それをコピーすると 永続レイヤーのペーストボードに移動し その時RTFにシリアル化されます

新OSには RTFを書き込む NSAttributedString APIがあります 文字列からRTFを作成する時 テキストスケーリングの メタデータを追加します

つまりiOSでコピーすると iOSテキストスケーリングの メタデータが付きます

RTFから属性を読み取るAPIもあります テキストスケーリング メタデータを検索し フォントサイズを調整します

iOSでコピーしたテキストを Macでペーストする時 メタデータを読み取ります そして フォントサイズを調整 Mac上でもiOSの元のテキストと 同じ大きさに見えます

見た目は同じですが フォントサイズは違います iOSの元のテキストは17ポイントで Mac上のテキストは13ポイントです

サイズの違いが コピー＆ペーストで問題とならないのは ランタイムレイヤーの 一時的な情報だからです しかし 永続レイヤーには RTFは不適当です

ドキュメント交換用の テキストスケーリングが必要です

バランスを取るのは プラットフォーム間の視覚的一貫性と ドキュメントモデルの整合性です

ドキュメント内で 同じフォントサイズを維持するため テキストスケーリングを 表示と保存で分ける必要があります

方法は２つあります 表示と保存で フォントサイズを変える方法と レンダリングスケールを変えることで ビューを変更する方法です

RTFに対する この両方のアプローチを 実装しました 皆さんのワークフローや ドキュメント形式で役立つ テキストスケーリングの 基本的なテクニックを紹介します

タグ付けする テキストスケーリングメタデータは ドキュメントパーサーやビューアーに 必要な情報です

既存ドキュメントを タグ付きフォーマットにします RTFの場合 新OSで保存する時 自動的に行われます

またテキストスケーリングが正しいか 確認が必要です 最初の移行で特に重要です そこで新APIのNSAttributedStringを 紹介します

ドキュメント保存時に NSAttributedString APIで テキストスケーリング属性を メタデータに入れます

特定のテキストスケーリングへ 変換する場合は 変換前後の属性を指定します

モデル変更ではテキストスケーリングの 変換制御が必要です そのための NSAttributedString APIと 読み取りオプションがあります

読み取りオプションの指定で テキストスケーリングを制御できます

ビュー変更なら 標準テキストスケーリングを使います RTFドキュメントには 新APIを組み合わせます まずターゲットテキストの スケーリングを標準に設定し Text ViewでusesStandardTextScalingを セットします

以上です 今日は盛り沢山でした まとめましょう iOS Appからのフォント供給 フォント名でのインスタンス化は 新OSからは保証されません オンデマンドリソースでの配信 クロスプラットフォームの基本は 標準テキストスケーリングです

詳細については このあとの Text and Fontsラボか iPad App and Macラボで ご質問ください

新機能のご活用を期待します ありがとうございました (拍手)