Previous Message
Next Message

[Printing problems with DL/DT/DD for numbered paragraphs] rides again...

Sent by Mirgy-css-discuss on 28 June 2005 20:08


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-REMOVED] (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-REMOVED]]
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/
Previous Message
Next Message

Possibly related: