Separating line color and dot/dash pattern

[Ethan M. <merritt@u.washington.edu>]

On Saturday 05 February 2005 09:09 am, Ethan Merritt wrote:
> Unfortunately you cannot currently set a line style to have a
> different dot/dash pattern than it has by default, but for a totally
> unintended feature that's not such a severe limitation.

Assuming that we would like to clean this up and document it properly,
there are a few things that should be decided.

- The current (unintended) mechanism only works with line styles,
  not with in-line specifications like "plot <foo> lt <bar>".
  Is that sufficient?

- The obvious extension is to add a keyword "{dt|dashtype} <n>".
  In the context of setting a line style, the command would be
    set style line <tag> dt <N> lt rgb "#aabbcc"
  This would be exactly equivalent to the current behaviour of
    set style line <N> lt rgb "#aabbcc"
  except that you could have (<tag> != <N>)

- A surprising number of terminal types already support dashed lines:
    apollo be cgm dxf eepic emf epslatex fig gnugraph gpic gpr
    hpgl iris4d metafont metapost next openstep post pslatex
    pstricks tgif tpic unixplot win x11
  But I suspect that other than the ones piggybacking on post.trm
  they all disagree about specific dot/dash patterns.
  Is this worth addressing?

- Another alternative is to create a small number of new linetypes.
  I suppose these would internally be LT_DOTTED, LT_DASHED,
  LT_DOTDASH, ..., and have negative index values (similar to -1
  for the current LT_BORDER line type). Support for this would
  have to be gradually added to terminal drivers individually.
  This would produce a consistent set of patterns for all drivers.
  But it has a big disadvantage compared to the current accidental
  method.  The current method is so harmless that I didn't even 
  know it existed; individual terminal drivers don't know anything
  about it, it "just works" for those that support dash patterns.
  By contrast, commands using special new line types would generate
  various errors on terminals that had not yet been modified to
  accept them.
  

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington 98195-7742