Re: [PATCH] nextup.3: minor improvements

[G. Branden Robinson]

Hi John,

At 2024-08-09T16:41:11+1000, John Gardner wrote:
> [I wrote:]
> > All of the terminal output devices groff supports lack overstriking
> > support.
> 
> Whoops. I forgot that what I was seeing in less(1) was actually duped

I don't think it was duped.  It was being clever.  There is lots of
cleverness in less(1).  Some of it makes me cringe.

> using an underline effect. On that note, am I right to assume that
> \fI+\fP0 is equally implausible by virtue of terminals diverging
> wildly in their italicisation support? (Underlining, obliquity,
> ignoring the effect outright, etc).

Not equally implausible.  Most terminals one encounters support enough
of what ECMA-48 calls "graphic renditions" that, _generally_, in your
exhibit the '+' and the '0' will appear in visually distinguishable
styles.  But little beyond that can be said: they might be different
colors, the plus sign might be in standout (reverse video) mode, it
might be underlined, and so on.

And a document author, particularly of a man page, does _not_ want to
rely solely on text style changes to communicate meaning.  Such things
go away when people do unspeakable things like copying and pasting
chunks of man pages into email messages, losing all formatting.  As a
rule it's prudent to ensure that your meaning is adequately conveyed
when the text is read aloud.  That's a laudable practice in all writing.

(I assume that Slack and Discord clients support "rich text", and
eagerly convert each word of styled text into 100kiB of CSS-ful HTML
overhead.[1])

