クライアント側の JavaScript を使用して、SVG テキスト要素の衝突検出を実装しようとしています。ヒット テストでは、テキストのグリフが別のテキスト要素のグリフとオーバーラップしているかどうかを確認する必要があります。getBBoxとgetExtentOfCharは正確ではないので、カスタム ソリューションが必要です。
私の最初のアプローチは、要素の各座標/ピクセルの色を取得し、手動でヒット テストを行うことでしたが、座標の色を取得できないため、これは機能しません。ピクセルの色を取得するには、追加のキャンバスが必要になります->ひどい回避策。
現在、ヒット テストのために、テキストまたはグリフをポリゴンに変換することを考えています。出来ますか？または、グリフベースのヒットテストの別のアプローチはありますか?
よろしくお願いします
あなたは本当に苦痛とクロスブラウザの問題の世界に入っています。結局、フォントのカスタムパスレンダリングを実行して、テキストの全長を信頼でき、一貫性のあるものにするだけでした。グリフヒットについても考えたくありません。
たとえば、Firefox（少なくとも3.6）とiircの一部のバージョンのオペラでは、スケーリング時に丸め誤差が発生するため、テキストを保持している親要素をスケーリングし、そのスケールの逆数でテキストをスケーリングすると、文字が-間隔は、スケールなしと比較してわずかに異なります。（各文字は偶数などで始まる必要があるため、アップスケールとダウンスケールの両方に10000のように掛けることで問題を解決できますが、それは別の話です）
残念ながら、テキストと比較してパスを使用することによるパフォーマンスへの影響は非常に顕著です。キャンバスがアニメーション化されたパンまたはズームの形式を実行する場合は、アニメーション中に純粋なテキスト要素に切り替え、静的になったら、正確さのためにパスレンダリングをオンにする必要があります。
幸い、svg-fontsをパスに変換するのは非常に簡単です。プレーンテキストであり、path-elementとまったく同じ形式を使用しています。（ただし、font-embedding-licensesに注意してください！ユーザーシステムのフォントは使用できないため、ファイルサイズにも注意してください）。
ピクセルベースのヒットテストに関しては、HTML5 Canvasに切り替えると、これが可能になります。いくつかのプロジェクトは、SVGからCanvasへの簡単な移行を提供します（例：fabric.js）。こちらの比較表をご覧ください。
ポリゴンベースのアプローチに関しては–可能ですが、困難です。いくつかのツール（たとえば、Inkscapeのtext-to-path）を使用して、テキストまたはグリフをポリゴン（パス）に変換できます。そして、計算があります。テキストの一般的な解決策を作成するには、多くの作業が必要になります。ただし、テキストが変更されない場合は、パスを使用してテキストを手動で描画することは、迅速で汚い解決策になる可能性があります。