[Groff] picture placing

[walter harms]

Hi list,
is there an easy way to place a picture ?

The design (a4 long):
two on top of each other with 4 and 3 columns. The "empty" column should 
be filled with a piucture. i tried with .PSPIC and \X:import

but causing havoc the to page onlY

basicly it should look like this. 2 tables and X marks the picture.

 +--+--+--+
 +--+--+--+

 +--+--+\/
 +--+--+/\


re,
 walter



___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff

Re: [Groff] picture placing

[walter harms]

hi list,
hi Ted,
finally i got the  macro working
can you please check my changes ? i got the idea from the grops man-page.

.ds mypic \Z'\v'-0.5c'\h'22.5c'\X'ps: import abibild.eps  204 276 404 
516 175000''


please note the \v \h . i used them to place the picture.
Then import name is abibild.eps then the bounding box and the scaling 
factor.


re,
 walter

Someone how knows macros may use this to place logos in headers ?


(Ted Harding) wrote:

On 14-Nov-05 walter harms wrote:

Hi list,
is there an easy way to place a picture ?

The design (a4 long):
two on top of each other with 4 and 3 columns. The "empty" column
should 
be filled with a piucture. i tried with .PSPIC and \X:import

but causing havoc the to page onlY

basicly it should look like this. 2 tables and X marks the picture.

  +--+--+--+
  +--+--+--+

  +--+--+\/
  +--+--+/\

re,
  walter


There are several oprtions for this sort of thing, depending
on precisely what you want to do. I have to make this a quick
reply, so here is one way.

Suppose you want the picture to really belong to the second
table.

Define -- before you embark on the table -- a string

.ds mypic \Z''v'XXXu'\X'ps: import picture.eps llx lly urx ury Wunits''

where:

XXX is the intended height of the picture in units,
picture .eps is the EPS file of your picture,
llx, lly, urx, ury are the coordinates of the bottom left
  and top right coirners of the picture (you get these from the
  "%%BoundingBox: llx lly urx ury" line in the EPS file),
Wunits is the number of units of the printed width of the
  picture that you want (units = 1000xPoints).

You may have to edit some of these numbers (XXX in particular,
also perhaps Wunits) to get the right result.

Then you can set up your table 2 like

.TS
tab(#);
l l l.
Row1 Col1#Row1 Col 2#\*[mypic]
Row2 Col1#Row2 Col2#
...
.TE

The "\Z'...'" in \*[mypic] means that drawing the picture
will cause no displacement of the printing position from
the point where it was initiated, so should not mess up
anything.

And, in other contexts, you can use the same "\Z'...'"
device for the same purpose.

Hoping this helps,
Ted.





___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff

Re: [Groff] How to make EPS?

[walter harms]

hi,
is the usage of gs an option ?
it has program called ps2epsi.

re,
 walter


Michail Vidiassov wrote:

Dear All,

can somebody, please, provide me with a working set of commands
to make a EPS file with groff?
Yes, I did read the FM, but the commands mentioned there did not work 
for me.

Do they work for you?

   Sincerely, Michail
PS.
Werner, if you see me (jumping and waving hands desperately ;),
what about metapost+groff?




___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff





___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff

Re: [Groff] Bullets in manual pages and -K groff option

[walter harms]

if libicons works while iconv() produces wrong results would it be the 
better way to use libiconv in general ? (until iconv() problems are fixed ?)


just my 2 cents,
 walter


Bruno Haible wrote:

Alexander E. Patrakov wrote:

The answer "patch
glibc so that iconv transliterates the bullet to 'o'" is better (and in
fact this is doable), but I think that users of non-Glibc systems (or
old Glibc) will complain if this becomes the official answer.


Why should they complain? They can use GNU libiconv. It transliterates the
bullet to 'o', like you wish.

Bruno



___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff





___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff

Re: [Groff] tbl: Standard column width?

[walter harms]

Hi Werner,
i have noticed the problem also (mostly fixing the problem by adding T{ 
to every line. a max width sepcifierer would be helpfull.

(forcing a wrap ?)

re,
 walter



Werner LEMBERG wrote:

I would like to know, if there is a standard column width, when I use
the .TS macro?


Yes.  If there are N columns, and a text block spans C columns, the
default width of this text block is

  \n[.l]*C/(N+1)

I've added this information to tbl.man.


The problem is, that the result of the following code is wrapped
text in the second column (independent from MANWIDTH), even if I use
expand:


You might try, say,

  lw(5u*\n[.l]u/12u)lw(5u*\n[.l]u/12u)

as the format specificier to slightly increase the width.


Werner


___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff





___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff

Re: [Groff] tbl: Standard column width?

[walter harms]

asume we create a datasheet from a database entry.
normaly you have line of "right" lenght (meaning they do not spoil the 
layout). So your document is nice untill someonly realy uses the max 
size in the database.

A simple version (read you know there is a large line) can be found at
/proc/cpuinfo most lines fit nicely on one line. but the flags entry
(e.g. mine) can be quit large.

/* larges line: */
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pni 
monitor ds_cpl cid xtpr

/* second larges */
model name  : Intel(R) Pentium(R) 4 CPU 2.80GHz

Having a maximum size here would prevent an spoiled layout.

re,
 walter





Werner LEMBERG wrote:

i have noticed the problem also (mostly fixing the problem by adding
T{ to every line. a max width sepcifierer would be helpfull.
(forcing a wrap ?)


I don't really understand.  Please give an example.


Werner





___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff

[Groff] Spam

[walter harms]

hi people,
i get a bunch of spam since a few days via this list.

Am i the only  one or have some more people seen spam also ?

re,
 wh


___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff

Re: [Groff] making tbl created tables fit on the paper

[walter harms]

if the page is not to large you can simply use postscript to rescale.
like 0.9 0.9 scale
of cause this works best if you have a table that fills the whole page.

re,
 wh

ps: of cause it works also the other way around. if the table fits 
nearly a page but leave some ugly gaps use 1.1 1.1 scale to resize :)




Gabriel Diaz wrote:

Hello,

I wonder what kind tricks you use to make big tables that goes beyond
the paper defined boundaries fit on the paper.

How you mangae to fit them? Just changin the point size?

I use the mm macro and in the tables i use the T{ T} to quote text.
But still i need to reduce it more.

Any tips would be appreciated.

Thanks

gabriel


___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff





___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff

Re: [Groff] empty line before .TH in man page produces sometimes an empty page

[walter harms]

hi all,
iff i remember correctly you may use  '\"tep (t for tbl e for eqn p for pic etc)
in the first line to invoke the various precompilers.

re,
 wh


Clarke Echols wrote:
> 
> ABSOLUTELY NO LINES, other than genuine troff/groff comment lines
> should appear in a man page file before the .TH line.  You do *not*
> want troff/groff interpreting *anything* before it encounters the
> .TH macro call because .TH sets up page boundaries, end-of-page
> traps, and a bunch of other stuff that you want fully established
> and settled before you start interpreting text.  This has been the
> case for decades.
> 
> In a source-code (SCCS) or revision (RCS) control environment, the
> first line in the file starts with .\" $Header:  [I think -- it's
> been many years since I did this stuff back in 1989-1992].  The
> RCS or SCCS software then fills in the line with date, revision
> version number, etc., but by making it a comment, it keeps the
> revision information invisible to troff/groff.
> 
> Any line before .TH that is not a comment will create a break in
> no-fill mode, and in fill mode will create a non-empty buffer prior
> to the .TH line, causing unpredictable behavior, depending on various
> environment/status conditions.
> 
> Clarke
> 
> 
> Bernd Warken wrote:
>> Consider the followin short man page:
>>
>> $ cat manpage.1
>> \" comment
>> .TH MANPAGE 1 "2006 Oct 1" "manpage"
>> .SH NAME
>> manpage \- test man page
>>
>> This has a bug: the first line (with the comment) should start with a
>> dot.
>> For example, the man page bash.1 has this bug.
>>
>> Without the dot, this line produces an empty space in the output.  In
>> text
>> or html output, this space is a single empty line, ok.
>>
>> But in ps or dvi output, a whole empty page is created.  I consider
>> this a
>> bug in ps and dvi mode.
>>
>> If you write some text before the .TH request this text is written in a
>> single line even in ps or dvi output.  But as soon as you add a line
>> that is
>> empty or has only spaces or a comment a whole empty page is created
>> in ps or dvi mode.
>>
>> Bernd Warken
>>
>> ___
>> Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
>> Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=02
>>
>>
>>
>> ___
>> Groff mailing list
>> Groff@gnu.org
>> http://lists.gnu.org/mailman/listinfo/groff
>>
> 
> 
> ___
> Groff mailing list
> Groff@gnu.org
> http://lists.gnu.org/mailman/listinfo/groff
> 
> 


___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff

Re: [Groff] groff v. TeX

[walter harms]

Larry Kollar wrote:
> 
> John Poltorak wrote:
> 
>> Can anyone explain what the differences are between groff and TeX and
>> which, if either would be most suitable for producing a magazine?
> 
> They're both typesetters that use plain text files with embedded markup
> to produce output. Both use macro packages to avoid dealing with the raw
> language. Both do a better job of typesetting than other Free or
> commercial offerings (with the possible exception of InDesign and the
> real top-shelf typesetters). In general, these are the differences as I
> see them:
> 
> * groff is faster; TeX's typesetting is a bit better (especially math)
> 
> * groff uses a combination of in-line and whole line markup; TeX is
> in-line only
> 
> * TeX's markup is more verbose
> 
> * LaTeX, the most popular macro package for TeX, severely restricts the
> type of page layouts and styles; groff is somewhat less restrictive
> 

to be fair, LATEX is a macro package


> * groff outputs a wider variety of media: PS, PDF, HTML, and text; TeX
> is primarily PS and PDF, although there are external conversion scripts
> for HTML
> 
> I'm not which which (if either) would be most suitable for producing a
> magazine -- they tend to not have a consistent layout from page to page,
> and you'll have to write some macro magic to flow text around pictures,
> sidebars, and so forth. For anything else, it comes down to which one
> that works best for you & your needs. I learned *roff near the beginning
> of my technical writing career, and I recently switched back to groff
> from FrameMaker. It takes one or two minutes to produce PDFs for a
> 4-volume set of documents running over 750 pages, a job that literally
> took an entire afternoon on my old computer running Frame & would still
> need nearly an hour to complete on the new computer.
> 

Tex/Latex can already work its way around packages and beside Latex there are
much more packages out, with special features for different applications
(e.g. Magazine settings).
It is simple to design a few pages with most of the DTP programs like FM. As 
with
all programming languages it is much of a personal choice to find a tools that 
let
YOU do what you want. Even combinations may be helpful but most settle for one 
tool.
IMHO it takes some time to be familiar with the *ideas* of a program. Even if 
its
hard: take that time; experiment; compare the results, have fun designing !
Most people will recognize the Layout and associate the program



re,
 walter

(trying hard to avoid the 'my lawn is greener that your lawn' problem)




___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff

Re: [Groff] Pic macros for flow charts?

[walter harms]

hi all,

http://citeseer.ist.psu.edu/wolfman89flo.html
was helpful to me.
You can download the description: cs.technion.ac.il/pub/mi...flo.doc.ps.Z 
(upper right corner)

somebody should rescue the document before it get lost forever.

Btw: homepage of Mr. Berry: http://se.uwaterloo.ca/~dberry/
perhaps he still has some code lying around ?

re,
 walter

btw: there is a Flowchart style for Tex :)





Michael Parson wrote:
> On Fri, Oct 13, 2006 at 05:35:09PM -0400, Larry Kollar wrote:
>> Does anyone have any pic code that would make drawing flow charts a
>> little smoother? I've been presented with a flow chart (done in Visio)
>> and think it would be easier to recode it in pic than it would to get
>> a decent EPS from Visio.
> 
> I found a reference to 'flo - a flowchart preprocessor for pic' 
> 
> But only a reference, from 1989, no URLs, source code, anything. :-/
> 


___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff

[Groff] why this warning ?

[walter harms]

hi list,
i have a warning that i do not understand.
the tbl below give a warning: grotty:tab:7: character above first line discarded
(using: groff -t -Tascii tab). Any idea why ?

.TS
tab(|);
l s s s
c c c c.
UEBERSCHRIFT
a|b|c|d
a|b|c|d
a|b|c|d
.TE

i use groff 1.18.1 from suse 10.0

re,
 walter


___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff

Re: [Groff] why this warning ?

[walter harms]

I am sure it is harmless but as usual this happens if you try to
show one something 

re,
 wh


Werner LEMBERG wrote:
>> i have a warning that i do not understand.  the tbl below give a
>> warning: grotty:tab:7: character above first line discarded (using:
>> groff -t -Tascii tab). Any idea why ?
>>
>> .TS
>> tab(|);
>> l s s s
>> c c c c.
>> UEBERSCHRIFT
>> a|b|c|d
>> a|b|c|d
>> a|b|c|d
>> .TE
> 
> The current development version in the CVS no longer shows this
> warning.  It's completely harmless, BTW.
> 
> 
> Werner
> 
> 


___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff

Re: [Groff] New roff2* programs

[walter harms]

if the packages become part of 'groff' why not add a 'make docs'
and generate them on request ?
and other option is adding this to a 'make check' so it can double
as output test for the compiled system.

providing dcos in roff only is bad because people that start using groff
may have no idea how to generate the required formats. ans they never
read any documentation :)

