ConTeXt output & commercial printing houses

ConTeXt output & commercial printing houses

[Matt Gushee]

Hello, all--

I am planning to publish a book that is typeset using ConTeXt, and very
soon I am going to start contacting printers for estimates. Given that a
shop prints from PDF files, does it matter that the PDFs are produced by
ConTeXt?

I've never worked with regular printers, but I have taken PDF files
produced by TeX or ConTeXt several times to Kinko's [for the non-US
readers: Kinko's is a shop found all over North America--originally they
were just a photocopy shop, but now they offer a wide range of services,
including computer rental, design consulting, low-end POD printing ...
they do good work within their limits, but their staff are really only
knowledgeable about mainstream commercial DTP software--the notion of
TeX is totally beyond them]. I have found that they can produce good
results, but it seems they have to adjust some settings in their system
and make several attempts before the job comes out right.

Are problems likely to arise with normal printers? If so, can anyone
suggest questions I should ask to help determine whether they can handle
my files? Also, is there anything in particular I should do to my files
to make sure they are print-ready?

Thanks in advance for any suggestions.

-- 
Matt Gushee                 When a nation follows the Way,
Englewood, Colorado, USA    Horses bear manure through
mgushee@havenrock.com           its fields;
http://www.havenrock.com/   When a nation ignores the Way,
                            Horses bear soldiers through
                                its streets.
                                
                            --Lao Tzu (Peter Merel, trans.)

Re: ConTeXt output & commercial printing houses

[Bill McClain]

On Sat, 24 Jul 2004 13:41:38 -0600
Matt Gushee <mgushee@havenrock.com> wrote:

> I am planning to publish a book that is typeset using ConTeXt, and
> very soon I am going to start contacting printers for estimates. Given
> that a shop prints from PDF files, does it matter that the PDFs are
> produced by ConTeXt?

I've only dealt with one print shop (www.bookmobile.com) for my books,
but have never had any problems with pdf files produced by
Context->pdftex. You have to be somewhat self-sufficient, in that if you
ask questions they'll tell you all about the right Pagemaker settings,
etc. Obviously, you should have all fonts embedded. 

Different shops might have different requirements, but Bookmobile simply
requires an exact image of the book, page size defined to be the paper
size. Easy. 

This has all been for digital printing and perfect-bound paperbacks. I
would like to know if an offset press generating folded and gathered
signatures takes the same pdf input. And where to go for sewn hardcovers
in small quantities and short run leatherbound books for "collector's
editions." I haven't explored those issues yet but will do so
eventually.

-Bill
-- 
Sattre Press                                      Pagan Papers
http://sattre-press.com/                    by Kenneth Grahame
info@sattre-press.com          http://sattre-press.com/pp.html

Re: ConTeXt output & commercial printing houses

[Siep Kroonenberg]

On Sat, Jul 24, 2004 at 03:21:39PM -0500, Bill McClain wrote:
> On Sat, 24 Jul 2004 13:41:38 -0600
> Matt Gushee <mgushee@havenrock.com> wrote:
> 
> > I am planning to publish a book that is typeset using ConTeXt, and
> > very soon I am going to start contacting printers for estimates. Given
> > that a shop prints from PDF files, does it matter that the PDFs are
> > produced by ConTeXt?
> 
> This has all been for digital printing and perfect-bound paperbacks. I
> would like to know if an offset press generating folded and gathered
> signatures takes the same pdf input. And where to go for sewn hardcovers
> in small quantities and short run leatherbound books for "collector's
> editions." I haven't explored those issues yet but will do so
> eventually.
> 
> -Bill

The printshops that I dealt with were capable of imposing normally
paginated pdfs into signatures for offset printing. I've never done
imposition myself.

-- 
Siep Kroonenberg

Re: ConTeXt output & commercial printing houses

[Henning Hraban Ramm]

> I am planning to publish a book that is typeset using ConTeXt, and very
> soon I am going to start contacting printers for estimates. Given that 
> a
> shop prints from PDF files, does it matter that the PDFs are produced 
> by
> ConTeXt?

Normally they should be able to process nearly every PDF. ;-)
If you don't need color, it'll be no problem.
If you need color, you must be careful to define everything in CMYK 
mode.
If you use pictures, save them as PDF; include ICC profiles if you need 
-
ConTeXt simply includes the PDFs "as is", so nothing gets lost.

If you like to impose yourself (discuss this with your printer!) you
must need some parameters like preferred size of the printing plate,
folding space etc. Normally you should leave this to the printshop.


Grüßlis vom Hraban!
---
http://www.fiee.net/texnique/

RE: ConTeXt output & commercial printing houses

[Mats Broberg]

> -----Original Message-----
> From: ntg-context-bounces@ntg.nl 
> [mailto:ntg-context-bounces@ntg.nl] On Behalf Of Matt Gushee
> Sent: den 24 juli 2004 21:42
> To: ntg-context@ntg.nl

> Are problems likely to arise with normal printers? If so, can 
> anyone suggest questions I should ask to help determine 
> whether they can handle my files? Also, is there anything in 
> particular I should do to my files to make sure they are print-ready?
> 
> Thanks in advance for any suggestions.

Matt,

Being a newbie when it comes to ConTeXt, but having worked in the
commercial printing busines for a decade, I would say that the majority
of printers actually prefer PDF files rather than Quark, InDesign or
Pagemaker files. At least that is the case in Europe, and it would
suprise me if it is not the same situation in USA.

The reason for this is that the printers get away from all the
associated problems with the DTP program files: typfaces that are
lacking, missing image links, text that may reflow etc.

However, a caveat emptor:

- I don't quite understand how ConTeXt:ers deal with solid PMS spot
colours - i.e. not a spot colour in CMYK mode where the spot colour is
made up of a screened colour mix of cyan, magenta, yellow and black, but
a colour that you want to print with a specially mixed Pantone PMS ink
from an additional printing plate (apart from the four C, M, Y, K
process plates). However, this is frequently done in printing, so it
would surprise me if ConTeXt didn't have a solution for it.

- Also, I don't know whether it is possible to downsample images in
PDF's that you generate from ConTeXt. If it is, avoid it. The printer
expects CMYK images (not RGB!) where the resolution is approx. 2 times
the screen count in the final print, @ the physical size on the paper.
So if you have an image in your PDF that is 10 cms /4 in. wide, and you
want it printed in a 150 lpi (lines per inch) screen, make sure the
original resolution is 300 dpi @ 10 cms / 4 in.

All the best,
Mats Broberg

Re: ConTeXt output & commercial printing houses

[Adam Lindsay]

Mats Broberg said this at Sun, 25 Jul 2004 12:01:03 +0200:

>- I don't quite understand how ConTeXt:ers deal with solid PMS spot
>colours 

Mats, have a look at:
 <http://pragma-ade.com/general/manuals/msplit.pdf>

Disclaimer: I haven't used spot colours yet, but I know it's in a manual. :)

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Adam T. Lindsay                      atl@comp.lancs.ac.uk
 Computing Dept, Lancaster University   +44(0)1524/594.537
 Lancaster, LA1 4YR, UK             Fax:+44(0)1524/593.608
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

RE: ConTeXt output & commercial printing houses

[Mats Broberg]

Yes, I eventually found it in that manual - sorry for using bandwidth
for RTFM issues... :)

Best regards,
Mats Broberg

> -----Original Message-----
> From: Adam Lindsay [mailto:atl@comp.lancs.ac.uk] 
> Sent: den 25 juli 2004 13:59
> To: mats.broberg@arsimprimispress.com; 'mailing list for 
> ConTeXt users'
> Subject: Re: [NTG-context] ConTeXt output & commercial printing houses
> 
> 
> Mats Broberg said this at Sun, 25 Jul 2004 12:01:03 +0200:
> 
> >- I don't quite understand how ConTeXt:ers deal with solid PMS spot 
> >colours
> 
> Mats, have a look at:  
> <http://pragma-> ade.com/general/manuals/msplit.pdf>
> 
> 
> Disclaimer: I haven't 
> used spot colours yet, but I know it's in a manual. :)
> 
> -- 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>  Adam T. Lindsay                      atl@comp.lancs.ac.uk
>  Computing Dept, Lancaster University   +44(0)1524/594.537
>  Lancaster, LA1 4YR, UK             Fax:+44(0)1524/593.608
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> 
> 

Re: ConTeXt output & commercial printing houses: Thanks!

[Matt Gushee]

Thanks for all the responses. I got some very useful information here.

I do have a couple of quick follow-up questions.

On Sat, Jul 24, 2004 at 03:21:39PM -0500, Bill McClain wrote:
> 
> Different shops might have different requirements, but Bookmobile simply
> requires an exact image of the book, page size defined to be the paper
> size. Easy. 

You're referring to just the interior, right? I would think that covers
have to have a bit of bleed, no?

> This has all been for digital printing and perfect-bound paperbacks.

Pretty much what I'm doing for now. As a matter of fact, partly inspired
by your example, I'm attempting something rather similar to your
publishing biz--though not in direct competition, I hope and believe.


On Sun, Jul 25, 2004 at 12:01:03PM +0200, Mats Broberg wrote:
> 
> Being a newbie when it comes to ConTeXt, but having worked in the
> commercial printing busines for a decade, I would say that the majority
> of printers actually prefer PDF files rather than Quark, InDesign or
> Pagemaker files. At least that is the case in Europe, and it would
> suprise me if it is not the same situation in USA.

Well, yes. Many printers here do prefer PDF. However, there's a small
problem in some cases--I know this is true for Kinko's, and was
wondering if it's true for regular printers, too: they think that PDF
means "Adobe PDF"--i.e. they believe that Adobe software is *the* way to
produce PDF, and are mostly unaware that there is such a thing as a PDF
standard. Now, I don't fully understand the issue, but apparently Adobe
software doesn't entirely follow the published specs, whereas TeX does.
And some processing software seems to be designed specifically to work
with the quirks of Acrobat output, and sometimes has trouble with PDFTeX
output.


> - Also, I don't know whether it is possible to downsample images in
> PDF's that you generate from ConTeXt. If it is, avoid it.

That raises an important question: if downsampling is done, is it
obvious what ConTeXt commands cause it to happen?

> The printer
> expects CMYK images (not RGB!) where the resolution is approx. 2 times
> the screen count in the final print, @ the physical size on the paper.
> So if you have an image in your PDF that is 10 cms /4 in. wide, and you
> want it printed in a 150 lpi (lines per inch) screen, make sure the
> original resolution is 300 dpi @ 10 cms / 4 in.

Now that's interesting. I imagined you would get the best results with
images that were designed exactly at the printer resolution.

-- 
Matt Gushee                 When a nation follows the Way,
Englewood, Colorado, USA    Horses bear manure through
mgushee@havenrock.com           its fields;
http://www.havenrock.com/   When a nation ignores the Way,
                            Horses bear soldiers through
                                its streets.
                                
                            --Lao Tzu (Peter Merel, trans.)

Re: ConTeXt output & commercial printing houses: Thanks!

[Brooks Moses]

At 11:15 PM 7/26/2004, you wrote:
>On Sat, Jul 24, 2004 at 03:21:39PM -0500, Bill McClain wrote:
> > - Also, I don't know whether it is possible to downsample images in
> > PDF's that you generate from ConTeXt. If it is, avoid it.
>
>That raises an important question: if downsampling is done, is it
>obvious what ConTeXt commands cause it to happen?

There's, to my knowledge, no engine in pdfTeX for downsampling images; 
there certainly be one coded in ConTeXt.  Thus, I'd be fairly confident in 
guessing that it is indeed, fairly obvious, on grounds that there are no 
commands which do that.

> > The printer
> > expects CMYK images (not RGB!) where the resolution is approx. 2 times
> > the screen count in the final print, @ the physical size on the paper.
> > So if you have an image in your PDF that is 10 cms /4 in. wide, and you
> > want it printed in a 150 lpi (lines per inch) screen, make sure the
> > original resolution is 300 dpi @ 10 cms / 4 in.
>
>Now that's interesting. I imagined you would get the best results with
>images that were designed exactly at the printer resolution.

You might, but that would only be true if you also have the image aligned 
exactly with the printer resolution -- which is unlikely to be the case 
unless you do it explicitly.  Having the 2x-or-higher resolution means that 
the downsampling in the printing process will produce an acceptable result 
no matter what the alignment is.

Beyond that, I suspect there are also some effects involved in the fact 
that the printer is creating a screen rather than dots of pure color; there 
are things going on in the screen that are on a finer scale than the line 
spacing, and having the higher-resolution to base them on probably produces 
a better result.

- Brooks

Re: ConTeXt output & commercial printing houses: Thanks!

[Tobias Hilbricht]

Am Di, den 27.07.2004 schrieb Matt Gushee um 08:15:
>  they think that PDF
> means "Adobe PDF"--i.e. they believe that Adobe software is *the* way to
> produce PDF, and are mostly unaware that there is such a thing as a PDF
> standard. Now, I don't fully understand the issue, but apparently Adobe
> software doesn't entirely follow the published specs, whereas TeX does.
> And some processing software seems to be designed specifically to work
> with the quirks of Acrobat output, and sometimes has trouble with PDFTeX
> output.

