Installed font not showing up in Font Family Picker

[Sharon_G]

Hi,
I'm a new user in the process of converting FrameMaker files to Flare 4. I'm probably missing something obvious, but I'm hoping that someone can tell me how Flare 4 handles this:

I have the Frutiger font family installed on my computer in the C:\Windows\Fonts directory. This is where Flare appears to obtain the font families that appear in the list of installed fonts (Font Family Picker). The only thing that is different about the Frutiger family is that they are Adobe (.PFM) fonts and not True Type fonts.
Other Adobe fonts also do not display in the list of installed fonts.
Is this a known issue with a workaround/functions as designed/a bug? Any advice is welcome.
Our print documents use Frutiger and once we move to Flare we would like to be able to continue to do so.
Thanks,
Sharon

[KevinDAmery]

I know that Flare has problems dealing with Open Type fonts - not sure about pfm, but it's distinctly possible that's a problem too. I would report it as a bug, which you can do here:

http://www.madcapsoftware.com/bugs/submit.aspx

I seem to recall that back in the day there was a way to convert post script fonts to true type. Not sure if there's anything that would do the same for pfm, but that may be something to look into as a workaround.

[LTinker68]

Also, if you're going to generate online help from the same content then you're going to want to use a different font/font family altogether for online output as Frutiger isn't a standard font and most (if not all) of your users won't have it available. Unless your user base is all internal and you all have Frutiger installed per your company's policies.

[Sharon_G]

Thanks Lisa,
I had already figured out the need for the online output to use a different (more standard) font family. Theoretically that shouldn't be a problem - right?
S.

[KevinDAmery]

Nope - you just have to specify different fonts in your Default medium than in your Print medium in your stylesheet. Very straight forward.

[beelia]

Unfortunately, this is a very important issue for my help system. Frutiger fonts are the "signature" corporate font for my company. They are REQUIRED for all web content.

I tried everything to get the original Adobe fonts to work. I forwarded them to Ryan Cerniglia, who worked on the problem for quite awhile. Meanwhile I converted OTF to TTF, PFM to OTF, searched the web for days, and tried various scripts and kludges I found. Then I tried a little tip that I found mentioning that downloading Microsoft Reader automatically installs Frutiger fonts, and thought I was really onto something when that font did finally show up in the "Installed Fonts".

I then deployed it throughout my help system, but when I output to WebHelp, all of those Frutiger fonts displayed as Times. I had to reset everything to Arial to avoid the very obvious non-compliance with company policy.

Installed Frutiger fonts are displayed in Microsoft Office, so it can't be just a problem with Adobe fonts. It's clearly a bug, and it looks like no one has filed it yet, so I will.

Corporate tech pubs is already ticked off that I'm using Flare, and I just hope it gets fixed by the time my help system goes into wide distribution.

[SteveS]

Hi Bee,

If you create a font family with (for example) Frutiger, Arial, Sans-serif and publish some form of web output, what does the stylesheet with the output say? If it reads the same as the stylesheet you use for Flare I don't think Flare is at fault.

I'm assuming you can view Frutiger with IE (or your browser of choice). If you then open a project created with Flare and using the stylesheet as above what font is displayed? You could also experiment with a 'creative' font set, one with outlandish fonts you wouldn't normally use, to make sure the style sheet is the only thing specifying fonts. It would be frustrating to find font family has been set on the body tag (or something similar) and its the cascade thats foiling your efforts!

[KevinDAmery]

Unfortunately, this is a very important issue for my help system. Frutiger fonts are the "signature" corporate font for my company. They are REQUIRED for all web content.

Hey, Bee - are these publications for internal use or also for outside customers? The reason I ask is, afaik Frutiger isn't shipped by default with any version of Windows, so if you're delivering WebHelp to Windows users or CHM files, you can't guarantee that your customers are seeing the content in Frutiger. (I'm running XP SP3 here, for example, and I don't have any variants of Frutiger installed.) If they're for internal use, it's easier to control, of course.

[Sara D]

Bee: I'm having the same problem using open type fonts in Flare. My situation is pretty much exactly the same as yours. My company using a proprietary font family, Knowledge, for all print documents. However, I can't select Knowledge in the font family picker. I am going to email support now, but I'm afraid my best option is going to be to generate the print documentation in Flare, change the font in Word, and the PDF the document. Way too many steps for my liking.

[LTinker68]

