This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 6003 - New type of lists
Summary: New type of lists
Status: CLOSED INVALID
Alias: None
Product: XSLFO
Classification: Unclassified
Component: XSL-FO Requirements (show other bugs)
Version: unspecified
Hardware: PC Windows XP
: P2 enhancement
Target Milestone: ---
Assignee: Mailing list for comments on XSL (XSl-FO)
QA Contact: Mailing list for comments on XSL (XSl-FO)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-08-30 12:18 UTC by Jan Tosovsky
Modified: 2009-05-27 20:49 UTC (History)
0 users

See Also:


Attachments

Description Jan Tosovsky 2008-08-30 12:18:58 UTC
At present, if definition lists are necessary, <fo:list-block> or <fo:table> elements are used. 

In case of list-block the term is inserted into <fo:list-item-label> while definition itself into <fo:list-item-body>. As for processing of <fo:list-block> element a value of label witdh is required, it is set manualy or computed (for the best results a quite complex formula is required).

In case of table the term is inserted into the first cell while definition into second one. If nested definition list are necessary, nested tables are used.

These solutions have drawbacks - indentation in both cases is equal to the width of term. If several levels of indentation are used, available width for text itself very quickly decrease. We also never get nice design as indentation of each level hasn't the same value. In case of <fo:list-block> such value can be set manualy and hence it is possible to ensure the same value for each level, but this idea goes against the automation.

In TeX different system is available:
Term is followed by definition (separated by space), but second line is indented by arbitrary value - not according the width of term:

Term Definition. If definition
  is long, it continues on se-
  cond line a litle bit inden-
  ted. Nested term:
  Nested term Definition of 
    nested term keep the same
    value of indentation.

I haven't found any drawbacks, but advantages only: 
- much nicer design (imagine terms in bold)
- no problems with width of term
- enough width for definition text if several nested levels

This system seems to be idealy suited for automated processing so its implementing should be high priority by my view.

I can imagine following structure:
<fo:definition-block start-indent="3em" provisional-label-separation="1em">
  <fo:definition-term>
     <fo:block>Term</fo:block>
  </fo:definition-term>
  <fo:definition-body>
     <fo:block>Definition</fo:block>
  </fo:definition-body>
</fo:definition-block>

Three new elements and two current parameters are enough to XSL-FO processor to build such output I think. It could improve design of many documents! Please consider this carefuly.
Comment 1 Vincent Hennebert 2008-09-01 09:32:00 UTC
I'm not sure new XSL Formatting Objects are needed to achieve such a layout. This can be done by something like the following:
    <fo:block-container>
      <fo:block start-indent="3em" text-indent="-3em">
        <fo:inline font-weight="bold">Term Definition.</fo:inline>
        <fo:leader leader-length="1em"/>
        If definition is long, it continues on second line a little bit indented. Nested term:
        <fo:block-container>
          <fo:block start-indent="3em" text-indent="-3em">
            <fo:inline font-weight="bold">Nested term.</fo:inline>
            <fo:leader leader-length="1em"/>
            Definition of nested term keeps the same value of indentation.
          </fo:block>
        </fo:block-container>
      </fo:block>
    </fo:block-container>

The block-container is used to reset the reference for start-indent. A solution without the block-container is to set start-indent and text-indent resp. to 6em and -6em, and so on, but obviously that requires to know the depth of the definition list (might make the XSLT stage a little bit more complicated).

Comment 2 Tony Graham 2009-05-27 10:11:46 UTC
As noted in comment 1, it is possible to achieve the effect you describe using XSL 1.1 features.

As such, the XSL FO SG has determined that no change is required for XSL FO 2.0.

This ticket is closed as 'invalid' only because that's the best description that we can use among the resolutions supported by Bugzilla.

If you are satisfied with this determination, please change the status of this issue to CLOSED, otherwise you are able to reopen this issue and provide further explanation.