PDF/X Frequently Asked Questions

of January 2002. By Martin Bailey

• Senior Technical Consultant, Global Graphics
• Chair, CGATS SC6
• Chair, ISO/TC130/WG2/TF2 (PDF/X)

Published here: 04. march 2002.

Article contents

Why do we need another format? Isn't PDF enough?
What can I do in PDF/X that I can't do in PDF?
When to use PDF/X?
Why is PDF/X better than a job options file?
Why is PDF/X better than pre-flighting?
What's this about different PDF/X standards?
What about color managed workflows?
When PDF/X-1 was published?
What's PDF/X-1a?
What's PDF/X-3?
Tell more about PDF/X-2
Which PDF/X to use?
Who's developing these standards?
Why don't these standards come out faster?
Acrobat makes PDF/X files, right?
Isn't PDF/X raster only? It's just a wrapper for TIFF/IT isn't it?
Can PDF/X do duotones?
Who's accepting PDF/X-1a files, and how?
And who's taking PDF/X-3?
Constructing pre-press workflows with PDF/X
Where can I get more information?
I'm an application developer – what should I develop for?
How can I get involved?

Why do we need another format?
Isn't PDF enough?

PDF/X is not an alternative to PDF, it's a focused subset of PDF designed specifically for reliable prepress data interchange.

It's also an application standard, as well as a file format standard. In other words, it defines how applications creating and reading PDF/X files should behave.

Back to Contents

What can I do in PDF/X that I can't do in PDF?

Nothing. The important point is that you can do a lot of things in PDF that are not appropriate for graphic arts use, and that can cause problems when outputting for high quality reproduction.

»PDF/X« can be thought of as a shorthand way of specifying most of what you need to tell somebody in order for them to create a file that's likely to print correctly when they send it to you, even if they don't understand the details of what it's doing for them.

Phrased slightly differently, think of all file formats used for file transfers as being compromises between flexibility and reliability (where reliability is defined as the final printed piece looking like your own proof).

At one end of the scale are application files like QuarkXPress documents. You can change those in whatever way you like if you have the application. Unfortunately the receiver of a file can also change them accidentally rather too easily, and the results you get when printing are dependent on many factors in the environment in which that copy of XPress is running, such as fonts, PPDs and printer drivers.

At the other end of the scale you have copydot scans. Those will print absolutely as you expect, given the necessary provisos about having been prepared for the correct resolution and calibration – that's part of why they are inflexible.

In between, in order of decreasing flexibility and increasing reliability, other options at other positions on the scale include PostScript, EPS, PDF, PDF/X and TIFF/IT. When I use a name like 'PostScript' in that list I mean the format in an otherwise unspecified way. It's always possible to push such a format towards the reliable end of the scale by using appropriate software to create it. In northern Europe many people use ProScript, which limits the options used in EPS files. A 'ProScript EPS' file might be placed on the scale somewhere between PDF and PDF/X.

Appropriate use of pre-flight tools on PDF can give you a 'reliable PDF' much closer to where PDF/X is on that scale. The point of PDF/X is that it gives you a convenient and well specified label to use when asking for such a 'reliable PDF' file.

Back to Contents

So when should PDF/X be used?

Every transfer of files from one place to another, whether it's between designers sitting at adjacent desks, or from an ad agency to a magazine publisher, has an optimal position on this compromise scale, and there's a file format appropriate to that optimal compromise.

In some cases there will be additional selection pressure for a specific format, e.g. for compatibility with other processes, but as a general rule the optimal compromise for the supply of print-ready files between organizations will be toward the reliable and less flexible end of the scale. On the other hand, those two designers at desks next to each other would be crazy to use anything but native application documents.

That doesn't mean ads and other print ready files should be sent as copydot files – that's too inflexible for most general transfers, although there are some instances where it's the right thing to do (typically between publishers and print sites).

For most inter-company print-ready transfers where the sender and receiver do not have a strong relationship in place, or where there's no intention of holding planning meetings for each job submission, either TIFF/IT-P1 or PDF/X will probably fit the bill best. That's why the 2001 edition of the SWOP specification recommends the use of those formats for digital delivery.

Back to Contents

Why is PDF/X better than a job options file?

