August 2012 - Wine-Devel - list.winehq.org

Re: [3/3] gdiplus: Make GdipMeasureCharacterRanges/GdipMeasureString/GdipDrawString add extra space around the text.

by Vincent Povirk

> IMHO the whole "resolution-independent" term in that article is a pure > speculation to justify inventing and adding new shiny technology to Windows. s/n/tt

Aug. 24, 2012

Re: [3/3] gdiplus: Make GdipMeasureCharacterRanges/GdipMeasureString/GdipDrawString add extra space around the text.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > >> I don't think we should make MeasureString/DrawString > >> resolution-independent because that also makes native's text > >> incredibly ugly, and would greatly increase the complexity of > >> gdip_format_string. > > > > That sounds like a pure guess, not related to my patches. > > Nope, I read about it here: http://support.microsoft.com/kb/307208 > > And since it's the rationale for the padding and the reason we can't > duplicate native's measurements exactly, I think it's relevant to the > discussion. IMHO the whole "resolution-independent" term in that article is a pure speculation to justify inventing and adding new shiny technology to Windows. GDI32 does all its rendering in "resolution-independent" manner just fine for a very long time already. -- Dmitry.

Aug. 24, 2012

Re: [3/3] gdiplus: Make GdipMeasureCharacterRanges/GdipMeasureString/GdipDrawString add extra space around the text.

by Vincent Povirk

>> I don't think we should make MeasureString/DrawString >> resolution-independent because that also makes native's text >> incredibly ugly, and would greatly increase the complexity of >> gdip_format_string. > > That sounds like a pure guess, not related to my patches. Nope, I read about it here: http://support.microsoft.com/kb/307208 And since it's the rationale for the padding and the reason we can't duplicate native's measurements exactly, I think it's relevant to the discussion.

Aug. 24, 2012

Re: [3/3] gdiplus: Make GdipMeasureCharacterRanges/GdipMeasureString/GdipDrawString add extra space around the text.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > > 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. > > That doesn't sound inconsistent to me, it's just that those functions > are measuring different things. CharacterRanges tells you where the > individual characters are (and is resolution-dependent as I understand > it), while MeasureString/DrawString only give information about full > lines and are resolution-independent (they may have to cut into the > padding depending on the hinting at that resolution, but users of > these functions can ignore that and assume the entire line will scale > to any resolution). > > Probably the callback just needs another argument specifying where the > first character is. (For tabs we may need a position for subsequent > characters as well, or multiple callbacks for a single line.) That's the whole reason of my comment: "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." Right now I just want to implement correct behaviour to make the tests pass, nothing more. Any optimizations, simplifications, or even redesign could be done later. > I don't think we should make MeasureString/DrawString > resolution-independent because that also makes native's text > incredibly ugly, and would greatly increase the complexity of > gdip_format_string. That sounds like a pure guess, not related to my patches. -- Dmitry.

Aug. 24, 2012

Re: [3/3] gdiplus: Make GdipMeasureCharacterRanges/GdipMeasureString/GdipDrawString add extra space around the text.

by Vincent Povirk

> 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. That doesn't sound inconsistent to me, it's just that those functions are measuring different things. CharacterRanges tells you where the individual characters are (and is resolution-dependent as I understand it), while MeasureString/DrawString only give information about full lines and are resolution-independent (they may have to cut into the padding depending on the hinting at that resolution, but users of these functions can ignore that and assume the entire line will scale to any resolution). Probably the callback just needs another argument specifying where the first character is. (For tabs we may need a position for subsequent characters as well, or multiple callbacks for a single line.) I don't think we should make MeasureString/DrawString resolution-independent because that also makes native's text incredibly ugly, and would greatly increase the complexity of gdip_format_string.

Aug. 24, 2012

Re: [3/3] gdiplus: Make GdipMeasureCharacterRanges/GdipMeasureString/GdipDrawString add extra space around the text.

by Dmitry Timoshkov

Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Vincent Povirk <madewokherd(a)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. GdipMeasureString and GdipDrawString add extra space to Y too. -- Dmitry.

Aug. 24, 2012

Re: [3/3] gdiplus: Make GdipMeasureCharacterRanges/GdipMeasureString/GdipDrawString add extra space around the text.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)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.

Aug. 24, 2012

Re: [3/3] gdiplus: Make GdipMeasureCharacterRanges/GdipMeasureString/GdipDrawString add extra space around the text.

by Vincent Povirk

> 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. 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). 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. + /* 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.

Aug. 24, 2012

Re: configure --with-osmesa fails to link

by Peter Urbanec

On 24/08/12 18:17, Alexandre Julliard wrote: > libOSMesa should be built without shared-glapi, we can't use it > otherwise. I rebuilt media-libs/mesa-8.1_rc1_pre20120814 without shared-glapi, but even then I get link errors during configure. Seems to be a missing dependency on C++ runtime. I've had to resort to the attached hack to get configure for wine64 to complete on Gentoo x64. I'm not submitting this as a patch, because I'm not anywhere near sure whether this is the right way of actually solving the underlying issue. Unfortunately, I can't configure wine32, even with this hack, because the 32-bit packages for 64-bit Gentoo are supplied as pre-compiled binaries and osmesa is disabled in those. Can I build wine64 --with-osmesa and WoW wine32 --without-mesa and still expect things to work? Best regards, Peter Urbanec

Aug. 24, 2012

Re: quartz/tests: Use proper method macros

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=21196 Your paranoid android. === WNT4WSSP6 (32 bit memallocator) === memallocator.c:34: Test failed: Unable to create memory allocator 80040154

Aug. 24, 2012