Thanks for the quick reply. Allow me to provide some more detail - I wanted
to know someone was interested first!
As an example, given an Arabic string, each character it contains could be
rendered in one of four forms depending on its context within the string.
GDI+ chooses the correct forms to display, but TextFromFont just renders
exactly what it's given. I understand that given the nature of Direct3D that
every clock cycle is vital and TextFromFont can't afford to do much
additional processing, but there's no easy way that I have found to
construct a string with the correct forms already in place. This is why
we've had to resort to using a 3rd party library...
As you say, the text ordering problem is fairly easily rectified. It seems
we need to reverse the right-to-left chunks within the string. I've actually
used GDI+'s MeasureCharacterRanges() to get the positions of all of the
characters and rearranged the characters in the string I pass to
In short, this is our workaround:
1) Given a Unicode string, replace the characters with their correct forms
for their context.
2) Sort the characters in to their left-to-right order.
3) Pass the result to TextFromFont().
Sounds easy doesn't it? Unfortunately, since Windows doesn't seem to expose
the logic we need and TextFromFont doesn't use it, (1) requires us to
redistribute a 9MB 3rd party library (there are a lot of tables!), and (2)
means we have to call into GDI+ to lay the string out correctly! The other
thing that worries me slightly is that we may get different results to the
text the user input into their textbox, although so far the ICU library
seems to do a pretty good job.
I'm sure you can see how frustrating this is, given that it's one line of
code for GDI+! Not to mention the layout/flow options it also provides... ;)
Still, hats off to the whole DirectX team - this is our first foray into
DirectX and we've found it remarkably easy to get fast, good looking results
(for our Western customers, at least ;).
Principal Software Engineer
Aston Broadcast Systems Ltd. (http://www.aston.tv)
Disclaimer: I really don't have a clue what I'm on about.
> >We've got some code which uses Managed DirectX 9's Mesh.TextFromFont()
> >method to produce meshes containing a given string. However, it produces
> >unsatisfactory results for anything other than simple, left-to-right
> What do you mean by "unsatisfactory results"? When creating text as a
> mesh, it isn't really displayed like the way that DrawText would do
> it. They just use the character widths to position the characters in
> space and tesselate the glyph outlines to produce a mesh.
> >Allow me to compare it to the similar functions in GDI+... With GDI+, you
> >can supply a Unicode string (typed into a text box using an Arabic IME,
> >say), and the characters are converted into their correct presentation
> >before being displayed. It also correctly positions right-to-left chunks
> >within a left-to-right string and vice-versa. In short, it looks how it
> I haven't tried creating a mesh from a string that should be rendered
> right-to-left, but if the resulting mesh isn't displayed properly then
> I would try reversing the string. The resulting mesh definately
> handles unicode characters properly as I was able to get Chinese
> glyphs rendered as a mesh properly.
> Another alternative would be to use GDI to render the text into a
> bitmap and then extrude the non-background pixels in the bitmap to
> create a mesh, but this would be blockier than what D3DX does for