from:"Manfred Pock"

Pdf cannot rendered on current Trunk-Version

2018-09-03 Thread Manfred Pock

Hello,

a PDF cannot be rendered with pdfbox, the file ist downloadable at 
http://cloud.directupload.net/4Wi4.

It’s seem to that some jpeg2000 Images are embeeded and the Exception is:

java.io.IOException: Could not read JPEG 2000 (JPX) image
at org.apache.pdfbox.filter.JPXFilter.readJPX(JPXFilter.java:111)
at org.apache.pdfbox.filter.JPXFilter.decode(JPXFilter.java:58)
at org.apache.pdfbox.cos.COSInputStream.create(COSInputStream.java:83)
at org.apache.pdfbox.cos.COSStream.createInputStream(COSStream.java:175)
at 
org.apache.pdfbox.pdmodel.common.PDStream.createInputStream(PDStream.java:235)
at 
org.apache.pdfbox.pdmodel.graphics.image.PDImageXObject.createInputStream(PDImageXObject.java:704)
at 
org.apache.pdfbox.pdmodel.graphics.image.SampledImageReader.from8bit(SampledImageReader.java:346)
at 
org.apache.pdfbox.pdmodel.graphics.image.SampledImageReader.getRGBImage(SampledImageReader.java:215)
at 
org.apache.pdfbox.pdmodel.graphics.image.PDImageXObject.getImage(PDImageXObject.java:418)
at 
org.apache.pdfbox.pdmodel.graphics.image.PDImageXObject.getImage(PDImageXObject.java:400)
at org.apache.pdfbox.rendering.PageDrawer.drawImage(PageDrawer.java:966)
at 
org.apache.pdfbox.contentstream.operator.graphics.DrawObject.process(DrawObject.java:62)
at 
org.apache.pdfbox.contentstream.PDFStreamEngine.processOperator(PDFStreamEngine.java:841)
at 
org.apache.pdfbox.contentstream.PDFStreamEngine.processStreamOperators(PDFStreamEngine.java:498)
at 
org.apache.pdfbox.contentstream.PDFStreamEngine.processStream(PDFStreamEngine.java:472)
at 
org.apache.pdfbox.contentstream.PDFStreamEngine.processPage(PDFStreamEngine.java:150)
at org.apache.pdfbox.rendering.PageDrawer.drawPage(PageDrawer.java:244)
at 
org.apache.pdfbox.rendering.PDFRenderer.renderImage(PDFRenderer.java:229)
at 
org.apache.pdfbox.rendering.PDFRenderer.renderImageWithDPI(PDFRenderer.java:166)
…..
Caused by: java.lang.IllegalArgumentException: Dimensions (width=100 
height=100) are too large
at java.awt.image.SampleModel.(Unknown Source)
at java.awt.image.ComponentSampleModel.(Unknown Source)
at java.awt.image.PixelInterleavedSampleModel.(Unknown Source)
at 
com.sun.media.imageioimpl.plugins.jpeg2000.J2KReadState.getSampleModel(J2KReadState.java:913)
at 
com.sun.media.imageioimpl.plugins.jpeg2000.J2KReadState.readBufferedImage(J2KReadState.java:358)
at 
com.sun.media.imageioimpl.plugins.jpeg2000.J2KImageReader.read(J2KImageReader.java:454)
at org.apache.pdfbox.filter.JPXFilter.readJPX(JPXFilter.java:106)
... 22 more

Could be there any possibility to render this PDF?

Regarts, Manfred

Pdf cannot rendered correct/ current Trunk-Version

2017-11-15 Thread Manfred Pock


Hello,

once again a PDF which one cannot be rendered with pdfbox. On an older version 
of Pdfbox (Trunkversion from 2016-05-12) it could be rendered.

The file is downloadable at http://cloud.directupload.net/4Vgf.

Regarts, Manfred

Re: Pdf cannot rendered correct/ current Trunk-Version

2017-10-18 Thread Manfred Pock

Hello,



no it's not created at our company, we got all kinds of pdf's from different 
companies to view at our software and have no influence tot he pdf-sources. 
Thanks for your answer.



Manfred



On 2017-10-16 19:13, Tilman Hausherr 
<t...@t-online.de<mailto:t...@t-online.de>> wrote:

> Am 16.10.2017 um 11:32 schrieb Manfred Pock:>

> > Hello,>

> >>

> > the PDF at http://cloud.directupload.net/97hE is rendered incorrect at 
> > current trunk-version, may there be any solution?>

> >>

> > Best regarts, Manfred>

> >>

> >>

>

> Did you create this file yourself / in your company?>

>

> The font has the "symbolic" bit set but it is not symbolic.>

>

> Tilman>

>

>

>

> ->

> To unsubscribe, e-mail: 
> dev-unsubscr...@pdfbox.apache.org<mailto:dev-unsubscr...@pdfbox.apache.org>>

> For additional commands, e-mail: 
> dev-h...@pdfbox.apache.org<mailto:dev-h...@pdfbox.apache.org>>

>

>

Pdf cannot rendered correct/ current Trunk-Version

2017-10-16 Thread Manfred Pock

Hello,

the PDF at http://cloud.directupload.net/97hE is rendered incorrect at current 
trunk-version, may there be any solution?

Best regarts, Manfred

Re: Pdf cannot rendered correct/ current Trunk-Version

2016-02-22 Thread Manfred Pock


*File can be uploadet at http://cloud.directupload.net/4Fph

regarts, Manfred
*
Am 22.02.2016 um 10:01 schrieb Tilman Hausherr:

Am 22.02.2016 um 09:43 schrieb Manfred Pock:

Hello,

enclosed a pdf which is rendered incorrect, wrong background-color, 
different black squares on the page, where no one should be.


Please upload the file somewhere. Sounds like a problem with 
transparencies, which we do not always render correctly.


Tilman


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

Pdf cannot rendered correct/ current Trunk-Version

2016-02-22 Thread Manfred Pock


Hello,

enclosed a pdf which is rendered incorrect, wrong background-color, 
different black squares on the page, where no one should be.


regarts,  Manfred


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

Re: Pdfbox trunk performance

2015-11-10 Thread Manfred Pock


Hi,

25 dpi not really useful to show on screen?

About "PDFBox isn’t really fast enough for real-time rendering, such as 
a PDF viewer in AWT / Swing."


For what else you will need a rendering module?

For printing? I think, 10 sec per Page is realy slow, also for printing.

regarts, Manfred

Am 05.11.2015 um 19:27 schrieb John Hewson:

On 2 Nov 2015, at 13:30, Manfred Pock <pock.manf...@gmail.com> wrote:

Hi,

Am 02.11.2015 um 21:27 schrieb John Hewson:

On 2 Nov 2015, at 08:35, Manfred Pock <pock.manf...@gmail.com> wrote:

Hi,

we render a image with the pdfbox-renderer:

for example
renderImageWithDPI(Pi_pageIdx, 250, ImageType.RGB);

250dpi, is a good value beetween performance and rendering quality

That’s a pretty high DPI, I’d expect PDFBox to take a while to render that. Is 
there any way you can reduce the DPI?

Not really, if you will use some zooming features like fit do screen width and 
so one, you need this dpi value. We have also tried it with lower dpi value, 
there ist not so an big difference.

Just to be clear I’m not saying that this is a high DPI in general, but it’s 
high for PDFBox, if your goal is rendering performance. It sounds like you 
might be rendering the document at an excessive DPI and then scaling-down the 
BufferedImage - if so you’d be better of rendering at a lower DPI.

Try rendering at a tiny DPI, such as 25, you should see great performance - if 
not, there might be something specific to that PDF file which is causing PDFBox 
problems.

— John


and we show the bufferedimage in java (we also cache the image that we don't 
need to rerender it always)

PDFBox isn’t really fast enough for real-time rendering, such as a PDF viewer 
in AWT / Swing.

— John

That are not good news. We have also testet other free java-pdf-libaries, some 
are faster, but they don't have the same rendering quality and no one can view 
so many kinds of pdf as pdfbox. There is pdfbox especial great.

BR, Manfred

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



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




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

Re: Pdfbox trunk performance

2015-11-10 Thread Manfred Pock


Hi,

is not that just that one pdf that need a lot of time to render, it's 
just a good example to see the difference between the may-trunk-version 
and the current one.


regarts, Manfred

Am 07.11.2015 um 04:52 schrieb Tilman Hausherr:

We take 12-18 seconds to display the first page.

I**PDF takes 2 seconds to display the first page.

Tilman

Am 05.11.2015 um 19:43 schrieb Tilman Hausherr:
That one is indeed slow to display. The reason is the huge background 
image. This is very inefficient. The company footer should be done 
with fonts; the company header should be done with a shading, or with 
a smaller image.


Amusingly, the company slogan is "faster in the business". But 
they're cluttering their own storage and the one of their customers 
with such huge PDFs.


I didn't do any benchmarks, but 1.8 seems also very slow with that one.

Tilman

Am 02.11.2015 um 17:09 schrieb Manfred Pock:

Hello!

Currently we you use a version from pdfbox to render pdf's from the 
trunk at date 2015-03-09. Not really fast, but it will be ok.


From time to time i try the current trunk version to check any 
improvements on the performance side, but no enhancement, it seems 
the rendering process is getting slower and slower.


For example the pdf at http://cloud.directupload.net/N4t needs on 
the may-version about 5 sec to render der first page, the current 
version needs at least 10 sec.


I have tried it it with different memory settings, no really 
different. It will be great if you can to some improvements on the 
rendering performance before 2.0 final version will release.


best regarts, Manfred

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




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




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




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

Pdfbox trunk performance

2015-11-02 Thread Manfred Pock


Hello!

Currently we you use a version from pdfbox to render pdf's from the 
trunk at date 2015-03-09. Not really fast, but it will be ok.


From time to time i try the current trunk version to check any 
improvements on the performance side, but no enhancement, it seems the 
rendering process is getting slower and slower.


For example the pdf at http://cloud.directupload.net/N4t needs on the 
may-version about 5 sec to render der first page, the current version 
needs at least 10 sec.


I have tried it it with different memory settings, no really different. 
It will be great if you can to some improvements on the rendering 
performance before 2.0 final version will release.


best regarts, Manfred

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

Re: Pdfbox trunk performance

2015-11-02 Thread Manfred Pock


Windows 7 pro, jdk 8, intel core i5, 8Gb Ram.

Java-Parameter:
-XX:MaxHeapFreeRatio=40 -XX:MinHeapFreeRatio=30 -XX:+UseParNewGC 
-XX:+UseConcMarkSweepGC -Xmx512m -Xms192m


Log-message, no there are no new logmessage.

BR, Manfred

Am 02.11.2015 um 17:12 schrieb Maruan Sahyoun:

