Renaud Richardet writes:
I just cleaned the patch that I submitted some long time ago. It should
work now. Please see my other mail to the list for details.
Thanks to both you and Jeremias for moving so quickly on this. I've
checked out the new code and am working on the changes now,
PS:
[EMAIL PROTECTED] writes:
I'm considering doing some work on the FOP viewer package.
The first patch has now been submitted.
The following improvements have been made:
1. Separated out the preview panels and control logic from the
buttons and dialog to make it easier to use elsewhere.
[EMAIL PROTECTED] writes:
jeremias2005/06/15 05:24:01
Modified:src/java/org/apache/fop/render/awt AWTRenderer.java
src/java/org/apache/fop/render/java2d Java2DRenderer.java
src/java/org/apache/fop/render/print PrintRenderer.java
Jeremias Maerki writes:
The migration of the xml-fop CVS module to Subversion is completed. The
CVS module is now read-only. All commits need to happen on SVN from now
on.
Base SVN URL for FOP:
http://svn.apache.org/repos/asf/xmlgraphics/fop/
FOP's trunk is at:
Jeremias Maerki writes:
If anyone has any problems, just shout! Have fun and hack away!
HELP! (you did say to shout :) )
Louder!
_ _ _ _ _
| | | | | | | _ \| |
| |_| | _| | | | |_) | |
| _ | |___| |___| __/|_|
|_| |_|_|_|_| (_)
bash-2.05b$
Jeremias Maerki writes:
Looks like Christian is right. The proxy probably coughs at Subversion's
special request methods. I've found the FAQ entry in the official SVN
FAQ concerning proxies. Maybe this contains an additional idea how to
solve this. The first step is probably identifying
Jeremias Maerki writes:
AFAIK, noones currently working on that otherwise. Most of the
dispatching of the render*() calls is done in AbstractRenderer. So this
should actually be renderer-independent. But still, there seems to be
something wrong. I'd have to do some debugging myself to find
There seems to be a number of bugs concerning the positioning and
cropping of external SVG images in Fop. In particular, any large
SVG image gets cropped back to the 100x100 viewport defined in
getViewportSize() in SVGUserAgent.java. This seems to fit with
the problems reported against 0.20.5:
Jeremias Maerki writes:
I'll have to take a closer look. I know there are still a few problems
left (I've been working in this area lately). The first step is to
create small test cases [1] to cover all the different possibilities.
There is one related testcase - external-graphic-svg.xml.
Jeremias Maerki writes:
Richard, is there a problem left to be looked at? I'm not sure from
reading your posts.
Yes. The external svg handling is broken. I'll get some new
testcases together at some point to demonstrate the effect. In
the meantime just get two or three large svg images and
Jeremias Maerki writes:
I'm starting now. I've had to rename inline_block_nested_\#36248.xml
to inline_block_nested_bug36248.xml to get the junit task to build.
Unix Which OS?
Linux,
Richard
[EMAIL PROTECTED] writes:
Most of the API finalization proposal is implemented now.
No deprecations, yet, and the image cache and a couple of
nits are not addressed, yet.
I know this is slightly late, but shouldn't the PreviewPanel
interfaces for embedding the viewer be counted as part of
Jeremias Maerki writes:
IMO, no. At least it's not part of the core API. The PreviewPanel is
some sort of an add-on component to FOP which it can theoretically live
without. Someone could maintain that outside the project. Why do you ask?
Just for completeness,
Richard
Hi,
I've been experiencing a couple of problems lately regarding
speed and memory usage when generating some large fop reports
(around 42MB .fo) Having run Hat on the hprof dump and taken
a closer look at the code I see an awful lot of objects which
don't appear to serve any useful purpose. e.g.
Andreas L Delmelle writes:
OTOH, if you feel like investigating further, I personally would be
very interested to see if the properties implementation cannot be
optimized in other ways than simply removing them as members from the
FOs.
I recently mentioned the idea of
Andreas L Delmelle writes:
All the property
classes are supposed to be immutable even though some of them
aren't and
none of them use final members. Is this all correct so far?
True, and this could be much improved, I'd say...
OK. I'll take a look at it. Whilst I'm at it I'll
Hi,
I'm having a few difficulties trying to work out what the
purpose of this is. Why is it necessary to manipulate so
many properties for a text render but not for any other
output format?
Richard
[EMAIL PROTECTED] writes:
http://issues.apache.org/bugzilla/show_bug.cgi?id=41044
Please note, I'm out of the office until 18th December. I'll
take a look at everything then. I've still got some more work
to do and some more patches to submit,
Richard
Andreas L Delmelle writes:
If I remember correctly, that was precisely the problem, since
Cliff's report consists of one giant table. It's supposed to look
like one uninterrupted flow, so figuring out where the page-sequences
should end is next to impossible... (or IOW: sorting that
Manuel Mall writes:
On Wednesday 10 January 2007 03:42, Andreas L Delmelle wrote:
White-space nodes? Could also be an effect of the white-space
collapsing. Long shot, but theoretically, 'white-space-handling' in
FOText means 'replace FOText.ca with a copy minus a few characters',
if
Andreas L Delmelle writes:
I'd say the 80K ArrayLists are simply the childNodes lists of all
those FObj (TableCells and Blocks), and that those are, in most
cases, lists of only one element.
This is correct - for most instances,
Richard
Is there any good reason why CommonBorderPaddingBackground
and BorderInfo are Cloneable yet don't implement a clone()
method? Am I missing something or is this just to confuse
any poor maintainers who happen to come along?
Regards,
Richard
Andreas L Delmelle writes:
log is a protected static, so if the class resides in the same
package, then you can use direct member access. Currently, in some
places, the properties seem to be routing the message to the FO's
logger, instead of using Property.log directly...
Or even
[EMAIL PROTECTED] writes:
(Richard? I'd be very interested to see how many more cells you can process
before running
into an OOMError...)
I'm not dead. I am still paying attention. Life is just hectic atm. I've
still got some more updates to make, including fixing the TXTHandler wrt
the
Andreas L Delmelle writes:
Anyone here going to Amsterdam (or: 'staying there' would be more
fitting for Simon) in May?
Or FOSDEM tomorrow?
Richard
Vincent Hennebert writes:
I fully agree. Good design should not be sacrificed for efficiency.
Anyway only the profiling of a FOP run would give us proper indications
of what is actually eating time and memory, and where we should start
optimizing.
If you apply the the recent patches
Kia Teymourian writes:
I am working on a patch for Arabic/Persian Text decoration and
Implementation of Bidi Algorithm.
Did you ever get anywhere with this? If so, what's the current
status? I'd rather like to see this working and have time to
spend on it if needed,
Regards,
Richard
Hi,
At some point in the past you did some work on getting Apache FOP
to work in Arabic: http://www.anneundsebp.de/fop/fop.html
I'd like to see fully working Arabic (and Farsi) support for FOP
working and am willing to devote some time to getting it done but
don't want to duplicate anyone
Kia Teymourian writes:
If you wish, I can send you this patch via email.
Yes please. If I make any useful changes I'll send them back.
Regards,
Richard
Am I correct in my assumption that the following XSL:FO:
fo:block text-align=left space-after.optimum=15pt
9. This is a simple test of bidi-override.
fo:bidi-override direction=ltr unicode-bidi=bidi-overrideThis text
goes left to right./fo:bidi-override
fo:bidi-override
30 matches
Mail list logo
