PDFsharp & MigraDoc Foundation

I'm now using the PDFSharp 1.3 in my little project and I found that when I use XFont, the memory usage goes up very quickly. And if I create about 50 XFont objects, the memory usage would exceeds 200Mb. My project is a small one, thus, such an memory usage is not acceptable.

I have dived into the source code a bit and found that FontData class used a lot of memory. And the issue is that there is no way to free the allocated memory that FontData class uses as far as I can see.

I can see that it seems that FontDataStock class holds the memory and it doesn't free it.
Is there a way to address this? Or is there a walk around solution?

I know that PdfSharp probably uses FontDataStock to cache the font data for performance's sake, but I think it would be better if a way to reclaim the memory is provided.

FYI, my program uses the office 2007 like live preview so that it creates different XFont objects when user is hovering one font family and that cause the going up of the memory usage.

50 XFont objects?

Fonts should only be added once to FontDataStock.
If you create 50 XFont objects for "Courier,10", the memory usage should stay low (otherwise there is a bug).
FontDataStock.UnregisterFontData is not yet implemented.


Workaround: So this preview shouldn't use XFont objects.

Hack: add a setter to "public static FontDataStock Global" that allows you to set it to null (when the users hover over fonts).

_________________
Regards
Thomas Hoevel
PDFsharp Team

About the live preview: I'm creating XFont objects with different font families, so the memory usage is huge if a lot of XFont with different font families are created.

About the UnregisterFontData method, I also noticed that it didn't have a implementation.

About the walkaround: If not XFont, what choices do I have?

About the hack, the issue is that FontDataStock is an internal class so that if I want to access it, I have to make it a public class which will make a lot classes have to be public. This fact makes it not practical to do so.

Or just use "InternalsVisibleTo" in PDFsharp's AssemblyInfo.cs.

_________________
Regards
Thomas Hoevel
PDFsharp Team

Thanks a lot, now the problem is solved. You're the hero.