MS_FONTPATH vs. MS_TTFPATH

Hi Michael,

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.

Regards

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.

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.

1.  installing in windows makes all the fonts available in all client workspaces. User's would use wrong fonts (on purpose even, "because it looks better") for clients all the time.
   1. User's are very unclear on the concept that when you send work back to a client that doesn't have your font installed someother font is substituted, usually with different character widths*
2. Installing in Windows requires admin permissions, setting up new users on projects would mean installing fonts for them, delaying the process as an admin is found to do it.
3. Installing fonts at the OS level affects the whole OS, a corrupt font can be very difficult to find when it's screwing up many of your apps, not just MicroStation.
4. Many of our clients seem to provide us with identically named font files, but are they actually identical? Modified versions of the open font license Bitstream Vera fonts seem particularly popular.
5. When working with external clients ProjectWise managed workspaces allow us to make sure even externals have the correct font set without the admins on their side getting involved as well.

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.

Big Tangent:

* 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)