+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,
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
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
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.
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 string,
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 something
-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
