Douglas du Boulay | 7 Feb 06:41 2002
Picon

DOCBOOK: newbie table colspec colwidth question

I have a docbook sgml document containing many informaltables.
I am using the linux documentation project ldp.dsl customization
of the modular docbook.dsl dsssl stylsheets for rendering to HTML.

Using all default sgml attributes, all the resultant HTML tables have 
explicitly equal width columns. In an earlier version of my document
using sgmltools and the linuxdoc.dtd the column widths were unspecified 
but the default behaviour of most browsers was to adjust the columnwidths to 
fit the contents. While the latter is clearly primitive and 
implementation specific, it was certainly a damn sight cleaner and 
easier to read than the equi-width columns I am now obtaining. 

Probably it is most desirable to specify the colwith explicitly with
the <colspec> tag but I wonder what is the recomended way to set those
widths for both html and print output. Also, since I have very many of these
tables, is there a simple dsssl customization switch to disable the 
current equiwidth settings in the meantime?

Thanks in advance
Doug

Norman Walsh | 7 Feb 14:43 2002

DOCBOOK: Re: A proposal to clarify the semantics of DocBook graphics

/ Yann Dirson <ydirson <at> fr.alcove.com> was heard to say:
| On Wed, Feb 06, 2002 at 10:31:32AM -0500, Norman Walsh wrote:
|> / Yann Dirson <ydirson <at> fr.alcove.com> was heard to say:
|> | On Wed, Feb 06, 2002 at 08:59:41AM -0500, Norman Walsh wrote:
[...]
|> If I say content-width="3in", I want the image to be 3in across.
|
| Hm.  I'm not sure I understand the wording "to be 3in across".  How
| does it compare with width="3in" ?

content-width="3in" says the image (before scaling) should be 3in
wide. width="3in" says that the area reserved for presentation of the
image (irrespective of scaling) should be 3in wide.

| I was not talking about the respective values of "content-width" and
| "width" attributes, but about those of the "content-width" attribute
| and the real size of the image.  In other words, what is supposed to
| happen if you lie to the processor when you specify "content-width".

The content is scaled.

I've updated the description at

  http://sourceforge.net/docman/display_doc.php?docid=9357&group_id=21935

and added a demo at

  http://www.oasis-open.org/docbook/proposals/graphicatts/demo.html

|> | with the implied behaviour being implementation defined.
(Continue reading)

Yann Dirson | 7 Feb 15:08 2002

Re: DOCBOOK: Re: A proposal to clarify the semantics of DocBook graphics

On Thu, Feb 07, 2002 at 08:43:24AM -0500, Norman Walsh wrote:
> and added a demo at
> 
>   http://www.oasis-open.org/docbook/proposals/graphicatts/demo.html

Cool, that helps to understand what you mean.

> / Yann Dirson <ydirson <at> fr.alcove.com> was heard to say:
> | On Wed, Feb 06, 2002 at 10:31:32AM -0500, Norman Walsh wrote:
> |> / Yann Dirson <ydirson <at> fr.alcove.com> was heard to say:
> |> | On Wed, Feb 06, 2002 at 08:59:41AM -0500, Norman Walsh wrote:
> [...]
> |> If I say content-width="3in", I want the image to be 3in across.
> |
> | Hm.  I'm not sure I understand the wording "to be 3in across".  How
> | does it compare with width="3in" ?
> 
> content-width="3in" says the image (before scaling) should be 3in
> wide. width="3in" says that the area reserved for presentation of the
> image (irrespective of scaling) should be 3in wide.
> 
> | I was not talking about the respective values of "content-width" and
> | "width" attributes, but about those of the "content-width" attribute
> | and the real size of the image.  In other words, what is supposed to
> | happen if you lie to the processor when you specify "content-width".
> 
> The content is scaled.

What bothers me then, is that the result here will be likely to be
different if the processor can't determine the image size.  But I can
(Continue reading)

Peter Eisentraut | 7 Feb 18:16 2002
Picon
Picon

Re: DOCBOOK: RFE 480957: Proposal: Improve name and address markup

Norman Walsh writes:

> <!ELEMENT personname %ho; ((honorific|firstname|surname|lineage|othername)+)>

This content model is still very much tied to a particular culture or
three.  Weren't there some ideas to allow character data directly in
personname?

--

-- 
Peter Eisentraut   peter_e <at> gmx.net

Norman Walsh | 7 Feb 18:19 2002

DOCBOOK: Re: RFE 480957: Proposal: Improve name and address markup

/ Peter Eisentraut <peter_e <at> gmx.net> was heard to say:
| Norman Walsh writes:
|
|> <!ELEMENT personname %ho; ((honorific|firstname|surname|lineage|othername)+)>
|
| This content model is still very much tied to a particular culture or
| three.  Weren't there some ideas to allow character data directly in
| personname?

I've always thought this markup was reasonably neutral culturally. Can
you provide some examples where this is not the case?

I would hope, in the worst case, that

  <personname><othername>the culturally different name</othername></personname>

