Hi Mattias,

Not sure if I follow your reasoning. In Windows, the ExtTextOut Dx param means 
use these character widths (in array pointed to by Dx) instead of the default 
character widths. Since Dx is otherwise ignored in the Carbon widgetset you're 
just using the Dx param as a switch. If Dx is nil, it means use fractional char 
widths; if non-nil it means don't use fractional char widths. Neither of these 
is consistent with how Dx is supposed to function.

Who's to say what normal character spacing should be? Tobias might suggest that 
it should be as close as possible to the way OS X currently renders buttons. I 
might suggest that it should be as close as possible to the way Windows renders 
text (as in "Write once compile anywhere").

There's probably quite a lot going on here. Tomas is actually passing a total 
of 8 options, including options to turn off kerning, to use rounded text 
metrics instead of fractional, and others, as well as disabling fractional 
spacing in the rendering of the line.

Thanks.

-Phil   


-----Original Message-----
From: Mattias Gaertner [mailto:[EMAIL PROTECTED]
Sent: Sat 11/3/2007 6:05 PM
To: [email protected]
Subject: Re: [lazarus] Carbon Widgetset: character spacing problems
 
On Sat, 3 Nov 2007 18:21:49 -0400
"Hess, Philip J" <[EMAIL PROTECTED]> wrote:

> Tobias,
> 
> I believe I can live with the patch by doing some conditional
> compiling on my end (note this is not needed with other widgetsets
> but will with Carbon if the patch is made). However, I'll need two
> additional changes. In TCarbonDeviceContext.GetTextExtentPoint and
> TCarbonDeviceContext.GetTextMetrics, please pass True in
> BeginTextRender instead of False and test to see if that has any
> undesirable consequences. I recompiled the IDE with this changes as
> well as my TLabel test app and I don't see any problems on this end.
> 
> ExtTextOut and GetTextExtentPoint are often used hand in hand, so
> disabling fractional spacing with non-nil DX means that it should
> also be disabled in GetTextExtentPoint. However, there's no way to
> pass this information to GetTextExtentPoint the way there is with
> ExtTextOut.

Providing a DX to ExtTextOut means overriding any normal widths.
That's why GetTextExtentPoint and GetTextExtentExPoint have no DX
parameter.
In other words: GetTextExtentPoint makes only sense if DX=nil in
ExtTextOut.


Mattias

_________________________________________________________________
     To unsubscribe: mail [EMAIL PROTECTED] with
                "unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

<<winmail.dat>>

Reply via email to