One reader wrote in stating that while Microsoft catches quite a bit of heat for its security holes, those are not the only bugs that Team Redmond struggles with. Sometimes the company — as is also the case with most other software vendors as well — knows about bugs, but does not fix them. This particular reader pointed to three bugs that Microsoft is aware of but has yet to either fix or commit to correcting. His letter in full: A bit of background – I started migrating a VB6 application to .NET a few months ago. This app has code that dates back to VB 1.0 (!) – so I decided a rewrite, rather than a direct port, to be the prudent direction. I started on the trickier aspects of the application first to ensure that a .NET rewrite was even possible. And I ran into three issues right away. I tag them as critical because I don’t have a product with these roadblocks in place. 1. GDI+ and .NET 2.0 don’t support Adobe Type 1 or OpenType fonts with embedded PostScript outlines. Enumerating system fonts using the .NET InstalledFontCollection() leaves out Postscript based fonts. And GDI+ simply can’t draw PS fonts. The only work around is to use interop to legacy Win32 API font and drawing functions. Apparently the Windows Presentation Foundation does support Postscript fonts. But I have not explored that tool set yet. Classic VB has always supported PS fonts. This is acknowledged by Microsoft. 2. GDI+ does react to system font changes. Say you have a text editor written with .NET 2.0 WinForms application and a user installs a new font using the Windows Control Panel. That font will not be made available to your application until the user restarts it. GDI+ does not process WM_FONTCHANGE messages sent out by Windows. Classic VB recognizes font changes while an application is running. Microsoft marks this as an operating system bug in GDI+ and won’t give me any details when/if a fix would occur. 3 .NET PrintPreview Control object has font-related bugs. Even if you play by the rules, using only plain vanilla .NET and no funky Win32 interop, you still get bitten. The PrintPreview control itself has a nasty little bug that renders it close-to useless for me. An uninstalled TrueType font added to a .NET PrivateFontCollection renders correctly on forms and printed documents. But the PrintPreview control renders the text as Courier. Terrible. This is acknowledged by Microsoft. I suspect it would be easy to fix. But they won’t tell me if it will be in Visual Studio 2005 SP1 release or not. These VS 2005/.NET bugs occur regardless of the language used – C# or VB.NET. How can developers get Microsoft to fix bugs like these? Talkback via the comments function below. Software Development