headers
Juan R. Migoya | 1 Mar 2002 07:56
Picon

Re: DOCBOOK-APPS: Re: Figure number restart in refentry?

What I did is removing "refentry" for the "component list". It works
well for that purpose, but I don't know If it will have non desired
effects in other parts.

Thanks and regards,

Juan R. Migoya
SPAIN

Norman Walsh wrote:

> / "Juan R. Migoya" <jmigoya <at> ingeteam.es> was heard to say:
> | It's there some way to avoid this? I would like the numbers to
> | be contiguous in the same chapter.
>
> There's no simple switch, but you could arrange it by changing
> block-autolabel to output
>
>  (format-number (component-child-number
>                  nd
>                  '("book")
>                 (label-number-format nd))
>
> (I think, that's an untested guess, but I think that's what you want.)
>
>                                         Be seeing you,
>                                           norm
>
> --
> Norman Walsh <ndw <at> nwalsh.com>      | Debugging is 99% complete most of
(Continue reading)

Permalink | Reply | 0 comments |
headers
Phillip Shelton | 1 Mar 2002 08:38
Picon
Picon
Favicon

RE: DOCBOOK-APPS: Re: different depth of TOC for different elemen ts

Being nasty, both??

-----Original Message-----
Subject: DOCBOOK-APPS: Re: different depth of TOC for different elements

/ Alexander Kirillov 
| does anyone know how to make TOC's for different elements (book, part,
| chapter...) have different depth? I.e., I want TOC for the book only
| show parts, chapters, and appendices; TOC for part - only chapters; TOC
| for chapters - sect1 and sect2...
<snip/>
No, but I've got another TOC-related request in my queue (a TOC for the
top-most
element, regardless of what type it is; so chapters formatted by themselves
have TOCs but chapters inside a book don't).

XSL or DSSSL?

                                        Be seeing you,
                                          norm

--

-- 
Norman Walsh <ndw <at> nwalsh.com>      | If we could read the secret
http://www.oasis-open.org/docbook/ | history of our enemies, we should
Chair, DocBook Technical Committee | find in in each one's life sorrow
                                   | and suffering enough to disarm all
                                   | hostility.--H. W. Longfellow
Permalink | Reply | 0 comments |
headers
Norman Walsh | 1 Mar 2002 08:51
Favicon
Gravatar

DOCBOOK-APPS: Re: No callout numbers in the code with programlistingco

/ Patrick Hartling <patrick <at> vrac.iastate.edu> was heard to say:
| the XSL stylesheets.  Now I am using version 1.49.  On line 329 of
| fo/param.xsl, the stylesheet result type was set to html instead of
| fo. I don't know how param.xsl is generated from param.xml, so I

Oh, ack! That's a param problem I'll have to fix.

                                        Be seeing you,
                                          norm

--

-- 
Norman Walsh <ndw <at> nwalsh.com>      | There has never been a perfect
http://www.oasis-open.org/docbook/ | government, because men have
Chair, DocBook Technical Committee | passions; and if they did not have
                                   | passions, there would be no need
                                   | for government.--Voltaire
Permalink | Reply | 0 comments |
headers
Ian Castle | 1 Mar 2002 09:05

Re: DOCBOOK-APPS: More justify

On Thu, 2002-02-28 at 19:15, Lars Bjørndal wrote:
> Thank you, I'll try.
> 
> Do I understand you right, if I say that I should exchange my ldp.dsl
> with one .css-file? In this case, what .css-file is most the same as
> ldp.dsl-file?

No, your choices are:

Process your SGML/XML with DSSSL to create HTML. HTML is generated with
nasty/deprecated attributes and tags to control the appearance of your
HTML.

or

Process your SGML/XML with DSSSL to create HTML. HTML is generated with
the nice/modern "class=" attribute to associate tags with definitions in
a CSS stylesheet which you supply.

The latter is the approach you should take. Esp. now that most browsers
in use support CSS.

> 
> Lars
> -- 
> Lars Bjørndal <lars.bjorndal <at> grieg.uib.no>
> Storetveitåsen 15, 5067 Bergen.
> Tlf.: 55 28 87 55  Mobil: 958 37 537  Telefaks: 55 28 40 67
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Veillard | 1 Mar 2002 10:02
Picon
Favicon
Gravatar

