--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
>
> 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
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 block
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 =
> "applicati
Glen Mazza wrote:
Hi Glen,
OH!!!
Yes, you're right, Chris--now I see the issue. I
implemented validation for about 80% of the FOs, but
80% is not 100%. fo:table-body never had any
validation implemented, hence the NPE's that were
occurring.
I'm glad this issue has finally been resolved, tha
Thanks Simon.
Glen
--- [EMAIL PROTECTED] wrote:
>
> spepping2005/03/02 13:03:25
>
> Modified:src/java/org/apache/fop/fo/flow
> TableBody.java
> TableFooter.java
> Log:
> Corrected a validation problem. Made TableFooter
> use TableBody's validation.
>
On Tue, Mar 01, 2005 at 09:15:37PM -0800, Glen Mazza wrote:
> OH!!!
>
> Yes, you're right, Chris--now I see the issue. I
> implemented validation for about 80% of the FOs, but
> 80% is not 100%. fo:table-body never had any
> validation implemented, hence the NPE's that were
> occurring.
Yo
OH!!!
Yes, you're right, Chris--now I see the issue. I
implemented validation for about 80% of the FOs, but
80% is not 100%. fo:table-body never had any
validation implemented, hence the NPE's that were
occurring.
Sorry, Jeremias, I thought you had just gratuitously
*removed* the validatio
Simon,
Thanks for reading and responding to my concerns. I
appreciate it. Your endorsement of this change is
sufficient for me--I am withdrawing my veto.
Regards,
Glen
--- Simon Pepping <[EMAIL PROTECTED]> wrote:
> On Thu, Feb 24, 2005 at 10:21:25PM -0800, Glen Mazza
> wrote:
> >
> > Jeremia
On Thu, Feb 24, 2005 at 10:21:25PM -0800, Glen Mazza wrote:
>
> Jeremias, I'm going to veto (-1) your change. I would
> like the content model restored to the XSL standard
> and the FONode.removeNode() method removed.
I support Jeremias' change, and vote +1.
> Technical reasons:
>
> 2.) You
Jeremias,
My veto still stands, along with the seven technical
reasons given for it.
Glen
--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
>
> On 25.02.2005 07:21:25 Glen Mazza wrote:
>
>
> For the moment I'm not going to answer the veto
> itself. Your veto makes
> this situation a one against
On Feb 24, 2005, at 10:21 PM, Glen Mazza wrote:
--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
I have nothing more to say about this. I want to
spend my time on more
productive things now.
Jeremias, I'm going to veto (-1) your change. I would
like the content model restored to the XSL standard
and
Jeremias Maerki wrote:
On 25.02.2005 07:21:25 Glen Mazza wrote:
For the moment I'm not going to answer the veto itself. Your veto makes
this situation a one against one. I have presented my reasons for the
change and therefore, I request feedback from the rest of the committers
on this matter even
On 25.02.2005 07:21:25 Glen Mazza wrote:
For the moment I'm not going to answer the veto itself. Your veto makes
this situation a one against one. I have presented my reasons for the
change and therefore, I request feedback from the rest of the committers
on this matter even if it's just a short
--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
>
> I have nothing more to say about this. I want to
> spend my time on more
> productive things now.
>
Jeremias, I'm going to veto (-1) your change. I would
like the content model restored to the XSL standard
and the FONode.removeNode() method remo
--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
>
> 2. Empty
> table-bodies make no
> sense but it makes life easier for stylesheet
> writers not to have to
> work around them.
I don't see the benefits. In XSLT, one does a test to
see if there is data in the source XML that would
constitute a fo:t
FOP 0.20.5 ignores an empty table-body, no error message.
XEP 4 displays a validation error and continues.
AltSoft Xml2PDF does the same.
FOP CVS HEAD now does the same.
The justifications for both changes are in the commit message. If you
prefer a hard exception in the case of an empty table-body
--- Glen Mazza <[EMAIL PROTECTED]> wrote:
>
> Jeremias,
>
> This should not be done. If someone has a problem
> with it--and I've never heard a complaint--they can
> send an email to xsl-editors, for them to adjust the
> content model for fo:table accordingly. (If they
> don't, they don't.)
>
Jeremias,
This should not be done. If someone has a problem
with it--and I've never heard a complaint--they can
send an email to xsl-editors, for them to adjust the
content model for fo:table accordingly. (If they
don't, they don't.)
Note that the editors are very reasonable about
this--for exa
I just took care of it--you may need to refresh PSLM
in the marker patch though as I did some minor changes
in that class as well.
BTW, I'd like to remove "String
getCurrentPageNumber();" from the LayoutManager
interface and replace it with "PageSequence
getCurrentPageSequence()". The latter offe
Glen,
no, that's ok. Thanks for the review. I've removed my change locally and
will commit either tomorrow or on Monday. I can't commit right now
because it overlaps with my changes for the marker problem where I still
hope for another comment.
On 05.02.2005 04:11:10 Glen Mazza wrote:
> Jeremias,
Jeremias,
We are using this pageCount statistic only at
endDocument() in ATH, i.e., when the document is
complete. Any problem with us just relying on the
rootFObj.getRunningPageNumberCounter() in
endDocument() instead of this page-by-page callback
(i.e., get rid of pageCount in ATH)? I would li
Jeremias Maerki wrote:
Can anyone tell why there was such a layout manager reuse in the first
place? I guess there was a reason.
I Should know because I wrote the first version, but I can't
remember the details. I guess it had something to do with the
overhead of constructing the LM. BTW page numbe
Can anyone tell why there was such a layout manager reuse in the first
place? I guess there was a reason.
On 26.01.2005 18:51:55 jeremias wrote:
> jeremias2005/01/26 09:51:55
>
> Modified:src/java/org/apache/fop/layoutmgr
> PageSequenceLayoutManager.java
> Log:
You're right. The check is not really needed. I simply assimilated that
part to the one in startPageSequence. So, there's no real reasoning here.
I'm aware of the validation scheme for the FO namespace but we're
talking about renderers which don't necessarily follow the same
structure as the FO tre
I don't think this is needed (unless I'm missing your reasoning here.)
The validation in the FO Tree would raise errors otherwise, at least one
page-sequence being required by the fo:root FO. The validation scheme
was designed so you don't need subsequent safety checks further downstream.
Gle
No problem. I stumbled upon it when I realized that I wasn't handling
space-before|after correctly in in-flow block-containers. I'll see if I
can do something about it.
On 17.01.2005 20:17:35 Glen Mazza wrote:
> Yes, I think that's my fault. I believe that was
> related to the space-before and spa
Yes, I think that's my fault. I believe that was
related to the space-before and space-after properties
which I was trying (unsuccessfully) to fix. This is a
very complex portion of the code.
Glen
--- [EMAIL PROTECTED] wrote:
> jeremias2005/01/17 10:59:50
>
> Modified:src/java/org/ap
I think I got it. As soon as I started working with start|end-indent
wherever possible everthing started clicking in place and got simpler.
Thanks again for your patience and for your helpful advice!
Jeremias Maerki
Funny! I just came to the same conclusion a few minutes ago. Simon's
last comment brought me to that.
Simon:
"I see no mention in section 5 of the spec that the trait value for
start-indent is different from the computed property value."
I then checked the BlockLayoutManager and realized that wha
[Simon]
There does not seem to be a need to add
the inherited value later; the property maker already has done so. See
IndentPropertyMaker.compute(PropertyList). It uses
propertyList.getInherited(baseMaker.propId).getNumeric()) to get the
inherited value. Earlier FOP developers understood this part
True, but for all times save the first, it ends up
being a cached-value "get". Repeated across all the
FO's, the ratio would appear to be about 90% get/10%
original make. I wanted to stress in the code that we
are not necessarily "making" a brand-new property
object each time it is applicable for
On Tue, Jan 11, 2005 at 12:07:53AM -, [EMAIL PROTECTED] wrote:
> gmazza 2005/01/10 16:07:53
>
> Modified:src/java/org/apache/fop/fo Constants.java
> FOPropertyMapping.java PropertySets.java
>src/java/org/apache/fop/fo/flow MultiCase.java
>
On Tue, Jan 11, 2005 at 09:25:50AM +0100, Jeremias Maerki wrote:
>
> On 10.01.2005 22:00:01 Simon Pepping wrote:
> > There does not seem to be a need to add
> > the inherited value later; the property maker already has done so. See
> > IndentPropertyMaker.compute(PropertyList). It uses
> > propert
On 10.01.2005 22:00:01 Simon Pepping wrote:
> Section 5.3.2 of the spec is really hard to understand. I combine it
> with 5.1.4 about Inheritance. Then my guess is this:
>
> A test file
>
> A test file
>
>
>
> The computed value of start-indent on the outer block is 'start-indent
> =
In the region body I am making a table. I want the table header(that
row) to be repeated on subsequent pages. How to do that?
-Original Message-
From: Glen Mazza [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 11, 2005 2:55 AM
To: fop-dev@xml.apache.org
Subject: Re: cvs commit: xml-fop
--- Glen Mazza <[EMAIL PROTECTED]> wrote:
> BTW, would Jeremias' proposal
> effect future
^^
oopsaffect ;)
Glen
BTW, would Jeremias' proposal effect future
implementation of the property value functions[1]?
Thanks,
Glen
[1]
http://www.w3.org/TR/2001/REC-xsl-20011015/slice5.html#section-N8624-Property-Value-Functions
--- Simon Pepping <[EMAIL PROTECTED]> wrote:
> Section 5.3.2 of the spec is really hard t
Section 5.3.2 of the spec is really hard to understand. I combine it
with 5.1.4 about Inheritance. Then my guess is this:
A test file
A test file
The computed value of start-indent on the outer block is 'start-indent
= inherited_value_of(start-indent) + margin-corresponding +
padding-c
On 07.01.2005 10:49:02 Finn Bock wrote:
> [Jeremias]
>
> > would you please check if it is acceptable to put the inherited values
> > directly into the CommonMarginBlock? It might have been cleaner to
> > always get the value via the parent FO but I think in this case it helps
> > simplifying the
[Jeremias]
would you please check if it is acceptable to put the inherited values
directly into the CommonMarginBlock? It might have been cleaner to
always get the value via the parent FO but I think in this case it helps
simplifying the code in TraitSetter and BlockLayoutManager.
It looks wrong, i
Finn or Simon,
would you please check if it is acceptable to put the inherited values
directly into the CommonMarginBlock? It might have been cleaner to
always get the value via the parent FO but I think in this case it helps
simplifying the code in TraitSetter and BlockLayoutManager.
On 07.01.20
--- Finn Bock <[EMAIL PROTECTED]> wrote:
>
>
> Using casts will prevent us from adding property
> proxies, which i
> suspect will be needed.
>
What's a "property proxy"? Can you
elaborate on that--give a simple scenario of it?
Thanks,
Glen
Sorry. Still learning. Thanks for paying attention. Fixed.
On 06.01.2005 13:33:08 Finn Bock wrote:
> [EMAIL PROTECTED] wrote:
>
> > Log:
> > convertValueForProperty didn't have the right signature and
> > therefore didn't override the superclass implementation.
>
> That was sloppy of me. T
[EMAIL PROTECTED] wrote:
Log:
convertValueForProperty didn't have the right signature and
therefore didn't override the superclass implementation.
That was sloppy of me. Thanks for finding and fixing it.
+ListProperty listProperty = (ListProperty)property;
That is a no-no. Propertie
On Mon, Jan 03, 2005 at 02:20:25PM +0100, Jeremias Maerki wrote:
> I'm trying to understand what's going on here. One thing that strikes me
> as odd is that PropertyList.convertAttributeToProperty() always
> contructs Properties based on the parentFO. Normally, this is probably
> ok since most calc
+1! Ausgezeichnet! Danke...
Glen
--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> Sorry, I'm so used to using A-F Enums that I didn't
> think about that.
> I've fixed this and hope that you can agree with my
> change now.
>
Sorry, I'm so used to using A-F Enums that I didn't think about that.
I've fixed this and hope that you can agree with my change now.
On 03.01.2005 14:51:00 Glen Mazza wrote:
> Jeremias,
>
> Would you please elaborate on the need for this? I
> want to make sure that adding an additional dependen
Jeremias,
Would you please elaborate on the need for this? I
want to make sure that adding an additional dependency
on the Avalon project is passing a cost-benefit
analysis here.
We're not a fluffy hi-level word processing system
--we are a very low-level application (like a
compiler), that is i
I'm trying to understand what's going on here. One thing that strikes me
as odd is that PropertyList.convertAttributeToProperty() always
contructs Properties based on the parentFO. Normally, this is probably
ok since most calculation bases are the parent FOs but in the case of
content-width/height
Simon Pepping wrote:
On Tue, Dec 28, 2004 at 06:03:13PM -, [EMAIL PROTECTED] wrote:
Index: LengthBase.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/datatypes/LengthBase.java,v
retrieving revision 1.8
retrievin
On Tue, Dec 28, 2004 at 06:03:13PM -, [EMAIL PROTECTED] wrote:
>
> Index: LengthBase.java
> ===
> RCS file:
> /home/cvs/xml-fop/src/java/org/apache/fop/datatypes/LengthBase.java,v
> retrieving revision 1.8
> retrievin
--- Simon Pepping <[EMAIL PROTECTED]> wrote:
>
> I have contained
> its effect by catching the exception, and have not
> explored the stack
> of methods that may need to declare the throwing of
> an exception. That
> is a problem in its own right, to be solved at
> another moment.
>
OK...sorry t
--- Simon Pepping <[EMAIL PROTECTED]> wrote:
> Glen,
>
> In my view the FO system knows nothing about the LM
> system.
It appears that you've just made a friend in Colorado.
;)
> That is
> how the LM system can be pluggable.
Not really, it can still be pluggable if you have
addLayoutManager
Glen,
On Mon, Dec 27, 2004 at 06:55:01AM -0800, Glen Mazza wrote:
> Simon,
>
> Why aren't these fatal errors--what's the gain in
> having FOP continue running in an invalid state?
>
> One-in-a-million bugs like these that occur for
> inexplicable reasons should raise an
> IllegalStateException a
Glen,
In my view the FO system knows nothing about the LM system. That is
how the LM system can be pluggable. The FO system sets itself up and
waits if any subsequent system finds it useful. Its only connection
with the subsequent system is that it sends FO events to its
FOEventHandler.
The LM sy
This doesn't seem appropriate--the business logic to
determine whether or not a layout manager is needed
for a particular FO should be within that FO object,
where it reads its own private variables--in whatever
manner it is internally constucted--and makes its own
determination.
Otherwise (1) you
Simon,
Why aren't these fatal errors--what's the gain in
having FOP continue running in an invalid state?
One-in-a-million bugs like these that occur for
inexplicable reasons should raise an
IllegalStateException and halt. FOP should not
continue running after catastrophic failures.
Glen
--- [
On Sat, Dec 25, 2004 at 01:08:11AM -, [EMAIL PROTECTED] wrote:
> gmazza 2004/12/24 17:08:11
>
> Modified:src/java/org/apache/fop/layoutmgr LayoutManagerMapping.java
>src/java/org/apache/fop/render/pdf PDFRenderer.java
> Log:
> More XSL 1.1-like terms for PDF book
Simon,
Will you please comment this method--the purpose of
checkLength is not obvious in meaning at least to me.
Thanks,
Glen
--- [EMAIL PROTECTED] wrote:
> public LayoutManager makeLayoutManager(FONode
> node, boolean checkLength) {
> List lms = new ArrayList();
> ma
--- [EMAIL PROTECTED] wrote:
> The property
> lists are not cloned.
For future clarity, it may be good to add this
"limitation" of FONode.clone() (and other ones you're
aware of) to its javadoc comment.
> +/**
> + * Perform a shallow cloning operation,
> + * set its parent,
Sounds good.
--- Luca Furini <[EMAIL PROTECTED]> wrote:
> Glen Mazza wrote:
>
> > Luca, I think we should be using getWidth()
> instead of
> > getW(), correct?
>
> Yes, it would be much clearer!
> I'm going to rename:
> getW() -> getWidth()
> getY() -> getStretch()
> getZ() -> getShrink()
Glen Mazza wrote:
> Luca, I think we should be using getWidth() instead of
> getW(), correct?
Yes, it would be much clearer!
I'm going to rename:
getW() -> getWidth()
getY() -> getStretch()
getZ() -> getShrink()
getP() -> getPenaltyValue()
The last name is quite long: I first thought of
Luca, I think we should be using getWidth() instead of
getW(), correct?
Thanks,
Glen
--- [EMAIL PROTECTED] wrote:
>
> +/**
> + * Return the width of this element.
> + */
>public int getW() {
>return width;
>}
>
Finn (or anyone else), given that FOText nodes (and possibly other
non-formatting object nodes in the future) also have properties, any
objections if we move FObj.bind() to FONode.bind()? That would
simplify the below code a bit.
Thanks,
Glen
[EMAIL PROTECTED] schrieb:
spepping2004/11/30
--- Finn Bock <[EMAIL PROTECTED]> wrote:
>
> > We've been doing the same with PR_ (properties)
> and
> > FO_ (FO's) for quite some time.
>
> To avoid a name conflict somewhere.
>
Yes, I was wondering why you didn't originally do that
for the enumeration constants as well. I like their
self-d
[Glen]
2.) Appended EN_ to enumeration constants to
[J.Pietschmann]
Yuk. Having a large number of identifiers in the
same scope with
an identical prefix isn't very good for
autocompletion both in
Emacs and Eclipse.
[Glen]
We've been doing the same with PR_ (properties) and
FO_ (FO's) for quite so
--- "J.Pietschmann" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > gmazza 2004/11/24 13:07:31
> > 2.) Appended EN_ to enumeration constants to
> make them better S&R'able throughout app.
>
> Yuk. Having a large number of identifiers in the
> same scope with
> an identical prefix
[EMAIL PROTECTED] wrote:
gmazza 2004/11/24 13:07:31
2.) Appended EN_ to enumeration constants to make them better S&R'able
throughout app.
Yuk. Having a large number of identifiers in the same scope with
an identical prefix isn't very good for autocompletion both in
Emacs and Eclipse. I als
> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
>
> 1.0's bookmarks are different from 0.20.5's, the former has
> fox:bookmarks as the "parent" element.
> It's been that way in 1.0 for a long time,
> before I came on board I believe.
>
Yes, and it even has been discussed
- Original Message -
From: "Andreas L. Delmelle" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, November 14, 2004 2:58 PM
Subject: RE: cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination
Root.java
> > -Original Message-
> >
> -Original Message-
> From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
Ignore this thread. Found the answer in the archives...
Sorry for the nuisance.
Greetz,
Andreas
> -Original Message-
> From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
>
> Hope the use of the bookmarks extension wasn't meant to be
> changed in HEAD.
Oops. Just noticed that a Bookmarks class has been added to the extensions
package...
What's going to be the prescribed usage patte
On Nov 9, 2004, at 11:58 AM, Simon Pepping wrote:
On Mon, Nov 08, 2004 at 01:43:51PM -0800, Clay Leeds wrote:
I suspect this could be a problem for the Forrest site-generation
process[1]:
Specifying menus with book.xml
Historically, menus in Forrest have been generated from a
book.xml file, o
On Mon, Nov 08, 2004 at 01:43:51PM -0800, Clay Leeds wrote:
> I suspect this could be a problem for the Forrest site-generation
> process[1]:
>
> Specifying menus with book.xml
>
> Historically, menus in Forrest have been generated from a
> book.xml file, one per directory. This mechanism
On Nov 8, 2004, at 12:48 PM, Simon Pepping wrote:
Clay,
On Sun, Nov 07, 2004 at 08:48:23PM -0800, Clay Leeds wrote:
Simon,
Does the book.xml file in your DnI section serve any specific purpose
(DnI-related), or is it to follow the common coding/forrest
convention?
I ask, because the use of book.xm
Clay,
On Sun, Nov 07, 2004 at 08:48:23PM -0800, Clay Leeds wrote:
> Simon,
>
> Does the book.xml file in your DnI section serve any specific purpose
> (DnI-related), or is it to follow the common coding/forrest convention?
> I ask, because the use of book.xml is deprecated in Forrest-0.6 in
>
Simon,
Does the book.xml file in your DnI section serve any specific purpose
(DnI-related), or is it to follow the common coding/forrest convention?
I ask, because the use of book.xml is deprecated in Forrest-0.6 in
favor of the site-wide src/documentation/content/xdocs/site.xml file.
On Nov 7,
On Nov 6, 2004, at 8:57 AM, [EMAIL PROTECTED] wrote:
clay2004/11/06 08:57:40
Modified:.forrest.properties
src/documentation sitemap.xmap skinconf.xml
src/documentation/content/xdocs compliance.xml
graphics.xml
resources.xm
That's exactly why we need a good regression test facility. I apologize
for not being more thorough. I'll probably have time on Thursday to look
into it if noone beats me to it.
I also thought about reusing the static areas but as soon as there are
things like the page number or another reference
Jeremias Maerki wrote:
> jeremias2004/10/10 04:21:29
>
> Modified:src/java/org/apache/fop/layoutmgr LineLayoutManager.java
> Log:
> This is supposed to fix a problem that surfaced with Finn's latest
> change in PageSequence. There was an ArrayIndexOutOfBoundsException here in
> LineL
On Oct 16, 2004, at 2:38 PM, Peter B. West wrote:
Clay Leeds wrote:
If anyone has any questions (or the command to diff all files in the
xdocs/ path after August 2), that would be great!
Clay,
In a working directory, try
cvs update
cvs diff -kk -D 2004-08-02 -u src/documentation/content/xdocs
Pete
Thanks Glen! I was planning to update the site to indicate Luca's
'promotion'.
Believe it or not, I'm actually about to update the xml-fop web site.
I've been waiting for Forrest 0.6 to be released so that the changes
won't get wiped away when we switch over to it. Unfortunately the
process wi
Sorry for the delay.
On 12.10.2004 01:20:54 Glen Mazza wrote:
> --- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
>
> > Glen,
> >
> > I don't
> > particularly like selecting renderers by integer
> > constant.
>
> FOP has been using integers for six years now, and as
> I explained earlier [1], MIM
Thanks.
--- [EMAIL PROTECTED] wrote:
> bckfnn 2004/10/12 23:53:33
>
> Modified:src/java/org/apache/fop/fo/flow
> Wrapper.java
> Log:
> Children can now contain FONodes (esp. FOText).
>
> Revision ChangesPath
> 1.15 +1 -1
> xml-fop/src/java/org/apache/fop/fo/f
--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
>
> On 11.10.2004 01:29:40 Glen Mazza wrote:
> > Jeremias: Why does the FOEventHandler need to
> know the MIME type
> > supported by a Renderer?
>
> The FOEventHandler doesn't need to know the MIME
> type. But maybe the a
> FOP integrator needs it.
--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> Glen,
>
> I don't
> particularly like selecting renderers by integer
> constant.
FOP has been using integers for six years now, and as
I explained earlier [1], MIME types don't make a very
good primary key for renderers, because not all
renderers
Glen,
I don't want a RendererFactory.setRendererOverride(). I don't
particularly like selecting renderers by integer constant. I like
pluggability. I'd prefer to register all our renderers in a central
registry. Integrators could plug in their renderers using the service
interface just as the FOP
On 11.10.2004 01:29:40 Glen Mazza wrote:
> Jeremias: Why does the FOEventHandler need to know the MIME type
> supported by a Renderer?
The FOEventHandler doesn't need to know the MIME type. But maybe the a
FOP integrator needs it.
> It hasn't been requesting it. The "primary
> key" of the Re
Jeremias,
The reason for getFOEventHandlerOverride()/getRendererOverride() in
FOUserAgent is to better black box the FOP system. This gives us a ton
of freedom internally of where we implement FOEventHandlers and
Renderers inside FOP. This has been a perfect example: So far over the
past few
Jeremias: Why does the FOEventHandler need to know the MIME type
supported by a Renderer? It hasn't been requesting it. The "primary
key" of the Renderer is its constants value in fo.Constants, and the
FOEventHandler has already chosen the renderer based on this value by
this time.
What add
Thanks, and sorry for the oversight.
Glen
--- [EMAIL PROTECTED] wrote:
>
> Log:
> Fix javadoc warnings.
>
[Jeremias Maerki]
Finn, it seems to me that you probably forgot the check in all your
changes. FOP doesn't compile ATM. The method makeBorder is missing.
Yes, I forgot. I'm sorry for the inconvenience.
Glen, Thank You for temporarily fixing my mistake.
regards,
finn
Finn, it seems to me that you probably forgot the check in all your
changes. FOP doesn't compile ATM. The method makeBorder is missing.
On 01.10.2004 11:46:36 bckfnn wrote:
> bckfnn 2004/10/01 02:46:36
>
> Modified:src/java/org/apache/fop/render/rtf
> TableAttri
Thanks!
Glen
--- [EMAIL PROTECTED] wrote:
> bckfnn 2004/09/24 03:31:22
>
> Modified:src/java/org/apache/fop/apps
> FOUserAgent.java
>src/java/org/apache/fop/fo
> FOTreeBuilder.java
> Log:
> Moved from element mapping class names to element
> mapping objects.
> T
I guess I'm the guilty one here--but I have the
tabbing option shut off in JEdit, I'll be more careful
(and test at home what is happening.)
Sorry/Thanks,
Glen
--- [EMAIL PROTECTED] wrote:
> jeremias2004/09/23 03:04:36
>
> Modified:src/java/org/apache/fop/area
> StorePagesModel.java
On Tue, Sep 21, 2004 at 09:28:10AM -, [EMAIL PROTECTED] wrote:
> cbowditch2004/09/21 02:28:10
>
> Modified:src/documentation/content/xdocs/design layout.xml
> Log:
> update todo list
>
> +
>Justified Text
>High
>This
Simon Pepping wrote:
On Sun, Sep 19, 2004 at 06:46:51PM -, [EMAIL PROTECTED] wrote:
gmazza 2004/09/19 11:46:51
Modified:src/java/org/apache/fop/area AreaTreeModel.java
StorePagesModel.java
src/java/org/apache/fop/fo CharIterator.java FOText.java
On Sun, Sep 19, 2004 at 06:46:51PM -, [EMAIL PROTECTED] wrote:
> gmazza 2004/09/19 11:46:51
>
> Modified:src/java/org/apache/fop/area AreaTreeModel.java
> StorePagesModel.java
>src/java/org/apache/fop/fo CharIterator.java FOText.java
>
--- Simon Pepping <[EMAIL PROTECTED]> wrote:
>
> PageLayoutManager has a seed for multithreading; it
> implements
> Runnable. The idea is to let each page sequence run
> in its own
> thread. It has not been worked out.
I'm uncertain of its benefit (that which calls FOP
should do the multithreadi
On Tue, Sep 07, 2004 at 08:47:07PM +0200, Jeremias Maerki wrote:
>
> Question to everyone: We currently don't have a multi-threaded design
> like Peter West's approach. Can anyone think of a reason that all the
> FO-building and layouting process for one processing run may run within
> more than o
1 - 100 of 204 matches
Mail list logo
