Text missing from PDF

[James Gifford—NitroPress]

I am a long-time and very experienced user of FrameMaker, Acrobat, and all associated tools. My XP-SP2 system is thoroughly debugged and fully updated.

When I create PDFs in Frame, sections of the text come up missing. The document remains correctly formatted and organized - there are simply missing sentences, paragraphs, etc. in no discernible pattern. I have tried every fix I can think of and all those I have found by searching online - to no avail.

These documents are created from scratch in Frame 7.2p158; I have updated the installation at least once without solving the problem. The PDFs are being created by every known process: print to Distiller (7.0) within Frame; Save As PDF; print to generic PostScript and pass to Distiller. The missing text remains consistent within all processes.

The fonts involved range from junk of unknown origin to (most of my fonts) true Adobe Postscript. Changing fonts does not cure the problem, although it sometimes changes which parts disappear. There is no particularly complex formatting involved (no equations, no unusual character overrides). These documents are mostly contracts and other simple but rigidly formatted documents. None involve imported graphics.

I have tried all variations of saving to MIF and RTF and re-importing. This sometimes changes the faults, but does not cure them.

This problem occurs ONLY with FrameMaker. I can export perfect PDFs, some from very complex source documents, from Word, InDesign, CorelDRAW and a dozen other tools, using any fonts on my system.

(I am dismayed at how hard Adobe support has gotten to use - as the owner of nine of their most expensive apps, I should be able to get better online support without calling in and begging permission!)

If anyone can point me to a known bug, a known fix, or a good starting point for unraveling this problem - or confirm that they've seen a similar error - I would appreciate it!

[James Gifford—NitroPress]

Sean - I'm not sure what this would fix. In my case, the documents were created using two font families - Stone Serif and Stone Sans. Nothing else. (Oh, Bedrock in a header logo.)

The missing text problem in absolutely no way that I can tell maps to any feature, formatting choice, or other simple thing. Part of a paragraph in Stone Serif will print; part won't. The headings in Stone Sans will print; a disclaimer paragraph in it won't. It isn't even whole paragraphs or headings or sections that fail to print - it's random chunks here and there. It's not even connected to character formats or paragraph overrides.

I have a very solid understanding of Frame and text processing and programming and system operation... and I can't figure out a possible root cause for this problem. I don't feel bad, though. Clearly, Adobe can't either. :P

[Seanb_us]

>I'm not sure what this would fix

Hi. It won't fix anything. I was curious about what would happen and it didn't seem like it'd take too much effort.

Given the randomness of it all, though, maybe that won't tell us anything.

>I have a very solid understanding of Frame and text processing and programming and system operation... and I can't figure out a possible root cause for this problem. I don't feel bad, though.

Please believe I am not questioning that. I'm just thinking about a way to troubleshoot this that has not been tried.

Cheers,

Sean

[_Bernd_Meissner_]

Sean,

since the process has been working yesterday (the whole day) and didn't work again today, I was in the lucky position to check this option, too. No difference, PDFs come out exactly as NitroPress describes.

NitroPress: What just (right in this very moment) *DID* re-enable the creation of correctly written PDFs, was the same thing I already wrote yesterday.

1. PDFs corrupt
2. Delete FNTCACHE.DAT from Windows/system32 folder and reboot
3. PDFs work :-)

... for today ;-)

Bernd

[Seanb_us]

Bernd, what fonts, from where did you get them?

Sean

[James Gifford—NitroPress]

Sean - I wasn't taking anything as an insult, just adding to the data points. I'm willing to try anything - I will muck with various Distiller settings, deleting the font cache, etc. in an attempt to help find a universal fix or workaround.

But not this week. I have one more day of killer logistical effort for a conference I have to drive 400 miles for... and I'm done with FM PDFs for the moment. :)

[_Bernd_Meissner_]

Sean,

Fonts used don't seem to matter. This bug happens with manuals completely based on the Berhold Imago (PS) as well as with completely different manuals, written using the FF Meta (PS).

It's just deleting the FNTCACHE.DAT from the Windows/system32 folder that *definitely* makes a difference. This file is automatically recreated on Windows start, so I get a new one that works for one day.

Bernd

[Art Campbell]

Bernd,
Thanks so much for posting the FNTCACHE.DAT fix/workaround.
Nothing readily visible on the MS site about it. Interestingly, there isn't too much about it or its inner workings. It seems to be recreated in the same size after the reboot, so it must survey the available fonts. Also, apparently some viri writers hide things in it...

Nitro -- Stone Sans is also one of the fonts on my system that may be related. Or it could just be a coincidence...

Cheers,
art