This is also true if you want to publish advertisements in journals -
the journals/newspapers often require PDF prepared by Adobe Acrobat /
Distiller. If you provide advertisements prepared by other means then it
is your fault if something goes wrong. This is despite the PDF/X3
standard for preprint ready PDF documents. For this reason the claim of
some commercial TeX-vendors to produce PDF which comes closer to the
"quirks of Acrobat output" is not worth so much in practice.
 
However, when you  prepare documents for print regularly, then it is
anyway best to have "your own" printer locally at hand - somebody you
can trust and who wants to keep you as a customer. Then you can deal
with problems arising and talk about solutions directly.

So far I did not encounter problems with PDFs made by PDFTeX, but then I
gave only documents to print in black and white or with colours where it
does not matter if the red or blue is slightly brighter or darker. I
dont know about printing-experiences of PDFTeX-prepared documents with
colour separation, spot colours, trapping ... in conjunction with
various media (glossy/matte paper ...) where it becomes more difficult.

Yours sincerely

Tobias Hilbricht 

Re: ConTeXt output & commercial printing houses: Thanks!

[Siep Kroonenberg]

On Mon, Jul 26, 2004 at 11:33:03PM -0700, Brooks Moses wrote:
> At 11:15 PM 7/26/2004, you wrote:
> >On Sat, Jul 24, 2004 at 03:21:39PM -0500, Bill McClain wrote:
> 
> >> The printer
> >> expects CMYK images (not RGB!) where the resolution is approx. 2 times
> >> the screen count in the final print, @ the physical size on the paper.
> >> So if you have an image in your PDF that is 10 cms /4 in. wide, and you
> >> want it printed in a 150 lpi (lines per inch) screen, make sure the
> >> original resolution is 300 dpi @ 10 cms / 4 in.
> >
> >Now that's interesting. I imagined you would get the best results with
> >images that were designed exactly at the printer resolution.
> 
> You might, but that would only be true if you also have the image aligned 
> exactly with the printer resolution -- which is unlikely to be the case 
> unless you do it explicitly.  Having the 2x-or-higher resolution means that 
> the downsampling in the printing process will produce an acceptable result 
> no matter what the alignment is.
> 
> Beyond that, I suspect there are also some effects involved in the fact 
> that the printer is creating a screen rather than dots of pure color; there 
> are things going on in the screen that are on a finer scale than the line 
> spacing, and having the higher-resolution to base them on probably produces 
> a better result.
> 
> - Brooks

For a screened picture, you can often get away with less than twice
the lpi, especially if there are no sharp transitions.

On the other hand, pure black-and-white line drawings are best
printed without screening. For such images, higher resolutions are
better. 600dpi is enough for losing jaggies.  Up to a point, more is
better, but printer resolution (2400dpi or more) would produce very
large bitmaps.

-- 
Siep Kroonenberg

Re: ConTeXt output & commercial printing houses: Thanks!

[Bill McClain]

On Tue, 27 Jul 2004 00:15:09 -0600
Matt Gushee <mgushee@havenrock.com> wrote:

> > Different shops might have different requirements, but Bookmobile
> > simply requires an exact image of the book, page size defined to be
> > the paper size. Easy. 
> 
> You're referring to just the interior, right? I would think that
> covers have to have a bit of bleed, no?

For the front and back covers I've just used the interior paper size.
Given a page count the printer specifies the spine width, and perhaps
they allow a little exapansion there?

For the cover I create a single PDF file with the panels joined as so:

    back|spine|front

-Bill
-- 
Sattre Press                                      Pagan Papers
http://sattre-press.com/                    by Kenneth Grahame
info@sattre-press.com          http://sattre-press.com/pp.html

Re: ConTeXt output & commercial printing houses: Thanks!

[George N. White III]

On Mon, 26 Jul 2004, Brooks Moses wrote:

> At 11:15 PM 7/26/2004, you wrote:
>> On Sat, Jul 24, 2004 at 03:21:39PM -0500, Bill McClain wrote:
>>> - Also, I don't know whether it is possible to downsample images in
>>> PDF's that you generate from ConTeXt. If it is, avoid it.
>> 
>> That raises an important question: if downsampling is done, is it
>> obvious what ConTeXt commands cause it to happen?
>
> There's, to my knowledge, no engine in pdfTeX for downsampling images; there 
> certainly be one coded in ConTeXt.  Thus, I'd be fairly confident in 
> guessing that it is indeed, fairly obvious, on grounds that there are no 
> commands which do that.