re,
 wh



Bernd Warken wrote:
>> Von: Ralph Corderoy <[EMAIL PROTECTED]>
> 
>> I think it's still worth providing the PostScript files because they may
>> not have a system where they can get things working sufficiently to
>> produce them, despite a README.  Further, it's more hassle and they may
>> just want a quick peruse without the overhead of building, etc.
> 
> If they can use PostScript they must have a working computer.  Moreover,
> the ps-files in the examples are very disgusting.  They hide the roff source
> code; a ps-subdirectory would do.  Maybe `html' would be better anyway.
> 
> Bernd Warken
> 
> 
> 
> ___
> Groff mailing list
> Groff@gnu.org
> http://lists.gnu.org/mailman/listinfo/groff
> 
> 


___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff

Re: [Groff] Linux Virus Detection?

[walter harms]

seems a common misidentification:
see:
http://forums.clamwin.com/viewtopic.php?p=2783&sid=c054dd63729c567c31558a0b7700bab7

Werner LEMBERG wrote:
>> groff-1.18.1.4.tar.gz: Exploit.Linux.Gv FOUND
>> groff-1.19.2.tar.gz: Exploit.Linux.Gv FOUND
> 
> Hmm.  A tar.gz file should be harmless -- it does neither expand to a
> binary nor to a shell script but to a directory tree, and it isn't a
> self-executable either.  Have you compared the signatures which are
> available on ftp.gnu.org/gnu/groff also?
> 
> 
> Werner
> 
> 
> ___
> Groff mailing list
> Groff@gnu.org
> http://lists.gnu.org/mailman/listinfo/groff
> 
> 


___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff

Re: [Groff] grohtml - "too many open files"

[walter harms]

Ralph Corderoy wrote:
> Hi Larry,
> 
>> Groff was barfing with a "too many open files" error, which I worked around 
>> by doing "ulimit -n 768" first. I ended up with over 640 HTML files. I'm not 
>> sure why all every output file has to be open at once, though.
> 
>
> $
> 
> What status close() returns depends on your awk.  And closing a pipe
> should wait for the command to finish so if you've a grep that produces
> 1E6 lines and you just want to read the first then pipe it into `sed 1q'
> before reading it into awk so the grep gets a SIGPIPE on writing to the
> finished sed, curtailing its largess.
> 
> Cheers,
> 
> 
> Ralph.

To access head or tail of a ascii file the 'head' and 'tail' commands are what 
you
are looking at (prevents reading the whole file just to get the result).

re,
 wh




___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff

Re: [Groff] Choosing a portability target

[walter harms]

hi list,
as author of several man pages i can say something about the "other" side.
When you read the current manuals (i admit that is some time ago) they ask
the authors to keep the file simple. Using the .TH, .BR, .I macros
means that the authors need to learn a few basic format stuff and that's it.
the only "test" you do as authors is to test with "man -l" (or groff)
to check if it looks ok on screen (ascii only!).
Stuff like tbl,eqn,... is discouraged (somebody mentioned it before) to keep
thinks simple.
the \fB stuff is mostly seen in older pages they should be replaced with .B
and friends.

And why bother with the section problem ? leave it to the maintainer. i see it
mostly as "copy to" problem.

Stupid system that restrict macro length could be cought with a macro i guess. 
simply
complain that the user needs a propper g/roff implementation.

re,
 wh





___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff

Re: [Groff] Choosing a portability target

[walter harms]

Eric S. Raymond wrote:
> walter harms <[EMAIL PROTECTED]>:
>> Stuff like tbl,eqn,... is discouraged (somebody mentioned it before) to keep
>> thinks simple.
> 
> Discouraging TBL is the wrong advice to give nowadays.  It used to make sense,
> back before the .\" t convention evolved and when most-third-party viewers
> would just ignore .TS/.TE, but the background has changed.
> 
> Today I would say "Do use TBL for tables, do *not* make ad-hoc ones using 
> ,ta, because structured TBL is easier for downstream viewers to parse
> unambiguously."
> 

i am a big fan of tables (for a different reason) but we can not change that
if the (man page) maintainers do not enforce it. someone should contact them
and perhaps they have some nice additional ideas that should be incorporated.

It would be a nice step forward to add stuff like pic into man pages aka
'a picture says more that 1000 words' (think of flow charts)

re,
 wh



> (doclifter handles both TBL and ad-hoc tables, so if it weren't for 
> the viewer-portability issue I would not care about this.)


___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff

Re: [Groff] chess font?

[walter harms]

maybe you can add this as a little howto to the wiki and/or groff docu ?

re,
 wh


Gaius Mulley wrote:
> Hi Ted,
> 
> many thanks for the pointers - have found the chess postscript adobe
> fonts!
> 
> Gaius
> 
> 
> 
> 

Re: [Groff] How to do Multipage tables?

[walter harms]

hi Larry,
i thing chris has a more basic problem
the last time i need .TS H i needed also the -ms macroset.
tbl alone did not help (yes, it was an older version)

i used: groff -t -ms -Tps my.tbl

