Jeremias Maerki schrieb:
Yes, Axis uses JCL just as I wanted. Concerning the discovery things,
they are using Commons Discovery [1]. I'm not sure myself what the
intent/benefit is behind it but I'm pretty sure we don't have to do the
same. For the moment, I think the current approach is quite sati
Chris Bowditch wrote:
One additional thing is to add a system property to each startup
configuration in your IDE where you need to configure logging. Working
with Eclipse I've added...
-Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog
We would need to add this to FOP.s
I use this tool (I couldn't find a patch program in WinCVS):
http://marc.theaimsgroup.com/?l=fop-dev&m=105874140111833&w=2
Two other notes to read:
http://marc.theaimsgroup.com/?l=fop-dev&m=106961785412734&w=2
http://marc.theaimsgroup.com/?l=fop-dev&m=106962776820285&w=2
to apply the patch, I use:
Yes, this needs more work then. I did not consider
fo:inlines when starting.
Still, I'm surprised that are within the
same FOText object (the fo:block is already parsed
into several FOText objects, roughly FOText object per
line in the source document)--the appearance of an
should precipitate
Thanks for looking through the code, Simon.
--- Simon Pepping <[EMAIL PROTECTED]> wrote:
>
> I have a remark on the logic of nextCharCalled. It
> is equal to
> curIndex - startIndex. Also, in remove() you should
> separately
> consider the case nextCharCalled == 0: it should not
> happen.
>
"ne
I'm not sure exactly what you mean--are you indicating
it might be best to pull out the interators from
FOText and flow.Inline and have everything done within
flow.Block? That could work well.
A further optimization might be to do all this before
the Block is even parsed into FOText and Inline
ob
Not to worry--this is just a switch from Avalon Logging to Commons
Logging within HEAD [1]. The conversion required 100's of changes, I
did the bulk grunt work, and then both Jeremias and Simon corrected the
implementation and did some specialty conversions that were outside my
knowledge. I h
I think it's just setLevel() that you're looking for:
http://jakarta.apache.org/commons/logging/api/org/apache/commons/logging/impl/SimpleLog.html
Glen
Peter B. West wrote:
Glen,
I see that you have the move to commons-logging. I was encouraged by
this because of the support for 1.4 logging,
looks like an oversight in the
definition of the 1.4 logger. I'll subscribe to the Commons lists and
check this.
Peter
Glen Mazza wrote:
I think it's just setLevel() that you're looking for:
http://jakarta.apache.org/commons/logging/api/org/apache/commons/logging/impl/SimpleLog
p out and start looking at the particular
implementation. I suppose it is still an advantage, in that *most* of
the code will still be able to log using common calls, but it is not
tidy.
Peter
Glen Mazza wrote:
There appears a getLogger() that will take you to the native
ja
I applied Clay's breadcrumbs.js patch directly in the
cvs xml-site/targets/fop/skin directory (where our
production site reads from). This overwrites the
buggy breadcrumbs.js that forrestbot keeps putting
there everytime we do a website publish.
I also put in a request to have the default (buggy)
Hello Joerg, welcome back.
J.Pietschmann wrote:
Glen Mazza wrote:
A further optimization might be to do all this before
the Block is even parsed into FOText and Inline
objects, as many spaces-only objects would end up not
even needing to be created.
This will not account for spaces to be
J.Pietschmann wrote:
Hmmm...not that big a deal to me, but I would be inclined to keep the
whitespace removal out of the LayoutManagers, because it is fo:block
specific
I don't quite understand this argument. Handling space-before is also
fo:block specific. Where should this logic be put, then?
[EMAIL PROTECTED]
John Austin wrote:
I'll be changing to a new e-mail address and am cancelling my
list subscriptions.
fop-user has instructions at the bottom of messages but
fop-dev doesn't.
I guess I'll have to read the web page.
J.Pietschmann wrote:
Mutable static data, like a static logger reference, interferes
severely with using FOP in an MT environment, because this means
"one thread rendering globally" rather than "one thread per FO
processor rendering, perhaps using multiple processors, each one
in a separate thread
J.Pietschmann wrote:
Static objects are bad because of the usual MT issues (yeah,
even for logging).
Should FOP itself multithread, or would it be better to let whatever
would call FOP do the multithreading? I don't know what Xalan does with
their translets, I suspect they just rely on the call
Jeremias Maerki wrote:
The first two frames are in static context. The LMs share a reference
to a user agent object, of type
layoutmgr.AbstractLayoutManager.userAgent. Would this be the right
object to hold a reference to the user configuration?
On first thought, yes. But I feel the scope of
Glen Mazza wrote:
I don't know what Xalan does with their translets, I suspect they just
rely on the caller to implement it.
Oops--my error--the translets just generate Java code. My comment was
in general for the need of XML processors such as Xalan and FOP to
implement MT internally.
Glen
I don't think so. For one, the 0.20.x branch is basically frozen. But
more fundamentally, we're moved away from Avalon in 1.0. Like Xalan,
Batik, AntennaHouse and RenderX, we're a base tool--we shouldn't be
sitting on frameworks which would then require other users of FOP to
import that fram
rnal a complete different resolving concept than cocoon. This could be solved very easy, i think.
Stefan
-----Original Message-
From: Glen Mazza [mailto:[EMAIL PROTECTED]
Sent: Friday, April 30, 2004 9:45 AM
To: [EMAIL PROTECTED]
Subject: Re: [Patch Proposal] Integrate FOP with
Cocoon/Excalibur
Yes, I think we agreed (when we were discussing the Avalon Logger to
Commons Logging switch) to stay with Avalon configuration unless and
until something better is found. If you find something different you'd
like to recommend, just let us know--now's the time!
Only concern I have about Avalon
Berin Lautenbach wrote:
Jeremias Maerki wrote:
Both Vincent and Thomas are practically unavailable
right now. How do we handle the Batik side for new PMC? Any idea,
Thomas,
when and if you can get back to the project?
If we cannot keep Batik going - then leave it in XML while we sort it
out.
I'
BTW, Andreas, sorry for not responding to your emails
on this thread, I'm juggling a bit much right now,
both FOP and non-FOP--thankfully Chris at least has
been able to comment on your work, and hopefully I
and/or a few others will be able to add something
later. Thanks for helping us out with th
Simon Pepping wrote:
Note in this respect the comment in
LayoutStrategy.java:
/** Useful only for allowing subclasses of AddLMVisitor to be set by those
extending FOP **/
right above
private AddLMVisitor addLMVisitor = null;
I think you should copy that comment to Document.java as well.
Perhaps these links may be of help:
>From the Java tutorials:
http://java.sun.com/docs/books/tutorial/2d/textandfonts/index.html
http://java.sun.com/developer/onlineTraining/Media/2DText/
(Warning: very old, from 1998)
Forums for questions:
http://forum.java.sun.com/forum.jsp?forum=20
Glen
--- Clay Leeds <[EMAIL PROTECTED]> wrote:
>
> However, I do understand the format itself pretty
> well, so if you can
> give me 'before' and after (or a diff would be fine,
> I can commit the
> necessary changes--committership has its
> privileges... don't worry, I
> won't touch JAVA code 'til I
(Far from being an expert on fonts, but commenting anyway... ;)
Peter B. West wrote:
I have read again the Wiki page on the font subsystem in the light of
my current work with Java fonts. I'm afraid that I am still convinced
that font handling is properly the preserve of the renderers. The
la
Peter B. West wrote:
Which is more sensible - writing a renderer's font handling to a
common renderer font interface as an integral part of the renderer
implementation, or discovering the fonts quirks of this particular
renderer and adding them separately to a central font handler/registry?
I
--- Simon Pepping <[EMAIL PROTECTED]> wrote:
Chris wrote:
>
> > Is anyone else on the team planning on making
> large commits over the next
> > couple of days? I would be grateful if you could
> hold off for a couple of
> > days whilst the problems with this large patch are
> resolved. I dont w
I'm unsure if this is related to your question, but I
think it would be nice for us to switch to Docbook.
Apparently at least one Apache project, Tapestry, is
already using it with Forrest [1][2].
We switched at work from RoboHelp HTML to Docbook and
it has been great for us.
Glen
[1] http://wi
For archival reasons, please ask these questions on
the FOP User list. The same developers are on both.
Glen
--- [EMAIL PROTECTED] wrote:
-
My application is deployed in a WAR format on Unix.
The XSLTInputHandler is trying to access the XSL and
the XML files on
Thanks for the link--I didn't know about this. Still,
switching to SVN would probably aggravate the problem,
by draining users and developers away from CVS--hence
slowing CVS' bug fixes and greater security
enhancements.
There's nothing magical about SVN--it is open source
too and subject to the
I think you *have* to use publish--(IIRC auto
refreshing will work only for what you *manually*
place in CVS xml-site CVS) Don't worry, go ahead and
press the "publish" button--the Forrestbot web
interface is a lot more robust than it looks!
After publishing, you will need to wait up to 6 hours
b
--- "Peter B. West" <[EMAIL PROTECTED]> wrote:
>
> Obviously, I would love to be able to output
> alt-design's layout to PDF
> without having to build a new interface mechanism.
>
I think you have that already in the render.Renderer
interface--which defines those methods that a Renderer
must be
--- "Peter B. West" <[EMAIL PROTECTED]> wrote:
> SVG Generator can be added to an environment in
> which Java 2D graphics
> are already being produced, using the same
> instructions which are used
> on a Graphics2D object. The SVGGraphics2D object is
> used instead, and
> the same graphical ope
Noted. My instinct would be for us to wait about 6-9
months after several other projects move over. If no
problems with them, or at least no major problems,
then I think it would be fine for us to switch
products if other committers would like.
However, this will still require someone SVN-loving
--- Clay Leeds <[EMAIL PROTECTED]> wrote:
>
> On Jun 11, 2004, at 1:02 PM, Glen Mazza wrote:
>
> > [BTW, you forgot to add Jeremy's birthyear to your
> > bio--no big deal, but you might be getting
> > congratulatory emails/demands for cigars every
> late
&
--- Simon Pepping <[EMAIL PROTECTED]> wrote:
> Subversion has strong migration utilities from CVS.
> I migrated some of
> my own projects without problems. Addmittedly they
> are small. By now
> the ASF must have collected much experience with
> such migrations.
>
I think it's just been a few pro
Done, thanks.
Glen
--- Simon Pepping <[EMAIL PROTECTED]> wrote:
>
> If I see correctly, FONode.name and
> PropertyList.elementName are now
> always null, and PropertyList.getElement() now
> always returns
> null. Can you fix that?
>
> Simon
>
Warmest Congratulations!!! (Can she program?!? ;)
Glen
--- "Peter B. West" <[EMAIL PROTECTED]> wrote:
> Fopfellows,
>
> I will be offline for the next week. I'm marrying
> Jenni tomorrow, and
> honeymooning in the frozen south of the South Island
> of New Zealand for
> a week. I'll post some
gt; On Wed, Jun 16, 2004 at 04:51:01PM -0700, Glen Mazza
> wrote:
> > Done, thanks.
>
> Thanks. I want to reinstate
> PropertyList.getElement() so that
> PropertyMaker can report which FO element it is
> working on via
> PropertyList; PropertyList.fobj is private. I wan
Clay,
Still too timid with the publish button? Go
ahead--don't worry about the breadcrumb problem right
now--it's OK if it doesn't work for a few days. More
important is to get you and Simon up on the committers
list.
However, after publishing, to fix the breadcrumb
problem:
c:\cvs checkout xm
ubbles up.
> When Batik's life
> energies come up to healthy levels again it shall be
> more strongly
> represented in the PMC as people come available.
>
> 3. I propose the following FOP people for the
> minimal initial PMC: Peter
> B. West, Jörg Pietschmann, Glen Mazza. I&#
Simon Pepping schrieb:
Glen,
On Sun, Jun 20, 2004 at 12:35:17PM -, [EMAIL PROTECTED] wrote:
gmazza 2004/06/20 05:35:17
src/java/org/apache/fop/render AbstractRenderer.java
Index: AbstractRenderer.java
===
R
ll enough to do any serious testing as
is required when you apply a patch. There's simply too much that can go
wrong. I'd have to find out how the whole testing infrastructure works
etc. etc. Too time-consuming. I'd rather we find ways to revive the
project from within the Batik communit
iggest part to get this working is to set up the
> resolution and charter,
> from then on I don't think there's a lot to do. The
> XML PMC list is not
> that active. Please reconsider.
>
> On 21.06.2004 00:52:04 Glen Mazza wrote:
> > I do know, however, that I don
--- Clay Leeds <[EMAIL PROTECTED]> wrote:
> The FOP web site Forrest update is nearing
> completion (finally!).
Great--much appreciated. The Embed page has new text
on it, so it would be nice when it gets updated.
> (speaking of which, do
> committers have any 'personal' space available on
>
--- Clay Leeds <[EMAIL PROTECTED]> wrote:
> BTW, I wouldn't mind changing the 'skin' for the web
> site to something
> more appealing ([2] comes to mind...).
+100, I like the modern white background. Axis also
uses that.The current blue color we use is
starting to look like the avocado gree
Great, this makes for an excellent system design
document that we can refine over time. I'm also happy
you have it done in Docbook. We're doing it right the
first time that way.
I'd like to see it incorporated, in Docbook format, on
our site. Tapestry has already managed Forrest and
Docbook tog
While you're at it, along with the skin change, you
may wish to switch our logo to the one at the top of
http://mirrors.xtria.com/apache/xml/fop/.
Glen
--- Glen Mazza <[EMAIL PROTECTED]> wrote:
> --- Clay Leeds <[EMAIL PROTECTED]> wrote:
> > BTW, I wouldn't mind ch
--- Simon Pepping <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 28, 2004 at 02:31:27PM -0700, Glen Mazza
> wrote:
> > Before doing so, it would probably be good if you
> > could look at our System design pages
> > (http://xml.apache.org/fop/design/index.html), if
> yo
FOP and Batik Committers,
*NEW Ballot* below. Please vote again. I've moved
the ending date to July 8th, and removed just one
clause involving tasking of migration/rationalization.
Glen
PART A
--
[ ] +1 - The attached resolution should be submitted
to the
Board for the formation
Team,
We allow--and have for many years--for input
processing of FO documents in the form of DOM trees.
Several months back I created an example [1] of a
"Hello World" FO document to show how this
functionality might be used.
The (well-written) classes which provide this
functionality, tools.Doc
published into PDF?
2) Is using DOM Trees an optimal way for you to do
your work, or is it just legacy code you don't wish to
disturb? (I.e., if you had to rewrite it from the
beginning, would you still use DOM Trees?)
Glen
--- Manuel Mall <[EMAIL PROTECTED]> wrote:
>
> From: &qu
the code
> setting up the final DOM tree. In future we would
> need
> to change the XSL and the code creating the XML
> from the data => Again no loss or gain.
>
> Manuel
> - Original Message -
> From: "Glen Mazza" <[EMAIL PROTECTED]>
>
>
--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
>
> Using
> a DOMSource and a SAXResult with an identity
> transformer.
>
Do we already have an example for this one? I'm not
sure of what you mean--are you saying that Manuel can
continue doing exactly what he's doing (slurping a FO
file into a DOM
--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
>
> > But FOP is not XML Commons, and IMO external users
> > should not be directly latching on to non-XSL
> portions
> > (i.e., not fonts or hyphenation, etc., things that
> we
> > are expected to share) of our code that way. That
> > would limit our
--- "J.Pietschmann" <[EMAIL PROTECTED]> wrote:
> Glen Mazza wrote:
> > driver.initialize();
>
>
> There is no initialize() method in the Driver class
> in FOP 0.20.5.
>
> J.Pietschmann
>
Thanks--that's good to know. I just made that meth
--- Simon Pepping <[EMAIL PROTECTED]> wrote:
> - From an app: add a configuration object to the
> FOUseragent object,
Why do you need to drag in the Avalon library for
this? For the classes in question, Avalon is just
providing a very thin wrapper--can't we do this
directly against the JDK?
Glen
--- Simon Pepping <[EMAIL PROTECTED]> wrote:
>
> Well, was, I hope. I have just committed code which
> enables using a
> user configuration file and adding fonts from it.
>
Thanks, Simon. Its good that we have people of your
skill on our team.
Glen
Team,
There are two possible API changes I am wondering if
we should make. I'm thinking about longer-term market
share of our 1.0 product, even if things get rocky for
us for a few months. Simon's changes are making the
HEAD code in FOP close to being useful, and so we may
have a narrowing windo
--- "Peter B. West" <[EMAIL PROTECTED]> wrote:
>
> FWIW, FAD merged Driver into Fop some time ago.
> From memory, the only
> issues were to do with the AWT renderer and its
> re-start capability
> (which I gather is not functioning anyway.)
>
Thanks for letting us know! I was unaware of that
Errr--I apologize--I forgot that we had already agreed
to use Avalon for configuration [1]. Sorry/Never
mind...
Glen
[1]
http://marc.theaimsgroup.com/?l=fop-dev&m=108337684719819&w=2
--- Glen Mazza <[EMAIL PROTECTED]> wrote:
> --- Simon Pepping <[EMAIL PROTECTED]> wrote:
--- "J.Pietschmann" <[EMAIL PROTECTED]> wrote:
> Glen Mazza wrote:
> > There are two possible API changes I am wondering
> if
> > we should make.
>
> Have another look at the API proposals in the old
> Wiki.
>
>
http://nagoya.apache.org/wiki/ap
-- "J.Pietschmann" <[EMAIL PROTECTED]> wrote:
> Glen Mazza wrote:
> > That should be enough for us in 1.0, no? Those
> more
> > elaborate API goals appear best discussed
> post-1.0,
> > presumably once more vital parts of the system
> have
> >
Team,
On my two earlier API proposals [1], I'm going to take
a step back on the first one about combining the
apps.Driver class into apps.Fop. Joerg's thoughts
that the API wrapper/class and application
wrapper/class should be distinct is weighing on my
mind; in the future we may find it benefici
Here is what I understand, others may have more to
add:
I see two ways to interpret your question: (1) what
happens in the code that makes page-sequence be the
lowest granularity we have, and (2) why we do it that
way.
1) When the page-sequence's children
(layout-master-set, declarations?, flo
Oops...my fault...sorry/thanks.
Glen
--- Peter Herweg <[EMAIL PROTECTED]> wrote:
> Hi,
>
> this issue is fixed.
> It was caused by the latest changes to
> StaticContent.java 7 days ago.
>
> Bye
> Peter Herweg
>
> > -Original Message-
> > From:
> [EMAIL PROTECTED]
> >
>
[mailto:[EMAIL P
Thanks Simon for your comments.
--- Simon Pepping <[EMAIL PROTECTED]> wrote:
> On Tue, Jul 13, 2004 at 12:16:22AM -,
> [EMAIL PROTECTED] wrote:
> > gmazza 2004/07/12 17:16:22
> > Log:
> > 1.) Combined the AreaTree and FOTreeHandler into
> a new AreaTreeHandler
> > object. FOTreeHan
(Resending apparently...)
Excellent--thanks--will do tonight. I didn't know the
reason for this method, and was unsure if it was just
legacy code. I'll also put a comment of how it speeds
things up.
Thanks,
Glen
--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> Glen,
>
> I'd like this change r
Thanks, Simon--I didn't think of this way of solving
the problem--I just modified Jeremias' previous DOM
example. However, I placed the method below
temporarily in the example and committed it before
returning to the Transformer version. This way, we
have a working example should we ever need to d
Sounds good.
--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> Because, IMO, it allows the user to use the same
> pattern for virtually
> everything:
> 1. Create a TransformerFactory
> 2. Create a Transformer and optionally use a
> stylesheet
> 3. Specify the Source (DOM, stream, file, SAX)
> 4
Good idea...this way those who prefer the
SAXParserFactory method can see how FOP would work
this way. (I tried to show both cases in one example,
but it just made a mess of things.) If you could take
care of this for us, it would be appreciated--else
I'll (probably) get to it eventually.
Glen
--- Simon Pepping <[EMAIL PROTECTED]> wrote:
>
> Introduce a constructor Driver(FOUserAgent
> foUserAgent)? It is good to
> enable our own CLI and embedding apps to first
> construct the user
> agent with all desired features and then create a
> driver with it.
>
> Regards, Simon
>
That might wo
Incidentally, is there any significant performance
difference between the two methods? I'm hoping "no",
i.e., we can use internally whichever proves more
convenient.
Glen
--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> Because, IMO, it allows the user to use the same
> pattern for virtually
> e
I agree; however we are none the worse off for Simon's
SAXParser example, and we even got a more powerful
DefaultHandler object in our API as a bonus.
Glen
--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> I simply think that the
> Transformer pattern is very
> universal and quite easy to use and
I renamed it yesterday.
Glen
--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> Just nitpicking, but could we call it
> ExampleFO2PDF-SAXParser instead of
> just "SAX", because the transformer solution relies
> on SAX, too? I don't
> have a problem with long names. :-)
>
> On 16.07.2004 21:14:18 S
An unfortunate decision.
Glen
--- "Peter B. West" <[EMAIL PROTECTED]> 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
>
--- "Peter B. West" <[EMAIL PROTECTED]> 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
Yes, the way I see it, one of FOP's successes will be
our close adherence to JAXP. Another one will be a
very strict and solid FO validation component--a "firm
handshake" that hopefully will paint FOP as a
Tomcat-like reference implementation for XSL.
BTW, Simon, and everyone else, there's about
No, but I just subscribe to the digest version of
fop-cvs.
Glen
--- "Peter B. West" <[EMAIL PROTECTED]> wrote:
> Is anyone else getting double cvs commit messages?
> I assume I am
> subscribed under more than one address, but my guess
> at what the
> redundant address might be has proved fruit
Simon, a word of caution*, I believe that anything
that goes into the Apache repository will need to be
copyright The Apache Software Foundation and only The
Apache Software Foundation. (Just look at the bottom
of any of the FOP site's web pages.) Else, best not
to commit it--we can always add a
Oh please do...
--- Simon Pepping <[EMAIL PROTECTED]> wrote:
> After that I
> want to work on the layout.
>
> Regards, Simon
>
Thanks for the elaboration--also the links to the pull
parsing sites.
Glen
--- "Peter B. West" <[EMAIL PROTECTED]> 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
apache/fop/render/rtf/ListAttributesConverter.java?annotate=1.7
--- Christian Geisert <[EMAIL PROTECTED]>
wrote:
> Glen Mazza wrote:
> > Simon, a word of caution*, I believe that anything
> > that goes into the Apache repository will need to
> be
> > copyright The Apache Software
y
> have the Apache
> License 2 text.
>
> Regards, Simon
>
> On Mon, Jul 26, 2004 at 04:16:18AM -0700, Glen Mazza
> wrote:
> > I believe the key word below is "transferable",
> i.e.,
> > before checking any work in, it still needs to be
> > co
Team,
While I'm implementing the validateChildNode()
methods, I would also like to work on removing the
AddLMVisitor visitor pattern[1], and revert to our
previous method of having the FO's themselves setup
the LayoutManagers via addLayoutManager(). (See here
[2][3][4] for examples of the previou
Well, the number of patches and enhancements made to
layout/rendering has only been about 2-3 per month in
the 12 months that we've had AddLMVisitor. FOP won't
finish at that rate, and that *will* affect the users.
In the 24 months preceding that change (i.e., the
original design I'm recommending
--- Chris Bowditch <[EMAIL PROTECTED]> wrote:
> Its the
> getNextBreakPoss/addAreas methods in TextLM and
> LineLM that are scarey.
>
Yes, that code is very complex (I wasn't able to fix a
problem with the space-after property despite much
effort), and I'm not sure there's anything that can be
d
I'll take care of it by this weekend, if not much
sooner.
Glen
--- "J.Pietschmann" <[EMAIL PROTECTED]> wrote:
> J.Pietschmann wrote:
> > I wonder why HEAD isn't affected?
>
> Darn, HEAD got it too :-/
>
> J.Pietschmann
>
Team,
Just updated the two libraries & source code on
maintenance and HEAD. (Only took 45 minutes...not
bad!)
Just for reference, the process involves (for both
HEAD and maintenance):
1.) CVS download of the latest Batik, compilation of
it into a single jar (use batik's "ant all-jar"
command to
--- Clay Leeds <[EMAIL PROTECTED]> wrote:
> FYI, I just made this post on the forrest mailing
> list[1]. It details
> that I made had a BUILD SUCCESSFUL with a /forrest/
> run on xml-fop/.
> :-D
>
Great! You've had it tough for the past few months
here. Before you came on board it used to be
again to understand my
concerns here.
BTW, thanks again for dropping the HEAD code base from
900 to 600 classes and getting rid of all that
autogenerated code. You have definitely made FOP more
accessible to the "programming masses"!
Regards,
Glen
--- Finn Bock <[EMAIL PROTECTED]>
--- Finn Bock <[EMAIL PROTECTED]> wrote:
> Glen Mazza wrote:
>
> > I still prefer my solution.
>
> Ok, but please consider that it will then become
> somewhat more difficult
> to add an alternative layout subsystem.
>
Layout subsystems are much rarer than
ctor, but
it should stop there--there shouldn't be
layout/formatting code within the FO.
Glen
[1]
http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/fo/flow/PageNumberCitation.java?r1=1.12&r2=1.8&diff_format=h
--- Glen Mazza <[EMAIL PROTECTED]> wrote:
> --- Finn
--- Finn Bock <[EMAIL PROTECTED]> wrote:
>
> My alternative layout subsystem isn't an alternative
> to FOP but an
> alternative way of implementing the
> getNextBreakPoss() code.
>
> I do not yet know if anything will come of it but it
> looks quite
> promising. If it works, I'll post it as a p
There are already other AFP Renderers for FOP
0.20.5--actually Hansuli has it in our resources page:
http://xml.apache.org/fop/resources.html
And--amazing what Google searches turn up--Keiron also
created one for FOP apparently:
http://www.aftexsw.com/personal/resume.html
But if you wish to don
My primary goal is not to "get this committed." But
if you have code you wish to donate to the ASF, just
do so via Bugzilla. It doesn't matter which
format--it is the logic in the code that is being
sought. No guarantees, however, as to it ever getting
committed into FOP, because we don't have s
--- Chris Bowditch <[EMAIL PROTECTED]> wrote:
> Glen Mazza wrote:
>
> > also the issue of the damage done to the FOP's
> > reputation as a whole should it ship with
> renderers
> > that operate only partially or incorrectly.
>
> Well, FOP already
I think Simon meant 1.4.2 (*not* 1.4), which is more
correct, I believe. I think he had even shown earlier
that the ones we distribute with FOP won't work with
FOP, while the ones already distributed with the SDK
1.4.2 will.
Glen
--- "J.Pietschmann" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED
101 - 200 of 664 matches
Mail list logo
