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 with

font-selection-strategy

2005-09-09 Thread Victor Mote
FOP-devs: WRT font-selection-strategy, I think the new aXSL methods provide the means to client applications to implement the "character-by-character" option. My current reading of the spec is that the "auto" option is merely an opportunity, a hook if you will, for an implementation to do somethi

RE: Relative font weights and font selection

2005-09-09 Thread Victor Mote
Victor Mote wrote (on Monday): > The following methods have now been added to org.axsl.font.Font: > public byte nextBolderWeight() ; > public byte nextLighterWeight() ; > public Font nextBolderFont() ; > public Font nextLighterFont() ; > > public int unavailableChar(String str

Re: Space-resolution doesn't work

2005-09-09 Thread Finn Bock
[Luca on space resolution] So, my idea for handling space resolution is tho have a LM ask its children about their spaces, and create the necessary elements (while at the moment each LM creates elements for its own spaces). For example, if we have this LM tree Outer BlockLM

Re: Space-resolution doesn't work

2005-09-09 Thread Luca Furini
Jeremias Maerki wrote: I'll start from scratch to come up with a better strategy of implementing these rules. I'll probably start by documenting a few cases in the Wiki and try to develop the right element list for them. After that I'll try to find out who exactly to implement everything. Help

Space-resolution doesn't work

2005-09-09 Thread Jeremias Maerki
I think we need to revisit the whole space-resolution story. The current code is fine for only the simplest of cases. If you look at the 4.3.1 Space-resolution Rules in the spec the example given there shows quite clearly IMO that we probably can't just rely on the right combination of Knuth elemen

Re: More style issues

2005-09-09 Thread Peter B. West
Jeremias Maerki wrote: +1 to all three points. But I'll never define a variable called blockProgressionDimension! That's always going to be bpd for me, but then ipd and bpd are so omnipresent so it shouldn't be a problem. blockProgressionDimension or blockProgressionDirection? Exceptions prov

Re: More style issues

2005-09-09 Thread Jeremias Maerki
+1 to all three points. But I'll never define a variable called blockProgressionDimension! That's always going to be bpd for me, but then ipd and bpd are so omnipresent so it shouldn't be a problem. Exceptions prove the rule, don't they? :-) On 09.09.2005 01:55:06 J.Pietschmann wrote: > Hi devs, >