I have been fighting a losing battle against loading fonts from an embedded file for use with DirectWrite. I am writing a simple puzzle game that has a C#/XAML interface but also uses SurfaceImageSource to add some DirectX content.
I have written a WinRT component that handles all of the DirectX code, and it works quite nicely. Some of my DirectX content is text drawn using the DirectWrite API. I can draw all the text I like so long as I’m loading an installed font from the system using IDWriteFactory::GetSystemFontCollection(), etc. But, I cannot seem to find a way to load a custom font from an embedded file.
From what I can tell Metro apps are not allowed to load files from the filesystem in the same way as a traditional app. So, the IDWriteFactory::CreateFontFileReference() method that takes a normal file path is worthless to me, right? I need to load my file from an ms-appx URL.
So, I wrote a custom font loader in my WinRT component that implements the IDWriteFontCollectionLoader interface (which is a ton of work if you’ve never done it before btw) that loads the font from an ms-appx URL using the new StorageFile API. Now, I can load my IDWriteFontFile and I can get a IDWriteFontFace, but if I try to call any of the truly useful methods on the font face it returns E_UNEXPECTED. I can get the number of glyphs and the glyph indices, but if I try to call something like GetGlyphRunOutline() or GetDesignGlyphMetrics(), it fails with E_UNEXPECTED. Using the same drawing code that generates an ID2D1PathGeometry using GetGlyphRunOutline() works great as long as I install the font file and get the IDWriteFontFace through the series of calls starting with IDWriteFactory::GetSystemFontCollection(). I am working with a normal true type font.
So, how do I load a custom font from an embedded file into DirectWrite in a Metro app? I’m probably just missing something easy, because I am certain that other people will want to be able to load custom fonts in this way.
I have a sample project (or could prepare one easily) for anyone who can help me identify my problem.
I have loaded the two IDWriteFontFace objects side by side, and I tried to figure out what is different between the one that works and the one that breaks. What I need to see in order to find out why it is failing is opaque to me hidden behind inside the IDWriteFontFace interface. HELP PLEASE!
Question also posted here: Building Metro style games with DirectX Forum
Well, the answer is… don’t write a IDWriteFontCollectionLoader! You can use IDWriteFactory::CreateFontFileReference() with the StorageFile API. I was under the impression from all of the Microsoft Conference talks I had attended that in Metro you would be unable to access the native file system directly; the way forward would be to use the StorageFile API which references resources, etc. using ms-appx URLs. I understood that this was done for concurrency and to allow the OS to insulate itself from Metro apps that would be downloaded from the store by creating a file system sandbox. I think that is accurate. But, I feel like I was led to believe that we would never be able to get native file system paths. That is NOT true. IStorageFile provides a way. Just use IStorageFile.Path. I never looked at it because I just assumed the Path property would hold the ms-appx URL that I used to create the object. Microsoft probably provided this for exactly the purpose in my problem above: calling legacy COM interfaces that require a native path.
I haven’t done any testing to determine whether the WinRT framework actually sandboxes you if you try to access a native file system path outside your own app package. I’m betting that it does…