[_Thomas_Michanek_]

> Thanks so much for posting the FNTCACHE.DAT fix/workaround.
> Also, apparently some viri writers hide things in it...

Yup. To quote some conversations on the net:


"...the next day i found a trojan backdoor virus on windows xp with a file it had created called FNTCache.dat.

The FNTCache.dat is merely camouflage, and has nothing to do with fonts (necessarily). Font caches are common system files, and
using them as a place to store viruses or virus data is just a little bit of social engineering on the virus-writer's part to keep
you from noticing they're there. Update your virus definitions and see what your virus checker tells you."


"I am seeing FNTCACHE.dat file in C:\WINNT\system32. Is this a bad file? Can I remove this file?

FNTCACHE.DAT (FoNT CACHE) comes with a clean install of Microsoft Windows 2000 Professional."


Meaning: FNTCACHE.DAT is a legit system file, but it may contain viruses.

[Seanb_us]

But, does this happen with Helvetica, Times, etc? Am wondering if we can get a list of affected fonts.

Hmmmmm ... you might want to change fonts anyway, given the requirement for password-protected PDFs.


You may embed the Font Software into electronic documents for use on computers that are NOT Licensed Computers, subject to the following restrictions: (a) the electronic documents are distributed in a secure format that allows only printing and viewing, and prohibits editing, selecting, enhancing or modifying the text; and (b) the electronic documents are for personal or internal business use. If you are unable to limit access to the document to view and print only, then the electronic document may not be used on computers that are NOT Licensed Computers.

You may embed the Font Software into electronic documents for use on computers that are Licensed Computers provided that the electronic documents are for personal or internal business use.

Without the purchase of an additional license, you may NOT otherwise embed the Font Software. For example and without limitation: (i) You may NOT embed the Font Software into your hardware, software or other products, such as, application programs, electronic games, e-books, kiosks, printers, etc.; (ii) You may NOT embed the Font Software into your web pages; and (iii) You may NOT embed the Font Software into electronic documents that permit editing, selecting, enhancing or other modifying of the text.

[_Bernd_Meissner_]

Art,

are you saying the (semi)fix works for you, too? Well, this could be a hint... maybe it becomes possible to really FIX this thing one day.

Sean,

I know (possible) license restrictions of fonts, but this is definitely the wrong track. All documents *have been working* for years and *still work* after deleting this §$%& DAT file and also still work on other computers. All fonts I'm using allow PDF embedding. So a font could possibly result in a distiller error message or in the not-creation of a PDF, but wouldn't pretend that all is well and create a PDF that's missing random text blocks.

Bernd

[Seanb_us]

Oh, sorry, not what I meant. As an aside I meant that given the requirement that you must password protect your PDFs, you might want to change fonts anyway.

But, I am really wondering if we can get a list of affected fonts.

Cheers,

Sean

[_Bernd_Meissner_]

Sean,

why should this become necessary? A PDF *only* allows editing, if the used fonts are installed on your local system (and thus assumes that you're a licensed user), no matter if you embedded fonts or not. So the license restrictions forbid anything that allows a direct download of the font file, but not embedding within a PDF.

Thomas,

I've been checking the Fntcache files using a HEX editor. Well, I'm not a programmer, but the working and the corrupt version definitely look like a... well... a Fontcache ;-)

The question is: What has the Adobe PDF Printer to do with this special cache file?

Bernd

[James Gifford—NitroPress]

Sean - I don't think it's any one font or family (assuming good quality fonts). I am reasonably sure that I converted a problem document to Times New Roman and had the same missing text problems. Sometimes changing the fonts will change the parts that drop out, but not fix the problem.

If I had to guess, it's related to the Distiller or FrameMaker working space and is caused or exacerbated by large physical or virtual memory spaces. (Tried to install an older version of Frame on a new, big-RAM system? Can't do it!) I suspect a similar glitch is at the heart of this problem - an overlooked bit of code that makes assumptions about the maximum memory size and thus causes overruns on the Postscript font space.

Complete WAG, I admit.

[Seanb_us]

Yup. Am WAGging, too. I was not assuming the problem could only be a Distiller one, though. I wanted to also consider other factors, like seeing if it was certain fonts or not, thus the list.

Cheers,

Sean

[James Gifford—NitroPress]

I don't see how the primary problem could be with Distiller when it works flawlessly with so many other apps, including things like InDesign with very complex pages, and non-Adobe apps not noted for their clean output such as Word and CorelDRAW. I haven't heard of any such problems with anything except FrameMaker. So, you'd have to go a long ways to convince me the fundamental problem doesn't lie within Frame... :P

[Art Campbell]

