Martin,
I only just realised, the new container class should have a private FriBidiCharType m_iDirection and accessors setDirection() getDirection(); on construction it should be set to FRIBIDI_TYPE_UNSET, and only get a meaningful value if the user manually sets this. Once I get rid of the #ifdef BIDI stuff the fribidi types will be available throughout, and I will add these at that point, but thought you should know. There, I think, will not be any generic functionality linked with this member, but some of the derived classes will need it: any container that lays out columns will use it to determine if the columns should be ordered from left to right or right to left, the footnote/endnote containers will need it to determine if the footnote number should be on the left or right side of the container, I cannot think of anything else at the moment. The other thing related to this, is that we will really need a set of document-wide properties stored within our document, from which the sections would inherit, the overall document direction being one of such properties. It has to propagate hardcoded-default- >document->section->block; at the moment it propagates hardcoded-default->section->block. I suspect the best way of handling this would be exactly the same as we handle section properties in the PT, eventhough this will affect lot of the present code that querries properties. Tomas
