't also be ordered, you forgot that one. The
> > fix doesn't add
> > > anything to iText, makes it slower, wastes memory, is
> > another lock on jdk
> > > 1.4 when many are still using jdk 1.3 and your reasoning
> > that the fonts
> > > mu
rom: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On
> > Behalf Of Chad Loder
> > Sent: Wednesday, August 27, 2008 3:09 AM
> > To: itext-questions@lists.sourceforge.net
> > Subject: [iText-questions] [patch] output PDF fonts in
> > predictable order
> >
One of our issues when unit testing our PDF generation code is that iText
creates PDFs with fonts in an unpredictable order. This makes it impossible
to simply compare checksums of itext-generated PDF files from one change
to the next.
This is due to one particular use of HashMap internally within
On Wed, Sep 12, 2007 at 11:18:47AM +0200, Bruno Lowagie (iText) wrote:
> Bruno Lowagie wrote:
> > Chad Loder wrote:
> >> Hi. Has anyone had a chance to look at this?
>
> > Unfortunately, due to circumstances in my dayjob,
> > I won't be able to look at
Hi. Has anyone had a chance to look at this?
I've attached a sample PDF to show what the output looks like.
Thanks,
c
On Wed, Sep 05, 2007 at 01:47:17PM -0700, Chad Loder wrote:
> Hello. I am experiencing a bug in iText PDF generation where text overlaps an
> image. The s
On Wed, Sep 05, 2007 at 09:01:55PM -0400, Leonard Rosenthol wrote:
> What you are trying to accomplish is called "Redaction" and it is a
> VERY complex operation with PDF, since you can't just draw over - you
> need to actually remove things. As such, iText is NOT the tool for
> the job.
>
t for help.
Please see the attached source code (with accompanying jpg) to see what I
am talking about.
Can someone suggest a fix or a workaround for this problem?
Thanks,
Chad Loder
import java.io.FileOutputStream;
import java.io.IOException;
import com.lowagie.text.
A similar (untested) patch for PNG. I do not know whether TIFF needs similar
logic.
Index: com/lowagie/text/pdf/codec/PngImage.java
===
RCS file:
/usr/local/cvsroot/nexposev4/src/3rdparty/itext/itext/java/com/lowagie/text/pdf/codec/
Two comments to my own diff.
1) Obviously you will want to remove the System.out.println call before
committing.
2) The same change will likely apply to other codecs, which suffer
from a similar (float->int) truncation problem, e.g. PngImage.
On Wed, Jun 27, 2007 at 03:16:23PM -0700, C
I believe the bitmap codec has a floating point truncation error that
causes a 300 dpi bitmap to be processed as 299 dpi. A 300 dpi image
specifies an xPelsPerMeter of 11811, which is multiplied by 0.0254
(one inch in meters), yielding an effective DPI of 299.9994. I do
not think it is correct to t
On Fri, Jun 22, 2007 at 06:38:21PM +0100, Mark Hall wrote:
> On Wednesday 20 June 2007, Chad Loder wrote:
> > I am confused with the way image scaling works in PDF vs. RTF. I have
> > read the May 15th thread between Thomas Bickel and Mark Hall where
> > this is discussed:
>
t sound like I am missing something completely obvious here? Would it
be more helpful for me to create a short test program to demonstrate the
problem?
Thanks,
Chad Loder
-
This SF.net email is sponsored by DB2 Expres
table partnership)? And does anyone else agree with me that this
approach is not quite compatible with Adobe's publicly stated support of open
formats?
Best,
Chad Loder
-
This SF.net email is sponsored by DB2 Expres
ous. There is no
substitute for efficient design.
c
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On
> > Behalf Of Chad Loder
> > Sent: Friday, June 08, 2007 5:51 PM
> > To: Post all your questions about
Paulo,
You're kidding, right? What if the Java heap is only 128mb?
c
On Fri, Jun 08, 2007 at 03:41:58PM +0100, Paulo Soares wrote:
> What's the problem? The GC takes care of that.
>
> Paulo
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On
15 matches
Mail list logo
