Where does SDL_TTF look for fonts? - sdl-2

Does TTF_OpenFont have any sort of path or standard install location it looks in, or only in the current working directory?
If the latter – have any conventions been established as to where applications install the TrueType fonts they need? I'm on a Mac, but I'm interested in the answer for Mac and Windows both.

TTF_OpenFont doesn't use any standard location to search for a font. You can give it a relative, to where your executable is (relative to the directory it is in, for example you could use chdir) or a full path.
Imo is best for you to ship the fonts you'll be using with your application.

Related

Windows equivalent of /usr/share/locale?

I have a program, ported from Unix, that uses libintl, and thus ships with .mo message catalogs. In the Unix world, those get installed into /usr/share/locale, and that's where this program will look for them. On Windows, that directory structure obviously doesn't exist. Is there a recommended location to install message catalogs in, or should I just install them alongside the program itself in C:\Program Files?
When using libintl you almost always hardcode the directory where message catalogs are located. You also do that for Unix, not just for Windows.
The difference is that for Unix you store the translations in a common directory, for example /usr/local/share/locale whereas for Windows you install the translations in the program directory.
A couple of years ago I have written an internationalized Gtk application and subsequently ported it to Windows. It will probably no longer build but I guess the libintl stuff hasn't changed since then. You can find it here: https://savannah.nongnu.org/git/?group=gibbon

How do I use third party TTF fonts on Cygwinx? How about Windows fonts?