You can try manually entering the font name in the stylesheet file itself. If the font name is actually just Knowledge then you can type it like that. If there are spaces in the font name then you need to put single quotes around it. For instance, font-family: ClassGaramnd, 'Times New Roman', serif;. Note the single quotes around Times New Roman.

[sdcinvan]

I know that Flare has problems dealing with Open Type fonts - not sure about pfm, but it's distinctly possible that's a problem too. I would report it as a bug, which you can do here:

http://www.madcapsoftware.com/bugs/submit.aspx

I seem to recall that back in the day there was a way to convert post script fonts to true type. Not sure if there's anything that would do the same for pfm, but that may be something to look into as a workaround.

Isn't it unbelievable that in five years or more, Flare hasn't considered this OTF compatibility issue important enough to fix?

The Monday, I attempted to change my print and web documentation to our new corporate font. This is a commercial font that is delivered in the superior OTF (aka a ISO/Windows standard since before Windows XP!). I was dumbfounded to discover that Flare could not see this font family! Flare lost major points because of this! FYI, Flare may be the ONLY software, in this genre, and one of the very few Windows programs that is incompatible with OTF fonts. Simply unbelievable!

[sdcinvan]

I know that Flare has problems dealing with Open Type fonts - not sure about pfm, but it's distinctly possible that's a problem too. I would report it as a bug, which you can do here:

http://www.madcapsoftware.com/bugs/submit.aspx

I seem to recall that back in the day there was a way to convert post script fonts to true type. Not sure if there's anything that would do the same for pfm, but that may be something to look into as a workaround.

Isn't it unbelievable that in five years or more, Flare hasn't considered this OTF compatibility issue important enough to fix?

The Monday, I attempted to change my print and web documentation to our new corporate font. This is a commercial font that is delivered in the superior OTF (aka a ISO/Windows standard since before Windows XP!). I was dumbfounded to discover that Flare could not see this font family! Flare lost major points because of this! FYI, Flare may be the ONLY software, in this genre, and one of the very few Windows programs that is incompatible with OTF fonts. Simply unbelievable!

[RamonS]

I dug a round a bit and it appears to be a problem with GDI+, means a Microsoft issue that also applies to Microsoft's own apps. You might try this tool
http://www.microsoft.com/typography/FontValidator.mspx
although I do not know if the results will get you any closer to a fix, I doubt it. Startpage the web for "OTF GDI+" and you will find plenty more people complaining and a few offering a workaround (code). The implications of the code hacks are beyond me, but they might fix this issue and introduce a dozen others. From what I read and understood, the buck stops with Microsoft foremost. MadCap could look into a workaround, but not sure if that will address everything.

[sdcinvan]

I dug a round a bit and it appears to be a problem with GDI+, means a Microsoft issue that also applies to Microsoft's own apps. You might try this tool
http://www.microsoft.com/typography/FontValidator.mspx
although I do not know if the results will get you any closer to a fix, I doubt it. Startpage the web for "OTF GDI+" and you will find plenty more people complaining and a few offering a workaround (code). The implications of the code hacks are beyond me, but they might fix this issue and introduce a dozen others. From what I read and understood, the buck stops with Microsoft foremost. MadCap could look into a workaround, but not sure if that will address everything.

I'm not sure about what you mean by this being a Microsoft problem.
Microsoft Office 2013 fully supports OTF fonts, .Net after 3.5 (via WPF?) supports OTF, and more importantly, all of Flare's competitors support OTF.

[RamonS]

The question is if any of those apps make use of the off the shelf dotnet GDI+ and if yes which workarounds they implemented to make OTF work. I'm not trying to make excuses here, but it appears to me as that fixing this is not as trivial as it might seem and it might only impact a few Flare users.
If you want to push the issue pester MadCap directly. Digging up old posts on the forums clearly makes your point that this issue is around for years, but it has little effect unless you can organize more users to generate a concerted response.
My suggestion would be to use a new forums post and compile a list of users ( a "me too" response is sufficient) to point out to MadCap that this is a major problem that needs a speedy fix. MadCap gets tons of feature requests and bug reports and what have not on a regular basis. The problem is prioritizing what to do first and what will generate a reasonable ROI. I've worked long enough in software development to learn that chasing every bug and every customer complaint is just not possible, even if that means that a customer drops the product and may take the one or the other with her. So the company lost a few customers but at the same time crafted bug fixes and new features that retained or added dozens or even hundreds of users. It really sucks for those who do not get what they need.
Shows again that we really should have one common standard for fonts that works across all systems and apps rather than three or four or five....

[wbrisett]

