Vincent Povirk <madewokh...@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. -- Dmitry.