tag:old.nabble.com,2006:forum-1672Nabble - Groff2009-11-24T05:15:06ZThe Groff (GNU Troff) software is a typesetting package which reads plain text mixed with formatting commands and produces formatted output. Groff now supports HTML. Groff home is <a href="http://www.gnu.org/software/groff/groff.html" target="_top" rel="nofollow">here</a>.tag:old.nabble.com,2006:post-26495652Re: Filtering our control characters2009-11-24T05:15:06Z2009-11-24T05:15:06ZWerner LEMBERG<br>> There's an extra dash required, see groff(1) for more details.
<br>>
<br>> groff -man -Tlatin1 -P-cbu
<br><br>Oops, thanks for the correction!
<br><br><br> Werner
<br><br><br><p>From forum: <a href="http://old.nabble.com/Groff---General-f1673.html" embed="fixTarget[1673]" target="_top" rel="nofollow">Groff - General</a></p>tag:old.nabble.com,2006:post-26491817Re: Filtering our control characters2009-11-23T23:56:34Z2009-11-23T23:56:34ZAnt_222Thank you, Werner and Ralph.
<br>And I was using sed :P
<br><br><br><p>From forum: <a href="http://old.nabble.com/Groff---General-f1673.html" embed="fixTarget[1673]" target="_top" rel="nofollow">Groff - General</a></p>tag:old.nabble.com,2006:post-26495603Re: Memory usage of troff2009-11-23T21:40:36Z2009-11-23T21:40:36ZWerner LEMBERG<br>> The attached patch solves the above problem and also fixes all
<br>> "definitely lost" memleaks reported by valgrind. With that patch
<br>> groff uses about 10MB on my system as well.
<br><br>Applied, thanks. Please note that I need a copyright disclaimer from
<br>you in case you want to contribute more code to groff.
<br><br><br> Werner
<br><br><br><p>From forum: <a href="http://old.nabble.com/Groff---General-f1673.html" embed="fixTarget[1673]" target="_top" rel="nofollow">Groff - General</a></p>tag:old.nabble.com,2006:post-26488476Re: Filtering our control characters2009-11-23T16:11:46Z2009-11-23T16:11:46ZRalph Corderoy<br>Hi Anton,
<br><br>Werner wrote:
<br>> The right solution, mentioned already on this list, is
<br>>
<br>> groff -man -Tlatin1 -Pcbu
<br>>
<br>> to pass flags -c, -b, and -u to `grotty', the tty output driver for
<br>> groff, without any need for `col'.
<br><br>There's an extra dash required, see groff(1) for more details.
<br><br> groff -man -Tlatin1 -P-cbu
<br><br>Cheers,
<br><br><br>Ralph.
<br><br><br><br><p>From forum: <a href="http://old.nabble.com/Groff---General-f1673.html" embed="fixTarget[1673]" target="_top" rel="nofollow">Groff - General</a></p>tag:old.nabble.com,2006:post-26486085Re: Filtering our control characters2009-11-23T13:02:58Z2009-11-23T13:02:58ZWerner LEMBERG>
<br>> I have read that the easiest way to convert
<br>> groff output to text is to filter it using
<br>> the col command.
<br>>
<br>> I tried this:
<br>> groff -man -Tlatin1 test.man | col -bx,
<br><br>The right solution, mentioned already on this list, is
<br><br> groff -man -Tlatin1 -Pcbu
<br><br>to pass flags -c, -b, and -u to `grotty', the tty output driver for
<br>groff, without any need for `col'.
<br><br><br> Werner
<br><br><br><p>From forum: <a href="http://old.nabble.com/Groff---General-f1673.html" embed="fixTarget[1673]" target="_top" rel="nofollow">Groff - General</a></p>tag:old.nabble.com,2006:post-26468454mom macros website is back2009-11-22T11:12:44Z2009-11-22T11:12:44ZPeter Schaffter-4The redesigned site for the mom macros is finally online at it's new
<br>home
<br><br> <a href="http://web.ncf.ca/fs222/mom/mom-01.html" target="_top" rel="nofollow">http://web.ncf.ca/fs222/mom/mom-01.html</a><br><br>Design/editorial comments welcome.
<br><br>--
<br>Peter Schaffter
<br><br><br><br><p>From forum: <a href="http://old.nabble.com/Groff---General-f1673.html" embed="fixTarget[1673]" target="_top" rel="nofollow">Groff - General</a></p>tag:old.nabble.com,2006:post-26465610Filtering our control characters2009-11-22T06:09:01Z2009-11-22T06:09:01ZAnt_222Hello all,
<br><br>I have read that the easiest way to convert
<br>groff output to text is to filter it using
<br>the col command.
<br><br>I tried this:
<br> groff -man -Tlatin1 test.man | col -bx,
<br><br>but in the result section names still con-
<br>tained color-setting characters:
<br><br>1mSection one0m
<br><br>Is one of the tools (groff or col) doing
<br>something wrong?
<br><br>Thanks in advance,
<br>Anton
<br><br><br><p>From forum: <a href="http://old.nabble.com/Groff---General-f1673.html" embed="fixTarget[1673]" target="_top" rel="nofollow">Groff - General</a></p>tag:old.nabble.com,2006:post-26465326Re: Memory usage of troff2009-11-22T05:31:53Z2009-11-22T05:31:53ZMaurice van der Pot-2On Sun, Nov 22, 2009 at 06:52:27AM +0100, Werner LEMBERG wrote:
<br>> > Now I don't know groff/troff so I ask you, is this not excessive?
<br>> > I would like to understand why troff uses so much memory.
<br>>
<br>> It's a bug, fixed on 2009-04-10, I think. Please try the CVS version.
<br>> Using it, the maximum number of allocated heap space (as checked with
<br>> massif) is 10.52MB for the above call on my Linux box.
<br><br>Thanks for that pointer, it was very helpful.
<br><br>I've tried the current version from CVS, but it uses (certain) statem
<br>objects after they have been freed and later frees them again. It looks
<br>like an ownership problem. Nodes delete their statem objects when they
<br>are destroyed, but the same statem objects are deleted when they are
<br>popped from the state machine stack.
<br><br>The attached patch solves the above problem and also fixes all
<br>"definitely lost" memleaks reported by valgrind. With that patch groff
<br>uses about 10MB on my system as well.
<br><br>Regards,
<br>Maurice.
<br><br>--
<br>Maurice van der Pot
<br><br>Gentoo Linux Developer <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26465326&i=0" target="_top" rel="nofollow">griffon26@...</a> <a href="http://www.gentoo.org" target="_top" rel="nofollow">http://www.gentoo.org</a><br>Gnome Planner Developer <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26465326&i=1" target="_top" rel="nofollow">griffon26@...</a> <a href="http://live.gnome.org/Planner" target="_top" rel="nofollow">http://live.gnome.org/Planner</a><br><br><br />Index: src/roff/troff/env.cpp
<br>===================================================================
<br>RCS file: /sources/groff/groff/src/roff/troff/env.cpp,v
<br>retrieving revision 1.22
<br>diff -u -B -r1.22 env.cpp
<br>--- src/roff/troff/env.cpp 5 Jan 2009 20:11:12 -0000 1.22
<br>+++ src/roff/troff/env.cpp 22 Nov 2009 13:16:30 -0000
<br>@@ -2213,14 +2213,15 @@
<br> */
<br> if (curdiv == topdiv && topdiv->before_first_page)
<br> topdiv->begin_page();
<br>- macro *m = new macro;
<br>- m->append_str("devtag:");
<br>+
<br>+ macro m;
<br>+ m.append_str("devtag:");
<br> for (const char *p = nm; *p; p++)
<br> if (!invalid_input_char((unsigned char)*p))
<br>- m->append(*p);
<br>- m->append(' ');
<br>- m->append_int(i);
<br>- return new special_node(*m);
<br>+ m.append(*p);
<br>+ m.append(' ');
<br>+ m.append_int(i);
<br>+ return new special_node(m);
<br> }
<br> return 0;
<br> }
<br>Index: src/roff/troff/input.cpp
<br>===================================================================
<br>RCS file: /sources/groff/groff/src/roff/troff/input.cpp,v
<br>retrieving revision 1.60
<br>diff -u -B -r1.60 input.cpp
<br>--- src/roff/troff/input.cpp 7 May 2009 16:22:17 -0000 1.60
<br>+++ src/roff/troff/input.cpp 22 Nov 2009 13:16:33 -0000
<br>@@ -531,6 +531,8 @@
<br> {
<br> if (t->is_diversion) {
<br> div_level--;
<br>+ if (diversion_state)
<br>+ delete diversion_state;
<br> diversion_state = t->diversion_state;
<br> }
<br> }
<br>@@ -4398,6 +4400,7 @@
<br> args += c;
<br> if (i != limit)
<br> args += ' ';
<br>+ delete p;
<br> }
<br> if (limit > 0) {
<br> args += '\0';
<br>@@ -4419,6 +4422,7 @@
<br> args += '"';
<br> if (i != limit)
<br> args += ' ';
<br>+ delete p;
<br> }
<br> if (limit > 0) {
<br> args += '\0';
<br>@@ -4438,6 +4442,7 @@
<br> }
<br> if (input_stack::space_follows_arg(i))
<br> args += ' ';
<br>+ delete p;
<br> }
<br> if (limit > 0) {
<br> args += '\0';
<br>Index: src/roff/troff/mtsm.cpp
<br>===================================================================
<br>RCS file: /sources/groff/groff/src/roff/troff/mtsm.cpp,v
<br>retrieving revision 1.6
<br>diff -u -B -r1.6 mtsm.cpp
<br>--- src/roff/troff/mtsm.cpp 5 Jan 2009 20:11:12 -0000 1.6
<br>+++ src/roff/troff/mtsm.cpp 22 Nov 2009 13:16:33 -0000
<br>@@ -390,8 +390,6 @@
<br> #endif
<br> if (sp == 0)
<br> fatal("empty state machine stack");
<br>- if (sp->state)
<br>- delete sp->state;
<br> sp->state = 0;
<br> stack *t = sp;
<br> sp = sp->next;
<br><br /> <div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>attachment0</strong> (205 bytes) <a href="http://old.nabble.com/attachment/26465326/0/attachment0" target="_top">Download Attachment</a></div><p>From forum: <a href="http://old.nabble.com/Groff---General-f1673.html" embed="fixTarget[1673]" target="_top" rel="nofollow">Groff - General</a></p>tag:old.nabble.com,2006:post-26463033Re: Memory usage of troff2009-11-21T21:52:27Z2009-11-21T21:52:27ZWerner LEMBERG<br>> Using strace I found that running the following command in the
<br>> specs/libX11 directory requires about 400MB of memory.
<br>>
<br>> troff -ms -dxV="libX11 1.3.2" -I. -dwww-image-template=. -Thtml libX11.ms &> /dev/null
<br>>
<br>> Now I don't know groff/troff so I ask you, is this not excessive?
<br>> I would like to understand why troff uses so much memory.
<br><br>It's a bug, fixed on 2009-04-10, I think. Please try the CVS version.
<br>Using it, the maximum number of allocated heap space (as checked with
<br>massif) is 10.52MB for the above call on my Linux box.
<br><br><br> Werner
<br><br><br><p>From forum: <a href="http://old.nabble.com/Groff---General-f1673.html" embed="fixTarget[1673]" target="_top" rel="nofollow">Groff - General</a></p>tag:old.nabble.com,2006:post-26458929Memory usage of troff2009-11-21T08:05:32Z2009-11-21T08:05:32ZMaurice van der Pot-2Hi,
<br><br>I've just had compilation of libX11 fail on my system because it ran out
<br>of memory during generation of the reference documentation using groff.
<br><br> <a href="http://cgit.freedesktop.org/xorg/lib/libX11/snapshot/libX11-1.3.2.tar.bz2" target="_top" rel="nofollow">http://cgit.freedesktop.org/xorg/lib/libX11/snapshot/libX11-1.3.2.tar.bz2</a><br><br>Using strace I found that running the following command in the
<br>specs/libX11 directory requires about 400MB of memory.
<br><br> troff -ms -dxV="libX11 1.3.2" -I. -dwww-image-template=. -Thtml libX11.ms &> /dev/null
<br><br>Now I don't know groff/troff so I ask you, is this not excessive?
<br>I would like to understand why troff uses so much memory.
<br><br>Valgrind's massif shows a more or less linear increase of memory use over time.
<br>These are the two parts that in the end are responsible for the majority of
<br>allocated memory:
<br><br>--------------------------------------------------------------------------------
<br> n time(i) total(B) useful-heap(B) extra-heap(B) stacks(B)
<br>--------------------------------------------------------------------------------
<br>287 56,715,762,716 403,261,336 381,991,029 21,270,307 0
<br>94.73% (381,991,029B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
<br>->67.59% (272,573,250B) 0x443D3C: string::operator=(string const&) (string.cpp:126)
<br>| ->62.42% (251,730,382B) 0x4278EA: statem::add_tag_ta() (mtsm.cpp:289)
<br>| | ->62.42% (251,730,382B) 0x40CBA4: environment::construct_state(int) (env.cpp:2258)
<br>| | ->60.65% (244,595,650B) 0x410E40: environment::add_char(charinfo*) (env.cpp:316)
<br>| | | ->60.31% (243,210,666B) 0x42153C: process_input_stack() (input.cpp:2834)
<br>| | | | ->60.31% (243,210,666B) 0x4227E1: process_input_file(char const*) (input.cpp:7373)
<br>| | | | ->60.31% (243,210,666B) 0x423918: main (input.cpp:7680)
<br><br>(...)
<br><br>->22.89% (92,301,216B) 0x40CAF8: environment::construct_state(int) (env.cpp:2250)
<br>| ->22.58% (91,041,888B) 0x410E40: environment::add_char(charinfo*) (env.cpp:316)
<br>| | ->22.46% (90,572,496B) 0x42153C: process_input_stack() (input.cpp:2834)
<br>| | | ->22.46% (90,572,496B) 0x4227E1: process_input_file(char const*) (input.cpp:7373)
<br>| | | ->22.46% (90,572,496B) 0x423918: main (input.cpp:7680)
<br>| | |
<br><br>Regards,
<br>Maurice.
<br><br>--
<br>Maurice van der Pot
<br><br>Gentoo Linux Developer <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26458929&i=0" target="_top" rel="nofollow">griffon26@...</a> <a href="http://www.gentoo.org" target="_top" rel="nofollow">http://www.gentoo.org</a><br>Gnome Planner Developer <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26458929&i=1" target="_top" rel="nofollow">griffon26@...</a> <a href="http://live.gnome.org/Planner" target="_top" rel="nofollow">http://live.gnome.org/Planner</a><br><br><br /> <div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>attachment0</strong> (205 bytes) <a href="http://old.nabble.com/attachment/26458929/0/attachment0" target="_top">Download Attachment</a></div><p>From forum: <a href="http://old.nabble.com/Groff---General-f1673.html" embed="fixTarget[1673]" target="_top" rel="nofollow">Groff - General</a></p>tag:old.nabble.com,2006:post-26438472Re: PATCH: string format errors2009-11-19T21:10:59Z2009-11-19T21:10:59ZWerner LEMBERG<br>> In most cases the patch is very simple: just replace
<br>> "printf(string)" with "printf("%s", string)". This is the case of
<br>> Groff =)
<br>>
<br>> The attached patch was made for the 1.20.1 version but also applies
<br>> to the current cvs checkout.
<br><br>Applied, thanks.
<br><br><br> Werner
<br><br><br>_______________________________________________
<br>bug-groff mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26438472&i=0" target="_top" rel="nofollow">bug-groff@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/bug-groff" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/bug-groff</a><br><p>From forum: <a href="http://old.nabble.com/Groff---Bugs-f1674.html" embed="fixTarget[1674]" target="_top" rel="nofollow">Groff - Bugs</a></p>tag:old.nabble.com,2006:post-26432123Re: header and footer in a cv with -mom2009-11-19T11:02:00Z2009-11-19T11:02:00ZPeter Schaffter-4On November 18, 2009 11:03:53 am Jan-Herbert Damm wrote:
<br>> Hello all,
<br>>
<br>> i am picking up my on my own post. It seems the issue was too
<br>> specific, since i didn't get an answer in the summer. Now i am
<br>> trying to be very general (even if this is still only a
<br>> mom-issue..., Peter?).
<br><br>I've been having terrible problems with ISPs and email since
<br>September, owing to a ridiculous number of physical moves, including
<br>the latest to a remote location where high-speed is available only
<br>via satellite. I guess the post I sent regarding your problem
<br>didn't get through, for which I'm sorry. Basically, there was a
<br>reported bug in 1.5-c that caused the sort of problems you've
<br>experienced, and I recommended that you update to mom 1.5-d.
<br><br>Tadziu's suggestion for a fix to 1.5-c should also work, BTW, if you
<br>don't feel like updating right now.
<br><br>It's been--shall we say?--an interesting year for me, with the
<br>result that normal Net activities, including cvs commits and
<br>whatnot, have been at best spotty. I believe things have settled
<br>down now, and hope to get a spiffy new version of the mom homepage
<br>back online shortly.
<br><br>--
<br>Peter Schaffter
<br><br><br><br><p>From forum: <a href="http://old.nabble.com/Groff---General-f1673.html" embed="fixTarget[1673]" target="_top" rel="nofollow">Groff - General</a></p>tag:old.nabble.com,2006:post-26430193PATCH: string format errors2009-11-19T08:51:32Z2009-11-19T08:51:32ZPaulo Ricardo Zanoni-2Hi.
<br><br>Using "printf(string);" is dangerous, might lead to bugs and even
<br>security issues. If the string being printed contains the "%" character
<br>one can do really dangerous things. Even if you think the string in
<br>question might not be dangerous, future code changes might lead that
<br>piece of code to bugs or security holes.
<br><br>Some distributions (like Mandriva) even compile all their sources with
<br>the "-Wformat -Werror=format-security" GCC flag.
<br><br>In most cases the patch is very simple: just replace "printf(string)"
<br>with "printf("%s", string)". This is the case of Groff =)
<br><br>The attached patch was made for the 1.20.1 version but also applies to
<br>the current cvs checkout.
<br><br>Some references:
<br><a href="http://wiki.mandriva.com/en/Development/Packaging/Problems#format_not_a_string_literal_and_no_format_arguments" target="_top" rel="nofollow">http://wiki.mandriva.com/en/Development/Packaging/Problems#format_not_a_string_literal_and_no_format_arguments</a><br><a href="http://wiki.debian.org/Hardening#DEBBUILDHARDENINGFORMAT.28gcc.2BAC8-g.2B-.2B--Wformat-Wformat-security.29" target="_top" rel="nofollow">http://wiki.debian.org/Hardening#DEBBUILDHARDENINGFORMAT.28gcc.2BAC8-g.2B-.2B--Wformat-Wformat-security.29</a><br><a href="http://en.wikipedia.org/wiki/Format_string_attack" target="_top" rel="nofollow">http://en.wikipedia.org/wiki/Format_string_attack</a><br><br>Thanks,
<br>Paulo.
<br><br><br /><tt>[groff-1.20.1-string-format-error.patch]</tt><br /><hr align="left" width="300" /><tt>diff -Nru groff-1.20.1/src/devices/grohtml/post-html.cpp new/src/devices/grohtml/post-html.cpp
<br>--- groff-1.20.1/src/devices/grohtml/post-html.cpp 2009-01-09 12:25:52.000000000 -0200
<br>+++ new/src/devices/grohtml/post-html.cpp 2009-10-30 18:02:18.000000000 -0200
<br>@@ -1588,7 +1588,7 @@
<br>
<br> buffer += as_string(h);
<br> buffer += '\0';
<br>- fprintf(f, buffer.contents());
<br>+ fprintf(f, "%s", buffer.contents());
<br> } else
<br> fputs(g->text_string, f);
<br> h++;
<br>diff -Nru groff-1.20.1/src/roff/troff/node.cpp new/src/roff/troff/node.cpp
<br>--- groff-1.20.1/src/roff/troff/node.cpp 2009-01-09 12:25:52.000000000 -0200
<br>+++ new/src/roff/troff/node.cpp 2009-10-30 17:58:51.000000000 -0200
<br>@@ -2196,7 +2196,7 @@
<br> if (c)
<br> fprintf(stderr, "%c", c);
<br> else
<br>- fprintf(stderr, ci->nm.contents());
<br>+ fprintf(stderr, "%s", ci->nm.contents());
<br> if (push_state)
<br> fprintf(stderr, " <push_state>");
<br> if (state)
<br>diff -Nru groff-1.20.1/src/utils/hpftodit/hpftodit.cpp new/src/utils/hpftodit/hpftodit.cpp
<br>--- groff-1.20.1/src/utils/hpftodit/hpftodit.cpp 2009-01-09 12:25:52.000000000 -0200
<br>+++ new/src/utils/hpftodit/hpftodit.cpp 2009-10-30 18:05:13.000000000 -0200
<br>@@ -870,9 +870,9 @@
<br> else if (!all_flag)
<br> continue;
<br> else if (tfm_type == MSL)
<br>- printf(hp_msl_to_ucode_name(charcode));
<br>+ printf("%s", hp_msl_to_ucode_name(charcode));
<br> else
<br>- printf(unicode_to_ucode_name(charcode));
<br>+ printf("%s", unicode_to_ucode_name(charcode));
<br>
<br> printf("\t%d,%d",
<br> scale(char_table[i].width), scale(char_table[i].ascent));
<br></tt><hr align="left" width="300" /><br />_______________________________________________
<br>bug-groff mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26430193&i=0" target="_top" rel="nofollow">bug-groff@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/bug-groff" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/bug-groff</a><br><p>From forum: <a href="http://old.nabble.com/Groff---Bugs-f1674.html" embed="fixTarget[1674]" target="_top" rel="nofollow">Groff - Bugs</a></p>tag:old.nabble.com,2006:post-26424770Re: header and footer in a cv with -mom2009-11-19T03:40:03Z2009-11-19T03:40:03ZTadziu Hoffmann<br>> Wow!
<br>> That has apparently solved my problem! Thank you!!
<br>> I am really amazed how one can find that in such a big and
<br>> cryptic file.
<br><br>Funny, because it took me probably only 10 minutes to find the
<br>bug, even though I'm not familiar with mom at all. In this
<br>case of course I was lucky because the bug was rather simple.
<br><br>I guess there's two parts to solving problems like this:
<br>experience in working with groff, and a strategy for finding
<br>bugs. However, I'm afraid can't really offer much more than
<br>"insert suitable print statements at strategic positions in the
<br>code to figure out where certain variables get their values",
<br>the crucial point being, of course, figuring out "where" and
<br>"what". Lastly, it comes down to what we call "intuition",
<br>which is probably just a fancy name for "this looks similar
<br>to something I've seen before elsewhere, so why don't we try
<br>something which helped in that other situation".
<br><br><br>> Will i be able to read macrodefinitions like that by digging
<br>> into "info groff"? Or is there another groff howto that i
<br>> should start with?
<br><br>My suggestion is to read the Troff User's Manual
<br><a href="http://plan9.bell-labs.com/cm/cs/cstr/54.ps.gz" target="_top" rel="nofollow">http://plan9.bell-labs.com/cm/cs/cstr/54.ps.gz</a> (which, by the
<br>way, is a most amazing piece of documentation: it's terse and
<br>extremely dense in information, yet still perfectly readable),
<br>play around a bit formatting a simple document using bare groff
<br>without any macro package, and then actually working through the
<br>tutorial at the end of the Troff User's Manual to create your
<br>own rudimentary macro package. This is fun and it illustrates
<br>techniques for dealing with the most common issues encountered
<br>in document formatting and layout.
<br><br><br><br><br><p>From forum: <a href="http://old.nabble.com/Groff---General-f1673.html" embed="fixTarget[1673]" target="_top" rel="nofollow">Groff - General</a></p>tag:old.nabble.com,2006:post-26411787Re: header and footer in a cv with -mom2009-11-18T09:05:33Z2009-11-18T09:05:33ZTadziu Hoffmann<br>This appears to be a bug in mom.
<br>Edit om.tmac, find the places where it says
<br><br> .ds $USERDEF_HDRFTR_VERSO \\$2
<br><br>and
<br><br> .ds $USERDEF_HDRFTR_RECTO \\$2
<br><br>and replace the "\\$2" by "\\$1", since there's a ".shift"
<br>before (which apparently wasn't there in an earlier version).
<br><br><br><br><br><p>From forum: <a href="http://old.nabble.com/Groff---General-f1673.html" embed="fixTarget[1673]" target="_top" rel="nofollow">Groff - General</a></p>tag:old.nabble.com,2006:post-26410565Re: header and footer in a cv with -mom2009-11-18T08:03:53Z2009-11-18T08:03:53ZJan-Herbert DammHello all,
<br><br>i am picking up my on my own post. It seems the issue was too specific, since
<br>i didn't get an answer in the summer. Now i am trying to be very general (even if this is
<br>still only a mom-issue..., Peter?).
<br><br>I cannot reproduce the following example from the mom documentation:
<br><br>---snip-from-momdoc/headfootpage.html----
<br><br>Example 1
<br><br>If you want the same header and footer on every page, here's how you'd do it.
<br><br> .HEADERS_AND_FOOTERS \ +-----------------------+
<br> C "\E*[$TITLE]" \ | Title |
<br> L "^\E*[$AUTHOR]#\*[PAGE#]^" | |
<br> | |
<br> | |
<br> | |
<br> | |
<br> | |
<br> | |
<br> | |
<br> | |
<br> | |
<br> | |
<br> | |
<br> | Author Pg. # |
<br> +-----------------------+
<br>-----end-snip----------
<br><br>I am using this file:
<br><br>-------begin-momfile---
<br>.AUTHOR "Jan-Herbert Damm"
<br>.PRINTSTYLE TYPESET
<br>.TITLE "Test-Document"
<br>.PAPER A4
<br>.HEADERS_AND_FOOTERS \
<br>C "\E*[$TITLE]" \
<br>L "^\E*[$AUTHOR]#\*[PAGE#]^"
<br><br>.START
<br><br>some text
<br>more text
<br><br>.NEWPAGE
<br><br>another page
<br>smore text
<br><br>.NEWPAGE
<br><br>yet another page
<br>and more text
<br><br>.NEWPAGE
<br><br>AND AN OTHER ONE
<br>----end-momfile---
<br><br>i run:
<br><br>groff -mom -P-pa4 test.mom > test.ps
<br><br>or just:
<br><br>groff -mom test.mom > test.ps
<br><br>with the same effect:
<br><br>A regular Docheader on the first page and just lines for headers and footers
<br>on subsequent pages.
<br><br>groff-version is:
<br><br>jan@herb:~$ which groff
<br>/usr/local/bin/groff
<br>jan@herb:~$ /usr/local/bin/groff --version
<br>GNU groff version 1.20.1
<br><br>the file /usr/local/share/groff/.../tmac/om.tmac
<br><br>contains a line stating:
<br><br>version 1.5-c
<br><br><br>Where am i going wrong?
<br><br>thanks
<br><br>jan
<br><br><br><p>From forum: <a href="http://old.nabble.com/Groff---General-f1673.html" embed="fixTarget[1673]" target="_top" rel="nofollow">Groff - General</a></p>tag:old.nabble.com,2006:post-26347486Re: Side coments2009-11-13T22:05:21Z2009-11-13T22:05:21ZWerner LEMBERG<br>> Thank you for the mild rebuke, but info.groff is not exactly my
<br>> friend.
<br><br>Why not? This is even available as a large PDF, if you prefer this
<br>format.
<br><br> <a href="http://groff.ffii.org/groff/groff-1.20.1.pdf" target="_top" rel="nofollow">http://groff.ffii.org/groff/groff-1.20.1.pdf</a><br><br>> [...] I accept that for you "legacy" is the name of the game, and
<br>> that GNU heaven is happy with the status quo, integer arithmetic &
<br>> all things like that included.
<br><br>Well, yes. I could `fix' this, but chances are high to break
<br>something. Tabs have a very special meaning in groff files (BTW, the
<br>situation for TeX is comparable); you should really use them only as
<br>advertized.
<br><br>> I just stated my opinion, I apologize if I offended you.
<br><br>No offence taken!
<br><br><br> Werner
<br><br><br><p>From forum: <a href="http://old.nabble.com/Groff---General-f1673.html" embed="fixTarget[1673]" target="_top" rel="nofollow">Groff - General</a></p>tag:old.nabble.com,2006:post-26344372Re: Side coments2009-11-13T14:13:45Z2009-11-13T14:13:45ZMiklos Somogyi<br>Werner,
<br><br>Thank you for the mild rebuke, but info.groff is not exactly my friend.
<br><br>We are talking about a silly bug that could be fixed in a few minutes.
<br>Much more work is to document it, to circumvent it, writing e-mails
<br>back-n-forth about it. The idea that whilst I am working on something,
<br>I need to be interrupted with a tour to info.groff
<br>about trailing spaces and tabs does not appeal to me.
<br><br>But I accept that for you "legacy" is the name of the game, and that
<br>GNU heaven is happy with the status quo, integer
<br>arithmetic & all things like that included. I just stated my opinion,
<br>I apologize if I offended you.
<br><br>Miklos
<br><br><br>On 14/11/2009, at 00:51 AM, Werner LEMBERG wrote:
<br><div class='shrinkable-quote'><br>>
<br>>> This is a rather inelegant solution but it works.
<br>>>
<br>>> Interesting thing:
<br>>>
<br>>> .so file\" \" does not work (utter chaos)
<br>>
<br>> ??? This works just fine. Are you perhaps missing a final newline?
<br>>
<br>>> .so file <tabs> \" does not work
<br>>
<br>> This is for compatibility with legacy troff; this limitation was there
<br>> from the beginning and is well-documented.
<br>>
<br>>> PS I did not know that I can ignore " at the start of the string
<br>>
<br>> This is documented too. `info groff' is your friend...
<br>>
<br>>
<br>> Werner
</div><br><br><br><p>From forum: <a href="http://old.nabble.com/Groff---General-f1673.html" embed="fixTarget[1673]" target="_top" rel="nofollow">Groff - General</a></p>tag:old.nabble.com,2006:post-26344305Re: Polish characters.2009-11-13T14:06:42Z2009-11-13T14:06:42ZJacek SobczakThank you. I've installed a font with polish glyphs as described in
<br>the grops man page. Now I can produce ps files with polish diacritics.
<br><br>--
<br>Jacek
<br><br>2009/11/13 Werner LEMBERG <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26344305&i=0" target="_top" rel="nofollow">wl@...</a>>:
<br>>> I cannot get all polish special characters in postscript output. The
<br>>> command I invoke is "groff -k -mom -Tps test.mom >test.ps". I can
<br>>> see in the resulting ps file only the characters ć, ó, ł - missing
<br>>> are ą, ż, ś, ź, ę, ń.
<br>>
<br>> I suspect that you don't have PostScript fonts which support those
<br>> glyphs. For example, there is no `eogonek' in the TR font.
<br><br><br><p>From forum: <a href="http://old.nabble.com/Groff---General-f1673.html" embed="fixTarget[1673]" target="_top" rel="nofollow">Groff - General</a></p>tag:old.nabble.com,2006:post-26349911footnote continues emptily to next page2009-11-13T08:36:32Z2009-11-13T08:36:32ZM.Douglas.McIlroyA trouble with footnotes in text processed with groff -ms -e.
<br><br>The footnote in the attached document is inappropriately continued
<br>to the next page, where an apparently bare footnote separator
<br>appears.
<br><br>Tests done with groff 1.20.1.
<br><br>[I suppose the continuation was caused by white space
<br>generated by .EN--apparently a pernicious analog of the
<br>relatively harmless ancient troff bug of sometimes emitting
<br>a blank page after the end of a document.]
<br><br><br><br /> <br />_______________________________________________
<br>bug-groff mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26349911&i=0" target="_top" rel="nofollow">bug-groff@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/bug-groff" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/bug-groff</a><br><div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>anomalousfootnote.ms</strong> (165 bytes) <a href="http://old.nabble.com/attachment/26349911/0/anomalousfootnote.ms" target="_top">Download Attachment</a></div><p>From forum: <a href="http://old.nabble.com/Groff---Bugs-f1674.html" embed="fixTarget[1674]" target="_top" rel="nofollow">Groff - Bugs</a></p>tag:old.nabble.com,2006:post-26336889Re: Side coments2009-11-13T05:51:25Z2009-11-13T05:51:25ZWerner LEMBERG<br>> This is a rather inelegant solution but it works.
<br>>
<br>> Interesting thing:
<br>>
<br>> .so file\" \" does not work (utter chaos)
<br><br>??? This works just fine. Are you perhaps missing a final newline?
<br><br>> .so file <tabs> \" does not work
<br><br>This is for compatibility with legacy troff; this limitation was there
<br>from the beginning and is well-documented.
<br><br>> PS I did not know that I can ignore " at the start of the string
<br><br>This is documented too. `info groff' is your friend...
<br><br><br> Werner
<br><br><br><p>From forum: <a href="http://old.nabble.com/Groff---General-f1673.html" embed="fixTarget[1673]" target="_top" rel="nofollow">Groff - General</a></p>tag:old.nabble.com,2006:post-26336833Re: Side coments2009-11-13T05:47:55Z2009-11-13T05:47:55ZTadziu Hoffmann<br>> Thanks but a string defined by DS (where from?) is not
<br>> accepted as a parameter to a macro.
<br><br>Not sure what you mean. ".DS" is just a wrapper around ".ds"
<br>with the purpose of processing the arguments through groff's
<br>macro argument parser, which allows you to enclose arguments
<br>in double quotes and therefore enables you to terminate the
<br>argument already before the whitespace preceding the comment
<br>escape.
<br><br>Here's a modified version which redefines ".ds" with new
<br>semantics:
<br><br>.rn ds ds-orig
<br>.de ds
<br>.ds-orig \\$1 "\\$2
<br>..
<br>Demo:
<br>.ds yy " foo bar " \" argument terminated by 2nd double quote
<br>-\*(yy-
<br><br><br><br><br><p>From forum: <a href="http://old.nabble.com/Groff---General-f1673.html" embed="fixTarget[1673]" target="_top" rel="nofollow">Groff - General</a></p>tag:old.nabble.com,2006:post-26335764Re: Polish characters.2009-11-13T04:19:08Z2009-11-13T04:19:08ZTed.Harding-2On 12-Nov-09 23:44:11, Werner LEMBERG wrote:
<div class='shrinkable-quote'><br>>
<br>>> I cannot get all polish special characters in postscript output.
<br>>> The command I invoke is "groff -k -mom -Tps test.mom >test.ps".
<br>>> I can see in the resulting ps file only the characters Ä, ó,
<br>>> Å - missing are Ä , ż, Å, ź, Ä, Å.
<br>>
<br>> I suspect that you don't have PostScript fonts which support those
<br>> glyphs. For example, there is no `eogonek' in the TR font.
<br>>
<br>> Werner
</div><br>It can be done -- there is indeed an ogonek in the standard PostScript
<br>fonts. According to the classical PostScript Reference Manual, it is
<br>at position 236 [oc\tal] in the ISOLatin1 ecncoding.
<br><br>However, in groff's .../devps/TR file, it is listed at position
<br>0230 (so there seems to have some change here), and it has groff
<br>name \[ho].
<br><br>There is also an l-slash listed at position 0234, groff name \[l/],
<br>which again in the PostScript Reference Manual is given at position
<br>370 [octal].
<br><br>Apart from the l-slash, all the others can be built as composite
<br>glyphs using accent-definitions.
<br><br>As an example, in the ms-macros you can find (under .\" Accents)
<br>the following:
<br><br>.de acc*over-def
<br>.ds \\$1 \Z'\v'(u;\w'x'*0+\En[rst]-\En[.cht])'\
<br>\h'(u;-\En[skw]+(-\En[.w]-\w'\\$2'/2)+\En[.csk])'\\$2'
<br>..
<br>.de acc*under-def
<br>.ds \\$1 \Z'\v'\En[.cdp]u'\h'(u;-\En[.w]-\w'\\$2'/2)'\\$2'
<br>..
<br><br>and then you can define
<br><br>.acc*over-def ' \'
<br>.acc*over-def dot \[a.]
<br>.char \[ogon] \h'0.5m'\[ho]
<br>.acc*under-def og \[ogon]
<br>.char \[A,] A\*[og]
<br>.char \[N'] N\*'
<br>.char \[Z.] Z\*[dot]
<br><br>Now look at the results of the following:
<br><br>\[A,]\0\0\[N']\0\0\[Z.]
<br><br><br>These are only examples. I will post the full details later
<br>(probably not today, since I am short of time right now).
<br>But the above may serve as templates for you to work it out
<br>for yourself!
<br><br>Hoping this helps,
<br>Ted.
<br><br>--------------------------------------------------------------------
<br>E-Mail: (Ted Harding) <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26335764&i=0" target="_top" rel="nofollow">Ted.Harding@...</a>>
<br>Fax-to-email: +44 (0)870 094 0861
<br>Date: 13-Nov-09 Time: 12:18:55
<br>------------------------------ XFMail ------------------------------
<br><br><br><p>From forum: <a href="http://old.nabble.com/Groff---General-f1673.html" embed="fixTarget[1673]" target="_top" rel="nofollow">Groff - General</a></p>tag:old.nabble.com,2006:post-26335219Re: Side coments2009-11-13T03:29:42Z2009-11-13T03:29:42ZMiklos Somogyi<br>Tadziu,
<br><br>Thanks but a string defined by DS (where from?) is not accepted as a
<br>parameter
<br>to a macro.
<br><br>Miklos
<br><br><br>On 13/11/2009, at 02:12 AM, Tadziu Hoffmann wrote:
<br><div class='shrinkable-quote'><br>>
<br>>> and groff is misbehaving if \" starts with tabs and/or spaces.
<br>>
<br>> The only situation I can think of where comments can't have
<br>> preceding whitespace is ".ds", and this can be worked around
<br>> by something like
<br>>
<br>> .de DS
<br>> .ds \\$1 \\$2
<br>> ..
<br>> Demo:
<br>> .ds xx foo bar \" space belongs to string
<br>> .DS yy "foo bar" \" not here
<br>> -\*(xx-
<br>> -\*(yy-
<br>>
<br>>
<br>>
<br>>
</div><br><br><br><p>From forum: <a href="http://old.nabble.com/Groff---General-f1673.html" embed="fixTarget[1673]" target="_top" rel="nofollow">Groff - General</a></p>tag:old.nabble.com,2006:post-26335143Re: Side coments2009-11-13T03:24:42Z2009-11-13T03:24:42ZMiklos Somogyi<br>Thank you Werner,
<br><br>This is a rather inelegant solution but it works.
<br><br>Interesting thing:
<br><br>.so file\" \" does not work (utter chaos)
<br>.so file <tabs> \" does not work
<br>.so file <spaces. \" it does work
<br><br>Oh my...
<br><br>Miklos
<br><br>PS I did not know that I can ignore " at the start of the string
<br><br>On 13/11/2009, at 10:12 AM, Werner LEMBERG wrote:
<br><div class='shrinkable-quote'><br>>
<br>>
<br>>> I'd like to add
<br>>>
<br>>> \" side comments, aligned
<br>>>
<br>>> to a few things, e.g.
<br>>>
<br>>> .so setup
<br>>> .ds HE "Something - " App 8
<br>>>
<br>>> and groff is misbehaving if \" starts with tabs and/or spaces.
<br>>>
<br>>> There is an escape that can close such things immediately and let me
<br>>> use \" all aligned at the right.
<br>>> Just I can't find it. Tell me please.
<br>>
<br>> You can repeat \", like this:
<br>>
<br>>
<br>> .ds foo This is a string\" \" yes, it is a string
<br>>
<br>> Or do you mean something different?
<br>>
<br>>
<br>> Werner
</div><br><br><br><p>From forum: <a href="http://old.nabble.com/Groff---General-f1673.html" embed="fixTarget[1673]" target="_top" rel="nofollow">Groff - General</a></p>tag:old.nabble.com,2006:post-26328691Re: Polish characters.2009-11-12T15:44:11Z2009-11-12T15:44:11ZWerner LEMBERG<br>> I cannot get all polish special characters in postscript output. The
<br>> command I invoke is "groff -k -mom -Tps test.mom >test.ps". I can
<br>> see in the resulting ps file only the characters ć, ó, ł - missing
<br>> are ą, ż, ś, ź, ę, ń.
<br><br>I suspect that you don't have PostScript fonts which support those
<br>glyphs. For example, there is no `eogonek' in the TR font.
<br><br><br> Werner
<br><p>From forum: <a href="http://old.nabble.com/Groff---General-f1673.html" embed="fixTarget[1673]" target="_top" rel="nofollow">Groff - General</a></p>tag:old.nabble.com,2006:post-26328292Re: Side coments2009-11-12T15:12:57Z2009-11-12T15:12:57ZWerner LEMBERG<br><div class='shrinkable-quote'><br>> I'd like to add
<br>>
<br>> \" side comments, aligned
<br>>
<br>> to a few things, e.g.
<br>>
<br>> .so setup
<br>> .ds HE "Something - " App 8
<br>>
<br>> and groff is misbehaving if \" starts with tabs and/or spaces.
<br>>
<br>> There is an escape that can close such things immediately and let me
<br>> use \" all aligned at the right.
<br>> Just I can't find it. Tell me please.
</div><br>You can repeat \", like this:
<br><br><br> .ds foo This is a string\" \" yes, it is a string
<br><br>Or do you mean something different?
<br><br><br> Werner
<br><br><br><p>From forum: <a href="http://old.nabble.com/Groff---General-f1673.html" embed="fixTarget[1673]" target="_top" rel="nofollow">Groff - General</a></p>tag:old.nabble.com,2006:post-26327564Polish characters.2009-11-12T14:19:00Z2009-11-12T14:19:00ZJacek SobczakHello everybody,
<br><br>I cannot get all polish special characters in postscript output. The
<br>command I invoke is "groff -k -mom -Tps test.mom >test.ps". I can see
<br>in the resulting ps file only the characters ć, ó, ł - missing are ą,
<br>ż, ś, ź, ę, ń. Exactly the same happens to the corresponding capitals.
<br>With the command "groff -k -mom -Tutf8 test.mom" all the special
<br>characters are properly displayed on the console. The version of groff
<br>is 1.20.1 on Debian. What could be wrong?
<br><br>--
<br>Jacek
<br><br><br><p>From forum: <a href="http://old.nabble.com/Groff---General-f1673.html" embed="fixTarget[1673]" target="_top" rel="nofollow">Groff - General</a></p>tag:old.nabble.com,2006:post-26320766Re: Side coments2009-11-12T07:12:36Z2009-11-12T07:12:36ZTadziu Hoffmann<br>> and groff is misbehaving if \" starts with tabs and/or spaces.
<br><br>The only situation I can think of where comments can't have
<br>preceding whitespace is ".ds", and this can be worked around
<br>by something like
<br><br>.de DS
<br>.ds \\$1 \\$2
<br>..
<br>Demo:
<br>.ds xx foo bar \" space belongs to string
<br>.DS yy "foo bar" \" not here
<br>-\*(xx-
<br>-\*(yy-
<br><br><br><br><br><p>From forum: <a href="http://old.nabble.com/Groff---General-f1673.html" embed="fixTarget[1673]" target="_top" rel="nofollow">Groff - General</a></p>tag:old.nabble.com,2006:post-26321635Re: (groff+)ghostscript/us letter/paper size problems2009-11-12T06:49:13Z2009-11-12T06:49:13ZLouis Guillaume-2Mike Bishop wrote:
<br>> I have just spent a happy hour PULLING MY HAIR OUT over misformatted
<br>> troff documents on my printers ... which printed perfectly several
<br>> months ago.
<br>>
<br>> The problem is that recent versions of ghostscript will (often)
<br>> assume a4 paper size, regardless of /etc/paper. This applies
<br>> after ghostscript 8.64-5 but I am not sure which version (8.70 has
<br>> the problem).
<br><br>I don't know much about how this is "supposed" to work with /etc/paper
<br>or /etc/papersize. I always thought those were ghostscript or grops things.
<br><br>If you need to explicitly define a paper size for groff to use (that
<br>isn't the default) I think you need: `-dpaper=letter' in addition to
<br>`-P-pletter'. The latter is for grops.
<br><br>Louis
<br><br><br><br><br><p>From forum: <a href="http://old.nabble.com/Groff---General-f1673.html" embed="fixTarget[1673]" target="_top" rel="nofollow">Groff - General</a></p>tag:old.nabble.com,2006:post-26318621Side coments2009-11-12T05:23:06Z2009-11-12T05:23:06ZMiklos SomogyiI'd like to add
<br><br> \" side comments, aligned
<br><br>to a few things, e.g.
<br><br> .so setup
<br> .ds HE "Something - " App 8
<br><br>and groff is misbehaving if \" starts with tabs and/or spaces.
<br><br>There is an escape that can close such things immediately and let me
<br>use \" all aligned at the right.
<br>Just I can't find it. Tell me please.
<br><br>Miklos
<br><br><br><p>From forum: <a href="http://old.nabble.com/Groff---General-f1673.html" embed="fixTarget[1673]" target="_top" rel="nofollow">Groff - General</a></p>tag:old.nabble.com,2006:post-26273173Re: (groff+)ghostscript/us letter/paper size problems2009-11-09T09:31:47Z2009-11-09T09:31:47ZWerner LEMBERG<br>> The solution is described here--
<br>> <a href="http://ghostscript.com/pipermail/gs-devel/2009-September/008565.html" target="_top" rel="nofollow">http://ghostscript.com/pipermail/gs-devel/2009-September/008565.html</a><br>> and consists of passing an explicit "-P-pletter" when formatting
<br>> your groff source; "groff -pletter ..." doesn't make it on my
<br>> system. Neither did modifying "gs_init.ps" (?)
<br><br>groff option `-p' doesn't take a parameter; it just tells groff to
<br>also use the `pic' preprocessor while processing the data.
<br><br>There's another solution described in groff_font(5): Modify the file
<br><br> /usr/share/groff/1.20.1/font/devps/DESC
<br><br>(or the one in /usr/local/... or whereever) and set up a useful value
<br>for the `papersize' parameter. A good value is
<br><br> papersize /etc/papersize letter
<br><br>If the file `/etc/papersize' contains the system wide paper size in
<br>its first line, it is used. If the file is missing, the next argument
<br>`letter' is taken as a fallback.
<br><br><br> Werner
<br><br><br><p>From forum: <a href="http://old.nabble.com/Groff---General-f1673.html" embed="fixTarget[1673]" target="_top" rel="nofollow">Groff - General</a></p>tag:old.nabble.com,2006:post-26262452(groff+)ghostscript/us letter/paper size problems2009-11-08T23:58:28Z2009-11-08T23:58:28ZMike BishopI have just spent a happy hour PULLING MY HAIR OUT over misformatted
<br>troff documents on my printers ... which printed perfectly several
<br>months ago.
<br><br>The problem is that recent versions of ghostscript will (often)
<br>assume a4 paper size, regardless of /etc/paper. This applies
<br>after ghostscript 8.64-5 but I am not sure which version (8.70 has
<br>the problem).
<br><br>If you use ISO standard paper sizes you are probably okay.
<br><br>The solution is described here--
<br><a href="http://ghostscript.com/pipermail/gs-devel/2009-September/008565.html" target="_top" rel="nofollow">http://ghostscript.com/pipermail/gs-devel/2009-September/008565.html</a><br>and consists of passing an explicit "-P-pletter" when formatting
<br>your groff source; "groff -pletter ..." doesn't make it on my
<br>system. Neither did modifying "gs_init.ps" (?)
<br><br>Other postscript generating programs may do this explicitly
<br>(evince does). surf/zathura users may wish to take note.
<br><br>Hoping this saves you hair,
<br><br>Rgds,
<br>--
<br>Mike (baldy) Bishop
<br>Willow, Alaska
<br><br><br><p>From forum: <a href="http://old.nabble.com/Groff---General-f1673.html" embed="fixTarget[1673]" target="_top" rel="nofollow">Groff - General</a></p>tag:old.nabble.com,2006:post-26102121Setting pdf document properties2009-10-28T14:05:51Z2009-10-28T14:05:51Zsmoore<br>continuing with this stream ....
<br><br>I have a request to set page display preferences,
<br>Page Layout to 'Single Page Continuous' and Zoom to
<br>'Fit Width'.
<br><br>I am having some challenge finding the correct language
<br>reference to determine whether this is possible with
<br>gs pdfwrite.
<br><br>Thanks.
<br><br><br><br><br><p>From forum: <a href="http://old.nabble.com/Groff---General-f1673.html" embed="fixTarget[1673]" target="_top" rel="nofollow">Groff - General</a></p>tag:old.nabble.com,2006:post-26100437Re: Fw: tbl/eqn: # does not work as delimiter2009-10-28T11:53:08Z2009-10-28T11:53:08ZWerner LEMBERG<br>> In your update to eqn.man, I see: [...]
<br><br>Fixed, thanks.
<br><br><br> Werner
<br><br><br><p>From forum: <a href="http://old.nabble.com/Groff---General-f1673.html" embed="fixTarget[1673]" target="_top" rel="nofollow">Groff - General</a></p>