I am using DotNet v1.1.4322.

This issue can be replicated with various text fonts - but is easiest to see
using WingDings.

1) Create a string which includes character #132
2) Draw it to a Graphics object with DrawString

S := #130+#131+#132+#133+#134+#135+#136+#137+#138+#139;
F := System.Drawing.Font.Create('WingDings', 16);
G.DrawString(S, F, Brushes.Black, 0, 0);

The output always wraps immediately after character #132, regardless of font
size, StringFormat settings, etc.

Is this a bug in DrawString, or is it due to some other setting of which I
am not aware?

Does it happen in DotNet v2?

Graham Dawson wrote:
I don't know what language this is, but the meaning is clear :)

Yes.

I was goig to write what I found, but it and more is all here:
<http://blogs.msdn.com/michkap/archive/2005/12/16/504851.aspx>

From which the last comment (by John Cowan) seems to make for a nice
summary:

"The main point of U+0084 and U+0085 is to discriminate between the two
historic uses of U+000A, line feed and new line respectively.   U+0084
was intended unambiguously as the line feed function, whereas U+0085 was
intended unambiguously as the new line function.  Of course it didn't
help.  (This is not a Unicode issue, actually.)"

Hi Larry,

Thanks very much for your helpful response. My language is Delphi (Pascal) -
syntax not too dissimilar to C#, so I was confident my code fragment would
be decipherable.

It looks as though this linebreaking attribute of  character 132 (U+0084)
may not be avoidable in DrawString.

This would not be a problem except that I use a custom symbol font (similar
to WingDings) which contains an important glyph in the U+0084 slot. Like
WingDings, there were no problems with this under Win32. But in DotNet, even
if I render JUST this single character via Drawstring (which you might think
would make the subsequent linebreak irrelevant) it causes "odd" character
aligment problems - ie. the character is rendered too far to the right, as
if it had a spurious blank character in front of it or perhaps more likely
has been justified differently from other glyphs in the same font. (I am
using StringFormat to center the glyphs both horizontally and vertically.)

At this point I am thinking that this will require me to create a new
version of my custom font - with the U+0084 slot deliberately left unused...
Unless anyone might just have some clever workround idea?

Regards, Graham

OK - I found my own workaround. The problem appears to be that the
DrawString function "believes" that character 132 has zero width (probably
because after the line break occurs, the end position of the character is
the same as its start position - although one line below), so using

    StringFormat.Alignment := StringAlignment.Center

actually appears to result in a left (near) alignment instead. The
workaround is to set the string alignment to Near, and then work out my own
horizontal offset to centre it. I am not sure if the text measuring function
would also return a zero width for this character, but in my own case this
doesn't matter, because all my other glyphs are the same width, so I can get
the required width by measuring one of the others, if necessary.

Graham

Error with SqlSmlCommand
WSS document event handler that will use System.web.mail sendmail
ClickOnce - Setting up a staging and production versions
creating a compile time error... is it possible?
using SerialPort in a service