OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: DOCBOOK: DOCBOOKAPPS: Is there any ENTRYTBL in ANY printstylsheets?

[This is a docbook-apps issue, follow-ups there, please. --moderator]

/ Sean Donnellan <sean@donnellan.de> was heard to say:
| 	The entrytbl subtables are supported in HTML but not in print
| (SGML stylsheets 1.54). Is there a way of printing entrytbl subtables? Why
| the limitation to (presumably only) HTML?

I don't know of any print formatter capable of handling nested tables.
(I know there are and/or have been some commercial formatters that
could, but I don't know what they are/were and I've never used one.)
HTML allows nested tables, so it was fairly straightforward to support
entrytbl in the HTML backend.

I think that it might be possible to automatically "unwrap" nested
entrytbls, but it would be devilishly hard. Actually, as I've
considered the case of multiple entrytbls occuring in the same rows
and columns as other entrytbls, I've become less sure that it can be

| Would it be possible to get the following to work without bending
| backwards in (rephrase "over") the stylesheets?
|  (N.B. second two morerows!!!)

Having noted them well, I have to point out that this is a semantically
broken table.

|   ---------------------------
|  <informaltable frame="all" pgwide="1">
|   <tgroup cols="4">
|   <tbody>
|   <row>
|     <entry morerows="1">cleared</entry>

Row 1, Column 1 = cleared and spans down 1 row

|     <entry morerows="1">2000.01.19</entry>

R1C2 = 2000.01.19 and spans down 1 row

|     <entry>03:00</entry>

R1C3 = 03:00

|     <entry><para>bla bla test test test test test bla test test test test
| test text unremarkable text...</para></entry>

R1C4 = bla bla ...

|   </row>
|   <row>
|     <entry morerows="1"></entry>

R2C3 is empty and spans down 1 row. N.B. this is *column 3* because the
cells from R1 in C1 and C2 span down into this row!

|     <entry morerows="1"></entry>

R2C4 is also empty and spans down 1 row

|     <entry>04:00</entry>

Huh? R2C5? But this tgroup only has four columns!

| My plan was to create a table from an existing dataset. I wanted to
| recursively create subtables (entrytbl) in order to avoid mucking around
| with vertical spans. When I found out that entrytbl doesn't print (I
| think) I decided to cut a corner on the recusion by passing the morerows
| down from row to row. I would have used a history of one row so that I

Alas, they don't pass from row to row, they're implicit in all
subsequent rows for the length of the depth you specify.

| Any answers would be welcome. I've already started to prepare the entire
| table recursively so as to get the spans working... but I'd really love to
| avoid the hassle of chewing memory with, a few thousand, row spans that 
| bridge a large volume of text. Then again if there's no easy way out then
| that's that :-).

That's that.

| P.s. How do I make the above table look decent in print? why does the
| literallayout not work?

This is an ugly, and difficult to handle bug, that effects the very first
element child of a table cell. The easy answer, if you're generating the
data is to put the literllayout inside a para:


The problem is that, in order to get alignment and other things right,
the contents of an entry is always placed inside a para. But then if I
put a para in a para, the spacing is wrong. So the table code cheats
and throws away the top-level wrapper inside an entry. But if this
wrapper had important formatting, that gets lost, too. Ugh!

                                        Be seeing you,

Norman Walsh <ndw@nwalsh.com>      | A new scientific truth does not
http://www.oasis-open.org/docbook/ | triumph by convincing its
Chair, DocBook Technical Committee | opponents and making them see the
                                   | light, but rather because its
                                   | opponents eventually die, and a
                                   | new generation grows up that is
                                   | familiar with it (Planck 1949)

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC