Flare's PDF output is a mystery (something chgd from v9-v10)

[sdcinvan]

Hello all,

I am trying to solve a mystery that appears centered with Flare's PDF output.

I am using a Cloud based collaboration tool called Crocodoc. Crocodoc accepts PDF documents and converts them to HTML5 in order to allow real-time commenting and annotations.

Recently, I noticed that any document published by Flare will no longer render. In other words, they all fail with an error. I have checked that all applicable (i.e. security) PDF settings are turned off in the publishing Target. I don't think there is anything else that needs checking.

I tested a very simple 4 page Flare published document:
- Crocodoc - fails
- Zoho - fails
- Box (takes a very long time and renders a error ridden preview)

To confirm that this problem is specifically related to Flare v10.1, I tested the following:

- If I print (to PDF) any of the Flare published PDF documents, the resulting 'fresh' PDF will preview in the aforementioned Cloud tools.
- This wasn't a problem in previous versions of Flare; in fact, the last working document was in January 2014.
So I tested this... thankfully, I still have Flare v9.12 installed
I opened and published all my documents (unchanged) in Flare v9.12 and they all successfully uploaded to the aforementioned Cloud apps.
Then I created a simple one page (using custom css) and line line of text and published to a PDF (45kb) and Flare v10 failed, while Flare v9 worked.

I think that experiment suggests a problem with the Flare v10.x PDF publishing engine.

[sdcinvan]

When I need to post a review doc to Crocodoc, I need to close v10.1, open v9.x and do my build, close v9.x and then re-open v10.1. Yeah... this problem is beginning to get really annoying. I reported it to MadCap support.

I must be the only MadCap Flare user that I utilizing Cloud document collaboration. LOL

[ToddPh]

I must be the only MadCap Flare user that I utilizing Cloud document collaboration. LOL

You might be the only one for now, but your system might solve a serious issue for me.
I will be awaiting your solution almost as eagerly as you are.

[sdcinvan]

... your system might solve a serious issue for me.
I will be awaiting your solution almost as eagerly as you are.

What is your serious issue?

[ToddPh]

That I have SMEs who want editable copies of my PDF output so they can mark it up, and I have nothing but headaches trying to produce Word versions for them. "Serious issue" really being "minor irritation that is repeatedly raised" but something I want to find a solution that people will use.

So I went out to Box and signed up for a free account. I then uploaded a PDF document that I had just built in Flare 10.1.0. I was able to open the PDF without any errors from Box. I was searching for Crocodoc and the resulting site tells me that Crocodoc is now Box API, sooooooo... I notice that the basic API wasn't allowing me to edit the PDF without opening it in my locally installed copy of Acrobat (not what you described and also not what I hoped to find) so I looked through the apps they support and found NotablePDF which did permit online editing and previewing of PDFs.

I'm not disputing the issue you are seeing with the change from Flare 9 to 10 as far as the PDF output is concerned, but on a fresh account with Box I cannot reproduce the problem. Could there be some outdated files in your Crocodoc installation? Are other people seeing similar behavior from different computers?

[sdcinvan]

Found the problem!

After learning that Madcap support was able to publish my sample project (on Crocodoc) without incident. I figured out what the difference was between my setup and Madcap support's setup.

When I publish my docs, I am using a commercial OTF [Postscript based] font family (part of our corp branding). When Madcap support published my sample doc, Flare defaulted to the alternate Calibri TTF font.

Code: Select all

body
{
	font-size: 11pt;
	font-family: 'Proxima Nova Rg', Calibri, sans-serif;
	font-variant: normal;
	font-style: normal;
	font-weight: 100;
	/* letter-spacing: 0.12%; */
	color: #404040;
	line-height: 1.3em;
	max-width: 100%;
}

As I mentioned earlier, the whole Crocodoc problem only recently appeared. The change is that Flare v10.x now supports OTF fonts. However, it seems apparent that there is a problem with Flare's support for OTF because the PDF format isn't quite right when an OTF font is present.

I have not tested other OTF fonts so perhaps the problem is isolated to just Postscript based OTF fonts? However, as far as my company's fonts are concerned, this problem is purely Flare related because I tested the font with Microsoft Word and several Adobe products (one, being a competitor to Flare). Only Flare produces a 'broken' PDF. But the question I have is... what exactly is broken?

Nevertheless, it is a problem and I have no workable solution except to remove the OTF fonts and explain to my marketing team that Flare can't work with our chosen documentation standard font.