Hello Manfred,


Am 02.11.2015 um 17:09 schrieb Manfred Pock <pock.manf...@gmail.com>:

Hello!

Currently we you use a version from pdfbox to render pdf's from the trunk at 
date 2015-03-09. Not really fast, but it will be ok.

 From time to time i try the current trunk version to check any improvements on 
the performance side, but no enhancement, it seems the rendering process is 
getting slower and slower.

For example the pdf at http://cloud.directupload.net/N4t needs on the 
may-version about 5 sec to render der first page, the current version needs at 
least 10 sec.

thanks for the pointer - do you get any (new) log messages while rendering? 
Which platform are you using?

BR
Maruan


I have tried it it with different memory settings, no really different. It will 
be great if you can to some improvements on the rendering performance before 
2.0 final version will release.

best regarts, Manfred

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



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




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

Re: Pdfbox trunk performance

2015-11-02 Thread Manfred Pock


Hi,

it is a standalone-app, no app server.

i will take a look about font cache.

BR, Manfred

Am 02.11.2015 um 17:24 schrieb Maruan Sahyoun:

Hi,


Am 02.11.2015 um 17:20 schrieb Manfred Pock <pock.manf...@gmail.com>:

Windows 7 pro, jdk 8, intel core i5, 8Gb Ram.

Java-Parameter:
-XX:MaxHeapFreeRatio=40 -XX:MinHeapFreeRatio=30 -XX:+UseParNewGC 
-XX:+UseConcMarkSweepGC -Xmx512m -Xms192m

Log-message, no there are no new log message.

is it a standalone app? running in an app server …