(shorten version of cause in real it is:
cat <> According to page 6 of the document "tbl - A program to Format Tables"
>> by M.E. Lesk, tbl is supposed to handle:-
>>
>> .TS H
>> page heading text
>> .TH
>>
>> How do I get this to work? I keep getting:-
>>
>> ...:2: unrecognised format 'p'
>> ...:2: giving up on this table
> 
> I was about to ask you for a sample, but I think I see what's happening. You 
> need to specify global options and column layouts before the table headings. 
> This is the kind of thing I do a lot at work:
> 
> .TS H
> allbox expand tab(@);
> cb cb
> l l .
> [EMAIL PROTECTED]
> .TH
> [EMAIL PROTECTED] the hard drive.
> [EMAIL PROTECTED] the world.
> [EMAIL PROTECTED]
> .TE
> 
> The line "[EMAIL PROTECTED]" is the table heading; it gets printed in bold 
> and 
> centered within the column.
> 
> Hope that helps!
> 
> -- Larry
> 
> 
> 
> 

Re: [Groff] colorized man pages

[walter harms]

Am 19.08.2016 13:06, schrieb Steffen Nurpmeso:
> "James K. Lowden"  wrote:
>  
> |http://boredzo.org/blog/archives/2016-08-15/colorized-man-pages-understood-a\
>  |nd-customized
>  |
>  |https://news.ycombinator.com/item?id=12296000
>  |
>  |It's a little far afield, but some here might be interested in the
>  |interest in manpages.  mdoc has no color features, leaving folks to
>  |resort to some pretty brutal techniques. 
>  |
>  |Raw VT-100 escape sequences, in 2016.  Where will it all end?  
> 
> I think it would be nice to offer people the possibility to
> specify a list of colours.  It shouldn't be too much work to
> instrument a few important man and mdoc macros and add an
> environment variable, say, MANUAL_COLOURS, in equal spirit to
> LS_COLORS.  In the Linux world there is now a dircolors(1) command
> which can be used to control LS_COLORS.  Well.
> 
> Yes, people are interested in that and should have the possibility
> to do that, exactly like you say.  And as flexible as possible.
> I place it on my TODO list for S-roff.
> 

hi guy,
please make sure that this is a reversible change.
personally i find dircorlors annoying, i can not read
anything with certain combinations. An i have no idea
what colors you would like to have in a man page.

re,
 wh

Re: [Groff] [PATCH] mdate.sh: rewrite in Perl

[walter harms]

Am 18.02.2017 19:07, schrieb James K. Lowden:
> On Sat, 18 Feb 2017 03:28:03 +
> Colin Watson  wrote:
> 
>> This version is much shorter and easier to understand than the
>> shell/awk version: we don't have to worry about convincing ls to
>> produce output that we can parse, and we don't have to play games
>> with the way that the same field may contain either the year or the
>> time depending on how old the file is.
> 
> Attached please find fdate.c. It accepts filename argments and prints
> the files' mtimes (and, optionally, names).  Like date(1), it accepts a
> strftime format argument, defaulting to -mm-dd.
> 
> If you would like to use it instead, i can provide the necessary GNU
> paperwork.  
> 
> $ fdate ~/projects/3/groff/*
> 2016-04-21
> 2013-11-12
> 2016-04-19
> 
> $ fdate -v +'%d %B %Y' ~/projects/3/groff/*
> 21 April 2016 /home/jklowden/projects/3/groff/groff
> 12 November 2013 /home/jklowden/projects/3/groff/mkgrft
> 19 April 2016 /home/jklowden/projects/3/groff/sidebar
> 
> --jkl


I dont know why this is needed in the first place, but maybe stat(1)
can help here ?

re,
 wh

Re: [Groff] Unix Research Editions 8, 9, and 10 Available.

[walter harms]

Am 30.03.2017 17:02, schrieb Ingo Schwarze:
> Hi Ralph,
> 
> Ralph Corderoy wrote on Thu, Mar 30, 2017 at 02:31:24PM +0100:
> 
>> Research Unix Editions 8, 9, and 10 will no longer have copyright
>> asserted over them.
> 
> While that vaguely resembles the wording of the original announcement,
> in this form, it is a grossly misleading statement.
> 
> For one thing, Alcatel-Lucent explicity says that they do "not
> relinquish any intellectual property rights".  That includes
> Copyright, so they clearly and explicitly retain ownership of their
> Copyright.  In stark contrast to that very clear and unambiguous
> statement, they do not explicitly say that they grant any permissions;
> the word "permit" does not occur at all in the document.  Even
> worse, the crucial sentence is grammatically incorrect and does not
> contain any predicate.  At least one word is obviously missing.  If
> that missing word is intended to be something like "guarantees" or
> "promises" or "officially states its legally binding, irrevocable
> intent", the statement might be somewhat useful; but if the missing
> word is intended to be somelike like "plans" or "considers" or
> "hopes", then it is rather useless and potentially a trap.
> 
> Besides, while they fail to explicitly grant any rights whatsoever,
> they do explicitly say that they do not grant "any rights for
> commercial purposes" - which is potentially another trap: For
> example, if somebody includes parts of this code into a compilation
> that is distributed non-commercially, suddenly parts of that
> compilation can no longer be used commercially, which users might
> not expect, potentially dragging unsuspecting end users into trouble.
> 
>> https://www.spinellis.gr/cgi-bin/comment.pl?date=20170328 says they
>> contain, amongst other things, "graphics typesetting tools" so perhaps
>> there's something of interest to today's troff users in them.
> 
> Something interesting, maybe; but given the vagueness of the statement,
> doing anything with it other than looking at it for historical interest
> seems fraught with multiple risks to me.
> 
> In particular, i don't think including code into groff that cannot
> be used for commercial purposes and that does not have a clear and
> unambiguous license would be a bad idea.
> 


I guess the only solution is to ask Alcatel-Lucent for clarification.

re,
 wh

Re: [groff] Loss of MSVC support

[Walter Harms]

> John Gardner  hat am 14. Februar 2019 um 14:20
> geschrieben:
> 
> 
> > but there's also no great urgency to remove them, IMO
> 
> Agreed. Personally, I think this is a non-issue.
> 
> If Groff still uses backticks to support the (pre-POSIX) ancient Bourne
> Shell for Solaris 9-10, then we may as well remove those too if we're
> "modernising" the codebase...

+1

re,
 wh

> 
> (I use "modernise" in this sense very loosely)
> 
> On Fri, 15 Feb 2019 at 00:17, Colin Watson  wrote:
> 
> > On Wed, Feb 13, 2019 at 06:58:18PM +0200, Eli Zaretskii wrote:
> > > Just to make what Keith says (and I concur) crystal clear: there's a
> > > need to distinguish between C99 compliance of the compiler and the
> > > C99/Posix compliance of the C runtime.  We can assume the former,
> > > certainly when using MinGW GCC, but we cannot assume the latter when
> > > building a native MS-Windows port (as opposed to Cygwin port) of
> > > Groff.
> >
> > If it's just the runtime, then Gnulib should be able to paper over a
> > pretty fair number of the differences, and groff already uses that.  It
> > may just be a matter of somebody who can do test-builds on Windows
> > making sure that we're importing the right set of Gnulib modules.
> >
> > (It's possible that some of the _WIN32 conditionals can be supplied by
> > Gnulib these days, but there's also no great urgency to remove them,
> > IMO.)
> >
> > --
> > Colin Watson   [cjwat...@debian.org]
> >
> >

[groff] anyone seen ".ny0" ?

[Walter Harms]

Hello list,
while looking at the xorg man pages there came
a question what this  .ny0 may mean (i shorted that of cause):



.ny0
.TH XtAppNextEvent __libmansuffix__ __xorgversion__ "XT FUNCTIONS"
.SH NAME

.

I could not find this in the groff manual. It seems to do nothing.
Any ideas ?

re,
 wh

Re: [groff] anyone seen ".ny0" ?

[Walter Harms]

> Mike Bianchi  hat am 24. März 2019 um 19:42 geschrieben:
> 
> 
> > .ny0
> 
> look for a macro definition:
>   .de ny
> :
>   ..
> 
> In the old days, no macro name was more than 2 characters so nroff/troff would
> understand   .ny0   to be  macro ny  with  argument 0 .
>   Mike
> 
> 

There is no macro definition .de ny.
I guess that is a left over from ancient times.
I wanted to make sure there is no .ny0 definition inside *roff 
that i was missing.

re,
 wh


> On Sun, Mar 24, 2019 at 07:16:07PM +0100, Walter Harms wrote:
> > Hello list,
> > while looking at the xorg man pages there came
> > a question what this  .ny0 may mean (i shorted that of cause):
> > 
> > 
> > 
> > .ny0
> > .TH XtAppNextEvent __libmansuffix__ __xorgversion__ "XT FUNCTIONS"
> > .SH NAME
> > 
> > .
> > 
> > I could not find this in the groff manual. It seems to do nothing.
> > Any ideas ?
> > 
> > re,
> >  wh
> > 
> 
> -- 
>  Mike Bianchi
>  Foveal Systems
> 
>  973 822-2085
> 
>  mbian...@foveal.com
>  http://www.AutoAuditorium.com
>  http://www.FovealMounts.com

Re: [groff] anyone seen ".ny0" ?

[Walter Harms]

> Ralph Corderoy  hat am 25. März 2019 um 11:29
> geschrieben:
> 
> 
> Hi Walter,
> 
> > .ny0
> > .TH XtAppNextEvent __libmansuffix__ __xorgversion__ "XT FUNCTIONS"
> > .SH NAME
> 
> Given .ny0 seems to be limited to the libx11 man pages here so
> https://www.x.org/wiki/ might be a starting point to tracing its
> addition in their source tree.
> 

nobody seems to know, i guess the headers were generated automaticly
and somehow the .ny0 got into that. Now i have a patch to add the
definition of ny0 but i would prefer to remove it complettly if one 
can tell me what it is supposed to do.


> It seems to always be just before the .TH that should start a man page,
> but sometimes there's a «'\" e» or similar between the two, indicating
> eqn(1) is required as described in man(7).  That magic comment only
> works as the first line of the file though, so it looks like these man
> pages have had a `portability' header added at their start, and that
> ends in .ny0?
> 
> > I could not find this in the groff manual. It seems to do nothing.
> 
> I was surprised
> 
> $ groff -Ww <<<.ny0
> $ groff -Ww <<<.foo
> $ 
> 
> didn't complain about those unknown things as they could be typos that
> it should help catch.

Yep that is the point that stoped me from just removing .ny0. I was thinging
about a forgotten command.

re,
 wh

thx for all how took part in the discussion


The full header looks like this, i have removed the comments on top
but so far i see they contain nothing that would affect the later processing.
Please note that the .Ds macro is brocken.


.ds tk X Toolkit
.ds xT X Toolkit Intrinsics \- C Language Interface
.ds xI Intrinsics
.ds xW X Toolkit Athena Widgets \- C Language Interface
.ds xL Xlib \- C Language X Interface
.ds xC Inter-Client Communication Conventions Manual
.ds Rn 3
.ds Vn 2.2
.hw XtFind-File wid-get
.na
.de Ds
.nf
.\\$1D \\$2 \\$1
.ft CW
.ps \\n(PS
.\".if \\n(VS>=40 .vs \\n(VSu
.\".if \\n(VS<=39 .vs \\n(VSp
..
.de De
.ce 0
.if \\n(BD .DF
.nr BD 0
.in \\n(OIu
.if \\n(TM .ls 2
.sp \\n(DDu
.fi
..
.de IN  \" send an index entry to the stderr
..
.de Pn
.ie t \\$1\fB\^\\$2\^\fR\\$3
.el \\$1\fI\^\\$2\^\fP\\$3
..
.de ZN
.ie t \fB\^\\$1\^\fR\\$2
.el \fI\^\\$1\^\fP\\$2
..
.ny0
.TH XtFindFile __libmansuffix__ __xorgversion__ "XT FUNCTIONS"
.SH NAME
XtFindFile \- search for a file using substitutions in the path list

Re: [groff] anyone seen ".ny0" ?

[walter harms]

Am 25.03.2019 20:30, schrieb Ingo Schwarze:
> Hi Walter,
> 
> Walter Harms wrote on Sun, Mar 24, 2019 at 07:16:07PM +0100:
> 
>> while looking at the xorg man pages there came
>> a question what this .ny0 may mean
>> I could not find this in the groff manual. It seems to do nothing.
> 
> In general, the X.org manual pages are relatively low quality,
> in particular containing quite some cargo cult.  Thomas Dickey
> continued that tradition of cargo culting by keeping the .ny
> even though it does nothing:
> 
> https://gitlab.freedesktop.org/xorg/lib/libxt/commit/7bdec43f299d2538d66f65892766bf3c5dd27056
> 
> I would say it is almost certain that it used to be some X11-specific
> hack decades ago that has never been maintained or tested since,
> because neither GNU troff nor Heirloom troff define an .ny or .ny0
> request.
> 
> If you really wanted to understand what it was supposed to do in
> the 1980ies, you would have to look at revision histories and commit
> messages of that (X11R4?) era.
> 

I think that John Gardner is right here; the original author tried to disable
automatic hyphenation.


> But i don't really see the point.  If you want to improve the X.org
> manual pages, just remove all that poorly working cruft from the
> preamble and use standard idioms instead.
> 
> In particular,
> 
> -.de IN
> -..
> 
> -.de ny
> -..
> -.ny 0
> 
> would be obvious improvements, but it would probably also
> make sense to use the standard .BR instead of .ZN
> and the standard .RB instead of .Pn.

I am with you. My goal is to remove all the stuff and replace
it with std. man page macros. The problem is to do this
automatically. There are few people checking documentation and
reporting obvious errors let alone writing documentation.

For now my idea is to replace the .Ds/.De macro with .RS/RE
and remove .ny0 and some friends completely.


re,
 wh

> 
> Using ".if t" or ".if n" in a manual page is almost never a good idea.
> 
> Yours,
>   Ingo

[groff] groff_man question

[walter harms]

Hello list,
the groff_man page is listing some useful macros i did not notice sofar.
.EE/.EX and \*(lq,\*(rq
Are these save to use or are they a groff special ?

re,
 wh

Re: [groff] Of grog, preprocessors, and missing programs

[walter harms]

Am 08.08.2019 17:16, schrieb John Gardner:
> I've noticed that grog(1) will suggest options for preprocessors
> irrespective of whether they're even available on the user's system. Some
> aren't part of Groff, like grap(1). Others are excluded from certain base
> installations — Ubuntu Server, for example, ships with pic(1) and tbl(1),
> but omits chem(1), refer(1) and grn(1). Finally, one of the preprocessors
> considered by grog while scanning *doesn't even exist*: gideal, hidden
> behind an undocumented `-J` switch in the main groff(1) executable:
> 
> $ groff -J
> groff: couldn't exec gideal: No such file or directory
> 

the option should be removed ASAP because it is useless an will confuse
users that trigger that accidently.


> $ printf 'Foo\n.IS\n.IE\nBar\n' | grog
> groff -T ps -J -p -
> 
> 
> It's debatable whether or not Grog should concern itself with site-specific
> matters like this. After all, an error at the command-line isn't a big
> deal. Most Troff-savvy users probably have a complete Groff installation on
> their site anyway. Troff-savviness can be reasonably assumed of anybody
> running the grog(1) command from their terminal.
> 
> The problem is when users aren't Troff-savvy, and document formatting is
> performed by a GUI without user intervention. That's exactly half of what
> Roff.js  exists to do — the code
> talking to Groff
> 
> from the browser is substantially more complex than it should be, due to
> the translation layers involved...
> 
> So. Thoughts?

thoughts:
" grog reads files and guesses which of the groff(1) options ..."

The point here is "guesses". If you add "Note: that does not say that you system
is capable to do so" then IMHO this problem is solved.

On the other side i would no be to complicated to teach grog an "-scan" to check
what of the exspected programms are available.

re,
 wh

AW: Unable to get GROFF_ENCODING to seep through to sourced subfiles

[Walter Harms]

If that does not work try (assuming bash):
export GROFF_ENCODING=utf8
groff_pipeline

rationale:
doing
GROFF_ENCODING=utf8 groff_pipeline
is setting GROFF_ENCODING for the first element only, if anything later in the 
pipe needs that also it is lost. Using export means that subshell also have 
this value.

hope that helps
 re,
 wh

Von: groff  im Auftrag von Bjarni Ingi 
Gislason 
Gesendet: Dienstag, 10. November 2020 23:40:04
An: Dorai Sitaram
Cc: groff@gnu.org
Betreff: Re: Unable to get GROFF_ENCODING to seep through to sourced subfiles

On Mon, Nov 09, 2020 at 03:58:38PM +, Dorai Sitaram via wrote:
> I have GROFF_ENCODING set to utf8, but this only works for the main file 
> processed by groff, not to any subfiles that are sourced via .so .
> Giving the -s option to groff to force a soelim doesn't work either.
> Adding the -k option to force a preconv, whether before or after the -s 
> option, doesn't work either. (I think regardless of the placement of -k and 
> -s, -k happens before -s, hence the problem? Perhaps -k should be forced to 
> happen last?)
> What does work is
> soelim mainDoc.ms | preconv | groff ...
> but it would be nice to avoid the pipelines with either options and/or 
> environment variable.
> Thanks--d

  By using the '-V' option one can see the pipeline,
 that "groff" constructs, for example:

a) "groff -s -k -V file" shows:

preconv file | soelim | troff -Tps | grops

b) "GROFF_ENCODING=utf8 groff -s -V file" shows

preconv -eutf8 file | soelim | troff -Tps | grops

  To get the right order, a patch must by applied,
 for example, that in groff-bug #59442:

"groff -s -k -V file" shows then

soelim file | preconv | troff -Tps | grops

  This does not work, as "preconv" needs an explicit encoding,
 when it gets the data from the standard input.


"GROFF_ENCODING=utf8 groff -s -V file" shows then

soelim file | preconv -eutf8 | troff -Tps | grops


  or the "-K" option for "groff" can be used instead of
"GROFF_ENCODING".

--
Bjarni I. Gislason

Re: [Groff] Umlaute

[walter harms]

you can use recode to convert between latin1 and unicode 8

re,
 wh



zoon wrote:
> Heinz, I changed my linux-Suse to ISO-8859-1  (the latin-1  coding)
> and IT WORKS FINE!
> Thanks, Thomas
>>  Original Message 
>> From: [EMAIL PROTECTED]
>> To: groff@gnu.org
>> Subject: Re: [Groff] Umlaute
>> Date: Wed, 27 Jun 2007 19:21:53 +0200
>>
>>> Am Mittwoch 27 Juni 2007 schrieb zoon:
 When I use groff on the win-xp platform, all german Umlaute like
>> äöü
 ÄÖÜ work fine (latin-1) - but when I work on the linux platform
>> (Suse
 8) the editors äöü become garbled. What would I need to do?
 Change groff? Change system?
 Thanks for any hints, Thomas
>>> if you are using latin-1 on Linux too, it will work. It works for me
>>> since years.
>>> Regards
>>>  Heinz
>>>
> 
> 
> 
> 
> 

Re: [Groff] man-page fixes

[Walter Harms]

>
> Am 21.09.2007 um 20:32 schrieb Axel Kielhorn:
>
>> Hi!
>>
>> I'm currently adding a section about further literature to my short
>> guide.
>> While reading the man-pages I stumbled over a few things:
>>
>> groff_char.man the Latin-1 (ISO-8859-1) code.
>>
>> groff.man (7) linkt to http://cm.bell-labs.com/cm/cs/54.ps but the
>> actual file is at
>> http://cm.bell-labs.com/cm/cs/cstr/54.ps.gz (Which is actually a ps
>> file, unless my browser ungziped it on the fly.)
>

Is is possible to have a copy of this document on gnu.org ?
sometimes documents vanish suddenly (i learned that leasson last week).


re,
 wh

Re: [Groff] Getting properly rendered single quotes in groff

[walter harms]

just a notice,
several years ago (1987 ?) a problem with theses backtics where noticed and
$( .. ) was introduced to replace them. before you start to replace every
backtic it may more resonable to replace it with $( .. )

re,
 wh


Michael Kerrisk wrote:
> On Tue, Jun 17, 2008 at 8:52 AM, Werner LEMBERG <[EMAIL PROTECTED]> wrote:
>>> Personally, I would prefer that quotes render sensibly in utf8, html
>>> and dvi, and that correctly written man pages do not need any
>>> modification.  Also, the use of `foo' is very convenient (even if it
>>> no longer appears balanced in the source).
>> Let me try to summarize:
>>
>>  . What people like to input in man pages is this:
>>
>>  `foo' should be equal to \[oq]foo\[cq]
>>
>>  \`foo\' should be equal to foo
>>
>>I say `in man pages' because \` and \' act as accents too, but
>>this is, AFAIK, not used (a quick search in the man pages on my
>>SuSE GNU/Linux box showed not a single man file which uses \' or
>>\` as an accent).
>>
>>  . Depending on the output device, ` and ' should be mapped to
>>different characters.  However, \` and \' should always map to
>>ASCII 0x60 and ASCII 0x27 for proper cut and paste support.
>>
>> Do you all agree with this?
> 
> This all sounds reasonable.  If needed I will adapt the 800 or so
> (Section 2, 3, 4, 5, 7) pages in man-pages to whatever input form is
> needed (provded it is not a heavy form -- e.g., not troff
> conditionals), so long as I can get what I consider to be decent
> *output*.  That is, balanced single quotes in ASCII (that probably
> means the equivalent of \(aq...\(aq ), and balanced quotes in UTF-8
> (as can currently be obtained by `...').
> 
> Cheers,
> 
> Michael
> 

Re: [Groff] Getting properly rendered single quotes in groff

[walter harms]

Werner LEMBERG wrote:
>> several years ago (1987 ?) a problem with theses backtics where
>> noticed and $( .. ) was introduced to replace them. before you start
>> to replace every backtic it may more resonable to replace it with $(
>> .. )
> 
> But this is not relevant to the general problem of providing good
> representations of ` and '.
> 

this is true, and the discussion was interesting but ntl before he starts to
replace all the ` with something else eg. \' or \(aq  he should consider this
solution.
It does not solve the typographical/technical problem but the "real" question 
was how
to display examples that the user can use clip&paste.

re,
 wh

Re: [Groff] eqn troubles

[walter harms]

may be Miklos can send the eqn output ?

re,
 wh

Werner LEMBERG schrieb:
>> I searched the archives and found Robert's problems with eqn, but
>> nothing about the list of bad groff binaries on Macs.
> 
> Ah, then my memory has tricked me.  It's apparently only eqn which
> causes problems.
> 
> 
> Werner
> 
> 
> 

Re: [Groff] Line continuation

[walter harms]

hi Clarke,
in case you sill have connections to HP. it would be nice if you could
convince them to publish that manuals on the internet.

re,
 wh


Clarke Echols schrieb:
> I wrote an extensive tutorial on sed back about 1987 or so.  It's part
> of HP's HP-UX User Guide series: "Text Editors and Processors".  I don't
> know if you can get your hands on it or not.  I based it on the
> sed standards-conformance tests that were run before the software could
> be shipped, plus other explanatory stuff.
> 
> The thing that confuses people about sed is the concept of "pattern
> space".  ^ is the start, and $ is the end, but you can have multiple
> lines in the space at the same time, with each adjacent pair
> separated by a newline (represented as \n in substitutions and
> pattern searches).
> 
> It's a very powerful program -- especially when run from inside vi
> (vim) and vi is run non-interactively from a shell script by
> redirecting input from a command file that ends with "ZZ" or ":wq"
> on the last line in the file.
> 
> I overhauled the entire HP-UX Reference (manpages) in a few minutes
> that way.  Took about 3 hours to write and debug the code, but the
> job ran in less than 5 minutes on a 30-MHz processor.  It would
> be interesting to see how long it would take on a 2-Ghz machine. :-)
> 
> I converted all in-line coding to macros; i.e., \fB became .B, etc.
> and I completely changed the typography conventions from AT&T to
> current industry practice, and got rid of font inconsistencies too.
> 
>

Re: [Groff] groff -mm output something I don't expect

[walter harms]

(Ted Harding) schrieb:
> On 14-Nov-08 12:03:58, Mike Bianchi wrote:
>> On Fri, Nov 14, 2008 at 08:58:50AM +0100, Werner LEMBERG wrote:
 I ``troff'' a simple file, hello.mm whose content is:

 .\" hello.mm
 Hello World!

 with the command line:

 $ /usr/local/bin/groff -mm hello.mm > hello.ps

 and opened it with ``evince'', then I found there are two short bars
 in topleft and topright corners of the page.
>>> This must be a problem with evince then.  Here is the PS output of
>>> your document (omitting the preamble) as processed with the current
>>> CVS version of groff (and I doubt that this has changed recently):
>>>
>>>   /F0 10/[EMAIL PROTECTED] SF
>>>   2.5(-1-)277.006 48 S
>>>   (Hello W)69.336 96 Q
>>>   (orld!) -.8 E
>>>   0 Cg
>>>   EP
>>>
>>> As you can see, no bars are created.  Maybe those bars indicate the
>>> left and right side of the paper, similar to the flashing lines in gv?
>> Is it possible the "two short bars" are the   - 1 -  (meaning page 1)
>> that
>> mm places as the Page Header?
>> -- 
>>  Mike Bianchi
> 
> I also tested the example. When I viewed 'hello.ps' with 'gv' [but
> see below], there was nothing wrong with the PS, and the top margin
> duly contained the page number "-1-".
> 
> However, I then viewed with 'evince', and could not see the "-1-":
> it was as though the top margin had been cropped.
> 
> I have had other bad experiences with 'evince' and now avoid using
> it altogether. In my Debian/gnome installation, /usr/bin/gv does
> not always work properly either, so I set up a symbolic link
> 
>   /usr/bin/GV -> /usr/bin/gnome-gv
> which in turn -> /usr/bin/ggv
> 
> which seems to work fine. So in fact what I originally viewed the
> file 'hello.ps' I used GV!
> 

i tried to file also and i thing it is a evince problem.
the -1- is clearly visible with ghostscript (gs) but not shown
with evince.

now the important question:
did someone report this to the evince people ?

re,
 wh

GNOME evince 2.22.1.1
gs 8.62
groff  1.18.1

Re: [Groff] Problem with -me package

[walter harms]

Anton Shepelev schrieb:
> Hello, Ralph
> 
>> I don't know -me so can't answer on your specific problem.  But have you
>> tried making the page length very long instead of trying to remove the
>> inter-page
> 
> Yes, that was the first thing I did. Although I works, the "functinality"
> of this method is a bit scantier bacause there's no division into pages.
> 
> And I wonder why setting bm to zero results in groff crashing.
> 


hi Anton,
can you please post the groff version and the code that caused the bug ?

re,
 wh

Re: [Groff] Problem with -me package

[walter harms]

Anton Shepelev schrieb:
> Mike Bianchi
> 
>>
>> To format a document of arbitrary length as _one_ nroff page
>> I use this trick.
>>
>> First, set the page length _very_ long.
>> .pl 9
>>
>> And then make the last two lines of input a line break and
>> setting the page length to the _current_ page length.
>> .br
>> .pl \\n[nl]u
> 
> Thanks for pointing out the real nroff way of doing it!
> 
> Walter Harms:
>> hi Anton,
>> can you please post the groff version and the code that caused the bug ?
> 
> groff version 1.19.2
> 
> Code:
> --
> .nr tm 0v
> .nr bm 0v
> Hello, Josephine; How do you do; Do you remember me, baby;
> Like I remember you?
> --
> 
> Not sure I am doing it right, maybe I just didn't
> understand what the bm value means...
> 


it does not matter, groff should not crash on any user input

A quick test with a older Version show following:
groff --version
GNU groff version 1.18.1

 groff -mme -Tlatin1 test.me
troff: fatal error: input stack limit exceeded (probable infinite loop)
grotty::5: character above first line discarded

It seems it is caused with "bm"
.nr bm 4v works
.nr bm 3v causes the error

re,
 wh

Re: [Groff] inability to process german umlauts

[walter harms]

Chris Schaller schrieb:
> Jan,
> 
> encountered this one, too. What's your fileencoding in vim (:set
> fileencoding?). You might want to try to set it either to utf-8 or
> latin-1. Latter worked for me despite having encoding set to utf-8. So
> you are experiencing a vim configuration issue here...
> 
> See also :h encoding and :h fileencoding in vim.
> 
> HTH,
>   Chris

did someone bother to send a bug report to the vim people ?

re,
 wh

Re: [Groff] inability to process german umlauts

[walter harms]

Chris Schaller schrieb:
> Nope. Is this considered a bug? It's just about proper vim settings.
> 
> - Chris
> 
> On Thu, Apr 9, 2009 at 9:25 AM, walter harms  wrote:
>>
>> Chris Schaller schrieb:
>>> Jan,
>>>
>>> encountered this one, too. What's your fileencoding in vim (:set
>>> fileencoding?). You might want to try to set it either to utf-8 or
>>> latin-1. Latter worked for me despite having encoding set to utf-8. So
>>> you are experiencing a vim configuration issue here...
>>>
>>> See also :h encoding and :h fileencoding in vim.
>>>
>>> HTH,
>>>   Chris
>> did someone bother to send a bug report to the vim people ?
>>
>> re,
>>  wh
>>

i dot know, just report and let the maintainer decide. maybe a more clear
wording for the errors/setup would be helpful. personally i say that if
people can not handle a program it is also bug. (it may be impossible to fix
but that is a different issue).

re,
 wh

Re: [Groff] Re: grops and grohtml problems on vista

[walter harms]

Efraim Yawitz schrieb:
> On Wed, Jun 17, 2009 at 7:01 PM, bousch ster  wrote:
>>It seems grops and grohtml are not working for me on Windows Vista even
> with
>>UAC disabled.
>>
>>this command: groff -p hello.pic > hello.ps
>>results in: grops:4:fatal error: fdopen: Invalid
> argument
>>the command: groff -Thtml -p hello.pic > hello.ps
>>results in: pre-grohtml:fatal error: fdopen: Invalid argument
>>
>>the command: groff -Tdvi -p hello.pic > hello.dvi
>>does work.
>>
>>The exact same commands on my Windows XP machine work fine.
>>I'm using groff-1.20.1.
>>
>>Any tips?
>>
> From looking at the code, it seems that grops is not succeeding in creating
> a temporary file, I think in the current directory.  Do you have some
> permissions issue that could cause this?
> 

according to the man page (i hope that m$ did not break specs) that means the 
"mode" argument
is wrong. perhaps you can add a message like:
/* adjust to your needs !*/
   fprintf("fdopen mode(%s):%s",mode,strerror(errno));


re,
 wh

Re: [Groff] Re: grops and grohtml problems on vista (walter harms)

[walter harms]

Ralph Corderoy schrieb:
> Hi Boudewijn,
> 
>> I just tried StraceNT, here is part of the output generated when grops
>> encounters 'x init'
>>
>> [T5140] CreateFileA(34f818, c000, 3, 22fcd0, ...) = 104
> 
> Based on WINE, CreateFileA is almost the same as CreateFileW which is
> 
> HANDLE WINAPI CreateFileW(LPCWSTR filename, DWORD access, DWORD sharing,
> LPSECURITY_ATTRIBUTES sa, DWORD creation,
> DWORD attributes, HANDLE template)
> 
> So we have access = 0xc000 and sharing = 3.  So access is READ |
> WRITE:
> 
> #define GENERIC_READ   0x8000
> #define GENERIC_WRITE  0x4000
> 
> and sharing is READ | WRITE:
> 
> #define FILE_SHARE_READ 0x0001L
> #define FILE_SHARE_WRITE0x0002L
> #define FILE_SHARE_DELETE   0x0004L
> 
>> I don't think the c000 is correct, in every other call to
>> CreateFileA the second parameter is 8000.
> 
> That sounds fine;  most of the other files are only being opened for
> reading, GENERIC_READ.  The trace continues
> 
>> [T5140] GetFileType(104, 0, 0, 1065, ...) = 1
>> [T5140] SetFilePointer(104, , 0, 2, ...) = 
>> [T5140] GetLastError(, 22fd2c, 22fcf8, 77122b19, ...) = 83
> 
> 0x104 is what CreateFileA returned.  SetFilePointer is
> 
> http://source.winehq.org/source/dlls/kernel32/file.c#L936
> 
> and the 2 being passed is FILE_END with 0x = -1 the `distance'.
> It returns INVALID_SET_FILE_POINTER = ~0 and GetLastError is returning
> 0x83 = ERROR_NEGATIVE_SEEK.
> 
> That then ripples through the next set of trace.
> 
>> [T5140] GetLastError(, 3, 770ee2d4, 770f4fe0, ...) = 83
>> [T5140] FlsGetValue(3, , 3, 770ee2d4, ...) = 3407d8
>> [T5140] SetLastError(83, , 3, 770ee2d4, ...) = 0
>> [T5140] GetLastError(, 16, 770ea9c5, 770f4ff3, ...) = 83
>> [T5140] FlsGetValue(3, , 16, 770ea9c5, ...) = 3407d8
>> [T5140] SetLastError(83, , 16, 770ea9c5, ...) = 0
>> [T5140] GetLastError(, 22fd2c, 770ee2d4, 77122b28, ...) = 83
>> [T5140] FlsGetValue(3, , 22fd2c, 770ee2d4, ...) = 3407d8
>> [T5140] SetLastError(83, , 22fd2c, 770ee2d4, ...) = 0
>> [T5140] LeaveCriticalSection(340a80, 22fd48, 7713db33, 3, ...) = 0
>> [T5140] GetLastError(3, 34f818, 770ea9c5, 420229, ...) = 83
>> [T5140] FlsGetValue(3, 3, 34f818, 770ea9c5, ...) = 3407d8
>> [T5140] SetLastError(83, 3, 34f818, 770ea9c5, ...) = 0
>> [T5140] GetLastError(0, 1, 770ea9c5, 77127c1a, ...) = 83
>> [T5140] FlsGetValue(3, 0, 1, 770ea9c5, ...) = 3407d8
>> [T5140] SetLastError(83, 0, 1, 770ea9c5, ...) = 0
>> [T5140] OutputDebugStringA(77144cc0, 10001, 770ee31e, 22fadc, ...)
>> Invalid parameter passed to C runtime function.
>> = 22f168
> 
> Dont' know if that helps any.  I'd back the hunch of others in that the
> mode of the file that's opened by the Windows kernel doesn't match the
> later request to the C library with fdopen().  This `negative seek'
> could just be a red-herring.  What happens for the `init x' on the case
> where there's no problems;  the dvi one?
> 


hi,
i do not use win* so if there is someone who knows and is willing to look into 
that
it may be interesting to that there is a function called tmpfile(3), it is 
ISO,POSIX,...

i admit not looking into the groff code.

re,
 wh

Re: [Groff] Driver for Panasonic KX-P1123

[walter harms]

KX-P1123 is a Matrixprinter. with ghostscript you can only use a "default" mode.
Adding the correct sequences to groff will give the opportunity to have the 
right
sequences in the output.

re,
 wh


Efraim Yawitz schrieb:
> I would like to understand what is the advantage of a custom groff driver
> rather than using the ghostscript driver for that printer on PS output.
> 
> 

Re: [Groff] Right-aligning tables?

[walter harms]

Tail Kinker schrieb:
> By default, tbl leaves tables on the left.  You can also specify
> centered.  It follows, therefore, that you should be able to define a
> right-aligned (relative to column) table.  Anyone have a quick and dirty
> macro for this?
> 
> 

does r not work for you ?

re,
 wh

Re: [Groff] Integer arithmetic

[walter harms]

Werner LEMBERG schrieb:
>>> I consider the groff mailing as a kind of archive which collects
>>> useful tips regarding the troff suite.  Your tar bundle is part of
>>> that bundle.
>> I appreciate that. But I don't think that it would inspire people to
>> write directly to the archive.
> 
> Well, yes.  Material like your bundle should be available more
> easily.  A longer time ago I've started to collect contributions at
> 
>   http://groff.ffii.org/groff/contrib/
> 
> and right now I've added it to
> 
>   http://groff.ffii.org/groff/contrib/documentation/ps-in-groff/
> 
> Sorry for the delay of three years...
> 
>>> Unfortunately, its importance for GNU documentation is zero.
>>> Officially, the GNU people prefer the texinfo documentation system.
>> Werner, my point is: why is it zero for them?
> 
> Because Stallman has decided to use texinfo as the official GNU
> documentation tool.  The importance of GNU roff itself is
> acknowledged, but it is not as important as, say, gcc.
> 
>>> Because it's just me who works on groff from time to time, noone
>>> else.  And I have a lot of other things to do.
>> Werner, my question is not why you don't do more, but why are you
>> alone?
> 
> Because noone steps forward and helps.
> 

to attact mor users:
 what is about a section "Solutions" on the webpage ?

just little programms that helps to make output nice, something like that ?

btw: Documentation/FAQ on that page would be nice also.

just my 2 cents,
 wh

Re: [Groff] names in groff -- was: Another hdtbl patch

[walter harms]

Mike Bianchi schrieb:
> On Thu, Feb 04, 2010 at 10:11:59PM +0100, Werner LEMBERG wrote:
>>> No macro, register, or string name within standard macro
>>> packages will ever end in * .  Thus all user created names
>>> that end in * will never collide with any within the standard
>>> macro packages.
>> Nice idea.  Have you already verified that no macro provided by any of
>> the `big' macro packages end with `*'?
> 
> No, I have not.  I was just shooting from the hip.
> 
>>  It should be noted that such
>> user macro names must be longer than two characters.
> 
> 
> I'm thinking groff needs the concept of  namespace  .
> 
> By default, everything lives in the top, unnamed namespace so all the bugs
> are preserved.
> 
> E.g.
>   .de LI  \"  my own take on the LI macro in the mm macros
>   :
>   ..
> 
>   .namespace MM -mm   \"  start the namespace MM,
>   \"  which contains the -mm macro package.
> 
>   .MM.BL  \"  use  .BL  from the MM namespace
>   .LI \"  use  .LI  from the top (unnamed) namespace
>   :
>   .MM.LI  \"  use  .LI  from MM
>   :
>   .MM.LE
> 
>   .BL \"  There is only one .BL (in MM);  use it.
>   .LI \"  As above.
>   :
>   .MM.LI  \"  As above.
>   :
>   .LE \"  There is only one .LE (in MM);  use it.
> 
>   .MM.\"  default all following macros to the MM namespace.
>   .BL \"  use  .BL  from MM
>   .LI \"  use  .LI  from MM
>   :
>   ._.LI   \"  use  .LI  from the unnamed namespace (named  _ ?)
>   :
>   .LE
>   ..namespace MM  \"  end default to MM .
> 
>   .MM.BL  \"  still defined.
> 
>   .namespace Mine \"  start the  Mine  namespace.
>   .de Glurp   \"  defines  .Mine.Glurp .
>   :
>   ..
>   .Glurp  \"  uses  .Mine.Glurp ,
>   \"" unless  ._.Glurp  is defined.
>   ..namespace Mine\"  end  Mine .
> 
>   .Mine.Glurp \"  still defined.
> 
> This is just a sketch, and needs to be thought about more.
> I'm sure someone who designs languages will have good suggestions.
> 


1. I have no idea about the inner workings of groff/troff.

I do not thing that there is a need for namespaces. Simply stop when a macro is 
defined again
(opposed to redefined),  helpful error messages will support debugging.

re,
 wh

[Groff] man makro oddity

[walter harms]

hi,
i was playing with man pages and found by chance that empty lines before .TH 
seems to confuse groff.


./"

./"

./"
.TH The header




works fine (no warnings what so ever) but has am empty page in front and 
changes in page numbering are
ignored.


./"
./"
./"
.TH The header




But this produces the desired output. Is is possible to have a warning, when
accidentally empty lines in front are found ?

re,
 wh

Re: [Groff] man makro oddity

[walter harms]

Werner LEMBERG schrieb:
>> i was playing with man pages and found by chance that empty lines
>> before .TH seems to confuse groff.
> 
> `Confuse'?  I don't think so.
> 
>> 
>> ./"
>>
>> ./"
>>
>> ./"
>> .TH The header
>>
>> 
>> 
>>
>> works fine (no warnings what so ever) but has am empty page in front
>> and changes in page numbering are ignored.
>>
>> 
>> ./"
>> ./"
>> ./"
>> .TH The header
>>
>> 
>> 
>>
>> But this produces the desired output.  Is is possible to have a
>> warning, when accidentally empty lines in front are found?
> 
> It's probably not worth the time to fix this.  Note that you can
> concatenate various man pages – in both man and mdoc formats, IIRC;
> .TH then needs to start a new page.  The result you are seeing is a
> side effect of this.
> 
> 

I do not think there is anything to "fix", it is simply a question of helping
users. Empty lines before .TH are most likely not what the user intended. *if* 
some can
fix that easy (read: print a warning) someone should do.

re,
 wh

[Groff] trouble with \_

[walter harms]

hi list,

I run into a problem that left me confused.
I wanted to use \_ to draw a line in a table.
My test programm looks like that:

.TS
tab(|);
l l l.
Geraet| Seriennummer   | Bemerkung
_
xx   |1  |\_
xx   |1  |\_
xx   |1  |\_
xx   |1  |\_
xx   |1  |\_
.TE

when i run my test it looks like that:

groff -t -Tascii line.tbl
grotty:line.tbl:7: character above first line discarded
GeraetSeriennummer   Bemerkung
---
xx   1  _
xx   1  _
xx   1  _
xx   1  _
xx   1  _


I expected that \_ will be expanded to 

(also no idea why grotty complains).
btw: the example in UTP p. 180 works fine to it is not a broken macro or so.


re,
 wh

Re: [Groff] trouble with \_

[walter harms]

Am 13.01.2011 12:02, schrieb Tadziu Hoffmann:
> 
>> I run into a problem that left me confused.
>> I wanted to use \_ to draw a line in a table.
> 
> Can you check for trailing spaces?  I get the underscore instead
> of a sequence of dashes if the cell contains more than just "\_".
> Or are you using cygwin, and it's a LF vs. CRLF problem?
> 

I am a linux-user, the problem was a space at the end.
It made me mad because i had a working example but space never
came to my mind. thx a lot,

re,
 wh

[Groff] tbl using \$_

[walter harms]

Hi list,
After printing my document i found that \_ does not do what i expected.
the line is to high more like - than _.
After reading the UTP book again i got the inpression that \$_ will do
what i want but that resulted in   "bad argument name `_'"

Then i tried \R_ what is very near what i would like to have. (i also tried 
\R\(ru).

I have a simple table here that describes what i want. I need some empty lines
to people can write some remarks in that line. Is there a simple way to do that 
?

re,
 wh

.TS
tab(|);
l l l.
Device   | Serial| Remark
_
xx   |1  |\_
xx   |1  |\_
xx   |1  |\_
xx   |1  |\_
xx   |1  |\_
.TE

Re: [Groff] tbl using \$_

[walter harms]

It is very nice,
but it look strange when you use:

\*_|\*_

I also changed from .1 to .3 (what looks in my context better).

re,
 wh


Am 14.01.2011 10:44, schrieb Tadziu Hoffmann:
> 
>> After printing my document i found that \_ does not do what i
>> expected.  the line is to high more like - than _.
> 
> How about something like this?:
> 
> 
> .\" tbl
> .\" 
> .sp 3c
> .ds _ \v'.1m'\D'l 6c 0'
> .vs 24
> .TS
> tab(|);
> c c c
> l l l.
> Geraet|Seriennummer|Bemerkung
> _
> xx|1|\*_
> xx|1|\*_
> xx|1|\*_
> xx|1|\*_
> xx|1|\*_
> .TE
> .\" 
> 
> 
> 
> 

Re: [Groff] tbl using \$_

[walter harms]

This works fine but it is not a future proof solution :)

what takes me wonder is the question what went wrong with \$_ ?
and can some one make the \*_ solution more flexable so it will fill
the whole column automaticly ?

(i have changed the 6c every time this works for me but may be not for others)

re,
 wh

Am 14.01.2011 11:16, schrieb Tadziu Hoffmann:
> 
>> but it look strange when you use:
>> \*_|\*_
> 
> Sorry, it was a bit sloppy (and worked only when \*_ was in
> the last column).  This is better:
> 
>   .ds _ \v'.1m'\D'l 6c 0'\v'-.1m'
> 
> or whatever vertical offset you prefer.
> 
> 
> 
> 

Re: [Groff] tbl using \$_

[walter harms]

Am 14.01.2011 20:29, schrieb Tadziu Hoffmann:
> 
>> This works fine but it is not a future proof solution :)
> 
> Hmmm.  Why not?
> 
> 
>> what takes me wonder is the question what went wrong with \$_ ?
> 
> I don't know where the "\$_" comes from.  It's not in the tbl
> manpage, nor in the original tbl paper from Bell Labs.

