The PDF list is a service provided by PDFzone.com | http://www.pdfzone.com __________________________________________________________________
Gary, Even though you do NOT use a proper destination device as printer instance for printing out of MS Access, I suspect you're a victim of the totally brain-dead Windows GDI. No more, no less! Dov Isaacs from Adobe has pointed you in the right direction. However, the overall information given may not be complete - at least not as I see it. To fully understand what happens you need to accept the fact that neither MS Access nor *any* MS product (I know of) can draw 'true' lines with a 'true' stroke at all. Yes, you might be able to *define* 'a line' and set a linewidth as you please in MS Access, but that is unfortunately NOT the same thing as *getting* 'a line' with a 'true' stroke on output! And it's definitely *far* from getting (from a technical stand point) what you see in a MS based 'Print Preview'. The fact is that a 'line' may not be a line afterall. Rather, most often with MS products, it's a fill! It's a very thin rectangle with *no* stroke at all. "Why is it so?", you might ask. I don't *really* know *why*, and I've always wondered *why* though I've learned to live with. A reason could be that vendors of display adaptors through a decade has focused on using 'polygon fills' to draw everything to the display for speed reasons, and that the Windows GDI - with some adjustment for resolution differences - port 'what you see' directly into the printer driver without thinking just a tiny bit about the difference between 'strokes' and 'fills'. Boiled down, the reason for your problem is the Windows GDI that simply doesn't draw the lines you ask for 'as lines'. Hence, the advice about installing the "Creo Distiller Assistant" is not likely to help you the slightest. Yes, it WILL help you with hairlines defined as 'strokes', but it doesn't take what both you and other normal human beings will view as a 'line', but in the technological sense is a 'fill' in the real world, into consideration. If you're lucky you'll get a close match to the 'Print Preview' if you select a proper destination device and set a proper output resolution on print. In that case Windows GDI does it's best to implement a 'pixel-snap' routine that should (often, at least) draw your hairlines as one pixel wide filled rectangles *at device resolution*, which works perfectly well in most cases, where the resolution defined in the job *exactly* match the physical device resolution on a traditional laser printer (which is quite low and therefore WILL render the hairline - though defined as a fill - in a visible state). This also explain why you likely will see the result you expect when you investigate a hardcopy from your HP printer, but doesn't when you use an equivalent data stream for PDF creation. In that case you might encounter that such fills disappear, completely unmotivated, from some positions on your page, simply because this pixel-snap functionality decides that 'this fill is too narrow to render' or 'this fill is wide enough to pass on'. But that's one thing. Another of similar importance is how many applications actually draws a table via Windows GDI in the real world. Often, the cell border lines are drawn first (as filled rectangles for each line representing a border edge), then the 'insideness' of the cell is filled with a fill colour (if no colour is selected you'll most often get 'white' whether you want it or not), and finally the text is drawn (and perhaps clipped by the Windows GDI function 'DrawText' - see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/fontext _0odw.asp for details - because the DT_NOCLIP flag deliberately is NOT set properly to ensure WYSIWYG in your MS Access forms designer module). Because of huge overall tolerances in numeric values with Windows GDI or minor mismatches between what GDI expects and what an application provide to GDI, you'll often see that a filled insideness of a cell actually cover parts of the cell border 'line' (*very* common with e.g. MS Excel). In such cases such a border 'line' may become invisible, simply because it's hidden behind the cell contents it was intended to frame. PDF-life ain't easy. If you need PDF's you can trust in suitably small file sizes, you simply cant use ANY Windows GDI printing application to create them. You'll need to use your own PostScript driver, since neither MS nor Adobe offer one with suitable functionality to handle the here mentioned discrepancies, and may not be able to as long as Windows GDI works as it does. Anyway, overall it's pretty sad that a rectangle - defined via Windows GDI and the PostScript driver on Windows - that *could* have been defined as a simple, single object with a fill property and a stroke property, in the real world 2003 actually ends up in the PDF as five objects total, namely four rectangles that represent each of the border lines of a cell, and one that represent the cell fill (which, on top of everything and as a bottom-line effect, often is misplaced so the border lines visually seem to have non-equal thickness or perhaps completely disappear). Oh, what a waste of all the good intensions! Best regards Jacob Sch�ffer DTP/Technical support -------------------------------------------- Grafikhuset (House of Graphics) Fures�vej 16 DK-3520 Farum Denmark Tel: +45 7011 0999 Fax: +45 4499 7020 Web: http://www.grafikhuset.dk http://www.grafikhuset.net/international Grafikhuset is a full service prepress centre offering * Imaging * Desktop publishing of any kind * Web design and automation * Advanced PDF workflow set-up and tools * Prepress troubleshooting * Education and training * PostScript programming * Specialized software for the Graphic Arts industry -----Original Message----- From: Dov Isaacs [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 13, 2003 7:53 PM To: [EMAIL PROTECTED] Cc: Wong, Gary A Subject: Re: [PDF] PostScript Directly To PDF (Not Using Standard Adobe PDF virtual printer) The PDF list is a service provided by PDFzone.com | http://www.pdfzone.com __________________________________________________________________ Gary, As you are hopefully aware, PostScript is not really device independent. In the general case, you cannot assume that PostScript generated correctly for a LaserJet 5siMX (using your example) is capable of being distilled without error. And in fact, PostScript for the LaserJet 5siMX is for a PostScript language level 2 grayscale device; Acrobat Distiller is a PostScript language level 3 color device. If you had color images, there was a good chance they would have ended up in grayscale in your PDF file. Anyway, you were lucky and also, without intending to, demonstrated what your REAL problem is. The problem is not Acrobat 5 or Acrobat 6. Nor is it the virtual printer (the "Acrobat Distiller" or "Adobe PDF" PostScript printer driver instances, respectively) itself. What IS the problem is how Microsoft Access is interacting with the PostScript driver based upon "device resolution" of the "current device." The LaserJet 5siMX PostScript printer driver instance reports itself to Windows and subsequently to the application (Microsoft Access) as a 600 DPI device. The "Acrobat Distiller" or "Adobe PDF" PostScript printer driver instances default to 1200 DPI. What is probably happening is that Microsoft Access is "printing" a one unit wide (either a 1/600 inch or 1/1200 inch) line via GDI to the PostScript driver yielding the OK line with the LaserJet 5siMX driver and the "skipped" (probably an exceptionally thin) line for the "Acrobat Distiller" / "Adobe PDF" driver. The workaround is to use the driver settings I have been recommending for a few years now -- 600dpi for either the Acrobat Distiller or Adobe PDF PostScript printer driver instance. Those settings are fairly well buried in the printer properties. You need to set both the "default" and the "preferences" and tunnel down to the "layout" tab and then the "advanced" button and then to the resolution setting. By the way, there are other circumstances in which real hairlines get into PDF, usually via AutoCAD. They use the PostScript construct "0 setlinewidth" which results in a comparable PDF construct which calls for a single pixel linewidth, regardless of the resolution. At 4800 dpi for example, that linewidth is 1/4800 of an inch, hardly if at all visible. There is a workaround from Creo that you can download from their site (after registering) call the "Creo Distiller Assistant" which consists of Distiller startup files to automatically detect and fix such problems (and a number of other similar annoyances!). - Dov At 8/13/2003 09:22 AM, Wong, Gary A wrote: >I have Acrobat 6.0 Pro. The standard virtual printer does not generate >the pdf file correctly of my MS Access output. Both Acrobat 5.0 and 6.0 >has this problem in generating hairline vertical lines and horizonal >lines. They skip sometimes. > >I have tried a test case of printing the MS Access to a post script >file and running the distiller (It works)!! > >I used a HP 5SI MX PS printer selection and printed to file. Then open distiller and created the pdf file. > >What I need is a way of automatically generating the pdf file when I >print my MS Access program. > >On my current technqiue, this is happening: > >1) Printing to a file, the system prompts me for a filename. >2) It writes to some location. >3) I use the distiller and locating the post script file and open it which generates my pdf file. > >I am looking for a way of generating the pdf file just by printing to >some virtual printer and the pdf file is generated. The default virtual >printer doesn't work for my MS Access application completely. > >Can anyone help me with this!!! > > >Your help is deeply appreciated. Thank You. > > >Gary To change your subscription: http://www.pdfzone.com/discussions/lists-pdf.html To change your subscription: http://www.pdfzone.com/discussions/lists-pdf.html
