Hi Bob,
Yes, I would be interested in write access; my SourceForge account is 'stilor'.
I would also appreciate some initial pointers on project's policies, such as
formatting style, regression tests (if any), etc. Is there some README that
describes all that?
Thanks,
Alexey.
On Monday, September 09, 2013 01:31:29 PM Bob Stayton wrote:
Hi Alexey,
Looking again at the history of the template for , I would say that the addition
of forced page number only for para was probably not thought through. I would
consider that a bug, so adding a param to support this behavior seems
inapproriate. So I agree that link should rely only on $insert.link.page.number.
Would you be interested in having write access to the repo? I think you have
demonstrated a good understanding of DocBook XSL.
If not, I can check in these changes.
Bob StaytonSagehill Enterprises
bobs@sagehill.net[1]
*From:* Alexey Neyman[2]
*Sent:* Monday, September 09, 2013 12:56 PM
*To:*
docbook-apps@lists.oasis-open.org[3]
*Cc:* Bob Stayton[1]
*Subject:* Re: [docbook-apps] FO output: xrefs to <para/> always include page
number
Hi Bob,
In our documents, we have numbered paragraphs, and a template for <para> in xref-
to mode - so the even the link text is auto-generated.
With what you've said, is $insert.link.page.number.para parameter even needed? Or
is it ok to just drop the unconditional page number for the references to
paragraphs, and rely solely on $insert.link.page.number?
And finally, it seems you're under impression that I have commit access to
docbook-xsl project :) I'd hate to disappoint you, but I do not - or at least, not yet :)
Regards,
Alexey.
On Monday, September 09, 2013 10:01:35 AM Bob Stayton wrote:
Hi Alexey,
The hard-coded addition of page number to para xrefs dates back to at least 2002.
I believe it was put in place because a para does not normally have text generated
for it, so a page number was generated instead. However, the stylesheets now have
several methods of generating text for any such element, including @endterm,
@xrefstyle, and @xreftext. The template does not take into account these other
options (except xrefstyle in the xref template). And I don't know why this "feature"
was later added to the link element, which does have its own text.
I agree that this should be configurable without customization of those
templates. Your solution of adding a new param to maintain backwards
compatibility is fine with me. The snapshot builds are working again, so go ahead
and check in the changes.
Are you familiar with how the params are handled in the source tree? The
param.xml and param.xsl files are generated in the build from the param.xweb and
param.ent files that are kept under source control.
Bob StaytonSagehill Enterprises
_bobs@sagehill.net_*From:* Alexey Neyman[2]
*Sent:* Sunday, September 08, 2013 11:43 PM
*To:*
docbook-apps@lists.oasis-open.org[3]
*Subject:* [docbook-apps] FO output: xrefs to <para/> always include page number
Hi all,
Why is a cross reference to a <para> element always inserting a page number in a
FO output? The stylesheets ignore the settings of $insert.link.page.number and
$insert.xref.page.number parameters if the link target is a <para> element. This
also applies to <olink> links if the link target is determined to be in the current
document.
There seems no easy way to turn off this behavior short of customizing the whole
match="link"/match="xref"/name="xref.page.citation" templates.
It seems somewhat counterintuitive that <para> element ignores the settings of
$insert.*.page.number parameters. But, if it is required to preserve backward
compatible behavior - is it at least possible to at least make it configurable, e.g.
something along the lines of the attached patch?
PS. The patch does not update fo/param.xml: I cannot describe why the new
parameters are needed until I know the reason for the current behavior.
Regards,
Alexey.
--------------------
--------
[1] mailto:
bobs@sagehill.net[2] mailto:
stilor@att.net[3] mailto:
docbook-apps@lists.oasis-open.org