One thing we do know about is the FontCache which has an performance impact. But there 
should be a log message about building/rebuilding the font cache ("Building font 
cache, this may take a while")

BR
Maruan


BR, Manfred

Am 02.11.2015 um 17:12 schrieb Maruan Sahyoun:

Hello Manfred,


Am 02.11.2015 um 17:09 schrieb Manfred Pock <pock.manf...@gmail.com>:

Hello!

Currently we you use a version from pdfbox to render pdf's from the trunk at 
date 2015-03-09. Not really fast, but it will be ok.

 From time to time i try the current trunk version to check any improvements on 
the performance side, but no enhancement, it seems the rendering process is 
getting slower and slower.

For example the pdf at http://cloud.directupload.net/N4t needs on the 
may-version about 5 sec to render der first page, the current version needs at 
least 10 sec.

thanks for the pointer - do you get any (new) log messages while rendering? 
Which platform are you using?

BR
Maruan


I have tried it it with different memory settings, no really different. It will 
be great if you can to some improvements on the rendering performance before 
2.0 final version will release.

best regarts, Manfred

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


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



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



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




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

Re: Pdfbox trunk performance

2015-11-02 Thread Manfred Pock


Hi,

we render a image with the pdfbox-renderer:

for example
renderImageWithDPI(Pi_pageIdx, 250, ImageType.RGB);

250dpi, is a good value beetween performance and rendering quality

and we show the bufferedimage in java (we also cache the image that we 
don't need to rerender it always)


what i know is that the usual way in pdfbox, or will there be a better way?

BR,  Manfred

Am 02.11.2015 um 17:27 schrieb Maruan Sahyoun:

Hi,


Am 02.11.2015 um 17:20 schrieb Manfred Pock <pock.manf...@gmail.com>:

Windows 7 pro, jdk 8, intel core i5, 8Gb Ram.

Java-Parameter:
-XX:MaxHeapFreeRatio=40 -XX:MinHeapFreeRatio=30 -XX:+UseParNewGC 
-XX:+UseConcMarkSweepGC -Xmx512m -Xms192m

Log-message, no there are no new log message.

btw - how do you do the rendering? Would you have a code snippet?

BR
Maruan



BR, Manfred

Am 02.11.2015 um 17:12 schrieb Maruan Sahyoun:

Hello Manfred,


Am 02.11.2015 um 17:09 schrieb Manfred Pock <pock.manf...@gmail.com>:

Hello!

Currently we you use a version from pdfbox to render pdf's from the trunk at 
date 2015-03-09. Not really fast, but it will be ok.

 From time to time i try the current trunk version to check any improvements on 
the performance side, but no enhancement, it seems the rendering process is 
getting slower and slower.

For example the pdf at http://cloud.directupload.net/N4t needs on the 
may-version about 5 sec to render der first page, the current version needs at 
least 10 sec.

thanks for the pointer - do you get any (new) log messages while rendering? 
Which platform are you using?

BR
Maruan


I have tried it it with different memory settings, no really different. It will 
be great if you can to some improvements on the rendering performance before 
2.0 final version will release.

best regarts, Manfred

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


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



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



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




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

Re: Pdfbox trunk performance

2015-11-02 Thread Manfred Pock


Hi,

Am 02.11.2015 um 21:27 schrieb John Hewson:

On 2 Nov 2015, at 08:35, Manfred Pock <pock.manf...@gmail.com> wrote:

Hi,

we render a image with the pdfbox-renderer:

for example
renderImageWithDPI(Pi_pageIdx, 250, ImageType.RGB);

250dpi, is a good value beetween performance and rendering quality

That’s a pretty high DPI, I’d expect PDFBox to take a while to render that. Is 
there any way you can reduce the DPI?
Not really, if you will use some zooming features like fit do screen 
width and so one, you need this dpi value. We have also tried it with 
lower dpi value, there ist not so an big difference.



and we show the bufferedimage in java (we also cache the image that we don't 
need to rerender it always)

PDFBox isn’t really fast enough for real-time rendering, such as a PDF viewer 
in AWT / Swing.

— John


That are not good news. We have also testet other free 
java-pdf-libaries, some are faster, but they don't have the same 
rendering quality and no one can view so many kinds of pdf as pdfbox. 
There is pdfbox especial great.


BR, Manfred

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

Re: ClassCastException during rendering pdf

2015-09-21 Thread Manfred Pock


Hi Maruan,

the pdf is not our own, a customer get this one from another customer. I 
have asked the customer that he can find out how the pdf will be created.
However, maybe the attachement is not correct, but the acrobat reader 
can show it, the pdf and the attachet pdf.
It is possible to filter or ignore the attachement, or any oder 
solution. For us it will be ok, that the attachement will be ignored.


BR, Manfred

Am 21.09.2015 um 12:41 schrieb Maruan Sahyoun:

Hi Manfred,

how was that document created. Has it been processed afterwards?

The reason for the issue - if I'm not mistaken is that the document contains a 
FileAttachment annotation but that is contained in the /Contents of the page 
where there should either be a single stream or an array of streams with the 
pages graphical content. A file attachment annotation should be in the /Annots 
entry of the page (which is empty in your case)

BR
Maruan


Am 21.09.2015 um 10:50 schrieb Manfred Pock <pock.manf...@gmail.com>:


Sorry, it's just by one pdf, i have removed the correct one, the exception 
exists at

http://cloud.directupload.net/2pYC

thanks, Manfred

 Weitergeleitete Nachricht 
Betreff:ClassCastException during rendering pdf
Datum:  Mon, 21 Sep 2015 10:44:48 +0200
Von:Manfred Pock <pock.manf...@gmail.com>
An: dev@pdfbox.apache.org



Hi,

i get a ClassCastException in Current 2.0-trunkversion, Java 1.8,
Windows 7, during rendering two pdfs. Is there any solution?

The Stacktrace is:

Exception in thread "AWT-EventQueue-0" java.lang.ClassCastException:
org.apache.pdfbox.cos.COSDictionary cannot be cast to
org.apache.pdfbox.cos.COSStream
at org.apache.pdfbox.pdmodel.PDPage.getContents(PDPage.java:157)
at
org.apache.pdfbox.pdfparser.PDFStreamParser.(PDFStreamParser.java:92)
at
org.apache.pdfbox.contentstream.PDFStreamEngine.processStreamOperators(PDFStreamEngine.java:450)
at
org.apache.pdfbox.contentstream.PDFStreamEngine.processStream(PDFStreamEngine.java:437)
at
org.apache.pdfbox.contentstream.PDFStreamEngine.processPage(PDFStreamEngine.java:148)
at org.apache.pdfbox.rendering.PageDrawer.drawPage(PageDrawer.java:179)
at
org.apache.pdfbox.rendering.PDFRenderer.renderPage(PDFRenderer.java:208)
at
org.apache.pdfbox.rendering.PDFRenderer.renderImage(PDFRenderer.java:139)
at
org.apache.pdfbox.rendering.PDFRenderer.renderImageWithDPI(PDFRenderer.java:94)

and you can download the pdf's at

http://cloud.directupload.net/2pYB
http://cloud.directupload.net/2pYC

best regarts, Manfred





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




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

Re: ClassCastException during rendering pdf

2015-09-21 Thread Manfred Pock


Hi Maruan,

an dirty but interesting workarround i have found, but it's not a real 
solution.
If i just read the problem-pdf with itext before and store them to an 
tmp-file (without any changes), then i can render the tmp-pdf with pdfbox.


BR, Manfred

Am 21.09.2015 um 12:41 schrieb Maruan Sahyoun:

Hi Manfred,

how was that document created. Has it been processed afterwards?

The reason for the issue - if I'm not mistaken is that the document contains a 
FileAttachment annotation but that is contained in the /Contents of the page 
where there should either be a single stream or an array of streams with the 
pages graphical content. A file attachment annotation should be in the /Annots 
entry of the page (which is empty in your case)

BR
Maruan


Am 21.09.2015 um 10:50 schrieb Manfred Pock <pock.manf...@gmail.com>:


Sorry, it's just by one pdf, i have removed the correct one, the exception 
exists at

http://cloud.directupload.net/2pYC

thanks, Manfred

 Weitergeleitete Nachricht 
Betreff:ClassCastException during rendering pdf
Datum:  Mon, 21 Sep 2015 10:44:48 +0200
Von:Manfred Pock <pock.manf...@gmail.com>
An: dev@pdfbox.apache.org



Hi,

i get a ClassCastException in Current 2.0-trunkversion, Java 1.8,
Windows 7, during rendering two pdfs. Is there any solution?

The Stacktrace is:

Exception in thread "AWT-EventQueue-0" java.lang.ClassCastException:
org.apache.pdfbox.cos.COSDictionary cannot be cast to
org.apache.pdfbox.cos.COSStream
at org.apache.pdfbox.pdmodel.PDPage.getContents(PDPage.java:157)
at
org.apache.pdfbox.pdfparser.PDFStreamParser.(PDFStreamParser.java:92)
at
org.apache.pdfbox.contentstream.PDFStreamEngine.processStreamOperators(PDFStreamEngine.java:450)
at
org.apache.pdfbox.contentstream.PDFStreamEngine.processStream(PDFStreamEngine.java:437)
at
org.apache.pdfbox.contentstream.PDFStreamEngine.processPage(PDFStreamEngine.java:148)
at org.apache.pdfbox.rendering.PageDrawer.drawPage(PageDrawer.java:179)
at
org.apache.pdfbox.rendering.PDFRenderer.renderPage(PDFRenderer.java:208)
at
org.apache.pdfbox.rendering.PDFRenderer.renderImage(PDFRenderer.java:139)
at
org.apache.pdfbox.rendering.PDFRenderer.renderImageWithDPI(PDFRenderer.java:94)

and you can download the pdf's at

http://cloud.directupload.net/2pYB
http://cloud.directupload.net/2pYC

best regarts, Manfred





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




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

ClassCastException during rendering pdf

2015-09-21 Thread Manfred Pock


Hi,

i get a ClassCastException in Current 2.0-trunkversion, Java 1.8, 
Windows 7, during rendering two pdfs. Is there any solution?


The Stacktrace is:

Exception in thread "AWT-EventQueue-0" java.lang.ClassCastException: 
org.apache.pdfbox.cos.COSDictionary cannot be cast to 
org.apache.pdfbox.cos.COSStream

at org.apache.pdfbox.pdmodel.PDPage.getContents(PDPage.java:157)
at 
org.apache.pdfbox.pdfparser.PDFStreamParser.(PDFStreamParser.java:92)
at 
org.apache.pdfbox.contentstream.PDFStreamEngine.processStreamOperators(PDFStreamEngine.java:450)
at 
org.apache.pdfbox.contentstream.PDFStreamEngine.processStream(PDFStreamEngine.java:437)
at 
org.apache.pdfbox.contentstream.PDFStreamEngine.processPage(PDFStreamEngine.java:148)

at org.apache.pdfbox.rendering.PageDrawer.drawPage(PageDrawer.java:179)
at 
org.apache.pdfbox.rendering.PDFRenderer.renderPage(PDFRenderer.java:208)
at 
org.apache.pdfbox.rendering.PDFRenderer.renderImage(PDFRenderer.java:139)
at 
org.apache.pdfbox.rendering.PDFRenderer.renderImageWithDPI(PDFRenderer.java:94)


and you can download the pdf's at

http://cloud.directupload.net/2pYB
http://cloud.directupload.net/2pYC

best regarts, Manfred

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

Fwd: ClassCastException during rendering pdf

2015-09-21 Thread Manfred Pock



Sorry, it's just by one pdf, i have removed the correct one, the 
exception exists at


http://cloud.directupload.net/2pYC

thanks, Manfred

 Weitergeleitete Nachricht 
Betreff:ClassCastException during rendering pdf
Datum:  Mon, 21 Sep 2015 10:44:48 +0200
Von:Manfred Pock <pock.manf...@gmail.com>
An: dev@pdfbox.apache.org



Hi,

i get a ClassCastException in Current 2.0-trunkversion, Java 1.8,
Windows 7, during rendering two pdfs. Is there any solution?

The Stacktrace is:

Exception in thread "AWT-EventQueue-0" java.lang.ClassCastException:
org.apache.pdfbox.cos.COSDictionary cannot be cast to
org.apache.pdfbox.cos.COSStream
at org.apache.pdfbox.pdmodel.PDPage.getContents(PDPage.java:157)
at
org.apache.pdfbox.pdfparser.PDFStreamParser.(PDFStreamParser.java:92)
at
org.apache.pdfbox.contentstream.PDFStreamEngine.processStreamOperators(PDFStreamEngine.java:450)
at
org.apache.pdfbox.contentstream.PDFStreamEngine.processStream(PDFStreamEngine.java:437)
at
org.apache.pdfbox.contentstream.PDFStreamEngine.processPage(PDFStreamEngine.java:148)
at org.apache.pdfbox.rendering.PageDrawer.drawPage(PageDrawer.java:179)
at
org.apache.pdfbox.rendering.PDFRenderer.renderPage(PDFRenderer.java:208)
at
org.apache.pdfbox.rendering.PDFRenderer.renderImage(PDFRenderer.java:139)
at
org.apache.pdfbox.rendering.PDFRenderer.renderImageWithDPI(PDFRenderer.java:94)

and you can download the pdf's at

http://cloud.directupload.net/2pYB
http://cloud.directupload.net/2pYC

best regarts, Manfred

image in pdf question

2015-08-17 Thread Manfred Pock


The Pdfboxversion is the 2.0 trunk Version.

For performance reason we render Pdf's with one picture over the whole 
page (scanned pdf's) at our own. (about 2 sec faster)
The other pdf's we will render it with pdfbox. We check different 
attributes from the page-resoureces  (ShadingNames, ExtGSNames, 
PatternNames, PropetiesNames, ColorSpaceNames) and the Count and Size of 
the Picture (larger then the Mediabox). But we don't the check the 
fontnames from the resources because we have ocr (unvisible) text on the 
pdf-page to search in the page.


Now we have an pdf where is a an size-filled background-image and some 
text overlayed. We detect this page as scanned page and so we just 
render the picture.


Would there be a better solution to check/detect that an pdf-page is an 
scanned pdf-page with no attitional text?


regarts, Manfred

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

Re: Performance of the trunkversion

2015-07-15 Thread Manfred Pock


Hi Timo,

i have tried it put it doesn't work now and i get different exceptions 
or Errors


i looks like that there is a problem with any kind of images, the rest 
will be shown.


for example:

SCHWERWIEGEND: TIFFFaxDecoder: Invalid code encountered while decoding 
2D group 4 compressed data.
java.io.IOException: TIFFFaxDecoder: Invalid code encountered while 
decoding 2D group 4 compressed data.
at 
org.apache.pdfbox.filter.ccitt.TIFFFaxDecoder.decodeT6(TIFFFaxDecoder.java:1125)
at 
org.apache.pdfbox.filter.CCITTFaxFilter.decode(CCITTFaxFilter.java:94)

at org.apache.pdfbox.cos.COSStream.attemptDecode(COSStream.java:422)
at org.apache.pdfbox.cos.COSStream.doDecode(COSStream.java:398)
at org.apache.pdfbox.cos.COSStream.doDecode(COSStream.java:335)
at org.apache.pdfbox.cos.COSStream.getDecodeResult(COSStream.java:278)
at 
org.apache.pdfbox.pdmodel.graphics.image.PDImageXObject.init(PDImageXObject.java:120)
at 
org.apache.pdfbox.pdmodel.graphics.PDXObject.createXObject(PDXObject.java:67)
at 
org.apache.pdfbox.pdmodel.PDResources.getXObject(PDResources.java:340)


SCHWERWIEGEND: FlateFilter: stop reading corrupt stream due to a 
DataFormatException
Jul 15, 2015 9:45:05 AM org.apache.pdfbox.contentstream.PDFStreamEngine 
operatorException

WARNUNG: java.util.zip.DataFormatException: invalid block type

Jul 15, 2015 9:46:18 AM org.apache.pdfbox.contentstream.PDFStreamEngine 
operatorException

WARNUNG: Not a JPEG file: starts with 0xe0 0x00

ul 15, 2015 9:46:23 AM org.apache.pdfbox.contentstream.PDFStreamEngine 
operatorException

WARNUNG: Image stream was not read - filter: DCTDecode

SCHWERWIEGEND: java.util.zip.DataFormatException: invalid distance too 
far back
java.io.IOException: java.util.zip.DataFormatException: invalid distance 
too far back

at org.apache.pdfbox.filter.FlateFilter.decode(FlateFilter.java:83)
at org.apache.pdfbox.cos.COSStream.attemptDecode(COSStream.java:422)
at org.apache.pdfbox.cos.COSStream.doDecode(COSStream.java:398)
at org.apache.pdfbox.cos.COSStream.doDecode(COSStream.java:335)
at 
org.apache.pdfbox.cos.COSStream.checkUnfilteredBuffer(COSStream.java:265)
at 
org.apache.pdfbox.cos.COSStream.getUnfilteredRandomAccess(COSStream.java:239)

at org.apache.pdfbox.pdfparser.BaseParser.init(BaseParser.java:146)
at 
org.apache.pdfbox.pdfparser.PDFStreamParser.init(PDFStreamParser.java:78)
at 
org.apache.pdfbox.contentstream.PDFStreamEngine.processStreamOperators(PDFStreamEngine.java:451)
at 
org.apache.pdfbox.contentstream.PDFStreamEngine.processStream(PDFStreamEngine.java:438)
at 
org.apache.pdfbox.contentstream.PDFStreamEngine.processPage(PDFStreamEngine.java:149)

at org.apache.pdfbox.rendering.PageDrawer.drawPage(PageDrawer.java:180)
at 
org.apache.pdfbox.rendering.PDFRenderer.renderPage(PDFRenderer.java:205)
at 
org.apache.pdfbox.rendering.PDFRenderer.renderImage(PDFRenderer.java:136)
at 
org.apache.pdfbox.rendering.PDFRenderer.renderImageWithDPI(PDFRenderer.java:95)
 Caused by: java.util.zip.DataFormatException: invalid distance too 
far back

at java.util.zip.Inflater.inflateBytes(Native Method)
at java.util.zip.Inflater.inflate(Inflater.java:259)
at java.util.zip.Inflater.inflate(Inflater.java:280)
at 
org.apache.pdfbox.filter.FlateFilter.decompress(FlateFilter.java:101)

at org.apache.pdfbox.filter.FlateFilter.decode(FlateFilter.java:74)

Am 15.07.2015 um 00:35 schrieb Timo Boehme:
I've created PDFBOX-2882 with a drop-in replacement of the scratch 
file implementation.
@Manfred: Could you please test if this helps in your scenario to 
increase performance?


Best,
Timo


Am 14.07.2015 um 13:47 schrieb Timo Boehme:

Hi,

instead of having a linked page list in ScratchFileBuffer I would
propose having a list of pages with the page numbers (integer) kept in
memory (takes 1k for 1MB data). This would ease page handling, seeking
does not need I/O-operations and caching of pages would be a lot easier.
I may find some time later to come up with such a replacement.

Best,
Timo


Am 14.07.2015 um 13:02 schrieb Timo Boehme:

Hi,

as I see it (had only a quick look at the implementation) the
ScratchFileBuffer implementation is not optimal for fast random access.
Single writes of bytes are not buffered but directly written to the 
file
- a lot of I/O-operations) and seek operations have to travel the 
linked
page list reading some bytes of each page - again a lot of seek and 
read

I/O-operations.
To speed things up it is crucial to minimize the number of
I/O-operations directly going to the random access file. Therefore 
it is

needed to buffer writes, keep last read page in memory for sequential
reads and have an in-memory cache of page meta data (offset, link to
previous/next page).


Best,
Timo


Am 14.07.2015 um 12:15 schrieb Manfred Pock:

Yes, the input is a inputstream. I can try it direct from file.

But in general we get the pdf from an document management

Re: Performance of the trunkversion

2015-07-15 Thread Manfred Pock


Hi Timo,

i have test it with different pdf's and die performance ist nearly of 
the version from may. Just a little bit slower.


It will be ok, but it will be nice if it will performe better ;-)

thanks and regarts.
Manfred

Am 15.07.2015 um 10:24 schrieb Timo Boehme:

Hi Manfred,

the issue should be fixed in the updated versions attached to 
PDFBOX-2882. Please give them a try.



Timo


Am 15.07.2015 um 09:51 schrieb Manfred Pock:

Hi Timo,

i have tried it put it doesn't work now and i get different exceptions
or Errors

i looks like that there is a problem with any kind of images, the rest
will be shown.

for example:

SCHWERWIEGEND: TIFFFaxDecoder: Invalid code encountered while decoding
2D group 4 compressed data.
java.io.IOException: TIFFFaxDecoder: Invalid code encountered while
decoding 2D group 4 compressed data.
 at
org.apache.pdfbox.filter.ccitt.TIFFFaxDecoder.decodeT6(TIFFFaxDecoder.java:1125) 



 at
org.apache.pdfbox.filter.CCITTFaxFilter.decode(CCITTFaxFilter.java:94)
 at 
org.apache.pdfbox.cos.COSStream.attemptDecode(COSStream.java:422)

 at org.apache.pdfbox.cos.COSStream.doDecode(COSStream.java:398)
 at org.apache.pdfbox.cos.COSStream.doDecode(COSStream.java:335)
 at 
org.apache.pdfbox.cos.COSStream.getDecodeResult(COSStream.java:278)

 at
org.apache.pdfbox.pdmodel.graphics.image.PDImageXObject.init(PDImageXObject.java:120) 



 at
org.apache.pdfbox.pdmodel.graphics.PDXObject.createXObject(PDXObject.java:67) 



 at
org.apache.pdfbox.pdmodel.PDResources.getXObject(PDResources.java:340)

SCHWERWIEGEND: FlateFilter: stop reading corrupt stream due to a
DataFormatException
Jul 15, 2015 9:45:05 AM org.apache.pdfbox.contentstream.PDFStreamEngine
operatorException
WARNUNG: java.util.zip.DataFormatException: invalid block type

Jul 15, 2015 9:46:18 AM org.apache.pdfbox.contentstream.PDFStreamEngine
operatorException
WARNUNG: Not a JPEG file: starts with 0xe0 0x00

ul 15, 2015 9:46:23 AM org.apache.pdfbox.contentstream.PDFStreamEngine
operatorException
WARNUNG: Image stream was not read - filter: DCTDecode

SCHWERWIEGEND: java.util.zip.DataFormatException: invalid distance too
far back
java.io.IOException: java.util.zip.DataFormatException: invalid distance
too far back
 at org.apache.pdfbox.filter.FlateFilter.decode(FlateFilter.java:83)
 at 
org.apache.pdfbox.cos.COSStream.attemptDecode(COSStream.java:422)

 at org.apache.pdfbox.cos.COSStream.doDecode(COSStream.java:398)
 at org.apache.pdfbox.cos.COSStream.doDecode(COSStream.java:335)
 at
org.apache.pdfbox.cos.COSStream.checkUnfilteredBuffer(COSStream.java:265) 


 at
org.apache.pdfbox.cos.COSStream.getUnfilteredRandomAccess(COSStream.java:239) 



 at 
org.apache.pdfbox.pdfparser.BaseParser.init(BaseParser.java:146)

 at
org.apache.pdfbox.pdfparser.PDFStreamParser.init(PDFStreamParser.java:78) 


 at
org.apache.pdfbox.contentstream.PDFStreamEngine.processStreamOperators(PDFStreamEngine.java:451) 



 at
org.apache.pdfbox.contentstream.PDFStreamEngine.processStream(PDFStreamEngine.java:438) 



 at
org.apache.pdfbox.contentstream.PDFStreamEngine.processPage(PDFStreamEngine.java:149) 



 at
org.apache.pdfbox.rendering.PageDrawer.drawPage(PageDrawer.java:180)
 at
org.apache.pdfbox.rendering.PDFRenderer.renderPage(PDFRenderer.java:205)
 at
org.apache.pdfbox.rendering.PDFRenderer.renderImage(PDFRenderer.java:136) 


 at
org.apache.pdfbox.rendering.PDFRenderer.renderImageWithDPI(PDFRenderer.java:95) 



 Caused by: java.util.zip.DataFormatException: invalid distance too
far back
 at java.util.zip.Inflater.inflateBytes(Native Method)
 at java.util.zip.Inflater.inflate(Inflater.java:259)
 at java.util.zip.Inflater.inflate(Inflater.java:280)
 at
org.apache.pdfbox.filter.FlateFilter.decompress(FlateFilter.java:101)
 at org.apache.pdfbox.filter.FlateFilter.decode(FlateFilter.java:74)

Am 15.07.2015 um 00:35 schrieb Timo Boehme:

I've created PDFBOX-2882 with a drop-in replacement of the scratch
file implementation.
@Manfred: Could you please test if this helps in your scenario to
increase performance?

Best,
Timo


Am 14.07.2015 um 13:47 schrieb Timo Boehme:

Hi,

instead of having a linked page list in ScratchFileBuffer I would
propose having a list of pages with the page numbers (integer) kept in
memory (takes 1k for 1MB data). This would ease page handling, seeking
does not need I/O-operations and caching of pages would be a lot 
easier.

I may find some time later to come up with such a replacement.

Best,
Timo


Am 14.07.2015 um 13:02 schrieb Timo Boehme:

Hi,

as I see it (had only a quick look at the implementation) the
ScratchFileBuffer implementation is not optimal for fast random 
access.

Single writes of bytes are not buffered but directly written to the
file
- a lot of I/O-operations) and seek operations have to travel the
linked
page list reading some bytes of each page - again a lot of seek and
read
I/O-operations

