Re: [Groff] pic: "shaded" problem

[Keith Marshall]

On Saturday 17 September 2005 12:41 pm, Ted Harding wrote:
> On 17-Sep-05 Gaius Mulley wrote:
> > Keith MARSHALL <address@hidden> writes:
> >> [...]
> >> Looks like you've discovered a bug in pic's shading code; it doesn't
> >> seem to work for round cornered boxes, at least on the Win32 platform.
> >> I've managed to achieve the effect I think you want, with the
> >> following
> >> quick and very dirty, and hideously ugly workaround:--
> >>
> >> .PS
> >> .fam H
> >> boxrad = 0.15
> >> [ box rad 0 width 1.5-2*0.15 shaded "green" invisible
> >>   circle at last box.nw-(0.0,0.15) rad 0.15 shaded "green" invisible
> >>   circle at last box.sw+(0.0,0.15) rad 0.15 shaded "green" invisible
> >>   circle at last box.ne-(0.0,0.15) rad 0.15 shaded "green" invisible
> >>   circle at last box.se+(0.0,0.15) rad 0.15 shaded "green" invisible
> >> ]
> >> box at last [].c width 1.5 height last [].height - 2.0*0.15 rad 0 \
> >>   shaded "green" invisible
> >> box at last [].c width 1.5 "some text"
> >> .PE
> >>
> >> Perhaps you could develop this into a macro, to work around the bug.
> >>
> >> HTH.
> >>
> >> Keith.
> >
> > Hi Keith,
> >
> > well done with the work around. I think this is the way to fix gpic,
> > internally gpic will have to map a cornered box onto your multiple
> > objects sequence as there isn't a "cornered box" glyph in gtroff.
> >
> > regards,
> > Gaius
>
> As I pointed out earlier, this is in fact how gpic itself deals
> with round-cornered boxes with the 'fill' attribute. So the
> mechanism is already there.

And indeed, your work-around and mine were entirely consistent -- you simply 
went a stage further, and actually provided a suitable macro implementation, 
as I pointed out would be desirable.

> However, unfilled round-cornered
> boxes are drawn as a succession of straight lines and arcs (and
> for good reason -- you don't want to see the "internal" parts of
> the circles, and the constituent rectangles, in an unfilled box).
>
> The bug in gpic, now that it has "shaded", is that it also uses the
> latter method  when drawing a round-cornered box with the 'shaded'
> attribute, and such an entity is not, as it stands, a closed path,
> so there is nothing to "fill" with the "currentcolor".
>
> Filled circles, and boxes with square corners, are drawn as closed
> entities (circles via gtroff '\D'C ...', boxes via '\D'P ...').
>
> The simpler immediate fix would be to ensure that when a box has
> the 'shaded' attribute and rounded corners, the 'fill' method of
> drawing it is used.
>
> However (something I've been pondering for a while), there is in
> fact a need for a more general "filled object" mechanism in gpic.
>
> Already one can draw arbitrary filled polygons (grey or colour)
> in gtroff using '\D'P ...', though there is no provision in
> gpic for generating such code except for boxes (unless you insert
> it "by hand" using 'command' or by enclosing it in text, so that
> it gets passed through to troff as-is).
>
> The sort of thing I have in mind might, in gpic, look like
>
> [ arc down rad 1; arc rad 1;
>   line up 0.5 left 0.75;
>   line left 0.5;
>   line left 0.75 down 0.5 ] closed shaded "green"
>
> (being the part of a house+garden plan showing the grass lawn).
>
> The idea here is that anything within [ ... ] consisting of
> a series of connected segments, arcs of circles or ellipses,
> splines, etc. can be made into a closed object with the 'closed'
> attribute and subsequently shaded (with "shaded" or filled (with
> "fill").
>
> This could then strightforwardly include the existing special case
> of filled/shaded boxes with rounded corners, since then the
> "unshaded" method of drawing these as a sequence of straight lines
> and arcs would be of such a type, and there would be no need for
> the special "work-pound" that gpic already uses with "fill".
>
> Another feature which is missing (and I'm actually surprised
> that the original 'pic' did not provide for it) is the rotation
> of entities.
>
> E.g.
>
>   box with .c at (0,0) rotate 30
>
> for a box rotated through 30 degrees anticlockwise.

In any two dimensional co-ordinate system, such as is employed by pic, there 
are three logical transformations which can be applied to any object, which 
is defined by a collection of co-ordinate pairs representing its vertices.  
These are scaling, rotation and displacement.  While pic already provides 
mechanisms for handling scaling and displacement, a technically astute 
implementation can conveniently encapsulate all three transformations into a 
single matrix, such that a single matrix multiplication operation applies all 
three transformations simultaneously.

Many years ago, when 4.7mHz 8088 PCs were hi-tech, I developed a technical 
graphing library, written predominantly in MS-Pascal, with an API resembling 
Plot-10, and with bindings for MS-FORTRAN resembling Gino-F.  That 
incorporated a transformation algorithm based on just such a matrix 
implementation.  I still have the source, (all my own work, and not subject 
to any licensing restrictions), if anyone would be interested in adapting the 
algorithm for use in pic.

> Howeve, these latter considerations are a longer-term target, since
> they would involve altering gpic at a much deeper level. As things
> stand, implementing the above "immediate fix" for round-cornered
> shaded boxes may be much simpler!

Perhaps, since pic is already capable of emitting troff code for coloured 
circles, and for coloured rectangles, and since it already can decompose 
shaded round cornered boxes into such entities, albeit with gray shading 
only, the simplest immediate fix would be to adapt the existing pic code to 
provide a decomposition to coloured entities, rather than gray shaded.  I'd 
need to study the pic code, to be able to say just how feasible that would be.

Best regards,
Keith.