As a general principle, it makes no sense for pdftex to provide image
manipulation capabilities.  Such capabilities are useful to a much wider 
audience than the users of pdftex, so there are lots of tools to do
image resampling and format conversions.  All that pdftex should do is
support inclusion of pdf.  The limited support for including png images
is a convenience, but if you are being careful you would want to make
pdf images.

--
George N. White III  <aa056@chebucto.ns.ca>
   Head of St. Margarets Bay, Nova Scotia, Canada

Downsampling images in pdfTeX

[Mats Broberg]

> From: ntg-context-bounces@ntg.nl 
> [mailto:ntg-context-bounces@ntg.nl] On Behalf Of George N. White III

> As a general principle, it makes no sense for pdftex to 
> provide image manipulation capabilities.  Such capabilities 
> are useful to a much wider 
> audience than the users of pdftex, so there are lots of tools 
> to do image resampling and format conversions.  All that 
> pdftex should do is support inclusion of pdf.  The limited 
> support for including png images is a convenience, but if you 
> are being careful you would want to make pdf images.
> 
> --
> George N. White III  <aa056@chebucto.ns.ca>
>    Head of St. Margarets Bay, Nova Scotia, Canada

Having checked the pdfTeX documentation, doesn't the internal parameter
\pdfcompresslevel deal with this? The documentation says:

"compress level This integer parameter specifies the level of text and
in-line graphics compression. pdfTEX uses zip compression as provided by
zlib. A value of 0 means no compression, 1 means fastest, 9 means best,
2..8 means something in between. Just set this value to 9, unless there
is a good reason to do otherwise - 0 is great for testing macros that
use \pdfliteral."

Best regards,
Mats Broberg

RE: ConTeXt output & commercial printing houses: Thanks!

[Mats Broberg]

> From: ntg-context-bounces@ntg.nl 
> [mailto:ntg-context-bounces@ntg.nl] On Behalf Of Matt Gushee

> Well, yes. Many printers here do prefer PDF. However, there's 
> a small problem in some cases--I know this is true for 
> Kinko's, and was wondering if it's true for regular printers, 
> too: they think that PDF means "Adobe PDF"--i.e. they believe 
> that Adobe software is *the* way to produce PDF, and are 
> mostly unaware that there is such a thing as a PDF standard. 
> Now, I don't fully understand the issue, but apparently Adobe 
> software doesn't entirely follow the published specs, whereas 
> TeX does. And some processing software seems to be designed 
> specifically to work with the quirks of Acrobat output, and 
> sometimes has trouble with PDFTeX output.

At one of the company I work for, we generate thousands of press-ready
PDF manuals (250+ pp each) every year that are generated from XML source
using XEP from RenderX - with no problems at all. So I don't think it is
a requirement for printers that the PDF files are generated using Adobe
tools.

> Now that's interesting. I imagined you would get the best 
> results with images that were designed exactly at the printer 
> resolution.

True, for line art - but the "exactness" is unimportant. A common
imagesetter resolution is 2540 lpi, so you may want to create your line
art in that resolution. However, most printers prefer 1200 dpi (but not
less) for line art, since images with a higher resolution become so
large (memory-wise).

Regarding halftones (color or grayscale), the commercial printing
community rule-of-thumb is a resolution about 2 times the screen count.
If your image is 10 cm wide on the scanner and you want it to be 10 cm
wide on the paper, and you want the printer use a screen of 150 lpi,
scan it at an optical resolution of 300 dpi. However, as I mentioned
before, this holds true only if the physical image size and the final
image size are the same. If the image is 5 cm wide on the scanner and
you want it to be 10 cms wide on the paper, you need to scan it with a
resolution of 600 dpi.

Never increase the resolution of an already scanned image using software
interpolation.

Regarding using a higher resolution than 2-2.5 times the screen count,
try to avoid it, since the photomechanical laws of process engraving
doesn't give you a better final image anyway. However, pls note that I
am talking about conventional lito offset here, and that I am talking
about a conventional screen technology (amplitude-modulated screening).
If you are using waterless lito offset, the screen count is usually
quite a bit higher (300-500 lpi are not uncommon), which requires higher
resolutions. Also, if you are using a different screening technology -
e.g. frequency-modulated screening, or a hybride screening - your images
may need to be of a higher resolution too. Talk to your printer.

Best regards,
Mats Broberg 

Re: Downsampling images in pdfTeX

[George N. White III]

On Tue, 27 Jul 2004, Mats Broberg wrote:

