When validating the following XSL Customization layer
I get the following error.
<?xml version="1.0" encoding="UTF-8" ?>
<xsl:stylesheet
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="1.0">
<xsl:import href="xsl/fo/docbook.xsl"/>
<!-- Parameters -->
<xsl:param name="paper.size" select="A4"/>
<xsl:param name="admon.graphics" select="1"/>
<xsl:param name="admon.textlabel" select="0"/>
<xsl:param name="admon.graphics.path"
select="xsl/images/"/>
<xsl:param name="shade.verbatim" select="1"/>
<xsl:param name="insert.xref.page.numbers"
select="1"/>
</xsl:stylesheet>
ERROR: F A location step was expected following the
'/' or '//' token.
Yet as far as I know xsl/images/ is the correct
syntax.
Sean Wheller
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
Hi,
Thought it may be useful to add the ability to store
xsl parameters in an external file and to be able to
export an existing parameter list to a file.
This will enable the same parameter file to be used
across documents in an easy manner. It will also make
management of xsl parameters easier.
Taking this one step further. It would be nice if the
exported file is a customization layer.
Sean Wheller
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
----- Original Message -----
From: "Bob Stayton" <bobs(a)sco.com>
To: "David Tolpin" <dvd(a)davidashen.net>
Cc: <docbook-apps(a)lists.oasis-open.org>
Sent: Wednesday, October 22, 2003 11:55 PM
Subject: Re: [docbook-apps] Section Numbering in
Preface Arabic instead of
Roman
> On Tue, Oct 21, 2003 at 09:45:20PM +0500, David
Tolpin wrote:
> > > On Tue, Oct 21, 2003 at 05:11:08AM -0700, Sean
Wheller wrote:
> > > > Hi,
> > > >
> > > > Docbook XML 4.2
> > > > Docbook XSL 1.60.1
> > > > Xerces J 2.5.0
> > > > Xalan J 2.5.1
> > > > Apache FOP
> > > > SuSE 8.2
> > > >
> > > > When I transform to PDF the TOC shows page
numbers,
> > > > for each section, in Arabic as apposed to
Roman, while
> > > > the page numbers within the sections are
Roman.
> > > >
> > > > Is this standard or can I force Roman in this
part of
> > > > the TOC.
> > >
> > > I'm not sure I'm understanding the question
here.
> > > Are you asking how to number the pages in a
Preface
> > > with arabic instead of roman numerals?
> > >
> >
> > If I remember correctly, FOP has or had a bug,
due to
> > that page-number-citation didn't
> > use format specified for the corresponding
page-number.
> > Thus even for pages numbered
> > in Roman numerals, Arabic numerals will be shown
in the TOC.
>
> It seems fop 0.20.5 no longer exhibits this bug in
the TOC.
>
> --
>
> Bob Stayton 400
Encinal Street
> Publications Architect Santa
Cruz, CA 95060
> Technical Publications voice:
(831) 427-7796
> The SCO Group fax:
(831) 429-1887
> email:
bobs(a)sco.com
>
> To unsubscribe from this list, send a post to
docbook-apps-unsubscribe(a)lists.oasis-open.org, or
visit
http://www.oasis-open.org/mlmanage/.
>
Hi,
Quite often I am wondering what version is a certain component that comes
with oXygen. By component I mean DocBook stylesheets, Xalan, Saxon or FOP.
Is there a place where all this is documented?
I am using oXygen 2.0.4 and I would like to know what version of Xalan is
used.
Thanks,
Marius
http://www.oxygenxml.com/forum/viewtopic.php?t=206
Marius Scurtescu
Tel: 604-222-3900x937
Fax: 604-222-3901
http://www.digitalpt.com
Hi,
I'm testing version of oxy that has support for
XInclude. The following problem is found.
After inserting xi:include elements to document,
code-insight no longer displays element list
correctly.
When all xi:include elements are commented.
Code-insight returns to normal functionality.
Example:
In a chapter document insert an xi:include for a
sect1.
Now try to use code-insight to insert a new sect1
inside the chapter.
sect1 is not available from code-insight.
Comment the xi:include, now sect1 is available from
code-insight.
Sean Wheller
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
Hi,
I just wanted to say that the bookmark idea is great.
It certainly improves productivity as I am able to
rapidly jump between multiple points in my documents
(especially my long docs > 200 000 lines), with a
stroke of the keyboard.
Another feature, I think this may already have been
suggested, is the ability to select an element and any
child/data it may contain. So the use case would be:
if I have a sect2 that is long, say three screens, I
would like to place the cursor into the opening or
closing sect2 element, right-click > select element.
This will cause the editor to select <sect2> ... any
content ... </sect2>.
We already have an option to Escape Selection.
If Oxygen had an XML Browser feature like that of
XMLShell or MSIE this would also be great for
productivity and usability.
Another feature. It would be very useful to have an
insight menu that displays the values of all id
attributes (XPath representation would be //*/@id).
The use case for this is great for Docbook xlink
elements like xref, where the xref linkend attribute
is the value an element id attribute. Naturally the id
should be within the current document so that parsing
can be done to obtain the value of all id's. Although,
an enhanced version should enable a user to select the
document to be parsed for id values. This would reduce
the need to open a document in order to identify the
exact string value of an id.
Another feature, also I think previously mentioned. Is
a Tree View. Not the Tree Editor, but a Tree View that
enables navigation and selection of document parts.
This view should also be insync with the cursor
position in the editor.
Next. This change would be very intrusive.
Would it be possible to break the interface into an
open plan? Rather than having a single window
bordering all parts, separate the parts into dock-able
pieces.
1. Main Menu and Toolbar
2. Project View
3. Editor ( a separate window per document )
Editor Toolbar and Message panel can remain on each
Editor Window.
The idea behind the open plan interface is to enable
better optimization of the screen real-estate, greater
flexibility in real-estate layout.
Just some thoughts. w b interested in hearing view of
developers and other users on these ideas.
Cheers.
Sean Wheller
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