As mentioned, this is a bug in the .net framework. Since Flare is built on the .net framework it inherits the bug. I know several of the .net developers have been harping on MS to fix this, and to some extent they have. They have fixed .net to work with Microsoft OpenType formatted fonts. So, as it turns out that only the Adobe version of OpenType fonts don't work (actually this was news to me. I didn't realize that Adobe and Microsoft had two different options for OpenType fonts).

The only real workaround is to convert your OpenType font into a TrueType font. This works, but may be in violation of your user agreement with the font company (it definitely is with Adobe typefaces).

Wayne

[sdcinvan]

The question is if any of those apps make use of the off the shelf dotnet GDI+ and if yes which workarounds they implemented to make OTF work. I'm not trying to make excuses here, but it appears to me as that fixing this is not as trivial as it might seem and it might only impact a few Flare users.

It isn't a question of whether or not it is trivial solution but whether or not it is necessary. My conservative estimate is that MadCap has had a minimum of five years to correct this flaw. Other products (including some competitors) have fixed this problem, near zero budget shareware and open source products fixed this problem (or never had it). Given that no other competitor (or near competitor) product suffers from this flow, there is no excuse for MadCap!

If you want to push the issue pester MadCap directly. Digging up old posts on the forums clearly makes your point that this issue is around for years, but it has little effect unless you can organize more users to generate a concerted response.
My suggestion would be to use a new forums post and compile a list of users ( a "me too" response is sufficient) to point out to MadCap that this is a major problem that needs a speedy fix. MadCap gets tons of feature requests and bug reports and what have not on a regular basis. The problem is prioritizing what to do first and what will generate a reasonable ROI. I've worked long enough in software development to learn that chasing every bug and every customer complaint is just not possible, even if that means that a customer drops the product and may take the one or the other with her. So the company lost a few customers but at the same time crafted bug fixes and new features that retained or added dozens or even hundreds of users. It really sucks for those who do not get what they need.
Shows again that we really should have one common standard for fonts that works across all systems and apps rather than three or four or five....

You are absolutely correct. I am still a bit bewildered that this is not a big issue for more Flare users. Prior to Flare, I spent ten years in the world of Adobe FrameMaker. If FrameMaker could not use OTF fonts, the users would have gone insane! FrameMaker has been able to use just about every font format in existence since it began counting.

I'll say this, it is a good thing I didn't find out about this until now because if I knew five months ago that Flare was only compatible with the antiquated TTF fonts, I would have laughed the product off and erroneously assumed it wasn't a serious competitor to Adobe FrameMaker. In publishing, fonts are often an important part of branding.

Anyhow, I'll post a message to the group (like you suggested) and see what happens next.


Thanks for listening,
Shawn

[wbrisett]

You are absolutely correct. I am still a bit bewildered that this is not a big issue for more Flare users. Prior to Flare, I spent ten years in the world of Adobe FrameMaker. If FrameMaker could not use OTF fonts, the users would have gone insane! FrameMaker has been able to use just about every font format in existence since it began counting.

First, FrameMaker has it's own legacy code issues to deal with, but that said, the other is it is not built upon .net framework, which Flare is. The bug is in the .net framework. Second, FrameMaker is pretty much a PDF and print tool. If you want to build web, or other help, you either go the WebWorks route or RoboHelp in conjunction with FrameMaker.

That's not to say this isn't an important thing to fix, but this is a Microsoft issue. Madcap in this case has two choices. One is to find some workaround to the bug (such as writing their own font selection tool instead of letting the framework deal with it), or work with MS to see what their plans are on fixing this issue. I would suspect that if I were making decisions, I would try to see what plans if any MS had fix the problem rather than rewrite things from the ground up and then possibly have that break when an update or OS change came about.

Wayne

[sdcinvan]

You are absolutely correct. I am still a bit bewildered that this is not a big issue for more Flare users. Prior to Flare, I spent ten years in the world of Adobe FrameMaker. If FrameMaker could not use OTF fonts, the users would have gone insane! FrameMaker has been able to use just about every font format in existence since it began counting.

First, FrameMaker has it's own legacy code issues to deal with, but that said, the other is it is not built upon .net framework, which Flare is. The bug is in the .net framework. Second, FrameMaker is pretty much a PDF and print tool. If you want to build web, or other help, you either go the WebWorks route or RoboHelp in conjunction with FrameMaker.

