Vincent Povirk madewokherd@gmail.com wrote:
These APIs use different logic for adding extra space, so at the moment I don't see how gdip_format_string() can be used to do this in one place, but if somebody has an idea how to do that - patches are welcome.
That is highly unlikely, particularly given that MeasureCharacterRanges is the accepted practice for highlighting parts of a string.
For instance accoding to the tests MeasureCharacterRanges adds extra space only to X, while GdipMeasureString and GdipDrawString also add extra space to Height and Width of the bounding rectangle.
You should make sure you do your tests so the size in pixels is the em size of the font, or at least at a consistent size between them, as native may cut into the padding if hinting makes the characters proportionally larger (this is the point of having the padding, but for the record I think it is behavior that we shouldn't try to duplicate).
That's an implementation detail, and my patch has nothing to do with that.
Do you have a visual test program for this? I'd like to see something that draws a string overlayed with the measurements, to confirm that the functions are not consistent on Windows (or, if they are, confirm that they are consistent with your patch). If not, I'll write one and send you the source code.
I have an application which makes a havy use of all of this.
- /* FIXME: GenericTypographic format prevents extra margins */
Since no margins is the current behavior, won't that cause a regression? It should be fairly easy to include that exception.
Then again, I think I've heard reports that GenericTypographic doesn't work.
GenericTypographic does work in my tests, but since it's currently completely ignored anyway I decided to leave it alone. Once these patches are in I'll add support for this case later.