Acrobat 8/8.1 Dropping Text in PDF

[Dov Isaacs]

Jacob,

Good to hear from you.

(1) No, I wasn't referring to "leading" but rather the
exact positioning and amount of space between text characters
on a line of text. Obviously 72dpi is going to look very
poor. I normally recommend a setting of 600dpi for all
layout work (and then always creating PDF with the Adobe PDF
PostScript printer driver instance set to 600dpi) to assure 
no reflow problems - a big problem with Microsoft Office and
probably much less of a problem with FrameMaker (Shlomo says
he has seen this; I haven't so far). I do not advise going
below the 300dpi setting. For most FrameMaker type documents,
any fine spacing quality loss at 300dpi compared to 600dpi
or 1200dpi would normally be quite acceptable.

(2) So far we haven't seen the NUMBER of fonts as the key
variable as to what causes corruption or too large a
font cache file. As I have indicated in early communications,
my systems routinely run with about 1400 to 1600 active 
typefaces, all concurrently installed.

One area that I would have others look at is the size of
the virtual memory file. Disable automatic paging files
and enable a constant paging file size of at least twice
the amount of real memory in the system which in reality
means a four to six gigabyte paging file. I am only 
speculating about this, but you never know.

(3) With regards to the GDI calls, FrameMaker's code still
uses very old (Windows 3.x) GDI calls that are very resolution
dependent and that can yield multiplication results that 
overflow 16 bits if you are talking about higher resolutions
and larger page sizes. As I indicated there is a known problem
due to these overflows that cause text drop out on systems
that don't suffer from the problem fixed by the font cache
deletion hack. (For example, this problem is consistent on
all systems for page size "tabloid" for 2400 dpi for the
same document!) The other problem occurs when this overflow
should not be a problem. The problem is that the GDI calls
used by FrameMaker are not really being maintained by Microsoft;
it's likely that there are bugs that have infested that area
of the code that are somehow tickled by FrameMaker and its
interesting remapping of character sets. But we really don't
know what is causing the problems.

(4) Because we can't debug problems we can't reproduce,
this whole issue is exceptionally frustrating not only to
the limited number of customers who repeatedly experience
it on particular computer systems, but also to the FrameMaker
support and development organization.

	- Dov


 

> -----Original Message-----
> From: Jacob Schäffer [mailto:js at grafikhuset.dk] 
> Sent: Thursday, June 21, 2007 6:05 PM
> 
> Hi Dov,
> 
> Normally I don't argue your statements, but sometimes 
> exceptions exists and require a tiny dialog:
> 
> You wrote:
> < ... Lowering the resolution down to 300dpi only affects 
> microspacing for line justification. >
> 
> 	First, I'm not completely sure what you mean when you 
> say "line justification". My mistake, but if you mean 
> "leading" I don't think of this as a problem. However, if you 
> mean "character spacing" I don't believe your statement is 
> entirely correct.
> 
> 	In my judgement lowering resolution (in printer 
> properties, which I assume you refer to) to anything less 
> than 1200 dpi WILL affect character spacing output from 
> FrameMaker. If you try with 72 dpi and compare the result 
> (e.g. in a PDF) with a similar 1200 dpi result I'm sure 
> you'll agree. Often, but not always, you'll find serious and 
> very visible spacing artifacts in the 72 dpi result.
> 
> 	Hence, generally I'd hold my horses and keep resolution 
> up, at least to 600 dpi.
> 
> You wrote:
> < We have heard of customers experiencing it on some systems 
> but not others using "allegely" the same document and 
> configuration. We have even seen internally at Adobe, but 
> cannot reproduce it at will. >
> 
> 	I have worked with this issue weeks and weeks to find a 
> reasonable and reproduceable scenario, since several of our 
> Grafikhuset Publi PDF customers ask us for advice. 
> Unfortunately, we haven't found a bullet-proof answer so far. 
> The best we have to answer is 
> 
> (1) Reduce the number of fonts to a minimum.
> 
> (2) Delete the FNTCACHE.DAT file and reboot.
> 
> You wrote:
> < Note however, I have heard of at least one system for which 
> this hack did not work. Why does this happen? And why does 
> deleting the font cache fix it? Don't really know! >
> 
> 	We have tested with a debugger and tried to nail down 
> memory leaks in FrameMaker. No *significant* such beasts seem 
> to exist with FrameMaker. Bravo!
> 
> You wrote:
> < It has nothing to do with Acrobat or the Adobe PDF 
> PostScript driver instance. >
> 
> 	This problem has definitely nothing to do with Acrobat 
> nor the Adobe PDF PostScript driver instance. It occur during 
> PostScript creation via a combination of GDI, GDI+ and the 
> universal Windows PostScript printer driver -- system 
> components each of which are very hard to point out as direct 
> offenders.
> 
> 	And the problem -- when it's present -- occur whenever 
> you print directly to a physical high-res device, PostScript 
> or 'Save as PDF'.
> 
> You wrote:
> < Since application programs, including FrameMaker, do not 
> and cannot directly access the FNTCACHE.DAT file, I can only 
> guess that whatever is causing this is the byproduct of 
> FrameMaker having its own character set and of its use of old 
> Windows GDI calls for display and print. >
> 
> 	Hmmm ...
> 
> 	Typical for Windows GDI calls are the differences in 
> resolution between display and print. That is, in fact, a 
> major -- if not the only major -- difference between the two 
> device contexts, by concept.
> 
> 	So, why can FrameMaker display stuff it can't print at 
> any resolution? And why does lowering resolution sometimes 
> help? I don't know, but I'd love to.
> 
> You wrote:
> < Note that from our experience, the number of fonts on a 
> system doesn't seem to be a common vector for this problem to 
> occur. I typically have more than 1400 typefaces installed 
> oncurrently on each of my systems and for better or worse, 
> I'v never been able to duplicate the problem on these systems! >
> 
> 	Sorry, but I'd be quite surprised if you personally 
> produce anything significant in FrameMaker, i.e. build from 
> scratch/work with hundreds and hundreds of pages spread out 
> in multiple chapters forming a book. Opening documents on a 
> test basis may not reveal enough information to establish 
> beyond doubt what's going on.
> 
> 	In my view the strict cause is pending and -- 
> apparently -- unknown, and that is a serious problem.
> 
> You wrote:
> < We will need to see whether the next major release of 
> FrameMaker resolves the problem once and for all!  :-) >
> 
> 	I wish you folks at Adobe a good hunt added all the 
> luck you can get -- for all of us :-)
> 
> - Jacob
> 
>