I got it from UTP page 487. This is my basic source.


> Tbl can do two different line fills.  "\_" as the only cell
> content will draw a line with the width of the column's other
> contents;  "_" as the only cell content will draw a line the
> full width of the column (this is what the UTP says "\$_"
> will do; might this be an error?).  However, in both cases
> the line will be raised to about the center of the lowercase
> letters, not below the baseline as you would like to have.

I read it this way:
|\_|will result in  |    |
|\$_|   will result in  ||



> 
> 
>> and can some one make the \*_ solution more flexable so it
>> will fill the whole column automaticly ?
> 
> What, in your opinion, should determine the width of the column?
> 
> One quick and dirty solution for the automatic fill would be
> 
>   .ds _ \v'.1m'\D'l \\n[3w2]u 0'\v'-.1m'
> 
> where 3w0 refers to the width of first column, 3w1 to that
> of the second column, 3w2 to that of the third column, etc.,
> but this is not a solution to be recommended since it depends
> on the internals of tbl's implementation.
> 
> 

so far i understand the \_ and \$_ are tbl commands so it would be fine.


>> (i have changed the 6c every time this works for me but may be
>> not for others)
> 
> I had thought it was an advantage to be able to specify the
> width explicitly, given your example where it was supposed
> to be a space reserved for remarks...
> 
It is not a major problem. I had more tables in the same style
(sometimes more or less columns).

