資産レビューで何を確立する必要があるかを定義する
A BIMI ファイル名が SVG で終わっているか、ブラウザで描画できるため、ロゴの準備ができていません。有用なハンドオフは、その構造、視覚的アイデンティティ、受信機の要件、および最終的にホストされるバイトを個別にレビューできる特定の候補です。承認されたブランド アートワークから始めて、その所有者を特定し、プロジェクトの対象となる送信ドメインと受信サービスを記録します。これにより、技術的に整然としたグラフィックが、承認された企業マークや保証されたメールボックス インジケーターと間違われるのを防ぎます。
この記事では、保存されているBIMIグループの実装ガイダンスと Google の受信者ドキュメントを使用します。 BIMI 、確立されたIETF Standards Track RFC ではなく、草案作業のままです。このレビューでは草案文書を完全な一次テキスト検証に利用できなかったため、これはソースを対象とした準備ワークフローであり、完全な規範適合仕様ではありません。 Google の要件は特にGmail要件であり、すべてのメールボックスに対する普遍的なルールではありません。
プロファイルを図面から分離する
BIMIグループは、Portable/Secure を SVG Tiny 1.2 よりも制限されたプロファイルとして説明しています。その作成ガイドでは、バージョン 1.2、baseProfile tiny-ps、および title 要素が必要です。指定された XML 名前空間、スクリプト、アニメーション、インタラクティブ要素、およびルート svg 要素の x または y 属性以外の外部参照は除外されます。プロファイル ラベルを変更するだけでは、ファイル内の他の場所にある禁止されたコンテンツは削除されません。冒頭の行だけでなく、実際の XML 構造と参照を確認してください。 BIMIグループ作成ガイダンス
受け入れ証明書ではなく、設計エクスポートを入力として使用します。簡略化する前に、要素、属性、埋め込みコンテンツ、および依存関係をインベントリします。デザイナーが画像ラッパーをエクスポートした場合は、承認されたデザイン ワークフローを通じてアートワークを本物のベクター ジオメトリに解決します。エクスポートにフィルターまたはアニメーションが含まれている場合は、視覚効果を適切な単純な静的構造に置き換えるか、デザインを修正してください。 BIMIグループのトラブルシューティングでは、埋め込み画像とサポートされていないエフェクトを問題として特定します。 SVGのトラブルシューティング
受信機の要件を強度を混ぜることなく適用する
Gmailの場合、Google は幅と高さの両方が少なくとも 96 ピクセルであることを要求しており、パーセンテージではなく絶対ピクセルで表されます。 Google は、中央に配置された正方形の構成、無地の背景、32 KB 以下のファイル、およびアクセシビリティのための説明要素を個別に推奨しています。必要な寸法と推奨されるプレゼンテーションの区別を維持してください。チームは推奨事項を独自の受け入れルールとして採用できますが、より強力な普遍的義務をソースに帰するのではなく、その決定にラベルを付ける必要があります。 Google SVG の要件
正方形のキャンバスは、目に見えるマークがすべての端に触れなければならないという意味ではありません。円形または丸みを帯びたプレゼンテーションによって切り取られる可能性のあるフィーチャの周囲には、意図的にスペースを残しておきます。狭いストロークや内部のネガティブスペースなど、小さなサイズでのコントラストと認識を評価します。これらは提案されたデザインレビュー基準であり、 Gmailまたは別の受信者がこの候補をレンダリングしたという証拠ではありません。検査でシミュレートされた作物、ローカル プレビュー、または実際のメールボックスが使用されたかどうかを記録し、後でレビューする人がそれらを区別できるようにします。
最適化によるアイデンティティの維持
ブランド所有者に、簡略化された候補と承認されたマスターを比較するよう依頼します。パス数を最適化するか、未使用の定義を削除すると、文字の形、グラデーション、またはシンボルが変更される可能性があります。間違ったマークが描かれたきれいなファイルは、許容できる結果ではありません。元のエクスポートと各候補を別々に保存します。レビュー用に提示された正確なファイルにダイジェストを割り当て、使用したツールのバージョンと変換をメモします。承認されたソースアートワークの唯一のコピーを上書きしないでください。
証明書に基づく展開の場合、資産を最終的なものとして扱う前に、候補者を発行者と調整します。 Google は、SVG と VMC または CMC 発行された PEM ファイルに埋め込まれます。したがって、独自に編集されたスタンドアロン イメージは、既存の証明書で検証された ID と一致すると想定すべきではありません。マークが変更された場合は、単に公開ファイルを置き換えて証明書が適切なままであると仮定するのではなく、発行者の指示を取得してください。 Google 証明書のワークフロー
1 人の候補者に関連付けられた合格ワークシートを使用する
以下は、完成した検証記録ではなく、オリジナルの提案されたワークシートです。各行に所有者、証拠の場所、日付、状態を与えます。証拠がない場合は、計画されたタスクをパスに変換するのではなく、不明を使用します。
- アイデンティティ: 承認されたアートワーク参照、法的所有者またはブランド所有者、対象ドメインおよびターゲット受信者。
- ファイル: 候補ファイル名、バイト数、ダイジェストとエクスポートまたは変換履歴。
- 構造: 宣言されたプロファイル、バージョン、タイトル、ルート属性、および禁止されたコンテンツの検出結果。
- 受信者のオーバーレイ: 正確なGmail寸法、単位、およびローカルで採用された適用可能な推奨事項。
- 視覚的なレビュー: 小さいサイズの認識、コントラスト、マージン、および提案された作物の比較。
- バリデータ: ツール名、バージョン、正確な入力ダイジェスト、完全な検出結果、および未解決の警告。
- 証明書の依存関係: 提案された発行者、受け入れられた資産バージョン、および一致する PEM 証拠のステータス。
- ホスティングハンドオフ: 提案された HTTPS URL、デプロイメント所有者、および未解決の公開検索証拠。
緑色のバリデーターバッジをワークシートの代わりとして扱わないでください。バリデーターは、実装するルールと受信したファイルのみを評価できます。警告やサポートされていないチェックを含む、完全な結果を保存します。その後、オプティマイザがバイトを変更した場合は、新しい候補を再度検証してレビューします。これにより、入力から分離されたスクリーンショットに依存するのではなく、受け入れステートメントが再現可能になります。
架空の例: 正しいロゴと間違ったエクスポート
Gmail に向かうパイロットのために灯台のマークを準備している架空のハーバー ランタンを考えてみましょう。そのデザイナーは、パーセント寸法と埋め込みビットマップを備えた視覚的に正しい SVG を提供します。この考えられたシナリオでは、エンジニアは最初に、baseProfile のみを変更することを提案します。代わりに、レビュー担当者は、構造的適合性とGmailのサイズ要件という 2 つの問題を分離します。どちらもプロファイル ラベルだけでは修復できません。
提案されている解決策は、承認されたベクター アートワークを取得し、それを簡略化し、適切な絶対寸法を設定し、完全なファイルを再チェックすることです。その後、ブランド所有者は、結果として得られる灯台の形状とその小さなサイズの読みやすさを承認する必要があります。証明書アプリケーションは、以前のエクスポートではなく、レビューされた候補を使用します。 Harbor Lantern に対してバリデータは実行されず、アセットも生成されず、メールボックスの結果も存在しません。この例は、証拠が次の決定をどのように導くべきかを示しています。
完了を誇張せずにハンドオフを終了する
有用なレビューの結論は、どの候補者が検査され、どの懸念が残っているかを正確に示します。たとえば、パブリック HTTPS フェッチと発行者の承認がまだ残っている間に構造レビューが完了する可能性があります。これらの状態を DMARC 準備状況と受信者の表示。 Google が文書化したGmailパスにはVMCまたはCMCと関連する PEM が必要なため、スタンドアロンの SVG レビューだけではGmailの導入準備を確立できません。 Google セットアップの前提条件
カタログの元の証拠要件は未解決のままです。候補資産、検証結果、およびコンテンツと証明書の証拠を含むパブリック HTTPS 取得は、ここでは提供または実行されていません。 SME による人間によるレビュー、現在の情報源の適用性、生産ルート、視覚的なアクセシビリティ、および所有者の公開も未解決のままです。この原稿は準備ガイドであり、参考文献や架空のワークシートが完成しているというだけの理由で出版準備完了に昇格させてはなりません。