Thanks, Thomas--I'll get to this tonight or tomorrow
night.
Glen
--- Thomas DeWeese <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I've attached a patch to the PDF transcoder
> which changes the
> UserAgent to always report a pixel to millimeter
> conversion
> corresponding to 72dpi. This is requ
Good idea, updated, thanks.
--- "J.Pietschmann" <[EMAIL PROTECTED]> wrote:
> I know, useing getBorderAndPaddingWidthBefore is
> longer, but
> the term "margin" seems to be already taken.
>
> J.Pietschmann
>
__
Do you Yahoo!?
Exclusive Video Premiere - Britney Sp
Victor,
We're much more in agreement than I thought--I'll
respond more a little bit later this weekend. (Brain
dead right now.) In particular, I like your multiple
JAR idea--that's what Batik does quite well (you may
want to see their build.xml).
In the meantime, if you could get Peter's patch o
--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
>
> This is no unsolvable problem. We just have to find
> the best way which
> may also lie in between opinions. One way may just
> be not to do anything
> at all right now or another to let Glen put his
> no-nonsense proposal to
> action until there
--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> Glen,
>
> first of all, thanks for your continuing effort in
> the development
> towards 1.0.
>
Sure thing--two patches down, 21,234,198 to go! ;)
>
> Take the two Transcoders (for PDF and PS) for
> example. They could just
> as well be in Bati
Team,
Two changes I would like to make to the 1.0dev branch:
1.) Rename the org.apache.fop.area.inline.Word class
to org.apache.fop.area.inline.Text, and rename the
renderWord() method in the Renderer subclasses to
renderText().
Reason: It's a lot clearer, given the data these
objects hold and
--- Thomas DeWeese <[EMAIL PROTECTED]> wrote:
>
> At least one of the issues is with the
> PDFGraphics2D.
> in PDFGraphics2D.java:632 in draw(shape s). There
> is
> a check for a newTransform which inexplicably
> decides that
> if the new transform is the Identity transform there
> is
> no cha
Good--I was concerned that this was just me having the
problem.
Glen
--- "J.Pietschmann" <[EMAIL PROTECTED]> wrote:
> Glen Mazza wrote:
> > I'll leave the 0.20.x branch alone until others
> > complain about this problem, however.
>
> There is no probl
--- "Andreas L. Delmelle" <[EMAIL PROTECTED]>
wrote:
>
> Thomas,
>
> Can you perhaps have a look at bug 23883? In
> embedded SVG, something's going
> wrong with translate() when large numbers are used.
> Apparently this works
> fine for svg:text elements, but a polyline gets
> drawn really ugly...
Thanks, Tom, for your quick assistance. I didn't know
about the AWT threading issue you brought up.
I went ahead and added explicit System.exit() commands
to Fop.java in 1.0. I was somewhat reluctant about
this though because others haven't been complaining
about this problem, and for some rea
Thanks, Tom, for your quick assistance. I didn't know
about the AWT threading issue you brought up.
I went ahead and added explicit System.exit() commands
to Fop.java in 1.0. I was somewhat reluctant about
this though because others haven't been complaining
about this problem, and for some rea
Team,
Using the elements within an
fo:instream-foreign-object is causing my work computer
to having hanging threads (everything works fine at my
home computer though). I'm concerned others may be
getting this hanging thread problem on their machines.
Results of the below FO (work computer):
0.
We may be able to add a working "setParameter()" to
the new XSLTInputHandler--which could then be used
internally for command line parameter parsing--but I
hate strengthening that wrapper because embedded users
might use it, hence running away from JAXP, something
I would much rather they become pr
At least with my work computer--thanks, Victor, for
applying Peter Herweg's patch so quickly.
Glen
--- Glen Mazza <[EMAIL PROTECTED]> wrote:
__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
Team,
I got a new computer at home two days back--OS still
won't work with it, however. Also, the hard drive on
my computer at work died yesterday afternoon, so I'm
0-2 with computers right now. Will hopefully get back
on track with the bugs this evening.
Victor, would you be able to take care
Jay,
Again, please send your questions to the FOP-USER (and
Batik-user) list--even if you sense a bug, breaking
the DEV list's purpose does not help matters.
Raise issues on FOP-USER--the developers are all on
that list as well--and if a bug is found in FOP (most
of the time, however, it has tu
Cool/Thanks.
--- Victor Mote <[EMAIL PROTECTED]> wrote:
> I just committed a change that fixes this.
__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
--- Victor Mote <[EMAIL PROTECTED]> wrote:
> > FO:Basic-link isn't working (anymore?) in trunk
> for
> > PDF. It is properly colored blue, but the link is
> not
> > active/clickable.
.
>
> The "anymore" is the key question. I don't know
> whether it worked before or
> not.
>
> If it is
I think one of Tom's concerns is keeping the
transcoder stuff modular enough so that it potentially
can be moved to the Batik team. But as you're
mentioning, separating the font information is not
that big a deal and can be postponed until the font
handling designs are finished in trunk.
If you
--- Clay Leeds <[EMAIL PROTECTED]> wrote:
> It would be great if there were a flag/arg that
> could be added to the
> COMMAND LINE to enable some type of identification
> to be appended (like
> the date/time stamp like '200310061500' might be
> good--or since it's a
> flag/arg, append the filena
--- Eric Galluzzo <[EMAIL PROTECTED]> wrote:
>
> The name of a printer job can be set via the
> java.awt.print.PrinterJob.setJobName( String )
> method. This would need
> to be done within whatever class creates the printer
> job and prints it.
>
> Hmmm, this is probably a really unhelpfu
--- Clay Leeds <[EMAIL PROTECTED]> wrote:
> Is there any way to control the document name when
> printing from the
> command line (fop-0.20.5, java 1.4.1_01-b01 running
> under Windows XP
> Pro).
I'm unsure what you mean--are you referring to the
-print render type? I don't think so here...
G
--- Victor Mote <[EMAIL PROTECTED]> wrote:
> I don't know. I recommend going back to a version of
> the code before the
> AddLMVisitor was checked in, and seeing 1) whether
> it worked properly then,
> and 2) what it was doing, and comparing that to what
> is happening now. The
Good idea--I'll do
--- "J.Pietschmann" <[EMAIL PROTECTED]> wrote:
> >
> > lm = new InlineStackingLayoutManager() {
> > protected InlineParent createArea(BasicLink
> node)
> > {
> > InlineParent area = super.createArea();
> > setupBasicLinkArea(node, parentLM, area);
> > return area;
> >
Victor,
FO:Basic-link isn't working (anymore?) in trunk for
PDF. It is properly colored blue, but the link is not
active/clickable.
Per your email here:
http://marc.theaimsgroup.com/?l=fop-dev&m=106125821432538&w=2
fo:basic-link may have been broken with the addition
of AddLMVisitor:
http://cv
--- Victor Mote <[EMAIL PROTECTED]> wrote:
> Glen Mazza wrote:
> > -
> > +
>
> Glenn:
>
> Thanks for working on this. I also see that the ugly
> formatting problems
> have been fixed (presumably by the Forrest team, as
> I see no
Thanks--I should have suspected something simple like
that, before questioning his stylesheet on that issue.
Glen
--- "J.Pietschmann" <[EMAIL PROTECTED]> wrote:
> glenmazza wrote:
> > But, I ran your xml & xsl through Xalan--one thing
> I noticed in the FO output
> > are lots of nonsensical  (A
his problem?
>
> Thanks.
>
> Jay
>
>
>
>
> Get your own "800" number
> Voicemail, fax, email, and a lot more
> http://www.ureach.com/reg/tag
>
>
> On Sat, 13 Sep 2003, Glen Mazza
> ([EMAIL
tension elements--then you may
need to start directing some questions to the Batik
user list to find out what the problem is.
Thanks,
Glen
--- Glen Mazza <[EMAIL PROTECTED]> wrote:
> I think I got the same result you did. I'll look
> into
> the problem.
>
>
>
> Get your own "800" number
> Voicemail, fax, email, and a lot more
> http://www.ureach.com/reg/tag
>
>
> On Sat, 20 Sep 2003, Glen Mazza
> ([EMAIL PROTECTED]) wrote:
>
> > Jay,
> >
>
>
> Get your own "800" number
> Voicemail, fax, email, and a lot more
> http://www.ureach.com/reg/tag
>
>
> On Sat, 13 Sep 2003, Glen Mazza
> ([EMAIL PROTECTED]) wrote:
>
> > Jay,
> >
> > I adde
If he's using the transcoder, he has no other choice
(fortunately)--that's the only place where they are
supported.
Glen
--- "J.Pietschmann" <[EMAIL PROTECTED]> wrote:
> Andreas L. Delmelle wrote:
> > I've just been running the same test (
> examples/fo/advanced/giro.fo ) and
> > received the sam
--- Victor Mote <[EMAIL PROTECTED]> wrote:
> You are the
> first person that I know of using trunk code for
> real work, so that is an
> encouragement.
Don't forget the transcoders (only provided via trunk)
and RTF as well. Trunk is certainly getting use!
Glen
--- "Andreas L. Delmelle" <[EMAIL PROTECTED]>
wrote:
> I'm just being curious: did my remarks turn out to
> be helpful here? (I just
> want to check to what extent I'm beginning to
> understand the internals of
> the application...)
>
I was happy to see you going through the source code.
Also we
Done--it required only a simple change in
AbstractRenderer.java.
--- "J.Pietschmann" <[EMAIL PROTECTED]> wrote:
> I'd suggest to restore the behaviour of the
> maintenance code
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http:
--- Thomas DeWeese <[EMAIL PROTECTED]> wrote:
>You say you 'fixed it', you should not
> have moved the result stuff into the if.
>
No, I did not--it was *reformatted* correctly I meant!
Glen
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site des
Jay,
I added in a new Batik extension element mapping in
our main trunk code--this should help you. It is not
perfect--I noticed a hyphenation warning during
running your sample fo document; also I ran one of the
samples in the Batik directory (I embedded gears.svg
into an FO document)--it *appea
Victor,
Sometime tomorrow--I just added Andreas' name to our
teampage (he OK'ed it) so it will take awhile to get
to the Forrestbot stage area--please republish the
website. Thanks.
Thanks,
Glen
--- Victor Mote <[EMAIL PROTECTED]> wrote:
> Jeff Turner wrote:
>
> > The attached patch will get F
Patch applied! But please be careful to keep all
if-statements within braces--for the second patch, the
change at line 500 made the code look somewhat vague
as to your intentions (see below--I fixed it though).
(...previous { somewhere...)
if (alpha != 255)
hasMask = true;
result[count++]
--- Bertrand Delacretaz <[EMAIL PROTECTED]>
wrote:
> Sorry if I didn't explain my objectives clearly
> enough, but everyone
> has the right to ask for clarification - and, if you
> allow me some old
> man advice, it is usually good to do when you think
> something is wrong,
> before getting the
Don't bother--issue is not that important. I guess
our general goal is to do what maintenance does for
overlapping regions (which the spec doesn't address
anyway but maintenance seems to handle nicely)--I may
take a look at it later.
Glen
--- Victor Mote <[EMAIL PROTECTED]> wrote:
> J.Pietschman
Hello Victor,
Do you have time over the next few days to look at
Peter's patches (and apply them as appropriate)? Some
of this proposed code is affecting your turf
(FOTreeBuilder), etc., the rest is primarily just the
RTF handler--all changes are thankfully just for
trunk. Take a good look at th
gt; bug). It seems that in general PDFGraphics2D is a
> little
> shaky in how it treats color vs paint. This patch
> just
> tries to make sure that everywhere it sets color it
> also
> sets paint. This part probably needs more work but
> might
> warrent an entry in Bugzil
Also, Bertrand, for votes, you'll have to make
yourself active again--edit team.xml--and hopefully
for more than just submitting the names of people who
have been supplying patches for all of 24 hours. I'm,
however, not very optimistic on that point.
Committership is a months-long-process, and I'
-1; he can supply patches and we'll apply them.
--- Bertrand Delacretaz <[EMAIL PROTECTED]>
wrote:
> Hi FOPpers,
>
> I'm making this a proposal instead of directly a
> vote, as there are two
> unusual things here: I've been recently (and
> rightly) moved to inactive
> committer status, and it h
Question,
When I have overlapping regions (e.g.,
fo:region-start/after/before/end are defined but no
margins are provided within fo:region-body to
accomodate their extents--see example below), the spec
doesn't appear to indicate which region should "win".
What it does say (6.4.13) at least is th
No problem--Thanks for the very quick response.
Glen
--- Victor Mote <[EMAIL PROTECTED]> wrote:
>
> All of the global imports are now gone. Again, I
> apologize for the
> inconvenience.
>
> Victor Mote
>
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-u
--- Thomas DeWeese <[EMAIL PROTECTED]> wrote:
> > 1.) We do not have plans anytime soon for making a
> new
> > release of maintenance--so, if I made the change,
> the
> > new pdftranscoder.jar could be based only on a
> nightly
> > build--is that OK with you?
>
>I think that would be fine.
>
May be a good idea. Xalan has something similar (it's
the only other class in the package that has its main
Process class, I believe.)
Glen
--- Clay Leeds <[EMAIL PROTECTED]> wrote:
> Would it be possible and/or would it make sense to
> output the following
> information at the top of the ERROR
Thomas,
Two concerns on making this change in our production
version:
1.) We do not have plans anytime soon for making a new
release of maintenance--so, if I made the change, the
new pdftranscoder.jar could be based only on a nightly
build--is that OK with you?
2.) I checked out xml-batik and r
ail in Gump as well.)
Glen
--- "J.Pietschmann" <[EMAIL PROTECTED]> wrote:
> Glen Mazza wrote:
> > next few days to fix the transcoders--on 0.20.x
> > production
>
> Skip this, it's not worth. We should finally
> concentrate
> on HEAD.
>
>
Jay,
Please type this up in Bugzilla so we don't forget it.
(http://xml.apache.org/fop/bugs.html)--Also include
this sample as an attachment to the bug. No time
guarantees can be given, however.
In the meantime, Thomas, I don't think I can just
switch our SVGElementMapping implementation from
SV
--- Thomas DeWeese <[EMAIL PROTECTED]> wrote:
>
> Thanks, there isn't a huge rush but I wanted to
> make
> sure this wasn't a really bad time for you.
>
It's always a bad time! ;)
1.) Please go ahead and commit the code on your side
right now--Gump will complain for the next couple of
day
Victor,
Your IDE tool created another ".*" invalid import at
http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/fo/extensions/svg/SVGElementMapping.java?rev=1.1&content-type=text/vnd.viewcvs-markup.
Please fix it up--the Batik team is requesting
changes to this file.
When I have m
Thomas,
Sorry for the delay in response--failing a answer from
the other FOP committers--I'll look into the issue
this weekend.
In the meantime, as you say, the pdf transcoder needs
updating--can you send us the patch where Batik
changed (or the ViewCVS link if it was already done),
also to anoth
Understood--I moved you three to our inactive list on
the team page--you're always committers, though, feel
free to move yourselves back to active when you're
ready to return.
Thanks!
Glen
--- Arved Sandstrom <[EMAIL PROTECTED]> wrote:
> > -Original Message-
> > From: Bertrand Delacretaz
Victor,
I'm inclined to keep 0.20.x out of 1.0. There's too
much a risk that merging the two apps into one is
going to create a bunch of mush. I don't have any
problem with maintaining both a development and a
release version--that's just about how every other
Apache team operates.
Having stu
Welcome back--You may wish to let Berin know about
your email troubles--he tried multiple times to
contact you:
http://marc.theaimsgroup.com/?l=xml-apache-general&m=106172165515361&w=2
Glen
--- "Peter B. West" <[EMAIL PROTECTED]> wrote:
> Mail troubles. Just testing.
>
> Peter
>
_
--- Victor Mote <[EMAIL PROTECTED]> wrote:
>
> If I'm going to give up encapsulation or Separation
> of Concerns, or whatever
> you want to call it, what do I get in return?
>
IMO you're not "giving up" SoC, you're gaining it:
The
"manager<-->A<-->B<-->C<-->D<-->customer model"
keeps the busin
--- Victor Mote <[EMAIL PROTECTED]> wrote:
> >
> > Relations in controller-class approach:
> > manager<-->A, manager<-->B, manager<-->C,
> > manager<-->D,
> > manager<-->customer
> >
> > In pipeline approach (theoretical, may not work in
> > FOP's case):
> > manager<-->A<-->B<-->C<-->D<-->customer
--- Victor Mote <[EMAIL PROTECTED]> wrote:
>
> Conclusion: We have three active committers right
> now, one positive, one
> negative, one lukewarm, so I will abandon the
> enforcement idea.
>
> Victor Mote
>
I don't see anyone modifying the new Apps/FO code
anyway--for backwards compatibility,
--- Victor Mote <[EMAIL PROTECTED]> wrote:
> Before starting down this path, I tried pretty hard
> to think of a use case
> where it is beneficial *not* to have the FO Tree
> isolated, and could not
> think of one.
Well, when taken to 100%, the duplication of classes
(FOPException) and functional
--- Victor Mote <[EMAIL PROTECTED]> wrote:
> So I propose first that
> keeping these five modules separate is a desirable
> thing, and should be
> enforced by our build process (I'll write the code).
>
> Here is my +1.
>
I'm -1. The decision for changing FOP architecture is
based on votes--not
No big deal--just fixed it.
--- "J.Pietschmann" <[EMAIL PROTECTED]> wrote:
> Glen Mazza wrote:
> > fully qualify the import statements
>
> Eclipse's "organize imports" sorts this out quickly.
> I'm sure other IDEs have similar features.
>
On another issue, Victor, *please* don't forget to
fully qualify the import statements -- that's one of
our coding conventions and very helpful in grokking
code -- a "import org.apache.fop.apps.*;" was added
last week in the PDFRenderer.java:
http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/
--- Victor Mote <[EMAIL PROTECTED]> wrote:
> > So, are we back to square one with the pluggable
> > ElementMappers idea? Should we rip out that
> > functionality from FOTreeBuilder that allows FOP
> to
> > dynamically load brand-new ElementMappings? I
> still
> > don't see its utility.
>
> IMO,
--- "J.Pietschmann" <[EMAIL PROTECTED]> wrote:
>
> Both collapsed and separated borders are supported,
> the latter
> actually better because collapsing depends on
> neighboring cells,
> which changes at breaks. Extreme settings may even
> cause
> layout oscillations.
>
I updated the compliance.
Going back home to beautiful Buffalo/Niagara Falls,
NY--I'll be back next Tuesday!
Glen
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
We have currently about four sets of
ElementMappings--fo, svg, extension, and MathML in
examples.
I'm confused about seeing Bookmarks referenced in
FOTreeControl.java--I thought our pluggable
ElementMappings (including the Bookmark formatting
object) were designed to run with zero internal
hardc
--- "J.Pietschmann" <[EMAIL PROTECTED]> wrote:
> Dead wrong, properties are inherited properly, if
> you
> ask the property list manager you'll get correct
> values.
Technically speaking, if properties were *inherited*
properly, setting border-width on fo:table-row would
propagate to a child fo:ta
Great!
--- Victor Mote <[EMAIL PROTECTED]> wrote:
> Glen Mazza wrote:
>
> > But if you don't mind taking care of this with
> > JBuilder's refactor task, please do--you're anyway
> > more familiar with Document in case something
>
--- Victor Mote <[EMAIL PROTECTED]> wrote:
>
> Actually my
> JBuilder has a nice refactor task that does this for
> almost free, so, unless
> you have something similar at hand, perhaps I should
> do that.
>
> Victor Mote
>
I use JEdit which has a pretty good global S&R
feature.
But if you don't
--- "J.Pietschmann" <[EMAIL PROTECTED]> wrote:
> Dead wrong, properties are inherited properly, if
> you
> ask the property list manager you'll get correct
> values.
> Have a look at the code: the problem is how border
> definitions at different levels interfere.
> Suppose your table has a top-bord
--- Victor Mote <[EMAIL PROTECTED]> wrote:
> IMO, changes to properties would seem to
> be low priority, since it works. However, a
> reasonable case can be made that cleaning it up
> simplifies layout, which is very,
> very important.
> At the very
> least, please tell us
> what your plans are
--- Victor Mote <[EMAIL PROTECTED]> wrote:
> I mention this because I know that Glen is
> trying to get apps
> cleaned up. I think creation of "control" should
> help.
>
>From my perspective, apps is pretty well cleaned up
now. (I'll try my luck at the properties and the
AWTRenderer next.)
Do
> Unfortunately,
> progress on the main code
> branch is very slow, due to the absence of the main
> developers.
>
Joerg, let's not divide ourselves into "main
developers" and "minor developers". Perhaps "absence
of many of the committers" would be a better way to
phrase it.
Glen
___
oops--sorry--thanks.
--- Victor Mote <[EMAIL PROTECTED]> wrote:
>
> The problem was in apps/Fop itself. I committed a
> fix just seconds ago.
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
-
Yeah, I had a problem building the checkout last
night--good to know its fixed.
--- Victor Mote <[EMAIL PROTECTED]> wrote:
> It looks like one of the changes I made about 24-30
> hours ago actually broke
> the build. I just committed a fix.
__
Do you Yahoo!?
Yahoo
No--I haven't touched RTF renderer yet, most of my
changes are AWTRenderer and pre-Driver-related.
However, I believe most of the non-pdf renderers in
1.0 return NPE's anyway, as they're primarily empty
skeletons. (AWTRenderer did that until a week or so
ago--I was able to fix that one.) Was RTF
I created a ExampleDOM2PDF class for general testing
and demonstration of FOP's DOM Document handling
abilities. It's in the same
examples/embedded/java/embedded directory as the other
embedded examples.
Going against 1.0, the code appears to work fine, so
Victor's recent Document-handling change
Great--hope things work out well with your new team!
Don't worry, while you're gone we'll steal liberally
from your ALT-DESIGN! ;)
Glen
--- "Peter B. West" <[EMAIL PROTECTED]> wrote:
> Fopdevs,
>
> Sorry about the long silence, but my situation has
> undergone some
> dramatic changes. I hav
Actually, I'm starting to like InputHandler and am
just cleaning it up for 1.0, new API or no new API.
The only thing else I would like to get rid of in apps
are the Starter classes, if possible, which are
internal anyway. Driver I might have a few minor
simplifications to, but I'm not (current
Victor--
After looking over the new design, I like it. Please
keep your FOInputHandler abstract base class as-named.
FOTreeHandler also is a very good name.
I'd like to keep, however, at least for the time
being, the naming convention in fop.apps with
InputHandler as well. It's the command lin
Team,
I'm looking at the "force" parameter-- Sean's recent
patch for the Ant Task. This parameter, when set to
"false", will stop xslfo files from being processed if
there hasn't been a timestamp change on the xslfo file
compared to the output file. force="true" means always
generate.
A default
--- Victor Mote <[EMAIL PROTECTED]> wrote:
> Glen, what are your
> plans for
> apps/FOInputHandler? Will it be going away or get
> renamed anyway? I have
> been using "Handler" as related to SAX events, and
> it looks like we have it
> also being used as I/O in a more raw form.
>
Here's my though
--- Victor Mote <[EMAIL PROTECTED]> wrote:
>
> Hmmm. I'm not sure how to interpret the silence. I'm
> going to press on with
> my proposals unless I get some sort of substantive
> reply.
>
> Victor Mote
>
Victor,
I apologize for the silence--I did read your email on
Sunday and more thoroughly
entralized and simplified somewhat, by having an
render() option that will take an InputHandler and
extract the parser and stream itself. I'll look into
that.
Glen
--- Glen Mazza <[EMAIL PROTECTED]> wrote:
> I'll look into it. Actually, I got my complaint
> wrong--I have less p
a problem with the apps package
> reference the configuration
> package. And it's almost the same code and with the
> same semantics
> everywhere so this would actually reduce code.
>
> On 21.07.2003 18:20:30 Glen Mazza wrote:
> > Yes, I said InputHandler is where the
--- Victor Mote <[EMAIL PROTECTED]> wrote:
> 1. In other words, I would
> like to have permission to temporarily treat Driver
> as either a singleton or
> a location for static constructs, which can be used
> to control the
> interaction between the various modules, so that I
> can move that logic
tioned in my earlier mail, I almost
> exclusively use the
> Transformer part of JAXP for XML parsing:
> InputSource --> Source. But
> that's personal preference.
>
> On 21.07.2003 17:50:19 Glen Mazza wrote:
> > We're currently creating equivalent XMLReader
Team,
We're currently creating equivalent XMLReaders for the
FO Tree in two places, the Driver class (within the
run() method) and within the InputHandler class
get/createParser() methods (with an additional
SetParserFeatures() within the Starter class).
I'd like to centralize all this into the
Team,
For internal xml/xslt -> fo translation, we are
currently using XSLTInputHandler in three places:
CommandLineOptions, FopPrintServlet and
TestConverter.java. (TraxInputHandler isn't being
used internally.) I would like us to switch from
XSLTInputHandler to JAXP.
For CommandLineOptions, I
Note before applying the patch file check how it
> references the files as
> you need to be in the correct directory to apply the
> patch file.
>
> If you're using Eclipse as IDE you can use the
> patcher from there. It's
> pretty easy there.
>
> Good luck!
&g
I've submitted them frequently, but, given a patch,
how does one apply it to a file in a working
directory? CVS has the "diff" command to create the
patch, but I don't know what its opposite command is,
to merge the patch into a file.
(BTW, using Windows 2000.)
Thanks,
Glen
_
Ali,
Have you considered http://www.renderx.com for their
commercial processor? That may be the best solution
for you at this moment. Regrettably, FOP is just not
ready for your needs yet.
Thanks,
Glen
--- ali farahani <[EMAIL PROTECTED]> wrote:
> To all FOP developers
>
> The out of memory p
J.Pietschmann wrote:
Glen Mazza wrote:
> (1.) I would like to remove the addToBuilder()
> function (and update its subclasses) from the
> ElementMapping interface and replace it with
> getNamespaceURI() and getFOTable() functions
+1
BTW this is not a change which requires a vote.
--- Victor Mote <[EMAIL PROTECTED]> wrote:
> I think it is instructive that neither of you
> commented on whether the
> changes that were made actually improved the code or
> not.
>
> I think you both
> need to either 1) show that the code was better
> before I changed it,
If the reason you gave
Victor,
I noticed we had to break up a function to satisfy
Checkstyle's max method length size of 150 (
http://marc.theaimsgroup.com/?l=fop-cvs&m=105806596213734&w=2).
That seems too constricted for our use--it's may
force parameter passing of local variables where none
would otherwise be needed.
Thanks for the explanation Stefan.
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On Thu, 10 Jul 2003, M. Sean Gilligan
> <[EMAIL PROTECTED]> wrote:
>
> > Putting the Fop task directly in Ant would be
> great. I would really
> > like to see that happen. I suppose we could get
> it in Ant 1.6 i
> As we are all getting
> our libraries
> updated through CVS anyway, would it not be better
> to name them
> consistently, and include a text file detailing the
> current versions?
>
> Peter
> --
I don't think so--it is helpful to immediately see the
version of the libraries when viewing the
501 - 600 of 664 matches
Mail list logo
