On Thu Aug 28/2008 @ 12:08:P +0100 asdasd, Paulo Soares wrote:
> PDF files can't be compared byte by byte. Testing PDF files is very
> hard and it's not the font order that is going to make any difference.
Paulo,
Your response is not only completely incorrect, but also seems to
betray a poor attitude towards people who contribute fixes
to iText. I have contributed fixes to iText in the past and I
would like to continue to do so, but your attitude is a bit
frustrating.
First, you have said that such a change is not necessary. This
is incorrect and goes against a fundamental principles of
testable software:
In the absence of randomness (e.g. crypto), the exact
same code should generate the exact same output.
This is a very valuable behavior because it allows you to
regression test your code changes in a very easy way, for
example "I made a change to iText which should not affect
the output format in any way, let me verify this".
You also wrote:
"I wonder why the dictionary keys shouldn't also be ordered,
you forgot that one".
No, I didn't forget that one. PdfDictionary uses PdfName objects
as keys. PdfName has an overridden hashCode method and therefore
the same PdfName object will always have the same hashCode.
This also means that if PdfName objects are added to
java.util.HashMap in the same order, the iteration order will
always be the same (unless the HashMap source code changes in
a drastic way, which could only happen if you upgrade your JDK
and even then it is quite rare).
You also wrote:
"[the fix] makes it slower, wastes memory"
Come on. The memory difference is negligible. Java objects are
stored by reference, so the memory overhead will be on the order
of 32 extra bits per unique font (64 bits on a 64-bit JDK). Even
if you have 1,000 different unique fonts in the document,
which is actually a huge amount, you are only talking 4kb of
memory -- it is miniscule.
It is not slower at all. My measurements indicated no speed
change whatsoever, which is not surprising considering that
both LinkedHashMap and HashMap have constant-time access
(in other words O(1)).
You also wrote:
"[the fix] is another lock on jdk 1.4 when many are still using
jdk 1.3"
I quote from the iText homepage, http://www.lowagie.com/iText/:
"iText requires JDK 1.4"
Paulo, that pretty much refutes all of the reasons you gave.
Of course, you can still be stubborn and refuse to accept
the patch, in which case I will just have to fork iText under
the terms of the LGPL. I'm hoping that you will agree with
my logic so I don't have to go through those hoops.
Thanks,
c
> Paulo
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On
> > Behalf Of JRudolph
> > Sent: Thursday, August 28, 2008 12:00 PM
> > To: [email protected]
> > Subject: Re: [iText-questions] [patch] output PDF fonts in
> > predictable order
> >
> >
> > Hi!
> >
> > Well, I just stumbled about the same problem. While it is arguably bad
> > practice to compare binary files byte by byte for testing, it
> > is at least
> > the first best option you come up with. (Do you know any better?)
> >
> > I think we can agree on caring about compability as far as
> > possible and not
> > introducing somewhat specific changes. BUT: IMO a tool
> > generating (binary)
> > files should do this in a deterministic and reproducible way,
> > at least in
> > the cases where no explicit non-uniqueness is wanted (like the ID or
> > timestamps). However, even for this cases it would be nice if
> > you could
> > explicitly control these fields.
> >
> > Johannes
> >
> >
> > Paulo Soares wrote:
> > >
> > > Well, I could ask you why should a fix be applied just to
> > ease your unit
> > > testing, as if the font order was any obstacle. I wonder why the
> > > dictionary
> > > keys shouldn'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
> > > must
> > > be ordered to be tested is flawed.
> > >
> > > Paulo
> > >
> > > ----- Original Message -----
> > > From: "Chad Loder" <[EMAIL PROTECTED]>
> > > To: "Post all your questions about iText here"
> > > <[email protected]>
> > > Sent: Wednesday, August 27, 2008 8:31 PM
> > > Subject: Re: [iText-questions] [patch] output PDF fonts in
> > predictable
> > > order
> > >
> > >
> > > Hi Paulo. Can you please elaborate on why the fix won't happen?
> > >
> > > Thanks,
> > > c
> > >
> > > On Wed Aug 27/2008 @ 12:08:P +0100 asdasd, Paulo Soares wrote:
> > >> That fix won't happen, change your testing or your iText code.
> > >>
> > >> Paulo
> > >>
> > >> > -----Original Message-----
> > >> > From: [EMAIL PROTECTED]
> > >> > [mailto:[EMAIL PROTECTED] On
> > >> > Behalf Of Chad Loder
> > >> > Sent: Wednesday, August 27, 2008 3:09 AM
> > >> > To: [email protected]
> > >> > 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 the PdfWriter
> > >> > class. Replacing this use of HashMap with LinkedHashMap
> > >> > solves the problem
> > >> > because LinkedHashMap iterates over its entries in the
> > order they were
> > >> > inserted. LinkedHashMap was added in JDK 1.4 so it will be
> > >> > compatible with
> > >> > the 1.4 requirement that itext has.
> > >> >
> > >> > The following diff fixes the issue and has been tested.
> > >> >
> > >> > Index: itext/java/com/lowagie/text/pdf/PdfWriter.java
> > >> >
> > ===================================================================
> > >> > diff -u -p -r1.1.1.9 PdfWriter.java
> > >> > --- itext/java/com/lowagie/text/pdf/PdfWriter.java 6 Jun
> > >> > 2007 23:11:39 -0000 1.1.1.9
> > >> > +++ itext/java/com/lowagie/text/pdf/PdfWriter.java 26
> > >> > Aug 2008 23:22:06 -0000
> > >> > @@ -57,6 +57,7 @@ import java.util.ArrayList;
> > >> > import java.util.HashMap;
> > >> > import java.util.HashSet;
> > >> > import java.util.Iterator;
> > >> > +import java.util.LinkedHashMap;
> > >> > import java.util.Map;
> > >> > import java.util.TreeMap;
> > >> > import java.util.TreeSet;
> > >> > @@ -1842,7 +1843,7 @@ public class PdfWriter extends DocWriter
> > >> > // [F3] adding fonts
> > >> >
> > >> > /** The fonts of this document */
> > >> > - protected HashMap documentFonts = new HashMap();
> > >> > + protected LinkedHashMap documentFonts = new LinkedHashMap();
> > >> >
> > >> > /** The font number counter for the fonts in the
> > document. */
> > >> > protected int fontNumber = 1;
>
>
> Aviso Legal:
> Esta mensagem ? destinada exclusivamente ao destinat?rio. Pode conter
> informa??o confidencial ou legalmente protegida. A incorrecta transmiss?o
> desta mensagem n?o significa a perca de confidencialidade. Se esta mensagem
> for recebida por engano, por favor envie-a de volta para o remetente e
> apague-a do seu sistema de imediato. ? proibido a qualquer pessoa que n?o o
> destinat?rio de usar, revelar ou distribuir qualquer parte desta mensagem.
>
> Disclaimer:
> This message is destined exclusively to the intended receiver. It may contain
> confidential or legally protected information. The incorrect transmission of
> this message does not mean the loss of its confidentiality. If this message
> is received by mistake, please send it back to the sender and delete it from
> your system immediately. It is forbidden to any person who is not the
> intended receiver to use, distribute or copy any part of this message.
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> iText-questions mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/itext-questions
>
> Buy the iText book: http://www.1t3xt.com/docs/book.php
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
iText-questions mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/itext-questions
Buy the iText book: http://www.1t3xt.com/docs/book.php
