Re: Good job! / Re: Integration of TIFFRenderer in FOP

[Jeremias Maerki]

Thanks to Glen for raising the issue. The ideal approach is if Oleg
would pack up his TIFFRenderer and donate it to the ASF accompanied with
a software grant [1], but Oleg is a FOP committer and has a CLA on file.
So if Oleg attaches a ZIP with the sources for the TIFFRenderer (ALv2
already applied) to a Bugzilla entry along with a note that we may
include it in FOP, that's good enough for me. It's not that the thing is
a big application in itself even though some people would argue works
like Renaud's AWT patch and Oleg's TIFFRenderer must go/run through the
Incubator.

[1] http://www.apache.org/licenses/#grants

On 09.03.2005 01:12:05 Glen Mazza wrote:
> Team,
> 
> Oleg's TIFF Renderer is under the Mozilla license[1],
> not the Apache one (also apparently some of the code
> is from Sun?).  Is the former compatible with the
> latter?  If not, I would like Oleg to switch the
> license on it before we proceed further in putting it
> into FOP.
> 
> Renaud--thanks for your fantastic work with the AWT
> Renderer.  You clearly have ace technical skills,
> enthusiasm, organization, and you write beautifully. 
> You have a bright future ahead of you.
> 
> [Thanks also to Bertrand for sending Renaud our way. 
> This is the second quality developer--Peter Herweg
> being the other--that we have gotten from him since
> I've been on this project.]
> 
> Regards,
> Glen
> 
> [1] http://www.tkachenko.com/fop/tiffrenderer.html
> 
> 
> --- Renaud Richardet <[EMAIL PROTECTED]>
> wrote:
> 
> > Oleg,
> > 
> > I'm currently working on the AWTRenderer. The basic
> > idea is to create
> > a Java2DRenderer which provides the (abstract)
> > technical foundation.
> > Other renderers can subclass Java2DRenderer and
> > provide the concrete
> > output paths [1].
> > 
> > I think it would be a good idea to integrate your
> > TIFFRenderer, as you
> > propose in [2]. Would you like to integrate it
> > yourself? Otherwise I
> > would like to do it.
> > 
> > Regards,
> > Renaud
> > 
> > [1]
> > http://wiki.apache.org/xmlgraphics-fop/FopAndJava2D
> > [2] http://www.tkachenko.com/fop/fop.html
> > 



Jeremias Maerki

Re: Integration of TIFFRenderer in FOP

[Jeremias Maerki]

Relationship to which PDF renderer? The one that directly creates PDF 
(PDFRenderer) or the one that creates PDF through JPS (normal
PrintRenderer as defined in the Wiki painting to a Graphics2D instance
provided by JPS) using a StreamPrintService? That's the two choices.
Obviously, you will be taking the latter approach. If you wait a bit
(until the common components area is set up) you'll have a neatly
separated package to create PDF using JPS because I'll be publishing my
proof-of-concept JPS StreamPrintService which you can build on.

Hmm, this gives me another thing to talk about over in XML Graphics
General.

On 09.03.2005 00:53:16 Peter B. West wrote:
> This approach is obviously of interest to me, and I will follow 
> developments closely.  The wiki page is very general.  If the 
> Java2DRenderer is to be the "(abstract) technical foundation", what will 
> the relationship to the concrete PDF renderer be?  The wiki is vague on 
> this point.


Jeremias Maerki

Re: cvs commit: xml-fop/src/java/org/apache/fop/render/awt/viewer PreviewDialog.java

[Jeremias Maerki]

No. It's quite ok like this. It is in line with my vision how renderers
should be made available to FOP in the future (dynamic registration like
the FOP extensions). It's clear that the AWT preview doesn't manifest a
certain type of file that has an officially defined MIME type. But
nobody is blocked from creating a new, special one for special purposes.
Only if you want to be purist about MIME types is this probably
suboptimal. The MIME type is ideal for choosing a renderer. JPS, for
example, works much in the same way.

RFC 2045 [1] says this:
> (1)   Private values (starting with "X-") may be defined
>   bilaterally between two cooperating agents without
>   outside registration or standardization. Such values
>   cannot be registered or standardized.

So to be on the safe side we would need to rename "application/awt" to
"application/X-awt".

[1] http://www.faqs.org/rfcs/rfc2045.html

On 09.03.2005 01:31:24 Glen Mazza wrote:
> The "application/awt" MIME type doesn't exist.  I
> think Jeremias wanted this to be null instead for
> output types that lack a MIME type, correct?
> 
> Thanks,
> Glen
> 
> --- [EMAIL PROTECTED] wrote:
> >
> >   +/** The MIME type for AWT-Rendering */
> >public static final String MIME_TYPE =
> > "application/awt";
> >



Jeremias Maerki

Good job! / Re: Integration of TIFFRenderer in FOP

[Renaud Richardet]

Glen,

Thanks for your mail.

It's good you raised the legal issue.

Peter, let me answer you last mail [1] here:

You are right that the wiki is still vague about the detailled
implementation of the different renderers. Actually, I haven't started
to think about it until today. I will put my ideas tomorrow on the
wiki. I would be happy if you could put your inputs there, too.

Regards,
Renaud

[1] http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgNo=10759


-- 
renaud.richardet (at) gmail (dot) com
+41 78 675 9501
www.oslutions.com

Re: cvs commit: xml-fop/src/java/org/apache/fop/render/awt/viewer PreviewDialog.java

[Glen Mazza]

The "application/awt" MIME type doesn't exist.  I
think Jeremias wanted this to be null instead for
output types that lack a MIME type, correct?

Thanks,
Glen

--- [EMAIL PROTECTED] wrote:
>
>   +/** The MIME type for AWT-Rendering */
>public static final String MIME_TYPE =
> "application/awt";
>

Re: Integration of TIFFRenderer in FOP

[Glen Mazza]

Yeah, Peter makes me want to do that sometimes
myself...  ;)

