GNOME Bugzilla – Bug 588015
Make sure that GIMP is Terminal-Server-aware
Last modified: 2013-01-22 22:16:51 UTC
I have a basic install of Windows Server 2003 32 bit and I am trying to use the text tool. I am using the GIMP 2.6.6. This is a basic install of Windows Server 2003 and the default install of GIMP 2.6.6 I am not sure what is causing the issue but I have an idea that it is a configuration issue probably with fontconfig and windows server. When I try to use the font tool there are no fonts listed and when I try to use it I get a message letting me know that there are no fonts installed. Message: Due to lack of any fonts, text functionality is not available.
I can't reproduce this, GIMP does find the installed fonts when running as a normal user or as an Administrator on Windows 2003 server. Is there anything special to this system? Can you reproduce this on other servers?
It is setup running terminal services. I have been able to reproduce on all test terminal servers. Also Gimp is installed on another drive not the default windows C: drive. I tried a windows server that was not in terminal server mode as 2 different users and the fonts did install correctly so it looks like it is a problem on windows terminal servers. Please let me know if you are able to reproduce on a termianl server deployment.
It could be that fontconfig fails to determine the value for WINDOWSFONTDIR in such environments. THis should be possible to check by adding the windows font dir to the fonts.conf file manually and see what happens. If this works, then we will probably close this bug as NOTGNOME - I see that you have already reported this in the fontconfig tracker: https://bugs.freedesktop.org/show_bug.cgi?id=22037
Michael I added the full path of the windows font directory into the fonts.conf file which fixed the issue. I would agree that it is not grabbing the path correctly in a terminal server environment. Thanks for looking.
fontconfig constructs the path corresponding to the WINDOWSFONTDIR magic markeer by using the "fonts" subdirectory of what GetWindowsDirectory() returns. (See FcEndElement() in src/fcxml.c in fontconfig.) Reading the docs for GetWindowsDirectory(), it says: If the application is running in a Terminal Services environment, each user has a private Windows directory. There is also a shared Windows directory for the system. If the application is Terminal-Services-aware (has the IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE flag set in the image header), this function returns the path of the system Windows directory, just as the GetSystemWindowsDirectory function does. Otherwise, it retrieves the path of the private Windows directory for the user. Presumably the GIMP executable does not have the IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE flag set, so the private Windows directory is used. And apparently there are normally no fonts there (unless the user has installed private ones), they are in the system Windows directory. So, a fix would presumably be to use GetSystemWindowsDirectory() instead of GetWindowsDirectory(). I will try to get that change into fontconfig. In the meantime, I wonder if starting to build the GIMP executable with IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE would be possible, and if it might have any unintended side-effects? MSFT's link has the /tsaware option to set that flag, but I don't see any ld option to do it. (I assume it should be possible to toggle it with editbin, though.)
GIMP does not meet the first requirement for the IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE flag: http://msdn.microsoft.com/en-us/library/cc834995%28VS.85%29.aspx "The application does not use .ini files." Granted, we use *rc, but I guess they are writing about the same conceptual problem.
It's questionable IMHO if applications like GIMP which are from Unix, written to run on multi-user systems from the start, even can be discussed using the same terms as oldfashioned Windows apps that can be classified as "terminal server aware" or not. I would say that GIMP is extremely well "terminal server aware" as it stores all user-specific settings in user-specific folders. When the MS docs talk about "not terminal server aware" apps, they presumably mean apps that store settings in the *Windows* folder! Thus for such apps to work in a terminal server, they need to be tricked into actually using the user-specific "Windows" folder.
I believe the INI files only refer to actual configuration files stored in Windows directory, which was the norm back in the Win3.1 days (and which some applications carried on doing in the Win9x era). The TS-aware flag basically means "the application is ready for multi-user environment, where several copies of the application can run at the same time under different accounts". The flag exists because many older Windows applications didn't cope with such environment properly.
The bug has been fixed in fontconfig.
Please try GIMP 2.7.4 and report back, we won't fix 2.6 bugs any longer.
Could you please try to reproduce problem with GIMP 2.7.4 or later version and update the bug report with your findings, tia.
GIMP 2.8 doesn't set the --tsaware linker option as far as I can see. This should be set the same way as --large-address-aware is.
Created attachment 213578 [details] [review] add a linker flag --tsaware in the same way as --large-address-aware Quick patch - not tested
Created attachment 213588 [details] [review] Quick patch - untested If, differently from --large-address-aware which is apparently only needed on 32bit Windowses, --tsaware is needed always, then it is better to patch only app/Makefile.am
Fixed in master and gimp-2-8: commit 104321642476a0838a4ffbafca0be887272ea443 Author: Jernej Simončič <jernej|s-cccp@eternallybored.org> Date: Mon Jan 21 21:17:45 2013 +0100 Windows: #588015 - Make sure that GIMP is Terminal-Server-aware (cherry picked from commit 4b9af783360cc0bcc4141e6a46d3c188dc4b8d73) app/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)