Font Memory Issue

[Parody]

Expanding on the info provided in the 217 release notes:

If you're looking to remove fonts from your system, think about which programs you've installed that might have also installed fonts, like office and design programs. Try using their installers or their entry in the Programs and Features Control Panel to selectively remove unwanted fonts rather than just deleting them from the Fonts folder. That way the programs "know" they're gone and you shouldn't run into problems like the one described.

However, if you've been adding fonts yourself and/or you don't know which fonts came from where, switch the Fonts folder into Details view and sort by "Designer/foundry". Any fonts whose foundry is "Microsoft Corporation" should be left alone. (On my Windows 10 install I believe a couple of these came with Office, but most are system fonts and shouldn't be removed.)

Note that this isn't comprehensive; some of the most commonly used fonts that come with the system are from other foundries. Arial, Courier New, and Times New Roman, for example, are from Monotype. It does, however, give you a visible baseline for which fonts you shouldn't be stubborn about removing!

Microsoft does provide lists of fonts that come with various products, but unfortunately these haven't been updated for more recent releases like Windows 10 or later versions of Office. Wikipedia has a list of typefaces included with Windows that does include Windows 10, but I haven't checked it personally.

[kbs666]

I'm still sort of impressed by the user who found a way to delete Tahoma. Windows doesn't like it when you try and mess with the system fonts.

Still not as bad as the Eve installer deleting C:\boot.ini a few years back.

[Parody]

Booting off a boot disc/drive would work; the recovery console would probably work. I don't really want to find out, though. :)

[kbs666]

I was lucky in that I had a recovery disc available, IIRC this was 2007. But a lot of people had to do full reinstalls of Windows. It goes to show that you should never name something the same as a vital system file even if it will be in a separate directory.

[craghammer]

Imho, removing Fonts from the system is not a very viable option. I have two reasons this is not good (at least for me); 1: Windows won't let me (may be policy rules), 2: I need a lot of fonts for my professional and private work.
One option would be to load only the necessary fonts into the RW runtime, but by using 3rd party librarys like DevExpress you might not be able to control that, but that sounds weird to me as a .NET developer.
Have you explored the various UI improvements that DevExpress offers? The UI could (in the far future when you have time) benefit from some upgrades to a more modern UI

Is there any work on moving RW to 64-bit?

[Parody]

It's a workaround. Not one I plan on using either, since I need the fonts I have installed for various projects, but for some folks it may be an option. It is unusual that you would be prevented from changing fonts, but if it's not your machine then you may well have policies set.

Poking around the Internet brings up a couple of posts pointing towards .NET applications (which use GDI+) on Windows 10 using a lot more memory when working with fonts than on Windows 7. No idea if it's true, though (FWIW) I am on Windows 10 now.

[rob]

Originally Posted by craghammer

Imho, removing Fonts from the system is not a very viable option. I have two reasons this is not good (at least for me); 1: Windows won't let me (may be policy rules), 2: I need a lot of fonts for my professional and private work.
One option would be to load only the necessary fonts into the RW runtime, but by using 3rd party librarys like DevExpress you might not be able to control that, but that sounds weird to me as a .NET developer.
Have you explored the various UI improvements that DevExpress offers? The UI could (in the far future when you have time) benefit from some upgrades to a more modern UI

Is there any work on moving RW to 64-bit?

It's NOT presented as something that users SHOULD do. It's merely presented as an option. We're informing users of what's going on with their system and the implications it has on their experience using Realm Works. It's entirely up to the user regarding what they choose, and some users won't be able to do anything about it, even if they want to. But lots of casual computer users will be completely unaware of all the silly fonts that are cluttering up their system, and they may appreciate being able to reclaim a lot of that essentially wasted memory.

As I indicated up-thread, we haven't done a thorough investigation regarding the font loading within DevExpress, but there is no readily apparent solution we've found. I'm pretty sure it would be possible, but then it's a question of how much work is involved and whether we should be spending our time on that instead of the many other features users are clamoring for. If you know of a quick solution with DevExpress, please let us know.

Your suggestion of revamping the UI to take advantage of recent improvements to DevExpress has one major drawback. Reworking the UI will entail LOTS of work that will result in no forward progress on new capabilities while that is going on. Given how loudly many users have been clamoring for a laundry list of new features, that would probably go over poorly with a lot of users. It's a damned-if-we-do, damned-if-we-don't situation.

Migrating RW to 64-bit is something we've looked into, but we haven't actively pursued it yet. It will entail a fair bit of work to accomplish due to a few key factors. Ultimately, a 64-bit solution looks to be the best solution overall. However, we've been focused on getting the Content Market into place, so work on stuff like that has not yet been undertaken.

[craghammer]

Originally Posted by rob

It's NOT presented as something that users SHOULD do. It's merely presented as an option. We're informing users of what's going on with their system and the implications it has on their experience using Realm Works. It's entirely up to the user regarding what they choose, and some users won't be able to do anything about it, even if they want to. But lots of casual computer users will be completely unaware of all the silly fonts that are cluttering up their system, and they may appreciate being able to reclaim a lot of that essentially wasted memory.

As I indicated up-thread, we haven't done a thorough investigation regarding the font loading within DevExpress, but there is no readily apparent solution we've found. I'm pretty sure it would be possible, but then it's a question of how much work is involved and whether we should be spending our time on that instead of the many other features users are clamoring for. If you know of a quick solution with DevExpress, please let us know.

Your suggestion of revamping the UI to take advantage of recent improvements to DevExpress has one major drawback. Reworking the UI will entail LOTS of work that will result in no forward progress on new capabilities while that is going on. Given how loudly many users have been clamoring for a laundry list of new features, that would probably go over poorly with a lot of users. It's a damned-if-we-do, damned-if-we-don't situation.

Migrating RW to 64-bit is something we've looked into, but we haven't actively pursued it yet. It will entail a fair bit of work to accomplish due to a few key factors. Ultimately, a 64-bit solution looks to be the best solution overall. However, we've been focused on getting the Content Market into place, so work on stuff like that has not yet been undertaken.

Thanks for the quick answer @rob, your responses are pretty on spot I'll look a bit into the font-loading issue and see if I can dig something up. Luckily I have 150 .NET devs around me, maybe someone has any insight (although, no guarantee )

[craghammer]

@rob: This ticket might be an approach to limiting fonts in RW

https://www.devexpress.com/Support/C...etails/T452974

[Parody]

That ticket isn't public, FWIW:

Originally Posted by DevExpress website

You can't view this ticket

Log in if this is your ticket.