賢い印刷ＡＰＩへの対応法は？？？

質問

A.....～.....a東京都B,,,,,～,,,,,b
という文字列を印刷した場合、文字列途中にある東京都の印刷位置を知りたいと思います
印刷した文字列が１行である場合には
A～ａまでの文字列をGetTextExtentPoint32に入れて印刷長を調べ、印刷基点であるAの位置に加算すれば東京都の位置が判明します

ここまでは分かりました
ところが文字列をクリッピング領域に出力し、文字列が複数行に渡った際の算出法が分かりません

GetTextExtentPoint32からもらった印刷長を
クリッピング領域の横幅値で除算して
商が行数（Ｙ位置）
余りが文字のＸ位置
と考えてテストしてみました
結果はＯＫの場合もありますがＮＧも多々あります

ＮＧの現象は次のようにして発生します
印刷ＡＰＩが賢くて見た目が良いように整形してしまいます

A.....～...
..a ←ここに印刷ＡＰＩが改行を入れてしまう
東京都B,,,,
,,,,～,,,,,b

ａの後ろにはまだ余裕があるのですが、東京都の直前で改行してしまうのです
見た目は向上しましたが私の計算式の想定外です
印刷ＡＰＩの美的判断を予測出来ません
どのように対応すれば良いでしょうか？
ヒントだけでもご指導頂ければ幸いです

追伸】
これまで数回これに関連する質問をさせて頂き、皆様の温かいご支援で何とかここまで到達出来ました
誠にありがとうございました
改めて御礼申し上げます

回答No.2

m-take0220 · ベストアンサー

GetTextExtentExPointを使って、指定された幅だとどの位置で改行されるかを判断するしかないのでは?

お礼

重ね重ねのご指導ありがとうございます

難しいこととは分かっていましたがプログラムで自動的に判別するのは困難なようです

ありがとうございました

回答No.1

m-take0220

その「印刷API」の正式名称は明かせないのですか?
何を使っているかによって、回答が変わってくるとは思いませんか?

補足

クリップ領域指定をパラメータに持ち、しかも複数行機能を有する印刷ＡＰＩの全てです

すなわち
(1)　DrawText
(2)　DrawTextEx
の両者です

なおExtTextOutはクリップ領域指定を持ちますが複数行機能はありませんので除外します

(1)、(2)ともクリップ領域と複数行の関係検証結果では同一でした