Over the last few years a number of people who receive PDF files have developed an approach that can work well under some circumstances. They save a set of job options in Acrobat Distiller, and send that to their clients. When files are created by relatively unsophisticated users it's far more likely that they will meet the receiver's quality requirements using such job options than they would otherwise.

The main drawback of this approach is that it requires all files to be created using Acrobat Distiller, and cannot help those people who want to use the increasing number of desktop applications that can export directly to PDF (Adobe Illustrator, PhotoShop and InDesign, MacroMedia FreeHand, etc.), or alternative PostScript to PDF conversion tools, such as Agfa Apogee Create or Jaws PDF Creator (Editors note: or the Grafikhuset developed Colour Chameleon product, which drive Acrobat Distiller to produce as compliant files as Distiller possibly can output. Please see Acrobat makes PDF/X files, right? later in this article. Jacob Schäffer).

It also cannot be applied to the high-end graphic arts tools that can generate PDF directly, like Creo Brisque, Dalim TWiST, or OneVision Solvero, although one might expect that the users of such equipment should understand the process well enough not to need such help!

A second, and rather minor, consideration is that a new job options file must be developed for every new version of Distiller.

It's also worth noting that the implications of some of the options available in Acrobat Distiller can be quite subtle, making it rather difficult for an individual company to develop the best possible configuration. On the other hand PDF/X has been developed over a period of several years by a broad-based team of users and vendors.

Back to Contents

Why is PDF/X better than pre-flighting?

An alternative approach that has also been used successfully by some companies receiving PDF files is to work with their customers to encourage them to apply appropriate pre-flight checks before sending files. When the sender and receiver both use the same pre-flight tool it is sometimes possible for the receiver to supply a configuration file (e.g. a ground control for Markzware FlightCheck) – with care this can eliminate a large proportion of problem files.

If the two parties involved are using different pre-flight tools, however, an explanation of the checks that should be made by the sender can be very complex.

As more and more pre-flight tools are released with pre-built PDF/X configurations already available these explanations can be significantly simplified.

Note that PDF/X files should still be checked before transmission for all of those issues that cannot be addressed in a standard, such as the trim area and CT and LW image resolutions.

Back to Contents

What's this about different PDF/X standards?

Most publishers make their specifications for ad delivery available to ad agencies and prepress houses. These include page sizes, bleed allowances, number and types of hard copy proofs to be sent alongside digital files and file formats that will be accepted. Once a publisher is confident that they have the tools to handle PDF/X files they can simply add it into that list. No further technical discussion should be required in order to make a suitable file for delivery. Obviously commercial discussions are a separate matter. This is known as »blind exchange«.

Blind exchange is also appropriate for some other parts of the print market - it will fit well wherever an exchange should be kept simple, or a single file is to be sent to many places to be printed. There are, however, situations where it's necessary to for the sender and receiver of a file (or file set) to have more discussion about how data should be prepared and exchanged. I'll refer to that as a non-blind exchange through the rest of this document.

The original intent of the PDF/X standard was that it be split into two. PDF/X-1 would be a file format for blind exchange, where all technical information and content is held within one single file and nothing needs to be supplied alongside it, while PDF/X-2 would be a format for more open, non-blind, exchanges.

Back to Contents

What about color managed workflows?

During the development of PDF/X-1 it became clear that some market sectors require exchanges with all color data already converted to CMYK, while others are better served by transferring data in other spaces, such as CIELab or RGB with a profile attached. A number of publishers and ad agencies in Switzerland and Germany, for instance, have joined together to form the European Color Initiative (ECI) to develop workflows for delivering ads in RGB or Lab.

Pre-conversion to CMYK works best where there is a clearly defined CMYK color space to convert into. Remember that a set of CMYK values do not specify a particular color until you also define what device it's being printed on – the same CMYK values printed on gravure, flexo, or offset litho presses, or on a laser or ink jet printer are likely to look quite different. In the US publication market most printers are attempting to standardize on the SWOP specifications, and the US newsprint market is converging on SNAP. Thus an ad prepared for SWOP or SNAP is likely to produce the expected colors in most magazines or newspapers. Specifications like SWOP or SNAP are described as »characterized printing conditions«.