re,
 wh

[Groff] tbl and large font

[walter harms]

Hello List,
i have found an oddity with tbl and large fonts.
i got the request to make the fonts larger to inprove readability.
i added the \s16 and found that the width seems to scale but not
the hight of the table. Is this intended ?
mean while i will try to use the postscript scale operator to
solve the problem.

re,
 wh

\s16
.TS
tab(|);
l l l.
Geraet   | Seriennummer  | Bemerkung
_
xx   |1  |\_
xx   |1  |\_
xx   |1  |\_
xx   |1  |\_
xx   |1  |\_
.TE

Re: [Groff] tbl and large font

[walter harms]

Am 18.01.2011 20:02, schrieb Deri James:
> On Tuesday 18 Jan 2011 17:51:22 walter harms wrote:
>> Hello List,
>> i have found an oddity with tbl and large fonts.
>> i got the request to make the fonts larger to inprove readability.
>> i added the \s16 and found that the width seems to scale but not
>> the hight of the table. Is this intended ?
>> mean while i will try to use the postscript scale operator to
>> solve the problem.
>>
> 
> Hi,
> 
> It might be easier to try:-
> 
> =
> 
> .ps 16

hi Deri,

I have tried but the result is not realy different. The postscript files
differ only in two lines. (i admit i have no idea why).
And that do not affect the box size.

