Re: startup refactoring
On 17.06.2003 21:28:29 Glen Mazza wrote: Instinctively, I wouldn't trust any code in the package root of org.apache.fop -- we wouldn't have a very modularized design that way (knowing FOP's current coding style, the main FOP API would then be accessing objects all through the packages, octopus-like, splitting of the business logic with the actual objects doing the work, inextricable from the XSL FO process.) Not necessarily. Well, the public API has to have some way to control the whole show. This will automatically lead to a little octopus if the code is in ...fop or ...fop.api. But no problem with another package. FOP is more a pipeline to me: APPs package (CLI, TRAX/XSLTInputHandler, Avalonized API, Victor's ideas) -- FOTreeBuilder/Layout/Area Tree creation -- Rendering. Uh, thanks for that one. It's a very nice show why the current apps package is a mess. SoC (Separation of Concerns) would suggest not to mix thing like CLI, public API and inner communication classes. IMO FOTreeBuilder should just expose three functions (perhaps another one for logging): Logging, at least in Avalon-land, is a lifecycle aspect (through the LogEnabled interface). The methods below are lifestyle methods. Lifecycle != lifestyle. It's best to talk about lifestyle primarily and leave the lifecycle (instantiation, logging, configuration, initialization) to a different discussion. Helps keeping the focus, I believe. The lifecycle can eventually be handled automatically by a container (such as Fortress or Merlin). Leaves you to care about the lifestyle (=functionality). 1.) SetXSLFOStream() (file or stream) 2.) SetRenderType() (those constants currently in Driver or CommandLineStarter) 3.) Run(). (returns a stream or file) This mixes concerns. A render type does not belong in a class called FOTreeBuilder. The name already implies that the class is responsible for building the FO tree. It should have nothing to do with the rendering aspect, especially since FO tree building is independant of the output format (wrt Renderers). The render type is better placed in a class such as a RenderingRun/Document/whatever-we-call-it. The FO tree builder is (to me) a service that simply accepts a SAX stream and builds the FO tree. The layout engine, another (coarse grained) service, will then access the FO tree to do the layout. This is all kept together by a supervising class. At least, that's my personal high-level view of it. You can have 500 methods of calling these functions within the apps package--it's all fine/OK, because they will only be able to work with FOTreeBuilder (apps will have no access to Renderers or Layout, etc.) and its three functions. Such an FOTreeBuilder may be getting to the heart of the XSLFO Spec: Input: XSLFO Stream, RenderType Output: Document and may be close to Xalan's approach, a team which has similar input/output requirements. Also, embedded Java code should be able to run without accessing the Apps class at all by directly calling those three functions in FOTreeBuilder. The FOTreeBuilder should remain an inner service to FOP, not exposed in the public API, if you ask me. The public API, IMHO, should be an easily understandable construct that masks the internal complexity from the user. Driver already does that today, it's just a bit too tightly packed and not focused on as little as possible. We need to disentangle that class to make it more like the JAXP API. (Although we can certainly provide additional options in apps--but FOTreeBuilder should be all that is strictly needed.) Said another way, the processing paths of FOTreeBuilder, once instantiated in embedded code, should not access *any* functionality in the apps package, because apps is to the left of the pipeline. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] Nomination of Glen Mazza as committer
Christian Geisert schrieb: Oleg Tkachenko schrieb: Jeremias Maerki wrote: I agree, so +1 from me. Here is my +1. +1 Clearly enough +1 and no -1, congratulations Glen! According to http://www.apache.org/dev/pmc.html the account request should be handled by the PMC - so Jeremias or Peter would you please take care of this? Glen, what userid would you like? Some infos for the start: http://www.apache.org/dev/committers.html Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] Nomination of Glen Mazza as committer
Can do. Here's the new account request form that we need to fill: New account request form: To: [EMAIL PROTECTED] Cc: pmc@project.apache.org, [EMAIL PROTECTED] Subject: Apache account request Full name:... Preferred userid: ... Forwarding email address: ... Requested karma: project[/subproject] ... [Vote: link to mail archive for PMC bookkeeping] On 18.06.2003 10:21:42 Christian Geisert wrote: Clearly enough +1 and no -1, congratulations Glen! According to http://www.apache.org/dev/pmc.html the account request should be handled by the PMC - so Jeremias or Peter would you please take care of this? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: new Logo
Christian Geisert wrote: What's going on with the new logo? The logo #30 [1] won the contest. It's by Tobias Muller, modified by Scott Hofmann. Some of us talked about additional tweaking and Scott said [2] he's ready to go for it. That's it afaik. I propose to put an end to this - let's discuss additional tweaking and get finally new logo (we need also SVG version). [1] http://www.tkachenko.com/fop/logocontest/fop_logo-revised-Tobias-Muller.jpg [2] http://marc.theaimsgroup.com/?l=fop-devm=105361141331672w=2 -- Oleg Tkachenko http://www.tkachenko.com/blog Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20868] New: - max external graphic height depends on region-body
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20868. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20868 max external graphic height depends on region-body Summary: max external graphic height depends on region-body Product: Fop Version: 0.20.5 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: images AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I try to produce a Spare Parts List PDF with Apache FOP 0.20.5rc3a. On even pages I just have a static explosion drawing and on odd pages a table with spare parts, that can spread over multiple pages. To do this I use repeatable- page-master-alternatives. To get nice page breaks, I have a pseudo region-body with a height of 1mm on the even pages (the flow is the table, the explosion drawing is on a static-content-area). Unfortunately I had to find out, that the external graphic on the static content area cannot be higher than the height of the region-body. Since I only have a pseudo region-body of 1mm height, the image is rendered far too small ;) I do not think that this is desired behaviour. So I stepped into the source code (I start to love open source). And in org.apache.fop.fo.flow.ExternalGraphic.layout(Area area) in line 209 I found out that the maximum height of the external graphic is indeed dependent on area.getPage().getBody().getMaxHeight(). But this class is used for static content areas, too. I changed this to area.spaceLeft(). For my special rendering this works fine. Of course, I do not have a clue, if this is a solution for any boundary condition. I would really appreciate if you could have a look at it. Thanks, FloH - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20879] New: - Leader is broken in PS Renderer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20879. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20879 Leader is broken in PS Renderer Summary: Leader is broken in PS Renderer Product: Fop Version: 0.20.5 Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: general AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The postscript renderer produces broken output when trying to render a leader. I'm not a postscript expert but comparing 0.20.4 (where it works) to 0.20.5rc3a (where it's broken) it looks like a couple of moveto's are missing. The FO below will produce the bad postscript. PDF rendering works fine. ?xml version=1.0 encoding=UTF-8? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master margin-right=0.3in margin-left=0.3in margin-bottom=0.1in margin-top=0.1in page-width=8.5in page-height=11in master-name=fax fo:region-body margin-left=0.3mm margin-bottom=65mm margin-top=30mm/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=fax fo:flow flow-name=xsl-region-body fo:block fo:leader rule-thickness=.5mm leader-pattern=rule leader-length=200mm/ /fo:block /fo:flow /fo:page-sequence /fo:root - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20879] - Leader is broken in PS Renderer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20879. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20879 Leader is broken in PS Renderer --- Additional Comments From [EMAIL PROTECTED] 2003-06-18 17:05 --- I am attaching a patch that seems to fix it. I'm not sure why though. Just reverting a previous change. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20868] - max external graphic height depends on region-body
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20868. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20868 max external graphic height depends on region-body --- Additional Comments From [EMAIL PROTECTED] 2003-06-18 17:05 --- Created an attachment (id=6874) Proposed patch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20879] - Leader is broken in PS Renderer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20879. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20879 Leader is broken in PS Renderer --- Additional Comments From [EMAIL PROTECTED] 2003-06-18 17:06 --- Created an attachment (id=6875) Proposed patch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20868] - max external graphic height depends on region-body
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20868. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20868 max external graphic height depends on region-body --- Additional Comments From [EMAIL PROTECTED] 2003-06-18 17:07 --- Oops, ignore attachment. Wrong bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[RTF] Jfor integration
Bertrand et al: I did a little work in RTFHandler yesterday (after reading the wiki related email messages on the topic), committing a change to implement text-align for paragraphs, mostly just to get a feel for what is going on there. I was using examples/fo/basic/normal.fo as my test document, so the next thing I thought I would mess with was paragraph shading (background-color). It looked like that was not implemented in the jfor libs, so I was trying to set up my IDE to use the jfor source watch it in the debugger. Some of the source files contain non-ASCII characters (see main/JForVersionInfo.java, line 67, for example), but are encoded as ASCII (instead of UTF-8), so the IDE was choking. This is easy to fix, and I am tempted to go ahead and drop the jfor source code into the FOP repository start hacking away. What do you think? The wiki made me think that maybe you were wanting to keep your options open. I guess the other issues that raises are 1) dropping in the Apache license (looks like no problem), and some style issues. What are your thoughts on all of this? Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [RTF] Jfor integration
+1 for working on JFOR integration. If JFOR's sources should go into CVS, I think from the licensing point of view, Bertrand will have to do the initial import of the sources. I believe, this performs an implicit grant process because of his committer license agreement. Victor, I don't want to draw you away from the API stuff with my earlier comments. I promise to come up with constructive thoughts within the next few days. My brain is already working on it. On 18.06.2003 19:09:01 Victor Mote wrote: I am tempted to go ahead and drop the jfor source code into the FOP repository start hacking away. What do you think? The wiki made me think that maybe you were wanting to keep your options open. I guess the other issues that raises are 1) dropping in the Apache license (looks like no problem), and some style issues. What are your thoughts on all of this? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [RTF] Jfor integration
Jeremias Maerki wrote: +1 for working on JFOR integration. If JFOR's sources should go into CVS, I think from the licensing point of view, Bertrand will have to do the initial import of the sources. I believe, this performs an implicit grant process because of his committer license agreement. It sure can't hurt. That sounds like a good idea. Victor, I don't want to draw you away from the API stuff with my earlier comments. I promise to come up with constructive thoughts within the next few days. My brain is already working on it. Not at all -- I understand the process. I think we are probably after much the same thing, just viewing it from different angles -- you from API, I from control of the processing. I have a lot to learn on the multithreading issues, but AFAIK, the two are completely compatible, and in fact complementary. On the RTF stuff, it is rare that I can string enough time together to do any coding, so I hate to waste it when it is there. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: startup refactoring
--- Jeremias Maerki [EMAIL PROTECTED] wrote: On 17.06.2003 21:28:29 Glen Mazza wrote: Instinctively, I wouldn't trust any code in the package root of org.apache.fop -- we wouldn't have a very modularized design that way (knowing FOP's current coding style, the main FOP API would then be accessing objects all through the packages, Well, the public API has to have some way to control the whole show. You don't mean that literally--e.g.., a servlet programmer does not need useThisRenderer() and attachAreaTree() functions in a public API. (i.e., the public (embedded) API would be a strict subset of the functions available to the supervising octopus running the show) This will automatically lead to a little octopus if the code is in ...fop or ...fop.api. But no problem with another package. For my discussion, apps=api (they're both supervising octopi). (Although I'm sure your package would be orders-of-magnitude cleaner and simpler!) FOP is more a pipeline to me: APPs package (CLI, TRAX/XSLTInputHandler, Avalonized API, Victor's ideas) -- FOTreeBuilder/Layout/Area Tree creation -- Rendering. Uh, thanks for that one. It's a very nice show why the current apps package is a mess. I agree with you that the apps package is hideous--but a pipeline may cleanup nearly all of it, providing it enforces the rules I mentioned earlier: a.) The only access between apps/api and the rest of the packages is via FOTreeBuilder and its three functions. b.) FOP is designed such that FOTreeBuilder *can* be directly instantiated via a servlet (even if we don't allow it). c.) Once so instantiated, no code within apps/api packages can be referenced. Via these rules, look at what gets removed from apps: (a) structure and layout handler are gone (those are past the FOTreeBuilder) (b) AWTStarter and PrintStarter are gone (those processing decisions are either handled by FOTreeBuilder or something that it delegates to.) (c) App class has *no* knowledge of renderers, element mappings, area trees, structure handlers. (d) Business logic is kept with each object, and not shared in multiple places. IMO FOTreeBuilder should just expose three functions (perhaps another one for logging): It's best to talk about lifestyle primarily and leave the lifecycle (instantiation, logging, configuration, initialization) to a different discussion. Helps keeping the focus, I believe. Excellent! We can leave that distraction out of the discussion. (Although they, in addition to threading issues, *do* appear to strengthen your argument on the need for a supervising class.) 1.) SetXSLFOStream() (file or stream) 2.) SetRenderType() (those constants currently in Driver or CommandLineStarter) 3.) Run(). (returns a stream or file) This mixes concerns. A render type does not belong in a class called FOTreeBuilder. I think it does, because it needs to know whether or not to generate an Area Tree, *which type* of structure handler, etc., also, since the Area Tree needs to know the render type, FOTreeBuilder will need to pass that information on to it via the pipeline. (Peter had said and you confirmed that the Area Tree still needs to know the rendering type for font sizes, etc.) Furthermore a different implementation of FOTreeBuilder may make different Area Tree decisions based on its render_type. It should have nothing to do with the rendering aspect, especially since FO tree building is independant of the output format (wrt Renderers). Indeed, nothing to do with *rendering* but it does need to know the render_type as mentioned above. APPS/API knows nothing but FOTreeBuilder, which knows nothing but AreaTree, which knows nothing but the Renderers. So I also agree with you that FOTreeBuilder doesn't need to know about the Renderers. (but it could be so redesigned in the future, depending on the pluggable implementation of FOTreeBuilder, and this design more easily allows for that type of change.) The render type is better placed in a class such as a RenderingRun/Document/whatever-we-call-it. Sure, providing they pass that information on to FOTreeBuilder. ;) The FO tree builder is (to me) a service that simply accepts a SAX stream and builds the FO tree. IMHO FOTreeBuilder is an object (C++/Java), not a service (C). The layout engine, another (coarse grained) service, will then access the FO tree to do the layout. This is all kept together by a supervising class. If we were doing C programming--my fear is that the supervising class is going to end up eating FOP's object-oriented design and splitting the business logic too much in multiple places (just like apps currently does). (I guess I'll just have to trust the team to be disciplined in this regard! ;) The FOTreeBuilder should remain an inner service to FOP, not exposed in the public API, if you ask me. OK, a *very* thin wrapper (for those not needing any of the threading/logging
Re: alt-design merits (WAS: Nomination of Glen Mazza as committer)
Victor, Trying to answer your latest questions on this topic has absorbed a deal of my time, exposed a contradiction in my thinking, and made me think through in more detail some of the fuzzy bits. I am still working on it, and I will get back to you. Thanks for the interrogation. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Eclipse Ant SerializeHyphPattern failure
Jeremias,
I'll try it and commit if it works.
Peter
Jeremias Maerki wrote:
Hmm, I've given up running Ant under Eclipse. Gave me too much of a
headache and it works well for me outside of Eclipse.
But I think the trick is to use ${basedir} instead of . in build.xml
because Eclipse has to set the base directory so everything is ok. I
have done some other changes locally that I cannot commit, yet, because
I'm blocked on an issue. So I can't commit my build.xml. Can you do it,
please?
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