[jira] [Updated] (PDFBOX-2882) Improve performance when using scratch file

2015-07-15 Thread Manfred Pock (JIRA)


 [ 
https://issues.apache.org/jira/browse/PDFBOX-2882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manfred Pock updated PDFBOX-2882:
-
Attachment: binary4564603505550490973.pdf

 Improve performance when using scratch file
 ---

 Key: PDFBOX-2882
 URL: https://issues.apache.org/jira/browse/PDFBOX-2882
 Project: PDFBox
  Issue Type: Improvement
  Components: Parsing
Affects Versions: 2.0.0
Reporter: Timo Boehme
Assignee: Timo Boehme
Priority: Minor
 Attachments: ScratchFile.java, ScratchFileBuffer.java, 
 binary4564603505550490973.pdf


 The current scratch file implementation uses many direct I/O calls which 
 slows down parsing compared with in-memory scratch buffer considerably.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: Performance of the trunkversion

2015-07-15 Thread Manfred Pock


Hi Timo,

i have seen and tried it again. I have set maxInMemoryByteSize to 256000 
and i cannot see a real improvement.


But i got an Exception with the appended pdf.

Exception in thread AWT-EventQueue-0 java.lang.NullPointerException
at 
org.apache.pdfbox.contentstream.PDFStreamEngine.showTextStrings(PDFStreamEngine.java:567)
at 
org.apache.pdfbox.rendering.PageDrawer.showTextStrings(PageDrawer.java:297)
at 
org.apache.pdfbox.contentstream.operator.text.ShowTextAdjusted.process(ShowTextAdjusted.java:38)
at 
org.apache.pdfbox.contentstream.PDFStreamEngine.processOperator(PDFStreamEngine.java:795)
at 
org.apache.pdfbox.contentstream.PDFStreamEngine.processStreamOperators(PDFStreamEngine.java:462)
at 
org.apache.pdfbox.contentstream.PDFStreamEngine.processStream(PDFStreamEngine.java:438)
at 
org.apache.pdfbox.contentstream.PDFStreamEngine.processPage(PDFStreamEngine.java:149)

at org.apache.pdfbox.rendering.PageDrawer.drawPage(PageDrawer.java:180)
at 
org.apache.pdfbox.rendering.PDFRenderer.renderPage(PDFRenderer.java:205)
at 
org.apache.pdfbox.rendering.PDFRenderer.renderImage(PDFRenderer.java:136)
at 
org.apache.pdfbox.rendering.PDFRenderer.renderImageWithDPI(PDFRenderer.java:95)


Am 15.07.2015 um 12:28 schrieb Timo Boehme:

Hi Manfred,

there is another update of ScratchFile. It now is able to use a 
certain amount of main memory before using the scratch file. Could you 
give it a try? You will have to change the source a bit since the 
constructor getting the allowed amount of memory is currently not 
supported by PDDocument class. Simply change


public ScratchFile(File scratchFileDirectory) throws IOException
{
this(scratchFileDirectory, 0);
}

to
public ScratchFile(File scratchFileDirectory) throws IOException
{
this(scratchFileDirectory, XX);
}
where XX is the amount of main memory to be used for buffers in 
bytes.


If you use a larger value and the performance still is not same/better 
as the May version than at least it is not the problem of the buffer 
handling for streams.



Best,
Timo


Am 15.07.2015 um 12:20 schrieb Manfred Pock:

Hi Timo,

i have test it with different pdf's and die performance ist nearly of
the version from may. Just a little bit slower.

It will be ok, but it will be nice if it will performe better ;-)

thanks and regarts.
Manfred

Am 15.07.2015 um 10:24 schrieb Timo Boehme:

Hi Manfred,

the issue should be fixed in the updated versions attached to
PDFBOX-2882. Please give them a try.


Timo


Am 15.07.2015 um 09:51 schrieb Manfred Pock:

Hi Timo,

i have tried it put it doesn't work now and i get different exceptions
or Errors

i looks like that there is a problem with any kind of images, the rest
will be shown.

for example:

SCHWERWIEGEND: TIFFFaxDecoder: Invalid code encountered while decoding
2D group 4 compressed data.
java.io.IOException: TIFFFaxDecoder: Invalid code encountered while
decoding 2D group 4 compressed data.
 at
org.apache.pdfbox.filter.ccitt.TIFFFaxDecoder.decodeT6(TIFFFaxDecoder.java:1125) 




 at
org.apache.pdfbox.filter.CCITTFaxFilter.decode(CCITTFaxFilter.java:94)
 at
org.apache.pdfbox.cos.COSStream.attemptDecode(COSStream.java:422)
 at org.apache.pdfbox.cos.COSStream.doDecode(COSStream.java:398)
 at org.apache.pdfbox.cos.COSStream.doDecode(COSStream.java:335)
 at