re,
 wh

Re: [Groff] tbl and large font

[walter harms]

Am 19.01.2011 16:34, schrieb Tadziu Hoffmann:
> 
>>> .ps 16
> 
>> I have tried but the result is not realy different. The
>> postscript files differ only in two lines. (i admit i have
>> no idea why).  And that do not affect the box size.
> 
> The important part was also changing the linespacing,
> 
>   .vs 20
> 
> otherwise you're setting 16-point type on a (default)
> 12-point baseline distance.
> 

this works much better. Is there any reason why changing the
font should not change the baseline also ?

It is confusing.

re,
 wh

[Groff] pagesize for terminal output

[walter harms]

Hi list,
i have a programm that generate nroff output that is intended to be printed.
that works fine.

Problems occur when i want to see the page as latin1 then it will be rendered
into 2 pages. Since i pipe the output into xmessage i do not care about page 
length.
Is there any fancy trick i can use to convince groff not to page break ?
(without changing the nroff code).

re,
 wh

Re: [Groff] Re: pagesize for terminal output

[walter harms]

Am 28.02.2011 20:58, schrieb Anton Shepelev:
> Walter Harms asked:
> 
>> Is  there  any  fancy  trick i can use to convince
>> groff not to page break ?
> 
> Yes. In addition to Clarke Echols's advice, you  can
> make  this  behaviour  more manageable using end-of-
> input traps.  This way, the single-page mode can  be
> turned on and off with a single command:
> 
>   http://lists.gnu.org/archive/html/groff/2011-02/msg00020.html
> 
> Werner  Lemberg  has added a refined version of that
> into the Texinfo manual, under the section  "End-of-
> input traps".
> 
> Anton

thx for the hint, but how does setting the page lenght affect
the printed output ? the main point is to print the document,
showing it is only second.

(my solution was to generate a pdf and show that page but this will
generate a tmpfile and is slow compared to the ascii output)

re,
 wh

Re: [Groff] Re: pagesize for terminal output

[walter harms]

Am 01.03.2011 12:28, schrieb Ralph Corderoy:
> Hi Walter,
> 
> Anton Shepelev wrote:
>> Walter Harms:
>>> thx  for  the  hint, but how does setting the page lenght affect the
>>> printed output ? the main  point is  to print the document, showing
>>> it is only sec- ond.
>>
>> It depends on what you call printed output.  If  you mean  the  output
>> of  one of groff's character-cell devices (-Tascii, -Tlatin1,...) then
>> yes.
> 
> If you only want to set a very long page length, or an end of input
> trap, for `nroff' output and not troff then use a
> 
> .if n ...do nroff-only things...
> 
> There's a matching `t' as well that's only true if we're troff.  That
> way your PostScript output can be paged, and your terminal output not.
> 

this looks like a good idea. please can you be more explicit ? I am more
a casual groff user and have no idea who to manipulate output device
beyond the command line.

(NTL: it would be a nice extension for grotty to have a switch like "papersize" 
)

re,
 wh

Re: [Groff] Re: pagesize for terminal output

[walter harms]

