Re: print page number /= current page number in Braille paginatio n.

Al Gilman writes:

 > > If I recall the page numbering discussion came up a while back.
 > > I objected at first (being print impregnated), but came to accept
 > > the common sense of the view expressed above.
 > I know it's not a capability to die for.  But it illustrates a
 > possible pattern of limitation in the CSS design.

Yes, CSS has limitations: it cannot make guarantees about the
presentation. Some examples: 

  If a font it not available, CSS cannot recreate it and must use
  another one (but CSS2 adds substantial support for finding the best

  If the output device is a tty terminal, margin measurements in pixel
  values cannot be fully honored (but the CSS definition of what a pixel
  is still makes it a useful unit on tty devices).

  If the user has a monochrome monitor, color values can't be honored.

So, if your requirements include absolute control over the
presentation, CSS does not provide a solution.

 > My memory is always suspect.  The way I remember this being left
 > was various people agreeing that we would use some attribute that
 > accepts appropriate values in HTML tags to record the print page
 > number.

Page numbers only appear when a document is rendered to pages. So, in
order to record page numbers you first need to render the document.
When doing so, the UA mus make specific choices about page sizes, what
fonts to use, to kern or not etc. Different UAs will render the same
document in different ways. With the introduction of CSS, the
differences will be smaller, but will not vanish.

 > I should admit, in a priority sense, this is not a burning issue.

What are your burning issues?

 > There are lots of functions that other user groups would like
 > that are of a comparable criticality (nice to have) and don't
 > work in CSS2 at the present.  Yet I am finding the discussion
 > with Howcome very instructive for me, and I think he is learning,
 > too.


 > At present the print version of the HTML Specification is not
 > competitive with real publishing standards because the page
 > number references are missing in the indices.  We should
 > recognize that we, as beneficiaries of the superior accessibility
 > of online hypertext text, want the HTML medium to be accepted as
 > a competitive "first" medium for authoring over a wider and wider
 > range of activities.  To get there, the associated print
 > capabilities including navigation references by page number (as
 > the CSS2 spec illustrates, n.b.) are an absoute requirement.

The navigational references by page numbers only appear in the
postscript version. In the HTML version, the references are done
through hyperlinks, which is one step upwards on the semanic ladder.
The postscript generator (html2ps) uses the hyperlinks when generating
the the page refernces, but the reverse process would not be possible.

 > While we are doing pagination, I don't yet see why we can't
 > support inclusion of secondary indices in appropriate places.  
 > For print-page-number it would be sufficient to have two
 > things:
 >      first: add an "index" variable as a peer of "title, chapter,
 >      section" in the header formatting infrastructure. 
 >      second: add a capability for dereferencing attributes of
 >      selected elements, and not just their contents.  The
 >      definition of the "index" variable in CSS would be 
 >      an attribute value lifted out of the HTML just as
 >      the other three variables are now lifted (modulo the
 >      addition of attribute dereferencing in the "copy" part
 >      of a variable definition).
 > The attribute extraction is clearly on the table for discussion
 > for many other reasons.

Yes. Attribute selectors made it into the CSS2 draft which went public
this week, but attribute extraction needs a little more discussion.
Here's a possible example:

    [INDEX]:before { 
      content: "(Ref page " attr(index) "in PS version) " 
  <P INDEX="48">This is a paragraph.</P>

Would be rendered as:

  (Ref page 48 in PS version) This is a paragraph.

To add this informatin in the header, one could do (after adding the
proposed "index" variable:

    @page :header {
      content: none, "Ref page " first(index) "in PS version", none;
    [INDEX] { running-head: index } 
  <P INDEX="48">This is a paragraph.</P>
  <P INDEX="52">This is another paragraph.</P>

Which could yield:

       Ref page 48 in PS version

    This is a paragraph.

    This is another paragraph.

(Among the above three lines, the first is the generated header, while
the other two are normal content.

Note that in the above example, the page numbers refer to a specific
PS rendering which most likely would be different from the printout
from the HTML source.

 > The big argument will be about whether HTML+CSS will ever sell
 > with 100% system-defined names for things like the "title,
 > chapter, section" variables used in header formatting.  It is
 > clear that one gets more capable formatting if the user can
 > define new variables under user-supplied names.  But that makes
 > the CSS processor more of a compiler.  We have to look at all the
 > places where you would really rather have a variable declaration
 > capability, and see if it's worth the heavy hit is processor
 > complexity.

We don't want to make CSS into a programming language. Also, we want
to ensure implementors that there's a limit to how much memory a
certain feature will take. After looking at how headers and footers
are used, we chose to propose three "fixed variables" -- we could't
find examples of documents which needed more. Do you have any?



H      k   o   n      W   i   u   m       L   i   e
World     W      i     d     e       Web  Consortium

Received on Friday, 7 November 1997 18:03:54 UTC