Re: bidi in win32graphics

From: msevior@physics.unimelb.edu.au
Date: Sat Sep 20 2003 - 09:40:19 EDT

  • Next message: Francis James Franklin: "commit: abi (BOTH): add new XHTML template instruction"

    > On 19 Sep 2003 at 19:02, Martin Sevior wrote:
    >
    >> No this should not be called UNLESS there are no
    >> pCharAdvances
    >> defined.
    >
    > No, Martin. If you look at the source, you will see that the
    > ExtTextOut() _always_ takes the pCharAdvances as a parameter (including
    > the
    > simple_exttextout branch). The only difference between the two
    > branches is that in the simple_exttextout scenario we pass to the
    > ExtTextOut the unicode string, while in the other branch we pass it
    > glyph indices (i.e., the indexes into the actual glyph table in the font
    > file); I have explained the reasons for this in an earlier posting.
    >

    Oh! Sorry I don't know I thought pCharAdvances was not in the
    simple_ecttextout branch.

    Now I'm totally puzzled as to how Jordi is getting his text over-run
    problems.

    > The problem with the code as it stands is that if we set
    > gcpResult.lpDx = pCharAdvances before calling
    > GetCharacterPlacement(), the call overwrites the advances we
    > calculated in the layout classes with advances calculated by the
    > system. That is why gcpResult.lpDx must be set to NULL, so
    > that the subsequent call to ExtTextOut would use our advances,
    > not the one's calculated by the system.
    >

    Oh! I get this. And in fact when I tested your suggestion on my WinME
    build it did appear to work well until the zoom was around 60.

    Maybe Windows developers could build a matrix of people and Windows OS's
    who see and do not see Jordi's overwriting bug with
    gcpResult.lpDx = NULL and
    gcpResult.lpDx = pCharAdvances

    Martin

    > Tomas

    This archive was generated by hypermail 2.1.4 : Sat Sep 20 2003 - 09:58:55 EDT