Fixed typo.

Added some Notes section with info contributed by Barry Rountree.

Original changelog from the docbook/contrib/xsl/db2man days.
Adding so that we at least have access to a record of the change
descriptions here (if not the whole CVS history).

Removed unnecessary trailing comma after final term/glossterm
(closes #1215890; thanks to Sam Steingold for reporting the
problem).

::PROBLEM::
If a varlistentry or glossentry contains multiple term or
glossterm elements, a comma is rendered after the final term or
glossterm. A comma should instead be rendered only after every
term or glossterm _except_ the last.

::FIX::
Reworked template logic for term/glossterm. They are now handled
with an xsl:for-each in the varlistentry/glossentry template,
rather than as separate templates.

HTML and FO stylesheets appear to have the same problem, so we
probably need to port this change to those as well.

Added Tagalog locale file contributed by Ramil Sagum.

Uppercase titles in x-ref to Refentry children (closes #1215547;
thanks to Jens Granseuer for reporting the problem).

::PROBLEM::
Titles of all first-level sections in man pages are always
rendered in uppercase. But cross-references to those titles are
not uppercase.

::FIX::
Cross-references to titles of all first-level sections of Refentry
output are now rendered in uppercase; that is, titles in x-refs to
Refnamediv, Refsynopsisdiv, Refsect1, and any Refsection that is a
direct child of Refentry.

Also, x-ref to Refnamediv now uses the localized "NAME" title
instead of the using the first Refname child. This makes the
output inconsistent with HTML and FO output, but for man-page
output, it seems to make better sense to have the "NAME". (It may
actually make better sense to do it that way in HTML and FO output
as well.) That said, I guess it's not likely that most people
would put in an x-ref to a Refnamediv section, so maybe it's kind
of a moot point...

Added tl.xml

Added Amharic locale file contributed by the The Ge'ez Frontier
Foundation.

Fixed bug [ 1212159 ] Missing navigational links with XHTML chunking
which was caused by the following:

1.  When chunk.hierarchy is created, it is a collection of
div elements in a variable, and then that is converted to a
node-set by exlt.

2.  In HTML, there is no namespace, so the div elements are in
no namespace and they work.

3.  In XHTML, the div elements are in the xhtml namespace because
it is the default namespace.  So they cannot be addressed as
just "div", they must have a namespace prefix.

4.  I added an explicit chunkfast namespace to avoid conflict
with the default namespace.

Added support for processing funcparams (closes #1213166; thanks
to Barry Rountree for reporting).

::PROBLEM::
The funcparams element was not being processed as expected.

::CAUSE::
No logic existed in manpages stylesheets for handling funcparams.

::FIX::
Fixed by taking old code for handling of funcprototype and
children, and replacing it with code ported over from HTML
templates for ANSI-style output.

::AFFECTS::
This change affects handling of all funcprototype output. Along
with adding support for funcparams, the following changes were
also made:

  - removed the space that was being output between funcdef and
    paramdef; example:

      was: float rand (void);
      now: float rand(void);

  - turned off bold formatting for the <type> element when it
    occurs within a funcdef or paramdef

  - moved space -> nobreak-space replacement logic into a separate
    template (for potential re-use elsewhere if we need it)

::TODO::
We need to add an option for K&R style funcprototypes.
See #1213277.

  http://sourceforge.net/tracker/index.php?func=detail&aid=1213277&group_id=21935&atid=516914

Backed out patch for #1211477 because it breaks table processing in Saxon.

Applied patch from David Green for #1211477, to prevent
StackOverflowError encountered when processing tables with ~700
rows with Xalan. Smoke-tested and didn't see any obvious problems
with the fix, so going ahead and committing it so others can test
with snapshot.

