This content has been marked as final. Show 114 replies
I'm assuming that you are using the Adobe PDF printer instance when
creating the output from FM. The dropped text issue can sometimes be
resolved by changing the default setting for the printer instance
Graphic > Print Quality to 600 dpi (located under the Printing
Preferences > Layout > Advanced and also under Properties > Advanced >
Printing Defaults > Layout > Advanced - change it at both locations).
This is described in the following technote:
This 600dpi setting only affects the object placement granularity on
the page, not the actual resolution of the objects. There is a magic
number based upon the page-size, font height and the graphic
resolution that causes all sorts of phunnies if you leave this setting
at the default (4000dpi, I think).
Mike - I can try, but it tends to be only longer documents (3-4 pages, so just whipping one up would be tedious) and most of my examples are confidential agreements and contracts. Wait - I probably have an event policy I can post. I'll check.
Arnis - I tried all of the suggestions in your post, and a few more. All of my print resolution settings were either 1200 or 600 dpi; I changed them to 600 across the board. (I should note that I tried a variety of standard and custom PDF settings, including "Smallest File Size," without solving the problem.) No solution.
I updated Acrobat to 7.0.8, one of the few updates not applied to my system. This changed the list of PDF standards from some odd-looking ones that never seemed right to the more usual v4-5-6-7 choices. I'm beginning to wonder if I should totally uninstall all Acrobat files, and perhaps Frame, and do a clean install. (Urgh... this is a relatively new, clean system build overall, done when I updated my entire Adobe suite in February.)
The problem, as nearly as I can tell, lies entirely with Frame. I do some very large and complex PDF output from InDesign and the only problems are ones I create myself. :)
Further ideas much appreciated. I will check for a broken file I can post.
ADDENDUM: I opened one of the first documents I had trouble with, one I finally beat into PDF form but do not recall exactly how (print to a generic PS driver and pass to Distiller, I think.) On attempting to print, I got a Frame internal error: 7204, 6109922 7778420 0. It will not print to PDF. It prints fine to HP PS and PCL.
Then I opened an old but reliable Frame 5 file, a short chapter from a book with some complex formatting (professional references and end notes). Opened, printed... huge swaths of missing text.
Is Frame broken with respect to PDF?
Well, I went to extremes and set all the driver dpi's to 150, and the PDF print resolution to 300.
Solved the problem. For the current doc, anyway; it still crashes the other.
Minor rant: how could this happen with an Adobe app updated to latest spec, printing with Adobe fonts to Adobe PDF (with Acrobat updated to latest specs), on a very "clean" system with fully updated XP and beaucoup resources (2GB RAM, 100's of GB of free disk space)? Huh. (Rant over.)
If I create and tweak a special Frame 7 PDF preset at 300 dpi all around, what am I giving up? Higher image res? It should not affect any vector components including type resolution, right?
Dov Isaac's take on it about 18 months ago was that they couldn't reproduce the bug but were trying. I agree with you that it's crazy it's been around so long. At least now that tech note documents the fix!
You shouldn't need to change anything but the settings Arnis described. They affect the granularity of text placement (nothing to do with graphics), and general feeling was that 300 dpi has no visible effect for almost everyone. Lower than that might. Others may have more info than I do on that.
Thanks, all. A working workaround is better than nothing... but not as good as a fix.
I wish Adobe would stop treating Frame like an unwanted stepchild. What is it with high-powered text-focused page layout apps that lead to their being kept in the closet under the stairs by their owners - Ventura, Sprint, Manuscript and now FrameMaker. *Sigh*. I've come to like InDesign a great deal for shorter work, but it's still not a very capable long-doc or simple-doc tool.
Dov, or any other Adobe people listening in ....
I think there are more than enough people who would be happy to provide sample documents for testing. ;- ) This is not a rare bug; it's depressingly common.
Just as a PS... another work around I've found that works for me is to use my Xerox PS driver to print a ps file and then distill that. May work with other PS drivers too.
All I can offer is a related experience-- I have a 300 page document that would print OK when I printed from FraeMaker, However when I generated a PostScript file and then generated a PDF, I ended up with missing text. Missing means that on a page I would have some text but not what I started with. I fund out that the problem was in the set-up of the postscript printer. Im my case I have Windows 2000 and it allows me to select a printer from the printer list and depending on what printers you have used, may or may not require you to need the Windows CD. What turned out to be the cause of the mising text was the I didn't use the CD or down-load of the printer files needed to install the printer. The second think that was important was that I embedded the fonts used in FrameMaker in Distiller. In my cae these were Type-1 fonts. Once these two things were corrected the missing text no longer occured. Although a lot of people on the forum believe that the only way to generate a PDF is using the Adobe PDF printer, Adobe tech support and the help files will tell you otherwise. Any PostScript printer will work if setup using the printers's installtion software and the one used has the resolution you need (note- you don't need to have a PS printer available to setup a PS printer, no one has an Adobe PDF printer, there is no such printer ever made by Adove). Both the Adobe PDF printer and the PS printer can create a PDF file (PS does require two setps). The resulting PDF is the same. The one thing that the Adobe PDF printer can do is allow you to set the page size to custom (not limited to pater try size of PS printer). And last never stop the generating of a PS file from a book by clicking the "Cancel" button, doing so crashed a Windows NT and 2000 system.
Thanks for the comments, Sherman. I recall that the way I got the first problem doc to print was by printing to a generic PS driver and passing it to Distiller. I installed a generic driver (one of the Xerox DocuColor ones, which I recall having good results from in the make-a-PS days) and it worked... although I had to re-output one page separately.
Better than nothing, it got my agreement off to the party who needs it, and now I get to add my voice to those clamoring for Adobe to fix the real problem here... :P
What I experienced recently (independent of the printer driver software , on both NT4 (with the kernel mode printing system) and XP (with the user mode running stuff)) is that, whenever using TrueType fonts which are downloaded incrementally, it happens that the initial part of the font program (the part containig the Type42 interpreter) is downloaded more than once, which causes the set of glyphs of the previously loaded instances get undefined (i.e. replaced by .notdef) and thus appearing as white space.
I suspect that this is an issue of the Windows GDI, as I never encountered this bug with applacations which generate their own PostScript code, like InDesign.
Suggest that he next time you have a project, avoid using the generic PS driver that MS allows. Even if you do not have a PS printer, get the software for installing what ever printer from the mfg's web site. It does make a difference both in the PDF color output and it corrects other problems that come up. If you have distiller, the Adobe PDF printer will work.
Maybe a little bit late, but I can confirm exactly the same bug as NitroPress described. My configuration:
- Win XP Pro on a P4/3GHz, 2 GB RAM
- Acrobat 3D
- FM 7.2, latest patches applied (but happens with 7.0 as well)
Documents, that have been saved to PDF in February this year without any problems now come out with large blocks of text missing. I've been trying several things (before discovering this thread), including several uninstalls of Acrobat 3D, installation of the original FM 7.2-Distiller (which always seemed to work), re-installation of A3D ...
I haven't been able to recognize any system behind the erratic behavior. FM-Distiller works - A3D 7.0.7 works - 7.0.8 doesn't - (re-install) - 7.0.7 doesn't - FM-Distiller works - A3D 7.0.7 works ... and stops working some hours later...
Interesting enough: I created a PS file using the Acrobat Printer to be distilled on Mac. Same result. The bug definitely occurs on writing to PS, not in distiller.
I've been doing this silly game for about 3 days. Now, after discovering the 300dpi quality solution, A3D 7.0.7 works again. I hope, for more than the next couple of hours.
Nitropress- ran into the same problem weeks ago using FM 7.2 and Distiller 7.x. and was able to solve the problem.
The company I work for has either HP or Lexmark printers, and even a few that do PostScript printing. However, the PostScript printers have never been set up to print asa PostScript printer. When I installed FM 7.2 on a PC, I added a Tektronix Phaser 550J 1200 dpi as my PS printer. In do this I forgot to use HP software and instead used Windows 2000 (in my case) to add the printer. I had no problem with a small FM document. When the document got bigger, I found missing test and throughout the document. I then delated the printer and installed it using Tektronics software from their web site. That fied the missing text.
I know that may people want to generate a PDF directly through FM, but I've been using FM from it;'s first release and find that creating a PS file first and then using Distiller is the best way to be able to control what one gets. Even FM and Adobne support agree. If you think the Adobe PDF printer is the cause, try this suggestion
Sherman - I've tried every possible path from FrameMaker document to PDF, including hand-cranked processes using a variety of PS print drivers and reducing the resolutions to dot-matrix levels. The fix is very hit-or-miss.
Bernd - your situation is similar to mine. I finally got my critical document to print by using a different PS driver (a Xerox RIP, can't recall exactly which model at this moment.) Then I went to print out a companion document a few days later... same round of problems that I could not fix.
So I went to reinstall Frame 6 on my system... and ran into the "too much memory" problem. I reset the virtual memory down to ridiculous levels (100 MB) and still got errors.
So - I installed Frame 6 on my new system, a dual-Opteron monster with not 2GB, but 4GB of RAM. Perhaps it's the better memory management of that system (with Windows XP64) but I had no problem and printed the document (via print to PS and manual processing to PDF) just fine.
Then I zipped up the Frame 6 installation and dumped it on the older system, where it works fine except for the persistent registry warnings - which I'll fix when I have a moment. However, THE SAME DOCUMENT, when saved from Frame 7.2 into v6 format, and opened in Frame 6, caused the same missing-text problems through several approaches.
I might be stating the obvious, but this is a major, major bug and it lies wholly within Adobe's product circle. It should not have existed with the final release or at least should have been fixed early on... yet here we are more than a year into it with no fix in sight (except a crappy, half-effective workaround).
And I have discovered, to my frustration and dismay, that InDesign makes a very poor substitute for Frame when doing long documents. Part of it was unfamiliarity with things like flowing text over multiple pages, but after an hour's work I still had nothing that looked like my relatively simple Frame document... and I had to spend two hours on the above process to get the stupid thing to PDF so I could get it to the client.
I realize FrameMaker is a minor product and an unwanted stepchild, without the glitz, glamor and recognition of Photoshop or Premiere, but really, Adobe... this clusterf*ck is beneath you!
There is a Frame support document online that offers troubleshooting suggestions, at http://www.adobe.com/support/techdocs/329942.html
Also, although I habitually print to a PS file generated by a Xerox 2450 driver and distill that, I've noticed that I have fewer problems if I turn off "Fast WWW view" and set the dpi to less than 600.
I agree with the general thesis however -- this whole area is a major bug that's been dragging on far too long.
Art - Yes, I've seen the Adobe document you reference. It doesn't quite seem to address the real problem, only concatenated problems stemming from the original that can be fixed on SOME systems by mucking with the product versions or settings.
My system was freshly rebuilt from an new OS install up, using all new and current Adobe products including Distiller 7.0 and Frame 7.2 (and nearly everything else they make). Although I verified the steps involved, none of my problem stems from having mismatched or outdated software components. And I think it's something of a fandance on Adobe's part to point the blame that way.
The new, current, supposedly stable apps, free of legacy and third-party issues, are broken. Everything else is window dressing.
just FYI... after it turned out that reducing the pdf/printer resolution didn't cure anything, I found something else which currently works. But as all solutions until now just have been temporary remedies, I'm not sure if it will continue to work tomorrow... but currently I've been able to finish the PDF export of about 20 manuals that refused to do so before.
What I did: once again I deleted all the AdobeFnt??.lst files and (this one was new) additionally the FNTCACHE.DAT file from the Windows/system32 folder. After restarting my PC all PDFs came out as expected.
About ID: I share your thoughts. Things I'm doing within a hour in FM take several hours in ID. This is quite annoying especially during work on early versions of any manual, when infos are changed on a daily basis. Currently I'm working on manuals in several languages, with about 60% of the languages done in FM, the rest is done in ID (was necessary for languages like Arabic). This gives a quite good workflow comparison...
InDesign is just about the most wonderful publication tool I've ever used - each time I learn a new function or feature, it's pretty much how I would have designed it based on 25 years of experience and preference. I wish I'd had something like it ten years ago!
But it's rotten at the long documents and formatted pages that are FrameMaker's strength. I don't know why professional-grade, long-doc tools are forever being left to rot by their makers - Ventura, Manuscript, Sprint, a few others. It's a small but stable market and any software company that gets into it thinking they're going to knock Word out of the box is a gang of idiots. But anyone who gets into it to give a sizeable and specialized base of users that don't want to muck with things like TeX a tool... well, we'll buy every version they make.
If you have the time and interest, perhaps you could start a new thread in which you compare the tasks you do quickly in FrameMaker, and which are more tedious to do in InDesign. This could invite some suggestions for workarounds or different work methods, and also become the basis for product enhancement requests for new InDesign releases.
Additional thoughts-- Have you ever generated a list of fonts and took a look at the page(s) that you have the problems with? Maybe we should have asked if this document was writen from scratch or imported from an existing document or even MS word? I have seen this happen where the imported text looks like it was formated with your document sytles, but you may have missed something (text was using a font from say MS word that is not part of your document). When you create a PDF, the font was not found and and you never embedded it in Distiller, result would be this missing material.
Using Windows 2000 or later (platform that FrameMaker is designed on) seems to work better with FM than Windows XP. Seems that a great number of problems with FM are Windows XP users!
I rarely try to import documents into FrameMaker - there was a time when I used it as my daily word processor as well as for formatting! - but I occasionally do import text from Word. I never leave any formatting in place on such docs and clear everything to "Body" before proceeding with an FM format.
My font set is extensive and I have a few that I use frequently - the Stone family, for example. There should be no font-related issues as I've used these for years in a dozen different apps with no problems.
As for OS, I stayed with Windows 2000 for a very long time after Windows NT got too creaky, and upgraded to XP only when I was forced to by... surprise!... Adobe's requirement for it on the video editing side. XP is hardly a new OS and we are way past the point where it should be causing problems on current-rev software.
I'm not sure whether XP is the real culprit, or if it's just that a majority of users are now on XP... and probably got there by upgrading a Win2K system or by haphazardly applying service packs and updates. Anything but a fresh XP install, with all SPs and updates applied before major software is loaded, is likely cause problems.
yes, of course checking the fonts (documents and system) has been one of the first steps. Like NitroPress, I'm quite familiar with things that *can* happen to a document (I'm working with FM since version 3.1 on Mac and Win), and all documents are as clean as they can be.
The symptoms definitely would be different in case of overridden paragraph formats. At least, it couldn't happen that one day PDF export works flawlessly, the next day it won't, the third day it works for three hours before it stops doing so... all with the same documents.
A great number of problems with XP users? Well, yes, on my Mac I definitely had less problems ;-)
Peter: Yes, a comparison thread could be a good idea. Just let me finish my currently not-so-fluent-but-still-urgent PDF creations (updating *many* manuals)...
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
>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.
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 ;-)
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. :)
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.
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...
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.
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.
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.
> 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.
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.
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?
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.
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