would be acceptable.

                                        Be seeing you,
                                          norm

--

-- 
Norman Walsh <ndw <at> nwalsh.com>      | No victor believes in
http://www.oasis-open.org/docbook/ | chance.--Nietzsche
Chair, DocBook Technical Committee |

Ben Schepens | 7 Feb 22:55 2002
Picon

DOCBOOK: DocBook markup question -- sourcecode

Is it possible to properly mark up source code in a docbook file so that
meinproc will produce html with the source code in a 'greybar' or colored
background?

I have included 2 examples of HTML files that have the look I would like to
get?

Thanks,
Ben Schepens
schepens <at> mindspring.com
Bob Stayton | 7 Feb 20:24 2002
Picon

Re: DOCBOOK: DocBook markup question -- sourcecode

On Thu, Feb 07, 2002 at 01:55:03PM -0800, Ben Schepens wrote:
> Is it possible to properly mark up source code in a docbook file so that
> meinproc will produce html with the source code in a 'greybar' or colored
> background?
> 
> I have included 2 examples of HTML files that have the look I would like to
> get?

This is most easily done with a CSS stylesheet associated
with your HTML output. You can do that with the
'html.stylesheet' parameter. If you look in the generated
HTML output, you'll see each element is output in a <div
class="elementname">, which makes writing css stylesheets
that style specific elements easy.  If you put your source
code in <programlisting> elements, and create a CSS
stylesheet that styles div.programlisting, then you can get
what you want.

Bob Stayton                                 400 Encinal Street
Publications Architect                      Santa Cruz, CA  95060
Technical Publications                      voice: (831) 427-7796
Caldera International, Inc.                 fax:   (831) 429-1887
                                            email: bobs <at> caldera.com

Norman Walsh | 7 Feb 21:20 2002

DOCBOOK: Re: A proposal to clarify the semantics of DocBook graphics

/ Dave Pawson <DaveP <at> dpawson.freeserve.co.uk> was heard to say:
| At 08:43 07/02/2002 -0500, Norman Walsh wrote:
|
|>content-width="3in" says the image (before scaling) should be 3in
|>wide. width="3in" says that the area reserved for presentation of the
|>image (irrespective of scaling) should be 3in wide.
|
| Bit too subtle Norm?

That content-width sets the width of the content and width sets the
width of the reproduction area (viewport)?

|>I don't feel strongly about this one. Anyone else have an opinion?
|
| KISS principle sadly lacking?

I'm not sure I follow. There are two things that you might want to be
able to control: the size of the image rendered and the size of the
area into which it is rendered. This is consistent with CALS, XSL FO,
and FOSI usage.

At present, DocBook has four attributes: depth, width, scale, and
scalefit. A recent thread[1] demonstrated that this paucity of
attributes leads to some confusion.

I thought that providing explicit, independent control over the two
regions might improve things. Perhaps I was mistaken.

                                        Be seeing you,
                                          norm
(Continue reading)

Tammy Fox | 7 Feb 21:30 2002
Picon

Re: DOCBOOK: DocBook markup question -- sourcecode

You can do this if you put the source code inside <screen> tags
and add the following to your custom stylesheet (if you are using
DSSSL):

(element tgroup
  (let* ((wrapper   (parent (current-node)))
	 (frameattr (attribute-string (normalize "frame") wrapper))
	 (pgwide    (attribute-string (normalize "pgwide") wrapper))
	 (footnotes (select-elements (descendants (current-node)) 
				     (normalize "footnote")))
	 (border (if (equal? frameattr (normalize "none"))
		     '(("BORDER" "0"))
		     '(("BORDER" "1"))))
	 (bgcolor '(("BGCOLOR" "#E0E0E0")))
	 (width (if (equal? pgwide "1")
		    (list (list "WIDTH" ($table-width$)))
		    '()))
	 (head (select-elements (children (current-node)) (normalize "thead")))
	 (body (select-elements (children (current-node)) (normalize "tbody")))
	 (feet (select-elements (children (current-node)) (normalize "tfoot"))))
    (make element gi: "TABLE"
	  attributes: (append
		       border
		       width
		       bgcolor
		       '(("CELLSPACING" "0"))
		       '(("CELLPADDING" "4"))
		       (if %cals-table-class%
			   (list (list "CLASS" %cals-table-class%))
			   '()))
(Continue reading)

Rory Hunter | 8 Feb 02:39 2002

Re: DOCBOOK: Re: A proposal to clarify the semantics of DocBook graphics


> I thought that providing explicit, independent control over the two
> regions might improve things. Perhaps I was mistaken.

The idea of having separate control is definitely the good thing IMHO, but 
I think people are getting confused between the names of two attributes. 
They /are/ initially a bit confusing, I didn't get it until I looked at the 
example someone posted.

Something like, mediawidth vs. reproductionwidth (but not to pretentious)?

-- roryh
"Yes, but most people don't attack their boxes with the same
  cavalier abandon you do."
                          -- Said when modding my box [fenriz.org]


Gmane