On Jul 19, 2007, at 18:01, Chris Bowditch wrote:
Andreas L Delmelle wrote:
If there is anything special about that file, you could always
post it, but I'll try to see if I can reproduce with a simple FO
without special features. If I don't succeed, I might ask you to
post you
On Jul 19, 2007, at 16:10, Manuel Mall wrote:
Now what does not completely sit right with me, is that the
properties are still not accessible on the inline level. Your patch
transfers the keeps to the FOText itself, instead of activating the
property on inline-level FOs.
That said, it obviousl
On Jul 19, 2007, at 16:37, Chris Bowditch wrote:
Hi Chris
I have been doing a little bit of testing with the current Trunk
code and observed that I can generate an OutOfMemoryError simply by
submitting the same 2 page document to FOP to render to Postscript
over and over again. After just
On Jul 19, 2007, at 01:10, Andreas L Delmelle wrote:
Number oneInt = new Integer(1);
Number oneDouble = new Double(1.0);
boolean check = (oneInt.hashCode() != oneDouble.hashCode());
=> (check == true)
Can this be relied upon?
AFAICT, it can.
Integer.hashCode() will simply return
On Jul 19, 2007, at 10:49, Luca Furini wrote:
Hi Luca
Firstly, hi all! It has been quite a long time since I last posted
or committed anything, but I'm still here!. :-)
Then, congratulations for all the great progresses fop is making!
Good to see you're still monitoring. :-)
On Jul 19, 2007, at 13:34, Manuel Mall wrote:
On Thursday 19 July 2007 19:27, Andreas L Delmelle wrote:
On Jul 19, 2007, at 04:06, Manuel Mall wrote:
Sorry Andreas but I still don't get it. We have this test case
This is Blah blah blah blah!
OK, then. Where ?
inline_keep-togethe
On Jul 19, 2007, at 04:06, Manuel Mall wrote:
Sorry Andreas but I still don't get it. We have this test case
This is Blah blah blah blah!
OK, then. Where ?
Cheers
Andreas
On Jul 19, 2007, at 01:31, Manuel Mall wrote:
I don't quite understand what you are trying to say here. The test
case
in question checks the use of keep-together.within-line="always" in
the
context of
Nope. For the sake of completeness, this is the one and only page-
sequence, includin
On Jul 19, 2007, at 01:10, Andreas L Delmelle wrote:
Hmm, made me wonder:
Number oneInt = new Integer(1);
Number oneDouble = new Double(1.0);
boolean check = (oneInt.hashCode() != oneDouble.hashCode());
=> (check == true)
Can this be relied upon?
BTW: the following is perfec
On Jul 18, 2007, at 23:31, Jeremias Maerki wrote:
[Me:]
All we really need to uniquely identify a NumberProperty is the
number-member, I think...
I dont' think that works, since Number doesn't implement hashCode
(), for
example.
Right, but its concrete subclasses in the java.lang packag
On Jul 18, 2007, at 23:18, Jeremias Maerki wrote:
Some additional thoughts before going to bed:
- I think the static synchronized WeakHashMap should be avoided.
There's
a lot of synchronization that is performed. I suspect this will have a
bad effect on performance.
I have always assumed
On Jul 18, 2007, at 22:17, Jeremias Maerki wrote:
So I wanted to play with this really great tool a little more and
ran a
big document which I knew would cause an OutOfMemoryError at 64MB heap
size. Here's what came out:
Interesting figures!
Did you have any chance to run a comparative test
On Jul 18, 2007, at 20:06, [EMAIL PROTECTED] wrote:
Hi Manuel & others
Author: manuel
Date: Wed Jul 18 11:06:09 2007
New Revision: 557347
URL: http://svn.apache.org/viewvc?view=rev&rev=557347
Log:
Added support for keep-togther.within-line="always"
Cool to see this implemented so quickly!
On
On Jul 18, 2007, at 19:38, [EMAIL PROTECTED] wrote:
Hi all
Author: adelmelle
Date: Wed Jul 18 10:37:14 2007
New Revision: 557337
URL: http://svn.apache.org/viewvc?view=rev&rev=557337
Log:
* Javadoc update: use [EMAIL PROTECTED] instead of @see where
applicable, removal of some @author tags
On Jul 18, 2007, at 17:44, Manuel Mall wrote:
Hi Manuel
This proposed patch seems to cause a side-effect I would like a
clarification on. The following fo snippet
some long text
used to have the effect of keeping "some long text" on a single page.
After my patch it would also keep "some lon
On Jul 18, 2007, at 16:07, Jeremias Maerki wrote:
- * @see http://www.ietf.org/rfc/rfc2397";>RFC 2397
+ * @inheritDoc http://www.ietf.org/rfc/rfc2397";>RFC
2397
^
Careful
Sorry, but no need to worry. If the correct [EMAIL PROTECTED] syntax is
used, as V
On Jul 18, 2007, at 14:28, Peter B. West wrote:
Hi Peter
alt-design always cached _all_ the Integer instances it needed.
Another
startling new idea.
FWIW, I did not presume my idea to be startling or new. Just was a
bit bugged by the number of places in the current trunk where
Integer
On Jul 18, 2007, at 11:17, Vincent Hennebert wrote:
Only the trunk. They are not functional changes so don't need to
figure
in the 0.94 release. Only (urgent) bug corrections should be merged in
the branch now.
OK.
BTW, the proper use of inheritDoc seems to be like the following:
/**
On Jul 18, 2007, at 01:20, HLeonardi wrote:
Hi Hugues & others
I have quickly tested auto detection font feature and my results
are at
this page :
http://leohome.free.fr/FOP/tests/fop094.xml.pdf
FWIW, I have taken a closer look at the related test-output myself
here, and I also get a numb
On Jul 17, 2007, at 21:29, [EMAIL PROTECTED] wrote:
Author: adelmelle
Date: Tue Jul 17 12:29:40 2007
New Revision: 557035
URL: http://svn.apache.org/viewvc?view=rev&rev=557035
Log:
Undo changes of r556112
Oops! Some javadoc changes already committed as well...
Well, if no one objects before
On Jul 14, 2007, at 15:59, Vincent Hennebert wrote:
Vincent
Andreas L Delmelle a écrit :
Tested locally, and is OK here. If you'd like, I can run a sanity
diff
later tonight, and commit the changes sometime tomorrow.
Thanks, Andreas. We should perhaps just wait a couple of days, ju
On Jul 16, 2007, at 22:25, J.Pietschmann wrote:
Vincent Hennebert wrote:
Addition of a general-purpose int-to-int map ...
...
This change makes me a bit uneasy. No doubt that this class is clever
and efficient and working, but that's something more to maintain.
Jakarta Commons Collections h
On Jul 16, 2007, at 16:38, Vincent Hennebert wrote:
Hi
This change makes me a bit uneasy. No doubt that this class is clever
and efficient and working, but that's something more to maintain. By
quickly looking at it I couldn't figure out exactly how it is working,
and this is the kind of code t
On Jul 15, 2007, at 14:17, Andreas L Delmelle wrote:
On Jul 14, 2007, at 21:22, Andreas L Delmelle wrote:
On Jul 14, 2007, at 15:59, Vincent Hennebert wrote:
Thanks, Andreas. We should perhaps just wait a couple of days,
just to
be sure everybody's ok with that?
Indeed, let&#
On Jul 14, 2007, at 21:22, Andreas L Delmelle wrote:
On Jul 14, 2007, at 15:59, Vincent Hennebert wrote:
Thanks, Andreas. We should perhaps just wait a couple of days,
just to
be sure everybody's ok with that?
Indeed, let's give everyone a chance to react before committing.
On Jul 14, 2007, at 17:37, Jess Holle wrote:
Andreas L Delmelle wrote:
What we are currently looking for are not large improvements, but
more the elimination of small annoyances, little things that could
mean a great deal to you.
So I suppose auto table-layout is still out of the
On Jul 14, 2007, at 15:59, Vincent Hennebert wrote:
Andreas L Delmelle a écrit :
A script would not even be needed. An editor like jEdit will let
you S&R
every @see with an @inheritDoc for all .java files in the
src/java/org/apache/fop directory and subdirectories...
Tested locally,
On Jul 14, 2007, at 13:27, Vincent Hennebert wrote:
J.Pietschmann a écrit :
Jeremias Maerki wrote:
Yes, inheritDoc would be the right way, as long as we're on Java
1.4.2
and later (feature not available in 1.3, severly buggy in
1.4.0/1.4.1. I
would have switched a long time ago if we weren
On Jul 13, 2007, at 21:16, Andreas L Delmelle wrote:
On Jul 13, 2007, at 15:45, Vincent Hennebert wrote:
I propose the following plan:
- make a list of patches/bugs that we would like to apply/fix before
releasing. Here everyone can help, even non-committers ;-) Once the
list is done we
On Jul 13, 2007, at 15:45, Vincent Hennebert wrote:
Hi Vincent
I'll soon start the release process for XML Graphics Commons. There's
not much to do there, apart from updating the website content.
Meanwhile
I'd like to enter some kind of freezing phase in the FOP area. That
is,
mainly, avoi
On Jul 13, 2007, at 12:09, Vincent Hennebert wrote:
Nothing related with (and against) the original change, but I take
this
one as an opportunity to launch the discussion. I've been having
this in
my head for a while.
Yes, I seem to remember the point being raised earlier... and to be
ho
On Jul 12, 2007, at 21:00, Loran Kary wrote:
I would imagine that support for additional fonts beyond the Base14
would be pretty fundamental to PDF formatting and therefore if it
isn't fully implemented there must be a pretty good reason.
What I do seem to remember is that, when you use emb
On Jul 12, 2007, at 20:12, Loran Kary wrote:
Hi
Perhaps I am posting this question on the wrong list or perhaps my
question has been asked and answered before.
The latter, in a way...
You asked the same question on fop-users a couple of days ago, where
the response was that FOP currently d
On Jul 12, 2007, at 18:17, [EMAIL PROTECTED] wrote:
Hi all
New Revision: 555680
URL: http://svn.apache.org/viewvc?view=rev&rev=555680
Log:
TODO removed: use LayoutContext's stackLimit instead of the
availIPD parameter
Maybe one of the layout-experts should have a look at this to see if
I
On Jul 12, 2007, at 15:49, Vincent Hennebert wrote:
Adrian Cumiskey a écrit :
The junit-layout-standard target seems to broken on trunk...
My bad, sorry. I didn't think of table cells with content of zero
length, which was the root of the problem... I've committed a
temporary
hack as I'm i
Hi all
Just a check to see if anyone knows off-hand how the availIPD.opt
that is passed into Paragraph.startParagraph() in
LineLM.collectInlineKnuthElements() would influence marker-retrieval.
Reason I'm asking is that I noticed the TODO on
collectInlineKnuthElements() to remove the avai
On Jul 9, 2007, at 22:30, J.Pietschmann wrote:
a_l.delmelle wrote in a bugzilla entry:
Hyphenation is, in fact, only applicable to pure alphabetical
characters.
Well, no. The pattern based hyphenator can deal with any Unicode
characters (apart from digits, whitespace and the dot, which have
On Jul 8, 2007, at 22:19, Max Berger wrote:
Hi Max
Now the second issue (and this requires further investigation
first, so it will be for post-0.94) is that the "image" should have
access to its surrounding context, in particular attributes like
foreground-color, font-size, etc.. This is o
On Jul 7, 2007, at 03:11, [EMAIL PROTECTED] wrote:
--- Additional Comments From [EMAIL PROTECTED]
2007-07-06 18:11 ---
Looking again at this patch, and Richard's observations, I'd say it
is worth it. Breaks nothing, and the
benefit seems to become bigger with the number of FOs.
On Jul 7, 2007, at 01:49, [EMAIL PROTECTED] wrote:
Hi all
Author: adelmelle
Date: Fri Jul 6 16:49:30 2007
New Revision: 554092
URL: http://svn.apache.org/viewvc?view=rev&rev=554092
Log:
Removal of unused classes ?
Removed:
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/txt/
TXTFOE
On Jul 5, 2007, at 21:01, [EMAIL PROTECTED] wrote:
Hi all,
Author: adelmelle
Date: Thu Jul 5 12:01:14 2007
New Revision: 553612
URL: http://svn.apache.org/viewvc?view=rev&rev=553612
Log:
Fix for a tiny but very nasty bug...
Stumbled upon this little bug while looking at moving the relative
On Jun 30, 2007, at 03:38, Manuel Mall wrote:
Hi Manuel,
have you considered the case of fo:marker elements where the fonts
available for selection may not be known at fo tree construction time?
Good that you point it out now, since I indeed did not explicitly
consider markers yet.
OTOH,
On Jun 28, 2007, at 18:32, Andreas L Delmelle wrote:
... calls an implementation of FontInfo.fontLookup() that just
returns the first family in the list...
Of course this should be supplemented: "... that is supported in the
current configuration."
On Jun 27, 2007, at 23:31, Jeremias Maerki wrote:
I've noted some things here:
http://wiki.apache.org/xmlgraphics-fop/FontSelectionStrategy
It's best to use that page to gather thoughts and come up with a
plan to
implement that feature.
Sorry, completely missed that Wiki update.
One thing
On Jun 27, 2007, at 20:49, Loran Kary wrote:
Hi,
I see there was a recent thread on fop-user called "Mixing
Languages and Unicode". I have the same problem. The PDFs that I
create with FOP could potentially contain any mix of languages and
no one font will support them all.
I do not be
On Jun 27, 2007, at 19:44, Andreas L Delmelle wrote:
On Jun 26, 2007, at 16:08, [EMAIL PROTECTED] wrote:
... Hopefully I will still get the chance to continue working
on FOP and I intend to take another look at the memory usage patches
asap,
I'm in the process of looking at your patch
On Jun 26, 2007, at 16:08, [EMAIL PROTECTED] wrote:
Hi Richard,
Please note that as of this Friday I will no longer be working at
Geoquip. Any e-mail directed to [EMAIL PROTECTED]
on matters concerning FOP is unlikely to get any meaningful
response. Hopefully I will still get the chance to cont
On Jun 25, 2007, at 11:03, Adrian Cumiskey wrote:
No, Adrian, I haven't forgotten your patch.
The patch has been applied now by Jeremias so don't worry about
this. Good to have you back :-).
So I noticed... a while after I had sent the mail.
Anyway, good to be back.
While catching up, I
On May 21, 2007, at 18:37, [EMAIL PROTECTED] wrote:
Hi Richard,
Am I correct in my assumption that the following XSL:FO:
9. This is a simple test of bidi-override.
This text goes left to right.
This text goes right to left.
Should be rendered as:
9. Th
On Jun 19, 2007, at 02:12, Peter B. West wrote:
Hi Peter & all,
I haven't seen anything from Andreas for some time now, and I was
wondering if anyone had heard from him privately.
Rumors of my death etc. :)
This little message to let everyone know that I'm very much alive and
doing pretty
On Apr 7, 2007, at 08:56, The Web Maestro wrote:
Hi Clay,
It didn't work for me (Mozilla 2.0.0.3; Mac OS X 10.4.9). I want it
to! :-)
Could be a problem with either the browser or the plugin. Works fine
if you use Safari and Adobe Reader 8.
Cheers,
Andreas
On Apr 4, 2007, at 16:42, Adrian Cumiskey wrote:
Hi Adrian / Jeremias,
Speak now or forever hold your peace :-)
This is not very helpful, despite the smiley. Besides, things change.
Your post is the best example of that. Well, maybe I'm missing a joke
not being native English speaking.
I
On Apr 1, 2007, at 16:49, [EMAIL PROTECTED] wrote:
Hi Jay,
Author: jbryant
Date: Sun Apr 1 07:49:12 2007
New Revision: 524603
URL: http://svn.apache.org/viewvc?view=rev&rev=524603
Log:
changes to support named destination
Modified:
xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/flow/Bl
On Mar 30, 2007, at 11:21, Vincent Hennebert wrote:
Hi Vincent,
I have little knowledge of the FO tree construction, so I'll perhaps
make naive questions and remarks. I write them in the hope they will
trigger further thoughts.
That was the general idea. :-)
Besides, people who are not all to
Hi,
Just an idea that popped in my head. I was thinking of the access to
a FONode's properties from the layoutengine, and it became apparent
to me that ATM the approach is not too flexible: each subclass has
its own little set of private instance methods and public accessors.
This makes
On Mar 28, 2007, at 10:25, Vincent Hennebert wrote:
Comparing FO to PDF, my common sense jumps up and says:
"Why do you expect the padding to be retained at page-breaks, when
specifying .conditionality='discard'?"
Precisely because of this notion of "fence".
OK ... and does the notion of a
On Mar 28, 2007, at 13:23, Paul Vinkenoog wrote:
Hi Paul,
org.apache.fop.pdf.PDFGoTo currently has the following position
setters:
public void setYPosition(float yPosition) {
this.yPosition = yPosition;
}
public void setXPosition(int xPosition) {
this.xPosition = (
On Mar 27, 2007, at 10:47, Vincent Hennebert wrote:
Andreas L Delmelle a écrit :
On Mar 26, 2007, at 16:48, Vincent Hennebert wrote:
I'm having a lot of fun playing with border and padding
conditionalities...
Just a sanity check: aren't you confusing padding-* with space-*
On Mar 27, 2007, at 10:32, Vincent Hennebert wrote:
That's why I suspect that for "fixed" the ref-area to be considered
should be the region-area (for paged media), unlike for "absolute"
where
this should be the nearest ancestor ref-area. There won't be any
difference in most cases except
On Mar 26, 2007, at 11:47, [EMAIL PROTECTED] wrote:
If I understand you correctly, what you're saying is that if the
fixed
positioned block's nearest ref-area is not initially visible, then
the
top/left/etc. properties should be taken WRT the region-viewport-
area?
Almost... What I'm sayin
On Mar 26, 2007, at 16:48, Vincent Hennebert wrote:
Hi Vincent,
I'm having a lot of fun playing with border and padding
conditionalities...
I think the padding should actually not be discarded on the second
page.
It would if the corresponding edge were a leading edge in the
region-body's r
On Mar 26, 2007, at 11:31, Vincent Hennebert wrote:
And there is a remaining question raised by Andreas:
[me:]
If the table is broken across several pages and the header shall be
replicated, do
border-before for table and table-column play again in border-
resolution
for the second and fol
On Mar 24, 2007, at 18:44, Jay Bryant wrote:
Hi Jay,
Well, I got the junit tests to work (first time, actually, once I
fixed the issue with XMLUnit).
However, I can't commit my changes. I get the following error
message from SVN:
svn: MKACTIVITY of '/repos/asf/!svn/act/8cd4ce0b-68b0-9b4
On Mar 21, 2007, at 22:06, Jeremias Maerki wrote:
[Me: ]
Seems my proposed fix (bugzilla 41894) goes in the right direction.
I agree.
Only it does not take reference-orientation and/or writing-mode into
account when mapping width/height to ipd/bpd... but that seems to me
currently a part
On Mar 23, 2007, at 13:49, Vincent Hennebert wrote:
We would then have two methods of iterating
over tables: one fast, memory-efficient relying on columns
specifications,
Slight addition: "... relying on column specifications or, if those
are absent, on cells in the first row."
This is en
On Mar 23, 2007, at 18:21, Vincent Hennebert wrote:
[Jeremias: ]
http://www.w3.org/TR/REC-CSS2/tables.html#table-layers answers that.
The
image should help you understand. An example: take the before
border of
the first cell of a table header. The elements that influence the
resolved bo
On Mar 23, 2007, at 18:18, Andreas L Delmelle wrote:
Sorry, only now reading Jeremias' answers, and noticed that I got the
picture wrong here:
- when we break at a grid line, should the entire border appear on
each
page, or the higher half at the bottom of the first page, an
On Mar 23, 2007, at 15:44, Vincent Hennebert wrote:
Table headers and footers:
Or perhaps that the border-before of the table should still be
considered?
I mean, for the first header it would come into play, and
for following headers it also would only if conditionality=retain.
I think I'll go
On Mar 23, 2007, at 11:22, Vincent Hennebert wrote:
Thanks for your perseverance ;-)
You're welcome. :o)
If the nearest ancestor ref-area is not immediately visible, then I
think this implies that the fixed-area's position is definitely not
relative to the viewport you refer to, but to anot
On Mar 22, 2007, at 10:05, Vincent Hennebert wrote:
Hi Vincent,
Well, that's still unclear. The area should be placed like in the
"absolute" model, plus mustn't move WRT the viewport.
In case of a continuous media, what should happen if the
nearest ancestor ref-area doesn't appear yet in the v
On Mar 21, 2007, at 10:42, Vincent Hennebert wrote:
Whatever follows in that second definition is irrelevant wrt
determining the base for percentage values to compute the initial
offset (or IOW: determining which is the nearest ancestor
reference area)
Indeed, you're right. In fact we d
On Mar 20, 2007, at 21:55, Andreas L Delmelle wrote:
On Mar 20, 2007, at 17:47, Chris Bowditch wrote:
Have you actually checked the code to see the difference in
handling between absolute-position="absolute" and absolute-
position="fixed"?
Errm, that would be a no.
On Mar 20, 2007, at 17:47, Chris Bowditch wrote:
Have you actually checked the code to see the difference in
handling between absolute-position="absolute" and absolute-
position="fixed"?
Errm, that would be a no. I've checked: a) the Recommendation and b)
the resulting output.
I never t
On Mar 19, 2007, at 15:49, Vincent Hennebert wrote:
Does that make you feel any sudden urge to shout? ;-) Any thoughts?
Hmm, it would indeed be a bit cheap... :/
Seriously, since we're still looking for a nicer way of separating
end-user info- and error-handling and developer debug-message
Begin forwarded message:
From: Andreas L Delmelle <[EMAIL PROTECTED]>
bidi="embed">
left="16.0%" top="16.0%">
1fo:inline>
So now the 1, 2 and 3 are all inside the outer box, but all at
the top le
On Mar 19, 2007, at 15:01, Vincent Hennebert wrote:
We could mimic the HTML specification to a certain extent, that is:
- if table-columns are specified, they fix the number of columns
and any
row having more columns would be considered erroneous;
- otherwise, I see two possibilities:
-
On Mar 13, 2007, at 14:51, Manuel Mall wrote:
On Tuesday 13 March 2007 17:50, Vincent Hennebert wrote:
That would imply to change almost every LayoutManager to
compute/transfer this information. Quite a bit of work.
Yes, but I think for slightly different reason. The logic (in the case
of li
On Mar 13, 2007, at 12:12, Andrejus Chaliapinas wrote:
Hi Andrejus,
Just wonder if that "svn" suffix in jar name for
xmlgraphics-commons-1.2svn.jar is correct. I could see it under
trunk lib
directory.
I think that previously we had just xmlgraphics-commons-1.1.jar
That's indeed the corre
On Mar 12, 2007, at 17:14, Townsend, Pete wrote:
Hi,
I'm the author of the AFPRenderer at http://afp-
renderer.sourceforge.net/
which was ported across to fop-0.93 by Manuel Mall. It's great to
see if
emerge in the 0.93 release thanks for everyone's effort in getting
this out
and for inclu
On Mar 10, 2007, at 21:16, Andreas L Delmelle wrote:
On Mar 10, 2007, at 21:14, Peter B. West wrote:
Novel idea.
Yeah, I did seem to remember this coming up earlier...
http://marc.theaimsgroup.com/?l=fop-dev&m=105728457029132&w=2
Re-reading this thread, I even realize now tha
On Mar 10, 2007, at 21:14, Peter B. West wrote:
Novel idea.
Yeah, I did seem to remember this coming up earlier...
http://marc.theaimsgroup.com/?l=fop-dev&m=105728457029132&w=2
Cheers,
Andreas
On Mar 10, 2007, at 15:34, Vincent Hennebert wrote:
Thomas Zastrow a écrit :
But I haven't a directory called "gensrc"? I downloaded the SVN-
version
just minutes ago.
This directory contains source files automatically generated during
the
build process. To create it you have to run
On Mar 9, 2007, at 18:35, Vincent Hennebert wrote:
[Me:]
-> bind the PropertyList to the FONode
(= transfer the applicable properties for that particular node-
type
to instance members of the FONode; the PropertyList itself is
only stored by the FOTreeBuilder to use as par
On Mar 8, 2007, at 20:15, Andreas L Delmelle wrote:
Hi Vincent,
On Mar 8, 2007, at 18:29, Vincent Hennebert wrote:
Now, does that picture represent the current code?
For the largest part, yes, I think so.
The only difference is the addArea() part, which currently goes top-
down. It is
On Mar 8, 2007, at 18:29, Vincent Hennebert wrote:
thanks for your inputs. That strengthens a bit the picture I have in
mind. I'm wondering if the following makes any sense:
We would have a list of page-level Knuth elements; some of those
elements would be wrapper around line-level Knuth elemen
On Mar 7, 2007, at 22:49, Simon Pepping wrote:
On Wed, Mar 07, 2007 at 03:58:18PM +0100, Jeremias Maerki wrote:
Grr, I actually changed it but forgot to commit. Thanks for
handling it.
On 07.03.2007 10:42:38 Adrian Cumiskey wrote:
This is a quicky.. Our fop.bat is currently broken, someone
On Mar 7, 2007, at 09:07, Vincent Hennebert wrote:
Hi Vincent,
I have some questions regarding the handling of Position elements. I'm
not familiar with that part of the code yet, and as there is little or
no javadoc for those it's a bit difficult to guess their purposes just
by looking at the c
On Mar 6, 2007, at 18:36, Jay Bryant wrote:
Hi Jay,
I have finished my named destinations project (I've been done for a
couple weeks, actually).
That's good news.
As the new kid on the block, I am leary of just checking it in, but
I gather that that's the normal process.
So, shall I che
On Mar 1, 2007, at 11:00, Andreas L Delmelle wrote:
It seems that our text-layout-algorithm works perfectly well on
small to medium-sized blocks, but there is a slight problem with
the scalability.
Some further follow-up:
Traced it down to the main loop in
On Feb 28, 2007, at 23:38, Andreas L Delmelle wrote:
So, I also tried manually inserting fo:blocks around each scene in
the example, but then bumped into an Exception:
That Exception seems to be related to the "last_even" page-master.
Comment that out, and the alternate vers
Begin forwarded message:
Hi people,
From: Jeremias Maerki <[EMAIL PROTECTED]>
Interesting: a simple FO wrapper around a big preformatted text file.
Still, it's a little scary when 0.20.5 processes this file in one
second
while 0.93 allocates 500MB+ memory for a 250KB file and eventually
d
On Feb 22, 2007, at 12:02, [EMAIL PROTECTED] wrote:
--- Additional Comments From [EMAIL PROTECTED] 2007-02-22
03:02 ---
I had a look at this and the problem has to do with the logic that
keeps track
of the last 'position' generated for an fo. It seems to get it
wrong when a
'lett
On Feb 22, 2007, at 10:38, [EMAIL PROTECTED] wrote:
Hi Richard,
Andreas L Delmelle writes:
Anyone here going to Amsterdam (or: 'staying there' would be more
fitting for Simon) in May?
Or FOSDEM tomorrow?
Wasn't planning on going, but since it's in my backyard, so to s
Anyone here going to Amsterdam (or: 'staying there' would be more
fitting for Simon) in May?
I can make it only on the opening day, since that is a legal holiday
over here, so I have no other obligations interfering with my being
present there this time, as was the case the previous editi
On Feb 21, 2007, at 12:16, [EMAIL PROTECTED] wrote:
[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.
We all know the feeling... Take
On Feb 12, 2007, at 16:12, Vincenzo Mazzeo wrote:
Hi Vincenzo,
Sorry for the late reply. The reason I'm cc'ing fop-dev is because,
while such an extension may turn out not to be necessary, it does
again raise interesting questions. Some of them, I cannot confidently
answer ATM, and I'm hop
On Feb 12, 2007, at 20:02, Andreas L Delmelle wrote:
On Feb 12, 2007, at 18:00, Vincent Hennebert wrote:
So my question is: is there a possibility of creating a tree of FObj
instances from a corresponding FO fragment, and use it to feed
objects
from the layout engine in order to unit test
On Feb 12, 2007, at 18:00, Vincent Hennebert wrote:
Hi Vincent,
I think the codebase is seriously lacking of unit tests, which makes
refactoring a bit hazardous. Of course there is the wonderful
layoutengine testsuite that allows to check if a XSL-FO file is
rendered
as expected (BTW, I don'
On Feb 6, 2007, at 21:03, Jeremias Maerki wrote:
Sorry about that.
No matter. Just checking if I could commit the fix for font-family
names containing spaces.
I'll go right ahead, then.
Cheers,
Andreas
On Feb 3, 2007, at 23:31, [EMAIL PROTECTED] wrote:
Jeremias,
Author: jeremias
Date: Sat Feb 3 14:31:34 2007
New Revision: 503326
URL: http://svn.apache.org/viewvc?view=rev&rev=503326
Log:
Bugzilla #41488:
Fix for NPE with PNG images for RTF output.
Submitted by: Dominic Brügger
Have I ov
301 - 400 of 859 matches
Mail list logo
