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

2005-03-10 Thread Renaud Richardet
Let me sum up this tread to see if I get the picture:

* Sun's codec [1] will not be integrated.
* instead, Batik's transcoders will be used [2].
* where and how these transcoders will be made available to fop will
be discussed next week [3]
* I'll start by implementing basic functionalities for TIFF and PNG
using Batik's codecs. This will be 1.3 compilant. I should be able to
use the actual codecs without modifications.
* aditional functionalities (like TIFF compressions) will be added via
the Java Image I/O (needs Java 1.4) or via JAI.Those additional
functionalities will be stored in a separate directory (src/java-1.4).
* an alternative would be to create|integrate these functionalities in
the Batik code.
* I should check that the output isn't restricted to 72-dpi [4]

Any input to tell me if these assertions are true is welcome.

Regards,
Renaud

[1] http://java.sun.com/developer/sampsource/jai/
[2] 
http://cvs.apache.org/viewcvs.cgi/xml-batik/sources/org/apache/batik/ext/awt/image/codec/tiff/
[3] 
http://mail-archives.eu.apache.org/mod_mbox/xmlgraphics-general/200503.mbox/[EMAIL
 PROTECTED]
[4] http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgNo=10756


Re: Integration of TIFFRenderer in FOP

2005-03-09 Thread Renaud Richardet
Peter,

Then my comment gave you a wrong impression: the Java2DRenderer is the
(abstract) base for all renderers that use the Java2D API for
rendering. The reference renderer is still the PDFRenderer, which
inherits from AbstractRenderer directly.

Renaud


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

2005-03-09 Thread Renaud Richardet
I downloaded sun's codecs [2] that Oleg used in his TIFFRenderer.
Jeremias, you mean that we can legally just put those in the FOP-code?

Following codecs are included in [2]:
- TIFF
- JPEG
- PNG
- BMP
So it should be possible to create a renderer for each of this file
formats. But do we need them all?
Do we also need GIF encoding ([2] only supports GIF decoding) . If
yes, we'll have to use other libraries like ACME Labs GIF encoder
(right?)

Besides, I haven't understand yet if Oleg will donate his code to Apache.

 Otherwise, I'd rather use ImageIO even if it's only available in JDKs
 =1.4.
I thought FOP should be 1.3 compilant [3]? So how do we go around that?

Regards,
Renaud

[3] http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgId=1332332


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

2005-03-08 Thread 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!

/me happy

 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


Integration of TIFFRenderer in FOP

2005-03-08 Thread 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


Good job! / Re: Integration of TIFFRenderer in FOP

2005-03-08 Thread 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: DO NOT REPLY [Bug 33760] New: - [Patch] current AWTRenderer

2005-03-07 Thread Renaud Richardet
I worked on my patch and tried to integrate you inputs. There are
still many issues, but I think the basic structure is OK. You can find
a patch attached to bug 33760.

Comments inline:

On Mon, 28 Feb 2005, Victor Mote 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.


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.

  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?

 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 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].

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.

Renaud

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


Re: Plass, Michael Frederick: Optimal Pagination Techniques for Automatic Typesetting Systems

2005-03-03 Thread Renaud Richardet
Vincent Hennebert wrote:
 By looking for this reference, I found the following article:
 www.pi6.fernuni-hagen.de/publ/tr234.pdf
 It's entitled 'On the Pagination of Complex Documents' (actually it's also
 referencing Plass). 

There's another article, where the top level of the algorithm is
presented (page 8).
http://www.pi6.fernuni-hagen.de/publ/tr205.pdf

Those 2 articles are summaries of a book. The link to command the book
can be found at the bottom of
http://web.informatik.uni-bonn.de/I/research/Pagination/

Renaud


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

2005-03-01 Thread Renaud Richardet
Victor and Jeremias, thanks for your Inputs.

Victor, I've checked out your aXSL. I'll study it and come back to you
if I have questions.

Jeremias wrote:

  Speaking of startVParea(), could we rename it to something more meanigfull?
  Proposition: TransformPosition, or something like this.
  Deleted the methods moved to AbstractRenderer.
 Actually, I like startVParea() (or rather startViewportArea like I would
 rather call it) because only for viewport a new transformation matrix is
 necessary. I think when you port the matrix concatenation from the PDF
 renderer over to Java2D in startVParea() you will start to understand
 what's going on here. 
OK,  thanks. That makes sense.

  fop.area.CTM: added two getters for e and f. If there's another way to get 
  those
  values, please let me know.
 Normally, we use toArray() but I guess these two getters are ok and
 don't hurt although I think they are not necessary because you need to
 use all other values in the CTM, too, to get the reference orientation
 stuff right. See above.
