<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">

  <title></title>

</head>

<body dir="ltr" bgcolor="#ffffff" text="#000000">

Alexandre Julliard wrote:

<blockquote cite="mid:87tyqav8b2.fsf@wine.dyndns.org" type="cite">

  <pre wrap="">

Which of course demonstrates that gdi32 calls usp10 on native too. Maybe

it does it indirectly through lpk.dll, but the end result is the same,

you have a dependency on usp10.

  </pre>

</blockquote>

I know I'm coming a bit late into the discussion, but just for the

record, this is how Windows does it (as of Windows 2000):<br>

<br>

<ul>

  <li>GDI has a soft dependency on LPK.DLL. It tries to load it using

LoadLibrary.</li>

  <li>If it succeeds, and if there are no breakout flags, each call to

ExtTextOut is redirected to the LPK version of that same call</li>

  <li>LPK links with uniscribe for the actual BiDi processing, and also

with GDI for the actual rendering of the result. Yes, this means a

circular dependency.<br>

  </li>

  <li>The breakout flags are ETO_IGNORELANGUAGE and ETO_GLYPH_INDEX. If

these are passed, GDI handles the request itself, without forwarding it

to LPK. This prevents the infinite recursion that might, otherwise,

happen.</li>

</ul>

I believe the reason for this twisted design is twofold. First, in

Windows 2000, CTL (complex text layout) was an optional component, to

be installed by a checkbox in the regional settings dialog. This meant

that the entire LPK dll could just be dropped in, along with some

fonts, and the system would start supporting BiDi. The second reason is

because BiDi is a rather multi-layered process. With BiDi, support for

multi line rendering (as done by DrawText in User32) requires some

fairly complex processing before the text could be passed off to

ExtTextOut for actual rendering. This way, all the BiDi code could be

placed in one place.<br>

<br>

Another reason, I believe, for this separation is that pre-Windows 2000

(and more importantly, pre-uniscribe) Windows still had BiDi code,

which was scattered all over the place, and which became obsolete (for

one example - GetCharacterPlacement, which supposedly does BiDi, has no

mechanism to choose the paragraph direction, without which no BiDi

processing makes sense. The MSDN docs even explicitly state it is

obsolete).<br>

<br>

I believe the best route forward is to use an LPK <b>like</b> DLL. Not

LPK itself, as that would require of us to reverse engineer a whole set

of APIs that no one but us even call, but another DLL, injected into

the dependency order at the same location, carrying a similar

functionality. I would suggest "winelpk.dll" as the name, but that is,

of course, entirely open.<br>

<br>

Shachar<br>

<br>

<pre class="moz-signature" cols="72">-- 

Shachar Shemesh

Lingnu Open Source Consulting Ltd.

<a class="moz-txt-link-freetext" href="http://www.lingnu.com">http://www.lingnu.com</a>

</pre>

</body>

</html>