Any thoughts?

[ToddPh]

Possibly check with the creator of the font to see if they have an updated font package? Seems very odd that the problem would be from the font itself if it can build properly on your local computer but fail when uploaded. Perhaps a chat with Crocodoc support is also in order if you haven't already.

[sdcinvan]

Possibly check with the creator of the font to see if they have an updated font package? Seems very odd that the problem would be from the font itself if it can build properly on your local computer but fail when uploaded. Perhaps a chat with Crocodoc support is also in order if you haven't already.

But Todd, it isn't a problem with the font. Rather it is specifically a problem with Flare. As I mentioned, the font poses no issues with any other application. Additionally, I just tested an unrelated font with similar characteristics and it too fails in this same manner.

Some further testing....

The problem is specifically with Madcap Flare and its recent support for OTF fonts. This is how I arrived at this conclusion:
- Changing the embedded font to TTF only, the published PDF uploads to Crocodoc without incident.
- It is not the OTF font. I have also tested this particular OTF font with other publication tools, including Microsoft Word and Adobe Framemaker; there were no issues.

Other facts:
- PDF files appear to function normally. It is only when I upload to Crocodoc-like apps when the problem manifests itself.

Additionally, some other tests that I have done:
- Opened the malfunctioning PDF into Acrobat (no apparent issues)
> Saved as optimized with all discard options turned on plus I ran the sanitize option. The new saved PDF still failed to upload.
> Removed ALL text and saved a blank page. Still failed to upload to Crocodoc
> As a verification, I created a PDF page (from clipboard) with Acrobat and saved that (one line of font using OTF font) - This successfully uploaded to Crocodoc.
> VERY INTERESTING...using Acrobat to CONVERT the problem PDF to eps and then eps back to PDF - This PDF uploaded successfully to Crocodoc.
BUT there is something 'wrong' with Adobe Acrobat's conversion because it only converts the first page back into a PDF.

I also tried converting to other formats (i.e. Word) but the conversion back is not perfect. So, that isn't an option.

Conclusion, as long as the PDF originated in Flare, it will fail to upload to Crocodoc. However, converting the document to .eps and then back to a PDF seems to have stripped away the 'bad' stuff. Unfortunately, converting to .eps is not a workable solution because Acrobat will only convert back the first page.

1. What I am trying to learn is what exactly is causing the upload and conversion error?
2. Is there a PDF validation tool and might identify what is causing this conversion problem?
3. What is removed/changed that fixes the problem when the PDF is converted to .eps and then back to PDF

Thanks

[techwriter31]

Not exactly related to the problems you're experiencing, but we've noticed some other font issues for our PDFs between Flare 9 and Flare 10.

Here's what we've noticed:
Humanist is a TTF that we have been using since Flare 6 for the front covers of our PDFs. We switched to Humanist because there was a bug in Flare (36093) that prevented us from using "Frutiger 67 Bold Condensed" TTF, and we had to find one that was a close match. (I believe this bug was fixed in Flare 7, but by that point, we decided not to switch back.)

In Flare 9:
We're specifying Humanist for the front cover title --> MS-PGothic is incorrectly being embedded in the PDF --> Japanese characters can be displayed in MS-PGothic --> Acceptable.

In Flare 10:
We're specifying Humanist for the front cover title --> SimSun is incorrectly being embedded in the PDF --> Japanese characters can't be displayed in SimSun (typically used for Chinese translations) --> Appear as MS Mincho --> Unacceptable (apparently MS Mincho is the default Windows font that is used for Japanese, but is considered to be a very undesirable font for Japanese translations).

Our workaround was to change the front cover fonts in our Japanese style sheet to use IPAPGothic instead, and all is well.

[sdcinvan]

Not exactly related to the problems you're experiencing, but we've noticed some other font issues for our PDFs between Flare 9 and Flare 10.

Here's what we've noticed:
Humanist is a TTF that we have been using since Flare 6 for the front covers of our PDFs. We switched to Humanist because there was a bug in Flare (36093) that prevented us from using "Frutiger 67 Bold Condensed" TTF, and we had to find one that was a close match. (I believe this bug was fixed in Flare 7, but by that point, we decided not to switch back.)

In Flare 9:
We're specifying Humanist for the front cover title --> MS-PGothic is incorrectly being embedded in the PDF --> Japanese characters can be displayed in MS-PGothic --> Acceptable.

