Fonts are not supporting UTF characters

[IanTrudel]

Updated to 3.2.23. The font is too bold and does not display some characters properly. It doesn't seem to use .fontconfig nor .fonts directory in home user directory. fc-cache is just too fast to update 1 GB fonts.

[ccoupe]

Of course, my system does not do that! fc-cache has never been fast so that's a good symptom.

fonts.conf is in c:\Program File(x86)\Shoes\etc\fonts\fonts.conf and env var FONTCONFIG_FILE should point there. You did un-install the previous Shoes before updating?

[IanTrudel]

I did uninstall Shoes beforehand, as usual. It apparently kept the old directory in FONTCONFIG_FILE and the new install added its own. So fc-cache.exe would use the first listed fonts.conf (now nonexistent after uninstall). Removing the extra path yields in the follow:

C:\Program Files (x86)\Shoes>fc-cache.exe
"C:/Users/Ian/.fonts": not a directory, skipping

Unfortunately, the installer does not create %USERPROFILE%.fonts directory. I had to rename my existing .fontconfig directory to .fonts. Now fc-cache is working and the rending is correct. It is obvious some changes have to be made to the installer.

[ccoupe]

I think it depends on the version you uninstalled. Newer versions do delete the FONTCONFIG_FILE env on uninstall. Older Shoes did not. #106

[IanTrudel]

Uninstalled 3.2.22 to install 3.2.23. The installer code hasn't change in 5 months. So perhaps the cleaning up didn't work properly during uninstall?

https://github.com/Shoes3/shoes3/blob/master/platform/msw/base.nsi#L129

[ccoupe]

I think the NSIS code doesn't delete the var if it contains two values, so if you ever get two in there for any reason, only one will be deleted. Applies to the PATH as well where it makes sense.

[ccoupe]

Close this one?

[IanTrudel]

It's unclear whether it should be closed or not. The issue itself is no longer a problem, at least for me, but the upgrade path may be problematic. Let's say someone upgrades from a previous version that are more distant than in my case. Perhaps a ticket should be open for the upgrade path with enhancement tag and close this issue here. What do you say?

[ccoupe]

It bit a few people in the ass, not just you. I don't see an enhancement coding solution unless we return to the shoes.bat and I'm not going back there lightly although I've been tempted many times. We could always create a "Warning" label and post an issue and solution for git users. But, who is going to see that? Or care?

[IanTrudel]

The batch file wouldn't solve anything. The installer may be able to check whether FONTCONFIG_FILE is already set or not. The nature of this variable seems to be demanding one value only. So maybe it should use the existing value, if any. Maybe it should wipe off all values upon uninstall.

[ccoupe]

My concern is there might be other programs on the users system that use the same env var and it's set up fine for that app and Shoes comes along and clobbers it.

The solution probably belongs to the fontconfig project so it's a little more 'system' wide like it is on Linux and not 'user' wide.

[IanTrudel]

System wide should make sense. We should use existing FONTCONFIG_FILE but there is a caveat — if someone uninstall another program that defined the environment variable, it might not be subsequently available.

You gave me an idea though. Clobbers could offer a diagnostic pane where it looks for faulty installation, common problems, etc. Maybe could even fix those. How's that sound to you?

[ccoupe]

Cobbler is getting a lot buttons so it might be time for something else. In this case, if the fonts don't work the windows repair screen wouldn't be much help.

Based on the traffic on the ruby-core mailing list, they do fix bugs in the RubyWin32 module/ext so it's probably safe to use in Shoes/Windows although I'm not the best person for using the API for Shoes purposes.

[IanTrudel]

You might be right about Cobbler where it may needs rethinking. However, I disagree on a repair feature — it would simply have to check FONTCONFIG_FILE environment variable, whether it has a one single value and it should be a valid path and file. Then repair may be possible or at least provide a link to the solution.

It could be an interesting diagnostic feature where a checklist could run and report on screen.

[ccoupe]

I don't doubt the utility of some diagnostic and repair (there is a image cache clean screen - which may or may not work correct). lib/shoes.rb could get the env var (on Windows), find the ';' and then do what? It can't trust either one to display properly so the repair screen could be unreadable.

