On Feb 2, 2007, at 09:51, Jeremias Maerki wrote:
The problem that I'm having is that the Oracle XML parser blows
chunks and
won't properly parse documents in order for FOP to work correctly.
If you look how many more problems Oracle produces than Xerces/
Xalan on
our user mailing list,
On Feb 1, 2007, at 21:53, Koen Heene wrote:
I have the feeling that the image cache doesn't properly reuse the
image (maybe because of the multi threaded environment), holds a lock
on the PNG file and therefore doesn't allow that file to be re-read.
Looking into the code, it seems like clearC
On Jan 24, 2007, at 22:16, Andreas L Delmelle wrote:
On Jan 24, 2007, at 22:10, Nicol Bolas wrote:
If that's true, what is the point of a named destination without a
bookmark?
An anchor point in the document that can be pointed to directly
from outside, so that a browser can jump
On Jan 24, 2007, at 22:10, Nicol Bolas wrote:
If that's true, what is the point of a named destination without a
bookmark?
An anchor point in the document that can be pointed to directly from
outside, so that a browser can jump to it when the named destination
is appended to the base UR
On Jan 24, 2007, at 01:19, Nicol Bolas wrote:
Can't you just use the bookmarking feature of XSL-FO? I mean, isn't
that what
it's there for?
Well, IIRC in PDF there's a clear distinction between bookmarks and
named destinations.
I'm not 100% sure, but I think that every bookmark points
On Jan 24, 2007, at 00:15, Jay Bryant wrote:
Hi Jay,
I spent the afternoon reading the FOP source code and the PDF
specification, and, if I understand things correctly, I need to add
to the catalog. To do that, I thought I'd extend PDFObject to
create an object called PDFDestination and th
On Jan 19, 2007, at 13:11, Adrian Cumiskey wrote:
Hi,
Thanks for the investigation (and the patch).
But this doesn't fix the SERERE error messages ... I am still
learning FO and don't understand all the layout stuff yet so I'm a
little hesitant to go in and try and fix this myself. The e
Hi,
Please check thoroughly if you have stray FOText in your document,
for example text as direct child of the flow...
Your assumption is almost correct, although it doesn't necessarily
mean 'text without block parent', but more general:
If no fo:block is found on the ancestor:: axis, then
On Jan 15, 2007, at 22:20, Andreas L Delmelle wrote:
Not really sure what would be most efficient:
- a void method appending to a parameter StringBuffer
- a method returning a copy of the char[] from index to index...
Seen that every String ultimately has a backing char[](*) anyway,
I&#
On Jan 15, 2007, at 21:25, J.Pietschmann wrote:
Andreas L Delmelle wrote:
BTW: I took a very quick look, and does anyone know if there is a
good reason why Hyphenation.word is a String?
The hyphenator interface goes through several wrapping layers,
probably due to the usual "take wo
On Jan 14, 2007, at 23:11, J.Pietschmann wrote:
Andreas L Delmelle wrote:
The SHY character will be presented to the hyphenator simply as a
character of the word it appears in. The hyphenator should then be
smart enough to recognize this as a special character, and do
something like
On Jan 14, 2007, at 22:51, J.Pietschmann wrote:
Andreas L Delmelle wrote:
Based on Jörgs statistics, I'd say that the number of children
will most likely never reach the level where using direct index-
based access (ArrayList) has its benefits over traversing a tree
of refer
On Jan 13, 2007, at 10:31, Manuel Mall wrote:
Hi Manuel,
Just committed the initial support for the soft hyphen.
Nice job, thanks!
As we had two in favour of having the SHY always produce a break
opportunity and only one against that's the route I took.
I had no luck with giving the SHY a
On Jan 9, 2007, at 15:22, [EMAIL PROTECTED] wrote:
Author: vhennebert
Date: Tue Jan 9 06:21:59 2007
New Revision: 494416
URL: http://svn.apache.org/viewvc?view=rev&rev=494416
Log:
In relaxed validation mode, it should be acceptable to have
fo:table-footer /after/ fo:table-body
Just a littl
On Jan 12, 2007, at 13:00, [EMAIL PROTECTED] wrote:
Just a quick comment on this, given the above stats you might
consider having a single Object field and switch the type of object
from the actual child (when there is a single child) to a List of
children when there are multiple children:
On Jan 11, 2007, at 22:31, J.Pietschmann wrote:
Quite some time ago I did some statistics on number of children
of FOs, using the FOP examples and FO files from bug reports.
The breakdown was roughly the following
~50% no children, mostly FOText nodes and FOs like region-body
and page-numbe
On Jan 11, 2007, at 19:51, [EMAIL PROTECTED] wrote:
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, inste
On Jan 11, 2007, at 13:41, [EMAIL PROTECTED] wrote:
Is there any good reason why CommonBorderPaddingBackground
and BorderInfo are Cloneable yet don't implement a clone()
method?
Wait, let me see... Nope, none at all, it seems. If my method is
correct, that is...
I tried adding an override th
On Jan 11, 2007, at 18:31, Andreas L Delmelle wrote:
... use an instance method to access a protected static member of
the superclass. That's a good one! :-)
And what about:
if (log.isDebugEnabled()) { getLogger().debug("..."); }
unless we were thinking about tying the s
On Jan 11, 2007, at 13:41, [EMAIL PROTECTED] wrote:
In FONode, it say:
//TODO Remove getLogger() method!
Yet everywhere around the code base it says foo.getLogger(),
in particular for FObj instances. What is the preferred way
to aquire a logger instance?
log is a protected static, so if
On Jan 11, 2007, at 10:02, [EMAIL PROTECTED] wrote:
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,
On Jan 10, 2007, at 20:39, Andreas L Delmelle wrote:
On Jan 10, 2007, at 04:50, Manuel Mall wrote:
On Wednesday 10 January 2007 03:42, Andreas L Delmelle wrote:
Property lists themselves are no longer alive in the snapshot, it
seems. I don't suppose they are that much of a problem. The
On Jan 10, 2007, at 04:50, Manuel Mall wrote:
On Wednesday 10 January 2007 03:42, Andreas L Delmelle wrote:
Property lists themselves are no longer alive in the snapshot, it
seems. I don't suppose they are that much of a problem. They are
meant to be in scope for only a very brief int
On Jan 9, 2007, at 18:46, Andreas L Delmelle wrote:
On Jan 9, 2007, at 14:11, Manuel Mall wrote:
What are the 81632 instances of class char[]? I assume this is the
text
in the table cells. But why are there more than twice as many as
there
are table cells?
Hehe, see my little remark
On Jan 9, 2007, at 14:11, Manuel Mall wrote:
What are the 81632 instances of class char[]? I assume this is the
text
in the table cells. But why are there more than twice as many as there
are table cells?
Hehe, see my little remark about the TextLM... In its initialize()
method (I think,
On Jan 5, 2007, at 16:20, Jeremias Maerki wrote:
Adding page breaks will not be enough, BTW. But you already noticed
that.
FOP can currently only release memory at the end of a page-
sequence. So
instead of creating page-breaks, try to restart a new page-
sequence. The
memory usage should dr
On Jan 7, 2007, at 10:34, Manuel Mall wrote:
Hi Manuel,
1) ...some text red text more text ...
Should 'red text' be underlined or not? We currently do underline the
text but I interpret the spec that we should not. Only text-decoration
applied to a block level element propagates to nested
On Jan 3, 2007, at 10:17, Vincent Hennebert wrote:
Hi Vincent,
...
In this case, two implicit columns are created, but the cell's width
is not yet distributed over the two columns.
I'll add a testcase demonstrating what still goes wrong, but the
issue
probably needs to put in a sl
On Dec 27, 2006, at 13:35, Manuel Mall wrote:
Hi,
I have reached a bit of mental block in coming up with a simple design
to solve the following problem and looking for some ideas here:
The UAX#14 line breaking algorithm works fundamentally on pairs on
neighboring characters possibly separated
On Dec 27, 2006, at 12:04, Simon Pepping wrote:
Herewith I start a vote on this release. The vote will end in 72
hours, that is, on Saturday 30 December 2006 at noon UTC.
+1 from me.
Cheers,
Andreas
On Dec 25, 2006, at 10:08, Simon Pepping wrote:
If I am correct, your only patch to the release 0.93 branch concerns
the replacement of a hash map with a weak has map. That is OK.
OK, sorry.
That one I only committed since Jeremias' remark was very right, and
it influences behaviour in produ
On Dec 24, 2006, at 10:56, Andreas L Delmelle wrote:
In the meantime, I've locally patched FOP to correctly deal with this.
Forget it. Too simplistic. After running a few thorough tests,
percentages are still not correctly distributed... :(
Works nicely for FixedLength though.
I
(Sorry for sending this as a new post, but seems my reply didn't come
through again ... *sigh*)
In the meantime, I've locally patched FOP to correctly deal with this.
Patch consists of a few changes in TableBody, TableRow and
PercentLength. The latter only because I needed to have some wa
On Dec 24, 2006, at 09:53, Andreas L Delmelle wrote:
Just had another look, and it currently only works correctly in
case there is no column-spanning going on in any of the cells in
the first row.
...
In this case, two implicit columns are created, but the cell's
width i
Hi all,
Since two replies I sent to Simon's posts seemed to end up in
oblivion, I'll post it as a new message.
Concerns the following issue:
[Simon:]
Uncertain status. The linked bug is resolved, but the description does
not match the description of the bug:
Omitting fo:table-col
Just testing... Seems like a few of my responses never made it to the
list the past couple of days.
On Dec 20, 2006, at 21:10, Andreas L Delmelle wrote:
On Dec 20, 2006, at 20:45, Jeremias Maerki wrote:
I wonder about the effect of that on very long running server
applications producing all kinds of different documents. There's no
chance for freeing instances here if memory is need
On Dec 23, 2006, at 12:33, [EMAIL PROTECTED] wrote:
Hi Simon,
Seems my response to your post yesterday didn't make it to the list
for some reason...
Anyway, this known issue
+
+Omitting fo:table-column or having fo:table-column without
a column-width
+and attemptin
On Dec 22, 2006, at 13:29, Simon Pepping wrote:
Hi Simon,
Uncertain status. The linked bug is resolved, but the description does
not match the description of the bug:
Omitting fo:table-column or having fo:table-column without a
column-width
and attempting to create columns
On Dec 20, 2006, at 20:45, Jeremias Maerki wrote:
I wonder about the effect of that on very long running server
applications producing all kinds of different documents. There's no
chance for freeing instances here if memory is needed. I assume
that in
this case the set of instances will still
Hi all,
Just bumped into this and started wondering: currently FObj.bind()
has public visibility, but it seems that protected would suffice. The
method is only accessed by processNode() (which is already a
protected method), but since it needs to be overridden by subclasses,
it cannot be
On Dec 16, 2006, at 20:17, Vincent Hennebert wrote:
For Fop 0.93 we will have to define what needs to be absolutely
done before releasing. I'm personally in favor of releasing as is
because we can't wait more. It would be great to release before
Christmas but that'll be tight IMO...
IMO
On Dec 7, 2006, at 22:38, J.Pietschmann wrote:
[EMAIL PROTECTED] wrote:
[snip]
Interesting. This reminds me that quite some time ago I
tried to get the text decoration property flyweighted
(still in the maintenance code), there are only 8 possible
values. Unfortunately, it failed to pay off, ap
On Dec 6, 2006, at 20:39, Simon Pepping wrote:
Hi folks,
On Wed, Dec 06, 2006 at 12:19:01PM +0100, Luca Furini wrote:
I agree with you that it would be good to have them configurable.
Your idea is to put them in the configuration file or in the fo file
itself? At the moment, my preference wo
fter the static member variables.
Cheers,
Andreas
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
On Nov 23, 2006, at 12:14, [EMAIL PROTECTED] wrote:
An excellent idea. However, before I go any further with implementing
anything I'd like to make sure that I actually understand what's going
on at the moment and (more importantly) what should be going on.
As I understand it, objects in the f
On Nov 22, 2006, at 15:23, [EMAIL PROTECTED] wrote:
Andrejus,
--- Additional Comments From [EMAIL PROTECTED]
2006-11-22 06:23 ---
(In reply to comment #47)
Don't think SVG is a problem... If you insist on JPEG or GIF,
there's always
Batik to transcode it :)
I'm just trying to f
On Nov 22, 2006, at 13:30, [EMAIL PROTECTED] wrote:
Hi Richard,
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 o
On Nov 15, 2006, at 11:41, Vincent Hennebert wrote:
Hi Vincent,
Just to let you know that I'd like to finish the implementation of the
collapsing border model.
I've started to look at the wiki pages, the code and the mail archives
but if you have any hint about what are the remaining problems t
On Nov 13, 2006, at 11:06, Andrejus Chaliapinas wrote:
I've tested Andreas approach with tables and column numbers/spans
but later
found it as very particular font specific (correct chars per tab
calculation
having in mind possible different text styles is almost equal to
the task of
spac
On Nov 14, 2006, at 16:28, [EMAIL PROTECTED] wrote:
[Christian:]
I'd rather remove it now than between the 0.93 (without beta tag) and
the 1.0 release.
I share that preference.
I agree with Simon and Christian. Better do it right away. Those
still using the deprecated API should change at
On Nov 12, 2006, at 13:25, Jeremias Maerki wrote:
Ok, so you don't just have a simple list of name/value pairs that
happen
to be separated by a tab element. You rather have arbitrary
type-writer-style text. That makes it a lot more complicated, at least
for XSL-FO.
Well, I've already been pl
On Nov 10, 2006, at 20:18, Andrejus Chaliapinas wrote:
That would be the
case if you needed different tab-stops for different lines. In the
example the tab-stops are all the same
My sample was just the easiest one to get your thoughts on it. But in
general case I really need to have different
On Nov 9, 2006, at 10:31, Jeremias Maerki wrote:
Hi Andrejus / Jeremias,
Besides that I think it would be rather difficult to implement. I'd
rather not introduce tab stops in FOP. But I don't know what the
others
think.
Seems quite awkward to me as well, and only really feasible in case
On Oct 10, 2006, at 22:25, J.Pietschmann wrote:
Andreas L Delmelle wrote:
I was thinking to use an approach analogous to the current
refinement white-space handling: one BidiProcessor stored in the
FOEventHandler.
This may have inindented consequences: some output formats expect the
On Oct 10, 2006, at 07:21, Manuel Mall wrote:
Jeremias already responded to you and my comments go in the same
direction. Firstly, its great that you want to look at this aspect. I
did investigate support for UAX#14 Unicode compliant line breaking
over
a year ago.
FWIW: a few months ago, I
On Oct 8, 2006, at 18:15, The Web Maestro wrote:
Hi Jeremias / Clay,
I suspect we need additional moderators. I've been having some
issues which have been taking a lot of my time.
If this is necessary, I'll gladly volunteer for taking some of the
load off your backs.
I'll have a look at
On Sep 2, 2006, at 11:59, [EMAIL PROTECTED] wrote:
Author: manuel
Date: Sat Sep 2 02:59:41 2006
New Revision: 439568
URL: http://svn.apache.org/viewvc?rev=439568&view=rev
Log:
Trivial change to testcase to avoid 800+ warning messages
Oops! Sorry about that... I noticed it as well, and meant
On Sep 1, 2006, at 14:45, Jeremias Maerki wrote:
I got the idea while debugging the behavior when processing the
disabled testcase 'page-breaking_4.xml'.
Notice that the FlowLM's getNextKnuthElements() is currently only
called once, which triggers line-breaking for the entire page-
sequence giv
On Aug 31, 2006, at 17:44, Jeremias Maerki wrote:
Would it be ok for everybody if I placed the newly-created FOP poster
under src/documentation/poster? I mean the sources, of course. We
could
also place a web-optimized PDF (i.e. without 1MB output profile) on
the
FOP website.
+1 from me.
On Aug 31, 2006, at 20:59, Jeremias Maerki wrote:
Yeah, it was a lot, wasn't it? :)
Actually, I was preparing the post myself as yours came in, so I
decided to c&p it into a reply, since it did seem to address the same
basic issue: interaction between line- and page-breaking.
What I can de
On Aug 31, 2006, at 17:04, Jeremias Maerki wrote:
Hi Jeremias,
I'm investigating what would be necessary to implement hyphenation-
keep.
After some thought, I think this is one of those very mean properties
that fire back from page-breaking back into line-breaking. IOW,
when you
detect a pa
On Aug 30, 2006, at 10:24, Chris Bowditch wrote:
Uhm, just looking more closely at the change you've made here.
Shouldn't FOP also look for the same family but with default
weight AND style before trying any family.
Yep, that's one situation I overlooked. Added in the meantime.
Thanks
On Aug 29, 2006, at 23:42, [EMAIL PROTECTED] wrote:
Author: adelmelle
Date: Tue Aug 29 14:42:54 2006
New Revision: 438235
URL: http://svn.apache.org/viewvc?rev=438235&view=rev
Log:
Some javadoc improvements
In the interest of facilitating maintenance... I hope :/
If the docs remain unclear in
On Aug 29, 2006, at 20:54, Vincent Hennebert wrote:
Thanks for your support, guys. I've made some progress since last
week, but there are still some bugs well hidden here and there, and
unexpected behaviors (but also some improvements, phew).
I know the feeling... I guess the other devs know i
On Aug 28, 2006, at 00:39, Jeremias Maerki wrote:
I've finally finished (more or less anyway) the poster I plan to
put up
at OpenExpo on 2006-09-20. I'd appreciate if someone could take a
quick
peek and tell me if it's looking too ugly
Not at all, looks really good!
or if there are any s
On Aug 25, 2006, at 20:33, Simon Pepping wrote:
On Thu, Aug 24, 2006 at 08:32:03PM -, [EMAIL PROTECTED] wrote:
I prefer a separate commit per issue.
Preference noted. I'll try to keep an eye on it.
Cheers,
Andreas
On Aug 25, 2006, at 03:07, Andreas L Delmelle wrote:
Rough sketch:
Page-breaking initializes first, and prefetches say five blank pages.
From these it constructs one long context, call it one big page --
or better: one region-body--, with ipd changes at a known set of
coordinates.
This
On Aug 24, 2006, at 21:01, Simon Pepping wrote:
On Thu, Aug 24, 2006 at 12:40:25PM +0200, Andreas L Delmelle wrote:
This could actually be done in a single thread, chopping the process
up into discrete parts, and bouncing control from (a) to (b) to (c)
and back.
Implementing this with multiple
On Aug 24, 2006, at 19:45, Andreas L Delmelle wrote:
On Aug 24, 2006, at 15:08, Chris Bowditch wrote:
Hi Chris,
Well I'm not sure if its one of your recent changes thats to
blame, but I've just noticed that simple tables (test file
attached) appear to be issuing a SEVERE mess
On Aug 24, 2006, at 15:08, Chris Bowditch wrote:
Hi Chris,
Well I'm not sure if its one of your recent changes thats to blame,
but I've just noticed that simple tables (test file attached)
appear to be issuing a SEVERE message to the log, i.e.
24-Aug-2006 14:04:41 org.apache.fop.datatype
On Aug 23, 2006, at 21:59, Andreas L Delmelle wrote:
The other consideration, but that would be for a more distant
future, is to be able to have three different threads:
- fo creation (a)
- base layoutengine initialization (b)
- actual breaking/layout (c)
A bit more elaboration:
This
On Aug 24, 2006, at 02:39, Patrick Paul wrote:
Andreas L Delmelle wrote:
A more correct approach --a matter of taste?-- would be for the
TableContentLM to 'collect' the accumulated list of its
descendant LMs, perform the min/max-width calculation, update the
LayoutContext,
On Aug 23, 2006, at 21:16, Patrick Paul wrote:
Simon Pepping wrote:
On Tue, Aug 22, 2006 at 11:35:12PM +0200, Andreas L Delmelle wrote:
I've been doing some thinking myself about the separation
between element-list creation and actual line-breaking, and went
wandering throug
On Aug 23, 2006, at 20:16, Patrick Paul wrote:
You are right. Thanks for the suggestion. I would even say that
"determine" is misleading since the min and max content widths are
calculated when getNextKnuthElements is called. So it maybe it
would be better to name it getMinMaxContentWidth
On Aug 23, 2006, at 17:44, Patrick Paul wrote:
Why not keep getNextKnuthElements() wich does the line breaking
depending on a boolean switch ? Then depending on wether the
element list already exists, the (modified) collectKnuthElements()
method is called.
FTM, such a boolean switch w
On Aug 23, 2006, at 02:10, [EMAIL PROTECTED] wrote:
Author: adelmelle
Date: Tue Aug 22 17:10:20 2006
New Revision: 433810
URL: http://svn.apache.org/viewvc?rev=433810&view=rev
Log:
Cleanup: removal of suspicious static in FOText
Finally went ahead with this one as well. Up to now, I was a bit
Hi all,
I've been doing some thinking myself about the separation between
element-list creation and actual line-breaking, and went wandering
through the related sources. Just checking here if my initial
estimates are correct.
At first glance, a possible separation seems already prepared
On Aug 22, 2006, at 18:13, Vincent Hennebert wrote:
Hi Vincent,
Ok, I'll need a couple of additional days to finish this work.
Don't worry. Even if the patch didn't get finished before the end of
GSoC, your Wiki is already quite a piece of work (as I'm sure your
eventual patch will be).
On Aug 21, 2006, at 23:08, Patrick Paul wrote:
Maybe I missed something, or should I be updating the colWidths
ArrayList rather than widths of the columns directly?
Correct. Feel free to add accessors if that simplifies your work.
I decided to separate the widths from the columns, so in a
Begin forwarded message:
From: [EMAIL PROTECTED]
URL: http://svn.apache.org/viewvc?rev=433291&view=rev
Log:
Rework of default column-creation and setting column-widths from
the first row (fixes Bugzilla 35656)
For Patrick, only this tiny bit changes:
The following part is moved from TableL
On Aug 17, 2006, at 23:54, Andreas L Delmelle wrote:
Hi all,
That default column gets the initial/default value for column-
width, which is defined in FOPropertyMapping as 'proportional-
column-width(1)'...
Somehow this needs to be revised, I think, as the Rec considers
this an
Hi guys,
First of all --for those of you who noticed ;)
Mucked up my setup here, and was testing a different version than the
one I was changing and committing from, so my apologies for breaking
the build :(
OTOH, the tests that currently wouldn't pass, all have the following
in common:
On Aug 17, 2006, at 14:02, Jeremias Maerki wrote:
Please update the commit message of revision 432201 to reflect that
following the pattern I've always used:
Bugzilla #.:
Submitted By:
Sorry. Will keep an eye on it for later commits.
For now, I saw I forgot to commit status.xml anyway.
On Aug 16, 2006, at 00:49, Reed, Gary wrote:
Thanks Andreas.
It's not a problem with the style sheet. MS Word creates the empty
list.
Yes it is :)
If it is producing list-item-labels without content --at least an
empty block would suffice-- then the stylesheet should be altered. It
is r
On Aug 16, 2006, at 00:03, Reed, Gary wrote:
Hi,
To get around this I modified the endOfNode() method in
org.apache.fop.fo.flow.AbstractListItemPart to only throw this
exception
if strict validation is configured:
Does anyone see a problem with this?
Not an immediate problem, but the
On Aug 9, 2006, at 22:32, Jeremias Maerki wrote:
Now, if we can free some objects even sooner FOP might even handle
files
like the one from Luis Ferro with under 256MB one day. For that we'll
need to know reliably when an FO is completely processed (including
area
generation). That's somet
On Aug 10, 2006, at 17:47, Jeremias Maerki wrote:
I could imagine properties like orphan-height and widow-height on
fo:table and fo:list-block for that purpose.
That indeed sounds like a job for extension properties.
I have always wondered what would need to be done to implement an
arbitra
On Aug 10, 2006, at 20:10, Andreas L Delmelle wrote:
(continuing on dev, since this is becoming less-and-less user-
related :))
I was just wondering what the correct output would be if:
...
Empty pages in between? If so, how many?
FWIW: I think the answer is no empty pages. The break
On Aug 9, 2006, at 22:32, Jeremias Maerki wrote:
Thank you, Karthik! That's very helpful information. Looks like
another
little change making a huge difference. Cool!
Now, if we can free some objects even sooner FOP might even handle
files
like the one from Luis Ferro with under 256MB one
On Aug 8, 2006, at 11:10, Jeremias Maerki wrote:
I agree with the interpretation. I just wonder whether a normal
user will
get it. Hmm.
Yeah, and taking into account that quite a lot of people forget to
remove the indent attribute from xsl:output once they know the FO to
be generated cor
On Aug 8, 2006, at 17:26, [EMAIL PROTECTED] wrote:
Author: adelmelle
Date: Tue Aug 8 08:26:54 2006
New Revision: 429689
Sorry, wrong version :(
Will be back shortly with the correct modifications.
On Aug 8, 2006, at 11:22, Jeremias Maerki wrote:
I think that should work. Please commit.
Done. FYI: not to get all your hopes up, but I still have those
modifications WRT table-borders --collapsing borders-- in the
pipeline. Should be ready to test quite soon now...
Later,
Andreas
One for Jeremias, I guess... Just browsing through a global diff I
made, trying to iron out some minor differences between the
repository and my local sandbox.
In TableContentLayoutManager, there's a small remark about the
possibility of re-using the TableStepper. Upon reading that, I tri
On Aug 7, 2006, at 13:23, Manuel Mall wrote:
On Monday 07 August 2006 18:33, Chris Bowditch wrote:
Surely this rule in the spec means first non-whitespace only node???
In any case, this is how FOP should behave IMO.
I am not so sure here. If this is illegal:
Some text before the marker
On Aug 6, 2006, at 20:24, [EMAIL PROTECTED] wrote:
Author: adelmelle
Date: Sun Aug 6 11:23:59 2006
New Revision: 429168
URL: http://svn.apache.org/viewvc?rev=429168&view=rev
Log:
Rework of the marker/retrieve-marker implementation to cater for
correct evaluation of percentages and relative
I discovered the following in our testcase 'marker_font-size.xml'
First marker with small font
According to the Rec, a marker must be an initial child of its
parent, but the above generates a FOText child node for which
willCreateArea() returns true, hence FObj.addMa
Hi people,
Simply a FYI to let you all know that I'm still working on marker
property resolution, which is just taking a little longer than I had
anticipated... :(
AFAICT, currently all properties are all handled nicely and evaluated
correctly --including percentage values and 'em' value
On Aug 3, 2006, at 18:59, Jeremias Maerki wrote:
I went looking and found that the fix is actually very easy: Just make
sure a page-sequences FO children are unreferenced when a page-
sequence
is done. The PageSequenceLM is properly disposed by the
AreaTreeHandler
so at least the LMs were al
On Aug 1, 2006, at 20:29, Andreas L Delmelle wrote:
On Aug 1, 2006, at 20:06, Andreas L Delmelle wrote:
Again answering my own question/remark here:
Oops, sorry for the noise. Totally overlooked the outer block-
container... :(
401 - 500 of 859 matches
Mail list logo