Berndt & Nitro,

I had a chance to test deleting the font cache file and then generating the .pdf this morning. Worked like a charm on the gnarliest book I have, one that I've never been able to print directly to the PDF printer before -- it always required the Xerox printer driver PS file to Distiller work around.

I don't know why it works, but it certainly seems to be the work around that kills the bug.

Berndt, why did you think of killing the cache file? Just a hunch or something else? I didn't even know it existed...

Cheers,
Art

[_Bernd_Meissner_]

Art,

that's good news and a valuable confirmation. Maybe even Adobe now has an idea where to look at ;-)

How I came to delete this file? Pure despair of crippled PDFs under a deadline... ;-)

I knew that the AdobeFNT**.list files could cause troubles on Mac and should be deleted from time to time. So I just did a search for everything that contains "...fnt..." in order to trash it. Well, not the dlls, of course, but everything that looked like a cache file. Finally the FNTCACHE.DAT turned out as being the only culprit.

Yepp, champagne for all ;-)

Bernd

[Arnis Gubins]

Bernd,

Good sleuthing! Just as a test for your empirical workaround, when you
have the text dropouts, have you tried simply re-booting instead of
deleting the font cache and then rebooting? This would remove one more
variable and add more weight to a possible workaround that others
could use.

AFAIK, there shouldn't be any dependence on the font cache with the
distilling process as you have to explicitly specify where Distiller
has to look for the fonts, i.e. Distiller doesn't use the system
resources to let it know what is available.

[James Gifford—NitroPress]

I might have a chance to try that fix later today and will report my findings back. If it really is The Workaround, serious thanks and kudos to Bernd and all!

[_Bernd_Meissner_]

Arnis,

yes, I just did this test again (although I've done it before for several times). It is reproducible on my PC at 100%.

1. Save book > PDF --- Text missing
2. Reboot, save book > PDF --- Text missing
3. Delete FNTCACHE.DAT, reboot, save book > PDF --- WORKS!

According to my tests, the problem doesn't occur during the distilling process. It happens before, while writing the PS file. I've done that separately ('save to file' option using Adobe PDF printer) and found the PS file to be corrupt as well.

PS file creation *does* use Windows system resources, doesn't it?

Bernd

[Arnis Gubins]

Bernd,

Interesting. Thanks for confirming this.

Yes, you're quite correct that the PS file creation in FM is dependent
upon the system resources.

As far as the difference between printing to file + manually
distilling and the Save As route goes, they are both functionally
identical. The only difference is that the Save As route assumes that
the printer instance is hooked to the PDF port, which triggers a
sequence of events in the background. This process prints the FM files
to a postscript file using the same Adobe PDF printer instance (PS
files are labeled with a .tps extension in this case), calls
Distiller with the joboption specified in the printer dialogue,
deposits the PDF in the specified location, deletes the .tps file when
Distiller has completed creating the pdf and then closes Distiller.

[_sherman_f_watstein_]

A search on MS website finds that the "Fntcache.dat" has only to results. Both refer to removal of MS programs related to MS Office. Doing a web search on "Fntcache does say that for Windows XP to delete this file and reboot.

[Art Campbell]

Just as another data point, I've gone through the same routine with
the same results for several days now. Rebooting without clearing the cache has no effect. Clearing it, though -- still no problems and
repeatable results.

About the fontcache file... It doesn't appear that anyone who's posted
actually knows how it works and why it's there, but logically it makes
sense that if font info is cached, that the cache would be the ready
source of font info for any font-related process. Otherwise why have a
cache -- you'd be reading from the font files....

And the corollary would be that something, somewhere in the system is corrupting or capable of corrupting the cache file in real-time.

Art

[_sherman_f_watstein_]

Can only speak about Windows 2000. I have 2 legal versions of FM one on each PC. Only one currently is used to build PDF's. What I do see on the this file is that the file date is the date my system rebooted and the PC that does the most number of building PDFs has the larger of the two Fntcace,dat files. Opening the file with notepad does appear to show printer font names seen among the ansi text. Will have to check my other two systems at home. I am not willing to delete this file at this time when things work. Windows has always had files that keep the same file size when rebooted but change the date and time stamp. One is the swapfile that can be deleted and rebuilds when PC is restated.

[Guest]

For those of you who want to install an older version of Frame on a new whiz-bang system, I recommend you try Resplendent Resolver. It, ah, lies to your system about all sorts of things such as processor, memory, and version numbers. I use it to run Fontographer on my 2 GB system. Fontographer normally won't run on a system with more than 512 MB, but Resolver solved the problem.

It's freeware.

http://www.resplendence.com/resolver