Other sectors of the print market are more difficult to characterize – many commercial printers, for instance, pride themselves on squeezing a larger gamut or better print contrast out of their presses than their local competitors. A wide range of paper stocks, in different colors, textures and coatings, obviously adds to the kind of color variation you'd see from the same CMYK values. A number of groups such as GRACoL and CGATS, are cooperating to determine whether it's possible to generate characterizations for commercial print. In the meantime it's a little difficult to provide a file in CMYK to a commercial printer and have your proof match the final printed piece off his press without significant discussion or on-press adjustments.

The rise of non-impact digital presses, based on either ink jet or laser technology, also makes it difficult to send CMYK data without knowing exactly what press it will be run on, because presses from the different manufacturers will print the same CMYK values as different colors.

It's in this context that PDF/X-3 was developed.

Back to Contents

So when was PDF/X-1 published?

The first PDF/X standard published was PDF/X-1:1999, approved by ANSI as an American National standard in October 1999 (ANSI/CGATS.12).

As indicated by the PDF/X-1 designation, it's intended for blind exchange. At that time magazine and newspaper publishers and those commercial printers considering such blind exchanges in the US believed that files must be converted to CMYK (plus spot colors) for reliable delivery, so that's what PDF/X-1:1999 requires.

As you'll be well aware, there is constant development and improvement of software, hardware and workflows in the graphic arts. The use of PDF is no exception.

PDF/X-1:1999 was based on PDF version 1.2, so a new version, based on PDF 1.3, was developed. This was approved as PDF/X-1:2001 in April 2001, and published in December 2001 as an International Standard (ISO 15930-1:2001). As you can see, PDF/X-1 followed the same path as TIFF/IT which was released first as an American standard and then further developed and released as an international one.

This standard defines two specifications, or conformance levels, PDF/X-1:2001 and PDF/X-1a:2001.

Back to Contents

What's PDF/X-1a?

During development of the first (1999) standard it was felt that it was important to provide a mechanism for associating data such as images in other file formats with the main file. This was achieved using a variant of OPI where the other files are completely embedded within the PDF/X file. Experience with PDF/X-1:1999 in the real world showed that the need for associating other files was not as great as had been thought, and that including OPI like this in the standard made it a much bigger job to support PDF/X. That reduced the number of tools available, and pushed them towards the higher priced end of the market.

The 2001 ISO standard therefore defines both PDF/X-1:2001, which is an updated equivalent to the ANSI PDF/X-1:1999, and also PDF/X-1a:2001, which prohibits OPI entirely. PDF/X-1a also prohibits encryption of files.

It's expected that many more tools will be available for handling PDF/X-1a files than PDF/X-1 because they are much easier to produce.

Back to Contents

What's PDF/X-3?

PDF/X-3 is a superset of PDF/X-1a:2001. The main difference is that color managed data may be included, rather than all data being restricted to CMYK (and spot colors). The same PDF/X-3 file may contain data in color managed color spaces (such as Lab, CalRGB or using an embedded ICC profile), and other data in Black and/or CMYK. The combination means that images can be included in a defined RGB space (for instance), while solid black text can be guaranteed to print in solid black without unexpected color fringing caused by color management spreading the black data to all the process separations.

PDF/X-3 is expected to be approved as an International Standard in Spring 2002 (ISO 15930-3:2002).

Back to Contents

Tell me more about PDF/X-2

PDF/X-2 is still under development in CGATS – an incomplete document is expected to be released as an International Specification (rather than an International Standard) in the Summer of 2002 (ISO 15930-2:2002).

PDF/X-2 is designed to address exchanges where there is more discussion between the supplier and receiver of the file. Maybe the receiver already holds high resolution images to replace proxy images (low resolution previews) in the supplied file.

It will be a superset of PDF/X-3, and will allow device independent color spaces, like Lab and those based on ICC profiles, to be used, just like PDF/X-3. 

Back to Contents

Which PDF/X should I use?

That's obviously quite a few different PDF/X standards, but it's expected that any particular market will settle on one, or two at the most, of these. For ad delivery and catalog work in the US PDF/X-1a will be the obvious choice.

The same ads in Europe might be sent as either PDF/X-1a or PDF/X-3.

The commercial print and packaging markets worldwide will be best served by PDF/X-2.

Work for output on digital presses, especially in anything approaching a blind exchange environment, would probably be best sent as PDF/X-3.

If you already have a workflow that's working reliably and efficiently then there is probably no immediately compelling reason to switch to using PDF/X. You may find, however, as new versions of your tool set are released, and especially when you find yourself needing to work with and educate new partners – clients or service providers – that it is simply easier to standardize on an appropriate conformance level of PDF/X.

