RE: [VOTE] Move all hyphenation patterns to offo.sourceforge.net

2005-03-18 Thread Andreas L. Delmelle
-Original Message- From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED] snip / As for the build targets: so we don't remove these, but it seems we definitely could/should tweak these to accomodate the creation of the JAR that will be offered through OFFO, What I did so far (locally

RE: [VOTE] Move all hyphenation patterns to offo.sourceforge.net

2005-03-18 Thread Andreas L. Delmelle
-Original Message- From: Chris Bowditch [mailto:[EMAIL PROTECTED] Andreas L. Delmelle wrote: snip/ Have the scripts --.bat and .sh-- append '${FOP_HOME}/build/fop-hyph.jar' to the local CLASSPATH. I'm not too sure about the location here: is 'build' OK, or should we dump

RE: [VOTE] Move all hyphenation patterns to offo.sourceforge.net

2005-03-19 Thread Andreas L. Delmelle
-Original Message- From: Simon Pepping [mailto:[EMAIL PROTECTED] When the jar is built by ant it should end up as '${FOP_HOME}/build/fop-hyph.jar'. When it is downloaded from elsewhere, '${FOP_HOME}/lib/fop-hyph.jar' would be a good place. All jars in lib are added to the classpath

RE: Updated OFFO 'site'

2005-03-21 Thread Andreas L. Delmelle
-Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Yes, that's ok. Just do it (TM). :-) It's only the non-inline level layout managers that I'd like to put under a certain amount of protection. Everything else can be changed at will. Done... well, everything except

RE: [VOTE] Batik and FOP to migrate from CVS to Subversion

2005-03-22 Thread Andreas L. Delmelle
-Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Goo oway and bekome a Teecher. Yea... To offer an alternative: Glen, translate Jeremias' proposal in both German and Rheto-Romanic without spelling or grammar mistakes. +1 on the vote Greetz, Andreas

RE: [VOTE] Batik and FOP to migrate from CVS to Subversion

2005-03-22 Thread Andreas L. Delmelle
-Original Message- From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED] -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Goo oway and bekome a Teecher. Yea... To offer an alternative: Glen, translate Jeremias' proposal in both I know, I know

RE: Creating combined element lists for a table row from cell element lists

2005-03-26 Thread Andreas L. Delmelle
-Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] snip / I haven't understood everything you wrote, yet. I think there's a spark of an idea in there but ATM I can't get hold of it. I'd appreciate if you could look at the current table layout code. Just did. The

RE: [VOTE] Release Transcoders

2005-03-29 Thread Andreas L. Delmelle
-Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] ... I'm now calling for a formal vote for a release of our transcoders. The only thing we do is tag CVS HEAD, ... (Seems I overlooked this one...) +1 Cheers, Andreas

RE: two more class renamings

2005-04-05 Thread Andreas L. Delmelle
-Original Message- From: Glen Mazza [mailto:[EMAIL PROTECTED] Hi, I see two LM classes that appear misnamed, which can cause confusion as to their purpose: 1.) FlowLayoutManager is defined as the layout manager for an fo:flow object -- but actually it can also be for an

RE: Some doubts about lists

