> -Original Message-
> From: John Austin [mailto:[EMAIL PROTECTED]
> Sent: November 20, 2003 12:37 PM
> To: [EMAIL PROTECTED]
> Subject: Development Environment suggestions ?
>
> So far I have been playing around like the Neanderthal*
> that I am. I use Sun Java 1.4.x with xterm, vi, emacs
> -Original Message-
> From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED]
> Sent: September 2, 2003 2:49 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Place committers on inactive list?
>
>
> Le Mardi, 2 sep 2003, à 03:33 Europe/Zurich, Glen Mazza a écrit :
> &g
working
> > without having to wait on us.
>
> +1
And also +1.
Arved
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
tters who are
interested in more - documentation, planning, the community, etc. The former
category, just as the non-committer developers, is not to be denigrated, but
you can defintely identify committers who take an interest in the big
picture as "leaders".
Arved Sandstrom
> ---
r a clarification and a re-write, the containing page is
> defined by the
> retrieved marker, the marker to retrieve is defined by the
> containing page.
I think we can all agree on asking for a rewrite. :-)
Arved
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
hen page 1...
> Admitedly it doesn't actually say that, but I can't interpret the
> wording otherwise.
[ SNIP ]
I re-read the spec so exhaustively that my eyes are burning. :-) I think
Keiron is right.
Boy, it would be cool if they could rewrite that section, though. :-)
Arve
Comments inline.
> -Original Message-
> From: Tony Graham [mailto:[EMAIL PROTECTED]
> Sent: February 24, 2003 10:26 AM
> To: [EMAIL PROTECTED]
> Subject: RE: markers in redesign
>
>
> Arved Sandstrom wrote at 24 Feb 2003 08:01:40 -0400:
> > Comments be
blishes
that there is no such qualifying area on the current page, than it's just
the first qualifying area one can find, moving back in the document.
Arved
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
te this portion (markers) made the spec too abstruse. I
finally just broke my rule of adhering to the law, and considered the use
cases, and decided what made sense. :-)
Arved
> -Original Message-
> From: Keiron Liddle [mailto:[EMAIL PROTECTED]
> Sent: February 23, 2003 6:49 PM
>
> -Original Message-
> From: Dirk-Willem van Gulik [mailto:[EMAIL PROTECTED]
> Sent: February 21, 2003 1:35 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Long licence
>
> On Fri, 21 Feb 2003, Arved Sandstrom wrote:
>
> > I'd like to find out what lawyer thou
a good
document, or a good implementation. Or both. In this case the experts are
the customers; we have a confused spec because they thought they were the
programmers and writers as well.
Arved
> -Original Message-
> From: Peter B. West [mailto:[EMAIL PROTECTED]
> Sent: February
ASF members list. I have problems with
this decision.
Arved
> -Original Message-
> From: Jeremias Maerki [mailto:[EMAIL PROTECTED]]
> Sent: February 21, 2003 9:19 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Long licence
>
>
> Arved,
>
> I don't see
o find out what lawyer thought a long license is needed with every
file. Because I question that finding.
Arved
> -Original Message-
> From: Dirk-Willem van Gulik [mailto:[EMAIL PROTECTED]]
> Sent: February 21, 2003 8:43 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Long licenc
cised, and replaced with plain language.
Arved
> -Original Message-
> From: Mark C. Allman [mailto:[EMAIL PROTECTED]]
> Sent: February 18, 2003 5:16 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Markers in areas
>
>
> ... but markers will continue to work as per the XSL
. In
fact, I can't see any theoretical use for the idea either.
Arved
> -Original Message-
> From: J.Pietschmann [mailto:[EMAIL PROTECTED]]
> Sent: February 16, 2003 8:14 PM
> To: [EMAIL PROTECTED]
> Subject: Markers in areas
>
>
> Hi,
> does somebody need th
;
> We had no -1 votes. The following active committers haven't voted so
> far: Karen Lease and Arved Sandstrom.
>
>
> Keiron Liddle proposed establishing some kind of rotation for the FOP
> representation in the XML PMC. We like the idea and we would like to ask
> the curr
ugh to rebalancing in
> case a is encountered?
Yes. There is no provision for columns in the footnote region.
Arved
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Title: JforIntegrationInFop - background and guidelines
I
looked at the page, Rhett. It looks good as a mission statement. This area
interests me a lot too, and I hope to start adding to it.
Arved
-Original Message-From: Rhett Aultman
[mailto:[EMAIL PROTECTED]]Sent: December
I'd like to wish everyone here happy holidays, whatever is appropriate.
This is a good crowd.
Regards,
Arved Sandstrom
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
But it was plausible. :-)
> -Original Message-
> From: Patrick Dean Rusk [mailto:[EMAIL PROTECTED]]
> Sent: December 18, 2002 12:51 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Sun XSL Formatter
>
>
> Then I retract the suggestion.
>
> Pat
>
>
> -Original Message-
> From: Tony Graham
> -Original Message-
> From: Tony Graham [mailto:[EMAIL PROTECTED]]
> Sent: December 16, 2002 12:23 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Sun XSL Formatter
>
>
> Arved Sandstrom wrote at 14 Dec 2002 15:05:05 -0400:
> > No bitterness at all, actually, Pet
> -Original Message-
> From: Victor Mote [mailto:[EMAIL PROTECTED]]
> Sent: December 14, 2002 3:40 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Sun XSL Formatter
>
>
> Arved Sandstrom wrote:
>
> > But can I point out that C is about as portable as it gets?
&
o keep plugging away at FOP.
>
> Victor Mote
Victor, I intend to continue supporting FOP myself.
But can I point out that C is about as portable as it gets?
Arved
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
> -Original Message-
> From: Peter S. Housel [mailto:[EMAIL PROTECTED]]
> Sent: December 14, 2002 2:21 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Sun XSL Formatter
>
>
> "Arved Sandstrom" <[EMAIL PROTECTED]> writes:
>
> > Well, Java or C or
Well, Java or C or C++ or Haskell, it would have been nice to have a clue.
We have an ASF tradition of developing communities...this kind of stuff that
Sun and IBM does is getting old. Don't open-source it; sell it. I will argue
against its adoption into Apache.
Arved
> -Original
Not to sound bitter, but it would have been nice to know about this sooner.
This pretty much usurps what I and Eric Bischoff have been doing (when we
can); I sort of figure it didn't get written in the last month either. Any
reason for the blasted secretiveness?
Arved
> -Original
Responses below.
> -Original Message-
> From: Keiron Liddle [mailto:[EMAIL PROTECTED]]
> Sent: December 10, 2002 5:56 AM
> To: FOP
> Subject: RE: Redesign issues
>
>
> Hi Arved,
>
> On Mon, 2002-12-09 at 20:30, Arved Sandstrom wrote:
> > The feeling I
I don't know.
Here's a common ground that I can agree on...pull the layout logic out, and
put it in "managers". This is not going to hurt. But really, really cut down
on the urge to re-use managers through an inheritance hierarchy. I think
this is also Joerg's point. It
ow December 2002 and we are not where we want
to be, not even close, which is providing an open-source Extended
conformance XSL processor to the hungry, huddled and poor.
Arved
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Considering that our new chief executive is Greg Stein, I'd be surprised if
this isn't on the horizon. :-)
> -Original Message-
> From: J.Pietschmann [mailto:[EMAIL PROTECTED]]
> Sent: December 1, 2002 4:12 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Still on for freeze deadline?
>
>
> Jerem
he only reason to adopt your approach (and I am not saying I don't like it)
is because it's easier to understand.
Regards,
Arved
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
ok at code much, and same goes for
weekends.
I am not disinterested in Fop and will attempt to continue providing input.
I haven't stopped monitoring the lists. But until such a time as I can
contribute code I should be considered inactive.
Arved
> -Original Message-
> From: [EMAIL
+1.
> -Original Message-
> From: Keiron Liddle [mailto:[EMAIL PROTECTED]]
> Sent: November 20, 2002 5:23 AM
> To: FOP
> Subject: [VOTE] Victor as committer
>
>
> Hi Developers,
>
> I propose we have a vote for Victor to become a committer.
>
> Plenty of eagerness shown already and I am
> -Original Message-
> From: Kevin O'Neill [mailto:kevin@;rocketred.com.au]
> Sent: November 11, 2002 5:47 PM
> To: FOP Developers
> Subject: Re: A performance patch for PDFInfo class
>
[ SNIP ]
> String buffers are used by the compiler to implement the binary string
> concatenation operato
> -Original Message-
> From: J.Pietschmann [mailto:[EMAIL PROTECTED]]
> Sent: October 6, 2002 2:15 PM
> To: [EMAIL PROTECTED]
> Subject: Re:
>
>
> Arved Sandstrom wrote:
> > And unless _I_ am missing something, "-" precisely matches that
> -Original Message-
> From: J.Pietschmann [mailto:[EMAIL PROTECTED]]
> Sent: October 6, 2002 1:29 PM
> To: [EMAIL PROTECTED]
> Subject: Re:
>
>
> Arved Sandstrom wrote:
> > An Expr can be a Literal, the production for which is
> >
> > '
> -Original Message-
> From: J.Pietschmann [mailto:[EMAIL PROTECTED]]
> Sent: October 6, 2002 12:39 PM
> To: [EMAIL PROTECTED]
> Subject: Re:
>
> Arved Sandstrom wrote:
> > Can you cite the specific productions that lead to this
> conclusion? I am not
>
> -Original Message-
> From: J.Pietschmann [mailto:[EMAIL PROTECTED]]
> Sent: October 6, 2002 12:00 PM
> To: [EMAIL PROTECTED]
> Subject: Re:
>
>
> Arved Sandstrom wrote:
> > Why is character="-" a parsing error? The XML Recommendation
> has at
> -Original Message-
> From: Peter B. West [mailto:[EMAIL PROTECTED]]
> Sent: September 30, 2002 11:24 PM
> To: [EMAIL PROTECTED]
> Subject: Re:
>
> Arved Sandstrom wrote:
> >>-Original Message-
> >>From: Tony Graham [mailto:[EMAIL PROTECTE
ength 1.
>
> Except that you know that that's not specified among the allowed
> conversions.
>
> The interesting thing is that 'character' doesn't appear in the
> productions in Section 5.9, Expressions, of the XSL Recommendation.
> Now there's a question for [
ation-separator" merely says
that it's a specification of a Unicode character. I guess that could be
interpreted the same way.
But for the "character" property says _code point_. And that is
an integer value.
So I
.._You_ had paper tape?! I
lived in a culvert, didn't go to school, and flipped switches on vacuum
tubes to set the program).
Arved
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
tuff correctly as well as being able to do the various
> kinds of line-stacking strategies defined by the XSL-FO spec.
I am definitely interested. I have put some thought into these things
already. Granted, when I implement it'll be a different codebase but I
ocal, but
m_b = 3;
is assigning to an instance variable. Not everyone has access to something
like IntelliJ IDEA where this kind of thing is much less of a problem.
BTW, I could personally care less about the syntax - m_name, _name,
this.name - that communicates the
he keeps problem to solve itself at implementation time?
:-) There needs to be an algorithm, pseudocode or otherwise, that clearly
explains how layout will occur in the presence of keeps.
If there is something I am missing here I would dearly love to hear about
it. :-)
Regards,
Arved
-
approach, not any more (if I ever was). I don't
think a typed child approach would interfere with extensibility, and I think
the primary advantage is that the code is more self-documenting. Accessor
methods could also be more specialized. Also, the sophisticated
con
ault constructor for ArrayList creates
an array of 10 Objects. An inexpensive check for null in addChild() is
unlikely to cost more, even over many children, especially averaged over an
entire document.
Case 2 might be overkill, unless one can make the case that single children
are frequent enou
y started,
no matter what. I think it's a good thing that we finally put some things on
the table.
Regards,
Arved
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
and make a hard decision.
Maybe I am the wrong person to be saying this right now - because I am not
currently involved - and maybe I am the right person - because I am not
currently involved. In any case, it is said, and I hope we get some good
discussion going. Peter, thanks, you started it off.
some generalisation of flows of the
fo:flow type, and have more flexibility than just one single fo:region-body.
Regards,
Arved Sandstrom
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
final key is
unlimited.
I just downloaded and unzipped the latest, and the interim key file is
certainly present, in the bin/ directory.
Arved
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
nt I am
in the same boat as lots of other people, i.e., I don't comprehend the
current HEAD codebase that well, and anything that helps is welcome.
Regards,
Arved Sandstrom
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
reeBuilder SAX2 interface.
> Does someone remember questions about SAX1 support? If not:
> +1 for removing XTFOTreebuilder and XTElementMapping
+1 on both.
Arved
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Well, if by "ASF" you mean the board, then that sentence parses better.
Because a mini-chunk of the ASF is already here and as uninformed as the
rest. :-)
Seriously, though, I'll track down board minutes and see where this is
explained, and report back.
Arved
> ---
t have been expressed before and I think
they are still valid.
But that's common sense. When did licensing ever mesh with common sense? :-)
If we have to switch back to the long form, oh well. Not much choice there.
Regards,
Arved Sandstrom
nk mailing lists are pretty poor for issue management, so I
think it is worth a shot. I am amost completely engaged with the other
project at the moment but I haven't left FOP but temporarily; my main
problem at the moment is keeping abreast of the lists an
> -Original Message-
> From: Christian Geisert [mailto:[EMAIL PROTECTED]]
> Sent: June 10, 2002 1:20 PM
> To: [EMAIL PROTECTED]
> Subject: manifest classpath (was: Re: delay for release candidate)
>
> Arved Sandstrom schrieb:
> > Christian, if it's not alr
I'll see what I can locate. It's useful to have the earlier history in mind
if we decide to talk to them now.
Arved
> -Original Message-
> From: Jeremias Maerki [mailto:[EMAIL PROTECTED]]
> Sent: June 5, 2002 8:11 AM
> To: [EMAIL PROTECTED]
> Subject: Re: R
e from that project ever contacted the FOP team.
They have, actually. :-) I believe the mail archives will reflect that.
There were the first expressions of interest in cooperation but it was not
really pursued. By either side.
Arved
--
to a
redundancy of XML parsers and XSLT processors.
Easiest way to do this and still maintain organisation is to expect fop.jar
to be co-located with the JARs that it needs.
Arved
> -Original Message-
> From: Christian Geisert [mailto:[EMAIL PROTECTED]]
> Sent: June 3, 2002 8:50 P
there is a label in VSS that maps to this.
JARs also include any shared libs/DLLs. These also get built at the same
time as everything else.
It's not perfect but if a customer reports problems with a JAR we have
enough in
Hi, all
I am very pleased to announce that Keiron has been elected to membership in
the Apache Software Foundation, effective tomorrow (voting finished today).
I'd like to be the first to extend my hearty congratulations. :-)
Regards,
Arved
__
Arved Sandstr
rk on, over a month or two, that is going to straddle a number
of releases, and they simply will not have working code available during
that time period, and what they are doing would actually affect
functionality if it were to be in the main branch. But with this major
exception I can't think
> -Original Message-
> From: Adrian Edwards [mailto:[EMAIL PROTECTED]]
> Sent: May 22, 2002 10:18 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Why do links generate multiple rectangles in PDF?
>
> Thanks Arved,
>
> That sounds far more promising than I had hoped.
> -Original Message-
> From: J.Pietschmann [mailto:[EMAIL PROTECTED]]
> Sent: May 22, 2002 6:07 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Why do links generate multiple rectangles in PDF?
>
> Arved Sandstrom wrote:
> > So that's your answer. :-) The mult
o links generate multiple rectangles in PDF?
>
>
> Can anyone (Arved?) give me a brief explanation of why one
> will generate multiple link rectangles (one for
> each word!) in a PDF rendering?
>
> This would seem to have a dramatic effect on the file size of
> larger PDF d
gards,
AHS
__
Arved Sandstrom
Sr Software Developer
Platform Products Group
Halifax R&D Office
Hummingbird Ltd
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
image size.
I think I am missing something. Can you describe this scenario in more
detail? It sounds like a good use case.
Regards,
Arved Sandstrom
> -Original Message-
> From: Torsten Erler [mailto:[EMAIL PROTECTED]]
> Sent: May 15, 2002 6:23 AM
> To: Fop-Dev (E-mail)
> S
A drop cap, in other words. :-)
> -Original Message-
> From: J.Pietschmann [mailto:[EMAIL PROTECTED]]
> Sent: May 14, 2002 4:47 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Line breaks and other typographical stuff (was: Re: Latest
> FOP schema)
>
>
> Arved Sands
erifs. Also, the automatic displacement of the next
> lines could be a problem. I think there is also a float necessary
> in XSLFO, perhaps with some adjustments to the width and with
> relative positioning for fine tuning.
text-indent. If that's not it,
fails me much to often...
This would not be covered in UTR 14, Line Breaking Properties?
(http://www.unicode.org/unicode/reports/tr14/).
Arved
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Comments intermingled.
> -Original Message-
> From: J.U. Anderegg [mailto:[EMAIL PROTECTED]]
> Sent: May 13, 2002 5:15 AM
> To: [EMAIL PROTECTED]
> Subject: AW: AW: Latest FOP schema
>
> J. Pietschmann wrote:
>
> are
>
> > Rectangular areas, perhaps indented and with border, padding
> >
Comments down under...
> -Original Message-
> From: Keiron Liddle [mailto:[EMAIL PROTECTED]]
> Sent: May 7, 2002 4:40 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [REDESIGN] Line layout manager discussion
>
>
> On Tue, 2002-05-07 at 03:56, Arved Sandstrom wrote:
ot;height"; one _can_
use "height" but only for replaced inline-level FOs. So for an original
"inline", say, we'd ignore a "height" but use "line-height" instead, which
more often than not is jus
s take precedence.
margin-left if explicitly specified has priority over start-indent.
I took a quick look at table.fo (the FO) and I think this will probably help
out. I have to admit if there is one area of the spec that I am not
particularly familiar with i
> -Original Message-
> From: Peter B. West [mailto:[EMAIL PROTECTED]]
> Sent: May 5, 2002 12:55 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [REDESIGN] Line layout manager discussion
>
>
> Arved,
>
> I agree that there is no need to tie the rendering to any part
am going to handcode it, though
(just as with FO).
Arved
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
X
needs to store certain information and it may as well use Area objects to do
it. But I lean strongly towards a viewpoint where the areas have no
knowledge of original semantics.
Regards,
Arved
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
t/shouldn't co-exist in a single normal block area
generated by the top-level block FO. I was suggesting the "shouldn't"
viewpoint; Karen reads it differently.
I am off to work so cannot comment more at the moment, on anything. :-)
Arved
---
is actually applicable to (useable by)
that FO. This isn't just a side-efefct of inheritability, this _is_
inheritability. :-)
> and
>
> Is there a list of these "inheritable attributes" ? Or do I just
> generate the list from those attributes that have an enum
ct: Re: [REDESIGN] Line layout manager discussion
>
> Arved, Keiron et. al.
>
> I guess logically it's true that the blocks nested in inlines should be
> wrapped in inline areas, but it makes me nervous :-)
> At least they cause line breaks, that much seems sure.
Good...if we a
ewhat reluctant to do any
coding at the moment until such a time (hopefully not far away) where I am
satisfied that I understand the new design well.
Arved
> -Original Message-
> From: Keiron Liddle [mailto:[EMAIL PROTECTED]]
> Sent: May 2, 2002 6:18 AM
> To: [EMAIL PROTECTE
Comments inline.
> -Original Message-
> From: J.U. Anderegg [mailto:[EMAIL PROTECTED]]
> Sent: May 1, 2002 5:19 PM
> To: [EMAIL PROTECTED]
> Subject: AW: [REDESIGN] Line layout manager discussion
>
> Questions:
>
> o A basic-link in PDF means an annotation - an annotation defines a
> rect
tly facilitate this sort of
> discussion. Any candidates for a linux-enabled SVG editor?
I'll have to take a look around. I happened to use Visio because it's on the
machine and I'm familiar with it, plus it's a nice piece of gear. The most
recent Visios do SVG, I believe, but I don't have a copy at home.
We could use Postscript as well.
Arved
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
that normal block
areas generated by a fo:block have either _single_ block areas _or_ one or
more line areas as children, not a mixture.
Final comment: it is the close intermingling of inlines and blocks in this
example that causes so much line breaking. Clearly each of the 2 nested
block
You'll get a disgruntled reply from Brian if you actually asked him on his
personal email. :-) Stuff like this it's best to go to [EMAIL PROTECTED];
typically you'll end up talking to Manoj Kasichainula.
Arved
> -Original Message-
> From: Peter B. West [mailto:[EMA
ackages - what it means is you are the POC for work being done
in that package. You are the arbiter of disputes. We could even combine this
with BugZilla ownership, possibly.
Comments? If folks are agreed or at least not against it I can set up what
needs to be setup.
Arved
> -Original
kidding. :-) Have
you looked at the Java reference implementation for it? :-) Not a trivial
thing.
Arved
> -Original Message-
> From: Keiron Liddle [mailto:[EMAIL PROTECTED]]
> Sent: April 26, 2002 10:16 AM
> To: [EMAIL PROTECTED]
> Subject: line layout commit
>
>
&
h a relatively
stable spec that _definitely_ has a strong business case. :-)
If you read the report, incidentally, the GAO is not urging caution with
respect to XML, per se - it has to do with how the technology is being
adopted.
Regards,
AHS
__
Arved Sandstrom
Sr Soft
What it says. It builds, and I ran a few simple tests.
I'll be standing by to do any further fixup work or to add more related
features.
Regards,
AHS
__
Arved Sandstrom
Sr Software Developer
Platform Products Group
Halifax R&D Office
Hummin
eases/). These mostly seem to be
based on Jabber. It wouldn't take much to do up a JMS solution using an
open-source JMS broker and some applets (I have a colleague who knocked out
something pretty similar as an inhouse experiment in a couple of days).
Arved
arved 02/04/23 15:33:40
Modified:src/org/apache/fop/render/awt Tag: fop-0_20_2-maintain
AWTRenderer.java
src/org/apache/fop/render/mif Tag: fop-0_20_2-maintain
MIFRenderer.java
src/org/apache/fop/render/pcl
arved 02/04/23 15:28:09
Modified:src/org/apache/fop/render/xml Tag: fop-0_20_2-maintain
XMLRenderer.java
Log:
support for background-image (all renderers)
author: Michael Gratton
Revision ChangesPath
No revision
No
arved 02/04/23 15:26:59
Modified:src/org/apache/fop/render Tag: fop-0_20_2-maintain
AbstractRenderer.java PrintRenderer.java
Log:
support for background-image (all renderers)
author: Michael Gratton
Revision ChangesPath
No
arved 02/04/23 15:26:10
Modified:src/org/apache/fop/layout Tag: fop-0_20_2-maintain Area.java
BackgroundProps.java BodyRegionArea.java
RegionArea.java
Log:
support for background-image (all renderers)
author: Michael Gratton
arved 02/04/23 15:25:25
Modified:src/org/apache/fop/fo/pagination Tag: fop-0_20_2-maintain
RegionAfter.java RegionBefore.java RegionBody.java
RegionEnd.java RegionStart.java
Log:
support for background-image (all renderers)
author
arved 02/04/23 15:24:45
Modified:src/org/apache/fop/fo/flow Tag: fop-0_20_2-maintain
Block.java BlockContainer.java ListBlock.java
Table.java TableBody.java TableCell.java
TableColumn.java TableRow.java
Log
arved 02/04/23 15:23:39
Modified:src/org/apache/fop/fo Tag: fop-0_20_2-maintain
PropertyManager.java
Log:
support for background-image (all renderers)
author: Michael Gratton
Revision ChangesPath
No revision
No
arved 02/04/23 15:22:53
Modified:src/codegen Tag: fop-0_20_2-maintain foproperties.xml
Log:
support for background-image (all renderers)
author: Michael Gratton
Revision ChangesPath
No revision
No revision
1.25.2.3
> -Original Message-
> From: Michael Gratton [mailto:[EMAIL PROTECTED]]
> Sent: April 22, 2002 11:11 PM
> To: [EMAIL PROTECTED]
> Subject: Re: inital background-image patch
>
> Arved Sandstrom wrote:
> >
> > I seem to recall from last year that we
1 - 100 of 390 matches
Mail list logo