org.apache.pdfbox.cos.COSStream.getDecodeResult(COSStream.java:278)
 at
org.apache.pdfbox.pdmodel.graphics.image.PDImageXObject.init(PDImageXObject.java:120) 




 at
org.apache.pdfbox.pdmodel.graphics.PDXObject.createXObject(PDXObject.java:67) 




 at
org.apache.pdfbox.pdmodel.PDResources.getXObject(PDResources.java:340)

SCHWERWIEGEND: FlateFilter: stop reading corrupt stream due to a
DataFormatException
Jul 15, 2015 9:45:05 AM 
org.apache.pdfbox.contentstream.PDFStreamEngine

operatorException
WARNUNG: java.util.zip.DataFormatException: invalid block type

Jul 15, 2015 9:46:18 AM 
org.apache.pdfbox.contentstream.PDFStreamEngine

operatorException
WARNUNG: Not a JPEG file: starts with 0xe0 0x00

ul 15, 2015 9:46:23 AM org.apache.pdfbox.contentstream.PDFStreamEngine
operatorException
WARNUNG: Image stream was not read - filter: DCTDecode

SCHWERWIEGEND: java.util.zip.DataFormatException: invalid distance too
far back
java.io.IOException: java.util.zip.DataFormatException: invalid 
distance

too far back
 at 
org.apache.pdfbox.filter.FlateFilter.decode(FlateFilter.java:83)

 at
org.apache.pdfbox.cos.COSStream.attemptDecode(COSStream.java:422)
 at org.apache.pdfbox.cos.COSStream.doDecode(COSStream.java:398)
 at org.apache.pdfbox.cos.COSStream.doDecode(COSStream.java:335)
 at
org.apache.pdfbox.cos.COSStream.checkUnfilteredBuffer(COSStream.java:265) 



 at
org.apache.pdfbox.cos.COSStream.getUnfilteredRandomAccess(COSStream.java:239) 




 at
org.apache.pdfbox.pdfparser.BaseParser.init(BaseParser.java:146

[jira] [Updated] (PDFBOX-2882) Improve performance when using scratch file

2015-07-15 Thread Manfred Pock (JIRA)


 [ 
https://issues.apache.org/jira/browse/PDFBOX-2882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manfred Pock updated PDFBOX-2882:
-
Attachment: (was: binary4564603505550490973.pdf)

 Improve performance when using scratch file
 ---

 Key: PDFBOX-2882
 URL: https://issues.apache.org/jira/browse/PDFBOX-2882
 Project: PDFBox
  Issue Type: Improvement
  Components: Parsing
Affects Versions: 2.0.0
Reporter: Timo Boehme
Assignee: Timo Boehme
Priority: Minor
 Attachments: ScratchFile.java, ScratchFileBuffer.java


 The current scratch file implementation uses many direct I/O calls which 
 slows down parsing compared with in-memory scratch buffer considerably.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: Performance of the trunkversion

2015-07-15 Thread Manfred Pock

Yes, now we have the same performance as the old may-version, it will be ok.

However, better parsing/render-performance would always be fine.

thanks and regarts, Manfred

Am 15.07.2015 um 15:43 schrieb Timo Boehme:
The latest ScratchFile* versions attached to PDFBOX-2882 fix the
described exception and improve on ScratchFileBuffer.clear() command.

Regarding speed test of file provided by Manfred Pock: on my machine
rendering is nearly the same for only scratch file usage vs. using
ScratchFile with allowed main-memory usage vs. not using scratch file:

- first run approx. 1.5 sec, further runs (same VM) 0.15 sec

So we might see the font or other initialization in the beginning,
having the pure file parsing/rendering time in the consecutive runs.

@Manfred: are these values what you would expect?

Best,
Timo

Am 15.07.2015 um 13:03 schrieb Timo Boehme:

I also wouldn't expect an improvement with 256k bytes of in-memory
pages. You should add possibly an 1000 times larger value - or what you
would like to use.

I will later have a look into the reason for your exception.

Timo

Am 15.07.2015 um 12:57 schrieb Manfred Pock:

Hi Timo,

i have seen and tried it again. I have set maxInMemoryByteSize to
256000

and i cannot see a real improvement.

But i got an Exception with the appended pdf.

Exception in thread AWT-EventQueue-0 java.lang.NullPointerException
at
org.apache.pdfbox.contentstream.PDFStreamEngine.showTextStrings(PDFStreamEngine.java:567)

at
org.apache.pdfbox.rendering.PageDrawer.showTextStrings(PageDrawer.java:297)

at
org.apache.pdfbox.contentstream.operator.text.ShowTextAdjusted.process(ShowTextAdjusted.java:38)

at
org.apache.pdfbox.contentstream.PDFStreamEngine.processOperator(PDFStreamEngine.java:795)

at
org.apache.pdfbox.contentstream.PDFStreamEngine.processStreamOperators(PDFStreamEngine.java:462)

at
org.apache.pdfbox.contentstream.PDFStreamEngine.processStream(PDFStreamEngine.java:438)

at
org.apache.pdfbox.contentstream.PDFStreamEngine.processPage(PDFStreamEngine.java:149)

at
org.apache.pdfbox.rendering.PageDrawer.drawPage(PageDrawer.java:180)
at
org.apache.pdfbox.rendering.PDFRenderer.renderPage(PDFRenderer.java:205)

at
org.apache.pdfbox.rendering.PDFRenderer.renderImage(PDFRenderer.java:136)

at
org.apache.pdfbox.rendering.PDFRenderer.renderImageWithDPI(PDFRenderer.java:95)

Am 15.07.2015 um 12:28 schrieb Timo Boehme:

Hi Manfred,

there is another update of ScratchFile. It now is able to use a
certain amount of main memory before using the scratch file. Could you
give it a try? You will have to change the source a bit since the
constructor getting the allowed amount of memory is currently not
supported by PDDocument class. Simply change

public ScratchFile(File scratchFileDirectory) throws IOException
{
this(scratchFileDirectory, 0);
}

to
public ScratchFile(File scratchFileDirectory) throws IOException
{
this(scratchFileDirectory, XX);
}
where XX is the amount of main memory to be used for buffers in
bytes.

If you use a larger value and the performance still is not same/better
as the May version than at least it is not the problem of the buffer
handling for streams.

Best,
Timo

Am 15.07.2015 um 12:20 schrieb Manfred Pock:

Hi Timo,

i have test it with different pdf's and die performance ist nearly of
the version from may. Just a little bit slower.

It will be ok, but it will be nice if it will performe better ;-)

thanks and regarts.
Manfred

Am 15.07.2015 um 10:24 schrieb Timo Boehme:

Hi Manfred,

the issue should be fixed in the updated versions attached to
PDFBOX-2882. Please give them a try.

Timo

Am 15.07.2015 um 09:51 schrieb Manfred Pock:

Hi Timo,

i have tried it put it doesn't work now and i get different
exceptions
or Errors

i looks like that there is a problem with any kind of images, the
rest
will be shown.

for example:

SCHWERWIEGEND: TIFFFaxDecoder: Invalid code encountered while
decoding
2D group 4 compressed data.
java.io.IOException: TIFFFaxDecoder: Invalid code encountered while
decoding 2D group 4 compressed data.
at
org.apache.pdfbox.filter.ccitt.TIFFFaxDecoder.decodeT6(TIFFFaxDecoder.java:1125)

at
org.apache.pdfbox.filter.CCITTFaxFilter.decode(CCITTFaxFilter.java:94)

at
org.apache.pdfbox.cos.COSStream.attemptDecode(COSStream.java:422)
at
org.apache.pdfbox.cos.COSStream.doDecode(COSStream.java:398)
at
org.apache.pdfbox.cos.COSStream.doDecode(COSStream.java:335)

at
org.apache.pdfbox.cos.COSStream.getDecodeResult(COSStream.java:278)
at
org.apache.pdfbox.pdmodel.graphics.image.PDImageXObject.init(PDImageXObject.java:120)

at
org.apache.pdfbox.pdmodel.graphics.PDXObject.createXObject(PDXObject.java:67)

at
org.apache.pdfbox.pdmodel.PDResources.getXObject(PDResources.java:340)

SCHWERWIEGEND: FlateFilter: stop reading corrupt

Performance of the trunkversion

2015-07-14 Thread Manfred Pock


Hi,

we use the Pdfbox-trunkversion to render pdf's, currently we use the 
version from 12. May 2015.


Today i have done an update to the current version and have test it. It 
seems to be that it need now much more time to render pdf's, it depends 
of the size of the pdf.


for example you can try this one:

http://cloud.directupload.net/15bu

It need five times more then the version from May 2015.

regarts, Manfred

Re: Performance of the trunkversion

2015-07-14 Thread Manfred Pock


Yes, the input is a inputstream. I can try it direct from file.

But in general we get the pdf from an document management system as stream.
Does make sense that i save the pdf to file before?

Why is there so an big performance difference beetween the version from 
May and the current version, if we use it with useScratchFiles = true ?


regarts, Manfred

Am 14.07.2015 um 12:02 schrieb Andreas Lehmkühler:

Hi,


Manfred Pock pock.manf...@gmail.com hat am 14. Juli 2015 um 11:39
geschrieben:


Ok, we load the pdf with useScratchFiles = true, if we load them with
false the performance is better, but a little bit slower than the old one.

What do you use as input, a stream or a real file? If the latter you should use
the load method with the file parameter.

PDFBox needs ramdom access to the pdf and if a stream is provided PDFBox copies
the data to a file (lower memory usage, slower performance) or to the memory
(higher memory usage, better performance).

BR
Andreas



But now it need more memory. I cannot load some pdfs with the current
version with the same java-memory configuration.

Am 14.07.2015 um 11:26 schrieb Manfred Pock:

Hi,

we use the Pdfbox-trunkversion to render pdf's, currently we use the
version from 12. May 2015.

Today i have done an update to the current version and have test it.
It seems to be that it need now much more time to render pdf's, it
depends of the size of the pdf.

for example you can try this one:

http://cloud.directupload.net/15bu

It need five times more then the version from May 2015.

regarts, Manfred

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




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

rotation info of PDImage

2015-07-07 Thread Manfred Pock


Hi,

is there a possiblity that i can get the rotation of an PDImageObject.

The rotation of the page is 90 degrees, and it seems to be that the 
embedded Pdimage also have this rotation.

How can i get this information from PDImage-Obj?

regarts, Manfred

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

Re: PDF-File cannot be viewed on current trunk version

2015-05-11 Thread Manfred Pock


Ok, try to download it at: http://cloud.directupload.net/10zR

Manfred

Am 06.05.2015 um 17:14 schrieb Tilman Hausherr:

Please upload the document to a public place, if possible.
Tilman

Am 06.05.2015 um 11:45 schrieb Manfred Pock:
PDF-File cannot be viewed on current trunk version, is there any 
solution or workarround.


enclosed the pdf-file

I got this exception:

Exception in thread AWT-EventQueue-0 
java.lang.UnsupportedOperationException: not supported for Type 3 fonts
at 
org.apache.pdfbox.pdmodel.font.PDType3Font.readEncodingFromFont(PDType3Font.java:68)
at 
org.apache.pdfbox.pdmodel.font.PDSimpleFont.readEncodingFromDictionary(PDSimpleFont.java:147)
at 
org.apache.pdfbox.pdmodel.font.PDSimpleFont.readEncoding(PDSimpleFont.java:106)
at 
org.apache.pdfbox.pdmodel.font.PDType3Font.init(PDType3Font.java:56)
at 
org.apache.pdfbox.pdmodel.font.PDFontFactory.createFont(PDFontFactory.java:79)
at 
org.apache.pdfbox.pdmodel.PDResources.getFont(PDResources.java:96)
at 
org.apache.pdfbox.contentstream.operator.text.SetFontAndSize.process(SetFontAndSize.java:50)
at 
org.apache.pdfbox.contentstream.PDFStreamEngine.processOperator(PDFStreamEngine.java:802)
at 
org.apache.pdfbox.contentstream.PDFStreamEngine.processStreamOperators(PDFStreamEngine.java:464)
at 
org.apache.pdfbox.contentstream.PDFStreamEngine.processStream(PDFStreamEngine.java:438)
at 
org.apache.pdfbox.contentstream.PDFStreamEngine.processPage(PDFStreamEngine.java:149)
at 
org.apache.pdfbox.rendering.PageDrawer.drawPage(PageDrawer.java:179)
at 
org.apache.pdfbox.rendering.PDFRenderer.renderPage(PDFRenderer.java:205)
at 
org.apache.pdfbox.rendering.PDFRenderer.renderImage(PDFRenderer.java:136)
at 
org.apache.pdfbox.rendering.PDFRenderer.renderImageWithDPI(PDFRenderer.java:95)

at Softline.awt.Pdf.PdfPagePanel.getImage(PdfPagePanel.java:2275)
at Softline.awt.Pdf.PdfPagePanel.paint(PdfPagePanel.java:2320)
at javax.swing.JComponent.paintChildren(JComponent.java:887)
at javax.swing.JComponent.paint(JComponent.java:1063)
at javax.swing.JViewport.paint(JViewport.java:728)
at javax.swing.JComponent.paintChildren(JComponent.java:887)
at javax.swing.JComponent.paint(JComponent.java:1063)
at javax.swing.JComponent.paintChildren(JComponent.java:887)
at javax.swing.JComponent.paint(JComponent.java:1063)
at javax.swing.JComponent.paintChildren(JComponent.java:887)
at javax.swing.JComponent.paint(JComponent.java:1063)
at javax.swing.JComponent.paintChildren(JComponent.java:887)
at javax.swing.JComponent.paint(JComponent.java:1063)
at javax.swing.JLayeredPane.paint(JLayeredPane.java:586)
at javax.swing.JComponent.paintChildren(JComponent.java:887)
at javax.swing.JComponent.paintToOffscreen(JComponent.java:5229)
at 
javax.swing.RepaintManager$PaintManager.paintDoubleBuffered(RepaintManager.java:1572)
at 
javax.swing.RepaintManager$PaintManager.paint(RepaintManager.java:1495)

at javax.swing.RepaintManager.paint(RepaintManager.java:1265)
at javax.swing.JComponent.paint(JComponent.java:1040)
at 
java.awt.GraphicsCallback$PaintCallback.run(GraphicsCallback.java:39)
at 
sun.awt.SunGraphicsCallback.runOneComponent(SunGraphicsCallback.java:79)
at 
sun.awt.SunGraphicsCallback.runComponents(SunGraphicsCallback.java:116)

at java.awt.Container.paint(Container.java:1973)
at java.awt.Window.paint(Window.java:3901)
at javax.swing.RepaintManager$4.run(RepaintManager.java:835)
at javax.swing.RepaintManager$4.run(RepaintManager.java:807)
at java.security.AccessController.doPrivileged(Native Method)
at 
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)
at 
javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:807)
at 
javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:782)
at 
javax.swing.RepaintManager.prePaintDirtyRegions(RepaintManager.java:731)