OK, I'll use the available toArray() instead.

  The enclosed image doesn't have ipd/bpd
  either. Again: is this normal so? I have a workaround in mind (getting those
  values through the FopImage), but it doesn't sound right.
 In this case it is probably better to fix the LMs. I've started doing
 that but haven't finished. ATM this is lower priority for me. I can send
 you my current code if you want to try to fix it. Shouldn't be so
 difficult.
I would also prefer to fix the LM's. I don't want to go into it now
(too complex for me ATM), but I'll come back to you later.
 
  renderTextDecoration(InlineArea) seems to work, even if it's not 
  implemented??
 Huh? It was you who moved the implementation up from PDFRenderer to
 AbstractRenderer. That's how you implemented it. Inheritance!
I mean renderTextDecoration(InlineArea) from AbstractRenderer, which
is an empty ATM . Did you mean renderTextDecoration(Font fs,
InlineArea Inline, int baseline, int startx) instead?
But I think I got in now: when I run examples/fo/basic/textdeko.fo ,
the underline of the sentence This is a whole block wrapped in
fo:inline with the property text-decoration=underline. Some more
Text to get at least two lines. works ok. This is because the
TextArea handles the underline (via renderTextDecoration(Font fs,
InlineArea Inline, int baseline, int startx) ) and the
renderTextDecoration(InlineArea) doesn't do anything.

 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.
Sounds very good. Why haven't I thought of it ? ;)

 Another thought: One of my low-priority tasks is to create a little
 application that renders a test suite with all of FOP's renderers
 creating bitmap images for each generated document and ultimately
 creating a little website that lets us compare the output. PDFs and PS
 files can be converted to bitmaps using GhostScript. Maybe you might
 want to write such a thingy. I won't get to it before I get to updating
 the PS renderer to full quality.
That would be good. Do you mean something like the Bitmap production
you documented on FopAndJava2D [1]? This is what I intend to work on
after the basic Java2DRenderer works.

Thanks for your valuable comments. I'll work them out carefully and
post an improved patch.

Regards, 
Renaud

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


Re: Skype-conference on page-breaking?

2005-03-01 Thread Renaud Richardet
I would be please to listen.

Renaud


Re: Renaming the AWT Renderer to Java2D Renderer

2005-02-23 Thread Renaud Richardet
Glen,

 We can do it this way.  But on second thought, I think
 it would be better for Renaud to move it in as
 AWTRenderer, and slowly start factoring out more and
 more while things are getting settled.  BTW, this will
 take some time to do anyway--it isn't easy because the
 renderers are so different between 0.20.5 and 1.0.
That's what I'm doing now. And yes, it might take some time...

 [A note for Renaud:  I would recommend cutting down on
 the chatroom English and instead start writing
 properly/respectfully to us, in the same manner that
 all of us have been writing to you.  Capitalize I,
 the first word of each sentence, your name, our
 names[1], greetings, etc.  Above all, when people
 write to you in standard polite English, you shouldn't
 be responding back with chatroom writing.  None of us
 here do.  Thanks!]
 
 Glen
 
 [1]
 http://marc.theaimsgroup.com/?l=fop-devm=110625230922690w=2

Your note sounded hard to me. My apologies to you and the other
members of the team. In the future i'll use standard English. Please
do not take my writing style as a sign of misrespect, as this was NOT
my intention. This style is pretty well accepted in Switzerland (in
German, we have to capitalize all Words, so this saves a lot of
Typing) and i find it personally nicer.
If you have other objects like [1] in your stack, please let me know
it now (via this maillist or directly to me). As I said in [2], I am
pretty new to open-source developpment, so please let me know if i'm
doing things the right way. I'm enjoying this project and would like
to move forward smoothly (and respectfully of the other members of
this team).

Regards, 
Renaud 

[2] http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgId=2080086


Re: another nose for the grindstone

2005-02-22 Thread Renaud Richardet
Mark, just let me know when you'll start to work on it.
Clay, sorry for not making clear that i needed the maintenance code
for reference.
Jeremias, thanks for the pointer

i'm not sure about the following. please correct me if i'm wrong:

the (currently named) AWTRenderer allows 3 different kinds of output
1) GUI-application 
2) a java Image (containing all areas represented as Graphics2D's)
3) a printed document through AWTPrintRenderer, or is it 

the commandline options to start the differents output are
1) -awt
2) 
3) -print

i started to investigate the rendering system. the AbstractRenderer is
well designed and already implementing a lot of stuff, so that should
go allright for the AWTRenderer.

thanks, renaud

On Tue, 22 Feb 2005 07:48:28 +0100, Jeremias Maerki
[EMAIL PROTECTED] wrote:
 Clay,
 
 he knows that. I told him to use the maintenance branch code as a
 reference for bringing back the AWT Renderer in CVS HEAD. Renaud and I
 met last Friday at lots.ch.
 
 So, Renaud, please use the code found under the fop-0_20_2-maintain
 branch for reference. And happy hacking!
 
 On 22.02.2005 05:38:58 The Web Maestro wrote:
  On Feb 21, 2005, at 4:55 PM, Renaud Richardet wrote:
   bonjour fop-devs
 
  Salut! Bienvenue!
 
   i would like to work on the awt renderer. Mark (or someone else) , are
   you working on it?
   i checked out the code from FOP 0.20.5. is it the latest maintenance
   version?
  
   thanks, renaud
 
  Actually, the fop-0.20.5 code is merely for reference. All FOP
  development has moved away from the fop-0.20-5 branch
  (fop-0_20-maintain OR 'maintenance' branch) in favor of  the re-design
  branch (HEAD). This was done because the 'maintenance' branch had
  significant problems that were not easily resolvable. The re-design
  branch occurred because of problems in implementing the XSL0FO 1.0
  spec--specifically with the 'keeps' I believe.
 
  In any case, if you wish to contribute to FOP development, please check
  out the HEAD branch. You may look to fop-0.20.5 for reference, but any
  work you do on that branch will probably not be integrated into FOP
  1.0.
 
 Jeremias Maerki
 
 


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


AWTRenderer: getting the absolute position of an area

2005-02-22 Thread Renaud Richardet
bonjour fop-dev's

i've been walking through the rendering process. if i understand it
rightly, an area doesn't records it's absolute position. therefore, we
have to pass the currentIPPosition, currentBPPosition all along during
the rendering process to figure out where to position an area.
what i don't understand: this information (the absolute position of an
area) MUST somehow have been known during the building of the area
tree (otherwise we could'nt know where to break the pages). so my
question: wouldn't it be easier to record the absolute position of an
area during the page-breaking process? or am i missing something?

renaud

PS: the abstract Java2DRenderer sounds like a really good deal to me :)


Re: AWTRenderer: getting the absolute position of an area

2005-02-22 Thread Renaud Richardet
hello Jeremias

merci for the informations. 

 I wondered about that, too:
 http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=984481

interesting!

Victor, 
in [1] you talked about dealing with the positioning of areas during
the AreaTree building. could you point me to the classes in FOray that
handle that logic?
 
 So far, I can only say that there's so mandatory reason for that change.
 It would certainly make the renderers simpler but there might be
 problems in other areas. The real downside is when you have to do the
 same calculations in every renderer.
ok, that's what i was affraid of... but i understand that the area
tree building is already enough complex.
well, i'll base the Java2DRenderer on the pdf renderer. could someone
tell me if it's stable enough (especially those tricky issues like
reference-orientation and writing-mode  that i don't completely
understand yet).

 Some can be (and already are) put
 in AbstractRenderer but for others this is not so easily possible. No
 definitive answer from me. We'll see what comes out of the page-break
 rewrite.
ok, good luck. i'm looking forward to see your rewrite.

renaud

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


Re: Renaming the AWT Renderer to Java2D Renderer

2005-02-22 Thread Renaud Richardet
Glen Mazza [EMAIL PROTECTED] wrote:
 Looks good!  Now whether you wish to do this before or
 after Renaud moves the logic over is up to you two.
 There's advantages/disadvantages to either method.
yes, that looks good! 

Jeremias, if it's ok for the team, i would apreciate if you would do
the changes asap.

thanks, Renaud


Re: AWTRenderer: getting the absolute position of an area

2005-02-22 Thread Renaud Richardet
Victor,
thanks for your explanations. i'll give a look into FOray when i'll
feel more confident about the layout process.
cheers, Renaud


Re: another nose for the grindstone

2005-02-21 Thread Renaud Richardet
bonjour fop-devs

i would like to work on the awt renderer. Mark (or someone else) , are
you working on it?
i checked out the code from FOP 0.20.5. is it the latest maintenance version?

thanks, renaud