In Flare 10:
We're specifying Humanist for the front cover title --> SimSun is incorrectly being embedded in the PDF --> Japanese characters can't be displayed in SimSun (typically used for Chinese translations) --> Appear as MS Mincho --> Unacceptable (apparently MS Mincho is the default Windows font that is used for Japanese, but is considered to be a very undesirable font for Japanese translations).

Our workaround was to change the front cover fonts in our Japanese style sheet to use IPAPGothic instead, and all is well.

Interesting. I too noticed something like this back in v10.0. It was on a new doc/new css and the font was mysterious changed from Calibri to Minion. Since I needed to assign my Proxima Nova font, I didn't pay much attention to this strange switcharoo... but I do recall that Calibri was in the css as the only font.

Perhaps not exactly what you experienced.

[wbrisett]

Since you are doing this as part of a review for comments, have you thought about having two targets? One for publication and one for internal review? In the internal review don't use the custom font, and use the custom font for the final publication target. Seems to me that would be a suitable workaround for now since one would hope they are reviewing the content mostly. I'll also do some testing. I have a couple of scripts that parse PDFs. I'll see if when I add PS OTF fonts to a PDF if I can parse them with the script. That will at least tell us if the problem is in the PDF output from Flare or how CrocDocs is reading in the information.

Wayne

[wbrisett]

I would be very interested in getting a test document you couldn't parse via crockdocs. My testing shows no difference in the ability to parse PDFs using my scripts. While this doesn't prove much other than crockdocs is using some other tool to parse, I do find this interesting that you can't parse using it when using a PS OTF font.

[sdcinvan]

PROBLEM SOLVED

I still believe that something in the way Flare handles OTF fonts *might* be a bit wonky. Remember, only Flare was writing a 'bad' PDF.

However, in a last effort to solve this issue this is what I did and what I observed.

1) I removed the Proxima Nova font family but despite doing so, the folder still had two 'corrupted' but unused copies of an italic font. They refused to remove so I had to boot into Win7 SAFE mode to remove.
2) After complete removal of the Proxima Nova family. I reinstalled Proxima Nova *BUT* from a different repository (oddly, this other OTF font set is slightly larger per font).
3) Once installed, I tested with Flare, published and uploaded to Crocodoc SUCCESSFULLY. Yeah!

I don't have anymore time to test but the questions remain, was it one or more of the following issues:
a) Flare has a problem handling some OTF fonts or cannot error correct (the way other programs do) for marginal fonts or font errors?
b) Was it the two corrupted fonts in the Windows/fonts folder?
c) Was it the slightly different OTF fonts that I am no longer using?

Anyhow, I am a very happy camper now.

[ToddPh]

I'm glad you found the solution Shawn. Seems like there was an issue with the font, at least your installation of it.

I'm only teasing a little. Unfortunately I didn't check back over the holiday (for us) weekend or I would have clarified. Our company went to an OTF last year with our most recent branding change and I had to talk with the creator of the font several times. Flare 9 was hit or miss with OTFs and the one we'd chosen was a miss as far as Flare was concerned. The font creator was intrigued by that since he'd done everything according to the standard. He was kind enough to provide me with an older TTF version of the same font for no charge, and also updated his OTF version to correct the issue in Flare.

I read your list of troubleshooting steps (excellently done, btw) and found myself thinking "it's the font" through most of it. There were a couple steps that started to shake my resolution, like creating a new file with a few lines of text and having it work. Did that one perhaps not use the italic? That would make sense since you mention the italics wouldn't uninstall.

I'm glad you got it fixed and that you shared your experience with us. Wish I'd been more helpful. I do agree that Flare's handling of OTF is a bit wonky, but I think that lies more heavily with .NET.

[wbrisett]

Shawn did send me a PDF that had issues in crocdocs. I was able to parse it without any issues using some scripts I developed using Ruby... actually, I wrote a very simple one based on some previous work for this, it simply parses the text on each page and displays it. What that tells me is the PDF objects on each page are correctly defined. Looking closer at the text properties also tells me that the fonts are correctly defined on the page. There were a few minor things that were not parsed correctly, but that could be due to the way the text was placed on the page (the pages numbers didn't have spaces between them, and in one place in the footer where there was a '1.5', it showed up as '1.' Not sure of the problem there, but otherwise things seemed OK.

Anyhow, seems he was able to resolve this, which is good since I couldn't see a difference in the PDF samples he sent me.