Loading ...
Sorry, an error occurred while loading the content.

Re: [XSL-FO] computing block-container height at fo rendertime

Expand Messages
  • W. Eliot Kimber
    ... Indeed. I certainly prefer standards-based approaches as well, which is why XSL-FO is always the first thing I try. But at least with an XSLT-based
    Message 1 of 7 , Aug 22, 2003
    • 0 Attachment
      Erik S. LaBianca wrote:

      > Eliot,
      >
      > Thanks for the reply.
      >
      > I'll be sure to look into UltraXML, although I like the idea of XSL-FO
      > due to the standardization and multiple implementations. I also like the
      > idea of a one-way transform, but I also have to work with designers who
      > want the output a certain way. It's a thin line to walk to say the least.

      Indeed. I certainly prefer standards-based approaches as well, which is
      why XSL-FO is always the first thing I try. But at least with an
      XSLT-based production process you are not committing your source data to
      a proprietary format, only part of the implementation. The risk is thus
      only the cost of re-working the implementation to use something else,
      not the cost of reworking all your data. That's a risk that can be
      quantified with some accuracy and therefore you can make an informed and
      considered business decision as to how to ballance the need to meet
      production requirements against the desire to limit risk and rework in
      the implementation.

      > What I'm really trying to do doesn't necessarily require "layout driven"
      > formatting, but rather just the ability to align structural elements
      > vertically on a grid. The vertical analog to tabstops or columns, I guess.
      >
      > I'm assuming there isn't some other possibility that I've overlooked?

      You might get some mileage out of fo:list-block or even using block
      containers, but I suspect that your requirements can't really be met by
      list-block.

      The XSL Subgroup is certainly thinking hard about these sorts of
      requirements. The challenge is to define facilities that are simple
      enough that they will be implemented (or that reflect existing
      implementations to some degree) but still provide enough useful
      functionality to be worth implementing. The sad fact is that
      sophisticated page composition is hard in general and defining a
      largely-declarative, implementation-independent page composition
      facility that implementors will accept is really hard. Thus even as we
      enhance and extend the FO specification, there will always be a need for
      proprietary extensions and other composition technologies.

      Cheers,

      E.
      --
      W. Eliot Kimber, eliot@...
      Consultant, ISOGEN International

      1016 La Posada Dr., Suite 240
      Austin, TX 78752 Phone: 512.656.4139
    Your message has been successfully submitted and would be delivered to recipients shortly.