Re: [Groff] refer question
On Thu, Mar 31, 2005 at 11:22:08PM -0500, Peter Schaffter wrote: > Blow, Joe, and John Doe > ^ > > By default, refer produces > > Blow, Joe and John Doe > > I'm wondering if anyone knows a way around this. I don't know if this helps, but in a document, it can be done as .R1 join-authors ", and " ", " ", and " .R2 The default is, as you show above .R1 join-authors " and " ", " ", and " .R2 I believe you can insert this in mom's implementation of refer support. Regards, Zvezdan Petkovic ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] CVS Build Problem
On Wed, Apr 27, 2005 at 09:16:33AM +0200, Werner LEMBERG wrote: > > > It was BSD/OS 4.2 too. I never found the time to get to the bottom > > of the problem and abandoned updating groff on that box. Somebody > > changed groff's build/install stuff to make it more Linux-specific, > > breaking backwards compatibility with the installed base. > > ??? This is nonsense. Normally, Nelson Beebe installs groff on more > than 20 different UNIX flavours, and not a single report of him > mentions severe installation problems. I don't think that he actually > has a BSD/OS 4.2 machine, but your accusation is plain wrong. I tend to agree with this. I've built groff 1.18.1.1 on OpenBSD 3.6 using native make (not gmake). I use it extensively and it works without problems. Has there been any change in CVS to the file in question since 1.18.1.1? FWIW, the only reason I do not use 1.19 branch is that it doesn't work with gpresent. The request .PAUSE inside a pic creates a vertical move, and the figure ends up quite different from what it should be. :-) Has anything been done to address this issue? Zvezdan Petkovic ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] CVS Build Problem
On Tue, May 03, 2005 at 10:26:45AM -0400, Larry Jones wrote:
> Keith MARSHALL writes:
> >
> > Really? I didn't know that, sorry. I used `type' to check that all of the
> > necessary prerequisite programs are installed, because I understood that it
> > *was* standard in Bourne shell; I've never come across one that didn't have
> > it, but my experience has been exclusively with System V, (since SVR2), and
> > more recently with GNU/Linux.
>
> To my knowledge, it has *never* been in the Bourne shell, it is the Korn
> shell's (ksh) answer to the C shell's "which" command. On SysV, it is
> fairly common to have sh be a link to ksh rather than being the real
> Bourne shell (that's how David Korn "proved" that ksh was completely
> upward compatible with sh -- he replaced sh with ksh on many of AT&T's
> systems and no one noticed), which is probably the source of your
> confusion.
Well, like it or not, Korn shell was the basis for POSIX. :-)
I personally like that.
For what it's worth, type is just an alias for whence -v in Korn shell.
See below for portable way to do this.
> > I followed the portability guidelines in the
> > Autoconf documentation, which does not list `type' as a non-portable Bourne
> > shell builtin, (in the `info' for 2.59) :-(
>
> Probably for the same reason it doesn't list "foobar" as a non-portable
> Bourne shell builtin. :-) The current more-or-less definitive
> specification of the shell command language is that specified by the
> Single UNIX Specification/POSIX:
>
>
> <http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html>
>
> The built-ins are on a separate page:
>
> <http://www.opengroup.org/onlinepubs/009695399/idx/sbi.html>
>
> > 3) For each test currently implemented using `type', reproduce the program
> >file location strategy used by Autoconf; this is likely to result in the
> >most portable solution, but is rather long winded.
> >
> > 4) Implement `type' as a shell function, based on the Autoconf strategy,
> >within `pdfroff.sh'; this would appear to be the most attractive option,
> >*but* the Autoconf documentation says not to use shell functions.
>
> I agree with your analysis. For what it's worth, CVS (which is also GNU
> software and widely portable) has the same problem in its test suite
> (although not in the core product) and uses a shell function to solve
> it. In fact, the test suite makes extensive use of shell functions. So
> I suggest going with 4: it's inifinitely better than using "type" and it
> seems to be "portable enough".
No need for the shell function.
POSIX specifies this:
The command -v and -V options were added to satisfy requirements
from users that are currently accomplished by three different
historical utilities: type in the System V shell, whence in the
KornShell, and which in the C shell. Since there is no
historical agreement on how and what to accomplish here, the
POSIX command utility was enhanced and the historical utilities
were left unmodified. The C shell which merely conducts a path
search. The KornShell whence is more elaborate-in addition to
the categories required by POSIX, it also reports on tracked
aliases, exported aliases, and undefined functions.
So the solution is to use command -v.
All the best.
Zvezdan Petkovic
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] CVS Build Problem
On Thu, May 05, 2005 at 10:42:13AM +0100, Keith MARSHALL wrote: > Larry Jones wrote, quoting Zvezdan Petkovic: > >> So the solution is to use command -v. > > > > Hardly -- "type" is probably more portable than "command -v" is. > > Particularly since "command -v" is optional in the latest version of > > POSIX (it's part of the User Portability Utilities option). Well, that changes the things. So, POSIX has introduced command -v to avoid incompatibility between type, whence, and which, and then stops making it obligatory, leaving us with no standard option. Nice job. :-) > I agree with Larry here. For shell portability, the least common > denominator is Bourne shell, but this doesn't guarantee *ANY* degree of > POSIX compliance. > > I will *NOT* use "command -v". It is *NOT* a Bourne shell builtin -- on > SunOS it is available as an external binary, but how should I use it to > confirm its own existence in the first place? What fallback code do I > specify, if it isn't present? > > In Cygwin's "sh", (which is a renamed "ash"), "command" *IS* a builtin, > *BUT* it doesn't support *ANY* options, so "command -v" fails, simply > reporting "-v not found". AFAIK, ash is a BSD shell used in FreeBSD too. FreeBSD man page says that it is currently in the process of being changed to conform to POSIX. Linux man page for ash says that they expect POSIX compliance by the time BSD 4.4 is released. Last time I checked that happened quite a while ago. :-) BTW, I don't think Cygwin should be a measure of Unix compatibility. Oh well, forget it. This is one of those fun things about portability. :-) > > This definitely *ISN'T* any sort of portable solution. > > Regards, > Keith. Agreed. Go for the function. Regards, Zvezdan Petkovic ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] CVS Build Problem
On Fri, May 06, 2005 at 03:51:17AM +0100, Keith Marshall wrote: > On Thursday 05 May 2005 7:40 pm, Zvezdan Petkovic wrote: > > BTW, I don't think Cygwin should be a measure of Unix compatibility. > > Possibly not; but, like it or not, Microsoft Windows has the largest user > base of any OS on the planet. For those of us who are forced, out of > corporate necessity rather than personal choice, to use it, Cygwin is > probably the most widely used UNIX emulator, allowing us to use our preferred > UNIXy tools on an alien platform. You may not consider it a measure of UNIX > compatibility, but you certainly can't ignore it as a measure of portability. I am absolutely aware of that. Unfortunately, in terms of Unix compatibility Cygwin assumes too many things as if it's running on a Linux box. In those terms Microsoft SFU (Services for Unix) and UWIN from AT&T (David Korn) are much more Unix than Cygwin. That's what I meant. I am also aware that much more people use Cygwin than SFU or UWIN, but we could also say that much more people uses Linux than Solaris, which doesn't mean that Linux is a better measure of POSIX conformance. If you are going to ensure that groff runs on Cygwin, I do not see a reason why you wouldn't ensure that it runs under SFU. Exactly because of the corporate requirements, someone's boss may be much more comfortable with the (free) download of a software from Microsoft, supported by Microsoft, on the corporate machines. I'm using groff for Windows on my office machine, and I have a VMware with a whole virtual network of virtual Linux and BSD machines, so I didn't feel a need to install Cygwin. Other machine in my office is an HP-UX workstation. At home I run only Linux and OpenBSD. However, if there's nobody else to do it, I wouldn't mind installing SFU on my office machine and from time to time compiling groff under it. Regards, Zvezdan Petkovic ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Fw: ac_ext problems
On Fri, May 06, 2005 at 01:59:21PM +0200, Werner LEMBERG wrote:
> > Is there any reason to stay with `.cc' as the extension for C++ files
> > for the autoconf tests, given that `.cpp' is much more portable?
>
> Not that I know of. I installed your patch. Thanks.
Sorry I didn't follow this thread and exact reason to change.
I see this as a good reason to leave it as .cc
$ cat tryme.cc
int main(int argc, char *argv[])
{
return 0;
}
$ make tryme
c++ -O2 -o tryme tryme.cc
$ rm tryme
$ mv tryme.cc tryme.cpp
$ make tryme
make: don't know how to make tryme. Stop in /home/zvezdan.
$ gmake tryme
g++ tryme.cpp -o tryme
Obviously only gmake recognizes .cpp as a C++ file on a Unix system.
With older version of gmake on a different Unix machine .cpp has not
been recognized.
Regards,
Zvezdan Petkovic
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Fw: ac_ext problems
On Fri, May 06, 2005 at 09:44:06PM +0200, Werner LEMBERG wrote: > There are at least two C++ compilers (MSVC and a native OS/390 one) > which can't handle the `.cc' extension, while *all* C++ compilers can > handle `.cpp'. I know that. > Whether `make' programs recognize the `.cpp' extension by default is > completely irrelevant for autoconf. BTW, groff's Makefiles don't use > *any* built-in make rules. That's what I wanted to know. Currently groff builds with make and gmake, and I consider that a great feature. Since it doesn't use the built-in rules, but rather defines them, it's irrelevant then. You can call them .c_plus_plus as far as I'm concerned. :-) I should have known better than to question the wisdom of groff developers. I guess I got paranoid using some other software where people are quick to introduce changes without thinking them through. Sorry for the noise. All the best, Zvezdan Petkovic ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] book typeset with groff
On Sat, May 21, 2005 at 12:50:25AM +0200, Werner LEMBERG wrote:
>
> Nelson Beebe told me that the following book has been typeset
> recently with groff:
> ...
> title ="The Design and Implementation of the {FreeBSD}
>Operating System",
> ...
I see that some other books are missing from troff.org list.
For example, recently Addison-Wesley started publishing revised editions
of the classics in computer literature.
Two of them are by the late W.R. Stevens.
We all know that he was one of the biggest advocates of groff.
The one I own is
Stevens, W. Richard, Fenner, Bill, and Rudoff, M. Andrew. 2003.
Unix Network Programming, vol. 1, 3rd ed.
Reading, MA: Addison-Wesley
ISBN: 0-13-141155-1
The authors state explicitly that they followed Stevens's tradition and
typeset the book in groff.
There's another one about to be published
W. Richard Stevens and Stephen A. Rago. 2005.
Advanced Programming in the UNIX Environment, 2nd ed.
Reading, MA: Addison-Wesley
ISBN: 0201433079
I strongly believe that it will be published in groff as well.
We'll have to wait till June to be certain, though.
I think that previous Rago's book
Stephen A. Rago. 1993.
UNIX System V Network Programming.
Reading, MA: Addison-Wesley
ISBN: 0201563185
has been published in groff too.
However, people who own Rago's book should check.
Will you please?
Zvezdan Petkovic
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] serious pdfroff problems
On Thu, Jun 16, 2005 at 09:04:08AM -0400, M Bianchi wrote: > I also strongly recommend _against_ using #!/bin/sh as the first > line of shell scripts. And what exactly do you recommend for a script that should run on dozen different systems? > There is no shell called "sh" anymore. It is always one of the other > shells and they are different enough that it has become unreasonable > to expect any given shell script to work with all of them. _Every_ UNIX system has /bin/sh. All commercial UNIX systems still have Bourne shell although on most of the updated ones it is made POSIXly correct. On some BSDs and Linux it is a link to some other shell, but if you take a look at manual pages you'll see that both ksh and bash behave differently when called as sh. They use a subset of their features. If your script uses that subset too, it should work on all these systems. > For example, I just discovered that tcsh does not understand > $(command) ! That's why you need #!/bin/sh so that users can choose their shell, but you choose the shell for your script. > So any script that uses the $(command) feature should use > #!/bin/bash as the first line, on the rash assumption that bash > is universal. (How likely?) Very unlikely. Bash is not installed by default on any commercial UNIX system or BSD. BSDs allow you to install it as a package. Korn shell has almost exactly the same features and is available on all commercial UNIX systems by default. In OpenBSD it is a default shell (sh is a hard link to ksh). FreeBSD has csh (a hard link to tcsh) as a default. Many users are quite happy with the features of ksh or tcsh that they never bother to install bash. FWIW, Windows Services for UNIX also have tcsh and ksh. No surprise considering what you get after running strings /usr/bin/* | grep BSD on Windows SFU. :-) Therefore, any script should start with #!/bin/sh because that is the only portable way. Best regards, Zvezdan Petkovic ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] serious pdfroff problems
On Thu, Jun 16, 2005 at 02:55:24PM +0100, Keith MARSHALL wrote: > I beg to differ here. While POSIX defines the $( ... ) syntax for > embedded command invocation, we have to deal with many legacy systems > which are not POSIX compliant. As you say, Mike, the syntax used in > pdfroff does have portability problems; as I have already indicated to > Werner privately, the correct portable syntax is > > MATCH="$MATCH"`echo --$OPT | $GREP "^$OPTNAME"` > > or, possibly, the two line form you indicate below. Just a thought. How many of the legacy systems that do not have POSIX sh can run a recent version of Ghostscript with pdfwrite which is a prerequisite for pdfroff? > Bash, tcsh, ksh, zsh, etc. are by no means universal -- /bin/sh *should* > be, and has the best chance of providing a portable script execution > environment, provided appropriate portability guidlines are followed. Couldn't agree more! Best regards, Zvezdan Petkovic ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] pic bug between 1.18.1 and 1.19.x
Pic bug that started in 1.19.x series is still not fixed.
Gpresent .PAUSE request, in combination with pic for loop, triggers a
vertical move which screws up a picture.
See the attached file for the example pic code.
Make a picture. Then
add
.copy "animate.pic"
after .PS
and instead of every, line, circle, etc., call
animate(red, blue, line down from X to Y)
Run it through gpresent and see your picture destroyed.
The animate macro worked fine in 1.18.x.
I have other examples of this bug, but this should be enough to
reproduce the problem.
ZP
.PS
define animate {
for i = 1 to 2 do {
if i == 1 then {
. COLOR $1
} else {
. PAUSE
. COLOR $2
}
$3
. COLOR P
}
}
.PE
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
[Groff] pdfmark patch
I had to apply the attached patch to build groff-1.19.2.pre-20050527 on OpenBSD 3.7. Keith uses $(RM) without ever defining it. I checked through the whole groff source tree and it's not defined anywhere. Thus those lines were failing trying essentially to execute the argument to $(RM). This solved the problem. You may want to think about the better solution. ZP P.S. I used BSD native make as always. --- contrib/pdfmark/Makefile.sub.orig Thu May 26 09:37:18 2005 +++ contrib/pdfmark/Makefile.subThu Jun 16 17:00:03 2005 @@ -52,6 +52,9 @@ export GROFF_BIN_PATH; GROFF_BIN_PATH=$(GROFF_BIN_PATH); \ ./pdfroff $(FFLAG) $(MFLAG) $(PFLAG) +RM=\ + rm -f + .SUFFIXES: .ms .pdf .ms.pdf: $(RM) $@ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] pic bug between 1.18.1 and 1.19.x
On Fri, Jun 17, 2005 at 09:17:49AM +0200, Werner LEMBERG wrote: > Unfortunately, I've never used gpresent, so I can't help here due to > lack of time. Please contact the author of this package for > assistance in debugging. I did a couple of months ago. He concluded that it's a groff bug. And it sounds reasonable. The same pic works with groff-1.18.x and fails with groff-1.19.x. Also, it happens only on pics that use for loops. Now, it could be also that "if" inside a for loop, but I doubt it. I think I have some pics with "if" where it works just fine. Your motivation for looking into this bug in understandably low. I, as a user, certainly have more motivation. My plan is to compile both versions (1.18.1.1 and 1.19.2pre) and compare the pic output for the minimal test picture. I'll also try to extract from CVS the diffs in the pic code between 1.18.x and 1.19.1 which first exhibited such behaviour. Since I need to concentrate on control structures only, I'll probably be able to find the bug soon. Right now I'm busy preparing a presentation for the conference, so groff-1.18.1.1 will be used. :-) As soon as I get back I'll look deeper into this. Hopefully, I'll have something in about two weeks from now. Best regards, ZP ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] pic bug between 1.18.1 and 1.19.x
On Fri, Jun 17, 2005 at 09:40:37PM +0200, Heinz-Jürgen Oertel wrote: > We are using gpresent with 1.19.2 and it works for us. I don't understand > your recommended use. Can you please give a complete example I've sent it a couple of months ago but the attachment was too big for the list. I'll send you off the list a tar.gz file with the complete extracted example (just run make in the directory) and the pdf files of how it looks like with 1.18.x and how 1.19.x changes it. The private mail follows. Best regards, -- Zvezdan Petkovic <[EMAIL PROTECTED]> http://people.umw.edu/~petkovic/ ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] pic bug between 1.18.1 and 1.19.x
On Fri, Jun 17, 2005 at 01:14:18PM +0200, Werner LEMBERG wrote:
>
> > Also, it happens only on pics that use for loops.
>
> Aah, there was indeed a change of the code!
It turns out it wasn't related to the for loop.
I think I've found a good fix.
I've run pic from groff-1.18.1.1 on my extracted test file.
Then I ran pic from groff-1.19.2pre. The diff showed a lot of lines
like this
-8<-
...
\m[darkgreen]
-.sp -1
\D't 2.000p'\h'-2.000p'
.sp -1
-\h'3.204i'\v'1.190i'\D'p0.000i -1.099i -1.648i 0.000i 0.000i 1.099i'
+\h'3.204i'\v'1.190i'\D'p 0.000i -1.099i -1.648i 0.000i 0.000i 1.099i'
.sp -1
\m[]
-.sp -1
\M[darkgreen]
-.sp -1
\m[darkgreen]
-.sp -1
\D't -1.000p'\h'1.000p'
.sp -1
.lf 11
...
->8-
The diff with \h... is OK.
But, the .sp -1 lines are missing in 1.19.2pre and causing all the
trouble obviously.
Then I compared carefully 1.18.1.1 and 1.19.2pre for all the files in
src/preproc/pic and noticed this at the bottom:
-8<-
...
@@ -478,13 +480,15 @@
void troff_output::set_fill(double f)
{
if (driver_extension_flag && f != last_fill) {
-printf("\\D'f %du'\\h'%du'\n.sp -1\n", int(f*FILL_MAX), -int(f*FILL_MAX));
+// \D'Fg ...' emits a node only in compatibility mode,
+// thus we add a dummy node
+printf("\\&\\D'Fg %.3f'\n.sp -1\n", 1.0 - f);
last_fill = f;
}
if (last_filled) {
free(last_filled);
last_filled = 0;
-printf("\\M[]\n.sp -1\n");
+printf("\\M[]\n");
}
}
@@ -494,13 +498,15 @@
if (last_filled || last_outlined) {
reset_color();
}
+// \m and \M emit a node in compatibility mode only,
+// but that won't work anyway
if (color_fill) {
- printf("\\M[%s]\n.sp -1\n", color_fill);
- last_filled = strdup(color_fill);
+ printf("\\M[%s]\n", color_fill);
+ last_filled = strsave(color_fill);
}
if (color_outlined) {
- printf("\\m[%s]\n.sp -1\n", color_outlined);
- last_outlined = strdup(color_outlined);
+ printf("\\m[%s]\n", color_outlined);
+ last_outlined = strsave(color_outlined);
}
}
}
@@ -509,13 +515,13 @@
{
if (driver_extension_flag) {
if (last_filled) {
- printf("\\M[]\n.sp -1\n");
- free(last_filled);
+ printf("\\M[]\n");
+ a_delete last_filled;
last_filled = 0;
}
if (last_outlined) {
- printf("\\m[]\n.sp -1\n");
- free(last_outlined);
+ printf("\\m[]\n");
+ a_delete last_outlined;
last_outlined = 0;
}
}
->8-
Now, I tried to fix the things by adding ".sp -1\n" to each "\\m[]\n"
and "\\M[]\n", for example
printf("\\m[]\n.sp -1\n");
as in 1.18.1.1. That has fixed the problem with the vertical movement
between the colour changes and pauses, but the picture was bad because
some elements were moved vertically back.
Then I tried the change given in the attached patch and the pics are now
all right. I tried it on two large presentations and it looks OK.
Werner, you know the best why the change was made in the first place.
Do you find this fix correct? Is it safe to assume it won't spoil other
things?
While waiting your answer I'll test it on my own recent documents and
see do they behave correctly.
Zvezdan Petkovic
--- src/preproc/pic/troff.cpp.orig Sat Jun 18 18:46:51 2005
+++ src/preproc/pic/troff.cpp Sat Jun 18 19:42:57 2005
@@ -488,7 +488,7 @@
if (last_filled) {
free(last_filled);
last_filled = 0;
-printf("\\M[]\n");
+printf("\\M[]\\c\n");
}
}
@@ -501,11 +501,11 @@
// \m and \M emit a node in compatibility mode only,
// but that won't work anyway
if (color_fill) {
- printf("\\M[%s]\n", color_fill);
+ printf("\\M[%s]\\c\n", color_fill);
last_filled = strsave(color_fill);
}
if (color_outlined) {
- printf("\\m[%s]\n", color_outlined);
+ printf("\\m[%s]\\c\n", color_outlined);
last_outlined = strsave(color_outlined);
}
}
@@ -515,12 +515,12 @@
{
if (driver_extension_flag) {
if (last_filled) {
- printf("\\M[]\n");
+ printf("\\M[]\\c\n");
a_delete last_filled;
last_filled = 0;
}
if (last_outlined) {
- printf("\\m[]\n");
+ printf("\\m[]\\c\n");
a_delete last_outlined;
last_outlined = 0;
}
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] pic bug between 1.18.1 and 1.19.x
On Sat, Jun 18, 2005 at 10:29:44PM -0400, Zvezdan Petkovic wrote: > Werner, you know the best why the change was made in the first place. > Do you find this fix correct? Is it safe to assume it won't spoil other > things? Hmm. Since reset_colors() is called from finish_picture() it seems to be changing at least one of my documents. A picture is at the bottom and a paragraph on the next page starts with a gap at the top of the page. Must be related to \c in the patch. On the other hand present.tmac uses \c at the end of .COLOR P request (to return to previous color), \\m[\\*[gp-color]]\c and at the end of .PAUSE request. \X'ps: exec PAUSE'\c The author of gpresent says that they are necessary. I tried removing \c and it _seems_ that, on my examples, it helps (with unpatched groff-1.19.2pre). I'm not sure I wouldn't have trouble with something else without that \c, though. Removing \c from the PAUSE is a disaster. The point is present.tmac works fine with 1.18.x. The change in troff.cpp in 1.19.x causes the trouble. My fix works, but it apparently can spoil other things. Why the old way with .sp -1 doesn't work any more? I'm giving up on this for tonight. I hope some explanations will be on the list when I wake up. :-) P.S. In the document mentioned at the top, first page is screwed with my patch or without it. I'll try to extract a minimal example and send it as a new thread. Best regards, ZP ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] spacing bug in 1.19.x
Please find attached example for the spacing bug introduced in 1.19.2pre
Notice the lack of spacing between picture and the labels below it.
Also 1.19.2pre gives a warning:
$ groff -pe -me example.me > example.ps
example.me:70: warning [p 1, 5.4i]: cannot adjust line
The same document looks OK with 1.18.x and gives no warnings.
Please advise.
Zvezdan Petkovic
example.me
Description: Troff ME-macros document
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] spacing bug in 1.19.x
Notice that when you switch off the register AK (answer key) .nr AK 0 then the document looks OK. So, this must be related to PIC colour handling again. Sigh. ZP ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] spacing bug in 1.19.x
On Fri, Jun 24, 2005 at 05:53:54PM +0200, Werner LEMBERG wrote: > Not at all. You don't use the `color' or `shaded' command in PIC, so > it is completely unrelated. First of all sorry for not replying earlier. I was at the conference, and didn't want to hurry through this from a hotel room without checking my files first. Please check more carefully before claiming that they are completely unrelated. I use my request .Sl (solution) to switch the colour to blue. I close that with .Se (solution end) later. These macros are usually used in the text, but occasionally they are used in the middle of a picture to provide the solution part of it. (The real picture was much more complex than the simplified example I've sent, of course). All the problems I have with groff-1.19.x are related to the change in colour handling that happened between 1.18.x and 1.19.x releases. (both \m[...] and \M[...]). ZP ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] spacing bug in 1.19.x
On Fri, Jun 24, 2005 at 06:00:02PM +0200, Werner LEMBERG wrote: > > > Please find attached example for the spacing bug introduced in > > 1.19.2pre Notice the lack of spacing between picture and the labels > > below it. > > Your macro definition of .Se relies on pic internals which are neither > documented nor expected to be stable. Perhaps they are not documented and not expected to be stable, but the fact is that they _were_ stable before 1.19.x. I didn't see that the change has been advertised too much in the docs either. :-) > Remove the `.sp -1' and everything looks fine. Easier said than done. As mentioned in the previous message I use these macros in the text usually. Without `.sp -1' there's an extra vertical space in the output (regular one for the end of the paragraph, and another one for the line with \m[] only that is generated by .Se request. > Even better, write the macros like this: > > .de Sl > . gcolor blue > . if \\n(.$ \&\\$1\m[]\\$2 > .. > .de Rf > . gcolor darkgreen > . if \\n(.$ \&\\$1\m[]\\$2 > .. > .de Se > . gcolor > .. This is a good solution. I avoid both \c and '.sp -1' and the document looks good. The only problem is incompatibility with older groff versions since gcolor doesn't exist there, but that can be worked around if necessary. Well, that seems to solve this issue. Thank you for the .gcolor hint. Now, only the gpresent problem and I can swith to 1.19.x completely. :-) > > Also 1.19.2pre gives a warning: > > > > $ groff -pe -me example.me > example.ps > > example.me:70: warning [p 1, 5.4i]: cannot adjust line > > > > The same document looks OK with 1.18.x and gives no warnings. > > This is a new warning which says that groff can't adjust a line > correctly. And indeed the formula after `(a)' must be printed in a > new line. I understand the warning. I do not understand why 1.18.x was able to adjust it and 1.19.x isn't. But this is not a big deal really. ZP ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] pic bug between 1.18.1 and 1.19.x
On Fri, Jun 24, 2005 at 06:12:15PM +0200, Werner LEMBERG wrote:
> I'll have a look into it if time permits.
No need.
Your change with .gcolor and .fcolor in src/preproc/pic/troff.cpp
instead of \m[] and \M[] is the solution.
(Do notice that in one comment you spelled .bcolor instead of .gcolor)
Gpresent now works great!
Thanks again!
Zvezdan Petkovic
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] pic bug between 1.18.1 and 1.19.x
On Fri, Jun 24, 2005 at 06:10:23PM +0200, Werner LEMBERG wrote: > I don't like your fix, sorry. It seems that gpresent relies on > internals of pic which have changed. I don't either. I later indicated that it breaks other things. > BTW, I've just changed PIC to emit `.gcolor' and `.fcolor' instead of > \m and \M, respectively. And that does it! My gpresent woes are gone! I applied the patch from groff-current to groff-1.19.2.pre-20050527 and all my animated pictures in all the presentations work as expected. Thanks a lot Werner! Zvezdan Petkovic ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Escape characters in -man output
On Thu, Jul 07, 2005 at 10:43:40AM +0200, Jörgen Grahn wrote:
> The -c option mentioned is an option to grotty, so you have to "tunnel" it
> through groff's -P option. This works for me (with groff 1.19):
>
>groff -P-c -Tlatin1 -man [...]
>
> (To confuse things a bit, groff has a -c option which is documented to
> disable tty color output, which in turn requires SGR -- but it disables
> color and nothing more.)
>
> Alternatively, you may set the GROFF_NO_SGR shell environment variable.
> That's also mentioned in grotty(1).
Setting GROFF_NO_SGR seems cleaner than calling groff with -P-c all the
time (or even aliasing it).
However, it uses the old way of backspacing for bold.
There is a better way that uses ASCII escape sequences.
Try
MANPAGER="more -R"
export MANPAGER
in your .profile or use setenv if you use (t)csh.
It works for me on OpenBSD where "more" is a hard link to "less".
$ ls -i /usr/bin/{more,less}
247424 /usr/bin/less 247424 /usr/bin/more
You may need to replace "more" with "less" above.
Regards,
Zvezdan Petkovic
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Re: man page encoding
On Wed, Jul 06, 2005 at 01:50:31PM +0200, Bruno Haible wrote: > Thanks, then let's go for the proposed >.\" t -*- coding: EUC-JP -*- > syntax. or a Vim syntax, replacing vim (vi, ex) with groff. .\" groff:option1:option2=value:option3 Notice that in vim syntax : can be replaced with a space between the options. There's also a variant compatible with the older vi versions that uses set command. .\" groff:set option1 option2=value option3 Yes, the argument is that it is very similar to Emacs. Yet, I just don't like those -*- signs. Also, vim syntax is allowed to be in the first N lines of the file, or the last N lines of the file. The default is N=5. Thus if you need something to be on the first line you can always move modeline to the end. Regards, Zvezdan Petkovic ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Re: man page encoding
On Wed, Jul 06, 2005 at 03:36:07PM +0200, Andries Brouwer wrote:
> I am not really aware of use of groff other than as a backend to man.
Now, you are a little upset with Bruno's response, so you are sending a
little jab. Nice. Some people never heard of TeX either and they think
Word (or OpenOffice) is the best thing after the sliced bread.
That doesn't diminish them in my eyes either.
Everybody should use what they feel the most comfortable with.
However, to make you aware of some uses of groff, other than man pages,
I suggest you take a look at the colophon of all O'Reilly books,
excluding only those in the last couple of years). You'll find there
the information that each one of them has been translated from format X
to groff and then printed. In the last couple of years they switched to
FrameMaker apparently.
You can find the list of other publisher books published in troff or
groff on troff.org too. It includes all books by Brian Kernighan (does
"The C Programming Language" rings a bell), Bjarne Stroustrup (C++),
Marshal Kirk McKusick ("The Design and Implementation of 4.4BSD" and
recently FreeBSD), and W. Richard Stevens (Unix network programming).
And we are talking about serious publishers here: Addison-Wesley,
Prentice Hall, ...
That's hack of a use other than man pages.
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] character garble
On Sat, Oct 08, 2005 at 07:22:41PM -0600, D. E. Evans wrote: > I have installed 1.19.2 (via todays cvs checkout) onto an OpenBSD > 3.7 system, (which uses 1.15 by default). This also required an > upgrade of texinfo to 4.8, (both of which I installed from source). > > I get the following result when accessing the man page for groff (though > texinfo's came out fine): > > http://www.deevans.net/groff.png> > > I'm sure there's something silly I've overlooked. Perhaps someone could > point it out to me? I'm using the same system. Put this into your .profile (or equivalent for (t)csh) MANPAGER="more -R" export MANPAGER Why did you need an upgrade of texinfo? groff works fine for me with the system default texinfo. ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] character garble
On Fri, Oct 14, 2005 at 10:52:14PM -0600, D. E. Evans wrote: > This works with 'man groff | less -R' On OpenBSD more is a hard link to less. So it works with more -R too. Read on. > This doens't appear to work Yes it does. Put this in your .profile (I already sent you a message about this) MANPAGER="more -R" export MANPAGER > o If the environment variable GROFF_NO_SGR is set, SGR output is >disabled, reverting to the old behaviour. > > nor does this. Totally not true. I had this set in my profile before more -R and it worked fine. > Is there some configuration for OpenBSD where I can automate this > so that it doesn't have to be typed, with a pipe through less, at > the command line? People have already told you many ways to do it. I use OpenBSD every day, and both of the options above (not together, but one or the other) when used in my .profile work flawlessly. Zvezdan Petkovic ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] character garble
Werner, On Sat, Oct 15, 2005 at 08:22:49AM +0200, Werner LEMBERG wrote: > Ah, yes, there are two competing `man' projects. Which one are you > using? I'm quite sure that you can get the same effect with probably > other means. In case you find it out please report it to the list so > I can update the docs. He just needs to set MANPAGER="more -R" and export it. > > > o If the environment variable GROFF_NO_SGR is set, SGR output is > >disabled, reverting to the old behaviour. > > > > nor does this. > > Hmm, strange. This *must* work since it directly affects grotty. Are > you sure that your man program doesn't use a hard-coded groff version? > Is it really using 1.19.2? It does work. I use OpenBSD 3.7 every day for all my work. He has messed up something on his system. Zvezdan Petkovic ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] character garble
On Sat, Oct 15, 2005 at 05:38:43AM -0600, D. E. Evans wrote: > This is the original BSD man started in 1987. OpenBSD is a > continuation of NetBSD, a continuation of 386BSD, which is a > branch of 4.3 BSD (and later 4.4 BSD Lite). With only a few > exceptions, groff being one of them, most of the software is > original to BSD, and is not a project that would be familiar to > GNU. It's quite familiar to most of the people. > I overwrote the existing groff 1.15 that was installed to the > system, so I am fairly certain. However, is there something I > can do to test it to make sure? Now, why on earth would you do this This could very well be the source of all your problems. Why are you messing up with the carefully tuned system files. What's wrong with installing groff-1.19.2 into another directory (/usr/local/bin is used for external stuff on OpenBSD) and set your PATH to have that directory first. I personally put it in opt in my own home directory and have $HOME/opt/bin first in my path. Thus, groff-1.19.2 is always used instead of the system's 1.15. But I also didn't mess up anything in the system. Of course, when configuring groff for compilation you have to pass the option --prefix=$HOME/opt and -with-X11-appresdir $HOME/opt/etc/X11 (I'm not sure of the exact name of this second option, but it's in the help for configure). Although, I still strongly believe that you need to set up the environment variables as I told you before MANPAGER="more -R" export MANPAGER Also, if you are trying SGR... don't forget to set it AND export it. If it still doesn't work, you've learned important lessons. 1. You _must_ read the documentation for a software. 2. You never _ever_ use the root account to install the new software until you have it tested in your own account, by using configure appropriately. 3. You never _ever_ overwrite the system files with your own stuff, because they will be overwritten on the first update of that system part. I always thought OpenBSD users know better than this. I wish you good luck and less use of rootly powers for no reason. Zvezdan Petkovic ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Would I dare to post here?
On Sun, Oct 16, 2005 at 05:15:59PM +1000, Miklos Somogyi wrote: > Soon I'll need groff so I subscribed to this mailing list. I've read > many interesting and useful things here > but after the latest posts I am not sure that I would dare to ask a > question at [EMAIL PROTECTED] Let me try to explain my "incivility", please. The thread in question is much longer than my single post, and if you read it all you will see that the original poster has claimed repeatedly that the answers he has received do not work because he has OpenBSD. Since I'm using the same system every day, I've sent him a two line solution to his problem. The posts have continued in a thread even after that. When I've seen what he has actually done, I replied the way I did. Let's now consider the "incivility" of my answer. > Things like these: > > "Now, why on earth would you do this" > "Why are you messing up with the carefully tuned system files." > "But I also didn't mess up anything ..." > "People have already told you..." > "... as I told you before..." > "I always thought OpenBSD users know better than this." This is the tone that OpenBSD user will find on OpenBSD lists all the time when they do something extremely wrong. (And overwriting system files is considered extremely wrong.) In that regard I do not feel "uncivil" at all. I sincerely wondered why would one do something like that, and the _fact_ is that he was repeatedly told the same things. However, I grant you that this is a groff mailing list and I do sincerely apologise if my tone has offended anybody. But, please grant me the right to be tired by the fact that somebody can't apply simple instructions and wastes _my_ time. Did you notice how in real life (work environment) people tend to quite rudely dismiss you if they have something better to do than talk with you at the moment? > put you on a pedestal (that you may richly deserve), but they also make > the recipient's face red. And you are not putting yourself on a pedestal of higher morality by scolding me? > He is not likely to come back for another serving, you have just turned > a friend into an enemy. I don't think so. If he really uses groff, he'll come back. > You may be an expert in all thing Unix, but a "user" is most likely to > operate the beast to accomplish a task other than Unix/groff what have > you. In this case he wanted to accomplish the task of using groff on a variant of Unix. So your point is not right here. > And in many other respect he/she may know orders of magnitude more > than you do. Probably about chemistry and agriculture. Never got time to learn too much about those. :-) Which has nothing to do with groff and OpenBSD. Which was the point of the thread. Otherwise I'm quite happy with the extent of my knowledge and its diversity. > If you want to help with your superior knowledge, that's fine. But it > can be done within the bounds of civility. Before you click on the > post button, just please consider how would you feel on the receiving > end of your own post. I would feel scolded as I do now. You do not realize that your words are not at all different than mine. The difference is that I scolded a person who wasted everybody's time because of his own error. You are scolding a person who tried to help him extremely politely and concisely at first, but dismissed him later because I had better things to do. > I wish you good luck and less use of destructive phrasing. Thanks. Zvezdan Petkovic ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Would I dare to post here?
On Sun, Oct 16, 2005 at 07:34:09AM -0500, Alejandro López-Valencia wrote: > I share your vision. We are here to share our knowledge, learn from > those who know more than we do and help those who know less than we do > so that they may one day surpass us; that is teach, in the true sense > of the word. Alejandro, There are students that will surpass you, and that will be the greatest reward of you as a teacher. Then, there are those that you'd prefer to keep quiet about the fact that you taught them. Because they didn't learn anything. And that was probably not your fault. Rather it was either their intellectual (in)capability or (as is often the case) they didn't care despite being smart. And then, there's an average Joe that will neither surpass you, nor you will feel bad about teaching him, but Joe will be grateful for your shared wisdom, and you will appreciate that Joe worked hard and submitted every homework on time. Well, you see, the Joe in our case neither came to class nor did he do the homework. And the teacher got tired of seeing Joe in his office repeatedly asking the same questions that were already answered. So the teacher told Joe to go back home and study the basics (in not very minced words). Now the teacher is rude, and Joe is the poor victim. Right. Zvezdan Petkovic ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Would I dare to post here?
On Mon, Oct 17, 2005 at 01:08:27AM +1000, Miklos Somogyi wrote: > The only "positive" is on your side, that you feel superior to the > other guy. > But that's arrogance, not education, don't you agree? I genuinely wondered why would someone overwrite system files, when they will be overwritten back on the first update? There wasn't a bit of intentional arrogance in my post, although it apparently came through as such. Sorry again. You really do not realise that you are committing the same sin? What makes you morally better than the other guy. I bet you really never lost the patience. > And we should know that arrogance has many nasty side effects. > I still remember how much I wanted that little forerunner of a Unix > workstation, before Microsoft came along. > How could it happen that they ate alive a technically far-far superior > and free Unix? > > I think that the arrogance of many of Unix's proponents had a lot to do > with it. Your dad is probably computationally > literate and you certainly don't think that he is stupid. Now show him > a few Unix man pages and ask him > to make sense of symlinks and Co. > Would you tell him that he is no good, or would you realize that the > writers did not have the slightest clue about writing? They failed the > first test, that you should know who you are writing for. With all due respect this is not true. Professional UNIX systems (Solaris, HP-UX, ...) didn't ask a user to read man pages. They provided graphical interfaces and help. The problem is that they cost between $5000-1. That's why your dad couldn't afford them, so he bought a PC. Are you saying that Microsoft help system is of any use to a clueless user? They are equally impenetrable as UNIX man pages. Microsoft has won the race (at least for now) because of the adopt-and-extend strategy. They took what was good (adopt a windowing environment of Macintosh and UNIX workstations), extended it to offer a consistent look and feel, and (most importantly) packaged it with a cheap PC that was an extensible architecture (using cheap ISA/PCI cards). Now, compare that with Sun machine running Solaris where you had to pay $1000 for a replacement disk only. That's why Microsoft succeeded. Small business is exactly that, small. They don't have money for expensive UNIX workstations and sysadmin to maintain them. They do not need all the reliability guarantees. They buy a cheap PC. But when you sum up all small businesses in the world it amounts to a huge market share. > Those who only know how to write for themselves, naturally try to make > a virtue out of their inability by insisting that the whole world now > should rise to their high level by reading this, analysing that, > experiment with those, all Unix. Off base, again. The person in question asked about groff on OpenBSD. That's a not-very-user-friendly typesetting system on a not-very-user-friendly OS. I exactly knew my audience. I wasn't answering a question of some grandma who can't find Outlook icon on a toolbar. Since this is how this all started, please tell me what's so complicated (uncivil) and only for myself about my FIRST post. "I'm using the same system. Put this into your .profile (or equivalent for (t)csh) MANPAGER="more -R" export MANPAGER Why did you need an upgrade of texinfo? groff works fine for me with the system default texinfo." I'm repeating I knew where my audience is coming from. A groff user on an OpenBSD. The only problem seems to be that you want to make him something that he's not. I'm getting the feeling that you've got a grudge about something in general and now using my post to vent it on the list. > That they are designers of cars or rockets, and would rather spend time > to learn more about thermodynamics, just doesn't matter, because Unix > is the one and all. Well, it is good, very good. But it is not all, it > is not even at the top of the food chain. In my case, when I started using UNIX I did that because I was designing a new microprocessor and the programs I needed ran only on UNIX (I used VAX before that). But as every good craftsman I learned the tools of my trade. You can't be a carpenter unless you learn how to use an adze. And again, the guy wanted to use groff on UNIX, so your comparison is off the base. > I hope that you agree with this little perspective and then we can go > back to the wonders and problems of groff. > With a bit of humility, if possible. I agree. We're way off the topic. Trust me. You've made your point. I've learned something in the process. Never too late for that. :-) Zvezdan Petkovic ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] character garble
On Sun, Oct 16, 2005 at 10:10:18PM -0400, Larry Kollar wrote: > Isn't that a little harsh? I overwrite the default groff installed > in MacOS X all the time. I simply built a .pkg file and re-install > it when Apple's system updates make it necessary. Granted it is. Two reasons: 1. On OpenBSD packages install in /usr/local One has to jump through hoops to make a port install in the other place, and experience tells me that the hoops are usually there for a good reason to stop you from doing it. 2. OpenBSD people security audit a lot of code that goes into a base OS. For example, Apache web server is much safer than the one that a person can download from apache.org and install from source. That's why I avoid changing system files. Unless it is enabled in a clean way by the developers. For example, sendmail is not built with SASL authentication as it comes in default OS. However, if you want it, you just put WANT_SMTPAUTH=yes in /etc/mk.conf and even when the system sendmail is updated your option will be respected. > The important thing is to make sure your build works properly > before installing it over the default version. Exactly. Very important point. Best regards, Zvezdan Petkovic ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Introduction
On Mon, Oct 17, 2005 at 05:50:55PM -0600, D. E. Evans wrote:
>The removal of the escape characters, etc., for a compatible output
>with OpenBSD's default, (this would be a configure option). For
>now, I guess a simple note (to the INSTALL file) that man -R needs
>to be set globally to the system profile.
Other people will certainly know about configuration more.
There are several options, though, without changing groff configuration.
1. Set in a user .profile or .login
(or /etc/profile _and_ /etc/csh.login if you want it for the
whole system)
MANPAGER="more -R"
export MANPAGER
or for csh users
setenv MANPAGER "more -R"
(PAGER works also if MANPAGER is not defined [but it is])
I use this solution in my .profile because it doesn't
subtract anything. It only adds value, making my man pager,
more, which is a hard link for less on OpenBSD, understand
colour escapes.
2. Set in a user .profile or .login
(or /etc/profile _and_ /etc/csh.login if you want it for the
whole system)
GROFF_NO_SGR=1
export GROFF_NO_SGR
or for csh users
setenv GROFF_NO_SGR 1
I used this solution initially when I started working with
1.18 version of groff. I abandoned it because it subtracts
value from all possible uses of nroff.
In other words, I wanted it for man pages, but not for other
applications of nroff.
3. In /etc/man.conf on OpenBSD 3.7 there are exactly ten
appearances of /usr/bin/nroff between the lines 19 and 28.
Nine of them use the option -man, and one uses -me.
Replace 'nroff' with 'groff -Tascii -P-c'.
Let me explain. I didn't replace system's groff installation
in /usr/bin, but I did the following experiment:
a) my PATH is already set to use my own installation of
groff-1.19.2 in $HOME/opt/bin.
b) unset MANPAGER
c) unset GROFF_NO_SGR
When I try 'man ImageMagick' now, the output is
garbled because /etc/man.conf calls
/usr/bin/nroff (version 1.15), which calls
grotty (found in my path; version 1.19.2).
d) cp /etc/man.conf ~/
e) edit it as described above (only $HOME/opt/bin/groff
instead of /usr/bin/groff because of my setup)
Now, try
man -C ~/man.conf ImageMagick
and it works like a charm.
The conclusion: if I put this changed man.conf in
/etc/man.conf it will work for the whole system under the
condition that groff-1.19.2 is first in everybody's PATH.
That should be true if you installed it over the original
system files.
I just got this idea, noticing that I used such options on a
personal document I needed in PDF, HTML, and ASCII text. To
produce ASCII text I passed options to groff (this is from my
Makefile):
GROFFTEXTOPTS ?= ${GROFFOPTS} -Tascii -P-bcou
Of these, -P-bcou are passed to grotty to avoid making any
extra output. Neither the colour escapes, nor the old
overstriking to produce bold and underline.
Just plain ASCII.
Of interest here is -c only, because we do want overstriking
for the old style man pages.
Thus, the benefit of this third approach, in comparison to 1.
above is that you get the old style man pages if you prefer
them. The benefit in comparison to 2. above is that you get
the new groff/nroff behaviour for other applications that are
not related to man pages.
Obviously, I chose 1. for my personal use, but for the use on the
system level, you can pick whichever you find the most suitable.
> Perhaps Zvezdan could clarify how this was done under
> /usr/src/gnu/usr.bin/groff (of the OpenBSD source) with 1.15?
> (Or was this a change made with a newer edition of groff?)
This one is easy and short.
Nothing was changed, because this feature was made default in 1.18.
Best regards,
Zvezdan Petkovic
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] XML and groff as frontend
On Wed, Oct 19, 2005 at 10:51:45PM -0600, D. E. Evans wrote: > groff is now a major component in a majority (I would think) of > UNIX systems, and UNIX variants. It is used for online manuals, > and print manuals; it is used for writing documentation, memos, > letters, and so on. I don't agree with this assessment. Take a look at O'Reilly books (colophon section). Until recently they all were converted from format X into groff and printed. Take a look at books written by W. R. Stevens. Even the updated editions after his death are done by the new co-authors in groff. I think that limiting groff to "documentation, memos, letters, and manuals" is not right. Regards, Zvezdan Petkovic ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] XML and groff as frontend
On Fri, Oct 21, 2005 at 10:23:25AM +0300, Greg 'groggy' Lehey wrote: > On Thursday, 20 October 2005 at 15:07:32 -0400, Zvezdan Petkovic wrote: > > Take a look at O'Reilly books (colophon section). Until recently > > they all were converted from format X into groff and printed. > > Has this changed? A while back I looked at their conversion software > and ported it to FreeBSD (/usr/ports/textproc/gmat). Unfortunately, > it's probably no longer buildable; there are some strange kludges in > there, and once I no longer had to use it, I didn't. Unfortunately, yes. The colophon of the recent O'Reilly books indicates that they were typeset in FrameMaker instead of groff. I really liked Garamond better than this Birka font they are using now too. :-) > > Take a look at books written by W. R. Stevens. Even the updated > > editions after his death are done by the new co-authors in groff. > > My books are also written in groff. Greg, I've seen your books online (I'm a BSD user after all), but didn't have an opportunity to browse through them and I am not a proud owner. It's worth mentioning some other people whose books I do own that are written in groff (and I'm talking about the recent books here, not the 80's works): Brian Kernighan, Marshal Kirk McKusick, Bjarne Stroustrup, Andrew Tanenbaum. It seems that _real_ UNIX books are written in groff. :-) > > > I think that limiting groff to "documentation, memos, letters, and > > manuals" is not right. > > I didn't see a limitation above. But I think it's fair to say that > the majority of books are *not* written in groff. Even the O'Reilly > books are usually written in XML DocBook and converted to groff; this > process is painful enough that I gave up on it. Correct. Many scientific books these days seem to be in LaTeX, and of course everything else is the "other" programs. I also agree with your assessment of XML DocBook. I've written a long manual in it, hoping to develop a skill I thought I will need. It was a total disappointment. I have developed a Vim filetype plugin for DocBook that allows me to use a lot of abbreviations. It opens a second narrow vertical buffer with all the DocBook keywords (and boy are there many!) so I can pick them up from there after which it closes and inserts an element of that type. The plugin also has a set of functions for quick commenting/uncommenting, enclosing the selected text with a matching pair of open/close elements, ... And despite all this, it was a pain I do not want to repeat. Yes, I even don't feel sorry for that nice plugin collecting the "electronic dust" on my disk drive. There's a certain beauty in writing just .LP, .lp, or .P to start a paragraph. :-) I do like the content sensitive mark-up, but mdoc approach is much more sane. And people who tell me that I should use a graphical front-end for XML mark-up are equally clueless. It's not faster at all to move my hand towards the mouse, find the menu, and choose one of 200 DocBook elements just to put a word in constant-width font (as it turns out eventually in PDF, HTML, or any other of DocBook supported formats). Ridiculous. It is a fantastic way to lose the concentration during writing. As I progressed through my manual I diligently tagged each word that should be tagged, got tired of that and ended up basically writing the plain ASCII text just to be able to concentrate on writing. Then I went through a text for proofreading and used my Vim function (bound to a keystroke) to enclose words in tags selected from the narrow vertical buffer with DocBook keywords. > A more interesting question is: can you point to a book written in > groff (not just converted to and formatted by groff) with serious > layout problems? Hmm. That's a good one. I think I always recognise books typeset in groff in (La)TeX by a certain pedantic quality to them. I think that not only they produce a high-quality layout, but also the people who prefer to use them are sensitive to detail. How many people prepare index for their book in such painstaking detail as the late Stevens used to (http://www.kohala.com/start/indexing.html). I doubt that people who choose to write a book in Word bother at all. Best regards, Zvezdan Petkovic ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] XML and groff as frontend
On Sat, Oct 22, 2005 at 03:47:19PM -0400, Larry Kollar wrote: > I use structured FrameMaker at work to write documentation, and one of > the easier ways I've found to get text into it is to paste it into > Vim then pipe lines through scripts that wrap blocks of text in tags > (lists, sections, and so forth). I then import that into Frame. It > works very well, although the technique is probably specific to the > writer and the work involved. That's also a nice example of how painful is writing in XML. You use a totally different tool (Vim) to help another tool that's supposedly made to help you with XML (FrameMaker). Also, sections and lists are the least of my issues with XML. Paragraphs like this one are the problem (quite frequent when writing about computing): Use either cp -a or cp -Rdp when copying, to preserve as much of the original attributes of an application. Then in rootfs/sbin make a hard link from mke2fs to both mkfs.ext2 and mkfs.ext3. If you count the characters in markup elements, they'll come quite close to the number of characters in the real content of the paragraph. I did the markup after writing, because the number of interruptions of the thought process is mind-boggling otherwise. Best regards, Zvezdan Petkovic ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Introduction
On Sat, Oct 22, 2005 at 02:40:10PM +0100, Ted Harding wrote: > Basically the repertoire of keystrokes, which seem to resemble > EMACS ones; OK if you remember them, which I don't (apart from > SPACE and BS). However, to be fair, it does seem that 'info' has > become more transparent over the last year or two than it used > to be. There's a good info viewer that is more like lynx than info. It's called pinfo, and I use it all the time for reading info pages. If it can't find info page it shows a man page (try 'pinfo cp'). The key bindings are familiar to UNIX users (think 'more') and extra features of info are supported with bindings that vi(m) users will love. :-) If you don't like the default colours you can use my .pinforc attached below (change mutt to your own mail program; pine was the default). Zvezdan Petkovic COL_BOTTOMLINE = COLOR_YELLOW, COLOR_BLUE, BOLD, NO_BLINK COL_INFOHIGHLIGHT = COLOR_CYAN, COLOR_BLACK,BOLD, NO_BLINK # pinfo reverses bold and italic attributes in man pages :-( COL_MANUALBOLD = COLOR_CYAN, COLOR_BLACK,BOLD, NO_BLINK COL_MANUALITALIC= COLOR_GREEN, COLOR_BLACK,BOLD, NO_BLINK COL_MENUSELECTED= COLOR_RED,COLOR_BLACK,BOLD, NO_BLINK COL_NOTESELECTED= COLOR_RED,COLOR_BLACK,BOLD, NO_BLINK COL_TOPLINE = COLOR_YELLOW, COLOR_BLUE, BOLD, NO_BLINK COL_URLSELECTED = COLOR_RED,COLOR_BLACK,BOLD, NO_BLINK MAILEDITOR=mutt ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] XML and groff as frontend
On Sat, Oct 22, 2005 at 11:45:50PM +0100, Ted Harding wrote: > Well, if you're using vim ... I do. > First enter the following (in command mode) to define abbreviations: > > :ab [cut a lot of good advice] You mean something like iabbrev byiwi<ea> fileref="" \format="linespecific">pa>-$h :-) I have a full Vim plugin that contains not only the most frequently used abbreviations, but also a function to enclose words in an arbitrary chosen DocBook XML element chosen from a small narrow buffer that opens on the right side of my Vim window with a list of all DocBook elements. It doesn't sing or dance though because I stopped working on it the minute I lost interest in editing more DocBook documents. :-) Best regards, Zvezdan Petkovic ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Introduction
On Sun, Oct 23, 2005 at 03:05:34AM +0200, Bernd Warken wrote: > > Zvezdan Petkovic wrote: > > > > There's a good info viewer that is more like lynx than info. > > It's called pinfo, and I use it all the time for reading info pages. > > Another possibility is dwww. I have it on a Linux Debian system, I do > not know how it is called on other systems. > > With dwww you can view info files, man pages, and other documentation > with a web browser. The needed html is generated on-the-fly. Even > links are created such that you can view other man pages by clicking > in a man page. Exactly the same as pinfo. For example, tar(1) in a text of a cp man page, is a hyperlink to tar man page. Advantage of pinfo to me is that it's like lynx browser that I was familiar with (and many other people are). Best regards, Zvezdan Petkovic ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Re: [Fwd: pdfmark troubles]
On Wed, Nov 02, 2005 at 08:09:44AM -0800, Amber Hassaan wrote:
> Hi everyone,
> Please , tell me, how the pdfroff or
> groff works with LaTeX as mentioned below
> > > They work with -mm (because of gpresent files),
> > -ms, -me, and
> > > even (La)TeX.
> > >
> regards
> amber
Amber, please read it again.
> > Zvezdan Petkovic wrote:
> > > When I get some time, I'll take a careful look at pdfroff script
> > > and see how I can incorporate it in my set of Makefiles.
> > > They work with -mm (because of gpresent files), -ms, -me, and
> > > even (La)TeX.
The pronoun "They" refers to _Makefiles_ that I have for document
processing. They are made in such a manner that I can process .mm, .ms,
.me, .mpr (for -mpresent) and .tex files with them.
I just type 'make' and the output in PostScript or PDF is produced.
If there are more than one kind of document in the directory they are
either all made, or I can limit it to one only by defining, for example,
DOCS=mydoc.ms
in the local.mk file.
It works for me, and I bet every serious groffer has some set of
Makefiles like that for their personal use.
However, I never said that I use pdfroff on (La)TeX files.
In fact these are the lines in my Makefile you are interested in.
# TeX #
.dvi.ps:
${DVIPS} ${DVIPSOPTS} -o $@ $<
.tex.bbl:
${TEX} $<
-${BIBTEX} $<
.tex.dvi:
for i in 1 2 3 ; do ${TEX:pdf%=%} $< ; done >${TEX:pdf%=%}.log
.tex.pdf:
for i in 1 2 3 ; do ${TEX} $< ; done >${TEX}.log
(for loop above is to resolve the references in (La)TeX with 3 passes)
where the variables are defined (among many others for groff) as
DVIPS ?= dvips
BIBTEX ?= bibtex
TEX ?= pdflatex
and
DVIPSOPTS ?= -Ppdf
As you can see it's pure TeX and it's totally off topic for this list.
Best regards,
Zvezdan Petkovic
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Re: What's missing for Unicode support of groff?
Werner,
On Sun, Dec 11, 2005 at 08:05:59AM +0100, Werner LEMBERG wrote:
> This is interesting, since it looks like a problem with sed. You are
> using BSD sed, right? Please show us what the following expression
> yields:
>
> makeinfo --version | sed 's/^.* \([^ ]\+\)$/\1/;1q'
The problem is in the sed expression.
This is a GNU sed or even vim regular expression, but not a POSIX sed
regular expression.
You can read about BSD sed (which is a superset of POSIX sed) here:
http://www.openbsd.org/cgi-bin/man.cgi?query=sed
That will tell you that sed uses basic regular expressions (not extended
like egrep).
It will also point you in Sed Regular Expression section to
re_format(7) manual page
http://www.openbsd.org/cgi-bin/man.cgi?query=re_format
That page has in the section Basic Regular Expressions, first bullet,
o `|', `+', and `?' are ordinary characters and there is no equiva-
lent for their functionality.
Thus your expression should have been (only \+ has been replaced
with \{1,\} below):
's/^.* \([^ ]\{1,\}\)$/\1/;1q'
In fact, I'd rather use
sed -e 's/^.* \([^ ]\{1,\}\)$/\1/' -e '1q'
it's more readable.
>
> with GNU sed, I get `4.8'. Then I have
>
> echo 4.8 | sed 's/^\([0-9]*\).*$/\1/'
This one is fine.
>
> ==> 4
>
> echo 4.8 | sed 's/^[^.]\+\(.*\)$/\1/'
This one needs to be changed into
sed 's/^[^.]\{1,\}\(.*\)$/\1/'
>
> ==> .8
>
> echo .8 | sed 's/\.\([0-9]*\).*$/\1/'
This one is fine.
>
> ==> 8
>
> The various sed expressions are there to handle various possible
> version info strings like `4', `4.8', or `4.8.1'.
>
> Before applying your patch I want to know the reason for the failure,
> probably reporting it to both the BSD sed and autoconf people. Maybe
> my original regexps are non-POSIX...
As somebody already mentioned there is no sed maintainer for BSD.
It's a part of a whole OS, that is maintained as a single CVS tree.
I suggest not to report it though.
I'm quite certain you'd get a reply that it won't be changed from what
POSIX suggests.
Changing the expressions as I suggested above is the easiest path to
take.
I hope this was helpful.
Best regards,
Zvezdan Petkovic
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Re: What's missing for Unicode support of groff?
On Mon, Dec 12, 2005 at 12:36:06AM +0100, Bernd Warken wrote:
>
> [EMAIL PROTECTED] schrieb am 12.12.05 00:12:28:
> >
> > On the whole, for maximum portability, I'd be inclined to adopt the syntax
> > suggested by Zvezdan, i.e.
> >
> > sed -e 's/^.* \([^ ]\{1,\}\)$/\1/' -e '1q'
> >
> The \{...\} construct might be critical as well. So the best way might be to
> replace c+ or c\{1,\} by cc*
>
> sed -e 's/^.* \([^ ][^ ]*\)$/\1/' -e '1q'
>
POSIX sed has \{...\}.
I'm not aware of any sed implementation with which it doesn't work.
However, I'm currently able to test it only on Solaris, HP-UX, Linux and
OpenBSD.
Do you know of any example where it doesn't work?
Otherwise we might go even deeper and say that \(...\) is questionable,
etc. But I think there's no need for it.
The expressions \{...\} and \(...\) is a part of BREs (Basic Regular
Expressions) for a long time.
Just my two cents.
Best regards,
Zvezdan Petkovic
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Adding fonts to groff -- instructions?
Resending a message that didn't show up on the list initially. On Sat, Mar 11, 2006 at 05:19:27PM +1100, Robert Marks wrote: > Although I've been using t/groff for almost 30 years (all my > word/text processing, including letters (with PostScript > letterheads), memos, academic papers, and lecture handouts and PDF > overheads (using the present package for the mm macros), using > PostScript output to the printer and for making PDFs, > I have never added a font to groff myself. That's generally a good approach. Don't do something unless you really need it. :-) > Now I want to add an ESSTIX font (which comes with .pfb, .afm, .pfm, > and .ttf files) and the only doc I can find is in the momdoc appendices, > at http://faustus.dyn.ca/mom/momdoc/appendices.html#FONTS > but registration of the new font is Debian-specific. This is a good information. You may want to disregard some of it since you have afm files already. I recently wanted to use with my slides a TrueType font for monospaced text (program code) that is used in the figures in the book I teach from. Funny thing is that I am on the list of credits for ttf2pt1, yet I didn't feel like compiling it so I rather used ttf2afm (part of pdfTeX) which is installed on most UNIX systems. Once I had afm files the procedure was simple. > Are there any more general instructions? Have I missed some? I don't claim that these are general but they are short and straightforward. I assume that the latest groff version is installed in $HOME/opt/, so $GROFF=$HOME/opt/share/groff, and actual fonts are in $HOME/.fonts/TrueType. I also assume that Ghostscript is installed. 1. mkdir $GROFF/site-font/devps 2. cd $GROFF/site-font/devps 3. For each .ttf file run ttf2afm $HOME/.fonts/TrueType/fontname.ttf -o fontname.afm 4. For each .afm file run afmtodit -e text.enc fontname.afm textmap FN where FN is the font name groff will use. For example, I chose LGR as a name for LetterGothic Regular. I added -i option for italic and -n for monospaced fonts (see man page). I removed *.afm files from $GROFF/site-font/devps 4. cd $HOME/.fonts 5. create Fontmap directory in $HOME/.fonts with entries such as % Aliases % ... /LetterGothic /LetterGothic-Reg ; /LetterGothic-Roman /LetterGothic-Reg ; /LetterGothic-Italic/LetterGothic-Ita ; /LetterGothic-Bold /LetterGothic-Bol ; /LetterGothic-BoldItalic/LetterGothic-BolIta; % ... 6. put these three lines in $HOME/.profile (or equivalent for .login) GS_FONTPATH=$HOME/.fonts/TrueType GS_LIB=$HOME/.fonts export GS_FONTPATH GS_LIB Now, groff sees my LGR, LGI, LGB, and LGBI fonts since they are in the standard groff path. Ghostscript can also see them thanks to the environment variables set up in .profile. It embeds them in PDF perfectly fine. Thanks to the aliases, Ghostscript can use them for the EPS files from the book too. As an added benefit, since fonts are in $HOME/.fonts I have them available even for my X applications by defining $HOME/.fonts.conf file with an entry: ... LetterGothic monospace ... Now I can start xterm -fa LetterGothic if I feel so inclined. I don't. :-) I hope this helps. All the best. Zvezdan Petkovic ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Adding fonts to groff -- instructions?
On Sat, Mar 11, 2006 at 05:19:27PM +1100, Robert Marks wrote: > Although I've been using t/groff for almost 30 years (all my > word/text processing, including letters (with PostScript > letterheads), memos, academic papers, and lecture handouts and PDF > overheads (using the present package for the mm macros), using > PostScript output to the printer and for making PDFs, > I have never added a font to groff myself. That's generally a good approach. Don't do something unless you really need it. :-) > Now I want to add an ESSTIX font (which comes with .pfb, .afm, .pfm, > and .ttf files) and the only doc I can find is in the momdoc appendices, > at http://faustus.dyn.ca/mom/momdoc/appendices.html#FONTS > but registration of the new font is Debian-specific. This is a good information. You may want to disregard some of it since you have afm files already. I recently wanted to use with my slides a TrueType font for monospaced text (program code) that is used in the figures in the book I teach from. Funny thing is that I am on the list of credits for ttf2pt1, yet I didn't feel like compiling it so I rather used ttf2afm (part of pdfTeX) which is installed on most UNIX systems. Once I had afm files the procedure was simple. > Are there any more general instructions? Have I missed some? I don't claim that these are general but they are short and straightforward. I assume that the latest groff version is installed in $HOME/opt/, so $GROFF=$HOME/opt/share/groff, and actual fonts are in $HOME/.fonts/TrueType. I also assume that Ghostscript is installed. 1. mkdir $GROFF/site-font/devps 2. cd $GROFF/site-font/devps 3. For each .ttf file run ttf2afm $HOME/.fonts/TrueType/fontname.ttf -o fontname.afm 4. For each .afm file run afmtodit -e text.enc fontname.afm textmap FN where FN is the font name groff will use. For example, I chose LGR as a name for LetterGothic Regular. I added -i option for italic and -n for monospaced fonts (see man page). I removed *.afm files from $GROFF/site-font/devps 4. cd $HOME/.fonts 5. create Fontmap directory in $HOME/.fonts with entries such as % Aliases % ... /LetterGothic /LetterGothic-Reg ; /LetterGothic-Roman /LetterGothic-Reg ; /LetterGothic-Italic/LetterGothic-Ita ; /LetterGothic-Bold /LetterGothic-Bol ; /LetterGothic-BoldItalic/LetterGothic-BolIta; % ... 6. put these three lines in $HOME/.profile (or equivalent for .login) GS_FONTPATH=$HOME/.fonts/TrueType GS_LIB=$HOME/.fonts export GS_FONTPATH GS_LIB Now, groff sees my LGR, LGI, LGB, and LGBI fonts since they are in the standard groff path. Ghostscript can also see them thanks to the environment variables set up in .profile. It embeds them in PDF perfectly fine. Thanks to the aliases, Ghostscript can use them for the EPS files from the book too. As an added benefit, since fonts are in $HOME/.fonts I have them available even for my X applications by defining $HOME/.fonts.conf file with an entry: ... LetterGothic monospace ... Now I can start xterm -fa LetterGothic if I feel so inclined. I don't. :-) I hope this helps. All the best. Zvezdan Petkovic ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Using a Bold Italic font in geqn
On Thu, Mar 30, 2006 at 02:25:43PM +1100, Robert Marks wrote: > Now I want geqn to use the symbols from this fault instead of from > SS. I suppose I could just rename MDUTBIMI (my name for the new > font) SS in font/devps, but isn't there a more elegant way to do it > in a document? (I don't always want to use the new font in geqn.) when I want to replace Courier with another monospaced font on my slides I use font translate request in gpresent source. Below is an excerpt I use. .\" - remap Courier to LetterGothic used in COD book - .ftr C LGR .ftr CR LGR .ftr CI LGI .ftr CB LGB .ftr CBI LGBI .\" - end of remapping - I have a macro that defines that code segments on the slide use bold and the above practically translates it into LGB. Works like a charm. I believe it should work for you too if you translate SS into your MDUTBIMI font. Best regards, Zvezdan Petkovic ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] patch for pdfroff
I use pdfroff a lot.
I also use gpresent a lot.
I process most of my writing using a set of makefiles to automate a task.
The problem is that gpresent _needs_ PostScript input, while pdfroff
removes PostScript and leaves PDF only.
That doesn't help, because it's an exception to the rules in my
makefiles. For gpresent I would have to use regular groff and "home
cooked" PDF markup macros (which I had for quite a time, but pdfroff is
much better).
To cut a long story short, I defined PDFROFF in my makefiles as
pdfroff2. Pdfroff2 is a slightly changed pdfroff script.
I also have defined
PDFROFFOPTS ?= --no-toc-relocation --leave-postscript-only
So I always simply use
${PDFROFF} ${PDFROFFOPTS} ...
The patch against 1.19.2 that creates pdfroff2 is attached below.
Keith is this acceptable to you?
Can it become a part of a regular pdfroff?
Best regards,
Zvezdan Petkovic
--- pdfroff Sat May 27 21:52:40 2006
+++ pdfroff2Sat May 27 21:58:18 2006
@@ -145,6 +145,7 @@
help reference-dictionaryno-reference-dictionary
stylesheet pdf-output no-pdf-output
versionreport-progress no-toc-relocation
+leave-postscript-only
"
# Parse the command line, to identify 'pdfroff' specific options.
# Collect all other parameters into new argument and file lists,
@@ -266,6 +267,10 @@
--no-toc-relocation)
TC_DATA="" TOC_FORMAT="" BODY_FORMAT=""
;;
+
+--leave-postscript-only)
+ LEAVE_POSTSCRIPT_ONLY="YES"
+ ;;
#
# any other non-null match must have matched more than one defined
case,
# so report the ambiguity, and bail out.
@@ -541,15 +546,22 @@
# In all cases, a final 'groff' pass is required, to format the document body.
#
$SAY >&2 $n "Formatting document ... body section ..$c"
- eval $STREAM $GROFF_STYLE $BODY_FORMAT $REFCOPY $INPUT_FILES > $BD_DATA
- $SAY >&2 ". done"
+ if test -n "$LEAVE_POSTSCRIPT_ONLY"
+ then
+eval $STREAM $GROFF_STYLE $BODY_FORMAT $REFCOPY $INPUT_FILES
+$SAY >&2 ". done"
+exit 0
+ else
+eval $STREAM $GROFF_STYLE $BODY_FORMAT $REFCOPY $INPUT_FILES > $BD_DATA
+$SAY >&2 ". done"
+ fi
#
# Finally ...
# Invoke GhostScript as a PDF writer, to bind all of the generated
# PostScript intermediate files into a single PDF output file.
#
$SAY >&2 $n "Writing PDF output ..$c"
- PDFWRITE="$GS -dQUIET -dBATCH -dNOPAUSE -sDEVICE=pdfwrite"
+ PDFWRITE="$GS -dSAFER -dQUIET -dBATCH -dNOPAUSE -sDEVICE=pdfwrite"
#
# (This 'sed' script is a hack, to eliminate redundant blank pages).
#
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] patch for pdfroff
On Fri, Jun 16, 2006 at 03:03:25PM +0100, Keith Marshall wrote:
> Thanks for suggesting this potential enhancement. I think, however, that
> I prefer `--emit-ps', or `--emit-postscript', (one or the other, but not
> both, otherwise abbreviation becomes unwieldy), to your choice of
> `--leave-postscript-output', for the name of the new option.
I agree.
> One problem I do see, with your patch, is that it always assumes that
> `--no-toc-relocation' is the desired behaviour; this may not always be
> the case. Better to define `PDFWRITE="$CAT"', rather than its normal
> `PDFWRITE="$GS ..." definition, if `--emit-ps' is specified, I think.
Well, the patch was for my personal use, and since gpresent generates
TOC for the slides I never really needed that feature.
However, I agree that in general case it should be considered.
The new patch and the patch to the man page are attached.
One issue I had is that your sed script erased completely valid EPS
files (created by ImageMagick convert program from JPG and PNG) embedded
in my presentations. Thus I decided to make it an empty script for
--emit-ps option. If you ever fix it, so that it doesn't remove images,
but rather blank pages only, it could be used without if-else-fi.
Till then, I think it is safer to assume that a user of --emit-ps wants
an unchanged PostScript output.
I'd fix that sed script myself if I had a faintest idea how to
reliably distinguish a valid embedded EPS from a blank page.
> I also note that you've added the `-dSAFER' option to the `gs' invocation.
> I'd prefer not to do that, as not all users may want it. Better to add a
> `--gs-options="option list"' option to pdfroff, so that users can make
> the choice, IMHO. (This is something which was discussed before, but I
> simply haven't found the time to implement it).
No need. I call it from Makefile as
env GS_OPTIONS="-dSAFER" pdfroff ...
Ghostscript respects GS_OPTIONS environment variable.
Best regards,
Zvezdan Petkovic
--- pdfroff.origSat May 27 21:52:40 2006
+++ pdfroff Fri Jun 16 21:38:24 2006
@@ -145,6 +145,7 @@
help reference-dictionaryno-reference-dictionary
stylesheet pdf-output no-pdf-output
versionreport-progress no-toc-relocation
+emit-ps
"
# Parse the command line, to identify 'pdfroff' specific options.
# Collect all other parameters into new argument and file lists,
@@ -230,6 +231,10 @@
normally required to position the table of contents at
the
start of a PDF document.
+ --emit-ps
+ Emit PostScript output instead of PDF.
+ Useful for postprocessors such as gpresent.
+
ETX
exit 0
;;
@@ -266,6 +271,10 @@
--no-toc-relocation)
TC_DATA="" TOC_FORMAT="" BODY_FORMAT=""
;;
+
+--emit-ps)
+ EMIT_PS="YES"
+ ;;
#
# any other non-null match must have matched more than one defined
case,
# so report the ambiguity, and bail out.
@@ -549,22 +558,34 @@
# PostScript intermediate files into a single PDF output file.
#
$SAY >&2 $n "Writing PDF output ..$c"
- PDFWRITE="$GS -dQUIET -dBATCH -dNOPAUSE -sDEVICE=pdfwrite"
+ if test -n "$EMIT_PS"
+ then
+if test -n "$PDF_OUTPUT"
+then
+ $SAY >&2 $n ".\nWARNING: --pdf-output is ignored with --emit-ps ..$c"
+fi
+PDFWRITE="$CAT"
+ERASE_BLANK_PAGES_SCRIPT=''
+ else
+PDFWRITE="$GS -dQUIET -dBATCH -dNOPAUSE -sDEVICE=pdfwrite
-sOutputFile=${PDF_OUTPUT-'-'}"
#
# (This 'sed' script is a hack, to eliminate redundant blank pages).
#
- $SED '
-:again
- /%%EndPageSetup/b finish
- /%%Page:/{
- N
- b again
- }
- b
-:finish
- N
- /^%%Page:.*0 *Cg *EP/d
-' $TC_DATA $BD_DATA | $PDFWRITE -sOutputFile=${PDF_OUTPUT-"-"} $CS_DATA -
+ERASE_BLANK_PAGES_SCRIPT='
+ :again
+/%%EndPageSetup/b finish
+/%%Page:/{
+ N
+ b again
+}
+b
+ :finish
+N
+/^%%Page:.*0 *Cg *EP/d
+ '
+ fi
+
+ $SED "$ERASE_BLANK_PAGES_SCRIPT" $TC_DATA $BD_DATA | $PDFWRITE $CS_DATA -
$SAY >&2 ". done"
#
#
--
--- pdfroff.1.orig Sat May 27 21:52:40 2006
+++ pdfroff.1 Fri Jun 16 18:49:57 2006
@@ -96,6 +96,7 @@
.opta T dev
.opta w name
.opta W name
+.opt -emit-ps
.opt -no-toc-relocation
.opte -stylesheet nam
Re: [Groff] Treatment of annotation paragraphs in refer
On Mon, Jun 19, 2006 at 03:55:10PM -0500, Bill Ward wrote: > However, refer turns the annotation text into one long string defined > using the .ds command and all troff commands are lost; e.g., You can tell it to turn it into something else instead of the default ".ds". For example .R1 annotate X (q .R2 will instruct refer to replace every "X" field with ".(q", which is the beginning of quoted paragraph in -me macros. One can add a closing ".)q" at the end of annotation in the reference. However, I prefer to add the closing ".)q" using a postrefer.sed script from a Makefile. Thus my annotations look like this after refer. .(q annotation .)q and produce a quotation paragraph in slightly smaller font indented inside from the left and right side. > .de [X > First paragraph of annnotation. > .LP > Second paragraph of annotation. > .. I believe it would be better if it just turns it into .LP First paragraph. .LP Second paragraph. > Anyone know of any way to circumvent this problem? I hope the above hint helps. Best regards, Zvezdan Petkovic ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] patch for pdfroff
On Mon, Jul 31, 2006 at 12:14:08AM +0100, Keith Marshall wrote: > > The problem with this sed script was that it would delete EVERYTHING > > from the `%%Page: n n' marker record for a new page, down to the first > > line of PostScript code following the associated `%%EndPageSetup' > > marker, if it matched the regular expression `0 *Cg *EP' ANYWHERE > > within that line range. Clearly, this was too greedy a match > > specification, which could remove page headers where they should have > > been retained, potentially even leading to an invalid PostScript output > > stream. > > > > I've now tightened the requirement... > > But not tightly enough, for it failed my `teapot' test, to the extent > that sed would hang, or segfault, while trying to parse the embedded EPS > photographic images. This too is now fixed in CVS. First of all sorry for not responding earlier. I was on a vacation and couldn't test the new version of pdfroff script. I checked it out today with and without --no-kill-null-pages option. It produces the same PostScript file which is good. The pictures are preserved and they show up on slides. Looks good. Best regards, Zvezdan Petkovic ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Re: Simplifying groff documentation
On Sat, Dec 23, 2006 at 12:25:01AM -0500, Eric S. Raymond wrote: > I *am* "skilled hands" in that sense, having done successful > full-length technical books in all three markups. Speaking from > that experience, I rate groff better than TeX but inferior to a good > DocBook toolchain (with the exception that TeX wins over both if you have > to do really intensive mathematical typesetting). I would classify myself as "skilled hands" too and I agree with your assessment of *roff and TeX (I used both extensively). However, I did write a 10 page technical document (34 with the appendices that simply include the files) in DocBook-XML. I have turned away in disgust and never looked back. This paragraph can be representative of what I thought was wrong: Use either cp -a or cp -Rdp when copying, to preserve as much of the original attributes of an application. Then in rootfs/sbin make a hard link from mke2fs to both mkfs.ext2 and mkfs.ext3. Also the syntax required to just include the files for appendix was incredibly convoluted. .config — kernel configuration file I can be classified as "skilled hands" with both Vim and Emacs. I've made my own Vim filetype plugin to insert DocBook keywords easier. Emacs (which I used to use for more than a decade) already has a DocBook support. Yet, I did not see them as an effective toolchain for a writer. I can't possibly imagine what could be an effective toolchain. One still has to select for each of these words whether they are command, filename, emphasis, acronym (over 100 possibilities in DocBook). The selection must be done through some sort of menu (remembering all 100+ possibilities couldn't be called comfortable I guess). And that is slow, very slow. It's also distracting from the writing. If I don't want to be distracted I could postpone the tagging for later. I'm afraid that then, I could simply omit a tag where I should have put it. I really wanted to start using DocBook more and invested some effort to make it happen. In the end I concluded that it's more of a trouble than it's worth. So I use groff or (La)TeX and produce PDF. You mention above a good DocBook toolchain. Can you give us some detail? What do you use to produce DocBook-XML documents effectively? If you consider that this is off topic for the groff list, you can reply off the list. I'm really interested in giving DocBook another chance. ZP ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] The case against the case against .EX/.EE & .DS/.DE
The point here is on "my" in the sentence above. What Mr. Ritter is saying all this time is that the number of cases simply does not warrant the _unportable_ change to a well established legacy format. If doclifter handles all these cases as well as you already described there is no need for an exception to man format. Best regards, ZP ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Re: Simplifying groff documentation
On Sat, Dec 23, 2006 at 06:01:29PM -0500, Eric S. Raymond wrote: > I use Emacs to edit DocBook markup directly. That's not different from what I've been doing. I wouldn't say that is a comfortable way of writing. > For someone as bothered by tag verbosity as you are I would recommend > using asciidoc, which can generate DocBook. I wonder why asciidoc? Is it really any different from docutils that we are supposed to use for Python program documentation? How about POD that we are supposed to use for Perl program documentation? I think I've learned enough "standard" documentation formats. I do believe that -mdoc already provided a structured (as opposed to presentation-oriented) way of writing *roff documents. I use OpenBSD every day, and the man pages on that system are excellent. The -mdoc macros suffer from the same problem as DocBook -- too many structural tags for comfortable writing. It should be noted however, that writing a precise technical manual requires that kind of tagging. Several editing iterations are needed to write a precise and concise technical manual -- they could as well be used to get all the tags straight. For general writing, which is what I referred to when I asked about the comfortable toolset, I find tagging distracting. Most of the time only a limited subset of tags is needed. I prefer to stay with *roff, define the macros for structured writing, e.g. to tag a filename, and use only the tags I really need. I can quickly change the look of my document with small edits to the macros. I can also quickly translate them with a simple script to any other format (e.g. DocBook). > On the back end, Norm Walsh's stylesheets do a perfectly competent job > of generating HTML. On the print side, I still use the grotty old > PassiveTex stylesheets for previewing and huddle with the specialists > at whatever publishers I'm working with (Addison-Wesley last time out, > O'Reilly before that) to get really good rendering. I used OpenJade, JadeTeX and DSSSL stylesheets. The back engine is TeX in both cases, but the layout format is not very appealing, frankly. One can do much better with pure TeX or *roff and structure macros. > FOP is at 0.92 level now. What with Java going open, I expect the > DocBook -> XSL:FO -> PostScript path via FOP will get really good > sometime in 2007 or early 2008. In other words I need this behemoth: $ pkg_info -s jdk Information for jdk-1.5.0p20 Size: 227110409 just to typeset my documents. And I already have a computer and groff installed on it. Which one I'm going to go for? :-) Don't get me wrong. I understand that we are in the 21st century, and I understand all the advantages that DocBook offers. There is a deeper philosophical question here. Who needs to tag a document for all the sorts of semantic or any other meaning? Is it the author or somebody else? I remember an anecdote about a faculty member from a non-scientific department attending a seminar on use of computers. Her comment was: "Good Lord, you are turning us all into secretaries." Best regards, ZP ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Simplifying groff documentation
On Wed, Dec 27, 2006 at 06:52:13AM -0500, Eric S. Raymond wrote: > I don't think your citation of -mdoc is really on point. IMO, the > reason it hasn't gained acceptance is that, while -mdoc markup is > cleverly designed, it is also quite complex -- more heavyweight than > most man-page writers want to deal with. If you have to deal with it you do. People writing man pages for BSD systems have no trouble with that format. However, this is an interesting observation in general. If -mdoc was refused for the above reason, how accepted DocBook will be? The same programmers who refused Ada embraced Java without seeing that it has brought the same things that Ada offered long time ago without a control of a single corporation over it. Is it only the time when something comes about that determines acceptance or not? Of course, DocBook has many more advantages over -mdoc than Java over Ada, so comparison is probably not fair. Best regards, ZP ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Re: Simplifying groff documentation
On Thu, Dec 28, 2006 at 11:11:34PM -0500, Eric S. Raymond wrote: > > There is a deeper philosophical question here. > > Who needs to tag a document for all the sorts of semantic or any other > > meaning? Is it the author or somebody else? > > Who tags the man pages you write? Who should tag them? I think I answered that in the previous post. There is a part where I said that the technical manuals absolutely require this. Since a great amount of effort is invested to produce concise and precise manual, tagging is not a large part of the effort. The only reason I began writing in DocBook was to make a precise How-To document on a certain topic which could be easily translated to different formats: - text for a terminal lookup (lynx -dump) - HTML for a browser lookup (GUI browser presumably) - print (non-technical people love this) I thought that DocBook gives me all of the above and a semantic context as a plus. I do believe that it is an excellent format for technical manuals and a very good documentation tool for system administrators, for example. > This isn't a silly or confrontational question -- because doclifter > can turm your man pages into high-quality DocBook markup, it's > actually the *same* question. I know. Please don't take my questions as confrontational. What I was more concerned with is general writing. Does an author of the book need to bother with semantic tagging on a scale that DocBook _requires_? Is it a task for a publisher if they want it? That's why I cited that anecdote about the old professor. She simply thought it preposterous that she needs to learn how to type and how to use a word processor -- she had a secretary for that. :-) One could argue that she had a backwards view of the world and no respect for other people's work. But then, why don't we all go and work on farms or beside a lathe in a factory to show a respect for people who do the things we could have done on our own. Or could we? One could also argue that a person who has been educated for so long a time to do a certain kind of work can spend her time more productively than typing (or semantic tagging). That's what might be wrong with DocBook or any XML format. People who have something to write about are usually not happy spending time on a work unrelated to what they want to write about (such as tagging). Of course, if the publishers don't have to pay somebody else to typeset or semantically tag the book (at least not completely), all the better for them. I doubt that authors writing in DocBook charge separately for the semantic tagging. On the other hand they certainly leave a good tip if a waiter in a restaurant they dined in showed any extra effort in serving them. Does the semantic tagging make the book look better? Does it make it express the ideas better? Why the author should do it? I'm a computer professional. I tend to do all the things by myself. I'm questioning whether I, or anyone else who does it themselves, should reconsider. Is the time invested worth it? Best regards, Zvezdan ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Re: Simplifying groff documentation
On Thu, Dec 28, 2006 at 08:51:37PM -0800, Meg McRoberts wrote: > I'm not sure of the solution but it seems that, if they could write in > docbook, this opens the option of using an XML WYSIWYG editor if > necessary. Which does not make the writing any faster. Picking one of 100+ tags from the menu is no fun. :-) ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
[Groff] grohtml and non-ms macros
I personally use groff for PDF and PostScript documents, so I did not
care for grohtml too much. The recent discussion about doclifter
prompted me to recheck, and it seems to be a little -ms centric.
This is a part of a paragraph from an -me document.
.lp
Let's look again at an $n$-bit integer
$[ x sub n-1 , x sub n-2 , . . . , x sub 1 , x sub 0 ]$.
It can be viewed as a bit vector $x vec$.
One way to look at it is a binary number with $n$ digits.
That is the
.i unsigned
interpretation of $x vec$:
.EQ
U({x vec}) = sum from i=0 to n-1 x sub i 2 sup i
.EN
It is translated using grohtml.
groff -I. -I/home/zvezdan/share/tmac -Iimages/inforepr -Rpte \
-P'-s 10' -Thtml -me -mpdfmark >inforepr.html
First, if I don't define -Iimages/inforepr all images are stored in my
tmac directory (which should be really used by soelim only).
Secondly, the HTML counterpart of the above paragraph looks like this:
Let’s
look again at an
-bit integer
. It can be viewed as a bit vector
. One way to look at it is a binary number with
digits. That is the unsigned
interpretation
of
:
U(
→
x)=
ni−1=0
Σ x
i
2
i
After this point all the letters are too small for comfortable reading.
Questions:
- This is not a too complicated paragraph, yet is it broken in
two paragraphs at "interpretation of". Why?
- Where five levels of come from?
(The document of 5 pages ends up with 7 levels).
Best regards,
Zvezdan
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Progress report on the portability audit -- and what to do about URLs?
On Wednesday 10 January 2007 18:59, Eric S. Raymond wrote: > Gunnar Ritter <[EMAIL PROTECTED]>: > > > I believe you are incorrect. If these definitions are *in the > > > file*, won't the Solarix/AIX/HP-UX toolchain evaluate them the > > > same way they would evaluate any other local macro? > > > > No, I was quoting ".URL and .MTO" which you cut away, and > > for rather obvious reason they will not. > > Um...are we misunderstanding each other? Yes. > I have not removed any instances of .URL or .MTO. He was referring to the quote in the email message he sent. You cut out that part in your reply to his message. Zvezdan ___ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
Re: [Groff] Correct protocol for making changes
On Fri, Feb 02, 2007 at 07:44:10PM +0100, Werner LEMBERG wrote: > . The proper way to write an ellipsis is `.\|.\|.\&', optionally > starting with `\&'. Please don't omit the `\|' -- it looks quite > ugly in PostScript output if the dots don't have enough horizontal > separation. Doesn't it look typographically even better as `\|.\|.\|.\&'. I think this is what eqn sequence `. . .' gets translated into. Best regards, Zvezdan
Re: [Groff] Correct protocol for making changes
On Sat, Feb 03, 2007 at 12:01:45AM +0100, Gunnar Ritter wrote: > Zvezdan Petkovic <[EMAIL PROTECTED]> wrote: > > > On Fri, Feb 02, 2007 at 07:44:10PM +0100, Werner LEMBERG wrote: > > > . The proper way to write an ellipsis is `.\|.\|.\&', optionally > > > starting with `\&'. Please don't omit the `\|' -- it looks quite > > > ugly in PostScript output if the dots don't have enough horizontal > > > separation. > > > > Doesn't it look typographically even better as `\|.\|.\|.\&'. > > I think this is what eqn sequence `. . .' gets translated into. > > In general, this depends on language and style guide. I know that it can depend on language. Some style guides are more authoritative than other. I was referring to English and usage in this form: .ds eL \|.\|.\|.\& sentence goes on\*(eL where the first \| provides that extra spacing between the last word and the first dot. Yet, the spacing is smaller than a full space which is a little unseemly. I'm not sure from Werner's explanation whether he assumes the usage with the space between the word and ellipsis: .ds eL .\|.\|.\& sentence goes on \*(eL or the usage with no space between the word and ellipsis: sentence goes on\*(eL > For example, the Chicago Manual of Style uses to put whole > spaces between the dots, and this indeed is common usage > in American books. Exactly. Diana Hacker's "A Writer's Reference" states: "The ellipsis mark consists of three spaced periods." and proceeds to give an example: "over . . . 300 milligrams" Furthermore, it says: "If you delete a full sentence or more in the middle of a quoted passage, use a period before the three ellipsis dots." It also cautions against using the ellipsis mark at the beginning or end of a quotation unless some words have been cut from the end of the final sentence quoted. She also shows an example of use of the ellipsis to mark a hesitation or interruption in speech to suggest unfinished thoughts. "Before falling into a coma, the victim whispered, 'It was a man with a tattoo on his. . . .'" To my eye, \| space looks better than a full length space here. Perhaps I am wrong and the full space should be used between the word and ellipsis. > p.s. While `. . .' has a special meaning in troff, it is > doubtful whether it should be used in emails or other text > files, see <http://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html>. I followed Werner's style here (see the part of his quoted message at the top). I usually don't use these quotes even in troff. I write .q "quoted text" instead. Best regards, Zvezdan
Re: [Groff] Correct protocol for making changes
On Sat, Feb 03, 2007 at 12:13:40AM +0100, Werner LEMBERG wrote: > > > Doesn't it look typographically even better as `\|.\|.\|.\&'. > > > I think this is what eqn sequence `. . .' gets translated into. > > > > In general, this depends on language and style guide. > > Indeed. Within groff, James always has used .\|.\|. for situations > like > > 1, 2, ... > > (and this is basically the way I want to use ellipses). I want to > stay with it. > > > Werner This implies the full space before the ellipsis, right? .ds eL .\|.\|. 1, 2, \*(eL instead of what I thought looks less asymmetric .ds eL \|.\|.\|. 1, 2,\*(eL I might be quite wrong on this, of course. Well, we never stop learning. I guess your judgment in these matters has a "little" more value. Best regards, Zvezdan
Re: [Groff] ChangeLog entries
On Mon, Feb 05, 2007 at 12:26:28PM -0500, Eric S. Raymond wrote: > While we're on the subject, though, I must say that I think traditional > GNU-style Changelogs are obsolete and irritating. It's a convention that > made a lot of sense before use of VCSes became common, but nowadays my > Changelog is normally my VCS commit-message trail. I agree with this. It's completely redundant. A good and precise check-in comment should be enough. Using tools like CVSweb enables a clear visual overview of changes done: when, how, and why? Best regards, Zvezdan
Re: [Groff] Vim/formatting question (WordPerfect files)
On Tue, Mar 13, 2007 at 03:15:08PM -0600, Clarke Echols wrote: > Words are separated by a single character that displays in vim as > a (blue) couple of characters: ( ~@ ) and there are other characters > showing up as ( ^U, ^^, ^@, ) etc.I know how to do regular > expression search and replace for control characters like ^U, but > this ~@ stuff is something I don't know how to specify in a search > string. Select that blue character ~@ and save it in a file (say, tryme.txt). Then run from a command line od -x tryme.txt See what hex code it is (for example, ^@ is 0d). Then in Vim say :%s/\%x0d/ /g or whatever you want to replace it with instead of space. > Any clues? Or an easy way to convert this to plain text without > buying a bunch of software? Take a look at :help regex in Vim for more regex features in Vim. > I'm a vim/groff bigot and don't like canned "authoring" software-- > especially if I have to pay for it. :-) I don't blame you. :-) Best regards, ZP
Re: [Groff] Vim/formatting question (WordPerfect files)
On Tue, Mar 13, 2007 at 03:04:21PM -0700, Nick Stoughton wrote: > Try using tr ... The character '^@' is a null byte (for tr, this is > '\000'). You can strip out all control chars by: He asked about ~@, not [EMAIL PROTECTED] The easiest way to find what it represents is saving it in another file and running od -x on the file. > tr -d '[:cntrl:]' < xxx.wpd > xxx.txt > > (or, in vim: gg!Gtr -d '[:cntrl:]') > > This won't strip out chars with the top bit set, but read the man page! As far as I understand he would like to replace them with a space rather than just strip them. Again, he can do this in Vim too: :%s/[[:cntrl:]]\+/ /g This will replace any run of 1 or more control characters with one space. Best regards, ZP
Re: [Groff] Refer and Journals
On Thu, Mar 15, 2007 at 09:36:22AM -0700, Frank Jahnke wrote:
> If that is so, do the readers of this list have some "standard" ones
> already worked out? It would be useful to pool these, so that we
> don't all have to reinvent the wheel.
First, a disclaimer.
I use -me most of the time, but couple of years ago, as I was writing
modifications for refer to get the refer macros right for -me I
implemented this for -ms. I don't know how general these are but they
worked for my needs at the time. Also notice that for the full
conformance with ACM style the names should be reversed and the first
name should be shortened to the initial only (e.g., Petkovic, Z.).
I'm sending this not as some serious contribution (more testing and
checking is probably necessary). I'm sending it because it may help the
original poster get around his problems with refer after small
modifications.
Best regards,
Zvezdan
.\" ACM-ms.tmac - refer support for -ms
.\"
.\" Conforms to the _Communications of the ACM_ reference style.
.\" The only exception is that author names are not reversed and shortened.
.\"
.\" Zvezdan Petkovic
.\"
.\"
.\" module ref
.\"
.\" Refer support.
.de ]-
.rm [A [B [C [D [E [G [I [J [N [O [P [Q [R [S [T [V [W
.rm ref*string
..
.\" Other
.ds ref*spec!0 Q A T2 N S V I C D P O
.\" Journal article
.ds ref*spec!1 Q A T2 J V2 N2 D I C P O
.\" Book
.ds ref*spec!2 Q A T N S V I C D P O
.\" Article within book
.ds ref*spec!3 Q A T2 B W E N S V I C D P O
.\" Tech report
.ds ref*spec!4 Q A T2 R G I C D P O
.\" ][ type
.de ][
.if r [T .als [T2 [T
.if d [V .als [V2 [V
.if d [N .als [N2 [N
.ie d ref*spec!\\$1 .ref*build \\*[ref*spec!\\$1]
.el \{\
. @error unknown reference type `\\$1'
. ref*build \\*[ref*spec!0]
.\}
.ref*print
.rm ref*string
.rm [F [T2 [V2 [N2
..
.\" start of reference number
.\"ds [. [EMAIL PROTECTED]
.\" end of reference number
.\"ds .] [EMAIL PROTECTED]
.\" period before reference
.\"ds <. .
.\" period after reference
.\"ds >. \" empty
.\" comma before reference
.\"ds <, ,
.\" comma after reference
.\"ds >, \" empty
.\" start collected references
.ig
.de ]<
.als ref*print ref*end-print
.SH
\&\\*[REFERENCES]
[EMAIL PROTECTED]
..
.\" end collected references
.ig
.de ]>
[EMAIL PROTECTED]
.als ref*print ref*normal-print
..
.ig
.de ref*normal-print
.ie d [F .FS "\\*([.\\*([F\\*(.]"
.el .FS \&
\\*[ref*string]
.FE
..
.ig
.de ref*end-print
.ie d [F .IP "\\*([F."
.el .XP
\\*[ref*string]
..
.ig
.als ref*print ref*normal-print
.de ref*build
.rm ref*string ref*post-punct
.nr ref*suppress-period 1
.while \\n[.$] \{\
. if d [\\$1 \{\
. ie d ref*add-\\$1 .ref*add-\\$1
. el .ref*add-dflt \\$1
. \}
. shift
.\}
.\" now add a final period
.ie d ref*string \{\
. if !\\n[ref*suppress-period] .as ref*string .
. if d ref*post-punct \{\
. as ref*string "\\*[ref*post-punct]
. rm ref*post-punct
. \}
.\}
.el .ds ref*string
..
.de ref*add-T
.ref*field T . "\fI" "\fP"
.if r [T .nr ref*suppress-period \\n([T
..
.de ref*add-T2
.ref*field T .
.if r [T .nr ref*suppress-period \\n([T
..
.de ref*add-V
.ie d [S .ref*field V , "vol. "
.el .ref*field V . "Vol. "
..
.de ref*add-V2
.ie d [N .ref*field V "" "\fI" "\fP"
.el .ref*field V "" "\fIVolume " "\fP"
..
.de ref*add-N
.ie d [V .rm [N
.el .ref*field N . "Number "
..
.de ref*add-N2
.ie d [V .ref*field N ,
.el .ref*field N ""
..
.de ref*add-S
.\" [V has a precedence over [N, [N over nothing, hence this order
.ie d [V .ref*field S .
.el .if d [N .ref*field S "" "in "
.el .ref*field S .
..
.de ref*add-J
.ref*field J . "\fI" "\fP"
..
.de ref*add-W
.ref*field W "" ( ", \\*([D)"
..
.de ref*add-D
.ie d [J .ref*field D "" ( )
.el .ie d [W .rm [D
.el .ie d [C .ref*field D ,
.el .ie d [I .ref*field D ,
.el .ie d [G .ref*field D ,
.el .ie d [R .ref*field D ,
.el .ref*field D .
..
.de ref*add-E
.ie [W .ref*field E . "" ", Ed"
.el .ref*field E , "" ", Ed"
..
.de ref*add-G
.ref*field G "" ( )
..
.de ref*add-B
.ref*field B . "In \fI" "\fP"
..
.de ref*add-O
.ref*field O .
.ie r [O .nr ref*suppress-period \\n([O
.el .nr ref*suppress-period 1
..
.de ref*add-A
.ref*field A .
.if r [A .nr ref*suppress-period \\n([A
..
.de ref*add-C
.ref*field C ,
..
.de ref*add-I
.ie d [G ref*field I ,
.el .ie d [R .ref*field I ,
.el .ref*field I .
..
.de ref*add-P
.ie d [D .ref*field P ,
.el .ie d [C .ref*field P
Re: [Groff] Venn Diagram in Pic?
On Wed, Sep 12, 2007 at 10:12:46AM -0400, Webb Roberts wrote:
> What is the easiest way to get a Venn diagram in Groff? Pic doesn't
> seem to like overlapping shapes.
You can get away with hatching.
I attached the file that does a simple variant of that.
Best regards,
Zvezdan
.PS
.fam H
define hatch_circle {
pi = atan2(0, -1)
start = $1
end = start + 6
opposite = 2 * start + 16
for i = start to end do {
dxr = circlerad * cos(i * pi/16)
dyr = circlerad * sin(i * pi/16)
dxl = circlerad * cos((opposite-i) * pi/16)
dyl = circlerad * sin((opposite-i) * pi/16)
line from last circle.c + (dxr, dyr) \
to last circle.c + (dxl, dyl) colour "$2"
line from last circle.c + (-dxr, -dyr) \
to last circle.c + (-dxl, -dyl) colour "$2"
}
}
circle outline "red"
hatch_circle(0, red)
circle with .c at last circle.c + (circlerad, 0) outline "blue"
hatch_circle(4, blue)
circle with .c at last circle.c + (-circlerad/2, -circlerad) outline "green"
hatch_circle(8, green)
.PE
Re: [Groff] eqn troubles
On Sep 29, 2008, at 3:09 PM, Stefan Tramm wrote: On Mac OS X 10.5.5 (with all latest patches applied) eqn(1) seems to be broken! Confirmed. Mac OS X Leopard with all the updates applied (same uname -a output as Stefan's except the host name). It does not work. I tried it with the Heirloom troff I compiled last year on the same machine (installed in $HOME/opt). $ PATH=~/opt/ucb:$PATH $ cat >ted.msted.ps << EOT .EQ x = { Y + Z } over { A + B } times ( C + D ) .EN EOT $ open ted.ps Works. I hope this helps Miklos. Zvezdan
Re: [Groff] GSView question (groff-PostScript viewer)
On Sep 29, 2008, at 3:23 PM, Clarke Echols wrote: On my old setup, I was using groff running in a bash shell as part of the cygwin package, and got the shareware PostScript viewer "GSView" which I really like for several reasons. If you are not after flashy viewers, "gv" is still the best PostScript viewer for Linux. It has all three features you need AFAIR. Zvezdan
Re: [Groff] eqn troubles
On Sep 30, 2008, at 6:14 AM, Ralph Corderoy wrote: Is there somewhere to raise bugs with Apple so it might get addressed sometime? http://developer.apple.com/bugreporter/ Apparently, one needs to register as an Apple Developer. There is a free registration option. I intend to do that for a long time already, but for some reason never found enough motivation to actually fill the form. If nobody else on the list has registered already, I could try to motivate myself over the weekend. :-) It keeps cropping up from time to time. Was it some bison/yacc problem? I can't recall. I'm not sure what exactly the problem was. I bet a mail list search or Google search could answer that. That should be an easy part. I think that even filing a report with sample inputs from this thread and the output one gets on Mac OS X 10.5 (Leopard) should be a good amount of information for Apple to work on. Zvezdan
Re: [Groff] GNU Bazaar import of Groff
I don't really want to get into a major revision control system fight here; as I said earlier it seems to be clearly Werner's decision. I didn't want to leave undefended assertions lying around though! I did not use bzr, but based on information I've seen, these are not "undefended assertions". See, for example, http://www.python.org/dev/peps/pep-0374/#tests-impressions Those numbers look bad to me, and the only indication to the contrary is that version 1.9 "should" bring the numbers down. A "should" is probably not good enough next to two competitors that already have numbers to show. The Mozilla project had similar benchmarking experience. http://weblogs.mozillazine.org/preed/2007/04/version_control_system_shootou_1.html There are several very large projects that use Mercurial. Linux kernel is the most prominent user of git. I believe that bzr has its success stories as well. However, when someone needs to decide which DVCS to switch to (from cvs or svn), bzr really does not stand out for me. Canonical actively pushes it on open-source developers with the marketing campaigns at conferences, or this import of groff tree :-). It certainly is in Canonical's interest to do that. I'm not convinced it's in my interest, though. Then again, I might be completely wrong and uninformed. ;-) Zvezdan
