From: Michal H. <ms...@gm...> - 2010-11-21 10:45:22
|
[please post to the mailin list as well - I am CCing the list now] On Sun, Nov 21, 2010 at 12:30:24AM -0500, Roger Burrows wrote: > Hi Michal, Hi, > Thank you for the detailed instructions on building PDFEDIT. Once I figured > out the exact names of the development packages to install, everything went > very smoothly, thanks! > > However, there is still a minor problem (perhaps unimportant or known): when I > load the delinearized PDF into Acrobat Reader (7.0.7) under Windows XP, the > following message appears *very briefly* (less than 1 second) on the screen: > The file is damaged but is being repaired. > Then the PDF is displayed correctly. > > There is a free (Windows) PDF viewer called PDF-Xchange, which allows PDFs to > be resaved. If I load the delinearized PDF and then tell it to save it, using > the incremental save method, I get the following message: > The source document is broken. Do you wish to use the non-incremental save > option? > If I reply yes, then the saved file is OK (but smaller) and can be read by e.g. > Acrobat Reader without any error msgs. > > This is with 0.4.5 built using the sources from: > http://sourceforge.net/projects/pdfedit/files/pdfedit/0.4.5/pdfedit- > 0.4.5.tar.bz2/download Could you try with the current CVS snapshot, please? If the CVS version works fine then I would say that http://pdfedit.petricek.net/bt/view.php?id=359 can be the culprit, but this is just a blind shot. > > I do not regard this as a big problem, but I thought you might like to know > about it. If you need further info, please let me know. Damaged documents are never minor bugs... > > Regards, > Roger Burrows -- Michal Hocko |
From: Roger B. <rfb...@ym...> - 2010-11-23 03:58:49
|
Hi Michal, On 21 Nov 2010 at 11:37, Michal Hocko wrote: > > > > However, there is still a minor problem (perhaps unimportant or known): when > I > > load the delinearized PDF into Acrobat Reader (7.0.7) under Windows XP, the > > following message appears *very briefly* (less than 1 second) on the > screen: > > The file is damaged but is being repaired. > > Then the PDF is displayed correctly. > > > > There is a free (Windows) PDF viewer called PDF-Xchange, which allows PDFs > to > > be resaved. If I load the delinearized PDF and then tell it to save it, > using > > the incremental save method, I get the following message: > > The source document is broken. Do you wish to use the non-incremental save > > option? > > If I reply yes, then the saved file is OK (but smaller) and can be read by > e.g. > > Acrobat Reader without any error msgs. > > > > This is with 0.4.5 built using the sources from: > > http://sourceforge.net/projects/pdfedit/files/pdfedit/0.4.5/pdfedit- > > 0.4.5.tar.bz2/download > > Could you try with the current CVS snapshot, please? If the CVS version > works fine then I would say that > http://pdfedit.petricek.net/bt/view.php?id=359 can be the culprit, but > this is just a blind shot. > You will have to excuse my lack of familiarity with CVS. I went to the Develop section of PDFEDIT in Sourceforge, clicked on Browse CVS, clicked on the pdfedit directory, then clicked on Download GNU tarball. I unpacked it into a separate directory, ran autoconf, then ./configure, then make, then make install. I hope that was correct. The resulting program creates a file with the same errors as before (shown above) when I delinearize a particular PDF. It's the same PDF I sent you before. Let me know what else I can do, Roger |
From: Michal H. <ms...@gm...> - 2010-11-23 09:33:35
|
On Mon, Nov 22, 2010 at 10:57:22PM -0500, Roger Burrows wrote: > Hi Michal, > On 21 Nov 2010 at 11:37, Michal Hocko wrote: > > > > > > However, there is still a minor problem (perhaps unimportant or known): when > > I > > > load the delinearized PDF into Acrobat Reader (7.0.7) under Windows XP, the > > > following message appears *very briefly* (less than 1 second) on the > > screen: > > > The file is damaged but is being repaired. > > > Then the PDF is displayed correctly. > > > > > > There is a free (Windows) PDF viewer called PDF-Xchange, which allows PDFs > > to > > > be resaved. If I load the delinearized PDF and then tell it to save it, > > using > > > the incremental save method, I get the following message: > > > The source document is broken. Do you wish to use the non-incremental save > > > option? > > > If I reply yes, then the saved file is OK (but smaller) and can be read by > > e.g. > > > Acrobat Reader without any error msgs. > > > > > > This is with 0.4.5 built using the sources from: > > > http://sourceforge.net/projects/pdfedit/files/pdfedit/0.4.5/pdfedit- > > > 0.4.5.tar.bz2/download > > > > Could you try with the current CVS snapshot, please? If the CVS version > > works fine then I would say that > > http://pdfedit.petricek.net/bt/view.php?id=359 can be the culprit, but > > this is just a blind shot. > > > You will have to excuse my lack of familiarity with CVS. I went to the Develop > section of PDFEDIT in Sourceforge, clicked on Browse CVS, clicked on the > pdfedit directory, then clicked on Download GNU tarball. This will give you the current CVS snapshot so you have the most current version. The downside is that you will have to do that again once you want to update again. With the CVS you just need: cvs -d:pserver:ano...@pd...:/cvsroot/pdfedit login [empty passwd] cvs -z3 -d:pserver:ano...@pd...:/cvsroot/pdfedit co -P pdfedit if you want to update to the latest sources (after we make any changes then just) cvs -d:pserver:ano...@pd...:/cvsroot/pdfedit login cvs update -d:pserver:ano...@pd...:/cvsroot/pdfedit in the source tree. > I unpacked it into a > separate directory, ran autoconf, then ./configure, then make, then make > install. I hope that was correct. Yes, sounds good. > > The resulting program creates a file with the same errors as before (shown > above) when I delinearize a particular PDF. It's the same PDF I sent you > before. Are you sure? It shouldn't be same because we are encoding strings in a different way. How did you compare those documents? > > Let me know what else I can do, Could you send me the "fixed" document (by the private email)? > Roger -- Michal Hocko |
From: Roger B. <rfb...@ym...> - 2010-11-24 20:29:32
|
Hello Michal, On 23 Nov 2010 at 10:33, Michal Hocko wrote: > > > > > You will have to excuse my lack of familiarity with CVS. I went to the > Develop > > section of PDFEDIT in Sourceforge, clicked on Browse CVS, clicked on the > > pdfedit directory, then clicked on Download GNU tarball. > > This will give you the current CVS snapshot so you have the most current > version. The downside is that you will have to do that again once you > want to update again. With the CVS you just need: > > cvs -d:pserver:ano...@pd...:/cvsroot/pdfedit login > [empty passwd] > cvs -z3 -d:pserver:ano...@pd...:/cvsroot/pdfedit co > -P pdfedit > > if you want to update to the latest sources (after we make any changes > then just) > cvs -d:pserver:ano...@pd...:/cvsroot/pdfedit login > cvs update -d:pserver:ano...@pd...:/cvsroot/pdfedit > in the source tree. > > > I unpacked it into a > > separate directory, ran autoconf, then ./configure, then make, then make > > install. I hope that was correct. > > Yes, sounds good. > > > > > The resulting program creates a file with the same errors as before (shown > > above) when I delinearize a particular PDF. It's the same PDF I sent you > > before. > > Are you sure? It shouldn't be same because we are encoding strings in a > different way. How did you compare those documents? > I'm sorry, I wasn't clear. The *input* (linearized) PDF was the same one I sent you before. I didn't try to compare the delinearized PDFs. > > > > Let me know what else I can do, > > Could you send me the "fixed" document (by the private email)? > Yes, will do. Roger |
From: Michal H. <ms...@gm...> - 2010-11-25 15:33:41
|
On Wed, Nov 24, 2010 at 03:29:43PM -0500, Roger Burrows wrote: > Hello Michal, > On 23 Nov 2010 at 10:33, Michal Hocko wrote: > > > > > > > You will have to excuse my lack of familiarity with CVS. I went to the > > Develop > > > section of PDFEDIT in Sourceforge, clicked on Browse CVS, clicked on the > > > pdfedit directory, then clicked on Download GNU tarball. > > > > This will give you the current CVS snapshot so you have the most current > > version. The downside is that you will have to do that again once you > > want to update again. With the CVS you just need: > > > > cvs -d:pserver:ano...@pd...:/cvsroot/pdfedit login > > [empty passwd] > > cvs -z3 -d:pserver:ano...@pd...:/cvsroot/pdfedit co > > -P pdfedit > > > > if you want to update to the latest sources (after we make any changes > > then just) > > cvs -d:pserver:ano...@pd...:/cvsroot/pdfedit login > > cvs update -d:pserver:ano...@pd...:/cvsroot/pdfedit > > in the source tree. > > > > > I unpacked it into a > > > separate directory, ran autoconf, then ./configure, then make, then make > > > install. I hope that was correct. > > > > Yes, sounds good. > > > > > > > > The resulting program creates a file with the same errors as before (shown > > > above) when I delinearize a particular PDF. It's the same PDF I sent you > > > before. > > > > Are you sure? It shouldn't be same because we are encoding strings in a > > different way. How did you compare those documents? > > > I'm sorry, I wasn't clear. The *input* (linearized) PDF was the same one I > sent you before. I didn't try to compare the delinearized PDFs. OK, just to make sure that I have understood you. Have you tried to delinearze with the latest CVS snapshot and open the resulting document? If this is the case then I do not know what can make acrobat consider that the document is not correct (my version 9.2.10 doesn't complain). It might be also bug in those applications. > > > > > > > Let me know what else I can do, > > > > Could you send me the "fixed" document (by the private email)? > > > Yes, will do. I have checked documents you have sent me in the separate (off-list) email but it is really hard to judge anything from that as the document is completely reorganized so I would have to match object-by-object which I do not have time for. > > Roger -- Michal Hocko |
From: Roger B. <rfb...@ym...> - 2010-11-26 05:12:12
|
Hi Michal, On 25 Nov 2010 at 16:27, Michal Hocko wrote: > > > > > > Are you sure? It shouldn't be same because we are encoding strings in a > > > different way. How did you compare those documents? > > > > > I'm sorry, I wasn't clear. The *input* (linearized) PDF was the same one I > > sent you before. I didn't try to compare the delinearized PDFs. > > OK, just to make sure that I have understood you. Have you tried to > delinearze with the latest CVS snapshot and open the resulting document? As noted before, I tried with the GNU tarball that I downloaded from the CVS. You said before that this was the same as the current snapshot. If that's correct, then the answer is yes, the error occurs with the latest CVS snapshot. > If this is the case then I do not know what can make acrobat consider > that the document is not correct (my version 9.2.10 doesn't complain). > It might be also bug in those applications. > It might be, but they are two different applications written by different companies. Also, note that the error message from Acrobat reader 7 only appears very briefly (maybe for half a second) before the PDF displays. I don't have a copy of Acrobat reader 9, but Acrobat reader 10 displays the PDF so quickly after loading it that it would be hard/impossible to see a similar error message (and perhaps they don't issue one because the error is repairable). Note that PDF-Xchange itself silently corrects the error when loading, and only complains when you want to do an incremental save. Further, if you are running on a "modern" cpu (rather than a 2.6GHz Pentium 4 like me), you probably wouldn't be able to see the message even from Acrobat reader 7 because it would disappear so quickly. My belief is that there probably is an error in the delinearized document, associated with the incremental save information. > > I have checked documents you have sent me in the separate (off-list) > email but it is really hard to judge anything from that as the document > is completely reorganized so I would have to match object-by-object > which I do not have time for. > I tried this: I sent the original & the delinearized PDF to the Solid Documents PDF/A validator. I know they are not supposed to be PDF/A-compliant, but I thought I would check if there were any error msgs issued for the delinearized that weren't issued for the original, in case they might give you a clue. Here's what I got for differences in error msgs: . "Metadata dictionary used stream filter" . "Incorrect delimiter used for indirect object" (many of these) As I said, these are probably worthless, but just in case ... I have also emailed the authors of PDF-Xchanage to see if they can help me determine what the problem is. I will let you know via the list what (if any) information I get from them. Roger |
From: Michal H. <ms...@gm...> - 2010-11-26 10:26:06
|
On Fri, Nov 26, 2010 at 12:12:23AM -0500, Roger Burrows wrote: > Hi Michal, > On 25 Nov 2010 at 16:27, Michal Hocko wrote: > > > > > > > > Are you sure? It shouldn't be same because we are encoding strings in a > > > > different way. How did you compare those documents? > > > > > > > I'm sorry, I wasn't clear. The *input* (linearized) PDF was the same one I > > > sent you before. I didn't try to compare the delinearized PDFs. > > > > OK, just to make sure that I have understood you. Have you tried to > > delinearze with the latest CVS snapshot and open the resulting document? > > As noted before, I tried with the GNU tarball that I downloaded from the CVS. > You said before that this was the same as the current snapshot. If that's > correct, then the answer is yes, the error occurs with the latest CVS snapshot. OK. > > > If this is the case then I do not know what can make acrobat consider > > that the document is not correct (my version 9.2.10 doesn't complain). > > It might be also bug in those applications. > > > It might be, but they are two different applications written by different > companies. I have tried that with ghostview as well and that one is famous for being extremely careful about any discrepancies from the specification. It processed the file just fine as well. > Also, note that the error message from Acrobat reader 7 only > appears very briefly (maybe for half a second) before the PDF displays. I have noticed this message window in Acrobat 9 already. I have checked that by simply editing the file (e.g. add some spaces after xref entries; those at the end of file in format "0000759792 00000 n"). Acrobat have complained with the message window. Ghostview has printed: **** Warning: An error occurred while reading an XREF table. **** The file has been damaged. This may have been caused **** by a problem while converting or transfering the file. **** Ghostscript will attempt to recover the data. xpdf was silent about this and PDFedit is based on xpdf code so it is silent as well for this. The errors would have to be much worse to complain. [...] > My belief is that there probably is an error in the delinearized > document, associated with the incremental save information. I am not sure I understand what you mean by that. Delinearization will create a single revision document (so there is no incremental information). All reachable objects are just copied to the new document and then we construct a new xref table which points to those documents. > > > > > I have checked documents you have sent me in the separate (off-list) > > email but it is really hard to judge anything from that as the > > document is completely reorganized so I would have to match > > object-by-object which I do not have time for. > > > I tried this: I sent the original & the delinearized PDF to the Solid > Documents PDF/A validator. I know they are not supposed to be > PDF/A-compliant, but I thought I would check if there were any error > msgs issued for the delinearized that weren't issued for the original, > in case they might give you a clue. Here's what I got for differences > in error msgs: . "Metadata dictionary used stream filter" . "Incorrect > delimiter used for indirect object" (many of these) As I said, these > are probably worthless, but just in case ... Does it also print object numbers? This would be really helpful. > > I have also emailed the authors of PDF-Xchanage to see if they can > help me determine what the problem is. I will let you know via the > list what (if any) information I get from them. Thanks! > > Roger -- Michal Hocko |
From: Roger B. <rfb...@ym...> - 2010-11-26 23:05:01
|
Hi Michal, On 26 Nov 2010 at 11:25, Michal Hocko wrote: > > My belief is that there probably is an error in the delinearized > > document, associated with the incremental save information. > > I am not sure I understand what you mean by that. Delinearization will > create a single revision document (so there is no incremental > information). All reachable objects are just copied to the new document > and then we construct a new xref table which points to those documents. > Ok, I guess this shows that I know nothing about PDF structures :-(. Since you are creating a new XREF table, perhaps that is where the error is? > > > > > > > > I have checked documents you have sent me in the separate (off-list) > > > email but it is really hard to judge anything from that as the > > > document is completely reorganized so I would have to match > > > object-by-object which I do not have time for. > > > > > I tried this: I sent the original & the delinearized PDF to the Solid > > Documents PDF/A validator. I know they are not supposed to be > > PDF/A-compliant, but I thought I would check if there were any error > > msgs issued for the delinearized that weren't issued for the original, > > in case they might give you a clue. Here's what I got for differences > > in error msgs: . "Metadata dictionary used stream filter" . "Incorrect > > delimiter used for indirect object" (many of these) As I said, these > > are probably worthless, but just in case ... > > Does it also print object numbers? This would be really helpful. > I will send you the results via private email for both the input document and the delinearized document. There are *many* errors listed for both ... but I assume that would be normal since they are not supposed to be PDF/A compliant. As I said, I listed the messages that were just in the output for the delinearized PDF ... I realize that they may also be caused by valid PDF failing a PDF/A test, but I thought it might be a clue. > > > > I have also emailed the authors of PDF-Xchanage to see if they can > > help me determine what the problem is. I will let you know via the > > list what (if any) information I get from them. > The initial comment is that there were errors in the XREF table - this is from a support guy, not the developers. He said he would pass the info on, but could not promise any more info (since PDF-Xchange is free, I can't be upset about that). Thanks, Roger Burrows |
From: Roger B. <rfb...@ym...> - 2010-11-29 06:14:41
|
Hi Michal, I thought it would be a good thing for me to understand a little bit about the file structure of PDFs. So I started by writing a simple program to display the file structure of a PDF, based on section 7.5 of the PDF 1.7 manual. I looked at a lot of PDFs, as well as the one delinearized by PDFEDIT, and I see one thing that is definitely different: the cross-reference table of the delinearized PDF has no object zero. In section 7.5.4 of the PDF 1.7 reference manual on page 41, it says: The cross-reference table (comprising the original cross-reference section and all update sections) shall contain one entry for each object number from 0 to the maximum object number defined in the file, even if one or more of the object numbers in this range do not actually occur in the file. So (with great hesitation because I am ignorant of the remaining 700+ pages of the manual), it seems to me that the problem with reading the delinearized output may be because there is no entry for object zero. Hope this helps, Roger Burrows |
From: Michal H. <ms...@gm...> - 2010-11-29 17:42:24
|
On Mon, Nov 29, 2010 at 01:14:58AM -0500, Roger Burrows wrote: > Hi Michal, Hi, > I thought it would be a good thing for me to understand a little bit about the > file structure of PDFs. So I started by writing a simple program to display > the file structure of a PDF, based on section 7.5 of the PDF 1.7 manual. I > looked at a lot of PDFs, as well as the one delinearized by PDFEDIT, and I see > one thing that is definitely different: the cross-reference table of the > delinearized PDF has no object zero. > > In section 7.5.4 of the PDF 1.7 reference manual on page 41, it says: > The cross-reference table (comprising the original cross-reference section and > all update sections) shall contain one entry for each object number from 0 to > the maximum object number defined in the file, even if one or more of the > object numbers in this range do not actually occur in the file. > > So (with great hesitation because I am ignorant of the remaining 700+ pages of > the manual), it seems to me that the problem with reading the delinearized > output may be because there is no entry for object zero. You can check that easily. Just edit the delinearized document and replace: xref -1 263 +0 264 +0000000000 65535 f \n Make sure that you do not edit anything before xref keyword and that that the added entry has exactly 20B (if you are using DOS EOL - \r\n then you have to skip the space after `f'). I have another suspicion that the problem might be related to UNIX vs. DOS EOL. This shouldn't be a problem because the specification is rather clear on the EOL but who knows. If the first test with the object 0 doesn't pass then I would try to update each entry to use DOS EOL. Let's see > > Hope this helps, > Roger Burrows Thanks! -- Michal Hocko |
From: Roger B. <rfb...@ym...> - 2010-11-29 22:26:51
|
Hi Michal, On 29 Nov 2010 at 18:42, Michal Hocko wrote: > > > > So (with great hesitation because I am ignorant of the remaining 700+ pages > of > > the manual), it seems to me that the problem with reading the delinearized > > output may be because there is no entry for object zero. > > You can check that easily. Just edit the delinearized document and > replace: > xref > -1 263 > +0 264 > +0000000000 65535 f \n > > Make sure that you do not edit anything before xref keyword and that > that the added entry has exactly 20B (if you are using DOS EOL - \r\n then > you > have to skip the space after `f'). > Well, I did that and (as you suspected) it didn't fix the problem. > I have another suspicion that the problem might be related to UNIX vs. > DOS EOL. This shouldn't be a problem because the specification is rather > clear on the EOL but who knows. If the first test with the object 0 > doesn't pass then I would try to update each entry to use DOS EOL. > I tried that too (I assumed you meant just for the cross reference list), and it didn't help either :-(. If you want to change Unix to DOS EOL for the whole document, I need to write a little program (EOLs in stream data shouldn't be changed!). Roger |
From: Michal H. <ms...@gm...> - 2010-11-30 09:30:29
|
On Mon, Nov 29, 2010 at 05:26:53PM -0500, Roger Burrows wrote: > Hi Michal, > On 29 Nov 2010 at 18:42, Michal Hocko wrote: > > > > > > So (with great hesitation because I am ignorant of the remaining 700+ pages > > of > > > the manual), it seems to me that the problem with reading the delinearized > > > output may be because there is no entry for object zero. > > > > You can check that easily. Just edit the delinearized document and > > replace: > > xref > > -1 263 > > +0 264 > > +0000000000 65535 f \n > > > > Make sure that you do not edit anything before xref keyword and that > > that the added entry has exactly 20B (if you are using DOS EOL - \r\n then > > you > > have to skip the space after `f'). > > > Well, I did that and (as you suspected) it didn't fix the problem. OK > > > I have another suspicion that the problem might be related to UNIX vs. > > DOS EOL. This shouldn't be a problem because the specification is rather > > clear on the EOL but who knows. If the first test with the object 0 > > doesn't pass then I would try to update each entry to use DOS EOL. > > > I tried that too (I assumed you meant just for the cross reference list), and > it didn't help either :-(. Hmm, strange I thought that the logs from verifier point to xref table. > If you want to change Unix to DOS EOL for the whole > document, I need to write a little program (EOLs in stream data shouldn't be > changed!). This would be more tricky because xref table contains offsets of objects in the file. How can I use the verifier? > > Roger -- Michal Hocko |
From: Roger B. <rfb...@ym...> - 2010-12-01 01:52:08
Attachments:
WPM$4104.PM$
|
Hi Michal, On 30 Nov 2010 at 10:30, Michal Hocko wrote: > > > If you want to change Unix to DOS EOL for the whole > > document, I need to write a little program (EOLs in stream data shouldn't > > be changed!). > > This would be more tricky because xref table contains offsets of objects > in the file. > Just a little more tricky ... :-) > How can I use the verifier? > Go to this web site: http://www.validatepdfa.com/ As I mentioned, this verifies against PDF/A which is, I understand, a subset of PDF 1.4. So I suppose that many (most? all?) of the errors reported are not errors in 1.4. Roger |
From: Michal H. <ms...@gm...> - 2010-12-02 17:21:09
|
On Tue, Nov 30, 2010 at 08:29:07PM -0500, Roger Burrows wrote: > Hi Michal, > On 30 Nov 2010 at 10:30, Michal Hocko wrote: > > > > > If you want to change Unix to DOS EOL for the whole > > > document, I need to write a little program (EOLs in stream data shouldn't > > > be changed!). > > > > This would be more tricky because xref table contains offsets of objects > > in the file. > > > Just a little more tricky ... :-) > > > How can I use the verifier? > > > Go to this web site: > http://www.validatepdfa.com/ I have used it for my several local documents and none of them passed the test... > As I mentioned, this verifies against PDF/A which is, I understand, a subset of > PDF 1.4. So I suppose that many (most? all?) of the errors reported are not > errors in 1.4. I wasn't able to find the complete specification though. Neither I have found what the error 6.1.8 "Incorrect delimiter used for indirect object" means. It would be much more easier if I knew that that means. > > Roger > -- Michal Hocko |
From: Roger B. <rfb...@ym...> - 2010-12-03 06:23:07
|
Hi Michal, > > > As I mentioned, this verifies against PDF/A which is, I understand, a subset > of > > PDF 1.4. So I suppose that many (most? all?) of the errors reported are not > > errors in 1.4. > > I wasn't able to find the complete specification though. Neither I have > found what the error 6.1.8 "Incorrect delimiter used for indirect object" > means. It would be much more easier if I knew that that means. > I think you probably need the ISO document that specifies PDF/A. I have located a draft specification for PDF/A at this URL: http://www.aiim.org/documents/standards/PDF-A/SC2N226.pdf This indicates that the correct delimiter for indirect objects in PDF/A is cr/lf. So Unix linefeeds are causing the error messages, which is irrelevant for PDF-1.4 compatibility. I guess we can ignore the PDF/A checker for this problem, unfortunately. Roger |
From: Michal H. <ms...@gm...> - 2010-12-04 10:28:49
|
On Fri, Dec 03, 2010 at 01:23:30AM -0500, Roger Burrows wrote: > Hi Michal, > > > > > As I mentioned, this verifies against PDF/A which is, I understand, a subset > > of > > > PDF 1.4. So I suppose that many (most? all?) of the errors reported are not > > > errors in 1.4. > > > > I wasn't able to find the complete specification though. Neither I have > > found what the error 6.1.8 "Incorrect delimiter used for indirect object" > > means. It would be much more easier if I knew that that means. > > > I think you probably need the ISO document that specifies PDF/A. I have > located a draft specification for PDF/A at this URL: > http://www.aiim.org/documents/standards/PDF-A/SC2N226.pdf Thanks! > This indicates that the correct delimiter for indirect objects in PDF/A is > cr/lf. So Unix linefeeds are causing the error messages, which is irrelevant > for PDF-1.4 compatibility. Yes. PDF specification doesn't say anything like that. It just defines that \r and \n are EOL markers and if they are used in a sequence they are treated as a single EOL (e.g. \r\r or \n\n is treated as a single EOL). So this looks like a PDFA specific requirement. (Btw. I have checked the PDF specification PDF and it uses single \r as an EOL) > I guess we can ignore the PDF/A checker for this problem, > unfortunately. Yes, I guess so. > > Roger -- Michal Hocko |