Re: gdi32: use usp10 to optionally generate glyphs for bidi strings

[Dmitry Timoshkov]

Aric Stewart  wrote:
> allows us to be able to make use of the mirroring code and eventually 
> the shaping code when it is in place.

This should be done the other way around. gdi32 should not depend on
a high level dll (that creates circular dependencies), gdi32 in Windows
doesn't use usp10 either.

gdi32: use usp10 to optionally generate glyphs for bidi strings

[Aric Stewart]

Hi Dmitry,

I know this is not official MSDN documentation but this appears to 
disagree with you. http://www.catch22.net/tuts/neatpad/11

It also makes sense to have all the complex script processing logic in 
one place instead of spreading it out and duplicating it.

Why do you say that Windows gdi32 does not use usp10?  I do not see a 
direct dependency but I have not traced inside to see if it is doing 
LoadProcAddress or the like.

-aric

Dmitry Timoshkov wrote:
> Aric Stewart  wrote:
> > allows us to be able to make use of the mirroring code and eventually 
> > the shaping code when it is in place.
>
> This should be done the other way around. gdi32 should not depend on
> a high level dll (that creates circular dependencies), gdi32 in Windows
> doesn't use usp10 either.

gdi32: use usp10 to optionally generate glyphs for bidi strings

[Dmitry Timoshkov]

Aric Stewart  wrote:
> I know this is not official MSDN documentation but this appears to 
> disagree with you. http://www.catch22.net/tuts/neatpad/11
>
> It also makes sense to have all the complex script processing logic in 
> one place instead of spreading it out and duplicating it.

Bidi and reordering were supported by gdi32 before Uniscribe has been
introduced.

Accridong to http://msdn.microsoft.com/en-us/goglobal/bb688137.aspx
uniscribe is used by lpk.dll (language packs): "ExtTextOut can be used
to lay out multilingual Unicode text including complex scripts. There is
no need for you to do anything other than call ExtTextOut; it handles
everything for you."
> Why do you say that Windows gdi32 does not use usp10?  I do not see a 
> direct dependency but I have not traced inside to see if it is doing 
> LoadProcAddress or the like.

Inspecting strings in gdi32.dll should be enough.

gdi32: use usp10 to optionally generate glyphs for bidi strings

[Aric Stewart]

ok, so the LPK calls uniscribe.  Do you feel we should implement the LPK 
style of interface to gdi32?  It seems needlessly cumbersome to me. The 
LPK.dll interfaces seem to be undocumented but based on names should not 
be to difficult to figure out.

-aric

Dmitry Timoshkov wrote:
> Aric Stewart  wrote:
> > I know this is not official MSDN documentation but this appears to 
> > disagree with you. http://www.catch22.net/tuts/neatpad/11
> >
> > It also makes sense to have all the complex script processing logic in 
> > one place instead of spreading it out and duplicating it.
>
> Bidi and reordering were supported by gdi32 before Uniscribe has been
> introduced.
>
> Accridong to http://msdn.microsoft.com/en-us/goglobal/bb688137.aspx
> uniscribe is used by lpk.dll (language packs): "ExtTextOut can be used
> to lay out multilingual Unicode text including complex scripts. There is
> no need for you to do anything other than call ExtTextOut; it handles
> everything for you."
> > Why do you say that Windows gdi32 does not use usp10?  I do not see a 
> > direct dependency but I have not traced inside to see if it is doing 
> > LoadProcAddress or the like.
>
> Inspecting strings in gdi32.dll should be enough.

gdi32: use usp10 to optionally generate glyphs for bidi strings

[Alexandre Julliard]

Dmitry Timoshkov  writes:
> Aric Stewart  wrote:
> > I know this is not official MSDN documentation but this appears to 
> > disagree with you. http://www.catch22.net/tuts/neatpad/11
> >
> > It also makes sense to have all the complex script processing logic in 
> > one place instead of spreading it out and duplicating it.
>
> Bidi and reordering were supported by gdi32 before Uniscribe has been
> introduced.
>
> Accridong to http://msdn.microsoft.com/en-us/goglobal/bb688137.aspx
> uniscribe is used by lpk.dll (language packs): "ExtTextOut can be used
> to lay out multilingual Unicode text including complex scripts. There is
> no need for you to do anything other than call ExtTextOut; it handles
> everything for you."

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.

gdi32: use usp10 to optionally generate glyphs for bidi strings

[Shachar Shemesh]

Alexandre Julliard wrote:
> 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.

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):

* GDI has a soft dependency on LPK.DLL. It tries to load it using
      LoadLibrary.
    * If it succeeds, and if there are no breakout flags, each call to
      ExtTextOut is redirected to the LPK version of that same call
    * 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.
    * 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.

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.

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).

I believe the best route forward is to use an LPK *like* 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.

Shachar