Hi
Unless I misunderstand something, shouldn't grog detect e.g. a
.cstart macro in a document and then come up with a suggestion
that includes the "-j" argument for the chem(1) preprocessor?
~/ % echo .cstart | ./grog.pl
groff -
These do not work either:
'lilypond', 'glilypond',
'Perl',
Trying to convert to pdf from this groff source:
.PS
elipse dotted
.PE
with the command:
groff -Tpdf -p
yields a broken/empty pdf. Opening it in e.g. zathura gives
this error message:
format error: cannot recognize version marker
warning: trying to repair broken xref
warning
Hi Branden,
On 2024-06-20 G. Branden Robinson wrote:
> The bug-groff list is mainly a reflector for Savannah ticket activity
> conducted via the WWW.
>
> Please consider filing future tickets directly with that system.
>
> https://savannah.gnu.org/bugs/?group=groff&func=additem
I shall do so fro
On 2024-06-20 Deri James wrote:
> Follow-up Comment #1, bug #65901 (group groff):
>
> After changing elipse to ellipse
That was a typo on my part. I did have "ellipse" in my source.
> in the two code examples, I can't recreate the first problem.
> The dots are visible in zathura.
Odd. The pdf
On 2024-06-20 Deri James wrote:
> Please could you run the dotted ellipse example again but adding this flag
> "-P-d", and post the resulting pdf. This adds some debug data which may be
> helpful.
I include it below, uuencoded.
Actually, it does show up in gv(1), but neither in zathura nor
mupdf
Follow-up Comment #2, bug #65936 (group groff):
[comment #1 comment #1:]
> What version of groff are you running?
I'm running 1.23.0
> Do you know if your system has pnmcrop installed (this is part of netpbm,
not groff)?
Yes, it is installed.
It is absolutely reproducible at my end.
__
Follow-up Comment #5, bug #65936 (group groff):
[comment #3 comment #3:]
> Is there any way you can get your hands on a different version of netpbm to
try it?
I downgraded netpbm from 10.86.42-1 to 10.86.40-1 which is the oldest version
in my Arch package cache. But the problem remains the same.
: None
___
Follow-up Comments:
---
Date: Wed 10 Jul 2024 06:41:40 PM UTC By: Morten Bo Johansen
The ./configure script didn't find the urw-base35-fonts:
configure: URW fonts in Type 1/PFB format were not
Follow-up Comment #2, bug #65974 (group groff):
The Foundry file is generated from the groff.m4 file, so all that is needed is
to add the paths to that file. I attach a patch which also includes the
$HOME/.fonts directory which is also a standard location for user installed
fonts. In the groff m4
Follow-up Comment #4, bug #65974 (group groff):
Okay. The groff configure script did not find the fonts on my Arch Linux
system, even though I have the ghostscript package installed.
Therefore I installed these urw-base35 fonts manually and as always when I
install something outside of the packag
: None
___
Follow-up Comments:
---
Date: Sat 13 Jul 2024 11:03:33 AM UTC By: Morten Bo Johansen
The make process completes well enough, but emits a whole bunch of errors and
warnings. I attach a lo
G. Branden Robinson wrote:
> You might want to disable grohtml and see what diagnostics remain when
> building.
How do I disable grohtml? I see no configure option for doing
so (or none that I understand).
signature.asc
Description: PGP signature
Follow-up Comment #3, bug #65985 (group groff):
I suppose your request for the information below was largely superseded by
<20240713-185904.sv108747.361...@savannah.gnu.org>
and <20240713-202450.sv108747.384...@savannah.gnu.org> ?
Anyway, in case you still want it, I supply it here:
The paper fo
Follow-up Comment #5, bug #65985 (group groff):
[comment #4 comment #4:]
> [comment #3 comment #3:]
> > The paper format is reported as:
> >
> >checking default paper format... letter
>
> Interesting! I was intrigued by the fact that every technique the
`GROFF_PAGE` macro uses to try to inf
: None
___
Follow-up Comments:
---
Date: Sat 20 Jul 2024 08:39:46 AM UTC By: Morten Bo Johansen
The grog source code has a comment:
_.TH is both a man(7) macro and often used with tbl(1). We expect to find .TH
in ms(7) document
On 2024-07-20 G. Branden Robinson wrote:
> There are limits to any heuristic tool's inferential power when presented with
> very small inputs as we might see with minimal bug reproducers. It's hard to
> accurately guess which macro package, if any, the input uses when there hardly
> *is* any inpu
16 matches
Mail list logo
