[self-follow-up]
At 2024-04-18T16:52:49-0500, G. Branden Robinson wrote:
> I vaguely recollect that this was solved by putting UARTs with
> (bigger) buffers on the motherboard.
...or on a third-party serial card...
> And then made more of its own. Hitching their wagon to UTF-16 for
> character
On Fri, 12 Apr 2024 01:27:54 -0500
"G. Branden Robinson" wrote:
> Yes, I reckon trapping into the kernel for every byte (or pair of
> bytes) written to the screen would indeed have eaten all your
> performance, and been pointless when there was no access protection in
> any part of the address
At 2024-04-12T01:27:58-0500, G. Branden Robinson wrote:
> Why not use one register for the character and one for the attributes?
Please disregard that sentence. What I was trying to say was, "why not
use one (16-bit) register for the text and attributes instead of the
lower 8-bit halves of 2
On Fri, 22 Mar 2024 22:12:05 -0500
"G. Branden Robinson" wrote:
> However, if the user told CONFIG.SYS to load ANSI.SYS,
> it would, because that module interposed itself before the BIOS call
> that talked to the display, and interpreted them, driving the
> CGA/EGA/VGA hardware appropriately.
At 2024-03-28T05:28:46-0500, Dave Kemper wrote:
> On Sat, Mar 23, 2024 at 1:29 PM G. Branden Robinson
> wrote:
> > (I've been slowly accumulating evidence that, for basic editing
> > operations, vi _really is_ more keystroke-efficient than Emacs,
>
> Not just in requiring fewer keystrokes, but
On Sat, Mar 23, 2024 at 1:29 PM G. Branden Robinson
wrote:
> (I've been slowly accumulating evidence that, for basic editing
> operations, vi _really is_ more keystroke-efficient than Emacs,
Not just in requiring fewer keystrokes, but in the ergonomics of them
too: (1) It requires fewer key
> (I use a bitmap font because it's substantially more readable
> for long periods of time than any TrueType font I've found at
> equivalent sizes, but using a bitmap font disables some of
> xterm's font family support.)
The xterm source can be hacked to provide italics using the
classic bitmap
On Sun, Mar 24, 2024, Steve Izma wrote:
> Do you remember what the costs of the Linotronic machines would
> have been?
IIRC, the 202 cost between $40,000 and $60,00 at the end of the
eighties. The 300 series ran about $60,000.
--
Peter Schaffter
https://www.schaffter.ca
"G. Branden Robinson" writes:
> It sounds like the way is clear to change perldoc's default back to
> Pod::Man plus nroff. ;-)
See https://github.com/briandfoy/pod-perldoc/pull/36. It looks like it's
being worked on, but there's apparently some complexity downstream of both
of us in figuring
On Sun, Mar 24, 2024 at 03:39:45PM -0400, Peter Schaffter wrote:
> Subject: Re: the Courier font family and nroff history
>
> On Sat, Mar 23, 2024, Steve Izma wrote:
> > I tend to believe that Linotype was the driving force in the
> > release of a complete package for
On Sat, Mar 23, 2024, Steve Izma wrote:
> I tend to believe that Linotype was the driving force in the
> release of a complete package for corporate typesetters: the
> Linotronic 202 (or something like it) driven by Adobe's new
> PostScript rasterizer (RIP), using ITC fonts, and with two
> choices
On Sat, Mar 23, 2024 at 07:13:38PM -0400, James Cloos wrote:
> Subject: Re: the Courier font family and nroff history
>
> So blame Jobs for Courier as the monospace family and for
> Times(12) as the serif family. And for Helvetica as the Sans
> family.
I think we need to rem
> "GB" == G Branden Robinson writes:
GR> I don't think Adobe standardized it
GR> for PostScript (and then PDF) for the _sole_ purpose of simulating
GR> terminal emulator, or even typewriter, output.
As I recall, it has frequently been posted over the years that the
selection of fonts which
> [looping the groff list back in]
Again I got my wires crossed. Thanks.
> Do you happen to remember _when_ the CSRC got its 4014? About what
> year? Did Joe Ossanna have access to one early enough to use it in aid
> of troff development?
I think it was about the time of v6, well after the
At 2024-03-22T21:37:51-0700, Russ Allbery wrote:
> "G. Branden Robinson" writes:
>
> > Okay...by this time groff had for about 10 years been producing
> > device-independent _terminal_ output from troff(1). On the other,
> > that is its own peculiar little language. Maybe the author just
> >
[looping the groff list back in]
At 2024-03-23T11:37:51-0400, Douglas McIlroy wrote:
> > "BI" fonts can, it seems, largely be traced to the impact
> > of PostScript
>
> There was no room for BI on the C/A/T. It appeared in
> troff upon the taming of the Linotron 202, just after v7
> and five
"G. Branden Robinson" writes:
> Okay...by this time groff had for about 10 years been producing
> device-independent _terminal_ output from troff(1). On the other, that
> is its own peculiar little language. Maybe the author just didn't want
> to deal with *roff, or didn't want to count on GNU
At 2024-03-22T22:12:08-0500, G. Branden Robinson wrote:
> (Kernighan didn't completely unify terminals under the
> device-independent troff scheme presented in CSTR #54
CSTR #97
> --nevertheless its "driving tables" for terminal devices bore a
> startling resemblance to "DESC" files for
At 2024-03-22T17:06:40-0700, Russ Allbery wrote:
> "G. Branden Robinson" writes:
>
> > That's a good argument against grotty(1) emitting overstriking
> > sequences, at least by default, and yet that the people swiftest to
> > anger on this subject argue _for_ it.
>
> I'm not fully following
On Fri, Mar 22, 2024 at 7:07 PM Russ Allbery wrote:
>
> The stated reason was that the output was device-independent, unlike
> output that embeds formatting codes derived from device-specific termcap
> entries, and they really liked the bold and underlining rather than the
> plain text or *ad
"G. Branden Robinson" writes:
> That's a good argument against grotty(1) emitting overstriking
> sequences, at least by default, and yet that the people swiftest to
> anger on this subject argue _for_ it.
I'm not fully following this argument, but (assuming I've not completely
lost the train of
Quoth G. Branden Robinson:
At 2024-03-19T19:59:58+, Lennart Jablonka wrote:
Right. We can emulate the nonsense typewriter /emulators/ do. I do
think that we shouldn’t do that, either.
I would not describe character-cell video terminals as "typewriter
emulators" precisely because they
[self-correction]
At 2024-03-22T13:24:04-0500, G. Branden Robinson wrote:
> and video terminals emulated typewriters well enough for unserious
> work like formatting man pages on a screen.
Err, this is pretty hugely false.
They didn't.
That's why you had to pipe nroff's output through col(1)
At 2024-03-19T18:28:13+, Lennart Jablonka wrote:
> Quoth G. Branden Robinson:
> > > And the page numbers reset at the start of each section. Which
> > > they shouldn’t do—the book is one unit; it should get its own page
> > > numbers. And in other books, you don’t usually see page numbers
>
24 matches
Mail list logo