This is 2 questions in one. Should I split them in two separate questions? I think in the end is the same thing.
I want to use some third party ttf fonts on my Cygwinx programs and I've being searching the web and Cygwin's docs and FAQs to see how to install this fonts on it. If it is possible to use third party fonts. How do I use all the fonts that windows already has installed?
It is as simple as that, I have a lot of fonts on windows and installed Cygwin on top of windows. I thought that Cygwin would automatically use all those nice fonts, but no! there is only a subset of them, and I'm starting to think that this subset of fonts are just open fonts that come with Cygwin with some aliases.
What have I tried?
Searching on Google, a lot!
Reading and searching CygwinX docs.
Searching Cygwin files for ttf fonts or related fonts configs.
Tried to understand /etc/fonts/* by myself.
Searching for some "font-update" program that is mentioned on some old (2005) emails of the Cygwin mailing list.
All that without any real achievement.
I'm using Windows 10 (64 bits) and Cygwin64 (installed through the Cygwin-Setup version 2.891).
The subset of windows fonts used by cygwin is defined by postinstall script
/etc/postinstall/zp_fontconfig_cache_1.sh
the Windows fonts are linked in /usr/share/fonts/microsoft
On my system around 229 of the 350 present under C:\windows\Fonts are selected.
You can copy your extra fonts in the same directory and run the same script.

Manual Cygwin Installation without using Setup.exe

I am having issues with finding all of the necessary files to actually install Cygwin correctly when not using the premade setup utility. The reason behind this is the fact that my company computer blocks the usage of the .exe, and won't give me clearance to install it, (they say it isn't needed for the job) but expects me to perform certain tasks that Cygwin would make much simpler.
So my question is thus; is there somewhere/someone that would have a list of packages that I would need to manually install from one of the mirrors to make Cygwin run correctly?
Well,
This is a new answer to an old question, but it might be helpful for someone...
Just run the installer with -B switch, for example:
setup-x86_64.exe -B
You should install it then on a path where you have rights.
If you don't need the full POSIX compatibility (which I'm guessing you don't, if the Unix subsystem isn't required for your job), I'd generally suggest you go with Mingw rather than Cygwin.
Sadly, Mingw also has an installer these days. It probably also requires admin (try it and see). However, you can download the individual components you need if you want to do it that way. That shouldn't require admin, so it would probably get you exactly what you want.
Mingw is also more corporate-friendly from a licensing standpoint, as its compiler doesn't render code built with it GPL like Cygwin's does.
Generally the rule is:
If you want to use Unixy tools to help with your native Windows development, you want Mingw.
If want to port a full (POSIX) Unix program to windows, you want Cygwin (and perhaps a support deal with Red Hat to get around the licensing problem).
There's a writeup on getting Cygwin [to work] on portable storage devices.
Boiling it down, you'd have to do this on a machine that does give you .exe/admin access to write to a 'stick, then run from the stick at work.
On the off-chance that super-lockdown-site allows you to run USB devices.
Use the GNUWIN32 utilities instead. http://gnuwin32.sourceforge.net/
That way you can choose only the .exe installs that you need, and it will be much easier to justify specific utilities than a humongous system install. If you hunt around on the site you can find the files directory where you can download a single utility, and if you get the -bin.zip version, then you can extract just the needed .exe file which would be even easier to justify and would not require your IT people to test an untrusted install package.
Stupid draconian rules or no, I would not recommend trying to thwart your employers rules. Try working to improve the situation or find another one.
But technically speaking if you can get a complete Cygwin install somewhere, you can copy the entire cygwin folder enmasse. There are a few things that you will want to change similarly to how I configured my cygwin installation to run from a thumb drive. I actually installed on my HD, copied it to the thumbdrive and then changed the batch file and a few other things to make it work. Here are the details: http://fadedbluesky.com/2011/portable-cygwin/
You could try installing it on another machine outside of work. After installing, copy the installed product's tree and Registry keys and environment settings to a CD or flash drive. Then you would have a DIY installation that you can copy and import settings manually. The installer doesn't do a whole lot else.
Don't count on job security if you're bypassing IT mandates after being explicitly told no, though. Getting an exception to the rule by submitting proper documentation through the proper process is usually the way to go.
You'll also have to hope that they aren't blocking the Cygwin programs and any Registry edits as well. It's not hard to find this sort of thing on a machine, either.

%HOMEDRIVE% vs. %ProgramFiles% vs. %HOMEPATH%: When should an Application choose which installation directory?

Some cross-platform packages like Ruby or Qt prefer %HOMEDRIVE% as the default installation path, Google Chrome uses something in %HOMEPATH%. What's the advantage and disadvantage of each choice? What's the best choice for a simple private application (i.e. a game, where the installation should work without administrator rights)? On the other end: What would be the best choice for an industrial application (i.e. a software that controls an industrial device, running on a computer that merely exists for that purpose)?
If you want to ensure your app can be installed without Admin privs, install under %LOCALAPPDATA% - if you want to install system-wide, use %ProgramFiles%. Whatever you do, don't use %ProgramFiles(x86)%.
As a general rule I find it hard to believe that a single installation will work for multiple operating systems. From my understanding it seems that you would need multiple different installation files to handle each of the different file systems (not just installation directory, but the actual file system). This will span not just private, and industrial systems, but all business systems as well. Go to the download page for any software that is available for multiple OS and they will have a link for each one.

Is it safe to assume that the path C:\WINDOWS\system32 always exists?

On OS from win 2000 or later (any language) can I assume that this path will always exists?
For example I know that on win xp in some languages the "Program Files" directory have a different name.
So is it true for the System32 folder?
Thanks.
Ohad.
You definitely cannot assume that: Windows could be installed on a different drive letter, or in a different directory. On a previous work PC Windows was installed in D:\WINNT, for example.
The short answer is to use the API call GetSystemDirectory(), which will return the path you are after.
The longer answer is to ask: do you really need to know this? If you're using it to copy files into the Windows directory, I'd suggest you ask if you really want to do this. Copying into the Windows directory is not encouraged, as you can mess up other applications very easily. If you're using the path to find DLLs, why not just rely on the OS to find the appropriate one without giving a path? If you're digging into bits of the OS files, consider: is that going to work in future? In general it's better to not explicitly poke around in the Windows directory if you want your program to work on future Windows versions.
No, you can't assume that.
Windows can be installed to a different path. One solution is to look for it by calling GetSystemDirectory (implemented as part of the Windows API).
Windows can be installed on a different harddrive and or in a different folder. Use the %windir% or %systemroot% environment variables to get you to the windows folder and append system32. Or use the %path% variable, it's usually the first entrance and the preferred method of searching for files such as dlls AFAIK. As per comments: don't rely too much on the system32 dir being the first item. I do think it's safe to assume it's in %path% somewhere though.
I would use the GetWindowsDirectory Win32 API to get the current Windows directory, append System32 to it an then check if it exists.
It might be safer to use the "windir" environment variable and then append the "System32" to the end of that path. Sometimes windows could be under a different folder or different drive so "windir" will tell you where it is.
As far as i know, the system32 folder should always exist under the windows folder.
Just an FYI, but in a Terminal Server environment (ie, Citrix), GetWindowsDirectory() may return a unique path for a remote user.
link text
As more and more companies use virtualized desktops, developers need to keep this in mind.

Resources