Am 02.03.2011 10:53, schrieb Werner LEMBERG:
>> (NTL: it would be a nice extension for grotty to have a switch like
>> "papersize" )
> 
> Uh, oh, a TTY has no length by its very definition.  A physical paper
> size is completely meaningless for terminals, and the logical paper
> size is given by gtroff anyways (with the `pl' request).
> 


let me reformulate:
A switch that let grotty ignore a given page size inside a document.

And the rationale is exactly what you said: paper sizes and screen sizes
do not mix properly; so it may be useful to ignore a length and leave the
"page break" to a pager. (I guess grotty was intended to work with simple
printers and of cause pages have there use.)

I have no clue about the internals of grotty and it is totally possible that
is it to complicated to do.

re,
 wh

Re: [Groff] Re: pagesize for terminal output

[walter harms]

Am 02.03.2011 11:38, schrieb Werner LEMBERG:
> 
>> A switch that let grotty ignore a given page size inside a document.
> 
> .rn pl pl-orig
> .de pl
> .  pl-orig i
> ..
> 
>> And the rationale is exactly what you said: paper sizes and screen
>> sizes do not mix properly; so it may be useful to ignore a length
>> and leave the "page break" to a pager.
> 
> Exactly.  For man pages this is done like this by default.
> 
> 
> Werner
> 

i have added .pl i and it works so far but now i see
^h^h^h^h in front of my table. I can fix that with "cut -b5-"
or  tr -d "\b" but i am confused.
(i did not notice it before since i used | more to show the
output but xmessage is something different).

is this intended ?

re,
 wh

Re: [Groff] Re: pagesize for terminal output

[walter harms]

Am 02.03.2011 17:32, schrieb Anton Shepelev:
> Walter Harms
> 
>> i have added .pl i and it works so far but now
>> i see ^h^h^h^h in front of my  table.  I  can  fix
>> that  with "cut -b5-" or  tr -d "\b" but i am con-
>> fused.
>> (i did not notice it before since i used | more to
>> show  the output but xmessage is something differ-
>> ent).
> 
> Looks like these are escape sequences  intended  for
> terminals  that  'know'  how  to treat them. You can
> tell groff to eliminate them and  output  a  vanilla
> text file with the '-P-cbu' command-line option.
> 
> XMessage  is  not a terminal and probably can't pro-
> cess them.
> 
> Anton
> 

does not work for me, the ^h are still produced

re,
 wh

Re: [Groff] man/troff to LaTex?

[walter harms]

The most easy way IMHO is to create a postscript file
and include that.

re,
 wh


Am 08.08.2011 00:41, schrieb steve.gnuli...@gmail.com:
> Hi,
> 
> Thanks everyone. Just i would to get the groff man's from some Gnu/Linux
> utilities and convert to a unified LaTex file. The purpose is as 'appendix'
> for a book on Gnu/Linux. So, i'll like to change headers, convert to two
> columns, etc...
> 
> thanks again,
> 
> Steve,
> 
> 
> 2011/8/4 Ralph Corderoy 
> 
>> Hi Clarke,
>>
>>> It's not apparent to me why you'd want to.
>>
>> I'm guessing the Steve has to produce a LaTeX document for some reason,
>> like journal publication, and part of that is intended to be the man
>> page for a program.  I agree though, it may help to know his reasons in
>> more detail.
>>
>> Cheers, Ralph.
>>
> 

Re: [Groff] ping: let man print volume headers like mdoc

[walter harms]

Am 16.11.2011 09:43, schrieb Ingo Schwarze:
> Hi,
> 
> do you hold any opinion on this one?
> 
> Thanks,
>   Ingo
> 
> - Forwarded message from Ingo Schwarze  -
> 
> From: Ingo Schwarze 
> Date: Tue, 1 Nov 2011 19:43:27 +0100
> To: groff@gnu.org
> Subject: [Groff] let man print volume headers like mdoc
> 
> Hi,
> 
> When the mdoc(7) .Dt macro is called without a third argument,
> the page header uses the default volume name associated with
> the second (section number) .Dt argument, controlled by the
> doc-volume-ds-N strings in tmac/doc-common.
> 
> On the other hand, when the corresponding man(7) .TH macro is
> called without a fifth argument, the volume name in the page
> header is left blank.
> 
> Yuri Pankov (of IllumOS) suggested to make the two more similar
> by letting man(7) fill in the default volume name as well.
> I like the idea - reducing gratuitious differences between
> mdoc(7) and man(7) seems good to me - and would like to
> implement the change in mandoc(1).
> 
> However, keeping groff(1) and mandoc(1) in sync is even more
> important than synching mdoc(7) and man(7), so i'm asking for
> your opinion first, whether you would accept the following patch,
> or a variant of it.
> 
> I think the strings are so short that there is no problem
> with having them both in doc-common and an-old.tmac;
> on the other hand, if you disagree, i could move them to
> their own file and include them from both places, but
> i fear the code will be uglier, whereas this looks quite nice.
> 
> Yours,
>   Ingo
> 
> 
> --- tmac/an-old.tmac.orig Fri Dec 31 08:33:09 2010
> +++ tmac/an-old.tmac  Sun Oct 30 22:37:29 2011
> @@ -145,7 +145,17 @@
>  .ie (\\n[.$] > 3) .ds an-extra2 "\\$4\"
>  .el   .ds an-extra2 \"Sun Release 4.0
>  .ie (\\n[.$] > 4) .ds an-extra3 "\\$5\"
> -.el   .ds an-extra3 \"System Programmer's Manual
> +.el .ie '\\$2'1'  .ds an-extra3 General Commands Manual
> +.el .ie '\\$2'2'  .ds an-extra3 System Calls Manual
> +.el .ie '\\$2'3'  .ds an-extra3 Library Functions Manual
> +.el .ie '\\$2'3p' .ds an-extra3 Perl Programmers Reference Guide
> +.el .ie '\\$2'4'  .ds an-extra3 Kernel Interfaces Manual
> +.el .ie '\\$2'5'  .ds an-extra3 File Formats Manual
> +.el .ie '\\$2'6'  .ds an-extra3 Games Manual
> +.el .ie '\\$2'7'  .ds an-extra3 Miscellaneous Information Manual
> +.el .ie '\\$2'8'  .ds an-extra3 System Manager's Manual
> +.el .ie '\\$2'9'  .ds an-extra3 Kernel Developer's Manual
> +.el   .ds an-extra3
>  .ds an-init
>  \\..
>  .


Basicly it seems ok for me, ntl some (non roff note).
* Sun Release 4.0Why ?
The names differ from what i see in the man page.
e.g.: Sec 4   Special files

Should that be in sync also ?

re,
 wh

Re: [Groff] ping: let man print volume headers like mdoc

[walter harms]

Am 16.11.2011 12:40, schrieb Ingo Schwarze:
> Hi Walter,
> 
>> Basicly it seems ok for me, ntl some (non roff note).
>> * Sun Release 4.0Why ?
> 
> That's a comment, and my patch doesn't touch it.
> I guess whoever put it there wanted to provide an example
> how the fourth argument might look like.
> 
jup sorry my bad,
but i guess the comment that be replaced with something meaningfull


>> The names differ from what i see in the man page.
>> e.g.: Sec 4   Special files
> 
> Cannot reproduce; and indeed, tmac/doc-common in the official
> groff CVS repo has:
> 
>   .ds doc-volume-ds-4 Kernel Interfaces Manual
> 
> Maybe "Special files" is specific to your operating system
> or even the particular page you are looking at (you mentioned
> neither unless i missed it).
> 
>> Should that be in sync also ?
> 
> As far as i can see, it is.
> 
> Y

just for curiosity this is in my man page:
.
   0   Header files (usually found in /usr/include)
   1   Executable programs or shell commands
   2   System calls (functions provided by the kernel)
   3   Library calls (functions within program libraries)
   4   Special files (usually found in /dev)
   5   File formats and conventions eg /etc/passwd
   6   Games
   7   Miscellaneous (including macro  packages  and  conven-
   tions), e.g. man(7), groff(7)
   8   System administration commands (usually only for root)
   9   Kernel routines [Non standard]

HISTORY
 .
   31st March 2001 - present day: Colin  Watsonis
   now developing and maintaining man-db.

re,
 wh

>   Ingo
> 
> 
>>> - Forwarded message from Ingo Schwarze  -
>>>
>>> From: Ingo Schwarze 
>>> Date: Tue, 1 Nov 2011 19:43:27 +0100
>>> To: groff@gnu.org
>>> Subject: [Groff] let man print volume headers like mdoc
>>>
>>> Hi,
>>>
>>> When the mdoc(7) .Dt macro is called without a third argument,
>>> the page header uses the default volume name associated with
>>> the second (section number) .Dt argument, controlled by the
>>> doc-volume-ds-N strings in tmac/doc-common.
>>>
>>> On the other hand, when the corresponding man(7) .TH macro is
>>> called without a fifth argument, the volume name in the page
>>> header is left blank.
>>>
>>> Yuri Pankov (of IllumOS) suggested to make the two more similar
>>> by letting man(7) fill in the default volume name as well.
>>> I like the idea - reducing gratuitious differences between
>>> mdoc(7) and man(7) seems good to me - and would like to
>>> implement the change in mandoc(1).
>>>
>>> However, keeping groff(1) and mandoc(1) in sync is even more
>>> important than synching mdoc(7) and man(7), so i'm asking for
>>> your opinion first, whether you would accept the following patch,
>>> or a variant of it.
>>>
>>> I think the strings are so short that there is no problem
>>> with having them both in doc-common and an-old.tmac;
>>> on the other hand, if you disagree, i could move them to
>>> their own file and include them from both places, but
>>> i fear the code will be uglier, whereas this looks quite nice.
>>>
>>> Yours,
>>>   Ingo
>>>
>>>
>>> --- tmac/an-old.tmac.orig   Fri Dec 31 08:33:09 2010
>>> +++ tmac/an-old.tmacSun Oct 30 22:37:29 2011
>>> @@ -145,7 +145,17 @@
>>>  .ie (\\n[.$] > 3) .ds an-extra2 "\\$4\"
>>>  .el   .ds an-extra2 \"Sun Release 4.0
>>>  .ie (\\n[.$] > 4) .ds an-extra3 "\\$5\"
>>> -.el   .ds an-extra3 \"System Programmer's Manual
>>> +.el .ie '\\$2'1'  .ds an-extra3 General Commands Manual
>>> +.el .ie '\\$2'2'  .ds an-extra3 System Calls Manual
>>> +.el .ie '\\$2'3'  .ds an-extra3 Library Functions Manual
>>> +.el .ie '\\$2'3p' .ds an-extra3 Perl Programmers Reference Guide
>>> +.el .ie '\\$2'4'  .ds an-extra3 Kernel Interfaces Manual
>>> +.el .ie '\\$2'5'  .ds an-extra3 File Formats Manual
>>> +.el .ie '\\$2'6'  .ds an-extra3 Games Manual
>>> +.el .ie '\\$2'7'  .ds an-extra3 Miscellaneous Information Manual
>>> +.el .ie '\\$2'8'  .ds an-extra3 System Manager's Manual
>>> +.el .ie '\\$2'9'  .ds an-extra3 Kernel Developer's Manual
>>> +.el   .ds an-extra3
>>>  .ds an-init
>>>  \\..
>>>  .
> 

Re: [Groff] ping: let man print volume headers like mdoc

[walter harms]

Am 16.11.2011 15:38, schrieb walter harms:
> 
> 
> Am 16.11.2011 12:40, schrieb Ingo Schwarze:
>> Hi Walter,
>>
>>> Basicly it seems ok for me, ntl some (non roff note).
>>> * Sun Release 4.0Why ?
>>
>> That's a comment, and my patch doesn't touch it.
>> I guess whoever put it there wanted to provide an example
>> how the fourth argument might look like.
>>
> jup sorry my bad,
> but i guess the comment that be replaced with something meaningfull
> 

read:
  but i guess the comment can be replaced with something more meaningfull
> 
>>> The names differ from what i see in the man page.
>>> e.g.: Sec 4   Special files
>>
>> Cannot reproduce; and indeed, tmac/doc-common in the official
>> groff CVS repo has:
>>
>>   .ds doc-volume-ds-4 Kernel Interfaces Manual
>>
>> Maybe "Special files" is specific to your operating system
>> or even the particular page you are looking at (you mentioned
>> neither unless i missed it).
>>
>>> Should that be in sync also ?
>>
>> As far as i can see, it is.
>>
>> Y
> 
> just for curiosity this is in my man page:
> .
>0   Header files (usually found in /usr/include)
>1   Executable programs or shell commands
>2   System calls (functions provided by the kernel)
>3   Library calls (functions within program libraries)
>4   Special files (usually found in /dev)
>5   File formats and conventions eg /etc/passwd
>6   Games
>7   Miscellaneous (including macro  packages  and  conven-
>tions), e.g. man(7), groff(7)
>8   System administration commands (usually only for root)
>9   Kernel routines [Non standard]
> 
> HISTORY
>  .
>31st March 2001 - present day: Colin  Watsonis
>now developing and maintaining man-db.
> 
> re,
>  wh
> 
>>   Ingo
>>
>>
>>>> - Forwarded message from Ingo Schwarze  -
>>>>
>>>> From: Ingo Schwarze 
>>>> Date: Tue, 1 Nov 2011 19:43:27 +0100
>>>> To: groff@gnu.org
>>>> Subject: [Groff] let man print volume headers like mdoc
>>>>
>>>> Hi,
>>>>
>>>> When the mdoc(7) .Dt macro is called without a third argument,
>>>> the page header uses the default volume name associated with
>>>> the second (section number) .Dt argument, controlled by the
>>>> doc-volume-ds-N strings in tmac/doc-common.
>>>>
>>>> On the other hand, when the corresponding man(7) .TH macro is
>>>> called without a fifth argument, the volume name in the page
>>>> header is left blank.
>>>>
>>>> Yuri Pankov (of IllumOS) suggested to make the two more similar
>>>> by letting man(7) fill in the default volume name as well.
>>>> I like the idea - reducing gratuitious differences between
>>>> mdoc(7) and man(7) seems good to me - and would like to
>>>> implement the change in mandoc(1).
>>>>
>>>> However, keeping groff(1) and mandoc(1) in sync is even more
>>>> important than synching mdoc(7) and man(7), so i'm asking for
>>>> your opinion first, whether you would accept the following patch,
>>>> or a variant of it.
>>>>
>>>> I think the strings are so short that there is no problem
>>>> with having them both in doc-common and an-old.tmac;
>>>> on the other hand, if you disagree, i could move them to
>>>> their own file and include them from both places, but
>>>> i fear the code will be uglier, whereas this looks quite nice.
>>>>
>>>> Yours,
>>>>   Ingo
>>>>
>>>>
>>>> --- tmac/an-old.tmac.orig  Fri Dec 31 08:33:09 2010
>>>> +++ tmac/an-old.tmac   Sun Oct 30 22:37:29 2011
>>>> @@ -145,7 +145,17 @@
>>>>  .ie (\\n[.$] > 3) .ds an-extra2 "\\$4\"
>>>>  .el   .ds an-extra2 \"Sun Release 4.0
>>>>  .ie (\\n[.$] > 4) .ds an-extra3 "\\$5\"
>>>> -.el   .ds an-extra3 \"System Programmer's Manual
>>>> +.el .ie '\\$2'1'  .ds an-extra3 General Commands Manual
>>>> +.el .ie '\\$2'2'  .ds an-extra3 System Calls Manual
>>>> +.el .ie '\\$2'3'  .ds an-extra3 Library Functions Manual
>>>> +.el .ie '\\$2'3p' .ds an-extra3 Perl Programmers Reference Guide
>>>> +.el .ie '\\$2'4'  .ds an-extra3 Kernel Interfaces Manual
>>>> +.el .ie '\\$2'5'  .ds an-extra3 File Formats Manual
>>>> +.el .ie '\\$2'6'  .ds an-extra3 Games Manual
>>>> +.el .ie '\\$2'7'  .ds an-extra3 Miscellaneous Information Manual
>>>> +.el .ie '\\$2'8'  .ds an-extra3 System Manager's Manual
>>>> +.el .ie '\\$2'9'  .ds an-extra3 Kernel Developer's Manual
>>>> +.el   .ds an-extra3
>>>>  .ds an-init
>>>>  \\..
>>>>  .
>>
> 
> 

Re: [Groff] modern xman?

[walter harms]

Am 11.03.2012 01:03, schrieb James K. Lowden:
> Like everyone else, I normally use nroff and man(1) to view manpages.
> Sometimes I whimsically use xman or tkman.  
> 
> It occurs to me that I'm using a bitmapped display on a 3,300 MHz
> processor with quite a few fonts installed.  I could benefit from troff
> output and pretty, proportional fonts on my X display, if only there
> were a viewer designed for dealing with, oh, dvi or ps.  For extra
> credit, the "SEE ALSO" references could be "hyperlinks" that would
> create and load the referenced file when clicked on.  Really, this
> could be big.  
> 
> Is anyone here aware of a troff-ish project to display man pages?  I
> can name several projects, starting with info, designed to *replace*
> man pages with something better?  I observe we still have man pages.  I
> would be nice if we had something better than less(1) to view them in.  
> 
> A quick search of the archives doesn't turn up anything relevant, so I
> thought I'd ask.  
> 


Hi
there are tools that convert the man(doc) into html inclusive hyperrefs.
and there have been a lot attempts to replace man pages with something else
but all failed so far i can remember.
And to be fair it is very easy to write a man page, it takes few resources
and you can see it actually everywhere.

re,
 wh

[Groff] replacement for col

[walter harms]

hi list,
i run into a problem that may be solved by others already.

I show a groff file as latin1, that worked fine. i had some ^H but that where 
filtered by "tr"
no problem. But i added some boldface to the text and i got something like that 
N^HNi^Hic^Hch^Hht^Ht.
No real surprise i know that "col" could handle that. Unfortunately the current 
version (util-linux-2.21.2)
stumble over some umlauts in the text (older version also).

Does someone have an sed statement that replaces col ?
Is there an easy way to tell groff to avoid N^HN for bold ?

re,
 wh

Re: [Groff] replacement for col

[walter harms]

Am 24.07.2012 18:16, schrieb Denis M. Wilson:
> Hello all
> 
> On Tue, 24 Jul 2012 16:50:09 +0200
> walter harms  wrote:
> 
>> hi list,
>> i run into a problem that may be solved by others already.
>>
>> I show a groff file as latin1, that worked fine. i had some ^H but
>> that where filtered by "tr" no problem. But i added some boldface to
>> the text and i got something like that N^HNi^Hic^Hch^Hht^Ht. No real
>> surprise i know that "col" could handle that. Unfortunately the
>> current version (util-linux-2.21.2) stumble over some umlauts in the
>> text (older version also).
>>
>> Does someone have an sed statement that replaces col ?
>> Is there an easy way to tell groff to avoid N^HN for bold ?
> 
> Pass on options to grotty; the following removes all backspaces:
> 
>  groff -ww -Tlatin1 -P-c -P-b -P-o -P-u
> 

Works fine for me.
A nice extension for grotty would be a switch for pure/plain that disables
all bold, underlines etc.

re,
 wh

Re: [Groff] replacement for col

[walter harms]

Am 26.07.2012 14:17, schrieb Werner LEMBERG:
 Pass on options to grotty; the following removes all backspaces:

  groff -ww -Tlatin1 -P-c -P-b -P-o -P-u
>>> Works fine for me.  A nice extension for grotty would be a switch
>>> for pure/plain that disables all bold, underlines etc.
>>
>> You could combine them.  -P-cbou
> 
> Or write a simple shell script.
> 

Actualy I have a simple shell script NTL it would be convenied to disable all
styles at once.

re,
 wh

[Groff] Q: .B man macros and escape

[walter harms]

Hi list,
i found a minor issue within the man macros.
Most likely this is a know behaver but i found no mention of it.

As documented you can escape "\" by using "\\" or "\e\".
This went wrong in a man page. Please try the striped down example:

.TH test 3 test
.SH test
.B "\en"
.B "\\n"

with "man -l example.1" i see the \n only once.
Bug of feature ?
NTL i found no mention in groff_man.

re
 wh

Re: [Groff] Q: .B man macros and escape

[walter harms]

Am 04.10.2012 15:41, schrieb Werner LEMBERG:
> 
>> As documented you can escape "\" by using "\\" or "\e\".
> 
> To which documentation are you referring?

Unix Text Processing p.377
i guess it is also mentioned in the man/info pages related to groff.

> 
>> This went wrong in a man page. Please try the stripped down example:
>>
>> .TH test 3 test
>> .SH test
>> .B "\en"
>> .B "\\n"
>>
>> with "man -l example.1" i see the \n only once.
>> Bug of feature ?
>> NTL i found no mention in groff_man.
> 
> If you say
> 
>   groff -Tutf8 -man -ww mantest.man
> 
> you get the following warning:
> 
>   mantest.man:4: a newline character is not allowed in an escape name
> 
> which you've probably missed.  Reason is that `"\\n"' doesn't survive
> multiple expansions.  After the first expansion you have `\n', but
> after the second expansion this tries to access a number register
> which has the newline character as its name.
> 

I suspected this. The problem for user is that you use "man" and you do
no see any errors (most times this is really better).
The use of "\n" is a specific problem for man pages. I would suggest adding
a line that explains that and shows the alternative.

here my idea for "MACROS TO SET FONTS".

"If your \fItext\fP contains a backslash you will need to escape it. The most 
easy way
 of doing so is to use \ee."

hope that helps,
 wh


> You have to say
> 
>   .B "n"
> 
> to make it work with backslashes only.
> 
> 
> Werner
> 

Re: [Groff] GPL or FDL

[walter harms]

Am 25.01.2013 00:52, schrieb Colin Watson:
> On Thu, Jan 24, 2013 at 11:54:43PM +0100, Bernd Warken wrote:
>> This mail goes to the Debian admins. I think that's mostly
>> Colin Watson.
> 
> Exclusively me; I have no co-maintainers of the groff package at
> present.  That said, the General Resolution regarding the GFDL was a
> decision of the whole project.
> 
>>> Von: "Bernd Warken" 
>>>
>>> The groff source tree is usually licensed to GPL.  That is excellent.
>>>
>>> But there are also some documents under the GNU FDL.  This is regarded
>>> as bad by Debian.  Many years ago, Debian made the groff package as
>>> non-free because of the FDL.  So I changed many documentation files in
>>> the groff tree to GPL.
>>>
>>> In 2006, Debian made a voting wether the FDL should become free
>>> software:
>>> http://www.debian.org/vote/2006/vote_001.en.html
>>>
>>> They decided that the FDL without invariant sections would be compatible
>>> with Debian.
>>
>> Can you tell us what Debian says today about using FDL (without
>> invariant sections), especially for GNU projects like groff.
> 
> The most recent vote of the Debian project on the subject was the one
> that you link above.  However, I'm afraid you've misquoted the outcome:
> it says "unmodifiable sections", not merely Invariant Sections.  (The
> full text of the winning option was
> http://www.debian.org/vote/2006/vote_001#amendmenttexta.)  Cover Texts
> are unmodifiable in some contexts and fall under this ruling, and the
> GFDL application to groff.info includes both Front-Cover and Back-Cover
> Texts.  That is explicitly unacceptable to Debian.  If those Cover Texts
> were omitted then we would have no problem.
> 
> However, since the LICENSE file stipulates that all files part of groff
> are licensed under the GPL v3 or later, and I took care to explicitly
> clarify the intent of this with Werner in an e-mail discussion which I
> excerpted in the debian/copyright file in the Debian groff source
> package, this is not currently a practical problem for Debian.  We take
> advantage of the dual-licensing and distribute our groff packages under
> the terms of the GPL, not those of the GFDL.
> 
> At present, I see no need to rock the boat by changing anything; the
> dual-licensing of documentation files seems adequate.
> 


NTL, for some people that is an issue and i am not a friend of double licensing
because that may cause complication.
There is a license for linux man-pages 
[http://www.kernel.org/doc/man-pages/licenses.html]
Is there any reason not to use them ?

re,
 wh

Re: [Groff] hdtbl for tables of many pages in man

[walter harms]

Am 01.02.2013 01:39, schrieb Bernd Warken:
> I have a man-page with a table that is 3 pages long.  It works when
> I split it in 3 parts and call .TS/.TE for each.
> 
> I would prefer to use hdtbl.  You mention in groff_hdtbl(7) a
> macro that can go over several pages, but that works only in ms.
> 
> Is there something for several pages tables in man?  If possible
> the header should also be written at each new page.
> 
> Bernd Warken
> 
> 

I use the .TS H as mentioned in the man-page for tbl.

An other question is clearly are 3 pages long lists useful ?

re,
 wh

Re: [Groff] Spanish Hyphenation

[walter harms]

Could you write a short howto for that (e.g. using spanish as example) ?

That would be helpful for everyone adding a new language.

re
 wh


Am 21.08.2014 01:50, schrieb Yves Cloutier:
> I have created hyphen.es and es.tmac and all seems to work!
> 
> I exactly wasn't sure what I had to put in es.tmac, like the translations?
> I guess i can do that later - for now hyphenation seems to work well.
> 
> Thank you!
> 
> 
> On Tue, Aug 19, 2014 at 12:07 PM, Yves Cloutier 
> wrote:
> 
>> Thank you all for your suggestions.  I will try my best in the next day or
>> two.  It seems like a lot of tinkering!
>>
>>
>> On Tue, Aug 19, 2014 at 9:25 AM, Steffen Nurpmeso 
>> wrote:
>>
>>> Werner LEMBERG  wrote:
>>>  |Use this one
>>>  |
>>>  |  https://www.tug.org/svn/texlive/trunk/Master/texmf-dist/te\
>>>  |  x/generic/hyph-utf8/patterns/tex/hyph-es.tex?revision=18607&view=co
>>>  |
>>>  |and convert it to latin-1 with something like
>>>  |
>>>  |  iconv -f utf-8 -t iso-8859-1 < hyph-es.tex > hyphen.es
>>>  |
>>>  |Then create a file `es.tmac' (in latin-1 encoding!), using
>>>  |e.g. `sv.tmac' as a model.  That's it.
>>>
>>> Ah, i see that TeX has switched all hyphenation over to UTF-8, so
>>> that is indeed likely his problem then, hmm.
>>>
>>> --steffen
>>>
>>
>>