Re: [Groff] parsing a corner specification

On Sun, 26 Aug 2007, Keith Marshall wrote: > Even if this were true, it makes no sense in geometric terms, to refer > to the `left corner' of an object. What, exactly, should that be > interpreted to mean? > > In your example, object `A' is a circle; it doesn't have *any* corners! Thanks fo

Re: [Groff] parsing a corner specification

On Sunday 26 August 2007 00:51, Joel E. Denny wrote: > Third, there are cases where the interpretation of "left" alone is > unambiguous and it should be interpreted as a corner, but it's a > syntax error instead.  My original example in this thread is such a > case: > >   .PS >   A: circle "A" >  

Re: [Groff] parsing a corner specification

On Tue, 21 Aug 2007, Werner LEMBERG wrote: > > > Patches are highly welcome :-) > > > > I wouldn't mind writing a patch once I'm sure of which behavior is > > best. My lack of practical experience with pic leaves me reluctant > > to make a judgement call yet. > > Well, it seems that you've hit

Re: [Groff] parsing a corner specification

On Tue, 2007-08-21 at 18:16 +0100, [EMAIL PROTECTED] wrote: > .PS > A: circle "A" > B: A .left > circle "B" at B > .PE > > Is there a known implementation of pic which does it the way > Joel Denny expects (i.e. as in "B: A left")? Certainly none I've ever used ... I'd write this as .PS

Re: [Groff] parsing a corner specification

On 21-Aug-07 16:14:58, Keith Marshall wrote: > On Tuesday 21 August 2007 06:42, Werner LEMBERG wrote: >> Well, it seems that you've hit a behaviour which is (a) quite obscure >> since there has never been a report about it, > > Perhaps because the expression in question is not just obscure, but is

Re: [Groff] parsing a corner specification

On Tuesday 21 August 2007 06:42, Werner LEMBERG wrote: > Well, it seems that you've hit a behaviour which is (a) quite obscure > since there has never been a report about it, Perhaps because the expression in question is not just obscure, but is rather unnatural. Given the preceding .PS A:

Re: [Groff] parsing a corner specification

> > Patches are highly welcome :-) > > I wouldn't mind writing a patch once I'm sure of which behavior is > best. My lack of practical experience with pic leaves me reluctant > to make a judgement call yet. Well, it seems that you've hit a behaviour which is (a) quite obscure since there has nev

Re: [Groff] parsing a corner specification

On Mon, 20 Aug 2007, Werner LEMBERG wrote: > > How can I obtain a copy of AT&T pic? > > The plan 9 stuff is the nearest one you can get, I think. > > Well, James Clark has written the parser from scratch, probably based > on his experience with sqtroff. Thanks for that information. Thanks also

Re: [Groff] parsing a corner specification

"Joel E. Denny" <[EMAIL PROTECTED]> wrote: > How can I obtain a copy of AT&T pic? This page makes it seem as if I > won't have much luck: > > http://troff.org/source.html > > It links to Plan 9, which has pic source here: > > http://plan9.bell-labs.com/sources/plan9/sys/src/cmd/pic/ > > Its

Re: [Groff] parsing a corner specification

> How can I obtain a copy of AT&T pic? The plan 9 stuff is the nearest one you can get, I think. > Its lexer returns left as a CORNER token only when preceded by "." > or followed by "of", so it can't be the inspiration for the GNU pic > behavior I'm observing. Well, James Clark has written the

Re: [Groff] parsing a corner specification

Hello If it helps, you are correct. The dpic compass-corner definitions are given in the documentation. The "upper" and "lower" keywords are not defined. I can only suggest that instead of writing B: A upper left write B: A.nw which will work both for gpic and dpic. DA At 04:41 PM 19/08/2

Re: [Groff] parsing a corner specification

On Sun, 19 Aug 2007, Ralph Corderoy wrote: > > Hi Joel, > > > I'm getting the strong impression that I'm looking at a very obscure > > usage of GNU pic. Would you agree? > > Or perhaps more likely bugs in its grammar? Then the question would be: what's the correct behavior? Should both or n

Re: [Groff] parsing a corner specification

Hi Joel, > I'm getting the strong impression that I'm looking at a very obscure > usage of GNU pic. Would you agree? Or perhaps more likely bugs in its grammar? Cheers, Ralph.

Re: [Groff] parsing a corner specification

On Sun, 19 Aug 2007, Werner LEMBERG wrote: > > > I've searched the web and Open Group for some roff or pic > > > standards document. So far, I haven't found one. Does one exist? > > > > > > Search for `pic.ps' (made from `pic.ms') in case y

Re: [Groff] parsing a corner specification

On Sat, 18 Aug 2007, Larry Jones wrote: > Joel E. Denny writes: > > > > I've searched the web and Open Group for some roff or pic standards > > document. So far, I haven't found one. Does one exist? > > Thanks for that reference. As fa

Re: [Groff] parsing a corner specification

> > I've searched the web and Open Group for some roff or pic > > standards document. So far, I haven't found one. Does one exist? > > Search for `pic.ps' (made from `pic.ms') in case you have groff installed. This documentation contains

Re: [Groff] parsing a corner specification

Look into src/preproc/pic/pic.y, that your first example goes to "label" because of the lower precedence of "left", and causes an error. In the second one, "upper", which has higher precedence than "CHOP", works well since it is "label corner" rather than "label". %left LEFT ... /* Give attribut

Re: [Groff] parsing a corner specification

Joel E. Denny writes: > > I've searched the web and Open Group for some roff or pic standards > document. So far, I haven't found one. Does one exist? -Larry Jones I'm not a vegetarian! I'm a dessertarian. -- Calvin

Re: [Groff] parsing a corner specification

On Sat, 18 Aug 2007, Clarke Echols wrote: > According to my eroff manual (from Elan Computer Group, Inc.) > the circle allowed-attribute list allows radius, diameter, > height, width, at, invis, same, and text. "at" takes a position > argument. Even though pic reports the error as being on line

Re: [Groff] parsing a corner specification

According to my eroff manual (from Elan Computer Group, Inc.) the circle allowed-attribute list allows radius, diameter, height, width, at, invis, same, and text. "at" takes a position argument. You might try a 'move _to_;' then the circle specification... The semicolon separates operations and