Back to Contents

Who's developing these standards?

With apologies for the alphabet soup – the PDF/X standard is being worked on by a number of organizations:

The work was started by Subcommittee 6, Task Force 1 of the Committee for Graphic Arts Technical Standards (CGATS SC6 TF1) at the request of the DDAP Association (Digital Distribution of Advertising for Publications) and NAA (Newspaper Association of America). CGATS has been tasked by ANSI (the American National Standards Institute) to generate standards for the graphic arts in the USA.

CGATS SC6 officially covers digital advertisement exchange, but that doesn't mean that PDF/X is only useful for ads – the committee recognized that they should make the standard more general and have deliberately not limited it in that way.

The active members of the CGATS task force have varied slightly over time, but have included the following companies and organizations over the last couple of years of the development: Young & Rubicam, Western Laser Graphics, Webcraft Direct Mail, Vertis, Time Inc., RR Donnelley, Quebecor World, NPES, Noosh, Newspaper Association of America, Kraft Foods, Iris Graphics, Hewlett Packard, Heidelberg, Graphic Communications Association, Global Graphics (Harlequin), Fuji Photo Film, Eastman Kodak, DuPont Color Proofing, the DDAP Association, Dainippon Screen, Creo, Barco, Apago, Agfa, Adobe Systems.

