RE: PdfGraphics2D class (RE: [iText-questions] generating graphs )

[Paulo Soares]

 -Original Message-
 From: Kevin Galligan [SMTP:[EMAIL PROTECTED]]
 Sent: Thursday, April 11, 2002 3:52
 To:   'Jeremy Bowman'; [EMAIL PROTECTED]
 Subject:  RE: PdfGraphics2D class (RE:  [iText-questions] generating
 graphs )
 
 I think you'll have to forget copyArea as well.  Much of the Graphics 2D
 spec is targeted to raster graphics (although printing from java apps is
 supported by the G2D object as well).  There's certainly a lot we can do
 with the primitives, but some of them are really not going to work out.
 Unless the pdf spec includes a copyArea style primitive, there are really
 only 2 options.  Create an off-screen buffer and paint the image to the
 pdf
 (-- bad), or record all function calls, traslate, clip, and play back all
 the paints.  I'm not very familiar with templates, but is that basically
 what a template is?  Then I guess copyArea wouldn't be that bad (assuming
 you can clip the repaint of the template).  Can you paint a template to a
 template?  To handle copyArea you'd have to create a new template, paint
 the
 old one to it, translate, clip, paint the old template again, then go from
 there with the new template.  I've done some java games, and that's the
 only
 place I've ever seen copyArea used.  It seems like more of an interactive
 thing.
 
