Re: Motivation for having a 'text color' that is invisible

["Sameer Sahasrabuddhe" <sameerds gmail com>]

On 10/25/07, Lars Clausen <lars raeder dk> wrote:
> > I would vote for correctness than ease of coding. If it takes some
> > effort to go look at every object, then so be it. What you really want
> > is that displaying some built-in text on some objects should be
> > optional, then that is what it should be. Making it invisible obscures
> > the intention. Who knows, when someone gets around to coding this,
> > they might notice an abstraction that helps in ways not currently
> > foreseen.
>
> Well, if text could be made invisible, then why not other things?  It
> could make sense to have an "invisible" color -- any renderer can handle
> that simply be not rendering the thing in question.  That way we provide
> much more than by having an extra option to turn any text field on/off.

This is a case of the classic arguments about content v/s style. To
make a perfect analogy, if appearance defined the role of an element,
HTML wouldn't need the H1 tag. An invisible object is not the same as
an undisplayed object. It is still around, and participates in other
interactions. For example, an invisible object near the border could
result in a strange blank area on the periphery if you export a bit
map. Demanding that every renderer handles this correctly can get
tricky. If you group an invisible object with other objects, the
border of the group would include a similar strange blank area. The
invisible colour can also get reset when you are using the properties
dialog to set the colour of multiple objects.

Full transparency support is of course, extremely desirable as Mike
says. But it is not the solution for this problem. And about notes for
objects, we could actually define a standard "notes" property that is
available for all objects!

Sameer.
-- 
Research Scholar, Department of CSE, IIT Bombay
http://www.it.iitb.ac.in/~sameerds/