2005-04-14 Thread Andreas L. Delmelle
-Original Message- From: Luca Furini [mailto:[EMAIL PROTECTED] Hi Luca, Working on lists, I found a couple of paragraphs in the recommendation whose meaning is not fully clear to me. Section 6.8.3. (fo:list-item) states that: the block-progression-dimension of the

RE: Some doubts about lists

2005-04-16 Thread Andreas L. Delmelle
-Original Message- From: Luca Furini [mailto:[EMAIL PROTECTED] Andreas L. Delmelle wrote: IIC, what is meant is: the space-* of the contained blocks should be seen as _content_ of the list-item, such that they are not ignored, but their values are _included_ in the total BPD

RE: Problems with break conditions and empty pages

2005-04-21 Thread Andreas L. Delmelle
-Original Message- From: Luca Furini [mailto:[EMAIL PROTECTED] Hi, It seems there is a bug affecting the creation of the right kind of page for documents containing blocks with break-* = odd-page or even-page. snip / I think this could depend on the conditions tested in the

RE: Problems with break conditions and empty pages

2005-04-21 Thread Andreas L. Delmelle
-Original Message- From: Glen Mazza [mailto:[EMAIL PROTECTED] Hi Glen, Also, as food for thought, I wonder if the two methods Luca has mentioned should eventually be in FlowLayoutManager (FLM) instead. The break properties appear relevant only for fo:flow descendants.

RE: Problems with break conditions and empty pages

2005-04-21 Thread Andreas L. Delmelle
-Original Message- From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED] snip / I also tried two fo:blocks, first one with break-after=even-page and the second with break-before=even-page, and I don't know exactly what the result is supposed to be, but IIC, if the first block ends

RE: Problems with break conditions and empty pages

2005-04-21 Thread Andreas L. Delmelle
-Original Message- From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED] snip / Also, a break-before=page on the very first block in the document seems to be ignored. Is that correct behaviour? After consulting the Rec, I'm still a bit confused, but I'm beginning to think

RE: Problems with break conditions and empty pages

2005-04-23 Thread Andreas L. Delmelle
-Original Message- From: Glen Mazza [mailto:[EMAIL PROTECTED] --- Luca Furini [EMAIL PROTECTED] wrote: My first impression is that I would find somewhat strange that the *page* breaking is not in the *Page*SequenceLM! :-) Well, under our current philosophy, our LM's map

RE: Problems with break conditions and empty pages

2005-04-22 Thread Andreas L. Delmelle
-Original Message- From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED] snip / Would we need a 'check' on whether the previous page already contains areas generated by elements of a given BlockSequence (or: whether the first area on curPage is also the first area generated

RE: break-before/break-after functioning?

2005-04-22 Thread Andreas L. Delmelle
-Original Message- From: Alex Milowski [mailto:[EMAIL PROTECTED] Hi, I've just recently checked out the current CVS tree and built FOP. It doesn't seem to be handling the break-before/break-after properties with the value 'page' at all. Yep! We're currently working precisely at

RE: break-before/break-after functioning?

2005-04-22 Thread Andreas L. Delmelle
-Original Message- From: Alex Milowski [mailto:[EMAIL PROTECTED] Hi, Is there a list of the different code branches somewhere? One very quick way to get all the branches is ViewCVS: http://cvs.apache.org/viewcvs.cgi/xml-fop/ Then at the bottom of the page, you have a drop-down

RE: Problems with break conditions and empty pages

2005-04-22 Thread Andreas L. Delmelle
-Original Message- From: Luca Furini [mailto:[EMAIL PROTECTED] Hi, snip / I don't know if the methods could be moved to the FLM: besides the break value, they depend on the current page number and this is known only by the PageSequenceLM. Yeah, it was just a thought... I assumed

RE: Problems with break conditions and empty pages

2005-04-25 Thread Andreas L. Delmelle
-Original Message- From: Glen Mazza [mailto:[EMAIL PROTECTED] Hi Glen, (Apologies in advance if the post seems a bit long; really don't mean to bore you ;-) ) snip / With an FLM-centric approach, what I'm seeing is something like either of these two: (pseudocode) a) Within

RE: Problems with break conditions and empty pages

2005-04-25 Thread Andreas L. Delmelle
-Original Message- From: Glen Mazza [mailto:[EMAIL PROTECTED] snip / I was thinking of the FLM controlling layout for *all* the FO descendants of the fo:flow. One and only one FLM instance for the fo:flow of an fo:page-sequence. OK, clear now and fully agreed on this. It returns

RE: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr AbstractBreaker.java PageSequenceLayoutManager.java

2005-04-26 Thread Andreas L. Delmelle
-Original Message- From: Glen Mazza [mailto:[EMAIL PROTECTED] --- [EMAIL PROTECTED] wrote: -protected void startPart(BlockSequence list) { +protected void startPart(BlockSequence list, int localPageNumber) { boolean isFirstPageByBlock is probably better. The

RE: More table borders

2005-04-27 Thread Andreas L. Delmelle
-Original Message- From: Luca Furini [mailto:[EMAIL PROTECTED] Jeremias Maerki wrote: I'm a bit concerned about the increasing complexity of this. It takes considerable time just to understand and play through all these examples and after that implementing it so that the code

RE: Collapsing border model

2005-05-03 Thread Andreas L. Delmelle
-Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Hi, snip / BTW: Am I the only one who has trouble viewing the pictures on the wiki page? (It seems to be the only one with which I have problems. The other table-related pages show up nicely...) That also means that

RE: Collapsing border model

2005-05-04 Thread Andreas L. Delmelle
-Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] I've attached the picture and an FO file I wrote today to mimic that picture. Apologies. Damn *me* now for not having tried this with a decent browser... of course IE will let you down. More feedback probably

RE: More table borders

2005-05-04 Thread Andreas L. Delmelle
-Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] On 27.04.2005 18:28:55 Andreas L. Delmelle wrote: snip / BTW: Does this problem pose itself only if a single cell or row spans more than two pages, or also when an entire row-group does so? Possibly, yes. A row

RE: iStartOn = break-before?

2005-05-05 Thread Andreas L. Delmelle
-Original Message- From: Glen Mazza [mailto:[EMAIL PROTECTED] Hi, The AbstractBreaker.BlockSequence has an iStartOn property, that from looking at PSLM, quite possibly just means the break-before trait. Are they synonyms? Not really. I seem to agree with Jeremias here, in that

RE: Collapsing border model

2005-05-06 Thread Andreas L. Delmelle
-Original Message- From: Simon Pepping [mailto:[EMAIL PROTECTED] Hi Simon, At first sight I agree with Andreas' interpretation in his reply to this message, which I think is the same as your original interpretation. Thinking on, however, I see that there may be a problem with

RE: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr PageSequenceLayoutManager.java

2005-05-06 Thread Andreas L. Delmelle
-Original Message- From: Chris Bowditch [mailto:[EMAIL PROTECTED] Hi Chris, Let me have a go... Glen Mazza wrote: Kein Problem. Bald werde ich dass machen, aber nicht dieser Nacht, weil ich ziemlich muede bin. No prob. I'll do it soon, but not tonight, because I'm quite

RE: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr PageSequenceLayoutManager.java

2005-05-06 Thread Andreas L. Delmelle
-Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Glen: Ja, jetzt sollen wir das alterer Kodierung (pNFA() usw.) entfernen. ... English: Yes, we should remove the old code now. Of course 'should', got my modal verbs mixed up again :-) Greetz, Andreas

RE: Would you please remove my email from this list?

2005-05-07 Thread Andreas L. Delmelle
-Original Message- From: Jerry [mailto:[EMAIL PROTECTED] Hi, Would you please remove my email from this list? because I am not actively participate in this forum. An empty message to '[EMAIL PROTECTED]' should do it... Cheers, AD

RE: Incomplete FOP-Sources?

2005-05-09 Thread Andreas L. Delmelle
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Hi, i've downloaded the FOP-Sources 0.20.5. But it seems, that some Java-Files are not included e.g. within the package org.apache.fop.fo.properties. Am i right? Yes... and no --seems to become one of my favourite

RE: [VOTE] Merge Knuth branch back into HEAD

2005-05-10 Thread Andreas L. Delmelle
-Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] On 10.05.2005 20:41:19 Simon Pepping wrote: Hi guys, For starters: my vote is +1. I agree with Simon, and also very much feel like we're on the right track with this. Sure, it will *still* take some work... snip /

RE: [VOTE] Merge Knuth branch back into HEAD

2005-05-12 Thread Andreas L. Delmelle
-Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Hi, snip / Hmm, I think you got the wrong impression. It's not that I'm having problems with the border resolution. This actually works fine by now even if it might need some additional tweaking for calculating new

RE: Footnotes working!

2005-05-17 Thread Andreas L. Delmelle
-Original Message- From: Luca Furini [mailto:[EMAIL PROTECTED] Hi Luca, First of all: compliments on yet another Nice Job! At the moment the page breaking algorithm is quite strict: it tries to insert every footnote in the same page where their citation is (the last footnote body

More collapsing borders... (RE: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr/table TableContentLayoutManager.java)

2005-05-17 Thread Andreas L. Delmelle
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Hi Jeremias and others interested in table-borders, (Sorry for the --again-- long post, but...) The following comment in the code (TCLM) got me wondering... //Create empty grid units to hold resolved borders of

RE: More collapsing borders... (RE: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr/table TableContentLayoutManager.java)

2005-05-19 Thread Andreas L. Delmelle
-Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Hi, (OK, apologies for my alias turning up... Completely unintended. here's the remainder of the response. Other comments, much longer than the previous one...) On 17.05.2005 23:24:55 Andreas L. Delmelle wrote

OT: Moving to UK? (RE: Foray's font subsystem for Fop)

2005-06-15 Thread Andreas L. Delmelle
-Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED] Hi Peter, ..., and Jenni and I are moving to the UK for 12 months at the end of June, ... Well, if you have plans to cross the channel and visit Belgium during those 12 months, be sure to drop me a line. Maybe we can

RE: fox in CVS?

2005-06-20 Thread Andreas L. Delmelle
-Original Message- From: Carson Reynolds [mailto:[EMAIL PROTECTED] Hi, I have been experimenting with the CVS version of fop, in an attempt to make some more sane figure caption behavior (below the figure, keep-with next). I've had no problems checking out the root and building

RE: [IMPORTANT] FOP and Batik loaded into test repository for verification

2005-06-22 Thread Andreas L. Delmelle
-Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Hi, Did a simple 'svn co' and subsequent build: zero problems here. Saw Simon correctly being mentioned as the last author. But... Please verify that everything is as expected by checking out your project from SVN.

RE: problem with identity comparison in types inheriting from org.apache.fop.fo.FONode

2005-06-26 Thread Andreas L. Delmelle
-Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Committers, I don't see a problem with what Nils proposes. Does anyone else? If not, I can do the change next week. If Nils already has a patch for us, even better. :-) Well, the whole idea behind using interned

RE: problem with identity comparison in types inheriting from org.apache.fop.fo.FONode

2005-06-26 Thread Andreas L. Delmelle
-Original Message- From: Glen Mazza [mailto:[EMAIL PROTECTED] Hi Glen, snip / Another option: validateChildNode() is called from only one place, FOTreeBuilder.startElement(). At that point, we can also feed vcN() the parameter namespaceURI.intern() instead of just namespaceURI.

RE: problem with identity comparison in types inheriting from org.apache.fop.fo.FONode

2005-06-26 Thread Andreas L. Delmelle
-Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Hi, Glen is right. java.lang.String.equals() checks == as the first statement. So this change shouldn't have a big impact on performance. It' just an additional method call (which might even be inlined by the JIT).

RE: svn commit: r201864 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo: ./ flow/ pagination/ pagination/bookmarks/

2005-06-26 Thread Andreas L. Delmelle
-Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Hi, ... So I believe Nils proposed change doesn't have any negative effects, especially since we don't seem to have pursued a more widespread use of String.intern() back when it was discussed in December 2003

RE: svn commit: r201864 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo: ./ flow/ pagination/ pagination/bookmarks/

2005-06-26 Thread Andreas L. Delmelle
-Original Message- From: Glen Mazza [mailto:[EMAIL PROTECTED] snip / Oh no, it wasn't--but we know the status quo *wasn't* acceptable, and that the performance argument was no longer valid because of the research you did on .equals(). Now you and Andreas can finish out the

RE: svn commit: r201864 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo: ./ flow/ pagination/ pagination/bookmarks/

2005-06-27 Thread Andreas L. Delmelle
-Original Message- From: Finn Bock [mailto:[EMAIL PROTECTED] snip / But since == *is* faster then .equals and I think we can assume that most URIs are in fact from the FO namespace we can get the benefit from both. Measured with jdk1.4.2_02 on winXP: Equal string == 141

RE: svn commit: r201864 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo: ./ flow/ pagination/ pagination/bookmarks/

2005-06-27 Thread Andreas L. Delmelle
-Original Message- From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED] -Original Message- From: Finn Bock [mailto:[EMAIL PROTECTED] snip / But since == *is* faster then .equals and I think we can assume that most URIs are in fact from the FO namespace we can get

Re: Element list generation for tables (special case)

2005-07-27 Thread Andreas L Delmelle
On Jul 27, 2005, at 20:45, Jeremias Maerki wrote: Hi, I got a test case for tables which raises not a technical but rather a interesting conceptual question. Please have a look at the attached test case. It defines a table with two columns and two rows. In the given setup the second row

Re: Element list generation for tables (special case)

2005-07-27 Thread Andreas L Delmelle
Sorry, forgot the attachment... table-body4b.xml.head.pdf Description: Adobe PDF document On Jul 27, 2005, at 23:26, Andreas L Delmelle wrote: On Jul 27, 2005, at 20:45, Jeremias Maerki wrote: Hi, I got a test case for tables which raises not a technical but rather a interesting

Re: Element list generation for tables (special case)

2005-07-28 Thread Andreas L Delmelle
On Jul 28, 2005, at 10:10, Jeremias Maerki wrote: On 27.07.2005 23:26:48 Andreas L Delmelle wrote: Indeed, doesn't look right. Given the value for the orphans property, one still would reasonably expect the break to occur before the first cell of the second row. ...or after the first 3 lines

Re: Element list generation for tables (special case)

2005-07-29 Thread Andreas L Delmelle
On Jul 28, 2005, at 14:04, Jeremias Maerki wrote: On 28.07.2005 13:42:08 Andreas L Delmelle wrote: Where it comes to rowspans: In my modified example, if you move all the text in the middle column to the first row and make that cell span two rows, things get a bit awkward without the proposed

Re: Element list generation for tables (special case)

2005-07-30 Thread Andreas L Delmelle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jul 29, 2005, at 23:25, Jeremias Maerki wrote: Strike that. Just found a mean case where my quick hack breaks. Back to frame one and a half. It's going to be a bit more difficult. FWIW: It occurred to me that, with a break-before=page on the

Re: Element list generation for tables (special case)

2005-07-30 Thread Andreas L Delmelle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jul 30, 2005, at 11:51, Jeremias Maerki wrote: D'oh, right. :-) Lucky me. Too bad, we don't generate validation warnings for misplaced non-inherited properties. Didn't we have that discussion already this year? I can't find it or am I imagining

Re: DO NOT REPLY [Bug 35939] New: - [PATCH] Port of 0.20.5 Driver.java class

2005-07-31 Thread Andreas L Delmelle
On Jul 30, 2005, at 17:34, Manuel Mall wrote (on bugzilla): Manuel, Devs, To be able to simply replace a 0.20.5 fop.jar with 1.0dev fop.jar I have written a backwards compatible apps.Driver.java class. Everything in the class has been labelled as deprecated. FWIW: Personally, besides the

Re: DO NOT REPLY [Bug 35939] New: - [PATCH] Port of 0.20.5 Driver.java class

2005-08-01 Thread Andreas L Delmelle
On Aug 1, 2005, at 11:37, Manuel Mall wrote: no argument from me against what you are proposing and also Joerg in [1]. We can still have a Driver.java for backwards compatibility for those who want to plug and play either in the product, or in a separate jar (fop-compat.jar?), or just here in

Re: Element list generation for tables (special case)

2005-08-01 Thread Andreas L Delmelle
Merely FYI: slight correction needed... On 30.07.2005 15:14:04 Andreas L Delmelle wrote: Currently, I don't think we already have a mapping of these object-applicable_props anywhere, ... We do have such a map in org.apache.fop.fo.PropertySets, but I don't get the impression

Re: RTF rendering

2005-08-01 Thread Andreas L Delmelle
On Aug 1, 2005, at 18:57, Sergey Simonchik wrote: Hi, Currently I work on upgrading FOP's RTF rendering. We need it as a part of another project. And now some patches to RTF-rendering with test cases are available. So I have two questions: 1) Would you be so kind to tell your intention about

Re: API discussion (was: DO NOT REPLY [Bug 35939] New: - [PATCH] Port of 0.20.5 Driver.java class)

2005-08-02 Thread Andreas L Delmelle
On Aug 2, 2005, at 11:14, Jeremias Maerki wrote: On 01.08.2005 18:31:35 Andreas L Delmelle wrote: ... Right now, the Driver would have to be wrapped around the main-class, which is something I do NOT like :-/ I doesn't have to. The Fop class is so light-weight (if you think the main

Non-implemented props: border-*-precedence

2005-08-23 Thread Andreas L Delmelle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, Back from holiday, and just started work on the collapsing border model (something I discussed thoroughly with Jeremias a while ago --don't worry, I'm not going to start all over :-) ) Let me just say that, where earlier on I didn't have

Re: Non-implemented props: border-*-precedence

2005-08-23 Thread Andreas L Delmelle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 23, 2005, at 22:09, Finn Bock wrote: Andreas L Delmelle wrote: The type should be a number with added 'force' enum. The number property will then coerce a 'force' value into an EnumNumber which is a number that also holds a enum value

Re: Non-implemented props: border-*-precedence

2005-08-24 Thread Andreas L Delmelle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 23, 2005, at 23:32, Andreas L Delmelle wrote: On Aug 23, 2005, at 22:09, Finn Bock wrote: So if it is possible at all, I would prefer to see that the inheritance issues is implemented in the PropertyMaker classes, instead of the FObjs

Re: Non-implemented props: border-*-precedence

2005-08-24 Thread Andreas L Delmelle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 24, 2005, at 19:15, Andreas L Delmelle wrote: Wouldn't inheritance still work as desired --by the Property subsystem-- if the default value is set in the FObj's bind() method? Hmm. ATM, it doesn't seem to be working... I tried using

FOTree Table FOs -- definitely non-urgent, just probing...

2005-08-25 Thread Andreas L Delmelle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, Has anyone ever thought about introducing an abstract class for table-related FOs, say TableFObj, that would be extended by all those FOs? It just occurred to me that there are: a) the border-precedences that are applicable only to those

Re: Collapsing borders: FOTree stage -- progress update

2005-08-26 Thread Andreas L Delmelle
On Aug 26, 2005, at 21:32, Jeremias Maerki wrote: You got me a little shocked when I read your post. Really? Good! Nothing personal, but I always tend to take 'shock-and-awe' to be a sign that I'm on the right track. I remember having driven Glen crazy on a few occasions, and that was

Re: Collapsing borders: FOTree stage -- progress update

2005-08-27 Thread Andreas L Delmelle
On Aug 27, 2005, at 09:09, Jeremias Maerki wrote: Ok, the shock is gone. Thank you for reassuring me that you know what you do. That was my biggest concern. I'm happy that you can reuse some of my code. Finally, someone can use something I wrote to make better progress. Normally, it's the other

Re: Collapsing borders: FOTree stage -- progress update

2005-08-27 Thread Andreas L Delmelle
On Aug 27, 2005, at 22:22, Jeremias Maerki wrote: On 27.08.2005 21:33:44 Andreas L Delmelle wrote: I'm wondering, for instance, whether the table's before-border specs are only relevant for the first page that is spanned by the table. For example: in case the table has a header (and omit

Re: Collapsing borders: FOTree stage -- progress update

2005-08-28 Thread Andreas L Delmelle
On Aug 28, 2005, at 04:33, Manuel Mall wrote: I must admit I know very little about collapsing borders. Therefore if my comment is useless just ignore it. Well, I certainly don't think it's useless... I have recently worked on all this percentage stuff. This applies also to border-width

Re: Collapsing borders: FOTree stage -- progress update

2005-08-28 Thread Andreas L Delmelle
On Aug 28, 2005, at 14:38, Andreas L Delmelle wrote: On Aug 28, 2005, at 00:06, Jeremias Maerki wrote: AFAIK you're trying to move the pre-resolvable pieces into the FO tree while you only do the specialities in the LMs, right? Exactly. Come to think of it, maybe that last idea won't

Re: Automatic column widths in fop

2005-08-28 Thread Andreas L Delmelle
On Aug 28, 2005, at 15:57, Manuel Mall wrote: This is just a clarification question to those in the know. In HTML when specifying a table browsers usually choose the smallest width without causing unforced breaks in columns. That is in XSL-FO terms the ipd of the table can be smaller than the

Re: Broken padding on table-cells

2005-08-28 Thread Andreas L Delmelle
On Aug 28, 2005, at 18:17, Manuel Mall wrote: Padding on table-cells is currently broken. The sample fo file below demonstrates the problem. I think I know the cause and the fix but would like confirmation: Am I correct in saying that in the collapsing border model any padding is not part of

Re: Automatic column widths in fop

2005-08-28 Thread Andreas L Delmelle
On Aug 28, 2005, at 16:21, Manuel Mall wrote: [Me:] We could either: - drop the table completely (+ warn about this, of course) - explicitly notify the user that, because auto-layout is not supported, the default value of auto is ignored and replaced by 100% I second that for the time being.

Re: e-g with padding and borders

2005-09-04 Thread Andreas L Delmelle
On Sep 2, 2005, at 18:42, Vincent Hennebert wrote: Hi Vincent, You're right. Indeed both situations below are handled by the standard, thanks to border conditionality and is-first/is-last traits. Thanks for the pointer! You're welcome, of course. I have to correct myself on the following,

Re: [VOTE] Manuel Mall as new FOP committer

2005-09-05 Thread Andreas L Delmelle
On Sep 5, 2005, at 10:29, Jeremias Maerki wrote: Manuel Mall ... That's why I'd like to nominate him for committership in Apache FOP. Definitely a BIG +1 from me. Cheers, Andreas

Tables, Columns... : FOTree or Layout?

2005-09-09 Thread Andreas L Delmelle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, In my attempt to facilitate an implementation of the collapsing border model on tables by moving the lion's share of the logic from layoutmgr.table over to the fo.flow package, I stumbled upon some other parts that are currently dealt

Re: Tables, Columns... : FOTree or Layout?

2005-09-11 Thread Andreas L Delmelle
On Sep 10, 2005, at 21:33, Simon Pepping wrote: Hi Simon, You are asking a lot of questions. To most I have no answer, but I have one reservation. On Sat, Sep 10, 2005 at 01:41:05AM +0200, Andreas L Delmelle wrote: The only downside is that certain information is lost. The tree structure

Re: Tables, Columns... : FOTree or Layout?

2005-09-11 Thread Andreas L Delmelle
On Sep 11, 2005, at 11:52, Jeremias Maerki wrote: Hi, On 10.09.2005 01:41:05 Andreas L Delmelle wrote: This kind of on-the-fly normalization of the tree structure has advantages for layout in that the table-grid co-ordinates will be readily available (no interpretation needed, just pick up

Another table-question: initial column-number for cells

2005-09-12 Thread Andreas L Delmelle
Hi, The Rec describes the default value for the column-number on table-cells as: For the first table-cell in a table-row, the current column number is 1... My question: is this also true in case there was a row-spanning cell from the previous row that already occupies the first column? IOW:

Re: Another table-question: initial column-number for cells

2005-09-12 Thread Andreas L Delmelle
On Sep 12, 2005, at 11:49, Jeremias Maerki wrote: The current code works that way. The first free grid unit is used. OK. Thanks for the confirmation. FYI: I'm currently almost done with having the initial values set by the Property subsystem itself. (Finn's recent addition of

Re: Hyphenation

2005-09-12 Thread Andreas L Delmelle
On Sep 12, 2005, at 12:06, Jeremias Maerki wrote: Uhm, given that we've decided to remove the hyphenation patterns entirely, we can't do these tests at all. D'oh! BTW: On the release-plan Wiki, I noticed that the hyphenation patterns still haven't been removed yet. I remember running into

Re: Hyphenation

2005-09-12 Thread Andreas L Delmelle
On Sep 12, 2005, at 12:48, Manuel Mall wrote: On Mon, 12 Sep 2005 06:17 pm, Andreas L Delmelle wrote: BTW: On the release-plan Wiki, I noticed that the hyphenation patterns still haven't been removed yet. I remember running into problems while trying to remove them a couple of months ago, so

Re: Another table-question: initial column-number for cells

2005-09-12 Thread Andreas L Delmelle
On Sep 12, 2005, at 12:01, Andreas L Delmelle wrote: FYI: I'm currently almost done with having the initial values set by the Property subsystem itself. (Finn's recent addition of TableBorderPrecedence gave me just the hint I needed to get the necessary understanding of the property system

FOTree test question

2005-09-13 Thread Andreas L Delmelle
Hi, I can describe the case only, since I can't commit my changes yet (they still break a few layout tests), so please ask further if you don't have enough info to form an idea of my changes. Maybe better to wait to when I commit my stuff to a branch --tomorrow or Thursday--, so you get a

Re: svn commit: r280608 - /xmlgraphics/fop/trunk/test/java/org/apache/fop/fotreetest/ext/AssertElement.java

2005-09-13 Thread Andreas L Delmelle
On Sep 13, 2005, at 19:58, [EMAIL PROTECTED] wrote: Author: bckfnn Date: Tue Sep 13 10:57:58 2005 New Revision: 280608 URL: http://svn.apache.org/viewcvs?rev=280608view=rev Log: Run the checks on the parent's propertyList. OK, so it wasn't me after all... :-) Thanks a lot for the very quick

Re: FOTree test question

2005-09-13 Thread Andreas L Delmelle
On Sep 13, 2005, at 22:06, Finn Bock wrote: [Andreas] Very roughly, the new ColumnNumberProperty.make() does something like this: That should be ColumnNumberPropertyMaker in order to follow the naming of all the other custom makers. OK, I'll keep that in mind... Shouldn't it be

Initial values for column-number (commit still pending...)

2005-09-15 Thread Andreas L Delmelle
Hi people, Just finished implementing the initial values for the column-number property. (Subversion still complains about files remaining in conflict, though, so I'll have to check those out first. Have to go now, but commit will most likely follow tonight...) All layout tests passed

Re: Initial values for column-number (commit still pending...)

2005-09-15 Thread Andreas L Delmelle
On Sep 15, 2005, at 13:35, Andreas L Delmelle wrote: On Sep 15, 2005, at 13:18, Jeremias Maerki wrote: There are no hints in the spec that indicate that the lack of an ends-row is an error if someone uses starts-row. You can perfectly split a bag full of cells into tables with only

Re: Initial values for column-number (commit still pending...)

2005-09-15 Thread Andreas L Delmelle
On Sep 15, 2005, at 13:50, Jeremias Maerki wrote: snip / But it should be clear that an explicitely defined property should override the default on the other corresponding property. Hmmm... 'should be clear'? No offence, but that is interpretation, not fact. The term 'corresponding

Re: Initial values for column-number (commit still pending...)

2005-09-16 Thread Andreas L Delmelle
On Sep 15, 2005, at 16:05, Jeremias Maerki wrote: Jeremias, Ok, let me then explicitely state that my previous mail contained my own interpretation and no facts. IMO there are certain gaps and inaccuracies in the spec and I tried to take my own expectations and create an interpretation that

Re: Initial values for column-number (commit still pending...)

2005-09-16 Thread Andreas L Delmelle
On Sep 16, 2005, at 12:15, Jeremias Maerki wrote: Absolutely no resentment here. I'm sorry for sending the wrong signals. I simply realized that I was not clear enough that the stuff I wrote is just my opinion. Stuff like that always happens if I don't want to lose too much time. Sigh. Ok,

Re: Initial values for column-number (commit still pending...)

2005-09-16 Thread Andreas L Delmelle
On Sep 16, 2005, at 12:26, Finn Bock wrote: My take is that only a true value is used to determine a change in row. It makes no difference to the fo-tree or to layout if a default false or an explicit false is found. FWIW: That was precisely my understanding too, hence my speaking of a

Re: Initial values for column-number (commit still pending...)

2005-09-16 Thread Andreas L Delmelle
On Sep 16, 2005, at 16:00, Andreas L Delmelle wrote: Well, currently you both got me convinced about this. I'm working on it --but a bit frustrated, since that was really the *only* case where it failed. All other situations are handled nicely including row-spans... --even when a user would

Re: Initial values for column-number (commit still pending...)

2005-09-17 Thread Andreas L Delmelle
On Sep 16, 2005, at 16:31, Andreas L Delmelle wrote: YES! Got it. Ok, so I ended up thoroughly revising my approach, to account for the starts-row/ends-row issue that was the topic of this thread. One thing I also hadn't considered, but which I also succeeded in dealing with now, is out

Re: Hyphenation

2005-09-18 Thread Andreas L Delmelle
On Sep 12, 2005, at 12:17, Andreas L Delmelle wrote: ..., I noticed that the hyphenation patterns still haven't been removed yet. I remember running into problems while trying to remove them a couple of months ago, so this appears to be a task I still have to finish... Can they be safely

Re: svn commit: r289865 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fo/ fo/flow/ fo/properties/ layoutmgr/table/

2005-09-18 Thread Andreas L Delmelle
On Sep 18, 2005, at 21:58, Finn Bock wrote: Hi Finn, +if( pList.getExplicit(PR_COLUMN_NUMBER) != null ) { +((TableFObj) parent).setCurrentColumnIndex( + pList.getExplicit(PR_COLUMN_NUMBER).getNumeric().getValue()); +} Why is explit specified

Re: svn commit: r289865 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fo/ fo/flow/ fo/properties/ layoutmgr/table/

2005-09-19 Thread Andreas L Delmelle
On Sep 19, 2005, at 11:08, Jeremias Maerki wrote: Looks ok on first glance, though I've got a request: Would you please consider installing a checkstyle plug-in into your IDE and configuring the rules file for FOP? Thanks! Dammit! And I thought I had all bases covered... :-( My apologies for

Re: svn commit: r289865 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fo/ fo/flow/ fo/properties/ layoutmgr/table/

2005-09-19 Thread Andreas L Delmelle
On Sep 19, 2005, at 18:03, Andreas L Delmelle wrote: On Sep 19, 2005, at 11:08, Jeremias Maerki wrote: Looks ok on first glance, though I've got a request: Would you please consider installing a checkstyle plug-in into your IDE and configuring the rules file for FOP? Thanks! Dammit! And I

Fwd: undefined page length

2005-09-19 Thread Andreas L Delmelle
Begin forwarded message (from fop-users) From: Andreas L Delmelle [EMAIL PROTECTED] On Sep 19, 2005, at 09:49, Jeremias Maerki wrote: On 19.09.2005 09:36:49 Willy Reinhardt wrote: Is it possible to create a pdf with all content into one page with length adapted accordingly

Re: svn commit: r289865...

2005-09-19 Thread Andreas L Delmelle
On Sep 19, 2005, at 23:19, Andreas L Delmelle wrote: Ok, corrected most of my violations. 'Most', I said... :-S There's still a few left, but bug 36720 came up, so the others will be committed together with the bugfix. Seems I've been quite sloppy in a few places... put too much focus

Re: rtf ignoring TableBody et al

2005-09-20 Thread Andreas L Delmelle
On Sep 20, 2005, at 17:40, Matthew L Daniel wrote: Hi Matthew, The least this would do is avoid a number of unnecessary calls to instanceof. You're on the right track, and maybe that switch impl would be an 80/20 win over the cost of the Right Way. But that huge if-instance case is exactly

  1   2   3   4   5   6   7   8   >