Since we compile fontconfig from source, it would worth exploring to see if we could rename the env var to something like SHOESFONT_CONF. Doing that, we don't have to worry about other apps. It would not surprise me to learn that is already an option they thought of.

I need to revisit the dependencies soon - @passenger94 got gtk3 working on Linux, so I need to get those Windows deps compiled to try it there. GTK3 does appear to work on OSX but there were some scary homebrew things to do before Shoes could be completed for that so I stopped.

[ccoupe]

Having read this email xchange http://lists.freedesktop.org/archives/fontconfig/2007-October/002686.html, I'm trying to remember why Shoes/Windows is using an Env var. Was it because of complaints in the console? Why did we (I) put fonts in the gtk user/etc? Oh, I just remembered! It's there for people who build Shoes on Windows and want to test it w/o installing it.

[IanTrudel]

I don't doubt the utility of some diagnostic and repair (there is a image cache clean screen - which may or may not work correct). lib/shoes.rb could get the env var (on Windows), find the ';' and then do what? It can't trust either one to display properly so the repair screen could be unreadable.

It should display on screen and generate a log.

I'm trying to remember why Shoes/Windows is using an Env var. Was it because of complaints in the console? Why did we (I) put fonts in the gtk user/etc?

The environment variable is used by fontconfig to store the font cache.

[ccoupe]

"It should display on screen and generate a log."

If they can't read the screen how would they would they know the log existed? They'd have to file an issue and someone would have to tell them "check the log" and later "here's the instructions for getting FONTCONFIG_PATH set correctly" No winners .

"The environment variable is used by fontconfig to store the font cache."

Primarily for the benefit of those who build Shoes from source on Windows and need to change it on the fly. IF fontconfig uses the dll location as its first guess and then uses the ENV var. (on linux it appears to look in lots of places). Typically, the env var overrides the defaults (it's used before other paths).

You (and others) had two search paths in the env var due to a "didn't think of that" in a the uninstaller - neither of us thought to write that code. Perhaps we thought PATH meant multiple values allowed? Perhaps we aren't as smart as we hope to be? No value for anyone to assign blame. It's an unfortunate event but your proposed cure for post-hoc clean-up would also increase the maintenance effort and the risk for another "didn't think of that" error.

Multiple layers of Error correcting code eventually ends up in some meta-discussion about which methodology or language de-jure to use and I find those unproductive to getting work done and getting maintenance work out the door, particularly for hobbyist effort like Shoes. (3.2 or 4).

[IanTrudel]

If they can't read the screen how would they would they know the log existed? They'd have to file an issue and someone would have to tell them "check the log" and later "here's the instructions for getting FONTCONFIG_PATH set correctly" No winners .

There is no obligations here as it is simply a suggestion. If you think about it for a moment, most systems behaves exactly like this: display on screen and log file. We can have a FAQ on the website or in a file as well.

Multiple layers of Error correcting code eventually ends up in some meta-discussion about which methodology or language de-jure to use and I find those unproductive to getting work done and getting maintenance work out the door, particularly for hobbyist effort like Shoes. (3.2 or 4).

It can be implemented in Ruby without any major hurdles. Some corrections might need admin level but this can be done as well. It's not a meta-discussion but there is really no obligations to implement it.

Alternatively, the installer could look for the env variable and choose to do nothing if there is already a value.

[ccoupe]

Alternatively, the installer could look for the env variable and choose to do nothing if there is already a value.

I like that. For better or worse, fontconfig will be with us for awhile. Are you willing you write the nsis code?

[ccoupe]

I started to work on this - the NSIS check for existing value in the FONTCONFG_FILE. I don't think NSIS can fix @BackOrder problem. (I tried). I think the problem is that if you're running in a console then the env vars you have created/modified are not 'system' sticky but the env vars set by the installer are system sticky (copied into the subprocess at console startup). IOW you can't run the Shoes installer from the console and assume it will rewrite your process local env vars. It won't. Nor will it propogate env changes to other existing consoles (for damn good security reasons).

Also for damn good security reasons Cobbler should not be able to set system wide env vars. If someone wants to modify the system level registry values for their convenience they can and should write a .bat file using existing MS tools. Without working code to prove I'm wrong. this issue will be closed.

[ccoupe]

Closing. Reopen if you feel other wise.