Maybe the output to a gc needs to be buffered, so that each gc output can have an independent pdf graphics state, and when a dispose is called, the buffered output is written to the pdf writer, with graphics state framing commands.
OR It would seem that the gc could track whether or not it "owned" the pdf graphics state (the last gc implicitly owns the state), and then if a command came in on a gc that did not own the pdf graphics state, it would reset the pdf graphics state to the one in the gc. This would support interleaved writing between different gc. As far as the transform matrix, could it not just always push the state at the beginning of the page, then when ever you need to change gc, pop the state (gets you back to the original/identity), repush the state (putting another identity on the stack), then concat the matrix from the current gc. Does this sound feasible? I could work on the changes if provided a bit of direction. Thanks. -----Original Message----- From: Paulo Soares [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 12, 2005 11:07 AM To: [EMAIL PROTECTED]; [email protected] Subject: RE: [iText-questions] iText bug? If things where that easy... The problem is that in Graphics2D you can set the transform and in PDF you can only add the transform to the current one resulting in a new transform. All kind of tricks with push/restore are needed to make it work as in Graphics2D. Dispose in the copied gc does nothing as many apps write to this gcs interleaved with the original gc. If all the apps behaved as well as yours this wouldn't be an issue. > -----Original Message----- > From: Robert Engels [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 12, 2005 4:42 PM > To: Paulo Soares; [email protected] > Subject: RE: [iText-questions] iText bug? > > Based on your statement, it seems this should work??? > > When the gc1 (copy) is disposed, shouldn't the image be > rendered into the > pdf, then when the outer gc is disposed, the text will be > rendered into the > pdf (on top of the image). > > I could see it being a problem if the gc1 was not disposed prior to > rendering the text, but this is not the case. > > I understand that you do this at your leisure, and I > appreciate the help. > > Thanks, > Robert > > > -----Original Message----- > From: Paulo Soares [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 12, 2005 10:36 AM > To: [EMAIL PROTECTED]; [email protected] > Subject: RE: [iText-questions] iText bug? > > > The Graphics2D isn't really part of iText but rather a class that uses > iText, included for convenience. What you've experienced is a > limitation, the copied gc are stored and only rendered at dispose. In > theory no interleaved gc and gc1 writing is allowed but in practice > many apps do that and writting the copy at the end is the lesser evil. > This could be fixed to work some other way but I don't use Graphics2D > and things that I don't use are not at the top of my to-do list. > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On > > Behalf Of Robert Engels > > Sent: Wednesday, October 12, 2005 4:20 PM > > To: [email protected] > > Subject: [iText-questions] iText bug? > > Importance: High > > > > I believe discovered a bug in the iText pdf generation library. > > > > If code similar to the following is used. > > > > get gc (graphics context) for the page > > create a new gc1 from gc > > change transform on gc1 > > render image to gc1 > > dispose gc1 > > render text to original gc > > dispose gc > > > > the image will be renderered on top of the text - obviously > > not what is desired > > > > code similar to the following needs to be used > > > > get gc (graphics context) for the page > > save transform from gc > > change transform > > render image > > restore saved transform > > render text > > > > Is this is known limitation. > > > > Although we can control this in our code, it is difficult > > with using third-party libraries with iText to render their > > output as pdf. > > > > Thanks, > > Robert Engels > > > > > > > > ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ iText-questions mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/itext-questions