Glen

--- vivek gupta <[EMAIL PROTECTED]> wrote:

> How to leave this group. Please help me to
> unsubscribe.
> 
> 
> 
> --- "Peter B. West" <[EMAIL PROTECTED]> wrote:
> > Renaud Richardet wrote:
> > > Oleg,
> > > 
> > > I'm currently working on the AWTRenderer. The
> > basic idea is to create
> > > a Java2DRenderer which provides the (abstract)
> > technical foundation.
> > > Other renderers can subclass Java2DRenderer and
> > provide the concrete
> > > output paths [1].
> > > 
> > > I think it would be a good idea to integrate
> your
> > TIFFRenderer, as you
> > > propose in [2]. Would you like to integrate it
> > yourself? Otherwise I
> > > would like to do it.
> > > 
> > > Regards,
> > > Renaud
> > > 
> > > [1]
> >
> http://wiki.apache.org/xmlgraphics-fop/FopAndJava2D
> > > [2] http://www.tkachenko.com/fop/fop.html
> > 
> > Renaud,
> > 
> > This approach is obviously of interest to me, and
> I
> > will follow 
> > developments closely.  The wiki page is very
> > general.  If the 
> > Java2DRenderer is to be the "(abstract) technical
> > foundation", what will 
> > the relationship to the concrete PDF renderer be? 
> > The wiki is vague on 
> > this point.
> > 
> > Peter
> > -- 
> > Peter B. West 
> > Folio 
> > 
> > 
> 
> 
>   
>   
> __ 
> Celebrate Yahoo!'s 10th Birthday! 
> Yahoo! Netrospective: 100 Moments of the Web 
> http://birthday.yahoo.com/netrospective/
> 

Good job! / Re: Integration of TIFFRenderer in FOP

[Glen Mazza]

Team,

Oleg's TIFF Renderer is under the Mozilla license[1],
not the Apache one (also apparently some of the code
is from Sun?).  Is the former compatible with the
latter?  If not, I would like Oleg to switch the
license on it before we proceed further in putting it
into FOP.

Renaud--thanks for your fantastic work with the AWT
Renderer.  You clearly have ace technical skills,
enthusiasm, organization, and you write beautifully. 
You have a bright future ahead of you.