Re: DOCBOOK-APPS: Re: xsltproc and tablecolumns.extension (was Re: No frames around tables - how to activate Saxon extensions for Norman Walsh's XSL 1.48?)

On Thu, Feb 28, 2002 at 11:48:54PM +0100, Norman Walsh wrote:
> / Alex Lancaster <alexl <at> socrates.berkeley.edu> was heard to say:
> | that extension.  Any word (Daniel V.?) on whether that is planned or
> | even possible at some stage in xsltproc?  It's not part of the exsl
> 
> Daniel and I have talked about getting the extensions ported over.
> He's got some support for extensions in Python so as soon as a couple
> of things are worked out, I'll probably try to write them in Python.
> Then maybe he can port them to the C code for maximum portability.
> (Yes, I could port them to C too, but I bet DV can do it about 10
> times faster :-)

  Problem is that those extension functions need to return nodesets
and I didn't yet finished that part in the Python bindings. I will try to
get this in the next release.
  But since the final goal is to have them directly part of the C
implementation getting the Java existing code for the couple of implementations
you did already could allow to avoid a round-trip. Where are they ? 
What are the most critical extensions ?

Daniel

--

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard <at> redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Permalink | Reply | 0 comments |
headers
Bob Stayton | 1 Mar 2002 11:29
Picon
Favicon

Re: DOCBOOK-APPS: Re: Simplifying the XSL transform commands

On Fri, Mar 01, 2002 at 12:26:53AM +0100, Norman Walsh wrote:
> / Dennis Grace <dgrace <at> us.ibm.com> was heard to say:
> 
> | 2. Is it possible to include an instruction in the XSL customization layer
> | that will direct the output to use the principal tag id as the name (so
> | that, for instance, a DocBook XML article with the id attribute set to
> | 'fred'
> |
> | <article id="fred">
> |
> | would generate output file fred.htm)?
> 
> Try setting use.id.as.filename to 1.

That parameter is only used by the chunking stylesheet.
The non-chunking stylesheet (is there a better name
for that concept?) has no concept of an output filename,
but instead writes to standard output, which
the XSL processor redirects with its -output option.
Using the chunk stylesheet just to get the filename
probably will have side effects (like generating other
chunks).

How about a simple shell or perl script controlling
xsltproc?

--

-- 

Bob Stayton                                 400 Encinal Street
Publications Architect                      Santa Cruz, CA  95060
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jirka Kosek | 1 Mar 2002 11:36
Picon
Favicon
Gravatar

Re: DOCBOOK-APPS: Re: Simplifying the XSL transform commands

Bob Stayton wrote:

> That parameter is only used by the chunking stylesheet.
> The non-chunking stylesheet (is there a better name
> for that concept?) has no concept of an output filename,
> but instead writes to standard output, which
> the XSL processor redirects with its -output option.
> Using the chunk stylesheet just to get the filename
> probably will have side effects (like generating other
> chunks).

There is onechunk.xsl stylesheets, which is based on chuning code but
produces just one HTML file.

				Jirka

--

-- 
-----------------------------------------------------------------
  Jirka Kosek  	                     
  e-mail: jirka <at> kosek.cz
  http://www.kosek.cz
Permalink | Reply | 1 comment |
headers
Bob Stayton | 1 Mar 2002 11:36
Picon
Favicon

DOCBOOK-APPS: Re: selecting imagedata for fo and html, scaling using depth

On Fri, Mar 01, 2002 at 12:13:17AM +0100, Norman Walsh wrote:
> / Bob Stayton <bobs <at> caldera.com> was heard to say:
> | On Sun, Feb 24, 2002 at 04:37:07AM -0500, Stephen Bannasch wrote:
> |> I would like to use a scaled high-resolution image for
> |> fo and an unscaled lower resolution image for html output.
> |> 
> |> [workaround using scaling]
> |
> | You have raised a good issue regarding
> | the processing of images.  Quoting the Definitive Guide
> | reference page for <mediaobject>:
> |
> |   "For example, a MediaObject might contain a video, a high
> |   resolution image, a low resolution image, a long text
> |   description, and a short text description. In a 'high
> |   end' online system, the video is used. For print
> |   publishing, the high resolution image is used. For other
> |   online systems, either the high or low resolution image is
> |   used, possibly including the short text description as the
> |   online alternative. In a text-only environment, either the
> |   long or short text descriptions are used. "
> |
> | This sounds like exactly what you want, but
> | the current XSL stylesheets don't do this.  The html
> | and fo stylesheets both use the same 'select.mediaobject'
> | template, which is in common/common.xsl.   That template
> | currently doesn't try to select an image appropriate for
> | its output medium.  I suspect this is just an unfinished
> | feature of the stylesheets.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alexander Kirillov | 1 Mar 2002 15:33
Picon
Favicon

Re: DOCBOOK-APPS: Re: different depth of TOC for different elements

XSL.
I actually managed to get part of what I wanted by a rather crude hack,
but having a real solution, which would allow setting  parameters
booc.toc.section.depth, chapter.toc.section.depth,
part.toc.section.depth, etc independenlty would be much appreciated

Sasha

On Thu, 2002-02-28 at 18:08, Norman Walsh wrote:
> / Alexander Kirillov <kirillov <at> math.sunysb.edu> was heard to say:
> | Hi all:
> | does anyone know how to make TOC's for different elements (book, part,
> | chapter...) have different depth? I.e., I want TOC for the book only
> | show parts, chapters, and appendices; TOC for part - only chapters; TOC
> | for chapters - sect1 and sect2...
> |
> | Dave Pawson's FAQ page 
> | http://www.dpawson.co.uk/docbook/styling/params.html#d60e59
> | lists this same question and says 
> |
> |>You'd have to create a customization layer that defined a new parameter
> |>and a modified TOC-generating template to use it. The TOC machinery is
> |>not simple, however. This would make a fine feature request, though.8^)
> |
> | I looked through TOC machinery and am not eager to customize it - I am a
> | newbie. But maybe someone has created such a customization layer since
> | this FAQ was written?
> 
> No, but I've got another TOC-related request in my queue (a TOC for the top-most
> element, regardless of what type it is; so chapters formatted by themselves
(Continue reading)

Permalink | Reply | 1 comment |
headers
Norman Walsh | 1 Mar 2002 16:48
Favicon
Gravatar

DOCBOOK-APPS: Resume hacking for DocBook

Over the past few months (years?) a number of people have asked me to
publish the stylesheets I wrote for publishing my resume from a
DocBook document.

I've put them in CVS (but done no release) at
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/docbook/contrib/xsl/resume/

(After I resurrect the DSSSL stylesheets, maybe I'll do a release.)

Enjoy!

                                        Be seeing you,
                                          norm

--

-- 
Norman Walsh <ndw <at> nwalsh.com>      | Worrying is the most natural and
http://www.oasis-open.org/docbook/ | spontaneous of all human
Chair, DocBook Technical Committee | functions. It is time to
                                   | acknowledge this, perhaps even to
                                   | learn to do it better.--Lewis
                                   | Thomas
Permalink | Reply | 0 comments |

Gmane