You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by "Peter B. West" <pb...@tpg.com.au> on 2004/07/20 05:03:07 UTC
Withdrawal of PMC nomination
Fopsters,
I have been discussing with Jeremias offline the appropriateness or
otherwise of my being on the XML Graphics PMC. On reflection, I had
some reservations, and I have decided to withdraw my nomination for the
XML Graphics PMC, on the understanding that I will continue to take a
keen interest in the factoring out of the graphics components.
Peter
--
Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
Re: Withdrawal of PMC nomination
Posted by Clay Leeds <cl...@medata.com>.
Peter B. West said:
> Clay, Glen, et al,
>
> I'm thinking of moving FAD development to SourceForge. My differences
> in approach are much more significant than Victor's, so much so that I
> have nothing to contribute to the discussions about details of
> implementation in HEAD. Like Victor, I retain an interest in seeing my
> ideas incorporated into FOP, and it seems that Victor's move may have
> opened much clearer channels of communication, without muddying the
> waters day-to-day.
>
> Jeremias' ideas about factoring out useful stand-alone elements from the
> combination of FOP and Batik are essential to the direction I am taking
> with layout and rendering, aside from being a Good Thing in their own
> right. That interest motivated my nomination for the PMC, but disguised
> the underlying differences concerning FOP. However, the primary
> business of the XML Graphics PMC, for the immediate future, will be the
> development of HEAD in FOP, and while I am thinking about moving, it
> doesn't seem to me to be appropriate to be on the PMC.
>
> Peter
>
> Clay Leeds wrote:
>> Glen is not alone in his expression of that sentiment. I too think that
>> was an unfortunate decision, and I suspect that others share it as well.
>> Perhaps it *might* help me and others understand why you've made this
>> decision (then again, it might not--we might still think it's an
>> unfortunate decision... ;-)).
> --
> Peter B. West <http://cv.pbw.id.au/>
Thanks for taking the time to make this clearer. I guess I would have to
say It Makes Absolutely Some Sense Whatsoever(tm). Just the same, I
certainly hope to hear your eloquent, knowledgeable voice chime into the
discussions.
Web Maestro Clay
--
Clay Leeds - cleeds@medata.com
Web Developer - Medata, Inc. - http://www.medata.com
PGP Public Key: https://mail.medata.com/pgp/cleeds.asc
Re: Withdrawal of PMC nomination
Posted by Glen Mazza <gr...@yahoo.com>.
Thanks for the elaboration--also the links to the pull
parsing sites.
Glen
--- "Peter B. West" <pb...@tpg.com.au> wrote:
> All of the requirements for inputs, transformations,
> etc, are the same,
> because I am using SAX "under the hood." But when a
> native pull parser
> comes along, say as a result of Andy Clark's work
> with NekoPull
>
<http://www.apache.org/~andyc/neko/doc/pull/index.html>,
> XmlPull
> <http://www.xmlpull.org/>, JSR173 Streaming API for
> XML
> <http://jcp.org/en/jsr/detail?id=173>, or the
> WebLogic XML Streaming API
>
<http://e-docs.bea.com/wls/docs70/xml/xml_stream.html>,
> I will happily
> ditch SAX. Whether the Streaming API will be JAXP
> compliant is a moot
> point. If not, it is another wedge between FOP and
> FAD.
>
Re: Withdrawal of PMC nomination
Posted by "Peter B. West" <pb...@tpg.com.au>.
Glen Mazza wrote:
> --- "Peter B. West" <pb...@tpg.com.au> wrote:
>
>>Jeremias' ideas about factoring out useful
>>stand-alone elements from the
>>combination of FOP and Batik are essential to the
>>direction I am taking
>>with layout and rendering, aside from being a Good
>>Thing in their own
>>right.
>
>
> Yes, I've pulled about 8 methods from the Renderer
> interface so far, giving Renderer implementors a
> little more freedom in how they choose to implement
> one.
>
> Also, I removed direct
> FOTreeBuilder.addElementMapping() methods which should
> HEAD a little bit more FAD-friendly (FAD, of course,
> doesn't have element mappings). The external user
> sets them in FOUserAgent instead, and HEAD's
> FOTreeBuilder reads from the FOUserAgent object to
> obtain them. The FAD version of an FOTreeBuilder
> would simply ignore this setting.
>
> This doesn't mean I'm trying to move to FAD's pull
> parsing--I'm not--
Shucks.
> but if I can increase the number of
> components you can use, so much the better. (To that
> end, notice the one-line of code in
> getDefaultHandler() in Driver that initializes
> FOTreeBuilder. If FAD's FOTreeBuilder equivalent can
> work with these arguments--a render type, output
> stream, FOUserAgent object--great! That would mean
> fop.apps package can be the same between two systems.)
I think there are some possibilities here. A lot of what you are doing
seems kindred (in spirit, at least) with Victor's approach. I'll take
whatever I can get from FOP for FAD, and the more commonality the
better. But there is a fundamental difference in approach to XML events
in pull parsing, which liberates application processing to a degree
which I don't think is appreciated by habituated SAX users. In FAD the
scope of XML parsing is entirely circumscribed by the parser thread,
which runs on-demand.
All of the requirements for inputs, transformations, etc, are the same,
because I am using SAX "under the hood." But when a native pull parser
comes along, say as a result of Andy Clark's work with NekoPull
<http://www.apache.org/~andyc/neko/doc/pull/index.html>, XmlPull
<http://www.xmlpull.org/>, JSR173 Streaming API for XML
<http://jcp.org/en/jsr/detail?id=173>, or the WebLogic XML Streaming API
<http://e-docs.bea.com/wls/docs70/xml/xml_stream.html>, I will happily
ditch SAX. Whether the Streaming API will be JAXP compliant is a moot
point. If not, it is another wedge between FOP and FAD.
> In general, I'm trying to move away from supporting
> direct manipulation of internal objects from external
> users: e.g., AreaTree.setWidget(), etc. and instead am
> placing the customization in FOUserAgent (or the xml
> configuration file, perhaps) for the internal objects
> to read. That way if an alternative implementation
> has nothing to do with widgets, it can simply ignore
> the setting in FOUserAgent without being forced to
> implement an architecture-breaking setWidget(). This
> also gives future implementors ability to completely
> revamp things internally without worrying about the
> API.
The layout engine that I'm currently working on looks as though it will
have three threads - a parser thread (which will disappear in a
streaming parser), a layout engine and a renderer.
<Press button="Repeat">
The Area tree is built in lockstep with the FO tree. An area may
provide the context for the resolution of properties on the descendants
of the FO that generated that area. The integration is that tight.
Furthermore, page layout begins with the start tag of a page-sequence
fo:flow, not the end-tag. It is pull parsing that makes this feasible,
and makes possible the solution of FOP's most critical problem - memory.
It doesn't matter how long the page sequence is in FAD.
</Press>
An API which is to accommodate both FOP and FAD must be able to span
such fundamental differences.
Incidentally, IIUC, the above is not to do with "eager" layout. That
was a property of layout strategies, concerning how much *layout*
context was examined before a final layout decision was taken. In my
understanding, it related to the ability to adjust layout across
multiple paragraphs or pages in order to find a better quality solution,
as opposed to making those decisions based only on local layout
information. The same decisions must be made in FAD.
However, the first order of business for FAD is to get basic layout
working, then demonstrate multi-columns with footnotes, marker
processing with inheritance from static-content, floats, keeps, and
last-page processing, in no particular order.
Peter
--
Peter B. West <http://cv.pbw.id.au/>
Re: Withdrawal of PMC nomination
Posted by Glen Mazza <gr...@yahoo.com>.
--- "Peter B. West" <pb...@tpg.com.au> wrote:
> Jeremias' ideas about factoring out useful
> stand-alone elements from the
> combination of FOP and Batik are essential to the
> direction I am taking
> with layout and rendering, aside from being a Good
> Thing in their own
> right.
Yes, I've pulled about 8 methods from the Renderer
interface so far, giving Renderer implementors a
little more freedom in how they choose to implement
one.
Also, I removed direct
FOTreeBuilder.addElementMapping() methods which should
HEAD a little bit more FAD-friendly (FAD, of course,
doesn't have element mappings). The external user
sets them in FOUserAgent instead, and HEAD's
FOTreeBuilder reads from the FOUserAgent object to
obtain them. The FAD version of an FOTreeBuilder
would simply ignore this setting.
This doesn't mean I'm trying to move to FAD's pull
parsing--I'm not--but if I can increase the number of
components you can use, so much the better. (To that
end, notice the one-line of code in
getDefaultHandler() in Driver that initializes
FOTreeBuilder. If FAD's FOTreeBuilder equivalent can
work with these arguments--a render type, output
stream, FOUserAgent object--great! That would mean
fop.apps package can be the same between two systems.)
In general, I'm trying to move away from supporting
direct manipulation of internal objects from external
users: e.g., AreaTree.setWidget(), etc. and instead am
placing the customization in FOUserAgent (or the xml
configuration file, perhaps) for the internal objects
to read. That way if an alternative implementation
has nothing to do with widgets, it can simply ignore
the setting in FOUserAgent without being forced to
implement an architecture-breaking setWidget(). This
also gives future implementors ability to completely
revamp things internally without worrying about the
API.
Glen
Re: Withdrawal of PMC nomination
Posted by "Peter B. West" <pb...@tpg.com.au>.
Clay, Glen, et al,
I'm thinking of moving FAD development to SourceForge. My differences
in approach are much more significant than Victor's, so much so that I
have nothing to contribute to the discussions about details of
implementation in HEAD. Like Victor, I retain an interest in seeing my
ideas incorporated into FOP, and it seems that Victor's move may have
opened much clearer channels of communication, without muddying the
waters day-to-day.
Jeremias' ideas about factoring out useful stand-alone elements from the
combination of FOP and Batik are essential to the direction I am taking
with layout and rendering, aside from being a Good Thing in their own
right. That interest motivated my nomination for the PMC, but disguised
the underlying differences concerning FOP. However, the primary
business of the XML Graphics PMC, for the immediate future, will be the
development of HEAD in FOP, and while I am thinking about moving, it
doesn't seem to me to be appropriate to be on the PMC.
Peter
Clay Leeds wrote:
> Glen is not alone in his expression of that sentiment. I too think that
> was an unfortunate decision, and I suspect that others share it as well.
> Perhaps it *might* help me and others understand why you've made this
> decision (then again, it might not--we might still think it's an
> unfortunate decision... ;-)).
--
Peter B. West <http://cv.pbw.id.au/>
Re: Withdrawal of PMC nomination
Posted by Clay Leeds <cl...@medata.com>.
Glen is not alone in his expression of that sentiment. I too think that
was an unfortunate decision, and I suspect that others share it as
well. Perhaps it *might* help me and others understand why you've made
this decision (then again, it might not--we might still think it's an
unfortunate decision... ;-)).
Web Maestro Clay
On Jul 22, 2004, at 5:27 AM, Peter B. West wrote:
> Glen,
>
> I'm pleased that you think so, bit I believe it was the best course
> for me at the moment.
>
> Peter
>
> Glen Mazza wrote:
>> An unfortunate decision.
>> Glen --- "Peter B. West" <pb...@tpg.com.au> wrote:
>>> Fopsters,
>>>
>>> I have been discussing with Jeremias offline the
>>> appropriateness or otherwise of my being on the XML Graphics PMC. On
>>> reflection, I had some reservations, and I have decided to withdraw
>>> my
>>> nomination for the XML Graphics PMC, on the understanding that I will
>>> continue to take a keen interest in the factoring out of the graphics
>>> components.
> --
> Peter B. West <http://cv.pbw.id.au/>
>
Re: Withdrawal of PMC nomination
Posted by "Peter B. West" <pb...@tpg.com.au>.
Glen,
I'm pleased that you think so, bit I believe it was the best course for
me at the moment.
Peter
Glen Mazza wrote:
> An unfortunate decision.
>
> Glen
>
> --- "Peter B. West" <pb...@tpg.com.au> wrote:
>
>>Fopsters,
>>
>>I have been discussing with Jeremias offline the
>>appropriateness or
>>otherwise of my being on the XML Graphics PMC. On
>>reflection, I had
>>some reservations, and I have decided to withdraw my
>>nomination for the
>>XML Graphics PMC, on the understanding that I will
>>continue to take a
>>keen interest in the factoring out of the graphics
>>components.
--
Peter B. West <http://cv.pbw.id.au/>
Re: Withdrawal of PMC nomination
Posted by Glen Mazza <gr...@yahoo.com>.
An unfortunate decision.
Glen
--- "Peter B. West" <pb...@tpg.com.au> wrote:
> Fopsters,
>
> I have been discussing with Jeremias offline the
> appropriateness or
> otherwise of my being on the XML Graphics PMC. On
> reflection, I had
> some reservations, and I have decided to withdraw my
> nomination for the
> XML Graphics PMC, on the understanding that I will
> continue to take a
> keen interest in the factoring out of the graphics
> components.
>
> Peter
> --
> Peter B. West
> <http://www.powerup.com.au/~pbwest/resume.html>
>