[Thanks also to Bertrand for sending Renaud our way. 
This is the second quality developer--Peter Herweg
being the other--that we have gotten from him since
I've been on this project.]

Regards,
Glen

[1] http://www.tkachenko.com/fop/tiffrenderer.html


--- Renaud Richardet <[EMAIL PROTECTED]>
wrote:

> Oleg,
> 
> I'm currently working on the AWTRenderer. The basic
> idea is to create
> a Java2DRenderer which provides the (abstract)
> technical foundation.
> Other renderers can subclass Java2DRenderer and
> provide the concrete
> output paths [1].
> 
> I think it would be a good idea to integrate your
> TIFFRenderer, as you
> propose in [2]. Would you like to integrate it
> yourself? Otherwise I
> would like to do it.
> 
> Regards,
> Renaud
> 
> [1]
> http://wiki.apache.org/xmlgraphics-fop/FopAndJava2D
> [2] http://www.tkachenko.com/fop/fop.html
> 

Re: Integration of TIFFRenderer in FOP

[The Web Maestro]

Send an e-mail to:
[EMAIL PROTECTED]
Be sure to use the e-mail address from which you subscribed.
On Mar 8, 2005, at 4:03 PM, vivek gupta wrote:
How to leave this group. Please help me to
unsubscribe.

--- "Peter B. West" <[EMAIL PROTECTED]> wrote:
Renaud Richardet wrote:
Oleg,
I'm currently working on the AWTRenderer. The
basic idea is to create
a Java2DRenderer which provides the (abstract)
technical foundation.
Other renderers can subclass Java2DRenderer and
provide the concrete
output paths [1].
I think it would be a good idea to integrate your
TIFFRenderer, as you
propose in [2]. Would you like to integrate it
yourself? Otherwise I
would like to do it.
Regards,
Renaud
[1]
http://wiki.apache.org/xmlgraphics-fop/FopAndJava2D
[2] http://www.tkachenko.com/fop/fop.html
Renaud,
This approach is obviously of interest to me, and I
will follow
developments closely.  The wiki page is very
general.  If the
Java2DRenderer is to be the "(abstract) technical
foundation", what will
the relationship to the concrete PDF renderer be?
The wiki is vague on
this point.
Peter
--
Peter B. West 
Folio 




__
Celebrate Yahoo!'s 10th Birthday!
Yahoo! Netrospective: 100 Moments of the Web
http://birthday.yahoo.com/netrospective/

Web Maestro Clay
--
<[EMAIL PROTECTED]> - 
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Integration of TIFFRenderer in FOP

[vivek gupta]

How to leave this group. Please help me to
unsubscribe.



--- "Peter B. West" <[EMAIL PROTECTED]> wrote:
> Renaud Richardet wrote:
> > Oleg,
> > 
> > I'm currently working on the AWTRenderer. The
> basic idea is to create
> > a Java2DRenderer which provides the (abstract)
> technical foundation.
> > Other renderers can subclass Java2DRenderer and
> provide the concrete
> > output paths [1].
> > 
> > I think it would be a good idea to integrate your
> TIFFRenderer, as you
> > propose in [2]. Would you like to integrate it
> yourself? Otherwise I
> > would like to do it.
> > 
> > Regards,
> > Renaud
> > 
> > [1]
> http://wiki.apache.org/xmlgraphics-fop/FopAndJava2D
> > [2] http://www.tkachenko.com/fop/fop.html
> 
> Renaud,
> 
> This approach is obviously of interest to me, and I
> will follow 
> developments closely.  The wiki page is very
> general.  If the 
> Java2DRenderer is to be the "(abstract) technical
> foundation", what will 
> the relationship to the concrete PDF renderer be? 
> The wiki is vague on 
> this point.
> 
> Peter
> -- 
> Peter B. West 
> Folio 
> 
> 




__ 
Celebrate Yahoo!'s 10th Birthday! 
Yahoo! Netrospective: 100 Moments of the Web 
http://birthday.yahoo.com/netrospective/

Re: Integration of TIFFRenderer in FOP

[Peter B. West]

Renaud Richardet wrote:
Oleg,
I'm currently working on the AWTRenderer. The basic idea is to create
a Java2DRenderer which provides the (abstract) technical foundation.
Other renderers can subclass Java2DRenderer and provide the concrete
output paths [1].
I think it would be a good idea to integrate your TIFFRenderer, as you
propose in [2]. Would you like to integrate it yourself? Otherwise I
would like to do it.
Regards,
Renaud
[1] http://wiki.apache.org/xmlgraphics-fop/FopAndJava2D
[2] http://www.tkachenko.com/fop/fop.html
Renaud,
This approach is obviously of interest to me, and I will follow 
developments closely.  The wiki page is very general.  If the 
Java2DRenderer is to be the "(abstract) technical foundation", what will 
the relationship to the concrete PDF renderer be?  The wiki is vague on 
this point.

Peter
--
Peter B. West 
Folio  

Re: Skype-conference on page-breaking?

[Luca Furini]

Jeremias Maerki wrote:

> Luca, do you think your total-fit approach may be written in a way to
> handle changing available IPDs and that look-ahead can be disabled to
> improve processing speed at the cost of optimal break decisions?

I think that a first fit algorithm could be implemented in two different ways:
1) wait until the list of elements representing a whole page-sequence is
   collected, and call findBreakingPoints(); this method will call a
   different considerLegalBreak() method, much simpler and faster than
   the knuth's one.
2) start building pages little by little: the FlowLM returns elements to
   the PageLM as soon as one of its own child returns them

Alternative 1) is much like the total fit algorithm: breaks are computed
at the end of each page-sequence; even if the evaluation method is much
faster than Knuth's one, there could still be a long wait in order to get
the whole list.

With alternative 2) the PageLM would behave much the same as it now does:
as soon as a page is filled, it is possible to call addAreas. Note that
the last elements in the partial sequence cannot be considered as feasible
break. For example, if there is a block which creates 6 lines, the
sequence will be something like:
 box
 box
 penalty(not infinite)
 box
 penalty(not infinite)
 box
 box
and the evaluation must stop at the second penalty; only when some
following elements are known it will be possible to decide whether the
last two lines could be at the end of a page.

If the IPD is always the same, I think the two alternatives are
equivalent, and the first one is "better" because it just needs a
different considerLegalBreak() method; as the output file cannot be
printed until the end of the process, the only advantage of 2) could be
memory usage.

> That's the part where I have a big question mark about changing
> available IPD. We may have to have a check that figures out if the
> available IPD changes within a page-sequence by inspecting the
> page-masters. That would allow us to switch automatically between
> total-fit and best-fit or maybe even first-fit.

If the IPD changes, I fear 2) must be necessarily used: if a block is
split between pages with different ipd, only a few lines need to be
recreated.
Using 1), the LineLM should know how wide the lines are, but this cannot
be known as page breaking has not yet started.

The check could be done before starting the layout phase: if there is a
change, 2) is used, otherwise 1).
Maybe, the check could be even more sophisticated: for example, if the
first page is different, but the following are equally wide, we could use
2) to create the first page and then switch to 1).

> A remaining question
> mark is with side-floats as they influence the available IPD on a
> line-to-line basis.

This is a question mark for me too! :-)

> One thing for a deluxe strategy for book-style
> documents is certainly alignment of lines between facing pages. But
> that's something that's not important at the moment.

I have created and implemented a new property right about this! :-)

> I'd be very interested to hear what you think about the difficulty of
> changing available IPD. The more I think about it, however, the more I
> think the total-fit model gets too complicated for what we/I need right
> now. But I'm unsure here.

If changing ipd is really important and not just a theorical possibility,
we could start implementing 2, and later add the check and the algorithm
1: the getNextKnuthElements() in the block-level LM could be used in both
cases.

Regards
Luca

Re: Integration of TIFFRenderer in FOP

[Oleg Tkachenko]

Renaud Richardet wrote:
I'm currently working on the AWTRenderer. The basic idea is to create
a Java2DRenderer which provides the (abstract) technical foundation.
Other renderers can subclass Java2DRenderer and provide the concrete
output paths [1].
I think it would be a good idea to integrate your TIFFRenderer, as you
propose in [2]. Would you like to integrate it yourself? Otherwise I
would like to do it.
Unfortunately I'm sort of busy currently. Go ahead, that will be great 
renderer.

--
Oleg Tkachenko
http://blog.tkachenko.com
Multiconn Technologies, Israel

Re: Integration of TIFFRenderer in FOP

[The Web Maestro]

On Mar 8, 2005, at 7:23 AM, Renaud Richardet wrote:

I think it would be a good idea to integrate your TIFFRenderer, as you
propose in [2]. Would you like to integrate it yourself? Otherwise I
would like to do it.

I think that would be great! Just be careful when you do, that the 
output isn't restricted to 72-dpi (IIRC, I had some problems in the 
past when i tried to use Oleg's TIFFRenderer--I ended up using 
ImageMagick to complete my task).

Cheers!
Web Maestro Clay
--
<[EMAIL PROTECTED]> - 
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Integration of TIFFRenderer in FOP

[Renaud Richardet]

Oleg,

I'm currently working on the AWTRenderer. The basic idea is to create
a Java2DRenderer which provides the (abstract) technical foundation.
Other renderers can subclass Java2DRenderer and provide the concrete
output paths [1].

I think it would be a good idea to integrate your TIFFRenderer, as you
propose in [2]. Would you like to integrate it yourself? Otherwise I
would like to do it.

Regards,
Renaud

[1] http://wiki.apache.org/xmlgraphics-fop/FopAndJava2D
[2] http://www.tkachenko.com/fop/fop.html

DO NOT REPLY [Bug 32612] - [PATCH] refactoring of knuth line breaking code.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32612


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-03-08 16:05 ---
Applied. This was long due and it helps me while preparing for page breaking.

Reference in the mailing list archives:
http://marc.theaimsgroup.com/?t=11026228562&r=1&w=2

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

RE: DO NOT REPLY [Bug 33760] New: - [Patch] current AWTRenderer

[Victor Mote]

Renaud Richardet wrote:

> > 1. FOray has factored the FOP font logic into a separate module, 
> > cleaned it up significantly, and made some modest 
> improvements. A few 
> > weeks ago, I aXSL-ized it as well, which means that it is 
> written to a 
> > (theoretically) independent interface:
> > 
> http://cvs.sourceforge.net/viewcvs.py/axsl/axsl/axsl-font/src/java/org
> > /axsl/
> > font/
> > I think there is general support within FOP to implement the 
> > FOray/aXSL font work in the FOP 1.0 code, but so far no one has 
> > actually taken the time to do it. If you get into messing 
> with fonts 
> > at all, I highly recommend that FOray be implemented before doing 
> > anything else. I will be happy to support efforts to that end.
> 
> For what I understand now, your approach sounds good to me. 
> But I'm missing some major pieces of the picture ATM to start 
> implementing your aXSL interface in FOP. Please let me come 
> back to you when I'll feel more comfortable with the font-mechanism.

Sure. The main thing I wanted to alert you about is that right now, AFAIK,
the HEAD code is pretty similar to the maintenance branch code and
integration *should be* relatively easy. If improvements are made to the
HEAD code, then issues of merging, etc. crop up that make integration
difficult. That is OK too -- I just want to make sure that if it is done
that way, it is done that way on purpose.

Please feel free to contact me offline if you have implementation questions.

Victor Mote

Re: DO NOT REPLY [Bug 33760] New: - [Patch] current AWTRenderer

[Renaud Richardet]

Thanks for integrating my patch in FOP. 

> > But how can I get an awt.Image from a FopImage?
> 
> I've modified your patch to demonstrate, but it needs some additional
> work to handle the different color models. Probably the image package
> should be extended to provide the necessary information/methods.

OK, I've put that on my TODO-list. 

> > I created an interface (RendererState) that could be implemented by
> > all xxxState of the renderers. To be discussed...
> 
> I moved the interface into the awt package for now since it contains
> Java2D-dependant methods and classes. I don't see right now how the
> other renderer would fit into the picture. 

Neither do I right now, but I think it will come clearer in the future.

> The PDF renderer's state
> class is in the pdf package and should probably stay there.

Yes, in any case.

> > If this code works for you, then I'll start to separate the
> > Java2DRenderer and the AWTRenderer. Otherwise, please tell me how I
> > can improve my code.
> 
> I liked the patch. It's a big step forward. Keep it up!



> By the way, Renaud, you should sign and send an ICLA (Individual
> Contributor license agreement) to the ASF if you haven't done so already.

I just did it last week. Thanks for remembering me.

Renaud

Re: DO NOT REPLY [Bug 33760] New: - [Patch] current AWTRenderer

[Jeremias Maerki]

By the way, Renaud, you should sign and send an ICLA (Individual
Contributor license agreement) to the ASF if you haven't done so already.

http://www.apache.org/licenses/#clas

Just so we're on the safe side. After all you're not just doing little
bug fixes. Thanks!

Jeremias Maerki

DO NOT REPLY [Bug 33760] - [Patch] current AWTRenderer

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33760


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-03-08 12:53 ---
Patch applied with modifications. Thanks a lot!

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: DO NOT REPLY [Bug 33760] New: - [Patch] current AWTRenderer

[Jeremias Maerki]

On 08.03.2005 03:18:21 Renaud Richardet wrote:

> On Mon, 28 Feb 2005 , Jeremias Maerki wrote:
> 
> > > AbstractRenderer: I moved what I could reuse from PDFRenderer to
> > > AbstractRenderer: renderTextDecorations(), handleRegionTraits(), and 
> > > added the
> > > needed empty methods.
> > 
> > I think that was good although only time will tell if this will hold for
> > all renderers to come. 
> 
> Eventually, I didn't modify AbstractRenderer, PDFRenderer and PS
> Renderer at all.
> The implementation of AWTRenderer is close to the other renderers, so
> that putting some methods in AbstractRenderer should not be a big
> problem.

I agree.

> > > Speaking of startVParea(), could we rename it to something more 
> > > meanigfull?
> > > Proposition: TransformPosition, or something like this.
> > 
> > Actually, I like startVParea() (or rather startViewportArea like I would
> > rather call it) because only for viewport a new transformation matrix is
> > necessary. 
> 
> startViewportArea() is fine for me.
> 
> > I think the Java2D approach is not unlike the
> > PDF/PS approach. 
> 
> Adobe was Sun's closest partner when they developed the Java2D API.
> 
> > > I implemented a simple .bmp rendering (BMPReader.java). 
> > > If there's a better way to render .bmp (JAI?), let me know. 
> > 
> > This should not be necessary. We have a BMP implementation in 
> > org.apache.fop.images.
> > The BMP bitmaps should be loaded through that mechanism. 
> 
> OK, now I see. But how can I get an awt.Image from a FopImage?

I've modified your patch to demonstrate, but it needs some additional
work to handle the different color models. Probably the image package
should be extended to provide the necessary information/methods.

> > BTW, Using Graphics.create() you should be able to create a copy of the
> > current Graphics2D object. By pushing the old one on a stack and
> > overwriting the graphics member variable should should be able to create
> > the same effect as with currentState.push()/saveGraphicsState() in
> > PDFRenderer.startVParea () and currentState.pop()/restoreGraphicsState
> > ()in endVParea(). When leaving a VP area you can simply restore an older
> > Graphics2D object for the stack and continue painting. This will undo
> > any transformations and state change done in the copy used within the VP
> > area. See second paragraph in javadocs of java.awt.Graphics.
> 
> Thanks for the hint. I did just that in AWTGraphicsState (same as
> PDFState). It holds all the context (font, colour, stroke,
> transformation) of the current graphics, and can act as a stack, too.
> I created an interface (RendererState) that could be implemented by
> all xxxState of the renderers. To be discussed...

I moved the interface into the awt package for now since it contains
Java2D-dependant methods and classes. I don't see right now how the
other renderer would fit into the picture. The PDF renderer's state
class is in the pdf package and should probably stay there.

> I also added a "Debug" button on the AWTRenderer-Windows, which
> outlines the blocks. This is just a test, and I would like to develop
> a full-fledged visual debugger [1].

That's an interesting feature.

> If this code works for you, then I'll start to separate the
> Java2DRenderer and the AWTRenderer. Otherwise, please tell me how I
> can improve my code.

I liked the patch. It's a big step forward. Keep it up!

> Renaud
> 
> [1] http://wiki.apache.org/xmlgraphics-fop/FopAndJava2D



Jeremias Maerki