>> From: ntg-context-bounces@ntg.nl
>> [mailto:ntg-context-bounces@ntg.nl] On Behalf Of George N. White III
>
>> As a general principle, it makes no sense for pdftex to
>> provide image manipulation capabilities.  Such capabilities
>> are useful to a much wider
>> audience than the users of pdftex, so there are lots of tools
>> to do image resampling and format conversions.  All that
>> pdftex should do is support inclusion of pdf.  The limited
>> support for including png images is a convenience, but if you
>> are being careful you would want to make pdf images.
>>
>> --
>> George N. White III  <aa056@chebucto.ns.ca>
>>    Head of St. Margarets Bay, Nova Scotia, Canada
>
> Having checked the pdfTeX documentation, doesn't the internal parameter
> \pdfcompresslevel deal with this? The documentation says:
>
> "compress level This integer parameter specifies the level of text and
> in-line graphics compression. pdfTEX uses zip compression as provided by
> zlib. A value of 0 means no compression, 1 means fastest, 9 means best,
> 2..8 means something in between. Just set this value to 9, unless there
> is a good reason to do otherwise - 0 is great for testing macros that
> use \pdfliteral."

The compression this parameter controls is quite different.  Without 
compression (e.g., \pdfcompresslevel=0) a PDF file consists of almost 
readable text. Even images can be stored in an ASCII encoding.  Setting a 
non-zero value for \pdfcompresslevel applies a lossless compression 
algorithm to objects in the pdf file.

For images that will be displayed only at low resolution it may be useful 
to downsample the original image to reduce the size.  For example you 
might have a 2 inch by 2 inch image scanned at 400 dpi.  This image would 
have 800x800 pixels.  For screen display you might prefer to have a 
200x200 pixel image (or 100 dpi for 2 inches).  Downsampling refers 
to the process of reducing an 800x800 pixel image to 200x200 pixels.
ways to reduce image size (lossy compression, colorspace changes,
even converting certain images to line art).

Some tools to generate PDF include methods to downsample images.
In particular, people who have been using tex-->dvipsone-->distiller 
and are now using just pdftex encounter problems with much larger 
pdf file sizes and excessive load times until they resize the input 
images.

--
George N. White III  <aa056@chebucto.ns.ca>
   Head of St. Margarets Bay, Nova Scotia, Canada

Re: Downsampling images in pdfTeX

[Vit Zyka]

>> Having checked the pdfTeX documentation, doesn't the internal parameter
>> \pdfcompresslevel deal with this? The documentation says:
>>
>> "compress level This integer parameter specifies the level of text and
>> in-line graphics compression. pdfTEX uses zip compression as provided by
>> zlib. A value of 0 means no compression, 1 means fastest, 9 means best,
>> 2..8 means something in between. Just set this value to 9, unless there
>> is a good reason to do otherwise - 0 is great for testing macros that
>> use \pdfliteral."
> 
> 
> The compression this parameter controls is quite different.  Without 
> compression (e.g., \pdfcompresslevel=0) a PDF file consists of almost 
> readable text. Even images can be stored in an ASCII encoding.  Setting 
> a non-zero value for \pdfcompresslevel applies a lossless compression 
> algorithm to objects in the pdf file.

For exactness. Primitive \pdfcompresslevel influences lossless 
compression of
1) content of pdf objects
2) included PNG images (they are decoded and encoded again)

In case of inclusion of PDF, it is put as it is (so compresslevel is not 
changed). JPG is also untouched.

It was valid for pdfTeX version <1.0. I have no info about changes in 
this case.

Vit Zyka

Re: Downsampling images in pdfTeX

[Peter Münster]

On Tue, 27 Jul 2004, George N. White III wrote:

> For images that will be displayed only at low resolution it may be useful 
> to downsample the original image to reduce the size.  For example you 
> might have a 2 inch by 2 inch image scanned at 400 dpi.  This image would 
> have 800x800 pixels.  For screen display you might prefer to have a 
> 200x200 pixel image (or 100 dpi for 2 inches).  Downsampling refers 
> to the process of reducing an 800x800 pixel image to 200x200 pixels.
> ways to reduce image size (lossy compression, colorspace changes,
> even converting certain images to line art).

Quite soon, I'm going to convert the degrade LaTeX-package
(CTAN: graphics/degrade) to ConTeXt. It permits to down-sample JPEG images on
the fly to a given resolution.
Cheers, Peter

-- 
http://pmrb.free.fr/contact/
_____________________________________
FilmSearch engine: http://f-s.sf.net/