Re: [ePiX-devel] Re: Stable release (Version 1.2.0)

[Andrew D. Hwang]

On Wed, 26 Sep 2007, Maik Beckmann wrote:

> Am Mittwoch, 26. September 2007 16:55:38 schrieb Andrew D. Hwang:
> > As I understand it, the new syntax accepts the same arguments as the old
> > (so is not more restrictive to the user),
> > [snip]
>
> I'm afraid it isn't valid, consider:
>
> void foo(P const& p1, P const& p2)
> {
>   P mid = 0.5*(p1 + p2);
>  // where + has the signature
>  // P operator+(P lhs, P const& rhs);
> }
>
> This dosn't work, since p1 is const and you can't pass a const object as
> no-const (the opposite: passing a non-const as const works).
Ah, I didn't know a const cannot be passed by (non-const) value, and 
neither of my compilers (both 3.3 and 4.0) complain with your code. I'll 
change the P and pair operators back to their old implementations.

> Btw. at some places you wrote things like
>  double  foo(const double arg);
> which is very uncommon.
Oops. I'll purge these for 1.2.0-2.

> PS: Can you add a hatching example? It doesn't work for me so far.
Hatching is used only to get solid filling in eepic; it's not really meant 
to be used as a fill style with visibly-separated hatch lines.

Here are some factors I considered regarding hatch filling:

* According to Tufte, hatch styles are difficult to distinguish, and can
  lead to Moire patterns and eye fatigue if over-used. Solid colors are
  preferable.

* It's easier to omit features than include them. :)

* Each output feature must be implemented either generically (the same
  code for all formats, like labels) or format-specifically (solid filled
  regions), balancing consistency of output against the efficiency of
  using special output capabilities.

  In the interests of simplicity, I reduced output to a small set of
  abstract operations: draw a label at specified location, draw a line
  between arbitrary endpoints, solid-fill a region. As many operations as
  possible are generic.

  Hatch filling would have added substantial complications (or substantial
  inefficiencies) to the design. Similar remarks hold for gradient fills.

* Solid colors cannot handle overlapping regions, while hatching can.
  Transparency should remedy this defect, though, and will presumably
  become better supported as time passes. I don't have a recent enough
  Ghostscript to produce transparency, but if I understood the tikz
  manual, transparency should be supported in tikz.

On the balance, I decided to omit hatch filling (and gradient fills).

Generic hatch filling could be added pretty easily (if inefficiently), but 
if so I'd rather make it an external module than part of the core library.

Thanks for all your help and input!

Best,
Andy

Andrew D. Hwang                 address@hidden
Department of Math and CS       http://mathcs.holycross.edu/~ahwang
College of the Holy Cross       (508) 793-2458 (Office: 320 Swords)
Worcester, MA, 01610-2395       (508) 793-3530 (fax)