at javax.swing.RepaintManager.access$1300(RepaintManager.java:64)
at 
javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1720)

at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:749)
at java.awt.EventQueue.access$500(EventQueue.java:97)
at java.awt.EventQueue$3.run(EventQueue.java:702)
at java.awt.EventQueue$3.run(EventQueue.java:696)
at java.security.AccessController.doPrivileged(Native Method)
at 
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)

at java.awt.EventQueue.dispatchEvent(EventQueue.java:719)
at 
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
at 
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
at 
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
at 
java.awt.EventDispatchThread.pumpEvents

Re: PDF-File cannot be viewed on current trunk version

2015-05-11 Thread Manfred Pock

Thanks John, for the hint, but i have done an svn update before, no 
difference.


My current Revision of PDType3Font is *164506812.12.14 21:54 12
jahewsonPDFBOX-922: Encode content stream text using PDFont.


- Manfred


Am 06.05.2015 um 19:10 schrieb John Hewson:

You’re actually using a slightly outdated version of trunk. Do an “svn update”.

— John


On 6 May 2015, at 02:45, Manfred Pock pock.manf...@gmail.com wrote:

PDF-File cannot be viewed on current trunk version, is there any solution or 
workarround.

enclosed the pdf-file

I got this exception:

Exception in thread AWT-EventQueue-0 java.lang.UnsupportedOperationException: 
not supported for Type 3 fonts
at 
org.apache.pdfbox.pdmodel.font.PDType3Font.readEncodingFromFont(PDType3Font.java:68)
at 
org.apache.pdfbox.pdmodel.font.PDSimpleFont.readEncodingFromDictionary(PDSimpleFont.java:147)
at 
org.apache.pdfbox.pdmodel.font.PDSimpleFont.readEncoding(PDSimpleFont.java:106)
at org.apache.pdfbox.pdmodel.font.PDType3Font.init(PDType3Font.java:56)
at 
org.apache.pdfbox.pdmodel.font.PDFontFactory.createFont(PDFontFactory.java:79)
at org.apache.pdfbox.pdmodel.PDResources.getFont(PDResources.java:96)
at 
org.apache.pdfbox.contentstream.operator.text.SetFontAndSize.process(SetFontAndSize.java:50)
at 
org.apache.pdfbox.contentstream.PDFStreamEngine.processOperator(PDFStreamEngine.java:802)
at 
org.apache.pdfbox.contentstream.PDFStreamEngine.processStreamOperators(PDFStreamEngine.java:464)
at 
org.apache.pdfbox.contentstream.PDFStreamEngine.processStream(PDFStreamEngine.java:438)
at 
org.apache.pdfbox.contentstream.PDFStreamEngine.processPage(PDFStreamEngine.java:149)
at org.apache.pdfbox.rendering.PageDrawer.drawPage(PageDrawer.java:179)
at org.apache.pdfbox.rendering.PDFRenderer.renderPage(PDFRenderer.java:205)
at org.apache.pdfbox.rendering.PDFRenderer.renderImage(PDFRenderer.java:136)
at 
org.apache.pdfbox.rendering.PDFRenderer.renderImageWithDPI(PDFRenderer.java:95)
at Softline.awt.Pdf.PdfPagePanel.getImage(PdfPagePanel.java:2275)
at Softline.awt.Pdf.PdfPagePanel.paint(PdfPagePanel.java:2320)
at javax.swing.JComponent.paintChildren(JComponent.java:887)
at javax.swing.JComponent.paint(JComponent.java:1063)
at javax.swing.JViewport.paint(JViewport.java:728)
at javax.swing.JComponent.paintChildren(JComponent.java:887)
at javax.swing.JComponent.paint(JComponent.java:1063)
at javax.swing.JComponent.paintChildren(JComponent.java:887)
at javax.swing.JComponent.paint(JComponent.java:1063)
at javax.swing.JComponent.paintChildren(JComponent.java:887)
at javax.swing.JComponent.paint(JComponent.java:1063)
at javax.swing.JComponent.paintChildren(JComponent.java:887)
at javax.swing.JComponent.paint(JComponent.java:1063)
at javax.swing.JLayeredPane.paint(JLayeredPane.java:586)
at javax.swing.JComponent.paintChildren(JComponent.java:887)
at javax.swing.JComponent.paintToOffscreen(JComponent.java:5229)
at 
javax.swing.RepaintManager$PaintManager.paintDoubleBuffered(RepaintManager.java:1572)
at javax.swing.RepaintManager$PaintManager.paint(RepaintManager.java:1495)
at javax.swing.RepaintManager.paint(RepaintManager.java:1265)
at javax.swing.JComponent.paint(JComponent.java:1040)
at java.awt.GraphicsCallback$PaintCallback.run(GraphicsCallback.java:39)
at sun.awt.SunGraphicsCallback.runOneComponent(SunGraphicsCallback.java:79)
at sun.awt.SunGraphicsCallback.runComponents(SunGraphicsCallback.java:116)
at java.awt.Container.paint(Container.java:1973)
at java.awt.Window.paint(Window.java:3901)
at javax.swing.RepaintManager$4.run(RepaintManager.java:835)
at javax.swing.RepaintManager$4.run(RepaintManager.java:807)
at java.security.AccessController.doPrivileged(Native Method)
at 
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:807)
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:782)
at javax.swing.RepaintManager.prePaintDirtyRegions(RepaintManager.java:731)
at javax.swing.RepaintManager.access$1300(RepaintManager.java:64)
at 
javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1720)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:749)
at java.awt.EventQueue.access$500(EventQueue.java:97)
at java.awt.EventQueue$3.run(EventQueue.java:702)
at java.awt.EventQueue$3.run(EventQueue.java:696)
at java.security.AccessController.doPrivileged(Native Method)
at 
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:719)
at 
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201

Re: PDF-File cannot be viewed on current trunk version

2015-05-11 Thread Manfred Pock


Great, i have tried it again and it works!

Thanks for fixing.

- Manfred

Am 11.05.2015 um 23:09 schrieb John Hewson:

Ok, I’ve fixed this issue now. Thanks for reporting it.

— John


On 11 May 2015, at 01:55, Manfred Pock pock.manf...@gmail.com wrote:

Ok, try to download it at: http://cloud.directupload.net/10zR

Manfred

Am 06.05.2015 um 17:14 schrieb Tilman Hausherr:

Please upload the document to a public place, if possible.
Tilman

