identified of making layout
easier to work on.
I do not know if this is a lot of work or not. To me it seems a
lot. Perhaps you may argue that this is not required for a 0.3
release. But to me it is rather essential to the new design. Without
it we might as well remain with the maintenance layout system
On Sep 28, 2004, at 2:08 AM, Chris Bowditch wrote:
Simon Pepping wrote:
I do not know if this is a lot of work or not. To me it seems a
lot. Perhaps you may argue that this is not required for a 0.3
release. But to me it is rather essential to the new design. Without
it we might as well remain
Chris,
thank you doing this. I think it's important to have a good instrument
to determine our progress towards an initial release. I was a bit
shocked when I summed up only the points you've marked as high priority:
20 weeks. It got me thinking and running all the example files again
that I
Team,
I have been trying to work out what is left to do be done before we can do an
initial release of HEAD, 0.3, say. I know some of you will prefer to aim for a
1.0 and get everything right first time, but please bear with me.
I have consolidated the layout issues from [1] and [2
Sorry for the delay.
On 16.07.2004 19:00:25 Victor Mote wrote:
Jeremias Maerki wrote:
Making these parts into separate components is in line with
what I have in mind when can talk about a shared repository
between Batik and FOP. I hope I can take a good look into
Good. I think it
Jeremias Maerki wrote:
I'm simply thinking that adding statics is a lot easier than
removing them again. I usually create non-static classes and
create singletons around them if necessary or convenient.
That's basically it.
One of the main purposes of
FontServer was to share as much
Chris, Jeremias, and anyone else looking at FOray code:
I have created the following branch in FOray's CVS that you will want to use
for your evaluation:
rel_0_1_branch
I have started some other changes in the root that should probably be
evaluated separately.
I apologize for the
Jeremias Maerki wrote:
Making these parts into separate components is in line with
what I have in mind when can talk about a shared repository
between Batik and FOP. I hope I can take a good look into
Good. I think it has potential to be useful to many applications.
what you did later.
solved.
When the XML Graphics project is set up I hope we can soon talk about
the details of my ideas. I'd love to have you with us to work on the
shared components.
On 13.07.2004 22:40:43 Victor Mote wrote:
FOP Devs:
I am pleased to announce the release of FOray 0.1 alpha 1. This release
Victor Mote wrote:
FOP Devs:
I am pleased to announce the release of FOray 0.1 alpha 1. This release is
only useful to FOP developers. Some useful information about the release can
be found in these places:
http://foray.sourceforge.net/module/font/index.html
http://foray.sourceforge.net/module
FOP Devs:
I am pleased to announce the release of FOray 0.1 alpha 1. This release is
only useful to FOP developers. Some useful information about the release can
be found in these places:
http://foray.sourceforge.net/module/font/index.html
http://foray.sourceforge.net/module/font/release.html
Clay Leeds wrote:
Thanks for the respectful response. I'm aware that HEAD release is
adversely affected by MAINTENANCE work (hence the I don't want to start
a ware here, but... :-)), however, I posted this for a few of reasons:
1) fop-dev team might discuss this in light of the possibility
J.Pietschmann wrote:
Well, we could release the current CVS as 0.20.5.1. The table memory
fix is probably important to many users. THere is a slo a minor fix
concerning leader expansion there.
Okay, but you said yourself that the adjustments you made to tables has
probably broken some other
things can we shoe-horn into
FOP. It's more of an issue with what features can be added to FOP to
make it even more desirable and get more users (and developers) on
board.
Web Maestro Clay
On Jan 7, 2004, at 12:42 AM, Chris Bowditch wrote:
J.Pietschmann wrote:
Well, we could release the current
, but is more of a would be nice...
I understand the desire to add new features like the Tif generator into
the maintenance code. However, doing so would mean effort is distracted
away from HEAD development. The sooner we can do a release from HEAD
then the sooner FOP gets out of the twilight zone
it
works, this isn't a make-or-break for me, but is more of a would be
nice...
I understand the desire to add new features like the Tif generator
into the maintenance code. However, doing so would mean effort is
distracted away from HEAD development. The sooner we can do a release
from HEAD
-Original Message-
From: Chris Bowditch [mailto:[EMAIL PROTECTED]
snip /
I understand the desire to add new features like the Tif generator into
the maintenance code. However, doing so would mean effort is distracted
away from HEAD development. The sooner we can do a release from
On Jan 7, 2004, at 12:07 PM, J.Pietschmann wrote:
It works for me for generating PDF for quite some time. I get NPE when
reloading a FO source in the AWT appilcation, but this maz have other
reasons, I didn't try to track it down.
As long as I can remember I got NPE when clicking the [Reload]
Chris Bowditch wrote:
Thus, I just wanted to know if some sort of 0.20.6 release will be
upcoming in the future
No, no further releases are planned from the maintenance branch, and all
development is focused on CVS Head.
Well, we could release the current CVS as 0.20.5.1. The table memory
fix
--- 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
Glen Mazza wrote:
I'll leave the 0.20.x branch alone until others
complain about this problem, however.
There is no problem in the maintenance branch, because it was
fixed there (and unfixed, and refixed etc...) ages ago.
J.Pietschmann
-Original Message-
From: Glen Mazza [mailto:[EMAIL PROTECTED]
Thanks, Tom, for your quick assistance. I didn't know
about the AWT threading issue you brought up.
Thomas,
Can you perhaps have a look at bug 23883? In embedded SVG, something's going
wrong with translate() when large
--- 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...
Andreas,
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 problem in the maintenance branch,
because it was
fixed
Glen Mazza wrote:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23883
Thomas,
You needn't bother on this at this time--we have yet
to find where Batik is wrong. So far, Squiggle has
drawn the SVG correct *all* the time. But comments
always welcome, and it's good for you to be aware of
the
-Original Message-
From: Glen Mazza [mailto:[EMAIL PROTECTED]
Also, providing a link to the bug is indicated
here--asking Thomas to hunt through Bugzilla in order
to help us out--these problems are with our code, not
his--is somewhat rude.
Ok. I probably supposed that Thomas would
):
0.20.5 release: works fine (1-yr. old Batik)
0.20.x nightly: hangs (Batik updated one month ago,
due to API changes)
1.0 dev: hangs (Batik version of two weeks
ago,
also with nightly build)
All three still generate a correct PDF document w/SVG,
even though the app hangs (I just need
). I'm concerned others may be
getting this hanging thread problem on their machines.
Results of the below FO (work computer):
0.20.5 release: works fine (1-yr. old Batik)
0.20.x nightly: hangs (Batik updated one month ago,
due to API changes)
1.0 dev: hangs (Batik version of two weeks
ago
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
To: [EMAIL PROTECTED]
Subject: RE: 0.20.5 release
I would agree to Ricardo. We're using tables for inventory lists
containing about 500 pages. The memory situation in that reports is
really critical and we cannot force the users to set filters.
On the other hand: to us it doesn't matter if this enhancement
the same feature separately).
The current pre-release needs about 1 MB RAM per page in our reports - that is indeed
no problem if you have a machine with about 256 MB or more and have no other
applications loaded while using FOP.
But we're using FOP as add-on to some of our applications
Le Mardi, 8 juil 2003, à 10:14 Europe/Zurich, Thomas Sporbeck a écrit :
...It might be a fundamental decision if FOP is a kind of toolbox
for developers or if it should be an out of the box-product for
nearly everyone - I think there's so much good ideas in it that
everyone should be able to
On Tue, 2003-07-08 at 14:31, Bertrand Delacretaz wrote:
I might be wrong, but I think most users of FOP are using it
server-side, where resources (especially memory) are more readily
I don't know about most users, but I am using FOP client-side since I do
not have a server.
Felix
I might be wrong, but I think most users of FOP are using it
server-side, where resources (especially memory) are more readily
available. This might explain your problems, I think little energy has
been spent to optimize FOP's memory requirements.
Yes, I agree.
else. It will certainly require some amount of testing, which
means another release candidate and which is therefore quite
unpopular with our release manager.
J.Pietschmann
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
Thomas Sporbeck wrote:
It might be a fundamental decision if FOP is a kind of toolbox for
developers or if it should be an out of the box-product for nearly everyone
It is Open Source. If you find issues and create patches, send
them in. Every contribution is welcome.
J.Pietschmann
, June 19, 2003 3:41 PM
To: [EMAIL PROTECTED]
Subject: RE: 0.20.5 release
I would agree to Ricardo. We're using tables for inventory lists
containing about 500 pages. The memory situation in that reports is
really critical and we cannot force the users to set filters.
On the other hand: to us
an older one for version
0.20.3). It would be nice if one of you guys could take a look at those
patches and consider them before issuing the final 0.20.5 release.
Congratulations to you all on an excellent job, you are doing,
Ricardo Amador
-Original Message-
From: Christian Geisert [mailto
I would agree to Ricardo. We're using tables for inventory lists
containing about 500 pages. The memory situation in that reports is
really critical and we cannot force the users to set filters.
On the other hand: to us it doesn't matter if this enhancement comes
with 0.20.5 or with a later
Ok,
RC3a seems to be rather stable and the changes since then look
non-critical to me. What about doing the release now (read: next days)
(and maybe 0.20.5a later if we get more hyphenation patterns back)
Or should we make the changes proposed by Jörg (improved memory
usage with tables - see
On 17.06.2003 19:16:23 Christian Geisert wrote:
RC3a seems to be rather stable and the changes since then look
non-critical to me. What about doing the release now (read: next days)
+1
(and maybe 0.20.5a later if we get more hyphenation patterns back)
Don't count on that. :-(
Or should we
Christian Geisert wrote:
RC3a seems to be rather stable and the changes since then look
non-critical to me. What about doing the release now (read: next days)
(and maybe 0.20.5a later if we get more hyphenation patterns back)
Or should we make the changes proposed by Jörg (improved memory
usage
Hi all,
the second Release Candidate for 0.20.5 is finally available at
http://www.apache.org/dist/xml/fop for downloading and testing.
(New download location - please use a mirror if possible)
It is planed to make the actual release on on february the 28th
if no serious bugs show up
At 09:08 AM 2/18/2003, you wrote:
the second Release Candidate for 0.20.5 is finally available at
http://www.apache.org/dist/xml/fop for downloading and testing.
(New download location - please use a mirror if possible)
Cheers, and congratulations all around.
This was a bumpy one (especially
Ok, I worked on the patch. Some notes:
Mark C. Allman wrote:
These files just have a mayContainMarker() method added:
I don't understand the advantage of this. Checks for
proper FO structure are flaky anyway. You also canned
the check that a marker can be preceded by whitespace.
This is
+1, but strict bugfixing only, or else we're never going to make it.
On 12.02.2003 17:44:14 Christian Geisert wrote:
Ok,
in a perfect world the 0.20.5 release would have happend last
year and we all were working on HEAD now but in reality we're
still fixing bugs (which is ok as it will take
and wouldn't it be nice to dig in to this before the final release.
Take a look at line 526 of PDFRenderer.java, it clips to the size of the SVG image.
Is it possible that part of the SVG goes outside the SVG width and height?
Try commenting it out or changing the size of your SVG and seeing
Christian Geisert wrote:
in a perfect world the 0.20.5 release would have happend last
year and we all were working on HEAD now but in reality we're
still fixing bugs (which is ok as it will take some time till
the first redesign-relase) but nevertheless we should finally
finish 0.20.5.
So I
Christian Geisert wrote:
Ok,
in a perfect world the 0.20.5 release would have happend last
year and we all were working on HEAD now but in reality we're
still fixing bugs (which is ok as it will take some time till
the first redesign-relase) but nevertheless we should finally
finish 0.20.5.
So I
Christer,
Christer Sandberg wrote:
This is our SVG width and height:
svg width=252.836 height=52.828 ...
Up to this point, I have no experience with SVG, but I was surprised to
see that there is no unit of measurement (cm, mm, pt, px) in the height
width.
When I added some println()
Christian Geisert wrote:
So I propose the following plan:
Make another RC on february 17th and do the final 0.20.5 release
on february the 28th (no delay except for very valid reasons)
Comments?
+1
Victor Mote
Ok,
in a perfect world the 0.20.5 release would have happend last
year and we all were working on HEAD now but in reality we're
still fixing bugs (which is ok as it will take some time till
the first redesign-relase) but nevertheless we should finally
finish 0.20.5.
So I propose the following
Christian Geisert wrote:
Ok,
in a perfect world the 0.20.5 release would have happend last
year and we all were working on HEAD now but in reality we're
still fixing bugs (which is ok as it will take some time till
the first redesign-relase) but nevertheless we should finally
finish 0.20.5.
So I
Christian Geisert wrote:
So I propose the following plan:
Make another RC on february 17th and do the final 0.20.5 release
on february the 28th (no delay except for very valid reasons)
+1
J.Pietschmann
-
To unsubscribe, e
Christian Geisert wrote:
Ok,
in a perfect world the 0.20.5 release would have happend last
year and we all were working on HEAD now but in reality we're
still fixing bugs (which is ok as it will take some time till
the first redesign-relase) but nevertheless we should finally
finish 0.20.5.
So I
it be nice to dig in to this before the final release.
Take a look at line 526 of PDFRenderer.java, it clips to the size of the SVG image.
Is it possible that part of the SVG goes outside the SVG width and height?
Try commenting it out or changing the size of your SVG and seeing if it changes.
I'll
Christian Geisert wrote:
Thanks for contribution but as I'm planing to do the 0.20.5 release
tomorrow (really ;-) it's just to late for it.
I want to take a closer look at this:
1. We need to keep a list of all pages. If a marker is referenced on a
later page we need to be able to retrieve
.
-- Mark C. Allman
-- Allman Professional Consulting, Inc.
-- www.allmanpc.com, 617-947-4263
-Original Message-
From: J.Pietschmann [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 06, 2003 8:14 PM
To: [EMAIL PROTECTED]
Subject: Re: Changes to maintenance release to support fo:marker
at this, if not I will commit it
and do the release.
Christian
? lib/jimi-1.0.jar
Index: src/org/apache/fop/layout/LineArea.java
===
RCS file: /home/cvspublic/xml-fop/src/org/apache/fop/layout/Attic/LineArea.java,v
retrieving revision 1.53.2.12
Christian Geisert wrote:
I managed to workaround bug #15936 with making all InlineSpaces non
resizable if a LineArea contains a leader. This renders leader.fo a bit
different (but IMHO barely recognizable).
This is dangerous, because it overflows the line. Actually,
the page number is supposed
Title: RE: Release
Hi,
Firstly apologies for the HTML attached to the end of this message, I think it's something to do with the mail server which I don't have access to. I have asked about it, but I'm going on holiday tomorrow, and haven't got a reply yet.
Some thoughts on the problems
Ok,
we should finally finish 0.20.5
Open issues:
Remove xml-apis from Batik (Jeremias?)
Joerg has mentioned bug #15936 as showstopper to me.
(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15936)
Should we try to fix this? If yes any volunteer?
Anything else?
Christian
On 20.01.2003 16:33:28 Christian Geisert wrote:
Ok,
we should finally finish 0.20.5
Open issues:
Remove xml-apis from Batik (Jeremias?)
done (in branch).
Joerg has mentioned bug #15936 as showstopper to me.
(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15936)
Should we try to
Christian Geisert wrote:
Joerg has mentioned bug #15936 as showstopper to me.
(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15936)
Actually, I can't reproduce it right now. I'll give it
another try tomorrow.
J.Pietschmann
Uh, yeah. Almost forgot. I guess I can come up with a first version
until Thursday.
On 09.01.2003 19:42:31 Christian Geisert wrote:
Jeremias Maerki wrote:
[..]
Christian, when do you plan to release 0.20.5? Seems like no major bugs
are around, right?
Yes, I'm just waiting for your
Christian Geisert wrote:
- Perfo[r]mance tuning
Typo in CHANGES: bug number should read 14013, not 14103 (Cocoon bug)!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Hi all,
the Release Candidate for 0.20.5 is finally available at
http://xml.apache.org/dist/fop for downloading and testing.
It is planed to make the actual release in about two weeks
if no serious bugs show up.
Changes since 0.20.4 include:
- Fixed link hotspot positioning
- Fixed multi
Hi all,
I've (finally) updated the build process to the new Forrest docs
and I'm ready now for doing the Release Candidate.
If this is ok for everybody I'll do it later today.
Christian
-
To unsubscribe, e-mail: [EMAIL
Jeremias Maerki wrote:
How will we maintain the website after the copy? Change in trunk then
copy over to maint branch each time something is changed? Or can we
Yes, I'm not sure if automatic merging would work and I don't think
there will be a lot of changes.
Christian
On Thu, 2002-11-28 at 17:33, Christian Geisert wrote:
Hi,
for the documentation for the maintenance release I think the
best thing is to copy src/documentation over from trunk and then
add a simple exec command=forrest to build.xml
Comments?
The track.png in status.html needs a update
Peter B. West wrote:
Victor Mote wrote:
Christian Geisert wrote:
for the documentation for the maintenance release I think the
best thing is to copy src/documentation over from trunk and then
add a simple exec command=forrest to build.xml
Comments?
I had a thought left over from
Hi,
for the documentation for the maintenance release I think the
best thing is to copy src/documentation over from trunk and then
add a simple exec command=forrest to build.xml
Comments?
The track.png in status.html needs a update. How is it done?
Christian
Geisert wrote:
for the documentation for the maintenance release I think the
best thing is to copy src/documentation over from trunk and then
add a simple exec command=forrest to build.xml
Comments?
The track.png in status.html needs a update. How is it done?
Jeremias Maerki
Christian Geisert wrote:
for the documentation for the maintenance release I think the
best thing is to copy src/documentation over from trunk and then
add a simple exec command=forrest to build.xml
Comments?
I had a thought left over from our discussion of branching a few weeks ago
Victor Mote wrote:
Christian Geisert wrote:
for the documentation for the maintenance release I think the
best thing is to copy src/documentation over from trunk and then
add a simple exec command=forrest to build.xml
Comments?
I had a thought left over from our discussion of branching
Jeremias Maerki wrote:
It works in my environment. I'd be very grateful if I got feedback if it
works for others as well because the changes have quite some impact.
Nice feature, works like a charm for me. I believe it should be
documented along with baseDir and also example of defining
Will do.
On Sun, 10 Nov 2002 22:58:19 +0200 Oleg Tkachenko wrote:
Jeremias Maerki wrote:
It works in my environment. I'd be very grateful if I got feedback if it
works for others as well because the changes have quite some impact.
Nice feature, works like a charm for me. I believe it
On 08.11.2002 22:34:35 Christian Geisert wrote:
[Thanks for the gratulations and now back to FOP
(with permission from my wife ;-)]
We hope this stays that way. :-)
OK,
I'm planing to do the following things for the next maintenance release
Fix for bug #7587 (color problems with jpeg
Christian Geisert wrote:
[Thanks for the gratulations and now back to FOP
(with permission from my wife ;-)]
Welcome to the club :)
The CHANGES files needs to be updated. Best thing would
be if everybody documents his own changes, if not I'll try to
do it from the cvs-commit messages
Here
Oleg,
Thanks for that. I have noticed that there are quite a few people who
do respond on dev-user, in addition to yourself and Keiron, which is why
I wondered whether Joerg was making a specific request. I eventually
concluded he was not.
Peter
Oleg Tkachenko wrote:
Peter B. West wrote:
, November 08, 2002 4:35 PM
To: [EMAIL PROTECTED]
Subject: plan for 0.20.5 release
[Thanks for the gratulations and now back to FOP
(with permission from my wife ;-)]
OK,
I'm planing to do the following things for the next maintenance release
Fix for bug #7587 (color problems with jpeg images
Christian Geisert wrote:
Anybody else (Joerg/Rhett?) working on something with should go
into this last maintenance release?
- update ant.jar, with ant-optional.jar (for style task),
or do something else.
- get rid of buildtools.jar Simply move the hyph taskdef
to the target and use
J.Pietschmann wrote:
Christian Geisert wrote:
Anybody else (Joerg/Rhett?) working on something with should go
into this last maintenance release?
- update ant.jar, with ant-optional.jar (for style task),
or do something else.
Why?
Who will take care of the unanswered questions while I'm
Rhett Aultman wrote:
... as soon as I'm done taking the GRE tomorrow (wishes of luck appreciated)...
Consider them wished.
Peter
--
Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/
Lord, to whom shall we go?
Joerg,
If you haven't already left, which questions did you have in mind? Is
it your practise to monitor dev-user for questions which nobody else
picks up? Is that the role you want someone else to take over?
Enjoy the holiday. Very sensible of you to stay off-line.
Peter
J.Pietschmann
J.Pietschmann wrote:
I'm on vacancy from tomorrow on for a bit more than three
weeks, so I can't do this myself.
Who will take care of the unanswered questions while I'm
offline? Oleg?
Sure. Have a nice time on the vacation!
--
Oleg Tkachenko
eXperanto team
Multiconn Technologies, Israel
Christian Geisert wrote:
I haven't had much time recently to work on the next (final)
maintenance release and will be on holiday the next two
weeks (honeymoon ;-)
Hearty congratulations!
but then we really should get the release
out and so I propose the end of the first week of november
Hi,
I haven't had much time recently to work on the next (final)
maintenance release and will be on holiday the next two
weeks (honeymoon ;-) but then we really should get the release
out and so I propose the end of the first week of november
as target date for the release candidate.
Then maybe
by then. That was my only real goal for
maintenance.
Felicitations on your matrimony, BTW.
-Original Message-
From: Christian Geisert [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 16, 2002 1:24 PM
To: [EMAIL PROTECTED]
Subject: Maintenance release
Hi,
I haven't had much time
Hello,
Will the maintenance release in the first week of November support the
keep-together property ?
Thank You!
Shaifali Prakash
CHT / Media Entertainment
San Francisco
email: [EMAIL PROTECTED
[EMAIL PROTECTED] wrote:
Will the maintenance release in the first week of November support the
keep-together property ?
Yes, in exactly the same way as the current version (table rows only).
J.Pietschmann
-
To unsubscribe
]
cc:
10/16/2002 12:38 PM Subject: Re: Maintenance release
Please
Christian Geisert wrote:
Hi,
I haven't had much time recently to work on the next (final)
maintenance release and will be on holiday the next two
weeks (honeymoon ;-)
Congratulations. The first FOP wedding!
but then we really should get the release
out and so I propose the end
Hi,
there is a new FOA release 0.4.0.
Here there is a short list of new features/bug fixes:
- Absolute Positioning Brick
- Page Number Formats and Counting
- Added US Page Formats
- Fixed bugs for JDK 1.4
- Fixed page/content sequence bugs
There is also a list of the currentlu supported
Hi all,
I haven't seen anything about the next maintenance release for about a
week now, but I noticed that there had been some discussion about
basic-link problems.
In the meantime, I have improved the basic-link positioning and also
made it work for external-graphic and foreign-inline
[EMAIL PROTECTED] wrote:
is there a way to clear the image cache in FOP 0.2.0.2?
I saw some documentation suggesting a new static method on FopImageFactory
org.apache.fop.images.FopImageFactory.clearCache();
has this been implemented in newer versions?
Interesting question... looks like
Extract from the Changes file :
- BaseDir property is now used for loading custom fonts (Bug #7608)
(thanks to Arnd Beissner and Brian O'Kelley)
Applying this fix broke some stuff as far as I can tell. Fop ships with a
config file that has this property commented out. As a result basedir
Jeremias Maerki schrieb:
Hi Christian
here is the plan for the 0.20.4 release
[..]
There is a bug that needs to be fixed IMHO (or to be documented as known
issue):
- fo:list-item-label at the end of line
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9864
IMHO this is no showstopper
Hello,
there is a new FOA (Formatting Object Authoring tool) release: 0.3.0
Now there are these additional features:
- Complex Table Brick (full FO table implementation with Body, Headers and
Footers)
- Page Number Brick
- Multiple Headers/Footers for each Page Sequence
- Compliant
Ok,
here is the plan for the 0.20.4 release
First there are the following uncommitted patches:
- reload functionality for AWT viewer
http://marc.theaimsgroup.com/?l=fop-devm=102415975220531w=2
- implementation of margin shorthand
http://marc.theaimsgroup.com/?l=fop-devm=102483701915153w=2
1 - 100 of 182 matches
Mail list logo
