RE: [dita] Thoughts on Issue #20 [printchar and colors]

["Grosso, Paul" <pgrosso@ptc.com>]

> -----Original Message-----
> From: Paul Prescod [mailto:paul.prescod@blastradius.com] 
> Sent: Tuesday, 2006 April 04 09:53
> To: dita@lists.oasis-open.org
> Subject: [dita] Thoughts on Issue #20

> 
> #2. Is "printchar" really implementable in most output formats? E.g.
> HTML, HTML Help? Is it easy or hard to implement in XSL-FO?

I think printchar is a bad idea.  It's very difficult to
implement in most outputs, and it's archaic.  Last time
anyone really printed a character down the left to highlight
something was with line printers.  XSL-FO supports change bars.
In HTML, you'd probably use background color or something.
But you'd never use a character in the margin to flag text
unless you were trying to mimic some system from the 70s.

> #3. What happens if two attributes on the same element suggest
> conflicting colours? Or an inherited attribute suggests one colour and
> an inner one suggests another.

I don't know about conflicts.  Color should inherit, and the inner
one wins.

Regarding:

 Colors may be entered by name or by code. Processor support is
 recommended for the following: blue #CAE1FF, green #DAF4F0, dark
 pink #CCCCFF, light pink #FFF0F5, yellow #ffffcc, and tan #EED6AF

 Draft comment:

 the list of values given here and below differs from current
 toolkit support - what do we want to doc in the spec? need to
 strike right balance between tool flexibility and interoperability

I agree that Colors may be entered by name or by code.  We should
clarify that "code" means the #rrggbb (i.e., 6 hex digit) RGB value
(there are other codes).

I object to specifying specific rgb values for names.  Neither CSS
nor XSL do this, and systems should be free to pick specific RGB
codes for a given name.  (Our editor allows users to specify the
specific RGB value for each color name; different values will look
best on different monitors/projectors/paper/etc.)

I'd be okay with leaving the list of color names to support out
of the spec and up to the implementations.  But if we are going 
to give a list of color names to support, that list is unacceptable
(e.g., "red" is missing and "dark pink" and "light pink" are not
even valid name tokens).  I'd recommend we follow those listed
in the XSL spec under the <color> datatype near
http://www.w3.org/TR/xsl/slice5.html#section-N8794-Property-Datatypes
which says:

 The list of keyword color names is: aqua, black, blue, fuchsia,
 gray, green, lime, maroon, navy, olive, purple, red, silver,
 teal, white, and yellow.

This list matches the 16 colors defined in CSS at
http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-color

paul