pdfbox-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tilman Hausherr <THaush...@t-online.de>
Subject Re: Problem with pdfbox save(Version 1.8.7 and snapshot 2.0.0) moe info
Date Tue, 13 Oct 2015 15:39:54 GMT
Hi,

I tried something simple and did not have any problem. Could you post 
some short complete code that reproduces the problem? Please post also a 
link to some public PDF.

Now that it is quite possible that a COSStream is closed, but not the 
COSDocument that contains it.

My suspicion is that after the split, some pages are closed, and later 
you are saving the original document (or split several times and then 
save). The problem is that internally, the elements are not cloned.

Re "filebuffer" - Are you building from source? If yes, please change 
the save method like this and tell whether it goes faster:

     public void save(File file) throws IOException
     {
         save(new BufferedOutputStream(new FileOutputStream(file)));
     }

I doubt we'd want to save to a memory buffer first and then save as a 
whole, this would cost much more space, but you can of course do this 
yourself.

re "same error at version 1.8.7" - I doubt this. There is no "COSStream 
has been closed and cannot be read" message there. (And we're at 1.8.10 
now).

Tilman


Am 13.10.2015 um 10:12 schrieb Fossestøl, Vegard:
>
> Hi,
>
> I have encountered a strange problem with pdf box. I’m trying to split 
> a Larger PDF file into smaller ones. The split function does work, but 
> when saving the new generated pdf to disk, there’s a problem. I get 
> this errormessage:
> /COSStream has been closed and cannot be read. //Perhaps its enclosing 
> PDDocument has been closed?/
>
> But I’ve sysout’ed the state of the document which say’s it’s not 
> closed. And as well, the program runs properly in debug mode. I’m 
> currently running eclipse on a Websphere applicatation Server 7. And 
> I’ve tried to fix the problem for days now. But converting the 
> PDDocument to a bytearray, and everything that is possible. As well 
> I’ve tried to just use your save function that takes a filename as a 
> parameter (Which is extremely slow, you should use a filebuffer and 
> bytearray to save it).
>
> How is it possible that it works in debug mode, and not “normal” mode. 
> And I’m adding a picture so it’s possible for you to see the 
> stacktrace. I’m adding a small part of the code as well, so it’s 
> possible for you to analyze the source code (Which now looks bad, due 
> to not being able to use debug mode, since it works fine)
>
>
>
> Hope you have the time to help me as soon as possible. Btw, get the 
> same error at version 1.8.7 and 2.0.0
>
> Med vennlig hilsen
>
> Vegard Fossestøl
>
> Tlf: 916 32 699
> Konsulent Møllergruppen
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: users-help@pdfbox.apache.org


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message