Am 06.05.2015 um 11:45 schrieb Manfred Pock:

PDF-File cannot be viewed on current trunk version, is there any solution or 
workarround.

enclosed the pdf-file

I got this exception:

Exception in thread AWT-EventQueue-0 java.lang.UnsupportedOperationException: 
not supported for Type 3 fonts
at 
org.apache.pdfbox.pdmodel.font.PDType3Font.readEncodingFromFont(PDType3Font.java:68)
at 
org.apache.pdfbox.pdmodel.font.PDSimpleFont.readEncodingFromDictionary(PDSimpleFont.java:147)
at 
org.apache.pdfbox.pdmodel.font.PDSimpleFont.readEncoding(PDSimpleFont.java:106)
at org.apache.pdfbox.pdmodel.font.PDType3Font.init(PDType3Font.java:56)
at 
org.apache.pdfbox.pdmodel.font.PDFontFactory.createFont(PDFontFactory.java:79)
at org.apache.pdfbox.pdmodel.PDResources.getFont(PDResources.java:96)
at 
org.apache.pdfbox.contentstream.operator.text.SetFontAndSize.process(SetFontAndSize.java:50)
at 
org.apache.pdfbox.contentstream.PDFStreamEngine.processOperator(PDFStreamEngine.java:802)
at 
org.apache.pdfbox.contentstream.PDFStreamEngine.processStreamOperators(PDFStreamEngine.java:464)
at 
org.apache.pdfbox.contentstream.PDFStreamEngine.processStream(PDFStreamEngine.java:438)
at 
org.apache.pdfbox.contentstream.PDFStreamEngine.processPage(PDFStreamEngine.java:149)
at org.apache.pdfbox.rendering.PageDrawer.drawPage(PageDrawer.java:179)
at org.apache.pdfbox.rendering.PDFRenderer.renderPage(PDFRenderer.java:205)
at org.apache.pdfbox.rendering.PDFRenderer.renderImage(PDFRenderer.java:136)
at 
org.apache.pdfbox.rendering.PDFRenderer.renderImageWithDPI(PDFRenderer.java:95)
at Softline.awt.Pdf.PdfPagePanel.getImage(PdfPagePanel.java:2275)
at Softline.awt.Pdf.PdfPagePanel.paint(PdfPagePanel.java:2320)
at javax.swing.JComponent.paintChildren(JComponent.java:887)
at javax.swing.JComponent.paint(JComponent.java:1063)
at javax.swing.JViewport.paint(JViewport.java:728)
at javax.swing.JComponent.paintChildren(JComponent.java:887)
at javax.swing.JComponent.paint(JComponent.java:1063)
at javax.swing.JComponent.paintChildren(JComponent.java:887)
at javax.swing.JComponent.paint(JComponent.java:1063)
at javax.swing.JComponent.paintChildren(JComponent.java:887)
at javax.swing.JComponent.paint(JComponent.java:1063)
at javax.swing.JComponent.paintChildren(JComponent.java:887)
at javax.swing.JComponent.paint(JComponent.java:1063)
at javax.swing.JLayeredPane.paint(JLayeredPane.java:586)
at javax.swing.JComponent.paintChildren(JComponent.java:887)
at javax.swing.JComponent.paintToOffscreen(JComponent.java:5229)
at 
javax.swing.RepaintManager$PaintManager.paintDoubleBuffered(RepaintManager.java:1572)
at javax.swing.RepaintManager$PaintManager.paint(RepaintManager.java:1495)
at javax.swing.RepaintManager.paint(RepaintManager.java:1265)
at javax.swing.JComponent.paint(JComponent.java:1040)
at java.awt.GraphicsCallback$PaintCallback.run(GraphicsCallback.java:39)
at sun.awt.SunGraphicsCallback.runOneComponent(SunGraphicsCallback.java:79)
at sun.awt.SunGraphicsCallback.runComponents(SunGraphicsCallback.java:116)
at java.awt.Container.paint(Container.java:1973)
at java.awt.Window.paint(Window.java:3901)
at javax.swing.RepaintManager$4.run(RepaintManager.java:835)
at javax.swing.RepaintManager$4.run(RepaintManager.java:807)
at java.security.AccessController.doPrivileged(Native Method)
at 
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:807)
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:782)
at javax.swing.RepaintManager.prePaintDirtyRegions(RepaintManager.java:731)
at javax.swing.RepaintManager.access$1300(RepaintManager.java:64)
at 
javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1720)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:749)
at java.awt.EventQueue.access$500(EventQueue.java:97)
at java.awt.EventQueue$3.run(EventQueue.java:702)
at java.awt.EventQueue$3.run(EventQueue.java:696)
at java.security.AccessController.doPrivileged(Native Method)
at 
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:719)
at 
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java

PDF-File cannot be viewed on current trunk version

2015-05-06 Thread Manfred Pock

PDF-File cannot be viewed on current trunk version, is there any 
solution or workarround.


enclosed the pdf-file

I got this exception:

Exception in thread AWT-EventQueue-0 
java.lang.UnsupportedOperationException: not supported for Type 3 fonts
at 
org.apache.pdfbox.pdmodel.font.PDType3Font.readEncodingFromFont(PDType3Font.java:68)
at 
org.apache.pdfbox.pdmodel.font.PDSimpleFont.readEncodingFromDictionary(PDSimpleFont.java:147)
at 
org.apache.pdfbox.pdmodel.font.PDSimpleFont.readEncoding(PDSimpleFont.java:106)
at 
org.apache.pdfbox.pdmodel.font.PDType3Font.init(PDType3Font.java:56)
at 
org.apache.pdfbox.pdmodel.font.PDFontFactory.createFont(PDFontFactory.java:79)

at org.apache.pdfbox.pdmodel.PDResources.getFont(PDResources.java:96)
at 
org.apache.pdfbox.contentstream.operator.text.SetFontAndSize.process(SetFontAndSize.java:50)
at 
org.apache.pdfbox.contentstream.PDFStreamEngine.processOperator(PDFStreamEngine.java:802)
at 
org.apache.pdfbox.contentstream.PDFStreamEngine.processStreamOperators(PDFStreamEngine.java:464)
at 
org.apache.pdfbox.contentstream.PDFStreamEngine.processStream(PDFStreamEngine.java:438)
at 
org.apache.pdfbox.contentstream.PDFStreamEngine.processPage(PDFStreamEngine.java:149)

at org.apache.pdfbox.rendering.PageDrawer.drawPage(PageDrawer.java:179)
at 
org.apache.pdfbox.rendering.PDFRenderer.renderPage(PDFRenderer.java:205)
at 
org.apache.pdfbox.rendering.PDFRenderer.renderImage(PDFRenderer.java:136)
at 
org.apache.pdfbox.rendering.PDFRenderer.renderImageWithDPI(PDFRenderer.java:95)

at Softline.awt.Pdf.PdfPagePanel.getImage(PdfPagePanel.java:2275)
at Softline.awt.Pdf.PdfPagePanel.paint(PdfPagePanel.java:2320)
at javax.swing.JComponent.paintChildren(JComponent.java:887)
at javax.swing.JComponent.paint(JComponent.java:1063)
at javax.swing.JViewport.paint(JViewport.java:728)
at javax.swing.JComponent.paintChildren(JComponent.java:887)
at javax.swing.JComponent.paint(JComponent.java:1063)
at javax.swing.JComponent.paintChildren(JComponent.java:887)
at javax.swing.JComponent.paint(JComponent.java:1063)
at javax.swing.JComponent.paintChildren(JComponent.java:887)
at javax.swing.JComponent.paint(JComponent.java:1063)
at javax.swing.JComponent.paintChildren(JComponent.java:887)
at javax.swing.JComponent.paint(JComponent.java:1063)
at javax.swing.JLayeredPane.paint(JLayeredPane.java:586)
at javax.swing.JComponent.paintChildren(JComponent.java:887)
at javax.swing.JComponent.paintToOffscreen(JComponent.java:5229)
at 
javax.swing.RepaintManager$PaintManager.paintDoubleBuffered(RepaintManager.java:1572)
at 
javax.swing.RepaintManager$PaintManager.paint(RepaintManager.java:1495)

at javax.swing.RepaintManager.paint(RepaintManager.java:1265)
at javax.swing.JComponent.paint(JComponent.java:1040)
at 
java.awt.GraphicsCallback$PaintCallback.run(GraphicsCallback.java:39)
at 
sun.awt.SunGraphicsCallback.runOneComponent(SunGraphicsCallback.java:79)
at 
sun.awt.SunGraphicsCallback.runComponents(SunGraphicsCallback.java:116)

at java.awt.Container.paint(Container.java:1973)
at java.awt.Window.paint(Window.java:3901)
at javax.swing.RepaintManager$4.run(RepaintManager.java:835)
at javax.swing.RepaintManager$4.run(RepaintManager.java:807)
at java.security.AccessController.doPrivileged(Native Method)
at 
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)
at 
javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:807)
at 
javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:782)
at 
javax.swing.RepaintManager.prePaintDirtyRegions(RepaintManager.java:731)

at javax.swing.RepaintManager.access$1300(RepaintManager.java:64)
at 
javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1720)

at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:749)
at java.awt.EventQueue.access$500(EventQueue.java:97)
at java.awt.EventQueue$3.run(EventQueue.java:702)
at java.awt.EventQueue$3.run(EventQueue.java:696)
at java.security.AccessController.doPrivileged(Native Method)
at 
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)

at java.awt.EventQueue.dispatchEvent(EventQueue.java:719)
at 
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
at 
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
at 
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
at 
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)

at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

regarts, Manfred

€ String encoding

2015-04-22 Thread Manfred Pock


Hi,

add PDFBox 2.0 (trunk) i have the Problem that the € sign is not correct 
encoded. I have take a look at PDFDocEncoding and maybe there is an bug 
at the method getBytes(String text):


public static byte[] getBytes(String text)
{
ByteArrayOutputStream out = new ByteArrayOutputStream();
for (char c : text.toCharArray())
{
Integer code = UNI_TO_CODE.get(c);
if (code == null)
{
out.write(0);
}
else
{
out.write(c);
}
}
return out.toByteArray();
}

This method look at the UNI_TO_CODE-Map for the required character, but 
it does not write the founded encoded Integer to the outputstream, it 
writes the character?


Is that correkt?

regarts, Manfred

[jira] [Commented] (PDFBOX-2692) Possibility to use our own and/or overwrite PageDrawer class

2015-02-26 Thread Manfred Pock (JIRA)

[
https://issues.apache.org/jira/browse/PDFBOX-2692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14339809#comment-14339809
]

Manfred Pock commented on PDFBOX-2692:
--

I will try this, but i think i have set the annotation to 'not hidden' back
when i store the pdf to view the annotation in an external viewer.

