> From: groff-bounces+jeff_conrad=msn@gnu.org bounces+jeff_conrad=msn@gnu.org> On Behalf Of Tadziu Hoffmann
> Sent: Wednesday, 28 August, 2024 9:59 AM
> To: groff@gnu.org
Regionalism
===
> I suspect conventions might be strongly regionally
> dependent.
For sure. And political.
> From: Jeff Conrad
> Sent: Monday, 26 August, 2024 8:39 PM
> To: 'groff@gnu.org'
> > From: G. Branden Robinson
Aagh ... from me, not Branden. One of these days I’ll figure
this out.
Something obvious I overlooked: for a command with long options,
there’s probably
> From: Jeff Conrad
> Sent: Monday, 26 August, 2024 8:39 PM
> To: 'groff@gnu.org'
> > From: G. Branden Robinson
Aagh ... from me, not Branden. One of these days I’ll figure
this out.
Something obvious I overlooked: for a command with long options,
there’s probably
> From: G. Branden Robinson
> Sent: Monday, 26 August, 2024 5:34 PM
> To: groff@gnu.org
Something obvious I overlooked: for a command with long options,
there’s probably something to be said for distinguishing between
‘--’ and a true em dash (‘——’). Another argument for Branden’s
approach.
> From: G. Branden Robinson
> Sent: Monday, 26 August, 2024 5:34 PM
> Good to hear from you! As the new guy, it's always nice for me when a
> veteran groff maven chimes in.
Veteran, perhaps, because of age, but rusty in recent years ...
> (Veteran groff detractors, not so much. 😅)
>
> [CCing
> From: groff-bounces+jeff_conrad=msn@gnu.org bounces+jeff_conrad=msn@gnu.org> On Behalf Of Dave Kemper
> Sent: Saturday, 24 August, 2024 12:33 PM
> The new logic is this:
>
> .ie '\?\*[.T]\?'\?utf8\?' .char \[em] \[em]\[em]
> .el .char \[em] --
>
Aesthetics
=
should need to resort to this sorta stuff ...
Jeff Conrad
Ingo,
> From: Ingo Schwarze [mailto:schwa...@usta.de]
> Sent: Sunday, February 16, 2020 2:26 PM
Free Software?
--
> Oh. Seeing you ask a question about the formatting of a manual page
> on a public list concerned with free software, i jumped to the conclusion
> that you wanted to pub
> Sent: Saturday, February 15, 2020 8:01 AM
>
> It's non-portable because that other person might use a man(7) formatter
> that doesn't support .am or .pdfbookmark, or not in the same way as groff.
> > What's far more nonstandard ...
> Yes, that is very evil. Never try to be clever in manual pa
Ingo,
> Sent: Friday, February 14, 2020 10:46 AM
> > .am SH
> > .pdfbookmark 1 "\&\\$*"
> > ..
> > .am SS
> > .pdfbookmark 2 "\&\\$*"
> > ..
>
> Just don't do that. Never use low-level roff stuff in manual pages,
> don't even think about it. This makes your manual pages non-portable.
I'm not
g the pdfmark
reference manual); is this just something one does not worry about?
Jeff Conrad
Mike, Damian,
> On Sun, 22 Dec 2019, Mike Bianchi wrote:
> > The .H macro is highly customizable.
> > In particular, the Hs register says:
> On Sunday, December 22, 2019 7:33 AM, Damian McGuckin wrote:
> Tried that. Does not fix it.
>
> If I do
>
> .rm misc@tag
>
> the problem goes
se of HTML output; it's described in the bug report.
Jeff Conrad
> From: groff [mailto:groff-bounces+jeff_conrad=msn@gnu.org] On Behalf
> Of Damian McGuckin
> Sent: Saturday, December 21, 2019 10:03 PM
> When using the 'mm' macros, I try
>
> .H 1
On Thursday, March 28, 2019 3:01 AM, G. Branden Robinson wrote:
> At 2019-03-27T04:34:18+0000, Jeff Conrad wrote:
> > Is there a reason that tty.tmac translates \(bu to \(pc or \(md
> > regardless of the output device or whether \(bu is available?
> >
> > .ie c\[pc] \
&
Is there a reason that tty.tmac translates \(bu to \(pc or \(md
regardless of the output device or whether \(bu is available?
.ie c\[pc] \
. tr \[bu]\[pc]
.el \
. if c\[md] \
.tr \[bu]\[md]
The only thing I can find on this is Ingo's message of 30 November 2015
("bullets render as question
Despite a few minor annoyances, it appears that ‘-Tutf8’ is a viable
option on Windows (at least on Win 10). The biggest annoyance is the
end-of-line hyphen, since it’s not included in the Lucida Console font.
I addressed this by adding the line
hy 24 0 0x002D -- Lucida C
On Tuesday, February 26, 2019 7:53 AM, Eli Zaretskii Wrote:
> you mean, you don't have objdump? Then download Dependency Walker
> from the above URL and use that.
I actually had objdump and Dependency Walker; not sure the last time I
used either. I don’t show MSVCRT.dll with either one. I stil
On Monday, February 25, 2019 7:51 AM, Ralph Corderoy wrote:
Hi Ralph,
> > Would it then make sense to include a devcp1252
>
> I don't have any valid input to that, but to wonder if there's an
> recode(1) or iconv(1) available to you for translating to CP 1252 or
> transliterating to UCS-2BE with
On Monday, February 25, 2019 7:58 AM, Eli Zaretskii wrote:
>
> You can verify the results with a dependency walker:
>
> http://www.dependencywalker.com/
>
> Or, if you have GNU Binutils, you do this:
>
> objdump -x PROGRAM.exe | fgrep "DLL Name:"
>
> where PROGRAM.exe is your test program.
On Monday, February 25, 2019 4:03 AM, Eli Zaretskii:
> The only explanation I could come up with regarding your simple program is
> that VS linked it against static libraries,
I’m sure I’m linking statically.
> In any case, the conclusion remains that UTF-8 console output on Windows is
> unrelia
Monday, February 25, 2019 2:35 AM, Eli Zaretskii wrote:
> > Running something like
> >
> > groff -Tutf8
> >
> > rather than something like
> >
> > groff -Tutf8 | more
> >
> > or
> >
> > groff -Tutf8 >
> >
> > Jeff
>
> Yes, I tried all of the above. The last method ends up with co
On Monday, February 25, 2019 2:09 AM, Eli Zaretskii wrote:
> What exactly do you mean by "directly to the console"?
Running something like
groff -Tutf8
rather than something like
groff -Tutf8 | more
or
groff -Tutf8 >
Jeff
Eli,
On Sunday, February 24, 2019 7:53 AM, Eli Zaretskii wrote:
> It is a known problem with the Windows console: you cannot reliably
> write UTF-8 encoded text to it using the ANSI/Posix emulation
> functions like 'write', 'printf', and their C++ equivalents, and
> expect the correct display, ev
Visual Studio 2015) and feed it Unicode values, the output is what I
> > expect—properly rendered UTF-8.
>
> How did you "feed it Unicode values", exactly? And what was the
> simple program you used?
A listing is worth a thousand words
use practically, I’m going to send the
output to a file or run it through a pager. But there is always the
thought: since this isn’t quite right, what else may go wrong?
I’m running the ezwinports Win32 binary 1.22.3 (the 1.22.4 grotty binary
does the same thing).
Jeff Conrad
On Thursday, February 21, 2019 3:10 AM, G. Branden Robinson wrote:
> At 2019-02-21T10:01:07+0000, Jeff Conrad wrote:
> > The Chicago Manual of Style, 13th ed., says “a single quotation mark,
> > however, should not be used to indicate an accent, because it could be
> > eithe
idea.
In all the excitement here, I created such a device and it works fine.
I run a Windows environment that has some issues with UTF-8, and this
allows reasonable rendering of most characters, including the infamous
use of an en dash for a minus sign because MS apparently didn’t consider
the latter important.
I don’t know if this works with fonts on *nix machines.
Jeff Conrad
f
> its runes that overlap, but it doesn't change ASCII.
ISO 646 “changes” ASCII only in that it removes options. An ISO 646–
compliant encoding would also seem ASCII compliant.
I do agree with Ralph that we’ve spent an awful lot of time on this ...
Jeff Conrad
common use. They just see that man(1) outputs
> "weird quotes."
At some time, what had displayed reasonably suddenly looked abominable.
One day, I got mad as hell and wasn’t going to take it anymore, so I
changed the nterm files to have nroff act as the typewriter it truly
was. We’re talkin’ 30 years ago, so for me, that was the beginning of
the “modern” era.
Jeff Conrad
On Sunday, February 17, 2019 2:30 PM, Bjarni Ingi Gislason wrote:
> The expression "modernize" in this context has a manipulative
> character. Who wants to be against "modernization"!
I think we’ve used “modernise” vs. “traditional” to describe how some of
us thought various output devices ren
On Friday, February 8, 2019 9:38 PM, Jeff Conrad wrote
> I discussed this with Doug Kerr, one of the authors (and the principal
> editor) of X3.4-1967. He assures me that accent grave was coded at
> 0x60; the intent was to provide the *option* to use 0x60 and 0x27 for
> opening
On Friday, February 8, 2019 6:18 AM, Ingo Schwarze wrote
> you seem to be reading too much into various sources,
Quite likely, but perhaps no more so than anyone else. My point was
simply that the distinction between “historical” and “modern” isn’t very
helpful. If indeed X3.4-1967 called for a
On Friday, February 8, 2019, Ingo Schwarze wrote
> > I think "historic" is pretty context dependent. As nearly as I can
> > tell, ASA/ANSI X3.4 has called for 0x60 to encode "accent grave".
>
> Absolutely not:
>
> http://worldpowersystems.com/ARCHIVE/codes/X3.4-1963/page5.JPG
>
> In that sta
On Saturday, February 2, 2019 8:58 AM, Ingo Schwarze wrote
> > I think you're incorrect there. Using ` ' as input
> > has always been a correct way to get single left and right quotes;
> > see CSTR 54 2.1.
>
> You seem to be right about that. In modern roff implementations,
> that appears to be
On Friday, February 1, 2019 3:31 PM, Ingo Schwarze wrote:
> And the correct way to mark up a single-quoted string in low-level
> roff(7) is \(oq...\(cq, with the rendering decided by the output
> device.
I think this gets to the essence of the matter. The character table for
-Tascii should recog
> On Thu, Jan 31 2019 at 02:14:13 PM, Ingo Schwarze
> wrote:
> > i just submitted the following patch to the groff bugtracker:
> >
> > https://savannah.gnu.org/bugs/index.php?55616
> >
> > The (identical) rationale and patch are reproduced below for
> > convenience.
> >
Bertrand Garrigues wrote
Tadziu Hoffmann wrote on Mon, Aug 20, 2018 at 11:22:44PM +0200:
> > I would like to add that I sometimes get the
> > impression that people think that once they use a macro
> > package, raw formatter requests should not be used anymore,
> > as they somehow taint the "purity" of the manuscript.
> >
ork with groff, and that `\c'
> can achieve the desired result.
To be honest, I’d never seen a need to so a file without a final newline
(perhaps some type of data-merge application would qualify), but should
such a need arise, Ralph’s suggestion seems the way to go. Especially
because it actually works.
And the documentation should probably eventually be corrected.
Jeff Conrad
y
for someone who didn’t already know the answer? Perhaps a brief
description of how this works—preferably not just in the soelim man
page—would be helpful.
Jeff Conrad
n/sh' by
searching PATH for the shell.
Sure makes things difficult ...
Jeff Conrad
athname
doesn't exist (in general, this probably makes sense to accommodate
scripts that expect /bin/sh rather than the MKS location).
The possible code above still may not be perfect, but it would arguably
be an improvement--but perhaps the good should not be rejected for the
perfect.
Any thoughts?
Jeff Conrad
100 (all 45 are TrueType). I doubt that much has
changed, but I haven't actually used a newer printer.
I agree with Larry's suggestion. I've only tried methods 1 and 3, but both
seem to work.
Jeff Conrad
___
Groff mailing list
Groff@g
\$3^G4^G \h'-.05m'\c
\s-5\\$3\s0\^\\$4
.\}
.el \{\
\%\&\v'-.3m'\s-4\&\\$1\s0\
\v'+.3m'\h'-.05m'\(f/\c
.if ^G\\$2^G4^G \h'-.05m'\c
\s-4\\$2\s0\
\^\\$3
.\}
..$
It worked well enough, including the diddle for the digit 4 in the
denominator, wit
ing, but I can't see
why there would be a problem.
Jeff Conrad
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
44 matches
Mail list logo
