On Sunday 16 March 2008 06:03, Werner LEMBERG wrote:
> > I am just a bit sad that though there is a lot of talent and
> > experience around, development is not seen to be a priority
> > anywhere. But we have been at this topic a year or so ago, so I
> > just shut up.
>
> Development is always a ma
[.]
Development is always a matter of time. As you can see, I'm the only
one basically who does some coding. And sadly, I can't afford much
time for groff these day.
[]
There is perfection in this world. I've perfectly forgot about this.
I am sorry I was pestering you. My apologies.
> > Hmm, what do you mean with `more serious graphics'? What
> > operation do you have in mind which can't be done with the scheme
> > I propose?
>
> Technically speaking you are absolutely right.
This relieves me :-)
> This is a nice cando masterpiece of true understanding of how gtroff
> work
On 15/03/2008, at 03:06 AM, Werner LEMBERG wrote:
If you could manage avoiding ‘cooking’ with a a ’one-part series’
(Schemes 3 and 4), that would be GREAT. Then I would not even mind
if I could not understand its working :-)
Hehe. This would need a new command in groff, and I'm not sure
whe
> >> If you could manage avoiding ‘cooking’ with a a ’one-part series’
> >> (Schemes 3 and 4), that would be GREAT. Then I would not even mind
> >> if I could not understand its working :-)
> >
> > Hehe. This would need a new command in groff, and I'm not sure
> > whether it's worth the trouble.
[.]
If you could manage avoiding ‘cooking’ with a a ’one-part series’
(Schemes 3 and 4), that would be GREAT. Then I would not even mind
if I could not understand its working :-)
Hehe. This would need a new command in groff, and I'm not sure
whether it's worth the trouble.
[]
T
> Thank you for your post. It works like charm and, since it only
> generates 1 pair of EBEGIN-EEND, it is much more preferable to my
> current scheme.
>
> However, one problem: I have no idea how it works, and I am sure
> that this would also be the case with other Mr Average Users. First
> I
On 02/03/2008, at 09:28 PM, Werner LEMBERG wrote:
You say that you've found a solution using `.trf' -- please post
it here.
I haven't, you did. You taught me about this in bits an' pieces a
year or so ago: [...]
Uuh, how embarassing :-)
Doing some debugging, I've found out that .trf does t
> > You say that you've found a solution using `.trf' -- please post
> > it here.
>
> I haven't, you did. You taught me about this in bits an' pieces a
> year or so ago: [...]
Uuh, how embarassing :-)
Doing some debugging, I've found out that .trf does the job right: It
doesn't handle the escape
On 01/03/2008, at 6:32 PM, Werner LEMBERG wrote:
In one of my early posts regarding actions a) .. e) I said that
processing an eps image needed something "pre", then the image, then
something "post".
I probably didn't understand the situation to comment on this then.
You say that the solu
> In one of my early posts regarding actions a) .. e) I said that
> processing an eps image needed something "pre", then the image, then
> something "post".
I probably didn't understand the situation to comment on this then.
> You say that the solution is to use \X with hooks for before and
> af
Werner, I am glad to see the light at the end of the tunnel.
In one of my early posts regarding actions a) .. e) I said that
processing an eps image needed something
"pre", then the image, then something "post".
I reported the problem that with the current tools this required the
making of
> After a lot of cutting it is now under 100k, I hope it will get
> through.
I think I begin to understand. What you want has absolutely nothing
to do with .cf, I believe: If you say
\X'ps: file foo'
grops produces
BEGIN
END
However, you want to insert some stuff right after `BEGIN'
> After a lot of cutting it is now under 100k, I hope it will get
> through.
Thanks. It still exceeds the limit, but I've just approved the mail.
Werner
> The "\X'ps: file ..." thing can read anything but it can not be used
> in an embedded macro that is a "ps: exec" stuff itself. That's why
> you have to close this embedded macro for a)-c) with a "\Y", then
> you read-in your file with "\X", then you need to open another
> embedded "ps: exec" macr
On 23/02/2008, at 4:28 AM, Werner LEMBERG wrote:
Werner, I get all your e-mails in pairs (with the exact same date),
a minute or so apart.
Yes, one from the groff list, and one directly from me. My mailing
program automatically removes such duplicates...
Well, PS is not the only output d
> Werner, I get all your e-mails in pairs (with the exact same date),
> a minute or so apart.
Yes, one from the groff list, and one directly from me. My mailing
program automatically removes such duplicates...
> > Well, PS is not the only output device driver...
> >
> Then it would be good to s
Werner, I get all your e-mails in pairs (with the exact same date), a
minute or so apart.
On 18/02/2008, at 7:33 PM, Werner LEMBERG wrote:
Yes, .cf copies the external file (A and B) verbatim, but to the
wrong place.
Well, it works as documented...
The documentation does not seem to sa
> >> Yes, .cf copies the external file (A and B) verbatim, but to the
> >> wrong place.
> >
> > Well, it works as documented...
> >
>
> The documentation does not seem to say that (unlike .trf's) .cf's
> output goes only to the intermediate file, not any further. Is
> there any point in having it
On 18/02/2008, at 5:33 PM, Werner LEMBERG wrote:
Yes, .cf copies the external file (A and B) verbatim, but to the
wrong place.
Well, it works as documented...
The documentation does not seem to say that (unlike .trf's) .cf's
output goes only to the intermediate file, not any further. I
> The 1.19.2 edition of groff documentation presents the trf and cf
> requests for including files in diversions.
Yes, the wording is a bit unfortunate.
> The trf request works well, but it does some processing of its
> input. The cf request is supposed to do the same as trf except it
> would n
The 1.19.2 edition of groff documentation presents the trf and cf
requests for
including files in diversions.
The trf request works well, but it does some processing of its input.
The cf request is supposed to do the same as trf except it would not
process
its input in any way.
Unfortunate
22 matches
Mail list logo
