さて、３番目に解決する問題は、２つ目の問題です。
順番がややこしくてすみません。
でも実際に制作してると終盤になってから序盤の問題が発覚するって結構よくあるんですよ。
みたいな枕にもならない話はさて置いて、内包パスの問題です。
「回」とか「国」みたいな、穴パスの中にさらに描画パスやら穴パスの存在する文字をどうするかという問題です。

ていうか忘れてましたがそもそも、穴パスがどの塗りパスの中にあるかを調べないといけません。こっちを先に片付けましょう。
ある座標が、ある領域の中に存在しているかどうか。
最初に思いついたものは、
「一番上の座標」とか「一番左の座標」とか調べてそれより小さい大きいで判断しようとというものです。即ち「パス内で一番左の頂点　＜　調べたい座標（穴パスの頂点どれか一個でよい）　＜　パス内で一番右の頂点」というのを上下も一緒に判定させれば、塗りの中にパスがあるか調べられるのではないかという考えです。しかし夢かなわず。こんな簡単なアルゴリズムでは「雨」も分解できないという事に気付いたのです。
で、結論。「頂点　図形　中　判定　javascript」でググって出てきた先人様の記事を参考に、面積を求める時みたいな座標の比較を行うやり方を実装しました。
私の見た記事はこちらです
https://www.nttpc.co.jp/technology/number_algorithm.html

で、です。
穴パスがどの塗りパスの中にあるのかはこれでわかりました。
じゃあ「回」はどうするんだってばよ！？って話に戻るわけです。
大きい方の塗りパスの範囲の中には疑いようもなく、小さい方の穴パスが含まれていますが、大きい方の穴パスの範囲内にあるわけですから、これは別々のグループに正しく分割されねばなりません。
穴パスの頂点がどの塗りパスの中にあるか調べた後にまた塗りパスの頂点がどの穴パスの中にあるかを調べるのでしょうか。もし回のループが10回くらいある文字があったら何回パスの頂点を調べるつもりでしょう。そんなループ回数があやふやなパスを調べまくったとしてどういうフラグを管理するというんでしょう。無理無理カタツムリ不可避です。

この問題を解決してくれたのは、皆さんお馴染、"面積"でした。有能過ぎる。
これ、穴パスの頂点が内包される塗りパスを「面積が小さい順」に調べて、最初に内包判定が出た瞬間次の穴パスの頂点の調査に移れば解決するのです。

説明しよう！（CV:山寺宏一）
一個前の記事で、最も面積の大きなパスは絶対に塗りパスだという話をしました。塗りパスは、穴パスより必ず大きいという話です。
これは別の言い方をすると、「穴パスは塗りパスより必ず小さい」のです。そして「穴パスに内包されている塗りパスは、内包する穴パスより必ず小さい」のです。何重に内包されていようともです。
これを内包構造の数だけ繰り返した先にあるものが、「穴パスを内包する塗りパスの中で、最も面積の小さい塗りパスが、穴パスが実際に穴を空ける塗りパスである」という法則です。
この説明でよく分からないという人は僕のTwitterのDMに訊きに来て。

ともかくこういう理屈で、内包の問題が解決しました。こうする事で、穴を正しく結合しつつ、分離したパスをそれぞれのグループに分ける理論が出来ました。
次の記事は、シェイプレイヤーのコンテンツを実際にどうやって分離してたかを、コードで書いてみます。