Hi Dom,
> I was looking at your last commit to
> GR_Win32Graphics::glyphBox() and had some questions
> about it. If you could please answer them using small
> words, I'd appreciate it. Thanks.
Sure.
>
> 1) In the Win9x case, why are you "converting" a
> "ucs4" value into a glyph index?
> 1.a) Isn't the input to the method already a glyph
> index?
> 1.a.i) If not, why isn't it?
My understanding is that the input to the glyphBox() method is ucs4
value of the character. This parameter is not documented in the abi
sources, but it is typed as UT_UCS4Char, and we currently have no XP api
for translating ucs4 values to glyph indices, so I assumed the typing is
correct. It is also treated as a ucs4 character in the Unix version of
the function, which was the starting point for implementing the win32
version.
> 1.a.ii) If not, why does the method have the word
> "glyph" in its name?
I assume because it is asking for the glyph-box dimensions of the given
character (it makes sense to speak of a glyph in the context of this
function, it is GR_Font:: method).
> 1.b) If it's not a glyph index, why don't you have to
> perform similar conversion to a glyph index for the
> WinNT case?
Because the WinNT provides GetGlyphOutlineW() function which can be fed
ucs2 value. In contrast, on win9x we only get GetGlyphOutlineA()
function which can only handle characters from the current ANSI page; in
order for this function to handle characters outside of the current ANSI
page, we have to feed it the actual index of the character in the font.
We calculate this index using the GetCharacterPlacement() method.
> 2) What does your most recent commit solve that didn't
> work before?
The previous code for w9x treated the UT_UCS4Char g as a glyph index.
> 3) In light of my previous questions, why have two
> codepaths (NT/9x) instead of one, assuming that both
> work equally well? I don't buy the argument that the
> WinNT code is simpler to read, IF we're also going to
> keep the 9x code around. All it leads to is less
> testing for the 9x codepath and ultimately more code
> to sift through (albeit only 3 lines more).
As the code is we could just have the win9x branch only, making use of
the GetGlyphOutlineA() function (I assume that this function is
available on the different NT flavours). However, we have been talking
for a while about a move toward unicode-only build of AW (requiring
unicows on w9x), which I would like to be done for 2.6. When that
happens the 9x branch will go completely, and the NT branch becomes the
only branch; it makes sense for me to have working and tested NT code
for all new win32 code we write (with no -A functions in it), but if you
prefer, I can #if 0 the NT branch in this function.
I hope this clarifies things.
Tomas
___________________________________________________________
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
Received on Wed Sep 14 09:09:50 2005
This archive was generated by hypermail 2.1.8 : Wed Sep 14 2005 - 09:09:50 CEST