copyArea is raster oriented. If it's needed it's best to draw to a
BufferedImage.

 Some of the paint object stuff is hairy as well.  Its designed to describe
 a
 raster paint.  You'd have to somehow map that to pdf's equation stuff
 (which
 I'm also not an expert of).  I have both the O'Reilly Java 2D Graphics and
 the Adobe PDF Reference books.  I'd highly recommend both for this type of
 thing.
 
Things are better here. Jim's implementation even supports textures.
I provided an example with this yesterday.

 As far as the graphics state, I can't imagine how you would do this
 without
 that.  You'd never be able to back out of your clipping.  You also
 wouldn't
 be able to return the document back to its original state.  If you have
 the
 saves and restores balanced it'll work.  Debugging pdf output is not easy.
 
This is not hard, it's only a matter of balancing save/restore and
keeping track of the setColorFill().

 To figure out my clipping problem I have to modify the PdfContentByte code
 to print the pdf doc without encryption.
 
Use Document.compress = false to disable compression.

Best Regards,
Paulo Soares

 -Kevin
 
  -Original Message-
  From: Jeremy Bowman [mailto:[EMAIL PROTECTED]]
  Sent: Wednesday, April 10, 2002 10:26 PM
  To: [EMAIL PROTECTED]
  Subject: Re: PdfGraphics2D class (RE: [iText-questions] generating
  graphs)
  
  
  Wow, there was a lot of discussion on this today...I'll just 
  throw out some 
  responses to points Jim made in case any of it is useful:
  
   Right now, though the drawing target has changed to a 
  template, the rest is
   still based around a document and writer (required in 
  constructor). Maybe it
   makes sense to move the whole thing over to a template base 
  like Jeremy's.
   What are everyone's thoughts?
  
  I generally like to provide as little information as possible to a 
  constructor...helps allow use in unforeseen circumstances and 
  makes the code 
  using it simpler.  And you can call getPdfWriter() on the 
  template, and 
  getPdfDocument() on that writer, so I don't really see the 
  need to pass them 
  explicitly even if they are needed.
  
   As for clipping, this seems to do the trick without 
  templates. I don't know
   enough about the internals of the 
  saveState()/restoreState() calls to know
   what other side effects this causes, though.
  
  This is what I tried first, but it generated invalid PDF 
  files more often 
  than not.  I may well have been missing some subtleties of the state 
  management functions, but I've had best luck just avoiding 
  state saves and 
  restores altogether.
  
   Actually, I think we are almost there. If I implement the 
  stuff from your
   code (copyArea and the GraphicsConfigration stuff), then 
  all I believe we
   are missing now is setXORMode(Color c) which I don't 
  believe is doable with
   pdf. (I could have used you and your book when trying to 
  figure out the
   AffineTransformations--it works now, but I was pulling my 
  hair out for a
   couple of days there).
  
  My copyArea() actually doesn't work...what's there was a 
  first attempt, and I 
  moved on when it didn't work properly since none of the code 
  I've seen uses 
  it.  It may serve as a starting point for something that does 
  work, though; 
  haven't played with it enough to tell.  I'm pretty sure XOR 
  mode isn't 
  feasible; it seems fundamentally incompatible with vector graphics.
  
  Jeremy
  
  ___
  iText-questions mailing list
  [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/itext-questions

RE: PdfGraphics2D class (RE: [iText-questions] generating graphs)

[Paulo Soares]

 -Original Message-
 From: jim moore [SMTP:[EMAIL PROTECTED]]
 Sent: Tuesday, April 09, 2002 18:36
 To:   Paulo Soares; 'Jeremy Bowman'; [EMAIL PROTECTED]
 Subject:  Re: PdfGraphics2D class (RE:  [iText-questions] generating
 graphs)
 
 To anyone following this thread, there is a small bug in the getTransform
 method. I was returning the transform directly, but I'm supposed to return
 a
 copy. I'm attaching an update copy of the file, but if you want to make
 the
 changes yourself, change it to:
 
 /**
 * @see Graphics2D#getTransform()
 */
 public AffineTransform getTransform() {
 return new AffineTransform(transform);
 }
 
 Also I was throwing UnsupportedOperationExceptions on getComposite and
 setComposite, but JFreeChart is actually using those. Changing them as
 below
 will get them working.
 
 /**
 * @see Graphics2D#getComposite()
 */
 public Composite getComposite() {
 return null;
 }
 
 and
 
 /**
 * @see Graphics2D#setComposite(Composite)
 */
 public Composite getComposite(Composite comp) {
 
 }
 
 By the way it now seems to be working very nicely. Just ran it against a
 battery of JFreeCharts (I modified the JFreeChartDemo to write pdf files
 as
 well as draw in the window) and it basically performed perfectly. The only
 problem I can find is that descenders are not being drawn for some of the
 labels (i.e. when drawing a 'y' you only see the 'v'; portion). I'm pretty
 sure this is a FontMetrics issue.
 
This was happening because of the template clipping. It doesn't
happen in the version without templates in the text which, by the way,
generates smaller pdfs.

Best Regards,
paulo Soares

 regards,
 
 --jim moore  File: PdfGraphics2D.zip  

___
iText-questions mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/itext-questions

RE: PdfGraphics2D class (RE: [iText-questions] generating graphs )

[Kevin Galligan]

Before I get fired, that pdf file comes from our app that will go into
production soon, but the data is bogus test data.

-Original Message-
From: Kevin Galligan [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 10, 2002 11:05 AM
To: 'Paulo Soares'; '[EMAIL PROTECTED]'
Subject: RE: PdfGraphics2D class (RE: [iText-questions] generating
graphs )


I've been holding this close to my chest for a while now, but since others
are working on it, here goes.  I wrote this Graphics2D for pdflib, but we
recently switched to iText, so I mapped it to PdfContentByte.  The 2 are
pretty close, and a while ago I thought I'd write a base set of interfaces
for pdf output, and implement for different platforms (pdflib and iText,
among others).

Anyway, I have most of the methods done.  I didn't bother with font
handling, as iText does it quite different than pdflib does.  Right now it
just hard-codes to Helvetica (but the sizes are ok).  

I currently have no image support, and the AttributedCharacterIterator is
gamey, but we are using this in our production code with Monarch charts.  I
had JFreeChart as well as 2dChart code work with it.

There are many hack spots in the code as we needed to get it up an running
for our app, but I'm including an example of the output.

Hope this helps.

-Kevin

-Original Message-
From: Paulo Soares [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 10, 2002 6:46 AM
To: 'jim moore'; 'Jeremy Bowman'; [EMAIL PROTECTED]
Subject: RE: PdfGraphics2D class (RE: [iText-questions] generating
graphs )




 -Original Message-
 From: jim moore [SMTP:[EMAIL PROTECTED]]
 Sent: Tuesday, April 09, 2002 18:36
 To:   Paulo Soares; 'Jeremy Bowman'; [EMAIL PROTECTED]
 Subject:  Re: PdfGraphics2D class (RE:  [iText-questions] generating
 graphs)
 
 To anyone following this thread, there is a small bug in the getTransform
 method. I was returning the transform directly, but I'm supposed to return
 a
 copy. I'm attaching an update copy of the file, but if you want to make
 the
 changes yourself, change it to:
 
 /**
 * @see Graphics2D#getTransform()
 */
 public AffineTransform getTransform() {
 return new AffineTransform(transform);
 }
 
 Also I was throwing UnsupportedOperationExceptions on getComposite and
 setComposite, but JFreeChart is actually using those. Changing them as
 below
 will get them working.
 
 /**
 * @see Graphics2D#getComposite()
 */
 public Composite getComposite() {
 return null;
 }
 
 and
 
 /**
 * @see Graphics2D#setComposite(Composite)
 */
 public Composite getComposite(Composite comp) {
 
 }
 
 By the way it now seems to be working very nicely. Just ran it against a
 battery of JFreeCharts (I modified the JFreeChartDemo to write pdf files
 as
 well as draw in the window) and it basically performed perfectly. The only
 problem I can find is that descenders are not being drawn for some of the
 labels (i.e. when drawing a 'y' you only see the 'v'; portion). I'm pretty
 sure this is a FontMetrics issue.
 
This was happening because of the template clipping. It doesn't
happen in the version without templates in the text which, by the way,
generates smaller pdfs.

Best Regards,
paulo Soares

 regards,
 
 --jim moore  File: PdfGraphics2D.zip  

___
iText-questions mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/itext-questions


= 
This message contains confidential business information that is 
intended for use only by the individual or entity to whom it is 
addressed.  If you are not the intended recipient, you are hereby 
notified that any disclosure, interception, copying, distribution 
or the taking of any action in reliance on the contents of this 
email is prohibited.  If you received this email in error, please 
notify the sender by forwarding the message back to the sender, 
and then delete the original information from your system. 
= 






= 
This message contains confidential business information that is 
intended for use only by the individual or entity to whom it is 
addressed.  If you are not the intended recipient, you are hereby 
notified that any disclosure, interception, copying, distribution 
or the taking of any action in reliance on the contents of this 
email is prohibited.  If you received this email in error, please 
notify the sender by forwarding the message back to the sender, 
and then delete the original information from your system. 
= 



___
iText-questions mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/itext-questions

Re: PdfGraphics2D class (RE: [iText-questions] generating graphs)

[jim moore]

 Some quick points of comparison on the 2 pieces of code so far:
 - My code uses a PdfTemplate as the basis of the Graphics context; I think
 this is a more flexible solution than writing directly to a PdfContentByte
 obtained from the PdfWriter, since the template can then be used in
multiple
 places, as an image, etc.

I actually had mine this way for a while as well as a way of getting setClip
to work. When they call setClip, change the reference to the current drawing
template to a new template with the correct clipping area.

/**
* @see Graphics#setClip(Shape)
*/
public void setClip(Shape s) {
PdfTemplate template = cb.createTemplate(document.getPageSize().width(),
document.getPageSize().height());
cb.addTemplate(template, 0, 0);
cb=template;
clip(s);
}

This is basically how you are handling setClip. The problem is, it doesn't
seem to work (at least I can't seem to get it to). The clip seems to be a
property of the document, not of the template (i.e. all templates share the
same clip), so expanding the clip area of a template seems to have no effect
to the clip area of the document. For instance with the below test code:

g.setColor(Color.black);
g.fillRect(0,0,300,300);
g.clipRect(0,0,100,100);
g.setClip(0,0,200,200);
g.setColor(Color.blue);
g.fillRect(0,0,300,300);

I should see a 300x300 black square with a 200x200 blue one on top of it.
Instead, the blue rect is still 100x100 (reflecting the original smaller
clip area).

You might give it a try and verify this.

 - Since there isn't really a 1-to-1 mapping between AWT fonts and PDF
fonts,
 I created an interface for mapping them; a simple implementation is used
by
 default, but applications which use more unusual fonts are free to
override
 this with a custom mapping.  This would be necessary for asian fonts, for
 example.

The font mapping issues is one of the larger stumbling blocks. I would like
to have this robust enough that all of this font mapping voodoo happens
behind the scenes if possible. i.e. I just write setFont(f) and even if f is
some obscure font, the pdf automagically deals with it. As an end user, to
generate pdf's I should also have to write font mapping classes as well. At
least this is my dream, and maybe it is impossible, but I think we should
shoot for handling all of this transparently if possible to simplify the
interface. Ideally an end user shouldn't see any difference between using a
PdfGraphics2D and any other Graphics2D. Indeed, s/he should never even need
to be aware of the implementation class at all. When you are drawing to an
applet or a BufferedImage, who knows or cares what the actual concretete
Graphics2D class is--you just know that it is a Graphics2D and that is good
enough. The PdfGraphics2D should arguably work the same way. i.e. you never
instantiate a PdfGraphics2D directly, but rather get one from the document
or some other factory:

Graphics2D g = document.getGraphics();
//do drawing stuff here



Back to your first point, I think a valid argument could be made to base the
Graphics2D around a PdfTemplate, rather than a Document:

Graphics2D g = template.getGraphics();
//do drawing stuff here

if you wanted to draw directly you could do:
PdfTemplate template = cb.createTemplate(document.getPageSize().width(),
document.getPageSize().width());
Graphics2D g = template.getGraphics();
//draw to template
cb.addTemplate(template(0,0));

For some documents this would slightly complicate things, because you would
always be drawing to a template, never directly, but maybe the benefits
outweigh this concern. What does everyone else think?

regards,

--jim


___
iText-questions mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/itext-questions

RE: PdfGraphics2D class (RE: [iText-questions] generating graphs)

[Kevin Galligan]

 -Original Message-
 From: jim moore [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, April 10, 2002 11:32 AM
 To: Jeremy Bowman; [EMAIL PROTECTED]
 Subject: Re: PdfGraphics2D class (RE: [iText-questions] generating
 graphs)
 
 
  Some quick points of comparison on the 2 pieces of code so far:
  - My code uses a PdfTemplate as the basis of the Graphics 
 context; I think
  this is a more flexible solution than writing directly to a 
 PdfContentByte
  obtained from the PdfWriter, since the template can then be used in
 multiple
  places, as an image, etc.
 
 I actually had mine this way for a while as well as a way of 
 getting setClip
 to work. When they call setClip, change the reference to the 
 current drawing
 template to a new template with the correct clipping area.
 
 /**
 * @see Graphics#setClip(Shape)
 */
 public void setClip(Shape s) {
 PdfTemplate template = 
 cb.createTemplate(document.getPageSize().width(),
 document.getPageSize().height());
 cb.addTemplate(template, 0, 0);
 cb=template;
 clip(s);
 }
 
 This is basically how you are handling setClip. The problem 
 is, it doesn't
 seem to work (at least I can't seem to get it to). 

I don't know how you have your clip method set up, but I ran into clip snags
when I did my G2D object.  Basically, you have to call...

cb.clip();
cb.newPath();

After that it works fine.  I haven't worked with templates, so I don't know
how that complicates things.

-Kevin


= 
This message contains confidential business information that is 
intended for use only by the individual or entity to whom it is 
addressed.  If you are not the intended recipient, you are hereby 
notified that any disclosure, interception, copying, distribution 
or the taking of any action in reliance on the contents of this 
email is prohibited.  If you received this email in error, please 
notify the sender by forwarding the message back to the sender, 
and then delete the original information from your system. 
= 



___
iText-questions mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/itext-questions

Re: RE: PdfGraphics2D class (RE: [iText-questions] generating graphs )

[psoares33]

See http://www.geocities.com/itextpdf/graphics2d-01.zip
I have some ideas for clipping without templates and for fonts. My mail blew, tomorrow 
I'll talk again.

Best Regards,
Paulo Soares

 
 De: Kevin Galligan [EMAIL PROTECTED]
 Data: 10/04/2002 16:45:19
 Para: 'jim moore' [EMAIL PROTECTED],  Jeremy Bowman [EMAIL PROTECTED],  
   [EMAIL PROTECTED]
 Assunto: RE: PdfGraphics2D class (RE:  [iText-questions] generating graphs
   )
 
 
 
  -Original Message-
  From: jim moore [mailto:[EMAIL PROTECTED]]
  Sent: Wednesday, April 10, 2002 11:32 AM
  To: Jeremy Bowman; [EMAIL PROTECTED]
  Subject: Re: PdfGraphics2D class (RE: [iText-questions] generating
  graphs)
  
  
   Some quick points of comparison on the 2 pieces of code so far:
   - My code uses a PdfTemplate as the basis of the Graphics 
  context; I think
   this is a more flexible solution than writing directly to a 
  PdfContentByte
   obtained from the PdfWriter, since the template can then be used in
  multiple
   places, as an image, etc.
  
  I actually had mine this way for a while as well as a way of 
  getting setClip
  to work. When they call setClip, change the reference to the 
  current drawing
  template to a new template with the correct clipping area.
  
  /**
  * @see Graphics#setClip(Shape)
  */
  public void setClip(Shape s) {
  PdfTemplate template = 
  cb.createTemplate(document.getPageSize().width(),
  document.getPageSize().height());
  cb.addTemplate(template, 0, 0);
  cb=template;
  clip(s);
  }
  
  This is basically how you are handling setClip. The problem 
  is, it doesn't
  seem to work (at least I can't seem to get it to). 
 
 I don't know how you have your clip method set up, but I ran into clip snags
 when I did my G2D object.  Basically, you have to call...
 
 cb.clip();
 cb.newPath();
 
 After that it works fine.  I haven't worked with templates, so I don't know
 how that complicates things.
 
 -Kevin
 
 
 = 
 This message contains confidential business information that is 
 intended for use only by the individual or entity to whom it is 
 addressed.  If you are not the intended recipient, you are hereby 
 notified that any disclosure, interception, copying, distribution 
 or the taking of any action in reliance on the contents of this 
 email is prohibited.  If you received this email in error, please 
 notify the sender by forwarding the message back to the sender, 
 and then delete the original information from your system. 
 = 
 
 
 
 ___
 iText-questions mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/itext-questions
 


___
iText-questions mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/itext-questions

Re: PdfGraphics2D class (RE: [iText-questions] generating graphs)

[Jeremy Bowman]

Wow, there was a lot of discussion on this today...I'll just throw out some 
responses to points Jim made in case any of it is useful:

 Right now, though the drawing target has changed to a template, the rest is
 still based around a document and writer (required in constructor). Maybe it
 makes sense to move the whole thing over to a template base like Jeremy's.
 What are everyone's thoughts?

I generally like to provide as little information as possible to a 
constructor...helps allow use in unforeseen circumstances and makes the code 
using it simpler.  And you can call getPdfWriter() on the template, and 
getPdfDocument() on that writer, so I don't really see the need to pass them 
explicitly even if they are needed.

 As for clipping, this seems to do the trick without templates. I don't know
 enough about the internals of the saveState()/restoreState() calls to know
 what other side effects this causes, though.

This is what I tried first, but it generated invalid PDF files more often 
than not.  I may well have been missing some subtleties of the state 
management functions, but I've had best luck just avoiding state saves and 
restores altogether.

 Actually, I think we are almost there. If I implement the stuff from your
 code (copyArea and the GraphicsConfigration stuff), then all I believe we
 are missing now is setXORMode(Color c) which I don't believe is doable with
 pdf. (I could have used you and your book when trying to figure out the
 AffineTransformations--it works now, but I was pulling my hair out for a
 couple of days there).

My copyArea() actually doesn't work...what's there was a first attempt, and I 
moved on when it didn't work properly since none of the code I've seen uses 
it.  It may serve as a starting point for something that does work, though; 
haven't played with it enough to tell.  I'm pretty sure XOR mode isn't 
feasible; it seems fundamentally incompatible with vector graphics.

Jeremy

___
iText-questions mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/itext-questions

RE: PdfGraphics2D class (RE: [iText-questions] generating graphs)

[Kevin Galligan]

I think you'll have to forget copyArea as well.  Much of the Graphics 2D
spec is targeted to raster graphics (although printing from java apps is
supported by the G2D object as well).  There's certainly a lot we can do
with the primitives, but some of them are really not going to work out.
Unless the pdf spec includes a copyArea style primitive, there are really
only 2 options.  Create an off-screen buffer and paint the image to the pdf
(-- bad), or record all function calls, traslate, clip, and play back all
the paints.  I'm not very familiar with templates, but is that basically
what a template is?  Then I guess copyArea wouldn't be that bad (assuming
you can clip the repaint of the template).  Can you paint a template to a
template?  To handle copyArea you'd have to create a new template, paint the
old one to it, translate, clip, paint the old template again, then go from
there with the new template.  I've done some java games, and that's the only
place I've ever seen copyArea used.  It seems like more of an interactive
thing.

Some of the paint object stuff is hairy as well.  Its designed to describe a
raster paint.  You'd have to somehow map that to pdf's equation stuff (which
I'm also not an expert of).  I have both the O'Reilly Java 2D Graphics and
the Adobe PDF Reference books.  I'd highly recommend both for this type of
thing.

As far as the graphics state, I can't imagine how you would do this without
that.  You'd never be able to back out of your clipping.  You also wouldn't
be able to return the document back to its original state.  If you have the
saves and restores balanced it'll work.  Debugging pdf output is not easy.
To figure out my clipping problem I have to modify the PdfContentByte code
to print the pdf doc without encryption.

-Kevin

 -Original Message-
 From: Jeremy Bowman [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, April 10, 2002 10:26 PM
 To: [EMAIL PROTECTED]
 Subject: Re: PdfGraphics2D class (RE: [iText-questions] generating
 graphs)
 
 
 Wow, there was a lot of discussion on this today...I'll just 
 throw out some 
 responses to points Jim made in case any of it is useful:
 
  Right now, though the drawing target has changed to a 
 template, the rest is
  still based around a document and writer (required in 
 constructor). Maybe it
  makes sense to move the whole thing over to a template base 
 like Jeremy's.
  What are everyone's thoughts?
 
 I generally like to provide as little information as possible to a 
 constructor...helps allow use in unforeseen circumstances and 
 makes the code 
 using it simpler.  And you can call getPdfWriter() on the 
 template, and 
 getPdfDocument() on that writer, so I don't really see the 
 need to pass them 
 explicitly even if they are needed.
 
  As for clipping, this seems to do the trick without 
 templates. I don't know
  enough about the internals of the 
 saveState()/restoreState() calls to know
  what other side effects this causes, though.
 
 This is what I tried first, but it generated invalid PDF 
 files more often 
 than not.  I may well have been missing some subtleties of the state 
 management functions, but I've had best luck just avoiding 
 state saves and 
 restores altogether.
 
  Actually, I think we are almost there. If I implement the 
 stuff from your
  code (copyArea and the GraphicsConfigration stuff), then 
 all I believe we
  are missing now is setXORMode(Color c) which I don't 
 believe is doable with
  pdf. (I could have used you and your book when trying to 
 figure out the
  AffineTransformations--it works now, but I was pulling my 
 hair out for a
  couple of days there).
 
 My copyArea() actually doesn't work...what's there was a 
 first attempt, and I 
 moved on when it didn't work properly since none of the code 
 I've seen uses 
 it.  It may serve as a starting point for something that does 
 work, though; 
 haven't played with it enough to tell.  I'm pretty sure XOR 
 mode isn't 
 feasible; it seems fundamentally incompatible with vector graphics.
 
 Jeremy
 
 ___
 iText-questions mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/itext-questions
 


= 
This message contains confidential business information that is 
intended for use only by the individual or entity to whom it is 
addressed.  If you are not the intended recipient, you are hereby 
notified that any disclosure, interception, copying, distribution 
or the taking of any action in reliance on the contents of this 
email is prohibited.  If you received this email in error, please 
notify the sender by forwarding the message back to the sender, 
and then delete the original information from your system. 
= 



___
iText-questions mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists