> 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