On Mon, 17 Jan 2005 10:54:43 +0100, Jeremias Maerki
[EMAIL PROTECTED] wrote:
 Hi Mark
 
 We'd love to have you with us.
 
 On 17.01.2005 05:18:23 Mark Brucks wrote:
  I'd like to join the fop development group.  I've been an xsl/fop user
  for the last year or so (generating PDF), but several new projects I'm
  proposing have a need for a robust and complete awt renderer, and I'd
  like to devote some time to ensuring this happens.  I have a little bit
  of time in the near term to commit to the project, and I hope much more
  time starting in the April time frame.  I'd like to use the next 2
  months to come up to speed, then dive in to serious work when more time
  is available.
 
 The AWT renderer is currently missing in CVS HEAD. It would be great if
 someone took up that task. To build that renderer you can look at the
 code from the maintenance branch (or FOP 0.20.5) for reference. Our
 reference renderer in CVS HEAD is the PDF renderer (like before).
 
 Personally, I'd rather call it Java2D renderer, not AWT renderer,
 because Java2D is essentially the name of the API you code against. AWT
 is, as the name says, a windowing toolkit, not primarily a graphics API.
 
  I need some advice.  I've learned enough about xsl and fop to get my job
  done, but there are lots of holes in my knowledge base.  I'd like to
  spend a little bit of time carefully reading the XSL spec.  Should I
  read the XSL V1.1 working draft (in anticipation of things to come), or
  should I stick with the V1.0 recommendation (which I assume is what the
  new version of fop will implement).
 
 The recommendation is still the main reference. Glen Mazza already
 started investigating the 1.1 WD (ex. bookmarks) and it might be helpful
 sometimes to consult the 1.1 WD because it seems to be somewhat more
 verbose. It's good to prepare for 1.1 but as long as it's in WD phase
 the focus should remain on the 1.0 Rec for the time being.
 
  Do the development and design documents that are available on-line
  relate to the root/trunk/redesign version, or do they still describe the
  maintenance branch?
 
 They refer to CVS HEAD. If they are not up-to-date, they should be
 updated.
 
  Is there a development schedule or a prioritized list of features to be
  implemented?
 
 A development schedule is always difficult in an all-volunteer project.
 I think it's pretty realistic now to target an initial release in late
 summer 2005.
 
 I'm currently working off this list: 
 http://wiki.apache.org/xmlgraphics-fop/FOPWorkEstimates
 
 But this list isn't binding. You're free to choose what you like to work
 on. If you want to build the Java2D renderer, that's great. If you want
 to help with the layout engine, even better. If you start a task simply
 notify us what you're working on so we don't have duplicate effort.
 
  Is anybody else actively working on the awt rendered for the next release?
 
 No, not at the moment.
 
  Since this is my first foray into open-source development, any and all
  advice is welcome.
 
 The advice is simple: Choose something to work on, notify this list (if
 it's something bigger), start hacking and in the end send patches via
 Bugzilla. Of course, this is a bit simplistic but essentially this is
 all what you need to know for now. :-)
 
 If you have questions simply ask. We're happy to help you getting
 started.
 
 
 Jeremias Maerki



Re: commit to fop

2005-01-20 Thread Renaud Richardet
jeremias and simon: thanks for your response. now i see better where to look.
i'll follow the maillinglist  start to dig in the code.

renaud


commit to fop

2005-01-16 Thread Renaud Richardet
bonjour fop-devs

bertrand delacretaz told me you might welcome some help on fop. I
would be pleased to contribute.

*** why fop ***
- i'm very interested in xml and java
- i believe in open-source and wish to contribute to a project
- bertrand told me you were a good team

*** me ***
you can get my background at www.oslutions.com/about

*** documentation ***
please could you tell me about the state of the following documentations:
- xml.apache.org/fop/dev: this documentation refers to 0.20, right?
- cvs/... /xdocs/DnI: simon, thanks a lot for your xdoc DnI, it really
helped me diving into the code. some parts of it have changed. i
started to update it and made a patch for chapter 4.1 , you can find
it attached to bug 33126. if it's useful for you, i'll continue.
- fop-wiki (http://wiki.apache.org/xmlgraphics-fop/FOPProjectPages)
seems pretty up to date. please tell me if  FOPProjectTasks and
FOPWorkEstimates are up to date.
- are there some more key-docs?

*** plans ***
(thinking loud)
i plan to start with some documentation update. i see there is a brand
new site at xmlgraphics.apache.org/ to do.
what about rtf-rendering? is peter herweg still active on it?
i'm open, so please give me some hints on where i could start


as i am pretty new to open-source developpment, please let me know if
i'm doing things the right way.

have a nice weekstart
greetings from switzerland
renaud