>
> What do you think about a warning for drawing outside the page boundaries?
I can't see that benefiting anybody, quite frankly. Since all coordinates
are precomputed, users are unlikely to see such a message in practice.
Personally, I find Groff's postprocessors too chatty, and would really
a
On 2020-11-22 at 13:10:15, John Gardner wrote:
> >
> > He declared a groff-compatible ps device resolution of 72000 but didn't
> > scale his arguments.
>
>
> That's assuming he didn't patch devps/DESC locally with an arbitrary `
> sizescale` or `unitwidth` parameter (which may have been an attemp
On Mon, Nov 23, 2020 at 03:02:49AM +1100, G. Branden Robinson wrote:
> At 2020-11-22T16:08:56+0100, Ingo Schwarze wrote:
> > Sure. I dislike the concept of mdoc.local for more than one reason,
> > but probably it is good enough for this purposes if there is no
> > better way in Debian. If mdoc.lo
See groff bugs #58164 and #59461 for the history of this.
I have simplified the testing script, making it internally independent
of any locale issues.
So, what is left, is testing by others in their real or created
environment.
The original test is in
"src/roff/groff/tests/smoke-test_htm
At 2020-11-22T16:08:56+0100, Ingo Schwarze wrote:
[worthy backgrounder snipped]
> There are many obvious problems in the design:
>
> 1. The syntax is not really consistent: both coded references
> like "BSD" "4.4" and free text strings are supported.
Yes, I found this particularly startli
At 2020-11-23T00:10:15+1100, John Gardner wrote:
> IMHO, it would be more intuitive to make this
[a positioning command before the first 'p' command]
> a no-op, rather than an error (a warning at *most*). Users may wish to
> "prepostprocess" the formatted output to control page order, extract
> or
Hi Branden,
i have to admit that .Os is among the worst-designed parts of the mdoc(7)
language. First, it was't designed consistently to start with. The first
major release it was widely used in was 4.4BSD. Already in that release,
it was documented in the mdoc(7) manual as
"OPERATING_SYSTEM
>
> He declared a groff-compatible ps device resolution of 72000 but didn't
> scale his arguments.
That's assuming he didn't patch devps/DESC locally with an arbitrary `
sizescale` or `unitwidth` parameter (which may have been an attempt to make
coordinates easier to visualise). But your point st
At 2019-12-21T14:51:23+0100, Ingo Schwarze wrote:
> Colin Watson wrote on Tue, Dec 17, 2019 at 01:15:30PM +:
> > On Tue, Dec 17, 2019 at 01:14:06PM +, Colin Watson wrote:
> > Side note: I am not the biggest fan of this business of encoding a
> > bunch of other projects' release history in g
At 2020-11-22T23:15:46+1100, G. Branden Robinson wrote:
> I'm attaching his version of the grops crasher, my reduced and
> corrected version, and a diff between them.
Why do I say these things when I know I'll forget to do it?
Trying again.
Regards,
Branden
x Typesetter ps
x resolution 72000 1 1
At 2020-11-22T13:42:22+1100, John Gardner wrote:
> >
> > In the meantime, John Gardner, who's written his own "ditroff"
> > interpreter in JavaScript, might be able to offer some useful insights
> > on the well-formedness of your sample documents.
>
> Sorry, I completely missed this.
No worries.
package groff-base
tag 421437 + upstream fixed-upstream
thanks
I can verify that, as I suspected (I mention that only because my
suspicions are so often incorrect), both instances arose from the same
bug, fixed in groff upstream last year and expected in the 1.23.0
release.
Details:
$ grodvi ./c
12 matches
Mail list logo
