About the people who work for companies, and *their* fonts

by Michael S. Kaplan, published on 2008/09/17 03:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2008/09/17/8954874.aspx

On a completely unrelated note, can anything ever be really Wright again now that Rick is gone. :-(

People who read my blog from the other day titled About companies and their fonts the other day who know something about fonts on Vista might be torn between two different feelings.

You know, the feeling of "wondering if I have any idea what I am talking about" versus the feeling of "being cheated of the full answer."

I suppose in fairness to that latter group that still have some faith in me, I should come clean and finish the story. :-)

Now it is true that, as I said:

Of course, to start with there is that whole On installing and removing fonts series that has laid out many of the real problems with and added some suggestions about the installation, updating, and removal of fonts from Windows.

And of course from the information in that series one can see the exact permissions that must be allowed if one wants permissions to be broadly granted to users to manage their own fonts:

• Write permissions to the Fonts folder, and
• Permissions to add values to the HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts subkey in the registry.

but if you find a company full of users who know how to do all of that manually then....

Never mind, that has never happened.

On the other hand if you find a company that would lock systems down but then go out of its way to open them up like this, then....

Never mind, that company will fold soon, so what their corporate network security and policy practices may or may not be is only interesting from a forensic analysis of who took the company down. :-)

What people are looking for any time they talk about managing their own fonts is not the ability to randomly write registry keys via function call, copy files via the DOS prompt, and reboot. They are talking about how to use the tools that are there -- the Fonts folder, dragging files in and out, etc.

That no longer works the same way -- having permission is not enough now, because of the way UAC/LUA works.

One example from the people who asked me about the rest of the story I was skipping there came from developer Matthew:

Indeed it is more complicated than that--at least as best as I can determine.

You'll recall there was a thread recently (end of August) about pretty much this issue.  I looked at the relevant code (the font dialog and the functions it uses), and, from what I saw, the only way to allow a user to manage their own fonts, across sessions, using documented UI or API, is for that user to be a member of the Administrators group.  This stems from the way the font dialog uses UAC--it requires elevation to Administrator (not just to an elevated token) before attempting any font manipulation, even if the user would have access.

That's just it -- the handler on top of the virtual Fonts folder, both from the Add Fonts... dialog and from drag/drop with the folder, is expecting more.

It runs through the "Elevate Me, Please?" code which has some pretty high expectations, as Matt indicates above -- higher than you may have set them to yourselves since in this case that code is not designed to try it and try to elevate on failure.

Which is just about the only way it could work well in this case.

And what is worse is that if you turn UAC off (which some people do!) then because of the way the code is structured, you might still be unable to add fonts, due to the way the code was structured to fail the attempt if elevation could not happen (and not properly handling the case where elevation failed due to it being turned off!). Luckily this is not a typical scenario for large companies to be allowing, it is just an additional bad example which can easily hit customers in the non-LORG case....

So what to do here, exactly?

Well, I suppose the space is ripe for third party utilities that will do all of the things that can be done programmatically when the main user interface to do the work has been shut down, either by intentionally having the UAC code blocking their way, or by turning UAC off and blocking this case anyway.

Hopefully someone is looking into making this space better for next version.

And also hopefully someone is looking at a utility like the one above to handle the cases today.

And finally, hopefully application developers who have to design applications that do not require Administrative permissions have looked at resources like that On installing and removing fonts series here, especially that last part that goes into the benefits of using font embedding and private fonts to remove the need for Administrative permission entirely.

Of course it is easy to start going on at length about how this kind of thing makes the OS seem unfinished. Though taking the wider view, I think the better locking down of the Fonts folder IS finished. What is left is working on the overall usability features of the Fonts folder, something that has been lacking for a long time anyway, even outside the problems noted here....

In the meantime, the pieces are in place for Microsoft to make all of this better; the pieces are even in place for others to step up in the meantime. The glass is, if not half full, then at least not half empty -- and both the bartender and a server behind the bar are on how way back to do the refill. :-)

This blog brought to you by ઘ (U+0a98, aka GUJARATI LETTER GHA)

# John Cowan on 17 Sep 2008 11:26 AM:

Simon Buchan on 22 Sep 2008 3:30 AM:

Michael S. Kaplan on 22 Sep 2008 3:42 AM:

John Cowan on 22 Sep 2008 12:03 PM:

go to newer or older post, or back to index or month or day