PDF/X-3 has been developed by the Swiss and German representatives to ISO, with additional funding from BvDM (the German printers' association), UGRA/EMPA (the Swiss standards and research institute) and IFRA (the international newspaper organization), and active support from the ECI (European Color Initiative) and FOGRA (the German printing research institute).

At the international level PDF/X work is done by the International Standards Organization, Technical Committee 130, Working Group 2, Task Force 2 (ISO/TC130/WG2/TF2). This task force feeds international requirements into, and reviews the work of CGATS, and the other groups working on PDF/X standards.

Back to Contents

Why don't these standards come out faster?

The latest version of PDF available is 1.4 (Acrobat 5), and both PDF/X-1 and PDF/X-3 are based on PDF 1.3 (Acrobat 4) – why the mismatch?

Two of the most important issues that come into play here are results of the fact that CGATS and ISO are open consensus organizations – i.e. they operate by allowing everyone with expertise in the relevant area to make contributions.

One consequence of that is that they cannot work under a non-disclosure agreement from a third party, so it's not possible to see, for instance, the specification for a new version of PDF before it's officially published by Adobe. Thus the work to determine which pieces of functionality offered by a new version should be supported cannot start until the PDF specification is made public.

The second is that both organizations have very formal balloting processes to ensure that all interested parties are given the chance to express opinions. From submission of PDF/X-1 for the final voting process to ANSI approval took approximately ten months; ISO ballots usually take about the same length of time.

A third consideration is that it's very difficult to determine the real-world implications of a new version of PDF on professional print production without real experience. The major new functionality of PDF 1.4 (for the print world, at least) is the support for partially transparent objects. It's not yet clear how that will impact processes such as trapping or color management for proofing.

Finally, it's inappropriate to require all users to keep on the cutting edge of technology for all stages in their workflows in order to accept a standardized file format. It usually takes some time after the release of a new version of PDF to generate the tool sets that can handle them, and sometimes even longer before those tool sets become stable enough to rely on in a production environment.

Back to Contents

Acrobat makes PDF/X files, right?

PDF version 1.3 and 1.4 are not exactly the same as PDF/X, and files created by Acrobat Distiller 4 or 5 will not automatically be PDF/X compliant.

Acrobat Distiller versions 4.0 and earlier cannot be coerced into creating PDF/X-1 compliant files because of problems with profile embedding.

It is possible to persuade Acrobat Distiller 5 to generate PDF/X compliant files. For the technically minded, it involves taking care in the construction of PostScript files to be distilled, a combination of specific Distiller job options, and a few PostScript fragments calling pdfmark, possibly added into a PPD file or the Distiller prolog. Such an approach is, by its very nature, not very robust – using tools specifically designed to create PDF/X files is far more likely to result in valid files.

Back to Contents

Isn't PDF/X raster only?
It's just a wrapper for TIFF/IT isn't it?

Although it's possible to use PDF/X-1 as a wrapper for TIFF/IT files, that is not the intent of the design. A PDF/X file can, and usually will, include vector objects (such as rules, fills and text) using normal PDF constructs. It can also include image data, whether scanned or computer-generated. In this sense PDF/X is very similar to both PostScript and PDF.

Unlike PostScript, PDF/X-1 can make references to TIFF, EPS, DCS and TIFF/IT-P1 files and actually have those »external« files embedded within it. This approach is not recommended unless required by the design of a specific workflow and is therefore disallowed in PDF/X-1a, PDF/X-2 and PDF/X-3.

Where it differs from PDF is in limiting some options (such as the color spaces which may be used) to ensure that it will print reliably and consistently through all devices with PDF/X compliant readers.

Some of the PDF/X file generators already on the market create files by converting from CT/LW into PDF/X. These obviously end up with a PDF/X file that includes only raster data (even if it isn't all actually encoded using raster constructs). If you prefer to use raster files for delivery because of the very small increase in robustness and predictability, then a raster-only PDF/X-1 file may be worth considering. It has a number of advantages over TIFF/IT-P1, such as:  

• Better compression, including ZIP and JPEG for CTs, leading to smaller files.
• Mechanisms for marking trim and bleed areas.
• Support for spot colors.
• A free and widely used file viewer.
• A mechanism for identifying the printing condition that the file was prepared for (e.g. SWOP).
• A flag to state whether the file has been trapped already.

Unfortunately, encoding CT/LW data into a PDF or PDF/X file is likely to produce a file that RIPs and traps extremely slowly, and can show unwanted imaging artifacts if output at a different resolution to what it was produced for. The most recent position papers from the DDAP therefore recommend that ads created in a CT/LW format be transmitted as TIFF/IT rather than converted to PDF/X if possible, and the same advice is probably appropriate for non-advertising workflows too.

Back to Contents

Can PDF/X do duotones?

The original ANSI PDF/X-1:1999 standard was based on PDF 1.2, plus those few pieces of PDF 1.3 included in Adobe Technical Note 5188 (PDF 1.2 was the native version for Acrobat 3, PDF 1.3 is the native version for Acrobat 4). Those few pieces do not include the DeviceN color space. Thus that standard could not comfortably encode duotones in a way that would display correctly in the Acrobat Reader, or proof properly on a CMYK printer.

All of the ISO PDF/X standards (PDF/X-1:2001, PDF/X-1a:2001 and PDF/X-3:2002) are based on PDF 1.3, which includes support for the DeviceN color space. Thus duotones and other multi-tones and bump plates can now be encoded, viewed and proofed reliably.

Back to Contents

Who's accepting PDF/X-1a files, and how?

Many publishers, pre-press shops and publication, commercial and packaging printers are represented on CGATS SC6, either directly, or through associations and trade organizations. Their representatives have worked hard to ensure that the standard will be suitable for their use.

Several PDF/X-1a compliant tools are now available - mainly initially addressed at converting PDF files into PDF/X, and in pre-flighting such files. The DDAP maintains a list of available PDF/X applications at http://www.ddap.org/resources/pdfx_imp.html.

A number of companies are well on the way to completing tests of PDF/X-1a to parallel similar workflows using TIFF/IT.

The first known complete test-run of a PDF/X-1a ad was in early August 2001, and by the end of August an ad delivered as PDF/X-1a had been printed in a national American magazine (both handled by LTC/Vertis).

In September 2001 the SWOP calibration test kit was issued in PDF/X-1a.

In December 2001 the first known case of PDF/X-1a being used for the whole of a magazine transmission from publisher to printer was recorded (Wizards of the Coast – Dragon issue 292).

The latest SWOP version recommends that all digital ads are supplied in either TIFF/IT-P1 or PDF/X-1a.

Back to Contents

And who's taking PDF/X-3?

A free PDF/X-3 verifier is under development and should be available soon. The latest version of pdfInspektor from Callas software can also verify PDF/X-3 files.

A number of the member companies of the organizations supporting the development of PDF/X-3 are evaluating the advantages of using it in their workflows.

Back to Contents

Constructing pre-press workflows with PDF/X

As mentioned before, PDF/X is an application standard as well as a file format. In simplistic terms a creation tool is compliant if the files it makes match the specification, but reading tools must be a little more careful.

If you're a publisher, printer or pre-press department and considering accepting PDF/X files, you must ensure that your whole workflow, including trapping, compositing partial-page submissions, imposition and RIPing, is PDF/X compliant, for both proofing and final output. That doesn't necessarily mean that every tool you use must be explicitly PDF/X compatible, although, if they are, it can obviously simplify matters.

Stating it like that makes it sound rather difficult to set up to receive PDF/X files, but there are only a few key issues that you need to keep close tabs on.

When files are initially delivered you should pre-flight them to ensure:

• they are compliant with the appropriate version of PDF/X,
• they were created for the correct characterized printing condition, or one that you are comfortable transforming into your printing condition (if you asked for SWOP files because you're printing magazines in the US then you don't want files created for SNAP, for instance),
• the trim and bleed are appropriate for the job,
• the resolution of images is appropriate.

You may want to apply your own extra tests as well, but that's the core set. For the rest of the workflow:

• If the file is noted as already being trapped you should not re-trap it. If it's marked as requiring trapping you should apply whatever traps are necessary.
• When rendering the file the embedded fonts must be used rather than any that happen to be installed in your RIP, on your print server, etc.
• When rendering the file overprinting should be applied as defined in the PDF 1.3 specification. Note that many RIPs have switches that allow you to adjust overprinting behavior and the default settings may not produce the required output.

For more details, download the appropriate application note (see the next section).

Back to Contents

Where can I get more information?

Published and final draft (DIS) ISO standards may be purchased directly from ISO or from national standards bodies around the world (NPES in the USA, BSI in the UK, DIN in Germany, etc.)

More information on PDF/X-3 is available at http://www.eci.org.

CGATS information is available at the web site for NPES The Association for Suppliers of Printing, Publishing and Converting Technologies http://www.npes.org/standards/workroom.htm#CGATS. The CGATS site includes copies of draft ANSI/CGATS standards. Drafts are only available here while a standard is in development or ballot. Once published, CGATS standards may be obtained from NPES for a small charge – see http://www.npes.org/publications/index.htm.

CGATS SC6 has also created application notes covering some issues which were not appropriate for inclusion within the standards themselves, but which are designed to assist developers and systems integrators. The application note for PDF/X-1:1999 is bound into the printed standard and also available at http://www.npes.org/standards/PDFX1AppNote-V1-Dec99.pdf

The application note for PDF/X-1a:2001 is available in draft form from http://www.npes.org/standards/workroom.htm#CGATS.

The DDAP web site (http://www.ddap.org) maintains a list of software either already available, or being developed to support the PDF/X standards.

Back to Contents

I'm an application developer – what should I develop for?

If you're developing tools for page design, pre-flight, file conversion or pre-press I'd strongly recommend that you take the time to investigate PDF/X fully. Depending on your target market sector you should consider developing support for PDF/X-1a:2001 and/or PDF/X-3:2002.

Unless you have a special need to do so, it's unlikely that it would be worthwhile developing to PDF/X-1:1999 or PDF/X-1:2001.

Back to Contents

How can I get involved?

CGATS welcomes representatives from vendors, user organizations and users themselves. SC6 works on standards for digital file exchange and therefore covers market segments from ad agencies through pre-press and repro companies as far as printing companies. If you think you can help to build better standards please contact NPES or me (standards@npes.org, martinb@harlequin.com).

Outside the US, you'd also be welcome in the ISO PDF/X task force. The same contacts apply.

If you wish to contact the Swiss/German group working on PDF/X-3 contact Olaf Drümmer (pdfx3@callassoftware.com), or Stefan Brües (brues@kommtech.uni-wuppertal.de).

Vendors of OPI and/or asset management software, as well as those developing page design, pre-flight, file conversion or pre-press applications should track the development of PDF/X-2 and consider assisting with it. A white paper describing the probable approach to OPI handling in PDF/X-2 is available at http://www.npes.org/standards/workroom.html.

Martin Bailey
Senior Technical Consultant
Global Graphics Barrington Hall, Barrington
Cambridge CB2 5RG
United Kingdom
Tel: +44 1223 873800
Fax: +44 1223 873873
martin.bailey@globalgraphics.com,
http://www.globalgraphics.com

Copyright © Global Graphics Software, 1999-2002. All rights reserved.

Back to Contents