Re: PDFBox*.tmp files not deleted by PDFParser

2016-05-25 Thread Tilman Hausherr 
I did an implementation similar to what is done in PDDocument. I 
remember that once (but don't remember why), the cached stream was 
accessed after parsing so we shouldn't close it too soon. But thanks for 
pointing me to the right direction!


https://issues.apache.org/jira/browse/PDFBOX-3363

Tilman

-
To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: users-h...@pdfbox.apache.org

Re: PDFBox*.tmp files not deleted by PDFParser

2016-05-25 Thread Tilman Hausherr 

Hi,

Thanks, I'll research this. I think you have a good argument, I just 
looked at PDDocument and there pdfSource is kept.


Tilman

Am 25.05.2016 um 12:11 schrieb Damien Butaye:

Hello Tilman,

  For your information I found a workaround to avoid the problem of tmp file
deletion. In the SignatureOptions object, I modified the method  *public
void setVisualSignature(InputStream is)  *with the following content :

   RandomAccessBufferedFileInputStream tmp=new
RandomAccessBufferedFileInputStream(is); --> NEW LINE
  PDFParser parser = new PDFParser(tmp);  --> NEW LINE
  parser.parse();
  visualSignature = parser.getDocument();
  tmp.close();  --> NEW LINE

Tmp files are well deleted and all unit tests passed without error on the
pdfbox maven project.
If you think it's not a good solution, don't hesitate to tell me.

Thank you.


2016-05-25 10:01 GMT+02:00 Damien Butaye :


Hello Tilman,

  Yes I did it. I verified in debug mode and this method (close() on
SignatureOption) is well reached but the close() method of the object
"RandomAccessBufferedFileInputStream" is never called, so the tmp file is
never deleted.
The patch [PDFBOX-2723] adds a line in the method parseXrefObjStream of
the COSParser but this method is not called. It seems this method is called
only in case of "xref stream" (line 286 COSParser) , why not in other case
-> xref (line 218 COSParser)?

Damien.

2016-05-24 20:10 GMT+02:00 Tilman Hausherr :


did you close the options object?

Tilman


Am 24.05.2016 um 15:51 schrieb Damien Butaye:


Dear all,

I'm trying to add a signature to a PDF using PDFBOX 2.0.1. During the
process, a tmp file (e.g: tmpPDFBoxXXX.pdf) is stored inside the /tmp
directory (RehHat server). This file is not deleted after completion.
After some checks, it seems that the object responsible of the file
creation is  "RandomAccessBufferedFileInputStream(InputStream is)". This
object is used by the PDFParser object which doesn't close the stream
after
completion.

The release note 2.0.0 [PDFBOX-2723] seems to handle this bug by adding
the
following line (see https://issues.apache.org/jira/browse/PDFBOX-2723)
in
the COSParser :

xrefStream.close(); // <--- *** NEW LINE ***

But, in debug mode, I saw this line is never reached so the stream is not
closed and the tmp file is not deleted. Has anybody a workaround to
handle
this ?
Thanks for your help!



-
To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: users-h...@pdfbox.apache.org





-
To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: users-h...@pdfbox.apache.org

Re: unable to calculate text width

2016-05-25 Thread Tilman Hausherr 

Is the font a subset?

Tilman

Am 25.05.2016 um 10:14 schrieb Croe.David:

Dear all,

i'm trying to replace and center a text in a pdf which has been created by 
phantomjs.

I'm not sure if it's a problem within phantomjs or pdfbox, but I get following 
exception while calculating the text width of a string starting with Symbol %:

Exception in thread "main" java.lang.IllegalArgumentException: No glyph for 
U+0025 in font TimesNewRomanStandard
at 
org.apache.pdfbox.pdmodel.font.PDCIDFontType2.encode(PDCIDFontType2.java:411)
at 
org.apache.pdfbox.pdmodel.font.PDType0Font.encode(PDType0Font.java:351)
at org.apache.pdfbox.pdmodel.font.PDFont.encode(PDFont.java:286)
at org.apache.pdfbox.pdmodel.font.PDFont.getStringWidth(PDFont.java:315)


in PDCIDFontType2:
isEmbedded is true
parent.getCMap().getName() is Identity-H
cmap is null
cid is -1



a closer look with pdfdebugger , this is the toUnicode:

/CIDInit /ProcSet findresource begin
12 dict begin
begincmap
/CIDSystemInfo << /Registry (Adobe) /Ordering (UCS) /Supplement 0 >> def
/CMapName /Adobe-Identity-UCS def
/CMapType 2 def
1 begincodespacerange
<> 
endcodespacerange
2 beginbfrange
<> <> <>
<0001> <0024> [<0025> <004E> <0041> <004D> <0045> <003A> <0043> <0054> <0052> <0062> <0065> <0073> <0074> <0061> <006E> <0064> <0020> <006D> <0069> <0066> <006F> 
<006C> <0067> <0072> <0050> <0075> <006B> <007A> <0068> <0055> <004B> <0044> <00FC> <0042> <0079> <0070> ]
endbfrange
endcmap
CMapName currentdict /CMap defineresource pop
end
end

how to calculate the width or fix the problem ?

best regards,
David Croé


[https://www.inside-online.de/mail/footer/anbieter_des_jahres.jpg]
Danke an unsere Kunden für die Wahl zum Anbieter des Jahres 2016!
Kontaktieren Sie uns 
hier
 und erfahren Sie, warum uns unsere Kunden
zum Anbieter des Jahres gewählt haben.
Gerne sprechen wir auch über Ihr E-Learning-Projekt!





-
To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: users-h...@pdfbox.apache.org

Re: PDFBox*.tmp files not deleted by PDFParser

2016-05-25 Thread Damien Butaye 
Hello Tilman,

 For your information I found a workaround to avoid the problem of tmp file
deletion. In the SignatureOptions object, I modified the method  *public
void setVisualSignature(InputStream is)  *with the following content :

  RandomAccessBufferedFileInputStream tmp=new
RandomAccessBufferedFileInputStream(is); --> NEW LINE
 PDFParser parser = new PDFParser(tmp);  --> NEW LINE
 parser.parse();
 visualSignature = parser.getDocument();
 tmp.close();  --> NEW LINE

Tmp files are well deleted and all unit tests passed without error on the
pdfbox maven project.
If you think it's not a good solution, don't hesitate to tell me.

Thank you.


2016-05-25 10:01 GMT+02:00 Damien Butaye :

> Hello Tilman,
>
>  Yes I did it. I verified in debug mode and this method (close() on
> SignatureOption) is well reached but the close() method of the object
> "RandomAccessBufferedFileInputStream" is never called, so the tmp file is
> never deleted.
> The patch [PDFBOX-2723] adds a line in the method parseXrefObjStream of
> the COSParser but this method is not called. It seems this method is called
> only in case of "xref stream" (line 286 COSParser) , why not in other case
> -> xref (line 218 COSParser)?
>
> Damien.
>
> 2016-05-24 20:10 GMT+02:00 Tilman Hausherr :
>
>> did you close the options object?
>>
>> Tilman
>>
>>
>> Am 24.05.2016 um 15:51 schrieb Damien Butaye:
>>
>>> Dear all,
>>>
>>>I'm trying to add a signature to a PDF using PDFBOX 2.0.1. During the
>>> process, a tmp file (e.g: tmpPDFBoxXXX.pdf) is stored inside the /tmp
>>> directory (RehHat server). This file is not deleted after completion.
>>> After some checks, it seems that the object responsible of the file
>>> creation is  "RandomAccessBufferedFileInputStream(InputStream is)". This
>>> object is used by the PDFParser object which doesn't close the stream
>>> after
>>> completion.
>>>
>>> The release note 2.0.0 [PDFBOX-2723] seems to handle this bug by adding
>>> the
>>> following line (see https://issues.apache.org/jira/browse/PDFBOX-2723)
>>> in
>>> the COSParser :
>>>
>>> xrefStream.close(); // <--- *** NEW LINE ***
>>>
>>> But, in debug mode, I saw this line is never reached so the stream is not
>>> closed and the tmp file is not deleted. Has anybody a workaround to
>>> handle
>>> this ?
>>> Thanks for your help!
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org
>> For additional commands, e-mail: users-h...@pdfbox.apache.org
>>
>>
>

Re: PDFBox*.tmp files not deleted by PDFParser

2016-05-25 Thread Andreas Lehmkühler 
> Damien Butaye  hat am 25. Mai 2016 um 10:01
> geschrieben:
> 
> 
> Hello Tilman,
> 
>  Yes I did it. I verified in debug mode and this method (close() on
> SignatureOption) is well reached but the close() method of the object
> "RandomAccessBufferedFileInputStream" is never called, so the tmp file is
> never deleted.
The RandomAccessBufferedFileInputStream is used for the whole document and for
the SignatureOptions. You already confirmed that you close the latter one. What
about the document itself, did you close it as well? 

> The patch [PDFBOX-2723] adds a line in the method parseXrefObjStream of the
> COSParser but this method is not called. It seems this method is called
> only in case of "xref stream" (line 286 COSParser) , why not in other case
> -> xref (line 218 COSParser)?
Neither a xrefstream nor a xref table uses its own
RandomAccessBufferedFileInputStream, so that this question doesn't seem to be
related to your problem.

BR
Andreas

> Damien.
> 
> 2016-05-24 20:10 GMT+02:00 Tilman Hausherr :
> 
> > did you close the options object?
> >
> > Tilman
> >
> >
> > Am 24.05.2016 um 15:51 schrieb Damien Butaye:
> >
> >> Dear all,
> >>
> >>I'm trying to add a signature to a PDF using PDFBOX 2.0.1. During the
> >> process, a tmp file (e.g: tmpPDFBoxXXX.pdf) is stored inside the /tmp
> >> directory (RehHat server). This file is not deleted after completion.
> >> After some checks, it seems that the object responsible of the file
> >> creation is  "RandomAccessBufferedFileInputStream(InputStream is)". This
> >> object is used by the PDFParser object which doesn't close the stream
> >> after
> >> completion.
> >>
> >> The release note 2.0.0 [PDFBOX-2723] seems to handle this bug by adding
> >> the
> >> following line (see https://issues.apache.org/jira/browse/PDFBOX-2723) in
> >> the COSParser :
> >>
> >> xrefStream.close(); // <--- *** NEW LINE ***
> >>
> >> But, in debug mode, I saw this line is never reached so the stream is not
> >> closed and the tmp file is not deleted. Has anybody a workaround to handle
> >> this ?
> >> Thanks for your help!
> >>
> >>
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org
> > For additional commands, e-mail: users-h...@pdfbox.apache.org
> >
> >

-
To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: users-h...@pdfbox.apache.org

unable to calculate text width

2016-05-25 Thread Croe . David 
Dear all,

i'm trying to replace and center a text in a pdf which has been created by 
phantomjs.

I'm not sure if it's a problem within phantomjs or pdfbox, but I get following 
exception while calculating the text width of a string starting with Symbol %:

Exception in thread "main" java.lang.IllegalArgumentException: No glyph for 
U+0025 in font TimesNewRomanStandard
   at 
org.apache.pdfbox.pdmodel.font.PDCIDFontType2.encode(PDCIDFontType2.java:411)
   at 
org.apache.pdfbox.pdmodel.font.PDType0Font.encode(PDType0Font.java:351)
   at org.apache.pdfbox.pdmodel.font.PDFont.encode(PDFont.java:286)
   at org.apache.pdfbox.pdmodel.font.PDFont.getStringWidth(PDFont.java:315)


in PDCIDFontType2:
isEmbedded is true
parent.getCMap().getName() is Identity-H
cmap is null
cid is -1



a closer look with pdfdebugger , this is the toUnicode:

/CIDInit /ProcSet findresource begin
12 dict begin
begincmap
/CIDSystemInfo << /Registry (Adobe) /Ordering (UCS) /Supplement 0 >> def
/CMapName /Adobe-Identity-UCS def
/CMapType 2 def
1 begincodespacerange
<> 
endcodespacerange
2 beginbfrange
<> <> <>
<0001> <0024> [<0025> <004E> <0041> <004D> <0045> <003A> <0043> <0054> <0052> 
<0062> <0065> <0073> <0074> <0061> <006E> <0064> <0020> <006D> <0069> <0066> 
<006F> <006C> <0067> <0072> <0050> <0075> <006B> <007A> <0068> <0055> <004B> 
<0044> <00FC> <0042> <0079> <0070> ]
endbfrange
endcmap
CMapName currentdict /CMap defineresource pop
end
end

how to calculate the width or fix the problem ?

best regards,
   David Croé


[https://www.inside-online.de/mail/footer/anbieter_des_jahres.jpg]
Danke an unsere Kunden für die Wahl zum Anbieter des Jahres 2016!
Kontaktieren Sie uns 
hier
 und erfahren Sie, warum uns unsere Kunden
zum Anbieter des Jahres gewählt haben.
Gerne sprechen wir auch über Ihr E-Learning-Projekt!

Re: PDFBox*.tmp files not deleted by PDFParser

2016-05-25 Thread Damien Butaye 
Hello Tilman,

 Yes I did it. I verified in debug mode and this method (close() on
SignatureOption) is well reached but the close() method of the object
"RandomAccessBufferedFileInputStream" is never called, so the tmp file is
never deleted.
The patch [PDFBOX-2723] adds a line in the method parseXrefObjStream of the
COSParser but this method is not called. It seems this method is called
only in case of "xref stream" (line 286 COSParser) , why not in other case
-> xref (line 218 COSParser)?

Damien.

2016-05-24 20:10 GMT+02:00 Tilman Hausherr :

> did you close the options object?
>
> Tilman
>
>
> Am 24.05.2016 um 15:51 schrieb Damien Butaye:
>
>> Dear all,
>>
>>I'm trying to add a signature to a PDF using PDFBOX 2.0.1. During the
>> process, a tmp file (e.g: tmpPDFBoxXXX.pdf) is stored inside the /tmp
>> directory (RehHat server). This file is not deleted after completion.
>> After some checks, it seems that the object responsible of the file
>> creation is  "RandomAccessBufferedFileInputStream(InputStream is)". This
>> object is used by the PDFParser object which doesn't close the stream
>> after
>> completion.
>>
>> The release note 2.0.0 [PDFBOX-2723] seems to handle this bug by adding
>> the
>> following line (see https://issues.apache.org/jira/browse/PDFBOX-2723) in
>> the COSParser :
>>
>> xrefStream.close(); // <--- *** NEW LINE ***
>>
>> But, in debug mode, I saw this line is never reached so the stream is not
>> closed and the tmp file is not deleted. Has anybody a workaround to handle
>> this ?
>> Thanks for your help!
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org
> For additional commands, e-mail: users-h...@pdfbox.apache.org
>
>