2023/03/08

	データとして矛盾がある？
	



	テストデータとして使用してきた，TToPA.exe の出力では処理に時間がかかりすぎる．

		内部的には，"文字列"のアウトラインを求めてそれをポリラインとして出力している．
		文字ごとに処理すれば少しは軽くなるのでは？

		::GetGlyphOutline 関係のコードを整理する必要がある．

2023/03/07

	少しは良くなったが，まだ完全ではない．データに矛盾がある場合か？
	

2023/03/06

	「穴」をうまく処理できていないもの．
	

		上の「穴」の処理順（穴を連結したポリライン）が逆（右側が先になっているため，クロスしている）．


		考え方としては，穴と結合する点（CS）と前後の点（CP,CN）と，穴の結合位置（CH）との位置関係で挿入位置を決定する．
			CP-CS-CN に対して，CH が右側になる様にして挿入する．

		他に，結合する点（CS）が複数にならない様に工夫できないか？
			これは簡単ではなさそう．
			次の候補を求める方法が簡単ではない思われる．

2023/03/03

	うまく処理できたもの．
	

	

2023/03/02

	「穴」をうまく検出できていない．
	

	データによるが，ネストしている場合に内側を検出してしまっている．

		三角形の中の，他の頂点の有無のチェック（2023/02/27）では不十分．
		交差している線分が存在する場合，その端点のチェックが必要か？


		hole_fnc.hxx Get_hole_connect で，交差する線が存在する場合に近い端点を考慮する様に変更．




	どこがおかしいのかは不明だが，穴をうまく検出できない．
	
	

2023/03/01

	先日までは，ハッチング領域の抽出など範囲の指定により穴との接続線を求めていた．

	今度は，複数のポリゴンの穴を順に処理する方法．
	


	ポリラインを指定して，1 つ目の穴との接続線を求めた所．