OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [docbook-apps] term in <variablelist> is rendered incorrectly in PDF

On Fri, 5 Sep 2003, Jeff Beal wrote:

> FO listitems consist of a "label" part and a "body" part.  These correspond
> directly to the <term/> and the <listitem/> in a DocBook <variablelist/>.
> FO processors determine the width of the "label" part from the
> provisional-distance-between-starts (PDBS) and provisional-label-separation
> (PLS) attributes on the <fo:list-block/> object.
> The PDBS specifies the distance from the start-edge (left for English) of
> the label to the start-edge of the body.  The PLS specifies the distance
> between the end-edge of the label and the start-edge of the body.  Thus, the
> width for the label part becomes PDBS - PLS.
> The DocBook stylesheets calculate the PDBS by determining the number of
> characters in the longest term in the stylesheets and specifying that many
> 'em' units.  That is, if the longest term in your variablelist has 9
> characters, the PDBS will be '9em'.  However, the PLS is hard-coded to
> 0.25in, so you only have 9em - .25in space for the term's content.  Also,
> there is another hard-coded value for the maximum PDBS (12em), so if you
> have a 15-character term, the PDBS will be 12em.
> I found that the best way to deal with this was to experiment.  Copy the
> template that matches variablelist in the 'vl.as.list' mode from lists.xsl
> into your customization layer and change the maxlength parameter that is
> passed to the 'longest.term' template and the PLS value until you get
> something that looks more like what you want.
> There is also the termlength attribute and a processing instruction (<?dbfo
> term-width="13em"?>) you can use to hard-code the term width into each of
> your variablelists.  This may be the better approach if you only have one or
> two problematic variablelists:

i followed most of that, i'll re-read it shortly to make sure.  i don't
imagine i'll need to do any customizing since this didn't pop up in the
context of an actual variablelist in one of my production documents, i was
just playing and noticed it.

it seems that there are two issues here.  the first is that the
stylesheet is prepared to hyphenate where it can, even when there's
room for the entire <term>.  for instance, the <term>kernel</term>
was hyphenated as


even though it was feasible to fit the entire word on a single
line.  (based on what you wrote, i'm assuming that the stylesheet
calculated PDBS-PLS, realized the entire term wouldn't fit, and

  the second issue was, as i showed, with an unusual term like
XXXXXX, what was produced was


which seemed to represent a complete failure to hyphenate, so what
happened (apparently) was to put as much as possible in the space
allocated, and just continue on the next line after that.

  in either case, it seems that the stylesheets could use some
tweaking.  simply, it seems that the stylesheet is calculating 
too small a value based on the length of the term, so that even
short terms like "kernel" are being hyuphenated when there's no
real need for it.

  is this making any sense?


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]