Align refnamediv title correctly when refentry.generate.title
is non-zero (closes #1212641).

::Problem:
When refentry.generate.title is non-zero, the title output for
Refnamediv is not aligned flush left.

::Cause:
No code for setting start-indent="" was included in
refentry.title.properties. It should be in order to make the
Refnamediv title output be flush left, as are titles for all other
sectioning children of Refentry

::Fix:
Added code for setting start-indent="" in
refentry.title.properties.

Generate XEP bookmarks for Refentry children. (closes #1212491)

Titled child sections of Refentry (Refsynosisdiv, Refsection, and
Refsect1 to Refsect3) were not included in the match statement
used for generating XEP bookmarks. Don't know whether that was
intentional for some reason or whether it was just an oversight.
But given that both AXF and Passivetex bookmarks are generated for
those same Refentry children, it seems like XEP ones ought to also
be generated, for the sake of consistency if for no other reason.

Corrected formatting of generated "Name" title in refentry output
(closes #1212396; thanks to Andreas Lalloo for reporting the
problem).

:Problem::
The "Name" title generated for FO output of Refnamediv in Refentry
is not aligned flush left, as all the other subheadings of
Refentry are, and as the generated Name subheading for Refentry is
in HTML output. Also, the Name title is in a larger font size than
the titles of the other first-level children of Refentry.

:Fix::
The "Name" title generated for FO output of Refnamediv in Refentry
is now handled using the same formatting as that used for all
other first-level children of Refentry.

::Affects:
Along with affecting processing for generated titles for
Refnamediv in FO output, it is possible that this change may have
unanticipated side effects on processing of titles for
Refsynopsisdiv, Refsection, and Refsect1 to Refsect3. The reason
is that part of this change takes the template contents formerly
used only for processing Refsynopsisdiv, Refsection, and Refsect1
to Refsect3, and "repurposes" those template contents for use in
processing the generated title for Refnamediv.

Fixed bug #1202971, chunktoc doesn't handle the chunk.tocs.and.lots=1
parameter.

The table.width template can now sum column specs if none use % or *.

Add support for HTML markup table border attribute, applied to each table cell.

Re-worked construction of .TH title line (closes #1210488).
Also, made comment generated at top of page include version info
(closes #1211254).

Here are the details about the refinements made to the
construction of the .TH title line:

  - "extra1" (which shows up in the center footer of each page):
    If a date cannot be found in the source, we now automatically
    generate a localized "long format" date

  - "extra2" (which shows up in the left footer):
    We now first search for "product version" info; then, if we
    can't find that, a "product name"; if we can't find that, we
    look for "other" info to use. And we can't find that, we leave
    it empty. The exact sequence of elements checked is this:

      1. productnumber in info or refentryinfo
      2. productnumber in info or referenceinfo of parent reference
      3. any refmeta/refmiscinfo that has class = 'version'
      4. productname in info or refentryinfo
      5. productname in info or referenceinfo of parent reference
      6. refmeta/refmiscinfo (first one)
      7. refnamediv/refclass (first one)

  - "extra3" (which shows up in the center header):
    The exact sequence of elements checked is now this:

      1. title in info or referenceinfo of parent reference
      2. refnamediv/refclass (first one)
      3. refmeta/refmiscinfo (first one)

Fixed typo in comment.

Standalone stylesheet for stripping namespaces from DocBook 5/NG
docs. You currently need to do two-pass processing to use this:
First, transform your DocBook 5/NG source doc using this, then
transform the result as usual with the manpages/docbook.xsl
stylesheet. Of course you can always run the process using a pipe
if you want. Example:

  xsltproc ./manpages/stripns.xsl myRefEntry.xml \
    | xsltproc ./manpages/docbook.xsl

It may be that there is actually some way to set it up as a
single-pass XSLT process, as is done with the HTML stylesheets.
But I've not yet figured out how to get that to work...

Added support for processing refsection down to any arbitrary
level of nesting (closes #1210482).

Added support for refsect3 and formalpara processing (closes
#1210478 and #1210479).

Also did some further templates re-organizing, including to the
logic for gathering and processing metadata.

Previous change (adding text-align="left") caused article titles to be displayed left aligned instead centered. This was backward incompatible change in presentation. Now attribute set is conditional and outputs text-align="center" for titles of standalone articles.

Probably in the future more general fix should be done -- either creating separate article.title.properties, or refactoring FO properties settings between titlepage templates and attribute sets.

Context node must be stored/restored in order to get correct language code. (Note that for-each changes current node.)

Added lib directory to the list of directories for which separate Makefile is called

Made path to chunker.xsl stylesheet relative.

Portability tweaks for the build.

  - pull in cvstools/Makefile.incl, mainly so that we can use
    cvstools/runtrang

  - "trang" -> $(RUNTRANG) so that cvstools/runtrang is used; if
    users don't have trang binary installed, that will find
    trang.jar and run it. Also allows users to manually specify
    what trang they want (e.g., "make RUNTRANG=trang")

  - "clean" target now also removes dbforms* files

  - "clean" target now also does "make -C build clean"

  - "xsltproc" -> $(XSLTPROC)

Added references to newly added parameter l10n.gentext.use.xref.language

Added header (with RCS keywords and copyright info) to all files
that lacked it.

Removed. This file has never been included by docbook.xsl, so it
serves no purpose at all...

Modularized a bit further.

Make build more portable.

Added include for $DOCBOOK_CVS/cvstools dir and:

  - replaced hard-coded "saxon" with $(XSLT)
  - replaced hard-coded "trang" with $(RUNTRANG)
  - added PERL=perl variable and replaced hard-coded "perl" with
    $(PERL)
  - replaced hard-coded rm with $(RM)

Modularized main "refentry" template a bit.

Make language codes RFC compliant (closes #1208931; thanks to
Bernd Groh for reporting).

::PROBLEM:
  Stylesheets output two-part language codes in the form "zh_CN".
  But underscores in language codes are actually neither RFC
  compliant nor compliant with the HTML 4.0 rec. The separator
  should be a hyphen. To quote the specs:

    Section 8.1.1, "Language Codes"[1], in the HTML 4.0 Rec.
    states that:

    [RFC1766] defines and explains the language codes that MUST be
    used in HTML documents.

    Briefly, language codes consist of a primary code and a
    possibly empty series of subcodes:

      language-code = primary-code ( "-" subcode )*

    And in RFC 1766, "Tags for the Identification of
    Languages"[2], the EBNF for "language tag" is given as:

      Language-Tag = Primary-tag *( "-" Subtag )
      Primary-tag = 1*8ALPHA
      Subtag = 1*8ALPHA

    [1] http://www.w3.org/TR/REC-html40/struct/dirlang.html#h-8.1.1
    [2] http://www.ietf.org/rfc/rfc1766.txt

::CAUSE:
  Stylesheets simply pass through language codes unaltered. So if
  users put "zh_CN" in their source, they will get "zh_CN" in
  their HTML output.

::FIX:
  Added a new boolean config parameter, "l10n.lang.value.rfc.compliant",
  set to 1 by default. If it is non-zero, any underscore in a
  language code will be converted to a hyphen in HTML output. If
  it is zero, the language code will be left as-is.

::AFFECTS:
  This change affects any HTML output that contains two-part
  language codes.

Fixed typo.

minor formatting change

Replaced leftover instances of "Website"

Fixed bug #851598 links to legalnotice in html are broken.

Set start-indent and end-indent for fo:table-body used to format lists to
zero so that they do not inherit any start-indent from their container, which
would indent relative to the cell boundary.

Cause "clean" target to remove xref.xsl

Make xrefs and olinks work, and prevent instances of &#8220; and
&#8221; entities in output (closes #741578 and #956072; thanks to
Jens Granseuer and Sam Steingold for reporting the problems)

::Problem:
  If you include an xref in a source document, instead of getting
  the xref text you would expect in the output, you just get
  "[xref to refsect1]", where "refsect" is the name of the target
  element for the xref.  If you include an olink, it works as
  expected -- except that the output text has &#8220; and &#8221;
  entities (double "curly" quotation marks).

::Cause:
  The manpages/docbook.xsl driver imports the html/docbook.xsl
  stylesheet, which in turn imports the html/xref.xsl file.

  The manpages/docbook.xsl file then imports the manpages/xref.xsl
  file. That file contains a "xref" template that overrides the
  the one in html/xref.xsl and that, by design, does nothing
  except to generate the "[xref to refsect1]" text instead of the
  expected xref output.

  On the other hand, the manpages stylesheets don't override the
  "olink" template; therefore, the "olink" template from the
  html/xref.xsl file is used "as is". And being that it is
  intended for HTML output, that template uses the &#8220; and
  &#8221; to wrap titles in xref output.

::Fix:
  The original manpages/xref.xsl file has now been removed. The
  build for the manpages distribution now makes that file, using
  the textify.xsl stylesheet to automatically generate it from the
  html/xref.xsl file. It is built in such a away that it basically
  just contains special copies of the "xref" and "olink" templates
  that cause &#8220; and &#8221; instances to be transformed into
  "\(lq" and "\(rq" (groff "left quote" and "right quote").

  It might seem odd that templates from the html/xref.xsl are
  used, since those templates a designed to generate hyperlinks of
  the form <a href="#foo">the section called "Bar"</a>. But it
  works because the manpages stylesheets end up using the text
  value of the output of the above. Thus, the <a href="#foo"> and
  </a> parts are stripped out, leaving just the text between
  ('the section called "Bar"').

::Affects
  Only affects output of xref and olink elements. The fix may not
  be complete and/or may cause other problems. Please test.

  In particular, while it may fix the &#8220; and &#8221; problem
  that English lang/locales users have run into, it doesn't fix
  the corresponding problem for output of xrefs and olinks in many
  non-English locales, which use quoting characters other than
  &#8220; and &#8221;

  To give just one example of many: in Japanese, the quoting
  characters are &#12300; and &#12301; ("left corner bracket" and
  "right corner bracket"). It is possible to "fix" the problem for
  all locales; but it is just a question of whether there is
  enough of a demand for it that it is worth doing.

Classical HTML index is suppressed in a cleaner way as suggested by David Cramer

Whitespace-only change. Expanded all tabs

Added replace-ldqou and replace-rdquo templates, for translating
&#8220; to \(lq and  &#8221; to \(rq

Prevent "sticky" fonts changes. (closes #956070; thanks to Sam
Steingold for reporting the problem, and for his patience...)

::Problem:
  Sometimes a bold or italic font change inadvertently ends up
  becoming "sticky" such that a following chunk of text that
  should just be rendered as plain text instead gets
  boldfaced/italicized.

::Cause:
  Font changes were simply being nested, as they are in HTML.
  While that works for HTML, it doesn't work for roff, where
  font-change instructions aren't actually intended to nest.

::Fix:
  Attempted to un-nest bold/italic font changes. When the manpages
  stylesheets encounter node sets that need to be boldfaced or
  italicized, they now put the \fBfoo\fR \fIbar\fR groff
  bold/italic instructions separately around each node in the set.

  This may not be a complete fix for the problem. In fact, it may
  cause other problems. Please test :^)

Support generation of choice separator in inline simplelist
(closes #1207532)

This ehancement enables auto-generation of an appropriate
localized "choice separator" (for example, "and" or
"or") before the final item in an inline simplelist.

To indicate that you want a choice separator generated
for a particular list, you need to put a processing
instruction (PI) of the form <?dbchoice choice="foo"?>
as a child a of the list. For example:

  <para>This release adds localiation support for the
  following Indic languages:
    <simplelist type="inline">
      <?dbchoice choice="and" ?>
      <member>Hindi</member>
      <member>Punjabi</member>
      <member>Tamil</member>
      <member>Oriya</member>
      <member>Gujarati</member>
    </simplelist>.
  </para>

Output (for English):

  This release adds localiation support for the
  following Indic languages: Hindi, Punjabi, Tamil,
  Oriya, and Gujarati.

Or if the logical relationship between the items in the
list is an "or" relationship, then use choice="or":

  <para>Choose from ONE and ONLY ONE of the following:
    <simplelist type="inline">
      <?dbchoice choice="or" ?>
      <member>A</member>
      <member>B</member>
      <member>C</member>.
    </simplelist>
  </para>

Output (for English):

  Choose from ONE and only ONE of the
  following choices: A, B, or C.

As a temporary workaround for the fact that most of the
DocBook non-English locale files don't have a
localization for the word "or", you can put in a
literal string to be used; example for French:

  <para>Choose from ONE and ONLY ONE of the following:
    <simplelist type="inline">
      <?dbchoice choice="ou" ?>
      <member>A</member>
      <member>B</member>
      <member>C</member>.
    </simplelist>
  </para>

That is, use "ou" instead of "or".

Rolled back some over-aggressive line-break cleanup, and removed
space-normalizing call in group|arg template because it causes
<sbr/> to be handled incorrectly.

Minor update to date/time handling.

Make handling of date format strings more robust (closes #1206837).

::Problem:
  If the "dbtimestamp" PI has words in it that contain any of the
  single-letter characters used as date/time formatting
  instructions, the output is not what would be expected.

  For example, Spanish "long" dates look like this:

    23 de mayo de 2005

  So you would expect that you could generate a date of that form
  using the dbtimestamp PI with a format string like the following:

    <?dbtimestamp format="d de B de Y"?>

  But if you try that, you get the following output:

    23 23e mayo 23e 2005

  That is, the "d" in "de" is replaced with the day of the month.

::Cause::
  The format-string parsing logic works by walking through the
  format string character-by-character. So when it gets to the "d"
  in "de", it has no way of discerning that it is not the "d"
  formatting instruction but is instead part of a word intended to
  be included in the output as a literal string.

::Fix::
  The format-string parsing logic now splits format strings into
  tokens and delimiters and evaluates them token-by-token instead
  of character-by-character.

  For example, it splits the Spanish "long" date format like this:

    <token>d</token> <token>de</token> <token>B</token> ...

  Thus, in looking for the "d" formatting instruction, the "d"
  token matches but the "de" token does not.

  As delimiters, it recognizes the following characters:

    <space> <tab> <CR> <LF> , . / - ( ) [ ]

::Affects:
  This change affects output of the "dbtimestamp" PI as well as
  output from any customization layers that call the
  "datetime.format" template. It affect all formats (HTML, FO, etc.).

Grand Unification: Epilogue (2): If "neighboring" text nodes in
mixed content are whitespace-only, apply the special sauce just
before serving; that is, at the end, not both at the beginning and
at the end.

Repaired line-breaking in list output. Thanks to Hendrik Sattler
for reporting the problem.

The cause of this is was a change that was made a while back to
reduce excessive blank lines in output. Looks like in this case it
cut it back a bit too aggressively. There may yet be some other
cases that will need more fine-tuning.

Whitespace Grand Unification: Epilogue (1): If "neighboring" text
nodes in mixed content are whitespace-only, leave them unseasoned;
that is, don't add the special sauce.

Fixed typo.

Added Kannada localization (from Siddharudh P T)

Verbatim environment "Grand Unification" fix.

Attempte to fix handling of verbatim environments (literallayout,
programlisting, screen) and, in a related way, text nodes.
Particularly in mixed-content blocks. I think I got it working...

Closes #1167995, #975243, #935833, #763861, #728932, #628393, #595213.

Thanks to Hendrik Sattler, Tobias Reif, Tommi Virtanen, Dennis
Grace, and Matthias Andree for reporting the problems.

Sorry it took so long for the fix.

fixed comments

convert CLDR locale data to the format used by DocBook stylesheets

Added mechanism for building HTML output that demonstrates various
bits of localized generated text. Useful for translators who want
to review output.

Replaced named character entities with numeric ones

Added missing entity ref for hi.xml

Fixed bug [ 1173576 ] rowsep lines after last row of a table

Added Mongolian localization from Sanlig Badral.

Set correct code for az.xml locale file.

Added all recently added locales.

Corrected uppercase/lowercase alpha lists.

Added Welsh localization (from Kevin Donnelly)

Fixed bug 1201333 mediaobjectco images not aligned.

fixed bug 1201333 mediaobjectco images not aligned.

Corrected name order

Minor cleanup for author atrribution

Added Azerbaijani translation (from Metin Amiroff)

Added %t for substitutable text in glosssee and glosseealso to fix
bug #858598.

Added Oriya localization (from Gora Mohanty)

Added Irish (Gaelic) localization (from Kevin Patrick Scannell)

Added %t for substitutable text in glosssee and glosseealso to fix bug 858598.

Now glosssee and glossseealso use full gentext template with substitution.

Make glosssee and glossseealso into full gentext templates with substitution.

Incorporated Albanian locale file contributed by Laurent Dhima.

added text for Author (thanks to Paulo Eduardo Neves)

clarified encoding section

ignore build dir

reworked entire file to make things easier for translators

explicitly set encoding to UTF-8 (makes it easier for translators
who might not be familiar with XML and the fact the UTF-8 is the
default...)

switched to ant-based build

clean target added

Added clean target

Changed order of build

touch pi.html so that nothing gets unnecessarily remade

create param.html stamp so that it doesn't get remade if nothing changes

clean target now removes generated *.html param files

Changed longest.term template to measure width after apply-templates to term.

Added/Corrected HTML Help language codes. Note that there are no
HTML Help language codes for Bangla, Gujarati, Punjabi, or Tamil.
So, set the code for those to the code for Hindi, which, it seems,
is the closest we can get.

fixed typo

Added hi.xml file contributed by Bernd Groh. Removed "letters"
element from locale files that don't need it.

Added support for Punjabi, Gujarati, and Tamil (via locale files
contributed by Bernd Groh) (ported from build branch)

Added Tamil, Punjabi, and Gujarati locale files contributed by Bernd Groh

Added several missing translations

Simplified and corrected rendering of simplelist. (closes #1154750
and #699081; thanks to Matthias Andree and Bert Vermeulen for
reporting the problem)

  - Any simplelist type="inline" instance is now rendered as a
    comma-separated list, with a comma and also a localized "and"
    before the last item.

  - Any simplelist instance whose type is not inline is rendered
    as a one-column vertical list (ignoring the values of the type
    and columns attributes if present)

Added QandAdiv for all locales that lacked it.