That's not to say this isn't an important thing to fix, but this is a Microsoft issue. Madcap in this case has two choices. One is to find some workaround to the bug (such as writing their own font selection tool instead of letting the framework deal with it), or work with MS to see what their plans are on fixing this issue. I would suspect that if I were making decisions, I would try to see what plans if any MS had fix the problem rather than rewrite things from the ground up and then possibly have that break when an update or OS change came about.

Wayne

Hello Wayne,

I am not so sure this is a Microsoft problem (I think you are referring to a very old .Net v 3.5 or earlier problem). I own Visual Studio 2010 an, over the holidays, created a test program that used a text type box and called the Windows font selector. In C#, I had no difficulty selecting and typing with an Open Type font. Besides, if Microsoft was still at fault (after about 2006), where are all the other Windows programs that cannot use Open Type Fonts? Besides Flare and Snagit, I have not found another Windows program that cannot use OTF fonts.

Take care.

[wbrisett]

MS did fix the .net limitation, but only with MS OpenType fonts, not with Adobe OpenType fonts (also as I recall, Flare is still using an older version of .net). It's possible that what we really need here is for MadCap to simply update the version of .net, but that's not a trivial thing.

[sdcinvan]

MS did fix the .net limitation, but only with MS OpenType fonts, not with Adobe OpenType fonts (also as I recall, Flare is still using an older version of .net). It's possible that what we really need here is for MadCap to simply update the version of .net, but that's not a trivial thing.

I fully understand that it isn't a trivial fix but the point is, MadCap Flare has had five years to work on this fix and NONE of their competitors have a problem with OpenType Fonts. Simply put, it is a ridiculous FAIL for this type of product. However, I seem to be in the minority so there isn't much point in complaining any further.

[wbrisett]

I fully understand that it isn't a trivial fix but the point is, MadCap Flare has had five years to work on this fix and NONE of their competitors have a problem with OpenType Fonts.

As far as I know, none of the "competition" is using .net either.

I am curious though, what is the competition? Word? FM? RH? DITA? ... each of these has their own set of issues. There isn't a 'perfect' solution out there.

[RamonS]

DITA is not an application, but that aside, I agree. I think FM does both the Adobe and Microsoft style OpenType fonts. But why two proprietary implementations anyway? The blame here goes as well to Microsoft as to Adobe. Some applications use workarounds based on online reports and while that may fix the issue it may cause problems in the long run.
I find it weird why some TWs are insisting on using this very specific font that exists on their computer and a few others within the company, but nowhere else. Unless you embed the sometimes rather large font files into your output the users will see a replacement font anyway. Go with Arial or Times Roman instead and call it a day. Users are way more interested in the content than if the font designed by marketing is used. They have better things to do than compare the help docs with the cut sheets and say "Ha! They used inconsistent fonts! I will call them up and ask for my money back!"

Come on, folks, focus on what actually matters!

[sdcinvan]

I fully understand that it isn't a trivial fix but the point is, MadCap Flare has had five years to work on this fix and NONE of their competitors have a problem with OpenType Fonts.

As far as I know, none of the "competition" is using .net either.

I am curious though, what is the competition? Word? FM? RH? DITA? ... each of these has their own set of issues. There isn't a 'perfect' solution out there.

The competition? I was using that term loosely and I should add that the 'competition' doesn't really matter considering that Flare should... plain and simple - support OTF because fonts are important and OTF is a Windows standard. But to answer your question, the most direct competition that even MadCap admits to is Adobe's FrameMaker. I was lured to Flare (from FM) and the sales pitches were geared to demonstrating how superior Flare was to FM. Of course, typesetting features were never discussed; not .

Of course it is rare to find a perfect tool... no, it isn't true that perfect tools do not exist. Anyway, that isn't a valid excuse for Flare.

[sdcinvan]

Go with Arial or Times Roman instead and call it a day....
.... Come on, folks, focus on what actually matters!

OMG, with all due respect you don't seem to understand the importance of branding. Sure, I agree that from my perspective, as a writer, the content is what matters. But branding is also important and, as a writer, it is very important that I comply with my company's branding standards.

Have you have worked for a large corporation? There is no way it would be acceptable to output a public facing document in a non-standard font. Even font kerning, colors, images, language, grammar, specific nouns, image placements, etc... are all important and must meet corporate standards set in their style guides.

Yes, fonts are always embedded in both PDF files and web sites so that there is consistency.

Does the customer care? Not usually or specifically, but there is a subliminal component where the consistency/the branding becomes familiar and trusted. Look at customer facing documentation or website details of VMware, Microsoft, Cisco, IBM... well actually most companies; some companies even employ a branding evangelist to police public facing content.