Michail Vidiassov mas...@iaas.msu.ru wrote:
is it possible to compile Heirloom for Windows?
Are there any prebuilt packages anywhere on the Net?
I don't know. It is software for Unix systems. Some of it
may compile using Unix emulation libraries, some if it may
not.
Gunnar
FENG Yu Ning fengyuning1...@gmail.com wrote:
Since I cannot find the mailing list of Heirloom, and the maintainer
seems to be on this list, I think it might be proper to ask for help
here.
It's better if you contact me directly.
I ran into trouble trying to use some Chinese ttf fonts in
Werner LEMBERG [EMAIL PROTECTED] wrote:
| If no line length is specified in the block of text itself, or in
| the table format, the default is to use LxC/(N+1) where L is the
| current line length, C is the number of table columns spanned by
| the text, and N is the total number of
Werner LEMBERG [EMAIL PROTECTED] wrote:
Note that heirloom's output is worse (I've used a compiled CVS version
from 2007-Jan-09). Using `tbl | nroff -Tlp' I get
a a c c
[7 b b b b b
b b b b b
b b b b b
b
e e
[7d d
Tadziu Hoffmann [EMAIL PROTECTED] wrote:
But seriously, regarding document portability I concede your
point: anything that goes beyond the standard should become
part of the document. (Especially that cross-font kerning
is a pretty neat idea.)
On the other hand, the same goes for
Tadziu Hoffmann [EMAIL PROTECTED] wrote:
The kerning information, however, can be modified without
a new font being created, because it is something the font
doesn't know about. [Don't know what the situation is with
OpenType.]
Principally the same, in that the kerning information is not
Tadziu Hoffmann [EMAIL PROTECTED] wrote:
The neat thing about groff's way of having the (editable)
metrics file separate from the actual font file (as opposed
to, say, a system where the metrics are read directly from a
not-so-easily-editable truetype or opentype font file), is that
it is
Denis M. Wilson [EMAIL PROTECTED] wrote:
I have to take issue with this. My printer (lj4) does not have
the fonts, its builtin fonts I cannot use because I require to
preview before printing. Everything is done via GhostScript.
There also is the option to simply buy the fonts, they are
(Ted Harding) [EMAIL PROTECTED] wrote:
I don't see any way of working round this, given the way
'tbl' works,
The content of T{ T} is evaluated only once.
Gunnar
James Cloos [EMAIL PROTECTED] wrote:
I'd also love to see full libhnj support. (Probably should have two
registers, one for choosing the libhnj hyphenation algorithm and a
second one to choose the line breaking algorithm. Just to ensure old
documents do not reflow unless one asks for the
Gunnar Ritter [EMAIL PROTECTED] wrote:
eqn produces a \^ where it should produce
a \|. I'll find a way to make that work properly and tell
you when it's done.
The fix is now in CVS. Thanks for reporting and insisting
on the issue being fixed.
Gunnar
Werner LEMBERG [EMAIL PROTECTED] wrote:
geqn seems to ignore part of explicit provided spaces ~ in the
above example (it seems to be the default spacing anyway). Is this
intended behaviour: increase spacing only by the difference of
explicit provided space and default space?
It seems
Joerg van den Hoff [EMAIL PROTECTED] wrote:
and compare geqn/groff with heqn/htroff generated ps
output _and_ with the above document from bell labs you'll
see especially that in the original doc the equation is
typeset with _some_ spacing, different from groff but more
(and
Gunnar Ritter [EMAIL PROTECTED] wrote:
Okay, I now see that I introduced that problem myself back
in November 2007;
2005, I mean.
Gunnar
Joerg van den Hoff [EMAIL PROTECTED] wrote:
shows that the hat is sort of right aligned above the K,
not centered as the dot is in the ps output. moreover the
vertical distance above the K seems different for both marks
(probably they both are top aligned in this direction?).
Thanks. A
brian m. carlson [EMAIL PROTECTED] wrote:
It's my experience that this is common with combining diacritic marks in
most TrueType fonts. In other words, this bug is not specific to
Heirloom troff, but instead probably a problem with the fonts.
No, this was not the problem here. Both
Michael Kerpan [EMAIL PROTECTED] wrote:
After joining this board (and being mostly a lurker), I've been clued
in to the awesome -mom macro package. I'd like to use it with my
extensive collection of OTF fonts, but it seems like groff's font
support rather lags behind that of Heirloom troff...
Michael Kerpan [EMAIL PROTECTED] wrote:
...that groff/troff seems to be written off by so many as obsolete
and only useful for man pages, despite the fact that it can do
everything that TeX/LaTeX (seemingly the favored non-WYSIWYG document
processor) can do
First, it cannot. TeX provides
Hi,
doc.tmac contains the following lines:
.ie (\n[doc-reg-dpr1] == 2) \
. \ the `\%' prevents hyphenation on a dash (`-')
. nop \%\*[doc-str-dpr]\\c
.el \{\
. \ punctuation character
. nop \f[\n[doc-curr-font]]\s[\n[doc-curr-size]u]\c
. nop
Werner LEMBERG [EMAIL PROTECTED] wrote:
Fixed in CVS. Please test.
Works fine here. Thanks.
Gunnar
___
bug-groff mailing list
bug-groff@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-groff
Frank Jahnke [EMAIL PROTECTED] wrote:
pinot% sed 9q figure9-acrobat.eps
%!PS-Adobe-3.1 EPSF-3.0
%ADO_DSC_Encoding: Windows Roman
%%Title: figure9.pdf
%%Creator: Adobe Acrobat 8.0
%%For: Administrator
%%CreationDate: 10/15/2007, 12:12:48 PM
%%BoundingBox: 0 0 536 152
%%HiResBoundingBox: 0
Frank Jahnke [EMAIL PROTECTED] wrote:
Well, in the most recent example, I used OO.o draw to combine three .jpg
images into a single file after cropping them with gimp. These came
from a colleague's CAD program -- I could start with a different format,
but JPEGs are pretty standard.
I am not
Bob Diertens [EMAIL PROTECTED] wrote:
This was already there in the PWB/MM Programmer's Workbench Memorandom
Macros, D.W. Smith and J.R. Mashey, October 1977.
So there only a bug in the groff_mm manual page.
The same document also mentions the names used by PWB/MM in the chapter
Extending
M Bianchi [EMAIL PROTECTED] wrote:
I think the right answer it to document what the current macro package does
You seem to refer to your variant, since there are multiple
current ones in existence (at least yours, Sun's, and mine).
By the way, does the groff_mm documentation describe which
Keith Marshall [EMAIL PROTECTED] wrote:
It's a genuine troff mm-ism. E.g. we found out about it from the book
by Narain Gehani (of ATT) Document Formatting and Typesetting on the
UNIX System, ISBN 0 -9615336-0-9 (highly recommended, BTW).
This may establish `prior art', but it doesn't
(Ted Harding) [EMAIL PROTECTED] wrote:
I don't have access to macro files for other troffs at the
moment, but I've browsed around in such documentation as
I can find, without seeing a reference to a number register
:p in mm.
Werner LEMBERG [EMAIL PROTECTED] wrote:
To avoid this, you need to decide what characters to use as quotes
on a per-font basis. (None of the Postscript fonts I know have
dedicated german quotes. Does Unicode?)
Yes:
U+201EDOUBLE LOW-9 QUOTATION MARK
U+201FDOUBLE
Axel Kielhorn [EMAIL PROTECTED] wrote:
Use whichever is most acceptable! There is a very slight difference
between \[Bq] and ,, : to get ,, to be exactly like \[Bq] you must
a) Move the first , leftwards by pointsize*0.0012 points
b) Then move the second leftwards by pointsize*0.002
(Ted Harding) [EMAIL PROTECTED] wrote:
The loop constantly checks whether the timestamp on myfile.tr
is more recent than that of myfile.watch and, if it is, then
groff is run on myfile.tr to generate myfile.ps, and then a
'kill -1' is sent to 'gv' so that it re-reads myfile.ps and
displays
Werner LEMBERG [EMAIL PROTECTED] wrote:
it seems not to have made it into the development snapshot dated
19-march-2007 13:08 (I downloaded that right and encounter the same
problem as before). is this to be expected or is something wrong
with the update of the snapshot?
Those snapshots
Joerg van den Hoff [EMAIL PROTECTED] wrote:
What is the point in using a snapshot anyway? cvs update -dP
working around my ignorance, of course :-).
I've never used `cvs' at all, so I don't know the commands. If you don't mind:
what need I to enter precisely to get the whole groff package?
Werner LEMBERG [EMAIL PROTECTED] wrote:
I'm not sure whether this classifies as a bug at all; it would take
some time to rewrite troff to handle that case gracefully (and I
haven't checked yet whether this is possible at all). Opinions,
please. Gunnar, how does your troff behave?
It prints
Werner LEMBERG [EMAIL PROTECTED] wrote:
So I want to know is it possible in these way and whether or not
ps2pdf can make an cid embeded pdf file from the one produced by
grops?
This looks like a bug in gs -- I think if you want long enough, gs
eventually finishes. Maybe you should try
Jeff Zhang [EMAIL PROTECTED] wrote:
And I also tried Heirloom Documentation Tools, it seems just works for
normal otf file not for my generated pfb file to produce utf8 contained
file.
This is because the OpenType font contains a Unicode mapping
table (i.e. a table that says U+E046 is named
Jeff Zhang [EMAIL PROTECTED] wrote:
I've also tested with ttf file (I'm an newbie to troff)like:
.do xflag 3
.lc_ctype zh_CN.utf8
.fp 1 R STXingKai ttf
.fp 0 T STXingkai ttf
.ft T
中文
It also gives error:
troff: Can't load font...
maybe it duce to the ttf file, I'm not very sure.
If
Jeff Zhang [EMAIL PROTECTED] wrote:
On 3/14/07, Gunnar Ritter [EMAIL PROTECTED] wrote:
Jeff Zhang [EMAIL PROTECTED] wrote:
I've also tested with ttf file (I'm an newbie to troff)like:
.do xflag 3
.lc_ctype zh_CN.utf8
.fp 1 R STXingKai ttf
.fp 0 T STXingkai ttf
Jeff Zhang [EMAIL PROTECTED] wrote:
After correct the name, it can produce ps file without error message.
However, it almost can't be converted into pdf by ps2pdf or to view it by
gv, for it runs very long time to convert and I have to kill ps2pdf.
Yes, I know that for whatever reason, if you
Clarke Echols [EMAIL PROTECTED] wrote:
I have been asked to evaluate a book project with the possibility
that I will be producing it for publication. The author sent me
a WordPerfect file (.wpd suffix) that my Microsoft stuff won't read.
OpenOffice has a WordPerfect input filter, and from
Werner LEMBERG [EMAIL PROTECTED] wrote:
. If you use a table within a man page, the first line should be
.\ t
Not exactly, it should be
'\ t
At least this is the convention on SunOS, and, following that,
on SVR4 derivatives. (The first reference I can find is in a
SunOS 4
Zvezdan Petkovic [EMAIL PROTECTED] wrote:
On Fri, Feb 02, 2007 at 07:44:10PM +0100, Werner LEMBERG wrote:
. The proper way to write an ellipsis is `.\|.\|.\', optionally
starting with `\'. Please don't omit the `\|' -- it looks quite
ugly in PostScript output if the dots don't
X-Content-Filtered-By: Mailman/MimeDel 2.1.5
This filtering component is stupid. Why doesn't it discard
a message after it has deleted all content anyway?
Gunnar
___
Groff mailing list
Groff@gnu.org
Werner LEMBERG [EMAIL PROTECTED] wrote:
HOWEVER, if groff can be compiled and run on HP-UX, groff-oriented
man pages will also need to be installed in the usual directories on
HP-UX systems, and HP-UX users will expect to be able to run the man
command on those pages.
If groff finds
Eric S. Raymond [EMAIL PROTECTED] wrote:
(2) Add portable implementations of .URL and .MTO to an-old.tmac
That would be OK.
I've written such implementations and added them, not to an-old.tmac
but to the standard preamble I've developed for groff pages. (This
is also where I've
Eric S. Raymond [EMAIL PROTECTED] wrote:
Gunnar Ritter [EMAIL PROTECTED]:
I've written such implementations and added them, not to an-old.tmac
but to the standard preamble I've developed for groff pages. (This
is also where I've defined .SY, .OP, and .YS.) In every case I've
looked
Eric S. Raymond [EMAIL PROTECTED] wrote:
Gunnar Ritter [EMAIL PROTECTED]:
Yes, and authors would also get nasty bug reports from
people who compile their manual pages with the switch
turned off because it is the default. This would be as
bad as gcc shipping with -Wall enabled by default
Eric S. Raymond [EMAIL PROTECTED] wrote:
Huh? What world are you living on, Eric? In yours, people
like browser windows popping up, make no use of browser tabs,
and especially do not have their tabbed browser on another
virtual desktop than their xterm(s)? Sounds like a strange
mirror
Eric S. Raymond [EMAIL PROTECTED] wrote:
Gunnar seems to think UTF-8 is the right direction.
Yes, with the exception of CJK writers, people all over
the world seem to agree on that, and it is unlikely that
anybody except those will even have the idea to write
text documents like troff input in
Eric S. Raymond [EMAIL PROTECTED] wrote:
Maybe. But still the tools should not complain if a troff
expert has decided that something is safe.
And how are they going to do that? Mental telepathy? :-)
As I wrote in the text following, by separating a lint
(or -Wall) mode and silent regular
Eric S. Raymond [EMAIL PROTECTED] wrote:
Gunnar Ritter [EMAIL PROTECTED]:
All I want is to avoid an incomplete hack extension to -man
which seems useful just for this discussion but does not
result in a general improvement.
What you're likely to get is an incomplete hack extension that's
Eric S. Raymond [EMAIL PROTECTED] wrote:
Gunnar Ritter [EMAIL PROTECTED]:
Maybe. But still the tools should not complain if a troff
expert has decided that something is safe.
And how are they going to do that? Mental telepathy? :-)
As I wrote in the text following
Eric S. Raymond [EMAIL PROTECTED] wrote:
Note that .br/.nl, .ti, .ta, and .in are *not* in the portable set.
These cannot be translated structurally by doclifter, and man-to-HTML
translators tend to ignore them or give useless results as well.
. . .
I noted previously that \w is *not*
Eric S. Raymond [EMAIL PROTECTED] wrote:
But now you say One can safely use almost all requests if their context
is pure visual nroff markup which does not hurt when omitted. You
reverse the thrust of your earlier argument, and you do it in a way
that makes no sense to me!
It is actually
M Bianchi [EMAIL PROTECTED] wrote:
If it is always created in groff tbl(1), can we get this documented in the man
page? As part of GNU TBL ENHANCEMENTS ?
But \n(TW is not a GNU tbl enhancement. It has always
been part of tbl and is documented in the Usage chapter
of Mike Lesk's original
Michael(tm) Smith [EMAIL PROTECTED] wrote:
Eric S. Raymond [EMAIL PROTECTED], 2006-12-24 13:01 -0500:
XSL-FO to troff would be far more appropriate. XSL and troff are at about
the same level; thus, you wouldn't have to wire in all the policy/styling
decisions you would in a DocBook-troff
Eric S. Raymond [EMAIL PROTECTED] wrote:
I've described the two extensions I think would be merited. The sort
of good-practice guidelines I nean are things like don't use troff
requests outside the safe set and don't put running-text notes in a
synopsis section and don't write multiple
[EMAIL PROTECTED] wrote:
Von: [EMAIL PROTECTED]
There has never been any IETF RFP, nor ANSI/ISO/W3C committee work.
Thus, there is no de jure standard here, only a de facto one.
It is the GNU standard, so it is the standard in the world of free software.
We spit on all commercial
Larry Kollar [EMAIL PROTECTED] wrote:
Reading the discussion, I feel like Bernd's objection is based on a
perception that ESR wants to *replace* groff -man with DocBook, where
I believe he wants to use DocBook as an *interchange* format for all
system documentation.
But this is not
Eric S. Raymond [EMAIL PROTECTED] wrote:
Gunnar, you could help by reporting which requests Heirloom Troff
Heirloom troff supports almost all groff requests; a complete
list is in http://heirloom.sourceforge.net/doctools/troff.pdf.
The exceptions are mainly in areas which are irrelevant in the
Eric S. Raymond [EMAIL PROTECTED] wrote:
Ralph Corderoy [EMAIL PROTECTED]:
Will /usr/share/man still have roff man pages as well as the HTML
conversion?
Probably. But is likely that man will at some point start presenting
through the browser by default if you have a BROWSER variable
mhobgood [EMAIL PROTECTED] wrote:
It's the 21st century, all the documentation on my system ought to
present as a hypertexted local Web through my browser.
Subject two. That is your personal preference. Myself, I'm quite
happy to use other forms for documentation; forms that do not
Werner LEMBERG [EMAIL PROTECTED] wrote:
I tend to advocate the use of .DS/.DE, .TQ, .EX/.EE, .SY, .OP, and
probably other nifty things to be used within man pages, *together*
with its macro definitions in the preamble. This gives us both a
decent markup and backwards compatibility.
This is
Werner LEMBERG [EMAIL PROTECTED] wrote:
http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap12.html
However, those rules are not really helpful IMHO in our discussion how
such macros should look like.
It gives an overview about the types of arguments that need
to be handled by
Eric S. Raymond [EMAIL PROTECTED] wrote:
An examination of the CSRG archives shows that .Ds had been
defined in -mdoc as a filled block display in 4.3BSD-Reno,
but was deleted with 4.4BSD.
Which DocBook tag should correspond to .DS?
A *filled* block display?
Not really. I have
Eric S. Raymond [EMAIL PROTECTED] wrote:
I have since written a little tool called 'mangrep' that recurses
zgrep -l over the manual tree.
Heirloom Toolchest grep -rz :-)
It shows me that in my corpus, DS is in
these 21 files:
Okay, so this effectively means that two people assume .DS
Eric S. Raymond [EMAIL PROTECTED] wrote:
Werner LEMBERG [EMAIL PROTECTED]:
I think it might not be a bad idea for troff to throw warnings when
a man page uses a troff request outside the safe set. Note that I
am *not* recommending this measure for troff documents other than
man
Werner LEMBERG [EMAIL PROTECTED] wrote:
It seems that we can do a decent job by adding a small set of
additional macros to man; this would have the benefit of getting a
clear conversion with doclifter, and a standardized interface for
future man pages (which current ones might adopt also).
Eric S. Raymond [EMAIL PROTECTED] wrote:
Gunnar Ritter [EMAIL PROTECTED]:
Real *roff is hardly the problem since it has supported the
two-character requests (except .do) for more than thirty years
now. The issues are with scripts that convert manual pages or
build indexes for them
Eric S. Raymond [EMAIL PROTECTED] wrote:
Gunnar Ritter [EMAIL PROTECTED]:
I have often used .in (and seen it used) in a context like
informalexample. Looking at a few pages, it seems that
others have used .ti similarly.
Can you send me an example?
This is from mush(1), July 17, 1996
Eric S. Raymond [EMAIL PROTECTED] wrote:
See my long reply to Larry Kollar. It's not clear to me that anything
interesting can be deduced here, but I'm open to suggestions. What
kind of semantic-level tagging could we use in this situation? Would
blockquote be the right thing here?
Werner LEMBERG [EMAIL PROTECTED] wrote:
I would claim it is. The groff manual pages also cannot be
displayed properly by other manual page viewers. There are
some glitches even with Heirloom troff; although it can handle
the language, some groff-specific macros do not exist in its
M Bianchi [EMAIL PROTECTED] wrote:
+-+ ++
| man pages |-+ +---| HTML on browsers |
+-+ | / ++
|
(Ted Harding) [EMAIL PROTECTED] wrote:
In other words,
.kp Font c1 d1 n1 c2 d2 n2 ...
would extend the kern-pair table for font Font by the lines
I have introduced a .kernpair in Heirloom troff. It is
similar to your proposed groff request but also allows to
specify different fonts for
Larry Kollar [EMAIL PROTECTED] wrote:
This sounds extremely promising. I haven't had a look (yet), but if it works
as
advertised, it would be a great way to rescue documents from MS Word since
OOo does a pretty good job of reading them (indeed, I've seen it do better
than Word with
Hi,
I announce the availability of an import filter to convert
OpenDocument files to troff input. I have released it as
part of my Heirloom Documentation Tools package, but since
it is not actually specific to a troff variant, it may be
useful with groff as well.
As most of you probably know,
Werner LEMBERG [EMAIL PROTECTED] wrote:
At the same time, I've disallowed `\s-[-...]' and friends.
Why? Their previous behavior was just fine mathematically.
Gunnar
___
bug-groff mailing list
bug-groff@gnu.org
Werner LEMBERG [EMAIL PROTECTED] wrote:
At the same time, I've disallowed `\s-[-...]' and friends.
Why? Their previous behavior was just fine mathematically.
First of all, it isn't documented.
Yes it is: \s+[N] ... N is a numeric expression.
Note that you are now also disallowing code
(Ted Harding) [EMAIL PROTECTED] wrote:
On 03-Sep-06 Gunnar Ritter wrote:
.ds a \ \h'-1u'
.ll \w'some\*a text and a \(br'u
some\*a text and a \(br
some text and a \(br
(The box rules should not align.)
Gunnar
That's an interesting comment. I've tried tracing
(Ted Harding) [EMAIL PROTECTED] wrote:
length is pointsize/2 (or 0.5m). And, for what it is worth, I'm
using the defaults for \n[.ss] and \n[.sss], namely 12/36m.
Just to clarify this: 12/36m was the size of the space character
in CAT troff. ditroff and groff include the size of the space
Werner LEMBERG [EMAIL PROTECTED] wrote:
I haven't found out yet the cause of this behaviour; I invite you to
use a debugger so that you can find the relevant spot. :-)
The problem is in environment::do_break() after the comment
this is so that hyphenation works. A zero-length space is
added,
(Ted Harding) [EMAIL PROTECTED] wrote:
1. I'm not aware of a simple mechanism in groff to
do this -- e.g. fill all lines whose minimum
formatted length is within X of line-length.
ATT troff has a \n(.x register which holds the remaining
horizontal space on the current output line. Thus
(Ted Harding) [EMAIL PROTECTED] wrote:
2. \[.rl] of course does not exist so would get value 0
if invoked.
The following works with groff:
.de SP
. if (\\n(.k+\\n[.in])=(\\n(.l-1n-\w' ') .brp
. sp
..
Note that there is an incompatibility between ATT troff and
groff here: ATT
Hi,
I am pleased to announce the availability of a groff
compatibility mode and macro set in Heirloom troff
http://heirloom.sourceforge.net/doctools.html. In
this mode, Heirloom troff is currently able to
- interpret output from GNU tbl, eqn, and pic
- use the -ms macros from groff
- format
82 matches
Mail list logo
