According to USTN Content,
MS_FONTPATH "specifies a list of directories that are searched to locate fonts. Any .RSC, .SHX, or .TTF/ttc file found in any directory in the list is loaded and/or available for use."
According to this Bentley Communities topic,
MS_TTFPATH "specifies the path to the directory which contains the True Type fonts."
These sound identical where true type fonts are concerned, so I defined both of them for my project.
My question is this: Why, with both of these variables defined, do the .ttf files in the support/fonts directory still show up in red?!
In the title of the post and the tags you don't say which version your working with.
You should follow forum best practices and infor us which program and version you're using.
Going to Help \ About will show you that in the form of [ 08.xx.xx.xx ].
Another way is to type in the key-in: version and the Message Center on the bottom will present the version being used.
From the screenshot I believe you're working with some version (v8i?) of Inroads, for that there's a proper forum.
Michael VerHoef said:Why, with both of these variables defined, do the .ttf files in the support/fonts directory still show up in red?!
Because if the fonts that you have inside the directory are from the right side screenshot, they are missing.
You can clearly compare the two screenshots and see that then ones in red are the ones missing from the right side screenshot.
I'm pretty sure that page that describes a MS_TTFPATH is wrong as far as both V8i SS4 and CONNECT Update 12 is concerned. None of the documentation mentions this variable.I ran a test and neither versions of MicroStation would load true type fonts in a directory pointed at by MS_TTFPATH. Both worked using MS_FONTPATH. I'd remove the MS_TTFPATH variable and just use MS_FONTPATH.
(CONNECT Update 14 documentation on font variables is here: https://docs.bentley.com/LiveContent/web/MicroStation%20Help-v16/en/GUID-27E1C7F4-95D2-7D07-16D5-9D3034E2C5FF.html)
That won't fix your issue, for that, i would verify the SUPPORT variable points to the directory you think it does. Verify the font files aren't corrupt (get a clean new copy), and as Jose Pinho points out make sure you have all the font files that match up with the missing ones.
Kevin van Haaren said:I'd remove the MS_TTFPATH variable and just use MS_FONTPATH
I agree: the latter is documented; the former is not.
It's never been clear to me why we need a configuration variable that points at a font folder separate from the Windows fonts folder. All apps, including MicroStation, know to look in the Windows fonts folder to find TrueType font files.
If MicroStation uses fonts from a folder specified by MS_FONTPATH, then no other Windows app can see those fonts. For example, if your corporate drawing standard mandates TrueType font ExoticCorp and you put that font file in MS_FONTPATH, then what happens in, say, Word when you want to use that same font? If you put font ExoticCorp into the Windows fonts folder then all apps can comply with the corporate standard.
Regards, Jon Summers LA Solutions
for us there are several reasons we prefer not installing in Windows mostly because we have workspaces from over a hundred clients, many including their own true type fonts.
Fonts separate from the windows install requirement isn't a full solution to #1 as without requiring admin permissions to install user's can easily copy new fonts into the font folder and make them available to the project. Managed workspaces helps us out here too as it gives us a more flexible permissions system to prevent this.
* many years ago my favorite font substitution issue arose years when some of our users decided to use one of the fonts AutoCAD installed on their system in their Outlook signature. Unknown to them when Outlook displayed that email and the font wasn't installed it would substitute Wing Dings font. So their very pretty e-mail signature was rendered incomprehensible to the receiver. And if the receiver replied back "why is there gibberish at the end of your email" the original sender wouldn't know what they were talking about because the reply would render with the correct font on their system. (I finally had to explain this with screenshots showing what it looked like without proper fonts installed)