Hi all, first: everyone should try to be clear whether they are discussing PD/A-1 (archiving PDF) or PDF/X-1a (using/exchanging PDF as print ready file in prepress) here.
Creating PDF: - whenever creating a PDF from scratch, one has good control over what to put inside the PDF, and how to do it. Thus, creating both PDF/A-1 or PDF/X-1a can be achieved with reasonable effort. E.g. if RGB is not allowed at all in PDF/X-1a, use DeviceCMYK instead - if material to be used (an image) is in RGB, a color conversion has to be done to the image before putting it inside PDF. Converting existing PDF: - here things can be arbitrarily complex and challenging. As one has no control over how the PDF was created, anything could be inside it. Both PDF/A-1 and PDF/X-1a disallow lots of things. For example, both disallow transparency. Turning a PDF with transparency into a PDF that still looks (colors?) and behaves the same (text extraction?) but does not any longer use transparency is far from being trivial. While PDFBox will provide quite a nice and extensive toolbox for creating, reading and modifying PDF, a lot of effort will have to go into implementation work in addition to and on top of PDFBox for any decent conversion from arbitrary PDF to PDF/A-1 or PDF/X-1a. Think man years if you do it yourself, or consider throwing in additional tools. Olaf > On 21 Jan 2017, at 08:40, Harry Yoon <[email protected]> wrote: > > Hi Tilman, Thanks for the answer. > > > My knowledge of PDF is rather limited (I've been researching only for the > last few days), but yes, I understand that I have to create a > standards-compliant doc using the APIs. It seems that the requirements for > PDF/X-1a are generally easy to satisfy, maybe except for CMYK colors. I am > not sure why it is harder than other requirements, but I hear that > ghostscript tool ps2pdf, for instance, cannot currently convert a ps/pdf to a > fully compliant PDF/X-1a pdf because of this CMYK requirement. I presume that > PDFBox does not have such limitations? > > > Just to follow up, can PDFBox be used to convert an existing pdf to PDF/X-1a > conformant pdf (in addition to generating a PDF/X-1a conformant pdf from > scratch)? If so, is there a facility in PDFBox to make this task easier? Or, > is it just a manual process going through the original pdf (after parsing) > and re-generating output pdf (enforcing the requirements)? > > > Thanks, > > ~Harry > > > ________________________________ > From: Tilman Hausherr <[email protected]> > Sent: Saturday, January 21, 2017 7:06:19 AM > To: [email protected] > Subject: Re: PDF/X-1a? > > Am 21.01.2017 um 07:38 schrieb Tilman Hausherr: >> Am 21.01.2017 um 00:11 schrieb Harry Yoon: >>> Hi, >>> >>> >>> I'm new to PDFBox. I'm currently trying to figure out how to generate >>> PDF/X-1a conformant PDF using PDFBox. I found some references related >>> to PDF/A validation using PDFBox, but none pertinent to PDF/X. >>> >>> >>> Is it possible to use PDFBox to generate PDF/X-1a compliant PDF docs? >>> Or, at least to validate PDF files against PDF/X-1a standards? >> >> Yes it is possible to use PDFBox to generate PDF/A-1a compliant docs. >> Just read the standard ( this https://en.wikipedia.org/wiki/PDF/X >> gives a preview) and respect the requirements. No, PDFBox doesn't have >> a validator for that. > > To clarify this - > PDFBox is rather low level, i.e. you have to know a bit about PDF > itself. There isn't switch in PDFBox that sets PDF/A-1a compatibility. > To see what I mean, have a look at the CreatePDFA.java example. This > isn't what you need, but it shows what extra work is to be done for that > standard, e.g. output intents and XMP. > > More on PDF/A here > https://www.pdfa.org/pdfa-faq/ > > Tilman > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