> That reminds me (and I'm being dead serious here), if anybody knows
> where a Model 37 can be acquired in 2024, *please* let me know. (I
> spent all arvo yesterday searching… seriously).

I read somewhere recently, possibly on the TUHS or COFF lists, that
Model 33 machines experienced an active and deliberate period of
junking.  And as far as I know Model 37s were not very common outside of
Bell Labs, which partly explains why such devices were known mainly as
"ASR 33"s, a misnomer in multiple respects.[2]  Who needs a Greek box,
anyway?

Good luck.  If you are ever successful I may send you a draft notice
enlisting you in the improvement of groff's hardcopy terminal support.

> Why stop there? Such a conditional could match against a named field
> (and optional value) in an output driver description (DESC) file,
> whether it's recognised by Groff or not. Something like:
> 
> .if T unicode \{
> .if T res > 50 \{
> 
> I mean, if we're gonna extend the syntax to include something this
> niche, we may as well go all the way.

Much of the machinery is already in place for this.

Numeric expressions are already valid conditional expressions, so all
we'd need here is a syntax for interpolating an output device parameter.

As it happens, `\T` is _not_ yet taken.  So I'd write your thought
experiment as follows.

.if '\?\T"unicode"\?'\?1\?' .tm hooray! we've got Unicode!
.if \T'res'>50 .tm output device has good resolution

Except in AT&T troff compatibility mode, switching up delimiters when
nesting them is not necessary, but doing so can be kind to humans.

And yes, there's a story behind all those wacky `\?` things.

---snip---
5.23.1 Operators in Conditionals


In 'if', 'ie', and 'while' requests, in addition to the numeric
expressions described in *note Numeric Expressions::, several Boolean
operators are available; the members of this expanded class are termed
"conditional expressions".
[...]
   If the first argument to an 'if', 'ie', or 'while' request begins
with a non-alphanumeric character apart from '!' (see below), it
performs an output comparison test.  (2) (*note Operators in
Conditionals-Footnote-2::)

'XXX'YYY'
 True if formatting the comparands XXX and YYY produces the same
 output commands.  The delimiter need not be a neutral apostrophe:
 the output comparison operator accepts the same delimiters as most
 escape sequences; see *note Delimiters::.  This "output comparison
 operator" formats XXX and YYY in separate scratch buffers; after
 the comparison, the resulting data are discarded.
[...]
 Surround the comparands with '\?' to avoid formatting them; this
 causes them to be compared character by character, as with string
 comparisons in other programming languages.

  .ie "\?|\?"\?\fR|\fP\?" true
  .el false
  => false

 Since GNU 'troff' reads comparands protected with '\?' in copy mode
 (*note Copy Mode::), they need not even be valid 'groff' syntax.
 The escape character is still lexically recognized, however, and
 consumes the next character.

  .ds a \[
  .ds b \[
  .if '\?\*a\?'\?\*b\?' a and b equivalent
  .if '\?\\?'\?\\?' backslashes equivalent
  => a and b equivalent
---end snip---

(Anyone who hates the word "comparand" can blame me.)

I don't know if we'd want to support a `\T[]` syntax as well.  Maybe.

Regards,

Re: vim :hardcopy equivalent

[G. Branden Robinson]

Hi Marcus,

At 2024-07-25T09:59:12+0200, me.gr...@mro.name wrote:
> On Wed, 24 Jul 2024 13:28:04 -0500
> "G. Branden Robinson"  wrote:
> > The subsection/node "Page Location Traps" discusses how to do this
> > and offers a simple example of the setup and use of header and
> > footer traps.
> 
> frankly I am usually hesitant to engage with traps, but your nudge
> encouraged me to do so and it turned out quite fruitful. See
> https://mro.name/2024/brief-dina4.roff

I'm glad to hear it!

[...]
> P.S.: I wonder why there's a single word on the page's last line, but
> I can live with that.

It is because you used (line-)breaking requests in your traps without
also using the no-break control character.

.de hd\" page header
.  sp 3
.  tl |Hinterbichlbach den 24. Juli 2024||%/2|
.  sp 1
..
.de ft\" page footer
.  bp \" just a page break to get a bottom margin
..
.wh 0 hd  \" trap at top of the page
.wh -5 ft \" trap at bottom of the page

As I put it recently to Dave Kemper, "[w]ords from a partially collected
line will spurt out like mustard if, inside trap-called macros, one
isn't careful with requests that imply breaks."[1]

I changed them as follows:

$ diff -u brief-dina4{,-gbr}.roff
--- brief-dina4.roff2024-07-25 02:53:52.0 -0500
+++ brief-dina4-gbr.roff2024-08-09 03:12:20.236198546 -0500
@@ -10,12 +10,12 @@
 .ll 17.6c
 .lt 17.6c
 .de hd\" page header
-.  sp 3
+'  sp 3
 .  tl |Hinterbichlbach den 24. Juli 2024||%/2|
-.  sp 1
+'  sp 1
 ..
 .de ft\" page footer
-.  bp \" just a page break to get a bottom margin
+'  bp \" just a page break to get a bottom margin
 ..
 .wh 0 hd  \" trap at top of the page
 .wh -5 ft \" trap at bottom of the page

...and got the following results in output, which I think solves the
problem you observed.

$ nroff -k brief-dina4.roff >| A
$ nroff -k brief-dina4-gbr.roff >| B
$ diff -u [AB]
--- A   2024-08-09 03:13:07.324051316 -0500
+++ B   2024-08-09 03:13:11.428038486 -0500
@@ -59,7 +59,7 @@
 
Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse
molestie consequat, vel illum dolore eu feugiat nulla facilisis at
-   vero
+
 
 
 
@@ -69,9 +69,9 @@
 
Hinterbichlbach den 24. Juli 2024 2/2
 
-   eros et accumsan et iusto odio dignissim qui blandit praesent lupta‐
-   tum zzril delenit augue duis dolore ‐e feugait nulla facilisi. Lorem
-   ipsum dolor sit amet,
+   vero eros et accumsan et iusto odio dignissim qui blandit praesent
+   luptatum zzril delenit augue duis dolore ‐e feugait nulla facilisi.
+   Lorem ipsum dolor sit amet,
 
Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam
nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam
@@ -125,7 +125,7 @@
Lorem ipsum dolor sit amet,
 
Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse
-   molestie
+
 
 
 
@@ -135,10 +135,10 @@
 
Hinterbichlbach den 24. Juli 2024 3/2
 
-   consequat, vel illum dolore eu feugiat nulla facilisis at vero eros
-   et accumsan et iusto odio dignissim qui blandit praesent luptatum
-   zzril delenit augue duis dolore ‐e feugait nulla facilisi. Lorem ip‐
-   sum dolor sit amet,
+   molestie consequat, vel illum dolore eu feugiat nulla facilisis at
+   vero eros et accumsan et iusto odio dignissim qui blandit praesent
+   luptatum zzril delenit augue duis dolore ‐e feugait nulla facilisi.
+   Lorem ipsum dolor sit amet,
 
Viele Grüße, Euer
Mustermax

Regards,
Branden

[1] https://savannah.gnu.org/bugs/?63176


signature.asc
Description: PGP signature

Re: hyphenating non-english characters

[G. Branden Robinson]

Hi Gáspár,

At 2024-08-01T10:23:31+0200, Gáspár Gergő wrote:
> Thank you for your thorough answer!

My pleasure!

> > The good news is that if you convert the hyphenation pattern file to
> > ISO Latin-2 (ISO 8859-2), you should be able to use it.
> 
> Unfortunately, I got stuck at this point, as the hyphenation file that
> I used is encoded in latin1. Sorry for not including it, this is the
> place I got the file from:
> https://ctan.org/tex-archive/language/hungarian/hyphenation

Werner Lemberg has been a major contributor to (and formerly was
maintainer of) groff, so I urge you to consider his advice.

WL> These patterns are very outdated.  The current version of the
WL> patterns (which is a file larger than a whopping 500kByte) is part
WL> of the 'tex-hyphen' bundle and can be found, among other places, in
WL> the TeXLive git repository at
WL> 
WL>   
https://git.texlive.info/texlive/tree/Master/texmf-dist/tex/generic/hyph-utf8/patterns/tex/hyph-hu.tex
WL> 
WL> > Another weird thing is, while it does contain the á,é,í,ó,ö and ü
WL> > characters, it omits the ő and ű characters entirely.
WL> 
WL> The abovementioned file is encoded in UTF-8, which you have to
WL> convert to Latin2 by doing, for example,
WL> 
WL> ```
WL> iconv -f utf8 -t latin2 < hyph-hu.tex > hyph-hu.latin2.tex
WL> ```

> I am using groff 1.23.0.  This encoding business is out of my depth,
> so sorry if I'm missing something obvious.

If you have any experienced at cloning Git repositories and compiling
software packages from source, I would encourage you to try groff Git
HEAD, which has seen subtle but significant improvements to hyphenation
support in just the past couple of weeks.

As the groff home page[1] says:

"To participate in groff development, clone its Git repository. Read the
INSTALL.extra and INSTALL.REPO files within for build requirements and
instructions."

Importantly, you should no longer need to mess with defining hyphenation
codes at all; that is now done by the existing "latin2.tmac" file, and
Hungarian, to my knowledge, doesn't need to alter any case mappings as
Turkish does (and which uses yet another encoding file anyway).

If you can get the "hyph-hu.tex" file working after converting it to ISO
Latin-2, then with a little translation help from you (or others fluent
in Hungarian), we could add "hyphen.hu" and "hu.tmac" files to groff.
I'd be pleased to get those into place for groff 1.24, which I hope to
release later this year.

Regards,
Branden

[1] https://www.gnu.org/software/groff/


signature.asc
Description: PGP signature

Re: [PATCH] nextup.3: minor improvements

[Vincent Lefevre]

On 2024-08-09 15:53:30 +1000, John Gardner wrote:
> Hi Vincent,
> 
> > So ideally, the fallback for "±0" should be "+0 or -0", which is
> > much more readable and less ambiguous than "+-0" or "+/-0".
> 
> For approximating ± in ASCII, is there some reason \z_+0 hasn't been
> considered?

I don't like that at all. I really see a "+" underlined, so it is
confusing. Moreover, the information is not kept by copy-paste,
and it is not rendered as wanted with "xterm +ulc" (to replace
underline by color). And I don't think that it will correctly be
interpreted by screen readers.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

a bilingual English/French groff document (was: an observation and proposal about hyphenation codes)

[G. Branden Robinson]

Hi Sigfrid,

At 2024-08-07T10:30:59+0200, Sigfrid Lundberg wrote:
> I have strong feelings when it comes to multilinguality. A background:
> I have a pre-retirement background in giving support to research in
> arts and humanities. Occasionally I have had the opportunity to use
> groff for that.  The PDF catalogue of St Laurentius Digital Manuscript
> library is an example of that. See
> 
> https://github.com/siglun/laurentius/blob/main/catalogue/catalogue.pdf
> 
> It is written in English, but contains implicits, explicits, rubrics
> etc in perhaps a half dozen languages (.hy), each of which could
> benefit from its own hyphenation mode (.hla). The Greek in this
> catalogue is medieval, not modern
> 
> https://github.com/siglun/laurentius/blob/main/catalogue/Mh_54.pdf
> 
> which on its own was exercise. I'm not sure but I believe I used
> English hyphenation throughout the  text, which is mostly in English,
> Latin and Danish.

Well, since groff has no hyphenation pattern files for Danish or Latin,
this is probably the best that can be done, unless you wanted to disable
hyphenation entirely for those two languages.

I am attaching an example of a bilingual English and French groff
document to illustrate how one might undertake such a thing.

> To me, Scientific type-setting and multilinguality is the raison
> d'etre for groff and its competitors.

I'm very happy to hear that you have found groff satisfactory for your
purposes to date.  Please let us know of any ideas you have for its
improvement.

> I'm a groff user (groff@gnu.org subscriber) since 1989 when I failed
> to install TeX on my workstation.

Not an uncommon experience, I think--apparently installing TeX used to
be so notoriously difficult that O'Reilly found it profitable to publish
a book on TeX, much of the page count of which was given over to helping
the reader actually get the system installed.

I remember when distributions like TeX Live came along and were very
warmly received for finally solving a problem that Knuth didn't find
interesting.  (Not that I blame him.  His talents are better applied to
producing as much TAOCP as possible before God calls him home.)

Regards,
Branden
.\" groff -K utf8
.ll 60n \" a line length that provokes hyphenation in both sample texts
.
.\" Set up environments for English and French.
.ev english
.evc 0
.ev
.
.ev french
.evc 0
.ev
.
.\" Set up macros to switch between them.
.de EN
.ev english
.mso en.tmac
..
.de FR
.ev french
.mso fr.tmac
..
.EN
France,
less favoured on the whole as to matters spiritual than her sister of
the shield and trident,
rolled with exceeding smoothness down hill,
making paper money and spending it.
.
Under the guidance of her Christian pastors,
she entertained herself,
besides,
with such humane achievements as sentencing a youth to have his hands
cut off,
his tongue torn out with pincers,
and his body burned alive,
because he had not kneeled down in the rain to do honour to a dirty
procession of monks which passed within his view,
at a distance of some fifty or sixty yards.
.
It is likely enough that,
rooted in the woods of France and Norway,
there were growing trees,
when that sufferer was put to death,
already marked by the Woodman,
Fate,
to come down and be sawn into boards,
to make a certain movable framework with a sack and a knife in it,
terrible in history.
.
It is likely enough that in the rough outhouses of some tillers of the
heavy lands adjacent to Paris,
there were sheltered from the weather that very day,
rude carts,
bespattered with rustic mire,
snuffed about by pigs,
and roosted in by poultry,
which the Farmer,
Death,
had already set apart to be his tumbrils of the Revolution.
.
But that Woodman and that Farmer,
though they work unceasingly,
work silently,
and no one heard them as they went about with muffled tread:
the rather,
forasmuch as to entertain any suspicion that they were awake,
was to be atheistical and traitorous.
.sp
.FR
La révolution survint,
les événements se précipitèrent,
les familles parlementaires décimées,
chassées,
traquées,
se dispersèrent.
.
M.\& Charles Myriel,
dès les premiers jours de la révolution,
émigra en Italie.
.
Sa femme y mourut d’une maladie de poitrine dont elle était atteinte
depuis longtemps.
.
Ils n’avaient point d’enfants.
.
Que se passa-t-il ensuite dans la destinée de M.\& Myriel\~?
.
L’écroulement de l’ancienne société française,
la chute de sa propre famille,
les tragiques spectacles de 93,
plus effrayants encore peut-être pour les émigrés qui les voyaient de
loin avec le grossissement de l’épouvante,
firent-ils germer en lui des idées de renoncement et de solitude\~?
.
Fut-il,
au milieu d’une de ces distractions et de ces affections qui occupaient
sa vie,
subitement atteint d’un de ces coups mystérieux et terribles qui
viennent quelquefois renverser,
en le frappant au cœur,
l’homme que les catastrophes publiques n’ébranleraient pas en le
frappant dans son existence et dans sa fortune\~?
.
Nul n’aurait pu le dire\~;
tout

Re: [PATCH] nextup.3: minor improvements

[John Gardner]

Hi Branden,

Numeric expressions are already valid conditional expressions, so all we'd
> need here is a syntax for interpolating an output device parameter. […] As
> it happens, `\T` is *not* yet taken.


True, but for fields that have lengthy values, it might help to have a
syntax for testing the presence (or absence) of a space-delimited token:

.ie T styles & BI \{ This device supports \f(BIbold-italic\fP text! \}
.el   \{ "BI" not listed in the DESC file's "styles" field. \}

However, I see the greater flexibility of an escape sequence that can be
utilised anywhere, not just in conditional expressions. Its output can
always be passed to a list-wrangling macro or something.

And yes, there's a story behind all those wacky `\?` things.


Wait, how long has that been supported\? (I've been away from Groff for the
past year-and-a-half, so apologies if this was a very recent addition).

And a document author, particularly of a man page, does *not* want to rely
> solely on text style changes to communicate meaning.


You're right. Hell, I believe I've made this exact same point in the past
when discussing A11Y, SEO,[1] and legible .textContent
 properties.

As a rule it's prudent to ensure that your meaning is adequately conveyed
> when the text is read aloud. That's a laudable practice in all writing.


True, but there are other, more cumbersome examples where author intent
must be communicated textually. Docopt  is probably my
favourite example of this.

Good luck. If you are ever successful I may send you a draft notice
> enlisting you in the improvement of Groff's hardcopy terminal support.


Thanks! I'm not hedging my bets, though, so in the meantime you can hit up this
guy  who somehow got an ASR-33 talking to
Linux and even Twitter's API .[2]

Email is for old men attempting to thwart all progress.


Or 37-year old hermits with ADHD who avoid instant messaging apps or social
media in favour of a digital medium most familiar to them.[3]

Also, the *real* old men who're attempting to thwart all progress are the
CEOs of Big Tech companies who keep shoving AI down our throats,
irrespective of whether we asked for it or not.[4] Because line must go up
.


(I assume that Slack and Discord clients support "rich text", and eagerly
> convert each word of styled text into 100kiB of CSS-ful HTML overhead)


Christ, I hear ya. You'd think a text-based medium like the Web would have
some efficient means of encoding textual content in a form separate from
presentational rules, in both a readable and approachable text format.
Shame that we now require Markdown processors to generate the HTML that's
piped through to the middleware that's rendered client-side in the user's
browser after loading 4.5 MBs of CDN-hosted fonts that only marginally
differ from system-installed typefaces, displayed after 10 MBs of
unoptimised Webpack chunks are loaded by the browser. I mean, what the hell
was Tim Berners-Lee thinking?

[1] Search Enshittification Operation, or the cancer that's eroded the
usefulness of search engines in recent years.
[2] Before it was ruined by Elon's BIG BRAIN™ decision to paywall the
site's API, effectively defeating its intended purpose to make Twitter
accessible to the broader web.
[3] The main advantage of the latter being that I can proof-read my
dexie-fuelled ramblings before making them public. So there's really no
excuse for this e-mail.
[4] Thank you, late-stage Capitalism, for returning us—the working class—to
serfdom. I'm sure the elites work very, very hard and aren't at all
leeching off of an inherently unsustainable system built upon exploitation
of labour.

^D

Re: [PATCH] nextup.3: minor improvements

[John Gardner]

Hi Vincent,

I really see a "+" underlined


Is it visually distinct from an ordinary underscore? I merely ask now out
of curiosity, as Brandan explained why overstriking is a no-go.

Concerning the original problem, I find myself in agreement with the
general majority here: consistency with the existing *"+0 or -0"* language
is probably the best fallback.

Regards,
— John

On Fri, 9 Aug 2024 at 19:25, Vincent Lefevre  wrote:

> On 2024-08-09 15:53:30 +1000, John Gardner wrote:
> > Hi Vincent,
> >
> > > So ideally, the fallback for "ą0" should be "+0 or -0", which is
> > > much more readable and less ambiguous than "+-0" or "+/-0".
> >
> > For approximating ą in ASCII, is there some reason \z_+0 hasn't been
> > considered?
>
> I don't like that at all. I really see a "+" underlined, so it is
> confusing. Moreover, the information is not kept by copy-paste,
> and it is not rendered as wanted with "xterm +ulc" (to replace
> underline by color). And I don't think that it will correctly be
> interpreted by screen readers.
>
> --
> Vincent Lefčvre  - Web: 
> 100% accessible validated (X)HTML - Blog: 
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
>

Re: [PATCH] nextup.3: minor improvements

[G. Branden Robinson]

Hi John,

...butting in on your dialogue with Vincent again...

At 2024-08-09T19:38:48+1000, John Gardner wrote:
>> I really see a "+" underlined
> 
> Is it visually distinct from an ordinary underscore? I merely ask now
> out of curiosity, as Brandan explained why overstriking is a no-go.

If the terminal device has sufficient vertical resolution and can be
bothered, yes.  gnome-terminal does at its default font size, at least
for me.  With xterm, using Xft fonts, I have to jack the type size up to
somewhere between 24 and 36 inclusive before they are distinguishable.

And that's not taking into account the possibility of baseline rule and
underrule (cf. under_score_) glyphs, which are things that exist in AT&T
and GNU troffs.  Neither has a Unicode code point, though, so I wouldn't
hold my breath for support in terminal emulators.

Regards,
Branden


signature.asc
Description: PGP signature

Re: [PATCH] nextup.3: minor improvements

[G. Branden Robinson]

Hi John,

At 2024-08-09T19:35:21+1000, John Gardner wrote:
> > Numeric expressions are already valid conditional expressions, so
> > all we'd need here is a syntax for interpolating an output device
> > parameter. […] As it happens, `\T` is *not* yet taken.
> 
> 
> True, but for fields that have lengthy values, it might help to have a
> syntax for testing the presence (or absence) of a space-delimited
> token:
> 
> .ie T styles & BI \{ This device supports \f(BIbold-italic\fP text! \}
> .el   \{ "BI" not listed in the DESC file's "styles" field. \}

I don't have a proof, but I think we're boxed in syntactically by AT&T
troff (or even nroff) design decisions here.  We can't use spaces as you
want because otherwise the formatter doesn't know where the conditional
expression ends and its consequent (the "then" of the branch) begins.

---snip---
   The above operators can't be combined with most others, but a leading
'!', not followed immediately by spaces or tabs, complements an
expression.

 .nr x 1
 .ie !r x register x is not defined
 .el  register x is defined
 => register x is defined

   Spaces and tabs are optional immediately after the 'c', 'd', 'F',
'm', 'r', and 'S' operators, but right after '!', they end the predicate
and the conditional evaluates true.(5)  (*note Operators in
Conditionals-Footnote-5::)
[...]
   (5) This bizarre behavior maintains compatibility with AT&T 'troff'.
---end snip---

> Wait, how long has that been supported\? (I've been away from Groff
> for the past year-and-a-half, so apologies if this was a very recent
> addition).

^351da0dcd troff/input.c(James Clark 1991-06-02 04:20:34 
-0500 1223) case '?':
587bd704da src/roff/troff/input.cpp (G. Branden Robinson 2024-07-13 12:35:49 
-0500 1224)   (void) input_stack::get(0);
^351da0dcd troff/input.c(James Clark 1991-06-02 04:20:34 
-0500 1225)   return ESCAPE_QUESTION;

> True, but there are other, more cumbersome examples where author intent
> must be communicated textually.

"Typographically", I would say.

> Docopt  is probably my favourite example of this.

Mmm, SSL certificate security alert.

Looks like yet another spawn of Markdown.

Meaning yet another inversion of one of the Zens of Python:

"Implicit is better than explicit."

Color me unenthused.  Also old and opposed to all progress.  ;-)

> Thanks! I'm not hedging my bets, though, so in the meantime you can
> hit up this guy  who somehow got an
> ASR-33 talking to Linux and even Twitter's API
> .[2]

I've seen that one.  Another thing to know is that apparently those
Teletype machines weighed on the order of a few hundred pounds^W^Wa
couple of hundred kilograms.

> Also, the *real* old men who're attempting to thwart all progress are
> the CEOs of Big Tech companies who keep shoving AI down our throats,
> irrespective of whether we asked for it or not.[4] Because line must
> go up .

Workers of the world unite and seize the means of production!  Thank you
for coming to my KARLTalk.

> Christ, I hear ya. You'd think a text-based medium like the Web would
> have some efficient means of encoding textual content in a form
> separate from presentational rules, in both a readable and
> approachable text format.  Shame that we now require Markdown
> processors to generate the HTML that's piped through to the middleware
> that's rendered client-side in the user's browser after loading 4.5
> MBs of CDN-hosted fonts that only marginally differ from
> system-installed typefaces, displayed after 10 MBs of unoptimised
> Webpack chunks are loaded by the browser. I mean, what the hell was
> Tim Berners-Lee thinking?

"Being first is better than being best."

> [1] Search Enshittification Operation, or the cancer that's eroded the
> usefulness of search engines in recent years.

Google lost their search monopoly case in the United States; I'll be
interested to see if the Supreme Court overturns that or if the next
administration has the stones to impose divestiture.

> [2] Before it was ruined by Elon's BIG BRAIN™ decision to paywall the
> site's API, effectively defeating its intended purpose to make Twitter
> accessible to the broader web.

Wealth equals genius.  That's why so many people are born smarter than
Stephen Hawking or Kenneth Arrow or C. F. Gauss.

> [3] The main advantage of the latter being that I can proof-read my
> dexie-fuelled ramblings before making them public. So there's really
> no excuse for this e-mail.

I like being reminded of the diverse population of humans behind the
monikers we see on the discussion list.

> [4] Thank you, late-stage Capitalism, for returning us—the working
> class—to serfdom.

I'd say we never really left.

> I'm sure the elites work very, very hard and aren't at all leeching
> off of an inherently unsustainable system built

Re: [PATCH] nextup.3: minor improvements

[Vincent Lefevre]

On 2024-08-09 19:38:48 +1000, John Gardner wrote:
> Hi Vincent,
> 
> > I really see a "+" underlined
> 
> Is it visually distinct from an ordinary underscore? I merely ask now out
> of curiosity, as Brandan explained why overstriking is a no-go.

The underline bar is slightly different from an underscore, but
this is not the issue. What matters is that the underlined "+"
is very different from the ± character: in this ± character,
the "+" part and the "-" part have the same width, but in the
underlined "+", the underline bar is larger than the "+";
moreover, the underline bar is below the baseline.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)