Re: gdiplus: GdipDrawString is not supposed to use the layout rectangle for clipping. Take 2.

[Vincent Povirk]

I tried making a testcase for this, and I'm consistently seeing that
native only draws text that lies inside the rectangle if a positive
width or height are given. If I specify StringFormatFlagsNoClip then I
see a slight difference. Without the flag, the last line of text is
clipped at the given height; with the flag, it is fully shown as long
as the top of that line lies inside the rectangle.

The test cases you linked appear to leave the width and height
uninitialized, and they do not specify StringFormatFlagsNoClip. My
guess is that they either default to 0 or undefined depending on how
the language works. Since we already handle the case where width and
height are 0, and an undefined width/height could work or not by
coincidence, I don't think your test cases show anything new. Due to
the way we (like native) calculate the text layout independent of
clipping, so that characters that lie entirely outside the rectangle
are not drawn, it's not even clear to me why this patch might have
helped. I think this needs more investigation.

gdiplus: GdipDrawString is not supposed to use the layout rectangle for clipping. Take 2.

[Dmitry Timoshkov]

Vincent Povirk <madewokherd(a)gmail.com> wrote:
> I tried making a testcase for this, and I'm consistently seeing that
> native only draws text that lies inside the rectangle if a positive
> width or height are given. If I specify StringFormatFlagsNoClip then I
> see a slight difference. Without the flag, the last line of text is
> clipped at the given height; with the flag, it is fully shown as long
> as the top of that line lies inside the rectangle.

In the test I was investigating I see that not initialized width is positive
while height is negative which makes text be clipped out in Wine, while under
Windows text is not clipped, and the flags say nothing about clipping.

masm32 site is about programming in assembler, and language/compiler shouldn't
have anything to do with the resulting binary code.

I'll test more about negative vs. positive rect extents.

-- 
Dmitry.