Hi All
Just to follow up on this thread, I haven’t yet removed the .properties
functionality.
However, it has now become not just desirable but necessary, as PDFBOX-2358 has
shown that PDFBox is not handling resource loading in an OSGI compatible manner.
Basically, a class shouldn’t load
Hello;
I am just going to jump in and ask about the following warning when used
with the default PDFTextStripper class:
WARNING: Count in xref table is 0 at offset 96825
Attached is the causing document. I thought it may have to do with the
Properties file that Tillman Hausherr pointed out to
+1 for removing the .properties file if the new mechanism is easier to
understand and handle. The discussion doesn’t provide that proof or some
information about that.
How would a replacement look like?
OTOH if it’s a documentation issue we could also add some more information to
the javadocs
Maruan Sahyoun sahy...@fileaffairs.de hat am 30. Juli 2014 um 08:12
geschrieben:
+1 for removing the .properties file if the new mechanism is easier to
understand and handle. The discussion doesn’t provide that proof or some
information about that.
How would a replacement look like?
On 29 Jul 2014, at 23:12, Maruan Sahyoun sahy...@fileaffairs.de wrote:
+1 for removing the .properties file if the new mechanism is easier to
understand and handle. The discussion doesn’t provide that proof or some
information about that.
How would a replacement look like?
Basically like
Hi,
it's not a black and white issue (comments inline)
John Hewson j...@jahewson.com hat am 29. Juli 2014 um 07:44 geschrieben:
Yes, really I should have said subclasses of PDFStreamEngine - that's where
the .properties file originates. I'd propose replacing the properties
mechanism with
On 29 Jul 2014, at 03:44, Andreas Lehmkühler andr...@lehmi.de wrote:
Hi,
it's not a black and white issue (comments inline)
John Hewson j...@jahewson.com hat am 29. Juli 2014 um 07:44 geschrieben:
Yes, really I should have said subclasses of PDFStreamEngine - that's where
the
Hi,
At this time, the problem I see and wanted to solve (PDFBOX-2246) exists
regardless whether we use a properties file or initialize directly in
the code.
Tilman
Am 29.07.2014 19:41, schrieb John Hewson:
On 29 Jul 2014, at 03:44, Andreas Lehmkühler andr...@lehmi.de wrote:
Hi,
it's
We need to get rid of these .properties files, they’re causing endless
confusion, not to mention that they hide runtime dependencies in text files.
We should make it so that overriding a TextStripper, PageDrawer, etc. doesn’t
require external .properties files, currently Preflight works in this
I disagree - one doesn't *have* to pass a property file to
PDFTextStripper and PageDrawer. The properties file for PDFTextStripper
is optional. The property parameter was already there before it became
an apache project.
Tilman
Am 28.07.2014 22:08, schrieb John Hewson:
We need to get rid
Yes, really I should have said subclasses of PDFStreamEngine - that's where
the .properties file originates. I'd propose replacing the properties mechanism
with a simple method containing the mapping which can be overridden in
subclasses. Ultimately, users expect to be able to subclass the
After having written the text below, I tested by including the rg
operator in the properties list and now it worked. I also tested
deleting your println and instead adding this if the text is red:
System.out.print (textPos.getCharacter());
and so I got this output:
21_Key .1295 R~Wall
It is even easier than I thought - replace super() with this:
super(ResourceLoader.loadProperties(org/apache/pdfbox/resources/PageDrawer.properties,
true));
Tilman
Am 27.07.2014 13:03, schrieb Tilman Hausherr:
After having written the text below, I tested by including the rg
operator in the
Tilman;
That is somewhat embarrassing. At one point I brought this to the mailing
list (because of the following warning) and was told to remove that line
because the TextStripper wasn't actually a PageDrawer. The functionality
still worked after that, however.
Is there a way to do this without
Hi,
That didn't happen to me, but maybe it did happen to you with another file.
Another solution would be to pass your own properties file, and it
should have this content:
===
# Licensed to the Apache Software Foundation (ASF) under one or more
# contributor license
Thank you, that works as promised and removes the warning. I'm still hoping
to find a resource that better explains the pieces of PDFBox and how they
work together. Unfortunately most posts on the internet are solely how and
not why.
Appreciate it!
-Aaron
On Sun, Jul 27, 2014 at 8:00 AM,
Hello again. I've been trying to figure out this issue that has come up for
me and in my research I found someone posting on StackOverflow (
http://stackoverflow.com/questions/10844271/how-to-get-font-color-using-pdfbox)
a similar issue where they could not read any colors from a PDF. The user
Hi,
Please upload the PDF somewhere and post the URL, PDF files are removed
from the mailing list.
Tilman
Am 27.07.2014 02:35, schrieb -A:
Hello again. I've been trying to figure out this issue that has come
up for me and in my research I found someone posting on StackOverflow
No problem, and done.
They can be found here:
Java File: http://www.hrtmn.net/Misc/IncrementalPDFStripper.java
PDF: http://www.hrtmn.net/Misc/test.pdf
The attached Java file should print true when ran on the test pdf, but only
ever returns false for me.
On Sat, Jul 26, 2014 at 11:43 PM,
19 matches
Mail list logo