Possibility to use our own and/or overwrite PageDrawer class

Key: PDFBOX-2692
URL: https://issues.apache.org/jira/browse/PDFBOX-2692
Project: PDFBox
Issue Type: Wish
Components: Rendering
Affects Versions: 2.0.0
Environment: JDK 1.8, Windows 7, PDF-Box - current trunk
Reporter: Manfred Pock
Labels: features
Attachments: pdfexample.jpg

We use PDFBox to render PDF's. Additionally, we have the posibility to add
different kinds of annotation (stamp, marks, free text, notes..) like in a
wysiwyg-editor. To do this, it is necessary that we paint these annotations
on our own.
Another reason is not to paint all parts: for example we have a pdf with an
embedded picture. Behind the picture we have the OCR-text to this picture.
This text is only needed for searching und should not be painted.
Thus it would be useful to use our own derived PageDrawer. As I see there are
some things to change.
a.) remove the final from PagerDrawer-class.
b.) make some global-variables (graphics, xform, pageSize...) protected,
c.) also some methods like setRenderingHints should be protected
d.) maybe the possibility to say to the PDFRender which PageDrawer should be
used.

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Issue Comment Deleted] (PDFBOX-2692) Possibility to use our own and/or overwrite PageDrawer class

2015-02-26 Thread Manfred Pock (JIRA)

[
https://issues.apache.org/jira/browse/PDFBOX-2692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Manfred Pock updated PDFBOX-2692:
-
Comment: was deleted

(was: I am not just yet comfortable with that. It would be nicer that we can
say which annotations (and if possible other parts of the pdf) should be
ignored for rendering, and which one not. Just our annotations should not be
rendered in our view. In an external viewer all should be visible.)

Possibility to use our own and/or overwrite PageDrawer class

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Issue Comment Deleted] (PDFBOX-2692) Possibility to use our own and/or overwrite PageDrawer class

2015-02-26 Thread Manfred Pock (JIRA)

[
https://issues.apache.org/jira/browse/PDFBOX-2692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Manfred Pock updated PDFBOX-2692:
-
Comment: was deleted

Possibility to use our own and/or overwrite PageDrawer class

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (PDFBOX-2692) Possibility to use our own and/or overwrite PageDrawer class

2015-02-26 Thread Manfred Pock (JIRA)

[
https://issues.apache.org/jira/browse/PDFBOX-2692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14339822#comment-14339822
]

Manfred Pock commented on PDFBOX-2692:
--

I will profile this again, and if i see a big difference i will attach this pdf.

At our performance-problems, make it sense that we prepare, size down... the
pdf (with an external tool) before we render this?

Possibility to use our own and/or overwrite PageDrawer class

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (PDFBOX-2692) Possibility to use our own and/or overwrite PageDrawer class

2015-02-26 Thread Manfred Pock (JIRA)

[
https://issues.apache.org/jira/browse/PDFBOX-2692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14339807#comment-14339807
]

Manfred Pock commented on PDFBOX-2692:
--

I am not just yet comfortable with that. It would be nicer that we can say
which annotations (and if possible other parts of the pdf) should be ignored
for rendering, and which one not. Just our annotations should not be rendered
in our view. In an external viewer all should be visible.

Possibility to use our own and/or overwrite PageDrawer class

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (PDFBOX-2692) Possibility to use our own and/or overwrite PageDrawer class

2015-02-26 Thread Manfred Pock (JIRA)

[
https://issues.apache.org/jira/browse/PDFBOX-2692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14339805#comment-14339805
]

Manfred Pock commented on PDFBOX-2692:
--

Possibility to use our own and/or overwrite PageDrawer class

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (PDFBOX-2692) Possibility to use our own and/or overwrite PageDrawer class

2015-02-26 Thread Manfred Pock (JIRA)

[
https://issues.apache.org/jira/browse/PDFBOX-2692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14339814#comment-14339814
]

Manfred Pock commented on PDFBOX-2692:
--

To extract the images could be a solution, but we have not just this type of
pdf's.

Possibility to use our own and/or overwrite PageDrawer class

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: [jira] [Commented] (PDFBOX-2692) Possibility to use our own and/or overwrite PageDrawer class

2015-02-26 Thread Manfred Pock

Yes, wie store them into the pdf, it's like an workflow. The first person
put the incomming stamp at the pdf, add some comments, the second the
controller stamp and so one
Am 26.02.2015 17:18 schrieb Maruan Sahyoun (JIRA) j...@apache.org:

[
https://issues.apache.org/jira/browse/PDFBOX-2692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14338632#comment-14338632
]

Maruan Sahyoun commented on PDFBOX-2692:

{quote}
It will be just nice that we can tell the pdfbox-render to ignore our
annotations.
{quote}

So after you have created them you do store them in the PDF or how do your
annotations get in there?

Possibility to use our own and/or overwrite PageDrawer class

We use PDFBox to render PDF's. Additionally, we have the posibility to
add different kinds of annotation (stamp, marks, free text, notes..) like
in a wysiwyg-editor. To do this, it is necessary that we paint these
annotations on our own.
Another reason is not to paint all parts: for example we have a pdf with
an embedded picture. Behind the picture we have the OCR-text to this
picture. This text is only needed for searching und should not be painted.
Thus it would be useful to use our own derived PageDrawer. As I see
there are some things to change.
a.) remove the final from PagerDrawer-class.
b.) make some global-variables (graphics, xform, pageSize...) protected,
c.) also some methods like setRenderingHints should be protected
d.) maybe the possibility to say to the PDFRender which PageDrawer
should be used.

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (PDFBOX-2692) Possibility to use our own and/or overwrite PageDrawer class

2015-02-26 Thread Manfred Pock (JIRA)

[
https://issues.apache.org/jira/browse/PDFBOX-2692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14338605#comment-14338605
]

Manfred Pock commented on PDFBOX-2692:
--

That's what, i mean, if the pdf-renderer has to render the annotation this
would be so. That's the reason that we render self our annotation. This part is
working well.

It will be just nice that we can tell the pdfbox-render to ignore our
annotations.

Possibility to use our own and/or overwrite PageDrawer class

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (PDFBOX-2692) Possibility to use our own and/or overwrite PageDrawer class

2015-02-26 Thread Manfred Pock (JIRA)

[
https://issues.apache.org/jira/browse/PDFBOX-2692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14338296#comment-14338296
]

Manfred Pock commented on PDFBOX-2692:
--

Hello John, Tilman and Maruan,

Thanks for your answer and I unterstand your view.

Our annotation are should be viewed on the top of the Pdf and should also be
visible in external viewer like Acrobat Reader.

We have to paint them at our own because we will edit it like in an
wysiwg-editor. Move and drag with the mouse, resize, show selection of the
current annotation, change text and so one (see attached image), I think this
all will not work direct in the pdfbox.
Current we render the pdf to an bufferedimage and view this image (which are
the general as i know). On the top of this image we show our annotations. If we
use the Pdfbox to render our annotations we always have to rerender the whole
page if we change any annotation. As I know the perfomance of pdfbox at
rendering, this would never work in an usable user experience. (Just the
rendering direct in pdfbox of this annotations does also not work very fine, as
I remember, it's a few week ago as i have tried this).

About the OCR text, it's not direct a problem, it's rendering mode is NEITHER
and the are not shown. We just want to filter this off performance issues. (In
general we have some perfomance problem with the rendering. do you have a any
tip what we can to for a better rendering performance.)

Maybe will be a kind of filter or an annotationhandler as maruan means a
solution.

Possibility to use our own and/or overwrite PageDrawer class

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (PDFBOX-2692) Possibility to use our own and/or overwrite PageDrawer class

2015-02-26 Thread Manfred Pock (JIRA)

[
https://issues.apache.org/jira/browse/PDFBOX-2692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Manfred Pock updated PDFBOX-2692:
-
Attachment: pdfexample.jpg

Possibility to use our own and/or overwrite PageDrawer class

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (PDFBOX-2692) Possibilty to use an own PageDrawer and/or overwrite the PageDrawer

2015-02-25 Thread Manfred Pock (JIRA)

Manfred Pock created PDFBOX-2692:


 Summary: Possibilty to use an own PageDrawer and/or overwrite the 
PageDrawer
 Key: PDFBOX-2692
 URL: https://issues.apache.org/jira/browse/PDFBOX-2692
 Project: PDFBox
  Issue Type: Wish
  Components: Rendering
Affects Versions: 2.0.0
 Environment: JDK 1.8, Windows 7, PDF-Box - current trunk
Reporter: Manfred Pock


We use the PDFBox to render PDF's. As addition we has also has the posibility 
to add different kinds of annotation (stamp, marks, free text, notes..) like in 
an wysiwyg-editor To do this it is necessary that we paint this annotations at 
our own.

Another reason is not to paint all parts, as example we have an pdf with an 
embedded picture. Behind the picture we have the ocr-text to this picture. This 
text is only necessary for searching und should not be painted.

And so it will be fine that we can use an own derivated PageDrawer. As i see 
there are some things to change.

a.) remove the final from PagerDrawer-class.
b.) make some global-variables (graphics, xform, pageSize...) protected,
c.) also some methods like setRenderingHints should be protected
d.) maybe the possibility to say to the PDFRender which PageDrawer should  be 
used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Use your own PageDrawer...

2015-02-24 Thread Manfred Pock


Hi,

why it ist not allowed to derivate or set the an own PageDrawer at the 
current trunk-version of Pdfbox.


It is not possible to derivate it because the PageDrawer is final. It's 
also not possible to set the PageDrawer because he is defined fixed in 
PDFRenderer.


I need this, because i want to paint some annotation at my own. The only 
thing i can to without any Pdfbox-codechanges to remove this annotations 
before i render it.


Could there be a better solution.

Regarts, Manfred

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

Question about Viewing Pdf's

2015-01-12 Thread Manfred Pock


Hello,

we use the Pdfbox to viewing pdf's in our software. Actually we use the 
version 1.6.0  in general it works fine (excepts memory and perfomance 
problem). But in last time we have problems to show different pdf's and 
so we decite to switch direct version of the trunk to get the latest 
features. All problem-pdf's can be viewed now.


But we have a problem with the viewing size. We has embedded the 
PageDrawer in an JScrollpane and added some zooming-feature to our 
pdfviewer.  There we have the problem that the PageDrawer paint also 
outside of der viewing Area of der Scrollpane. It seem to be a problem 
in the PdfStreamEngine (line 130). For the clipping it uses the 
PDGraphicsState setted in the graphicStack. This one is set to the size 
of the CropBox. To set the CropBox outside have some side-effects and to 
not work. A solution, that work for us, is to give with parameters that 
define the actually viewing area.


It's possible to integrate something like this?

best regarts, Manfred

46 matches

Mail list logo