TextFromFont and complex scripts

TextFromFont and complex scripts

Post by Graeme Foste » Fri, 30 May 2003 22:55:43



Hi,

Be warned - this may look like a Managed DirectX question but it isn't!

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

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 forms
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
should.

With Direct3D, the string is just displayed as it is. The processing that
GDI+ does is missing. This would be fine, however I can't find a reasonable
way to pre-process the string. Is there an easy way to convert the Unicode
string into another string that Direct3D will correctly convert to a mesh?
We looked at Uniscribe, but that only gives you access to the glyphs (as
opposed to the presentation form characters Unicode which TextFromFont
needs). We have had some success using ICU
(http://oss.software.ibm.com/icu/), but this seems like a lot of effort to
include just because we can't have Direct3D reuse the same OS stuff that
GDI+ uses...

In the future, I'd like to see the same options in the Direct3D functions as
in the GDI+ ones. Then the problem just goes away (at least at my end) :)

Cheers,
G.
--

Principal Software Engineer
Aston Broadcast Systems Ltd. (http://www.aston.tv)
Disclaimer: I really don't have a clue what I'm on about.

 
 
 

TextFromFont and complex scripts

Post by Rich [Microsoft Direct3D MV » Sat, 31 May 2003 09:13:48


[Please do not mail me a copy of your followup]



Quote:>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 text.

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.

Quote:>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 forms
>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
>should.

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
you.
--
    "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ:
              <http://www.xmission.com/~legalize/book/>

 
 
 

TextFromFont and complex scripts

Post by Graeme Foste » Sat, 31 May 2003 17:34:33


Hi Rich,

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

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

Cheers,
G.
--
Graeme Foster
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
text.

> 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
forms
> >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
> >should.

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

 
 
 

TextFromFont and complex scripts

Post by Rich [Microsoft Direct3D MV » Sat, 31 May 2003 23:36:47


[Please do not mail me a copy of your followup]



Quote:>Thanks for the quick reply. Allow me to provide some more detail - I wanted
>to know someone was interested first!

I think the DirectX team would be interested in hearing about your
experiences with Arabic languages and D3DXCreateText.  Have you sent a

that if you haven't done it yet.

I think the bottom line is that while GDI (and GDI+) handles the
presentation issues when rendering text into a DC, D3DXCreateText
doesn't use GDI to do "rendering" of the text -- it only uses GDI to
get the glyph outlines and inspects the font metrics to position the
extruded glyph outlines in space.  For that reason, it may never work
properly for the fully general case of all Unicode characters without
tons of work -- basically re-implementing everything that GDI does.

There may be an intermediate stage of using GDI to position the
characters and then using this information to generate the resulting
extruded glyphs.  I'm not an expert in this area, so I can't suggest
anything specific to help out in this case.

Have you tried rendering the text at a large scale into a monochrome
bitmap and extruding the result yourself?  That might provide
something of reasonable quality for a minimal amount of effort.  Since
you'd be using GDI{,+} to render the text into the bitmap, you
wouldn't need to know anything about the characteristics of Arabic
language characters.
--
    "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ:
              <http://www.xmission.com/~legalize/book/>

 
 
 

TextFromFont and complex scripts

Post by Graeme Foste » Tue, 03 Jun 2003 16:59:32




> I think the DirectX team would be interested in hearing about your
> experiences with Arabic languages and D3DXCreateText.  Have you sent a

> that if you haven't done it yet.

OK, I'll do that.

Quote:> I think the bottom line is that while GDI (and GDI+) handles the
> presentation issues when rendering text into a DC, D3DXCreateText
> doesn't use GDI to do "rendering" of the text -- it only uses GDI to
> get the glyph outlines and inspects the font metrics to position the
> extruded glyph outlines in space.  For that reason, it may never work
> properly for the fully general case of all Unicode characters without
> tons of work -- basically re-implementing everything that GDI does.

> There may be an intermediate stage of using GDI to position the
> characters and then using this information to generate the resulting
> extruded glyphs.  I'm not an expert in this area, so I can't suggest
> anything specific to help out in this case.

That's excatly what we had been doing - using GDI to work out the correct
order for the characters, then using D3DXCreateText to create meshes for the
individual characters and positioning them as appropriate. It's only when we
realised we couldn't actually work out which character codes we needed to
give to D3DXCreateText that we found we had a lot more work to do.

Quote:> Have you tried rendering the text at a large scale into a monochrome
> bitmap and extruding the result yourself?  That might provide
> something of reasonable quality for a minimal amount of effort.  Since
> you'd be using GDI{,+} to render the text into the bitmap, you
> wouldn't need to know anything about the characteristics of Arabic
> language characters.

Quality is extremely important in our application, so that was ruled out
fairly quickly :)

Thanks for your help, it's much appreciated.

G.
--
Graeme Foster
Principal Software Engineer
Aston Broadcast Systems Ltd. (http://www.aston.tv)
Disclaimer: I really don't have a clue what I'm on about.

 
 
 

TextFromFont and complex scripts

Post by Rich [Microsoft Direct3D MV » Tue, 03 Jun 2003 23:42:25


[Please do not mail me a copy of your followup]



Quote:>That's excatly what we had been doing - using GDI to work out the correct
>order for the characters, then using D3DXCreateText to create meshes for the
>individual characters and positioning them as appropriate. It's only when we
>realised we couldn't actually work out which character codes we needed to
>give to D3DXCreateText that we found we had a lot more work to do.

I'm not sure what you mean here.  D3DXCreateTextW takes unicode characters,
just like GDI's DrawTextW.

Quote:>> Have you tried rendering the text at a large scale into a monochrome
>> bitmap and extruding the result yourself?  That might provide
>> something of reasonable quality for a minimal amount of effort.  Since
>> you'd be using GDI{,+} to render the text into the bitmap, you
>> wouldn't need to know anything about the characteristics of Arabic
>> language characters.

>Quality is extremely important in our application, so that was ruled out
>fairly quickly :)

Fitting curves to the result of GDI rendering into a large
(monochrome) bitmap should be able to give you sufficient quality,
though.  Its the same process as what D3DX is doing, just that you're
rasterizing the glyphs, then fitting curves to them again.  So its not
as efficient, but you get all of GDI's rendering know-how when you
create the bitmap.
--
    "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ:
              <http://www.xmission.com/~legalize/book/>
 
 
 

TextFromFont and complex scripts

Post by Graeme Foste » Wed, 04 Jun 2003 01:08:23




Quote:> [Please do not mail me a copy of your followup]

> I'm not sure what you mean here.  D3DXCreateTextW takes unicode
characters,
> just like GDI's DrawTextW.

DrawTextW converts the "simple" Unicode characters to their presentation
forms, D3DXCreateTextW doesn't. Give them the same Arabic string and you
will get very different results.

Quote:> Fitting curves to the result of GDI rendering into a large
> (monochrome) bitmap should be able to give you sufficient quality,
> though.  Its the same process as what D3DX is doing, just that you're
> rasterizing the glyphs, then fitting curves to them again.  So its not
> as efficient, but you get all of GDI's rendering know-how when you
> create the bitmap.

OK... But it sounds like just as much work to me. Also (as you say) it would
have memory and CPU requirements that we can avoid using the other method.

Cheers,
G.
--
Graeme Foster
Principal Software Engineer
Aston Broadcast Systems Ltd. (http://www.aston.tv)
Disclaimer: I really don't have a clue what I'm on about.

 
 
 

TextFromFont and complex scripts

Post by Rich [Microsoft Direct3D MV » Wed, 04 Jun 2003 02:18:03


[Please do not mail me a copy of your followup]



Quote:>DrawTextW converts the "simple" Unicode characters to their presentation
>forms, D3DXCreateTextW doesn't. Give them the same Arabic string and you
>will get very different results.

OK, I'll just take your word for that -- I'm not a Unicode expert and
I don't really understand the difference between "simple" Unicode
characters and "presentation" Unicode characters.

Quote:>OK... But it sounds like just as much work to me.

Yes, well only you can judge how much effort you are willing to put
into solving this problem.

Quote:>Also (as you say) it would
>have memory and CPU requirements that we can avoid using the other method.

The memory requirements for the bitmap wouldn't be much -- remember
its only a monochrome (1 bit per pixel) bitmap, so it could be really
large and still not consume much memory.  How big would you need?  A
4Kx1K monochrome bitmap consumes half a meg.
--
    "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ:
              <http://www.xmission.com/~legalize/book/>
 
 
 

TextFromFont and complex scripts

Post by Graeme Foste » Fri, 06 Jun 2003 18:09:50






> >DrawTextW converts the "simple" Unicode characters to their presentation
> >forms, D3DXCreateTextW doesn't. Give them the same Arabic string and you
> >will get very different results.

> OK, I'll just take your word for that -- I'm not a Unicode expert and
> I don't really understand the difference between "simple" Unicode
> characters and "presentation" Unicode characters.

I'm greatly simplifying it here, but Arabic characters can take different
forms depending on whether they're at the beginning, middle, or end of a
word. They are, however, still the same character. Since there are not
different keys for the different forms, when a word is typed the same
Unicode value is stored no matter where in a word a character is positioned.
Therefore, the context of each character must be considered when deciding
which glyph to render.

I suppose it's a bit like starting a sentence with a capital letter. If we
didn't have a Shift key, some clever bit of software would have to detect
that a letter was at the beginning of a sentence and display "A" in place of
"a".

Also, sometimes pairs of Arabic characters are combined into one glyph,
either because a better representation of the characters exists in the
typeface, or because they're just written differently when next to each
other.

There are a couple of examples here:

http://www.pms.informatik.uni-muenchen.de/lehre/seminar/international...

Also, lots of information (as you might expect) here:

http://www.unicode.org

Quote:> >OK... But it sounds like just as much work to me.

> Yes, well only you can judge how much effort you are willing to put
> into solving this problem.

Like I said - we've already solved it, we're just annoyed that we had to ;)

Thanks again for your thoughts on this issue!

Cheers,
G.
--
Graeme Foster
Principal Software Engineer
Aston Broadcast Systems Ltd. (http://www.aston.tv)
Disclaimer: I really don't have a clue what I'm on about.

 
 
 

1. DirectX 9 Mesh.TextFromFont memory leak/crash

It seems like repeatedly calling the Mesh.TextFromFont method on
varying strings results in a slow memory leak and eventual crash.

Below is the slightly modified code from the Text3D example in the
DirectX 9 C# SDK install.  After a few minutes, the mesh text turns
very small.   Soon afterwards, the app crashes.

Any ideas?

Thanks!

// Draw D3DXFont mesh in 3D (blue)
if (mesh3DText != null)
{
        double value1 = (double)random.NextDouble();
        someText = Convert.ToString(value1) ;

        // Create our 3d text mesh
        mesh3DText = Mesh.TextFromFont(device, ourFont, someText, 0.001f,
0.1f);
        Material mtrl3d = GraphicsUtility.InitMaterial(Color.Blue);
        device.Material = mtrl3d;
        device.Transform.World = objectTwo;
        mesh3DText.DrawSubset(0);
        mesh3DText.Dispose();

2. CorelDraw -> Mac ??

3. ScriptRunner script for CS2, neat way to launch scripts

4. Jobs@Exile Interactive Inc.

5. Gnuplot scripts within Korn shell scripts

6. probleme d'utilisation de MESH BOMBE sous max

7. script to generate multiplot scripts

8. How to make a Neon light in POV?

9. Script error 600 with a simple script to export

10. Running scripts from within scripts

11. creating complex 3D objects in ANFY3D/SPAZZ3D

12. INFO: optimizing complex models

13. Surface calculation for complex polygon