In the CVS I've updated groff.texinfo to use texinfo 4.8 --
unfortunately, it no longer works with older versions (causing an
endless loop on my Linux box which finally aborts due to a segfault).
Werner
___
Groff mailing list
[EMAIL PROTECTED]
ht
Michail has provided updates for afmtodit for better Unicode support
(which I've complemented with syntax updates to use Perl 5 features).
Please test!
Werner
PS: It took a long time to apply his changes because of postal delays
with his assignment papers.
__
> > In the CVS I've updated groff.texinfo to use texinfo 4.8 --
> > unfortunately, it no longer works with older versions (causing an
> > endless loop on my Linux box which finally aborts due to a
> > segfault).
>
> This is bad news, for those of us building groff on MS-Windows :-(
Well, it is ba
> In fact, even Groff hasn't applied patches submitted almost a year
> ago; see
> http://lists.gnu.org/archive/html/groff/2004-05/msg00206.html
Oops! I see this the first time, sorry. Will have a look soon.
In general, if you don't get an answer from me please resubmit the
mail.
Werner
> In fact, even Groff hasn't applied patches submitted almost a year
> ago; see
>
> http://lists.gnu.org/archive/html/groff/2004-05/msg00206.html
Kees,
your patch looks fine. To include it, I need papers from you (a
request has been sent separately). BTW, have you ever had a look at
`progreloc
> here is a better patch, I broke formatted text with the last
> patch,
Uh, too late. Please provide a patch w.r.t. to the current CVS.
Werner
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
> As an aside, will info 4.8 be required to to read the info files
> generated by makeinfo 4.8?
No.
Werner
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
> > Uh, too late. Please provide a patch w.r.t. to the current CVS.
>
> sure, here it is,
Applied, thanks.
Werner
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
> I've fixed this bug and a few others (many vertical space bugs have
> been quashed).
Right now I'm looking at my test output, pic.html, and I notice the
following two problems:
. Vertical space is missing right before a figure begins.
. Vertical space is missing after a figure ends.
Can
> yes, basically the groff_char source needs to be altered to use .ta
> rather than horizontal motion escapes.
This isn't optimal. I trust you if you say that horizontal motion
escapes can't be handled properly in grohtml. What I want instead is
to add a special HTML position tag so that grohtm
> Has anyone tried the EQN processor additions that I submitted 3
> weeks ago, and have any experimenters uncovered any problems?
> Assuming no problems, will the code be incorprated into EQN in the
> near future?
It looks very promising! Before integration I need your papers
(request sent separ
> Has anyone tried the EQN processor additions that I submitted 3
> weeks ago, and have any experimenters uncovered any problems?
I've now carefully read your sample_data document, without trying the
examples yet. A minor thing which slightly disturbs me is that I
always have to use a formatting
While studying eqn.y I've just discovered some features of GNU eqn which
appear to be undocumented in eqn.man.
. `undef' undefines a macro.
. `copy' is a synonym for `include'.
. `Alpha', `Beta', etc., is the same as `ALPHA', `BETA', etc.
. GNU eqn has two more predefined operators: `ldots' (t
> . The keyword `space' sets the vertical spacing (in hundredths of
> em), normally before and after an equation.
I forgot to mention two things:
. `space' is ignored if an equation is used within a picture
processed by pic.
. `space' replaces the default values for the top and bottom
> We could introduce a new tag (variant on .col tag, say .coln), which
> indicates that this position is has been generated via a \h
> motion. post-grohtml could check for sequences of `.coln' tags
> between `.sp' tags, record their positions and see whether they line
> up vertically (or at least d
> thebeast:/usr/src/groff-1.19.1# groff
> groff: can't find `DESC' file
> groff:fatal error: invalid device `ps'
>
> The groff on my Debian system is 1.18.1 and the groff I compiled is
> 1.19.1. I compiled the new groff statically, could that be a
> problem? Is this a bug, or do I need to set up
> If I understand correctly, you would like the format line to be
> optional,
Yes.
> but if specified to be preceded by the work "col".
Yes.
> As an option, the second format statement above might also be used
> (col "ll").
Mhm, perhaps it is better to use just one the formats. I don't see a
> (1) I googled on groff and japanese. There seems to be a "ja-groff"
>or "jgroff" with the proper extensions, but trying to find it
>became a kafkaesque adventure. I found diff.gz files at BSD ports
>(this is a slackware 10.0), and description files, and then ".tbz"
>files which
> Readin info groff I found how to do utf-8 output, but nothing about
> input :(
This is correct, unfortunately. groff doesn't yet support UTF8 input.
You have to convert your file first to something groff can understand.
Below is a small perl script which does that. Note that it doesn't
`fake
> > This is correct, unfortunately. groff doesn't yet support UTF8
> > input.
>
> But, it's something impossible to implement, or just it isn't
> interesting?
I want to do this since years, but there are always more important
things to do :-( Reason is that I'm involved in more than a single
pro
> > Right now I'm looking at my test output, pic.html, and I notice the
> > following two problems:
> >
> > . Vertical space is missing right before a figure begins.
> >
> > . Vertical space is missing after a figure ends.
> >
> > Can you fix this? Otherwise the output is nice!
>
> I belie
> It's taken a while, but I have now produced a suitable script
Great!
> I've attached the update as a tarball containing the two new files,
> `pdfroff.sh' and `pdfroff.man', together with a patch against the
> CVS versions on which my additional modifications are based
Only the attachment with
> But I've not got the fix yet. Here was my reply (a couple of days
> ago, maybe it got lost in a thread?)..:
I'm answering emails off-line normally. First I send my written
mails, then I receive the next bunch emails. While sending the mail
to you, I've received your answer :-)
Werner
_
Maybe some of you can use such a macro...
Werner
==
.\"
.\" .uppercase in out
.\"
.\" Convert the contents of string with name `in' to uppercase
.\" and return the result in a string with name `out'.
.\"
.\" Note th
> The patch file was also included in the tarball, along with the two
> new files.
Oops! A bug in mc prevented me to see the patch. Very strange.
> Consequently, I have modified my patch to set AC_PREREQ(2.59), and
> to use AS_HELP_STRING instead of AC_HELP_STRING throughout.
Thanks.
I've no
> There are two errors in the ChangeLog entry:
Fixed, thanks.
> Also, I've noticed two small problems with my coding, fixed by the
> attached patch: [...]
Applied.
Werner
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listin
> It seems there is a problem with this script.
> If there is an `Amacron' in the data, the script produces `u0100'.
> But glyphs in groff are named in decomposed form,
> glyph name for `Amacron' is `u0041_0304'.
> You can see this from unicode_decomposed hash in afmtodit
> and uniglyph.cpp & glyp
> .URL from www.tmac uses la and ra
> .URL is often used in the groff man pages.
Aah, I see. Can you do a survey which characters for la and ra could
be used also, this is, what popular UTF8 console fonts actually have?
It should be straightforward to add a fallback character with `.fchar'
to tt
A preliminary remark: Some of the features you are asking for are
possible but haven't been implemented in the macro packages.
> 1: Regarding color, is it possible to specify color for, say, drop
> caps, paragraphs, lines etc, in the CMYK color system?
Yes.
> 2: Being a non-programmer, font ins
> > .fchar \[la] <
> > .fchar \[ra] >
>
> Could we do that for \[hy] and \[mi] too?
Of course! Which entities do you suggest?
Werner
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
> > Below is a small perl script which does that. Note that it
> > doesn't `fake' glyphs, this is, it doesn't construct, say,
> > `Amacron' from an `A' and a `macron' glyph. Any volunteer for
> > this?
>
> It seems the following function is what you are looking for:
>
> $NFC_string = NFC($strin
> 1: Language, how is that handled? Different languages need different
> hyphenation files.
A general remark: groff uses a simplified version of TeX's hyphenation
algorithm; it can also directly read (simple) TeX pattern files.
There is basically no restriction on the number of languages which ca
> > Below is a small perl script which does that.
>
> This does not work (Mdk 10.2rc1, groff 1.19 with some mdk patches
> but they are unlikely be the cause). Manuals on mdk are in koi8-r,
> my locale ru_RU.UTF-8.
Actually, it does work. See below.
> :3: warning: can't find special character `
Gaius,
I've added Cyrillic entities to grohtml's fonts. To avoid zillions of
warnings, special care must be taken to select a proper font which is
used during the PS run. The easiest way is to add the following at
the beginning of the document:
.if '\*[.T]'ps' \
. fam UT
Here we assume
> > I want a library of artificial
> > characters which combines base characters and accents to composite
> > characters, [...]
>
> Such substuitution, if done properly, has to be font-dependent and
> resorted to only if the font lacks precomposed characters.
Right. This is what the `.fchar' req
> Like I said, I'm willing to fund some work and maybe Ted H. is the
> right guy. I'd like to see a new release of the docs: *roff
> reference & user guide, pic/tbl/eqn/etc, macro packages, etc.
To have groff documentation in info format has a) historical reasons
-- there already was a groff.tex
> Indeed, as Robert points out, texinfo 4.8 is now required; but also,
> IIRC, it had been previously been noted that 4.7 should *not* be
> used, because of a bug -- before the step up to 4.8, you had to use
> 4.6. Your use of 4.7 was always doomed to failure.
It has been shown that groff.texinf
> > I ran into the same problem, before noticing in the ChangeLog that
> > texinfo *4.8* is now required.
>
> Indeed, as Robert points out, texinfo 4.8 is now required; but also,
> IIRC, it had been previously been noted that 4.7 should *not* be
> used, because of a bug -- before the step up to 4.
> > This is a test
> > .IP X
> > Line number 2
> > .LP
> > .ce 1
> > Line number 3
>
> again, thanks for the report, here is a patch to fix the bug:
Applied, thanks.
Werner
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listin
Dear groffers,
I ask you to stop arguing for and against your favourite source code
revision management system. You've done your recommendations, and it
is now up to Larry K. to choose the system which fits his needs best.
Werner
___
Groff mai
> as far as I understand, the situation with character composition
> in groff is as follows [...]
Thanks for your analysis, to which I agree.
> 3) Metrics for some decent PostScript or TrueType fonts are to
> be included in groff distribution.
I think this will eventually come. The main ques
> I've rewritten the m.tmac patch to reflect changes in www.tmac. No
> functional changes beyond the previous patch; it simply marks
> headings for grohtml and disables headers & footers.
Applied, thanks!
Werner
___
Groff mailing list
Groff@gnu
I'm going to improve grotty, the TTY backend of groff, so that it can
handle zero-width and double-width characters, as needed for proper
Unicode support.
Doing so I wonder how is the backspace character (U+0008, \b) handled
in TTYs? Is there any documentation for it?
Most importantly: If I hav
> > I wonder whether it makes sense to add an option to grohtml so
> > that no PS run is executed. Instead of calling groff with -Tps it
> > should emit warning messages like `warning: table in line XXX
> > won't be converted'. My question: Is this possible at all?
>
> certainly it is possible, b
> You mean the "erase" character, right ?
I don't know how it is called correctly. Unicode says that `\b' (as
used in the C language) is U+0008 BACKSPACE.
Werner
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Sorry for being off-topic: Ralph, do you ever get mails from me sent
to you privately? I tried it a few times, and I never got a response,
so I now have the feeling that I'm somehow filtered out by your email
system.
Werner
___
Groff mailing lis
I've uploaded groff.html (from the current CVS) as
http://groff.ffii.org/groff/devel/groff.html.bz2
Werner
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
Thanks to all who have answered my questions. I was unclear
w.r.t. the backspace character: It isn't needed for positioning (this
is done internally in grotty before the output is emitted) but for
signalling that a character should be underlined or rendered bold.[1]
This isn't directly supported
> I forgot the documentation update. Use this patch tarball instead.
Applied, thanks!
Please use the `-u' switch of diff the next time.
Werner
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
> Yes thanks Werner and in return I offer `Yet another Drop Capital
> Macro'.
*Very* nice! This may be something for mom...
Below a patch for it.
Werner
==
--- dropcap.tmac.orig 2005-03-18 10:17:24.263842176 +0100
+
> However, I see a couple of problems:- [...]
Gaius, in case you've fixed those issues please repost your macro with
all patches applied.
Werner
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
> > 2) if there isn't enough following text to bring the paragraph
> >baseline below the bottom of the dropped cap, and the following
> >para also begins with a dropped cap, the indentation is messed
> >up for subsequent paras.
>
> I've not fixed (2) either.. does anyone see an obvious
> This also fixes dropcaps which vertically span more
> than a single paragraph.
Well, this is not correct. It fixes the case where we have empty
lines or a vertical space which is larger than the height of the
dropcap.
Werner
___
Groff mailing
> I have observed that groff changes certain characters in manpages.
> [...]
>
> For example, in perlcheat.1, the $| is changed into '$' and a
> vertical bar if the locale is UTF-8.
>
> real: | (U+0x7C)
> output: â (U+0x2502)
>
> This also to a number of other characters, including the backwa
> In the section on creating links to internet resources, I propose
> using the groff web site address in my examples. I note that this
> site is mirrored at `http://groff.ffii.org' and at
> `http://www.gnu.org/software/groff'; which of these is the preferred
> address to cite in my examples?
A
> This *shouldn't* have happened, so here's a patch to fix it ...
Applied, thanks.
Werner
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
> >The .tr request translates characters. In this particular case, it
> >translates `|' to `\(bv'. `bv' is equivalent to `braceex' in PS
>
> Hm, here's a suse'd perlcheat.1.gz, which when viewed with a plain text
> editor, contains $|, and not \(bv.
> (http://jengelh.hopto.org/f/perlcheat.1.gz)
> Aah, sorry, I've changed the `bv' mapping in later groff versions
> (U+2502 is wrong).
BTW, I've just read the XFree 4.5.0 release notes, and I've found this
item regarding xterm:
Add translation to ASCII of commonly-used characters that groff
translates to Unicode, when the font in use do
nt is the first whole word. This is
.\" automatically chopped into a letter and the subsequent
.\"letters are capitalised.
.\"
.\"Author Gaius Mulley
.\"Patches/fixes by: Keith Marshall and Werner Lemberg.
.\"
.\"It was ba
> I would like to translate troff.1 in French,
Great! Note that it is probably more important to translate groff.1
since this is what normal users should read first.
> - do you know if this has already be done?
As far as I know, this hasn't been done already.
> - the version of this manpage I
> Also is it possible to change the font eqn uses for
> variables?
Have a look at the `gfont', `grfont', and `gbfont' commands.
Werner
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
> While waiting for better suggestions, I played with
> .PS
> box xslanted color ...
> box yslanted
> .PE
> to get the following results (see attached file)
Nice! Can you send the source too? I wonder whether it is possible
to provide high-level macros to handle such 3d-boxes...
Werner
> > I'm printing the lyrics of a CD; I want it in 2-col; so I did
> >
> > .2c
> > .nf
> >
> > I wanted groff to *not* join short lines but break long lines;
> > Short lines were not joined, ok!
> > But groff did not break the long lines :-))
> > - Long lines in the first column invaded th
> Darn! It seems you beat me to the list by 30 minutes. But the
> funny thing is that this is not the first time we've come up with
> structurally the same solution to a problem. Does this imply that
> in groff normally only one workable approach to a problem exists?
Well, some solutions can't
> I got two pornographic-sounding spams today, one apparently from
> Werner, the other apparently from Ted Harding. Rather than wait to
> see if these are isolated incidents, I'm cut 'n' pasting both emails
> with full headers into this post.
Thanks. I've written a complaint to the savannah peo
Kees,
Your relocation changes are now in the CVS. I had to do some heavy
hacking to incorporate everything in a clean way. Please test.
Werner
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
> I think, if there's a problem with refer, it's the documentation.
> There's very little of it other than the manpage, and the manpage is
> a pure example of what can be both good and bad about manpages: it
> contains all the information you need, but in a form so terse you
> have to know the pro
> Is it considered a security risk to allow ~ or shell environment
> variables in the argument to .so? For example,
>
> .so ~/.groffrc
>
> .so $HOME/.groffrc
I don't think so. All `dangerous' requests like `.open' or `.sy' are
enabled only if you add the `-U' flag to groff.
Werner
___
I was asked whether ctype.h should be included in
src/roff/groff/pipeline.c -- this is for MS-DOS and Windows only. It
seems to me that it is not necessary, right?
Werner
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo
> I don't see any such calls in pipeline.c, so I think you are
> correct; it is not necessary.
Thanks, I've removed it.
Werner
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
--- Begin Message ---
The Free Software Foundation will be moving to a new office on
Friday April 29, 2005.
Starting Friday morning (GMT-4) and extending through the weekend, the
following FSF services will be unavailable:
* fencepost.gnu.org: GNU project shell server
* lists.gnu.org, lists.no
> The first problem was easy -- you're not allowed to have
> declarations mixed with code in C like you are in C++:
Applied, thanks.
Werner
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
> Here's a patch to add support for the creation of folded outlines,
> in any PDF document formatted using the pdfmark macros.
Applied, thanks.
> Also Werner, when (if) you apply this, could you also please correct
> a typo in my previous entry [...]
Fixed too.
Werner
__
> The problem appears to be due to the use of `realpath()' in
> `relocate.cpp'; the native Win32 equivalent for this function is
> `_fullpath()', and the semantics are different. It could probably
> be fixed with an appropriate `#define' in `nonposix.h', or, if this
> module is specific to Win32
> > Sorry, but I can't see any obvious clues in the make trace you posted.
>
> Neither can I, that's why I'm asking for help. :-)
Perhaps you can try to use `strace' or a similar program. Then you
can check where the files are searched.
Werner
__
On comp.tex.latex there was some discussion w.r.t. document layout
stability and hyphenation patterns:
Subject: Consistency of US hyphenation patterns across distributions
References: <[EMAIL PROTECTED]>
Up to today, noone has ever mentioned a similar problem here, and I
must admit that I've
> It appears that groff doesn't pass the command line font directories
> on directly but rather sets an environment variable
> ($GROFF_FONT_PATH).
This is correct.
> That variable does seem to be set correctly for both grn and troff,
> but they don't seem to be paying any attention to it.
Stran
> It turns out that the problem is that search_path::search_path is
> called from a static constructor, but static constructors are called
> *before* the global environment pointer is set, so getenv() doesn't
> work in a static constructor. Not being a C++ expert, I have no
> idea whether this is
> It was BSD/OS 4.2 too. I never found the time to get to the bottom
> of the problem and abandoned updating groff on that box. Somebody
> changed groff's build/install stuff to make it more Linux-specific,
> breaking backwards compatibility with the installed base.
??? This is nonsense. Norm
> When i process a pic file into a postscript file, for some reason it
> gets shrunk automatically, how do i stop this? i type this in the
> command line:
>
> pic floorB.pic | psroff -ms -t > floorB.ps
>
> and get this output:
>
> pic: 60 X 42 picture shrunk to 7 X 4.9
Uh, oh, whatever you use, i
> [...] I configured in a separate build directory, and uncovered a
> small problem with the `doc' directory. Specifically, the `gnu.eps'
> file needs to be in the build directory when `webpage.html' is
> formatted, but the make doesn't copy it from the source.
>
> Attached patch fixes this, [...
Nelson, groffers,
I'm going to release a new groff version, and I ask you to run the
current CVS snapshot tarball on your platforms to check for problems.
Honestly, I do expect minor glitches because I've updated the getopt
files to the latest versions of GNU libc.
You can find the tarball at
Keith,
thanks for the patch. I've simplified it a bit: Your _MAX_PATH code is
now in maxpathname.cpp. Please test.
Werner
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
> Just a quick note in case you haven't already noticed, the new GNU
> getopt routines that you checked in apparently require the GNU
> gettext routines, too (which you haven't checked in as yet):
@#$%! I missed it. Since groff doesn't use gettext, I'll undo the
change, reverting to the old fil
> >> http://groff.ffii.org/groff/groff-1.19.2-pre.tar.gz
>
> Actually, it's
>
> http://groff.ffii.org/groff/devel/groff-1.19.2-pre.tar.gz
Oops! Thanks for the correction.
Werner
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/m
> Having said that, I've subsequently realised that I omitted to test
> `pdfroff' on Cygwin. I've since done just that, and uncovered a
> problem with running in the `ash' shell, (which Cygwin uses, rather
> than `bash', in place of `sh').
>
> Here's a patch: [...]
Applied, thanks.
Werner
> Like the title line says, with the messages:
>
> getopt.c:73:22: gettext.h: No such file or directory
This is fixed now by reverting to the old getopt version. Will post a
new preprelease soon.
Werner
___
Groff mailing list
Groff@gnu.org
htt
> I could, but it wouldn't help -- the bug is in the system's startup
> code, which isn't part of the compiler. Fortunately, I have source
> code, so I can fix it. After setting up the environ global variable
> before running the initialization code, things work much better.
Can you prepare a s
> Using the tarball I mentioned in the other email, I've installed
> Debian stable's DejaGnu and after `./configure && make' get
>
> $ make -s check
> WARNING: Couldn't find tool init file
> Test Run By ralph on Sun May 1 19:27:48 2005
> Native configuration is i586-pc-linux-gnu
> However, my version *did* have one important difference -- according
> to MSDN, _MAX_PATH is defined in stdlib.h, which isn't #included by
> maxpathname.cpp, so you need to add that.
Done.
> If path_name_max() is to be used, in place of MAX_PATH in the
> _fullpath() call, should it not also be
> And thanks again, for this. Unless there are any objections from
> others, I'll investigate a solution based on option 4.
I agree. What the autoconf people use we can use also.
Werner
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org
> > is there a way to reset refer settings somewhere 'downstream' if
> > the 'upstream' defaults are no good?
> >
> > specifically:
> >
> > in my document I source a certain defaults file in which, upon
> > different other settings, one finds:
> >
> > ...
> > .R1
> > database the_standard_database
Good news for you, Jeff. Finally!
Werner
--- Begin Message ---
Werner LEMBERG <[EMAIL PROTECTED]> writes:
> Is there any reason to stay with `.cc' as the extension for C++ files
> for the autoconf tests, given that `.cpp' is much more portable?
Not that I know of.
> Sorry I didn't follow this thread and exact reason to change.
> I see this as a good reason to leave it as .cc
There are at least two C++ compilers (MSVC and a native OS/390 one)
which can't handle the `.cc' extension, while *all* C++ compilers can
handle `.cpp'.
> c++ -O2 -o tryme tryme.c
> I should have known better than to question the wisdom of groff
> developers. I guess I got paranoid using some other software where
> people are quick to introduce changes without thinking them through.
> Sorry for the noise.
Well, it's sometimes very valuable to have an advocatus diaboli :-)
> Should I rather use option 3, [...]
No.
> Attached is a small script, demonstrating a possible `searchpath'
> shell function. [...]
On my Linux box it works fine.
Werner
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/list
> Hi, I'm new to pic/groff and I've been having some problems
> producing either gif or jpeg images using them. The basic problem
> seems to be that pic/groff/postscript all have the concept of a page
> that they are drawing on whereas I want the resulting image to have
> all the whitespace croppe
> Hmmm, what I didn't notice was that this time the _bottom_ of the
> image wasn't getting cropped!
This seems to be a bug. Please send me an example file together with
the exact command line.
Werner
___
Groff mailing list
Groff@gnu.org
http://
> Hi, create a file foo.pic containing just one line:
>
> box "hello world"
>
> process like this:
>
> pic2graph -format jpg -density 90 < foo.pic > foo.jpg
>
> if you put foo.jpg into a web page you can see that there is a load
> of blank space below the box.
>
> This was using groff version
> By the way, another weird little quirk which doesn't seem to be
> mentioned in my admittedly brief read of the documentation: if your
> diagram goes beyond the default width as understood by pic then it
> starts scaling the image automatically! It's really baffling when it
> first happens - you m
1 - 100 of 2232 matches
Mail list logo
