Vincent Povirk wrote:
> This should probably be handled somehow by gdip_format_string.
> DrawDriverString doesn't have access to the StringFormat, and there's
> a good change that the native implementation really does draw tabs as
> squares. Also, MeasureCharacterRanges and MeasureString will hav
This should probably be handled somehow by gdip_format_string.
DrawDriverString doesn't have access to the StringFormat, and there's
a good change that the native implementation really does draw tabs as
squares. Also, MeasureCharacterRanges and MeasureString will have to
account for tabstops.
gdip
> Since I have no tests for GdipMeasureCharacterRanges I don't want to break
> it inadvertently. If somebody proves that GdipMeasureCharacterRanges should
> be affected by extra padding as well, merging the code to gdip_format_string
> shouldn't be too hard.
Well, I'm saying you'll break it if you
Vincent Povirk wrote:
> >> >> Why can't this logic go in gdip_format_string?
> >> >
> >> > Because not all of its callers should be affected
> >> > (GdipMeasureCharacterRanges
> >> > is one of them).
> >>
> >> How not? If the padding is there when drawing the whole string, it
> >> affects the po
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=20983
Your paranoid android
>> >> Why can't this logic go in gdip_format_string?
>> >
>> > Because not all of its callers should be affected
>> > (GdipMeasureCharacterRanges
>> > is one of them).
>>
>> How not? If the padding is there when drawing the whole string, it
>> affects the positions of individual characters.
>
> Ma
Vincent Povirk wrote:
> You also removed the test for rotation and skewing, which are
> definitely NOT handled by gdi32.
I guess that this patch could be dropped then, other patches in the series
shouldn't be affected.
--
Dmitry.
Vincent Povirk wrote:
> >> Why can't this logic go in gdip_format_string?
> >
> > Because not all of its callers should be affected
> > (GdipMeasureCharacterRanges
> > is one of them).
>
> How not? If the padding is there when drawing the whole string, it
> affects the positions of individual c
>> Why can't this logic go in gdip_format_string?
>
> Because not all of its callers should be affected (GdipMeasureCharacterRanges
> is one of them).
How not? If the padding is there when drawing the whole string, it
affects the positions of individual characters.
Vincent Povirk wrote:
> Why can't this logic go in gdip_format_string?
Because not all of its callers should be affected (GdipMeasureCharacterRanges
is one of them).
--
Dmitry.
>> > Both StretchBlt and GdiAlphaBlend handle that case just fine.
>>
>> Only if the graphics interpolation mode happens to be nearest
>> neighbor, which isn't the default.
>
> Feel free to add a check for it, there is no need to penalize a common
> case without a reason.
You also removed the test
Vincent Povirk wrote:
> > Both StretchBlt and GdiAlphaBlend handle that case just fine.
>
> Only if the graphics interpolation mode happens to be nearest
> neighbor, which isn't the default.
Feel free to add a check for it, there is no need to penalize a common
case without a reason.
--
Dmitr
Why can't this logic go in gdip_format_string?
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=20977
Your paranoid android
> Both StretchBlt and GdiAlphaBlend handle that case just fine.
Only if the graphics interpolation mode happens to be nearest
neighbor, which isn't the default.
On Fri, Aug 17, 2012 at 1:37 AM, Alexandre Julliard wrote:
> There's no reason to move the data.
Thanks for review!
Will provide a better version soon.
--
Regards,
Qian Hong
-
Sent from Ubuntu
http://www.ubuntu.com/
Qian Hong writes:
> @@ -304,8 +307,19 @@ static LRESULT ME_StreamInText(ME_TextEditor *editor,
> DWORD dwFormat, ME_InStrea
>
> if (!(dwFormat & SF_UNICODE))
> {
> - /* FIXME? this is doomed to fail on true MBCS like UTF-8, luckily
> they're unlikely to be used as CP_ACP */
> -
On Thu, Aug 16, 2012 at 5:20 PM, Sergey Guralnik wrote:
>
> --
> Sergey
>
>
>
You can use simple assignment with st_null instead of that:
+memset(&nmsc.stSelEnd, 0, sizeof nmsc.stSelEnd);
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=20934
Your paranoid android
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=20933
Your paranoid android
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=20934
Your paranoid android
On 2012-08-16 16:28, Marvin wrote:
=== WNT4WSSP6 (32 bit monthcal) ===
monthcal.c:1258: Test failed: monthcal hit test: the msg 0x000f was
expected, but got msg 0x1001 instead
This is unrelated to my patch.
--
Sergey
Alexandre Julliard wrote:
> > To clarify things a bit: current code uses empty font face name, and GDI
> > uses "System" font in that case (regardless of requested FIXED_PITCH), which
> > is absolutely not readable. ANSI_FIXED_FONT should use built-in "Courier",
> > which is actually a FIXED_PITC
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=20929
Your paranoid android
On Thu, Aug 16, 2012 at 4:55 PM, Alexandre Julliard wrote:
>
> This shouldn't be necessary, you can use a simple printf. Functions
> should only be added to test.h if there's a clear need across a wide
> range of tests.
Thanks for review!
Will provide an updated patch set soon.
--
Regards,
Qia
Dmitry Timoshkov writes:
> Dmitry Timoshkov wrote:
>
>> static void set_fixed_font( HWND dlg, UINT id )
>> {
>> -HFONT hfont = (HFONT)SendDlgItemMessageW( dlg, id, WM_GETFONT, 0, 0);
>> -LOGFONTW font;
>> +HFONT hfont;
>>
>> -GetObjectW(hfont, sizeof(LOGFONTW), &font);
>> -
Perhaps not, but I'll be the first to admit that I know very little about
wine internals; this seemed to return the correct result in the case that I
tested it.
On Thu, Aug 16, 2012 at 11:39 AM, Alexandre Julliard wrote:
> Michael Blumenkrantz writes:
>
> > @@ -656,8 +656,8 @@ int WINAPI GetCale
Michael Blumenkrantz writes:
> @@ -656,8 +656,8 @@ int WINAPI GetCalendarInfoW(LCID Locale, CALID Calendar,
> CALTYPE CalType,
> * for the CALTYPES not requiring GetLocaleInfoA */
> switch (CalType &
> ~(CAL_NOUSEROVERRIDE|CAL_RETURN_NUMBER|CAL_USE_CP_ACP)) {
> case CAL_ICALINT
28 matches
Mail list logo
