🚀 go-pugleaf

This Problem happens with Office applications (GDI), esp. MS Word is notorious for it.  AFAIK somebody will not get a poorer PostScript using a resolution of 300 or 600 dpi. Only the TrueType to Bitmap Conversion renders to this resolution. I think you described the problem pretty well; a solution could be some PS-Code placed in the Startup-Folder of the Distiller.

To my knowledge this is not an OS problem but a general Windows GDI problem. PSCRIPT on Windows NT has it, but AdobePS 5.2 seem to work around it. 

It's a known problem, however, that GDI under some circumstances has a problem with rendering some fonts at higher resolutions than a magic limit of 1440 dpi (I suspect this is due to some sideeffects of the internal TWIP unit used by Windows). 

Why do you need a higher resolution than 1200 dpi? Is it because you have Type 3 fonts that render as bitmap images and you need a higher resolution to render them properly? 

If so this is exactly where you run into trouble.

Thanks for your time.

If it is a "known problem with GDI", do you happen to know where I can find
more info on it? I failed to find anything related to this in the Microsoft
Knowledge Base. I have to come up with a good explanation, and, if possible,
with a workaround that ensures all text appears ok.

The problem is not that I (personally) need resolutions of 1200dpi and
higher. The app we have written is not graphics-intensive, and TrueType as
bitmaps is a very bad idea in the first place. In practice, there are 2
problems:
(1) The app prints some forms for taxes which are sent to the
administration, so missing text is really bad. The administration doesn't
care why the text is missing, and explanations like "I forgot to change the
resolution" or "blame X or Y" will not be accepted.
(2) The app has "Create PDF" capabilities, using Distiller. Problems begin
when a user installs Acrobat 5, because Distiller defaults to 1200dpi. Of
course the user can switch to 600dpi, but (a) (s)he must be aware of this
workaround and (b) usually will do this only after zillions of tech support
calls.

A solution would be to create your own driver and acrobat setup with fixed PPD- and .joboptions-files.

The previous post sounds like the quickest and most straightforward solution. A more complicated attempt (which may or may not work) is to apply a hairline stroke to each character. 

Regards,
 Victor Lee.

SaGS, 

Sorry, but I can't find the documentation on this 'resolution' issue. I believe I found it in an answer from Leo Chen (MS) at one of the various newsgroups at MSDN some time ago. 5D (the JAWS interpreter before the merge with Harlequin, now Global Graphics) also had a tech. note that described the issue, but they also (as I remember it) focused on some subtle stuff with regard to the version parameter in the PPD file that described the printer properties for MS PSCRIPT. 

To my knowledge this problem is all fixed by AdobePS 5.2 (for NT4 or newer). I'm not so sure the same accounts for Win98 etc. 

I will second 'mgww' and recommend a custom rollout of Acrobat 5.0, where the 'Distiller Printer' only has one possible resolution setting (and perhaps define new fixed page sizes) and the system registry is modified so the pointer to your preferred .joboptions file is set as new default (if eBook isn't suitable). 

The requirement is knowledge on the PPD 4.3 specification and knowledge on setting up a custom install script for Acrobat. 

I'm not much of an install script wizard, but writing a modified PPD file is quite easy.

Thanks to all for their effort.

Since I'm writting the affected program, it's more simple for me to ignore
the resolution set up in the "Print" dialog box, end force 300dpi to 600dpi
(depending on what the printer supports).

However, in the meantime I (think I) found a better solution. The
ExtTextOut() function, when passed a proper clipping rectangle and the
ETO_CLIPPED flag, is not affected by this bug. (This workaround can be used,
of course, only by program authors, not by end-users.)

I'll be gratefull if someone can point me to some documentation on this bug
(like an article in MSKB); especially because I found the above-mentioned
workaround by trial and error, not by actually descovering where the bug is
located (and I'm affraid it can reapper in other conditions). I will check
Jaws System's site too, and search again MSKB and news.microsoft.com.

Be careful when using this flag with Type 1 fonts. 

Type 1 fonts and TrueType fonts does have different y-insertion points and may render differently within the clipping regions. 

You may see that some characters from a Type 1 font is clipped somewhere between the lower bound of the x-height and the lower bound from the full height according to the point size (I don't know the english expression for this, in Denmark we call it 'Kegleh�jden' � hope this helps :-) �, which is an expression for the height of the old full-height of the led types used 30 years ago) � simply because Type 1 fonts usually are offset a bit down compared to TrueType fonts at print time (yeah, another GDI issue, I suspect). 

I'd avoid such clipping if I possibly could for portability reasons even though I know that apps like MS Word and especially MS Excel does this in some situations. I can guarantee you that such clipping is a royal pain if your documents ever is passing by a prepress work flow. In addition, the PDF file size will grow considerably because of quite a few extra, completely unneeded objects. 

Take care and good luck. 

Jacob Sch�ffer
 Grafikhuset

Thanks for the additional info, I'll keep this in mind. Currently, the app
uses only core TrueType fonts (Arial, Times New Roman, Wingdings, Symbol)
and calls GDI to measure the text (returned text metrics and string
width/height seem ok, even for those strings that exhibit the problem I
described). In need arrives, maybe passing a large clipping rectangle, like
one that covers the whole page, will work. (Note that I don't pass a
clipping rectangle because I actually need to clip the text, but to avoid
that GDI computes one, because here seems to be the problem.)

As for the PDF file, not only it will be correct (all text there), but it
will be a bit smaller too - if I make the GDI call as I described, guess
what: NO "rectclip" is generated in the intermediary PostScript file.

Interesting. 

I'll write this behind my left ear! 

- Jacob