Friends,
This is a continuation of the "page looks fine but printing is screwed up"
thread...
In response to the suggestion from Peter Williams I removed the xml line
from the top of the file. I appreciate the suggestion and the education,
but it has made no difference in the outcome. The illustrative sample
(http://www.h4c.org/testing/test-case.html) validates, and has its CSS in-line.
I'm satisfied with this general approach (using definition lists) for
having numbered text paragraphs, as it appears to scale well, given that
even what I would think of as ridiculously large font sizes (e.g. 38 px)
for visually impaired users. Likewise, it requires only a bare minimum of
markup to achieve the desired result, in contrast to the use of tables, and
in fact even in contrast to the use of floated divs. Note that in this
instance, since the numbers are not properly part of the text, I wanted to
distinguish that visually; an ordinary <OL> would not allow that, and in
any case the material with which I am working offers a lot of complexities.
Not every document can be numbered in simple numeric sequence, and
aesthetically I prefer to choose one solution that will handle all
situations, rather than having several solutions, depending... (It is
certainly not essential to the technical issues, but if anyone is
interested, a more complex, real-world example of how I intend to use this
is found at http://www.h4c.org/testing/html/20020410.html. I've no doubt
made some tyro errors, but I've tried to keep everything proportional for
future scaling via JS and manipulations of the CSS.)
If the problems with printing can be solved, it looks as though this
approach could provide a useful solution to certain classes of multiple
item, two column text problems, such as building questionnaires, offering
screenplays, etc. Those of us who come to this list, hat in hand, should
expect to give something back. Perhaps this approach would be of modest use
to others, assuming that the printing problems are resolved/resolvable.
The overall "cannot print" difficulty, I am well nigh convinced, has to do
with the user agent wanting to put the entire definition list on one page--
treating it as one unit-- and as such short test cases (1 page) do not
demonstrate it. (It makes some modest sense to me that the UAs would try to
keep the contents of a DT/DD pair together on one page, but the whole list??)
When trying to print a longer definition list-- i.e. which exceeds one
page-- the UAs are (mostly) acting thus
(http://www.w3.org/TR/css-print/#s.8.2):
If page-break-inside: avoid is specified for a long element and the printer
is unable to buffer the entire element before committing it to paper, it
SHOULD force a page break to occur before the long element and begin the
element starting at the top of the next page. If the long element starts at
the top of a page and exceeds the page length, the printer SHALL print as
much as possible on the first page and then resume that element on the next
and subsequent pages as REQUIRED to preserve the content.
As I said, both FF and IE (1.0.4 and 6.0.2 on XP; test browsers most
readily available to me) appear to consider the whole definition list as
one "long element", and are only "mostly" following the process listed in
the spec (albeit I've not found any spec that specifies this behavior for
definition lists). In other words, it seems that both IE and FF try to
assemble the page, but, for a long list with the CSS as last submitted
(i.e. http://archivist.incutio.com/viewlist/css-discuss/59495), these UAs
want to put a page break as the first element of every page-- and so they
loop. Different buggy output occurs-- a few all blank pages; far too many
blank pages; FF freezing; strange page breaks; truncated printout of the
list; etc.-- depending on the specifics of the CSS used (i.e. using
page-break-inside:auto; in the DL element, or using page-break-after:
always; in the DD element)...
I've not found anything via Google et al about what should happen with a >1
page definition list, nor about this specific problem. Anyone?
I have found several ways to avoid having FF freeze as it ponders the
problem of its infinite "must put all this on the next page" loop (the
"best" one is shown in the in-line CSS), but so far, no joy at getting what
would seem to be the desired result, which is pages with text that are well
filled within the margins specified by the browser... The present sample
will not freeze FF, but removing the page-break directive from the CSS will
cause that...
Thoughts?
If this can be fixed, then great, but if not, would anyone out there in
expert land wish to venture an opine about other/better ways to accomplish
the overall goal, which is having numbered text paragraphs.
d.
David William House
AllHear, Inc.
P.O. Box 330 / 23022 Yeary Lane N.E.
Aurora, OR 97002-0330 USA
(503) 266-6730 (voice) / (503) 266-6418 (fax)
[EMAIL PROTECTED] (e-mail)
http://www.AllHear.com (corporate web site)
"Make no search for water.
But find thirst,
And water from the very ground will burst."
(Rumi, a Persian mystic poet, quoted in Delight of Hearts, p. 77)
______________________________________________________________________
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
