RE: New Developer Suggestion
> = J.Pietschmann <[EMAIL PROTECTED]> > [ ... ]For working on HEAD, pick an area: > - layout core > - a renderer > - the font subsystem > - API and configuration > - parsing and property resolution > - FO extensions [ ... ] Thanks for the great suggestions. This one message taught me more about the system design than a month's worth of list-reading. And now, it's time to start looking at code. -- Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Where to start for an RTF renderer (was: New Developer Suggestion)
> Yes, we've been talking about structure-based renderers (like RTF and MIF) > vs. layout-based ones (PDF being the focal point) for some time. [ ... ] > 4) My suggestion is to first use the RTF library from jfor in binary form, by > including jfor's jar in the FOP distribution, to create the RTF document from > the StructureHandler events. The current jfor code does a similar thing where > the jfor Converter (jfor/jfor/converter/Converter) uses SAX events to drive > the jfor RTF library. This makes sense, and I will start looking at it. But, as I said up front, nobody should count on my being able to accomplish this, and anyone who wants to do it will not offend me by going ahead and doing it without me. -- Scott .sig wanders off, mumbling something about learning CVS. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RTF or not RTF? (was: New Developer Suggestion)
Hi Marcelo, On Thursday 10 October 2002 14:07, [EMAIL PROTECTED] wrote: > ... > RTF is not intended to provide full rendering capabilities, it is > in scope somewhere between docbook and FO. It mixes style and content, > the illness for which stylesheets where designed. >. . . Sure, I don't know anyone who likes RTF as a format, it is badly specified and has many shortcomings. But so is life sometimes ;-) The aim is to be able to produce *editable* documents from FOP, semi-finished documents that can be reviewed and possibly modified. Although many would prefere to use another format, it is a fact that RTF is widely used today for this task. This has been discussed many times on this list already, please have a look at the archives for more precise info. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: New Developer Suggestion
Although I'd appreciate the capability to produce RTF files from DocBook documents, I really don't think FOP would be the right tool to do it. RTF is not intended to provide full rendering capabilities, it is in scope somewhere between docbook and FO. It mixes style and content, the illness for which stylesheets where designed. I think it would be feasible to produce the RTF directly with XSLT stylesheets (it is text based anyway), and rely on Word and other RTF-aware editors to render the document. Has anyone tried that? I'd rather see FOP incorporate more crucial features like floats and auto tables then simply degrade a FO file into RTF. = Marcelo Jaccoud Amaral Petrobrás (http://www.petrobras.com.br) mailto:[EMAIL PROTECTED] voice: +55 21 2534-3485 fax: +55 21 2534-1809 = There are only 10 kinds of people in the world: those who understand binary and those who don't. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: New Developer Suggestion
J.Pietschmann wrote: ... > > For working on HEAD, pick an area: > - layout core > - a renderer > - the font subsystem > - API and configuration > - parsing and property resolution Don't pick this one. There is definitely a lot of work going on in this area, which will at least be relevant to HEAD. > - FO extensions Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ "Lord, to whom shall we go?" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: New Developer Suggestion
Sauyet, Scott (OTS-HAR) wrote: >>So what I was hoping for is a suggestion for something that I can work >>on that might be useful, but not critical to any immediate plans, >>ideally something that overlaps little with currently active portions of >>the project. > > > There were no replies yesterday. Well, I thought I wait for one of the lead developers to surface. First, you'll have to decide whether you want to work on the redesigned code (CVS HEAD), or fix bugs, or do some experiments in the maintenance branch. Either way has it's pros and cons. Picking work for the maintenance branch is easy: there's bugzilla, and the list. The advantage is taht you might immediately help some people, the drawback is that your work is lost after the maintenance branch is abandoned, and you probably can't take much to CVS HEAD. For working on HEAD, pick an area: - layout core - a renderer - the font subsystem - API and configuration - parsing and property resolution - FO extensions Expertise neede for the layout core - Java - intimate XSLFO knowledge, up to language lawyering - layout algorithms (and TR14) - the current design There is a task list, as already noted. A small task not on the list would be to provide the Unicode character propery DB. For a renderer, you'll need mainly knowledge of the rendered format. A small, self containing task would be implementing PDF encryption. There's also a task list. Font subsystem: - the metric file generators probably need lots of fixes. Get a lot of fonts from public directories and other sources and try them. - support for other font file formats - improve usability of the font metrics generators (auto format detection, write a GUI, leverage platform specific repositories) API and configuration: search the list for the discussions - get rid of static configuration data - redesign API with emphasis on easy embedding - URI resolving for images and font files - configurable image chaching - configurable image format detection and handling - auto-detection of image format support (in particular JAI vs. JIMI) FO extensions - author and other information for PDF and perhaps other formatss - cache="yes|no" for external-graphics - embed forms and JS stuff in PDF. - embedding binary image formats, for example base64 encoded in instream-foreign-object - look at MathML support - dig out a processor which produces charts and graphs form some marked up data and tie it into instream-foreign-object J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Where to start for an RTF renderer (was: New Developer Suggestion)
Hi Scott, On Wednesday 09 October 2002 17:15, Sauyet, Scott (OTS-HAR) wrote: >. . . > So is integrating other renderers something that the group > would eventually like to do? >. . . Yes, we've been talking about structure-based renderers (like RTF and MIF) vs. layout-based ones (PDF being the focal point) for some time. The following messages might shed some light on this: http://marc.theaimsgroup.com/?l=fop-dev&m=102742684000426&w=2 http://marc.theaimsgroup.com/?l=fop-dev&m=102795797014083&w=2 >. . . > As of today, I know nothing about PDF syntax and little about RTF. I > figure I'm going to have to learn both. I understand FO fairly well, and I > speak Java fairly fluently. What do you think is first priority? >. . . As Jeremias said, you're the one who decides what you'd like to work on. I'm personally biased towards the RTF renderer because that's the part I know best, so here are some starting points if you're interested in studying this in more detail and hopefully jumping in. You won't need much RTF knowledge to start with as the jfor RTF library will generate it for you, and no PDF knowledge at all since this RTF renderer will bypass the layout and PDF generation stages completely. Starting points: 1) org/apache/fop/apps/StructureHandler is the base class that receives structure events from the FO tree while the input XSL-FO is being parsed. The main class of the RTF renderer will inherit from this class to transform the events into an RTF document. 2) Package org/apache/fop/mif is an example of how to build a "structure-based renderer" similar to what the RTF renderer (org/apache/fop/rtf) will be. 3) jfor (www.jfor.org) is currently a separate project that converts XSL-FO to RTF directly, but could take advantage of FOP's much better handling of XSL-FO properties, hence the plan of replacing jfor by a FOP RTF renderer. 4) My suggestion is to first use the RTF library from jfor in binary form, by including jfor's jar in the FOP distribution, to create the RTF document from the StructureHandler events. The current jfor code does a similar thing where the jfor Converter (jfor/jfor/converter/Converter) uses SAX events to drive the jfor RTF library. Later, when FOP becomes better than jfor at generating RTF, we can move the jfor RTF library code into the FOP codebase. I'd like this to happen in a second stage to avoid having to maintain two RTF libraries while both projects coexist. Hope this helps - feel free to ask any additional questions! -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: New Developer Suggestion
Sauyet, Scott wrote: > Does anyone have a suggestion about something I could look at fixing / > enhancing which is not mission-critical, but which might give me a chance > to look at a fair bit of the code? There are some documents in the trunk docs/design directory that have a list of things that need to be done. I last night finished creating a pdf document that can be built from them (a comprehensive FOP Developer Documentation). I can't submit that patch until the last one is committed, but I'll be happy to send it to you by email if you wish. It isn't perfect, but is usable. (I didn't write it, I'm just trying to get it more visible). Victor Mote (mailto:[EMAIL PROTECTED]) Enterprise Outfitters (www.outfitr.com) 2025 Eddington Way Colorado Springs, Colorado 80916 Voice 719-622-0650, Fax 720-293-0044 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Off-Topic Gripe (WAS:RE: New Developer Suggestion)
I think "struggling" might be understating it, at least for me. Kull Wahad! Why does the work come in faster than time? I think I smell the secret to hyperspace here... -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 09, 2002 2:07 PM To: [EMAIL PROTECTED] Subject: Re: New Developer Suggestion Hi Scott Your offer is highly appreciated even if the feedback to your initial mail was a bit sparse. :-) We're all struggling for time to work on FOP and gladly take any helping hand. On 09.10.2002 17:15:21 Sauyet, Scott (OTS-HAR) wrote: > > = Bertrand Delacretaz <[EMAIL PROTECTED]> > >> = Scott Sauyet <[EMAIL PROTECTED]> > > >> Does anyone have a suggestion about something I could look at fixing / > >> enhancing which is not mission-critical, but which might give me a chance > >> to look at a fair bit of the code? > > > The integration of jfor (www.jfor.org) as a structure renderer for RTF > > documents is still waiting for someone to jump in. If you have good java > > skills and want to tackle this one we can certainly help you find your > way. > > I expect my Java skills are up to the task. This is all J2SE, right? I > have no experience with J2ME, and only a little with J2EE. That's fully sufficient. We're only doing J2SE here. > I don't really have a sense of the charter of FOP. I know that there is a > an AWT Renderer as well as the PDF converter, but is that meant more as a > testing system than as something critical to the central project? Or do I > misunderstand? So is integrating other renderers something that the group > would eventually like to do? FOP already has quite a bunch of renderers: PDF, AWT, PS, MIF, Text etc. PDF is the classic renderer. It has traditionally the best quality. The redesign focuses on PDF at the moment and as soon as the layout is advanced enough we will surely begin to reimplement the other renderers again. AFP and others will also be welcome additions. So, we're not really talking about a testing system. PDF is just the most important format. And AWT output is just another. > For me, that would be a real plus, as I'm hoping to eventually work with > PDLs for high-volume printers. As FOP is in a redesign phase it would be nice to have help with bringing FOP's layout to the level of the current maintenance branch before implementing more output formats. PDF is the reference and once this works acceptably we can think about reimplementing all other renderers including new ones. Integrating JFOR as suggested by Betrand is also a good idea, because it doesn't depend so much on the layout stuff. Actually, we can't tell you what you should do. If you like to implement a AFP renderer, then do it. Any help is welcome. Look here for todo lists: (Unfortunately we don't have a single todo list ATM) - http://cvs.apache.org/viewcvs.cgi/xml-fop/status.xml - http://xml.apache.org/fop/todo.html - Bugzilla To get familiar with FOP and the new design the following is a good starting point: http://xml.apache.org/fop/design/index.html > > But note that this part of FOP is not at all related to PDF layout, fonts, > > > etc., it's a fairly different way of rendering documents. > > As of today, I know nothing about PDF syntax and little about RTF. I figure > I'm going to have to learn both. I understand FO fairly well, and I speak > Java fairly fluently. What do you think is first priority? > > So how would we expect this to integrate. What user code would change to > generate an RTF document rather than a PDF one? > > And as to mechanics, what code should I start with? The output format is decided in the org.apache.fop.apps.Driver class ATM. Use that as a starting point. The StructureHandler class is the another important focus point for integrating RTF. You should also search the mailing list archives for the discussion on the JFOR integration. That will explain how this should be done. Good luck diving into FOP. We'll try to support you as best as we can. Fire away with questions as they come up! Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: New Developer Suggestion
Hi Scott Your offer is highly appreciated even if the feedback to your initial mail was a bit sparse. :-) We're all struggling for time to work on FOP and gladly take any helping hand. On 09.10.2002 17:15:21 Sauyet, Scott (OTS-HAR) wrote: > > = Bertrand Delacretaz <[EMAIL PROTECTED]> > >> = Scott Sauyet <[EMAIL PROTECTED]> > > >> Does anyone have a suggestion about something I could look at fixing / > >> enhancing which is not mission-critical, but which might give me a chance > >> to look at a fair bit of the code? > > > The integration of jfor (www.jfor.org) as a structure renderer for RTF > > documents is still waiting for someone to jump in. If you have good java > > skills and want to tackle this one we can certainly help you find your > way. > > I expect my Java skills are up to the task. This is all J2SE, right? I > have no experience with J2ME, and only a little with J2EE. That's fully sufficient. We're only doing J2SE here. > I don't really have a sense of the charter of FOP. I know that there is a > an AWT Renderer as well as the PDF converter, but is that meant more as a > testing system than as something critical to the central project? Or do I > misunderstand? So is integrating other renderers something that the group > would eventually like to do? FOP already has quite a bunch of renderers: PDF, AWT, PS, MIF, Text etc. PDF is the classic renderer. It has traditionally the best quality. The redesign focuses on PDF at the moment and as soon as the layout is advanced enough we will surely begin to reimplement the other renderers again. AFP and others will also be welcome additions. So, we're not really talking about a testing system. PDF is just the most important format. And AWT output is just another. > For me, that would be a real plus, as I'm hoping to eventually work with > PDLs for high-volume printers. As FOP is in a redesign phase it would be nice to have help with bringing FOP's layout to the level of the current maintenance branch before implementing more output formats. PDF is the reference and once this works acceptably we can think about reimplementing all other renderers including new ones. Integrating JFOR as suggested by Betrand is also a good idea, because it doesn't depend so much on the layout stuff. Actually, we can't tell you what you should do. If you like to implement a AFP renderer, then do it. Any help is welcome. Look here for todo lists: (Unfortunately we don't have a single todo list ATM) - http://cvs.apache.org/viewcvs.cgi/xml-fop/status.xml - http://xml.apache.org/fop/todo.html - Bugzilla To get familiar with FOP and the new design the following is a good starting point: http://xml.apache.org/fop/design/index.html > > But note that this part of FOP is not at all related to PDF layout, fonts, > > > etc., it's a fairly different way of rendering documents. > > As of today, I know nothing about PDF syntax and little about RTF. I figure > I'm going to have to learn both. I understand FO fairly well, and I speak > Java fairly fluently. What do you think is first priority? > > So how would we expect this to integrate. What user code would change to > generate an RTF document rather than a PDF one? > > And as to mechanics, what code should I start with? The output format is decided in the org.apache.fop.apps.Driver class ATM. Use that as a starting point. The StructureHandler class is the another important focus point for integrating RTF. You should also search the mailing list archives for the discussion on the JFOR integration. That will explain how this should be done. Good luck diving into FOP. We'll try to support you as best as we can. Fire away with questions as they come up! Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: New Developer Suggestion
> = Bertrand Delacretaz <[EMAIL PROTECTED]> >> = Scott Sauyet <[EMAIL PROTECTED]> >> Does anyone have a suggestion about something I could look at fixing / >> enhancing which is not mission-critical, but which might give me a chance >> to look at a fair bit of the code? > The integration of jfor (www.jfor.org) as a structure renderer for RTF > documents is still waiting for someone to jump in. If you have good java > skills and want to tackle this one we can certainly help you find your way. I expect my Java skills are up to the task. This is all J2SE, right? I have no experience with J2ME, and only a little with J2EE. I don't really have a sense of the charter of FOP. I know that there is a an AWT Renderer as well as the PDF converter, but is that meant more as a testing system than as something critical to the central project? Or do I misunderstand? So is integrating other renderers something that the group would eventually like to do? For me, that would be a real plus, as I'm hoping to eventually work with PDLs for high-volume printers. > But note that this part of FOP is not at all related to PDF layout, fonts, > etc., it's a fairly different way of rendering documents. As of today, I know nothing about PDF syntax and little about RTF. I figure I'm going to have to learn both. I understand FO fairly well, and I speak Java fairly fluently. What do you think is first priority? So how would we expect this to integrate. What user code would change to generate an RTF document rather than a PDF one? And as to mechanics, what code should I start with? Thanks for any info, -- Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: New Developer Suggestion
Hi Scott, On Wednesday 09 October 2002 16:20, Sauyet, Scott (OTS-HAR) wrote: > Does anyone have a suggestion about something I could look at fixing / > enhancing which is not mission-critical, but which might give me a chance > to look at a fair bit of the code? The integration of jfor (www.jfor.org) as a structure renderer for RTF documents is still waiting for someone to jump in. If you have good java skills and want to tackle this one we can certainly help you find your way. But note that this part of FOP is not at all related to PDF layout, fonts, etc., it's a fairly different way of rendering documents. -- Bertrand Delacrétaz (codeconsult.ch, jfor.org) buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding. disclaimer: eternity is very long. mostly towards the end. get ready. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: New Developer Suggestion
Me: > So what I was hoping for is a suggestion for something that I can work > on that might be useful, but not critical to any immediate plans, > ideally something that overlaps little with currently active portions of > the project. There were no replies yesterday. Does anyone have a suggestion about something I could look at fixing / enhancing which is not mission-critical, but which might give me a chance to look at a fair bit of the code? Thanks, -- Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
New Developer Suggestion
Hi, my name is Scott Sauyet, a Java developer in Connecticut, USA. I'm new to this group. I've been reading for about a month, but have made no contributions yet. I would like to contribute. Eventually, I hope to understand the system well enough to produce a spin-off which could render output for high-volume printers, in Xerox Metacode, AFP, or some such; this would be very useful for my industry. First, obviously, I have to learn how it all works. I'm looking for a suggestion. When trying to learn a system, I usually find it easiest to have some task, some project that would improve the product. I don't want to assign any work to myself from the bug list. I don't know how much time I can dedicate to it, and I don't want anyone thinking something is being actively worked on when it's not clear if I can deliver or when it might be ready. So what I was hoping for is a suggestion for something that I can work on that might be useful, but not critical to any immediate plans, ideally something that overlaps little with currently active portions of the project. If you have any ideas, please let me know, either on or off the mailing list. Thanks, -- Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
