Haters of official Microsoft Office font Calibri finally have their
wish – the infuriatingly 11-point default typeface has been chucked
to the bin in favor of Aptos, the new official font to be used in all
the Microsoft Office apps.…
I liked Calibri, but I never understood why the default size was 11
instead of 12. I liked Times New Roman too. It's all good.
2023-07-15, Visiblink <visiblink@mail.invalid> schrieb:
[Calibri-schnipp]
I liked Calibri, but I never understood why the default size was 11
instead of 12. I liked Times New Roman too. It's all good.
It depends probably on your eyesight, but I prefer 11pt, 12 is
slightly to big for me.
Haters of official Microsoft Office font Calibri
finally have their wish the infuriatingly
11-point default typeface has been chucked to the
bin in favor of Aptos
In any program I use intensively, including e-mail
and Usenet clients, text editors, IDEs, document
processors, and word processors, most of the de-
faults are redefined to what suits my needs and my
easthetics. The defaults are a minor nuance, only
annoying when a feature is "on" by default rather
then "off", throwing in your face tons of function-
ality you never asked for. The correct approach is
the opposite: turn all bells and whistles off and
let the user feel what they are missing, and encour-
ange them to explore the settings and documentation
in search of it.
The very fact that default settings have so
tremen dous an impact shows how lazy and care-
less they are. In any program I use intensive-
ly, including e-mail and Usenet clients, text
editors, IDEs, document processors, and word
processors, most of the defaults are redefined
to what suits my needs and my easthetics. The
defaults are a minor nuance, only annoying when
a feature is "on" by default rather then "off",
throwing in your face tons of function ality you
never asked for. The correct approach is the op-
posite: turn all bells and whistles off and let
the user feel what they are missing, and encour-
ange them to explore the settings and documenta-
tion in search of it.
So you're saying you *intentionally* enabled this
obnoxious text justification in your post? Differ-
ent strokes, I guess.
John to Anton Shepelev:
The very fact that default settings have so tremen dous an impact shows how lazy and care- less they are. In any program I use intensive- ly, including e-mail and Usenet clients, text editors, IDEs, document processors, and word processors, most of the
defaults are redefined to what suits my needs and my easthetics.
The defaults are a minor nuance, only annoying when a feature is
"on" by default rather then "off", throwing in your face tons of
function ality you never asked for. The correct approach is the op- posite: turn all bells and whistles off and let the user feel what
they are missing, and encour- ange them to explore the settings and documenta- tion in search of it.
So you're saying you *intentionally* enabled this obnoxious text justification in your post? Differ- ent strokes, I guess.
No, I am not saying that. But my beautiful justifi- cation is
intentional. It is standard in the better plain-text documents, e.g.:
MODULA: a language for modular multiprogramming <https://www.research-collection.ethz.ch/bitstream/handle/20.500.11850/68669/eth-3057-01.pdf>
But my beautiful justifi- cation is intentional.
Beautiful justification?It isn't beautiful on ~my~ Usenet.
Another nit-pick: you posted an undelimited URL, now
corrected.
Sn!pe
But my beautiful justifi- cation is intentional.
Beautiful justification?It isn't beautiful on ~my~ Usenet.
You Usenset reader? MacSOUP? I conjecture it is not, by
default, displaying posts in a monospace font, which it
sould. Hard-wrapped plain-text -- whether justified or
not -- is medium for character-cell devices.
Another nit-pick: you posted an undelimited URL, now
corrected.
Oh, I never do it for aesthetical reasons. Whenever I wish
to follow a URL, I manually copy it and paste into the
browser. It is safer, I think.
http://www.example.url.com <~~[broken]
<http://www.example.url.com> <~~[works]
Anton Shepelev:
Sn!pe:
Anton Shepelev:
But my beautiful justification is intentional.
Beautiful justification?It isn't beautiful on ~my~
Usenet.
You Usenset reader? MacSOUP? I conjecture it is not, by
default, displaying posts in a monospace font, which it
sould. Hard-wrapped plain-text -- whether justified or
not -- is medium for character-cell devices.
I disagree.
You're misquoting too, see above.
Another nit-pick: you posted an undelimited URL, now
corrected.
Oh, I never do it for aesthetical reasons. Whenever I
wish to follow a URL, I manually copy it and paste into
the browser. It is safer, I think.
Nonsense. Whatever, delimiting is in the RFCs.
Sn!pe:
Another nit-pick: you posted an undelimited URL,
now corrected.
Oh, I never do it for aesthetical reasons. Whenever I
wish to follow a URL, I manually copy it and paste into
the browser. It is safer, I think.
Nonsense. Whatever, delimiting is in the RFCs.
The fact that the delimiter is specified in an RFC does not
render nonsencial my reasons of not following it. I did not
know, however, about an RFC for URL delimiters, nor can I
find one right now. Which RFC is it?
Now that I have enclosed an URI in <> I see that it has
become harder to select and copy. <~~ [unnecessary step]
Sn!pe:
Anton Shepelev:
Sn!pe:
Anton Shepelev:
But my beautiful justification is intentional.
Beautiful justification?It isn't beautiful on ~my~ Usenet.
You Usenset reader? MacSOUP? I conjecture it is not, by default,
displaying posts in a monospace font, which it sould.
Hard-wrapped plain-text -- whether justified or not -- is medium
for character-cell devices.
I disagree.
I defend my point with the two arguments:
1. Hard-wrapping splits lines based on their length in
characters, whereas with a proportional font line length
cannot be measured by character count.
Anton Shepelev <anton.txt@g{oogle}mail.com> wrote:
Sn!pe:
Anton Shepelev:
Sn!pe:
Anton Shepelev:
But my beautiful justification is intentional.
Beautiful justification?It isn't beautiful on ~my~ Usenet.
You Usenset reader? MacSOUP? I conjecture it is not, by default,
displaying posts in a monospace font, which it sould.
Hard-wrapped plain-text -- whether justified or not -- is medium
for character-cell devices.
I disagree.
I defend my point with the two arguments:
1. Hard-wrapping splits lines based on their length in
characters, whereas with a proportional font line length
cannot be measured by character count.
I suspect that Sn!pe's complaint is not the hard-wrap (my own reply
here is also hard wrapped), but instead is about the even right
justification by additional full space insertion plus the
auto-hyphenation. Those two, in a mono-space context, make for
severely ugly wordwrap.
Now that I have enclosed an URI in <> I see that it has
become harder to select and copy. <~~ [unnecessary step]
Why make work for yourself when you can simply click a URL?
I note that you have silently discarded my comments about
Thunderbird's faulty quoting.
RFC 1738 (and others)
I suspect that Sn!pe's complaint is not the hard-wrap (my
own reply here is also hard wrapped), but instead is about
the even right justification by additional full space
insertion plus the auto-hyphenation. Those two, in a
mono-space context, make for severely ugly wordwrap.
Consider the case of Thunderbird, which has the bad habit of omitting
a space between the quote chevrons and the quoted text. If the text
quoted is an undelimited URL, it will be broken (non-clickable)
Examples below:-
http://www.example.url.com <~~[original]
becomes (when quoted by Thunderbird):-
http://www.example.url.com <~~[broken]
If it were delimited it becomes, when quoted:-
<http://www.example.url.com> <~~[works]
Sn!pe to Anton Shepelev:
Now that I have enclosed an URI in <> I see that it has
become harder to select and copy. <~~ [unnecessary step]
Why make work for yourself when you can simply click a URL?
Since Usenet predates web, clients need not be aware of URLs
to such a degree as to make them clickable (presumably to
open them in the default browser). I don't think such
newsreaders as tin, trn, or slrn recognise URLs at all.
Rich:
I suspect that Sn!pe's complaint is not the hard-wrap (my own reply
here is also hard wrapped), but instead is about the even right
justification by additional full space insertion plus the
auto-hyphenation. Those two, in a mono-space context, make for
severely ugly wordwrap.
Did you mean /non/-monospace context, wherein this format is indeed
horrible?
The very fact that default settings have so tremen-
dous an impact shows how lazy and careless they are.
In any program I use intensively, including e-mail
and Usenet clients, text editors, IDEs, document
processors, and word processors, most of the de-
faults are redefined to what suits my needs and my
easthetics. The defaults are a minor nuance, only
annoying when a feature is "on" by default rather
then "off", throwing in your face tons of function-
Sn!pe <snipeco.2@gmail.com> wrote:
Consider the case of Thunderbird, which has the bad habit of omitting
a space between the quote chevrons and the quoted text. If the text
quoted is an undelimited URL, it will be broken (non-clickable)
Examples below:-
http://www.example.url.com <~~[original]
becomes (when quoted by Thunderbird):-
http://www.example.url.com <~~[broken]
If it were delimited it becomes, when quoted:-
<http://www.example.url.com> <~~[works]
Who died and made you net.cop? In any case, if your newsreader can't handle a URL within plain text, perhaps you should get a better newsreader. tin
(to name just one example) has no problem with either of the URLs given
above (or below, in my sig).
Bear in mind that Usenet predates the Web by several years. I've been posting here since 1989, and it had already been around for a few years before that.
Sn!pe to Anton Shepelev:
Now that I have enclosed an URI in <> I see that it has
become harder to select and copy. <~~ [unnecessary step]
Why make work for yourself when you can simply click a URL?
Since Usenet predates web, clients need not be aware of URLs
to such a degree as to make them clickable (presumably to
open them in the default browser). I don't think such
newsreaders as tin, trn, or slrn recognise URLs at all.
Yes, copying the URL and inserting it into the browser is
more work than simply clicking on it in the client, but at
the same time it is less dangerous, in that one can click on
a URL by accident.
I note that you have silently discarded my comments about
Thunderbird's faulty quoting.
I have read your example, though, but had nothing to say to
it. One possible suggestion is to fix TB so that it will
detect and parse URLs propertly even when they are at the
beginning of a quoted line. I see no reason why TB should
fail with:
>http://www.example.url.com
Another -- not to rely on this funcionality, as I do,
preferring the freedom of treating the message as uniform
text.
RFC 1738 (and others)
Indeed, but please observe that according the examples in
RFC the major funciton of those delimiters seems to leting
the client pars URLs <https://that.are.split.over.several.
lines>, whereas I myself never ever post such URLs,
preferring rather to exceed the recommended line length
limit of 78 characters. Keep URLs on a single line helps
with both readablity and usability, i.e. copying the entire
URL.
Observe also that the RFC recommends not only to delimit
URLs with <>, but also to preped them with the `URL:'
prefix, which you do not seem to require. I wonder if your
TB will handle <URL:https://fusionanomaly.net/
EssenceNode.html>.
I see that you or your client reflow text, so that my URL may
not appear split across two lines on your side.
Observe thirdly, that according to GNKSA, a newsreader
should preserve line breaks while displaying a message:
Any line breaks shown to the user while she is editing
her article SHOULD still be present when the article is
actually posted to the Net. The software SHOULD NOT show
the user four 75-character lines while actually posting a
single 300-character line. Nor should it show the user a
series of 100-character lines while actually posting
alternating lines of 80 and 20 characters each.
So I hope your TB shows my articles as they are meant to be
viewed.
snipeco.2@gmail.com (Sn!pe) writes:
What about News Message-IDs and References? If properly delimited,
MacSOUP can automatically search its stored articles for a match on
M-IDs.
| group local.test
| 211 1 1 1 local.test
| post
| 340 Ok, recommended Message-ID <ucl...s$1@himalaya6...5id.onion>
Do message IDs ever appear without <...>?
Even digging back to RFC822 they seem to be always defined including
<...> so I wouldn't read that as optionally delimiting them and as
necessary part instead.
--
|rom The Future. +++ Breaking News From The Future. +++ Breaking News F|
| The USoA are switching to the binary number system because |
| having more than 1+1 distinct digits is far too woke. |
|+ #MABA + #makeAmericaBinaryAgain + #USA + #USoA + #woke + #MABA + #ma|
Andy Burns wrote:
Sn!pe wrote:
Examples below:-
http://www.example.url.com <~~[original]
That's me quoting your non-delimited URL in thunderbird
Still looks good to me (though personally I would delimit it)
What about News Message-IDs and References? If properly delimited,
MacSOUP can automatically search its stored articles for a match on
M-IDs.
Examples below:-
http://www.example.url.com <~~[original]
Sn!pe wrote:
Examples below:-
http://www.example.url.com <~~[original]
That's me quoting your non-delimited URL in thunderbird
Rich:
I suspect that Sn!pe's complaint is not the hard-wrap (my
own reply here is also hard wrapped), but instead is about
the even right justification by additional full space
insertion plus the auto-hyphenation. Those two, in a
mono-space context, make for severely ugly wordwrap.
Did you mean /non/-monospace context, wherein this format is
indeed horrible?
I switched over to tin a while back when I could no longer get trn to compile. I have it running on a VPS that hosts my mail and websites. I
ssh into that VPS, whether from a Konsole (KDE terminal) window under Linux or a WSL window running Gentoo Linux under Windows 11. In either case, double-clicking a URL will select it, upon which I can copy-and-paste it to transfer it into whatever browser I'm using.
Whether this behavior is part of tin or part of the host terminal, I
couldn't say. I think I could highlight and copy URLs out of trn in the
same way, though, so it's likely a feature of the local host and its software, not the newsreader running on a remote host.
I switched over to tin a while back when I could no longer get trn to compile. I have it running on a VPS that hosts my mail and websites. I
ssh into that VPS, whether from a Konsole (KDE terminal) window under Linux or a WSL window running Gentoo Linux under Windows 11. In either case, double-clicking a URL will select it, upon which I can copy-and-paste it to transfer it into whatever browser I'm using.
Whether this behavior is part of tin or part of the host terminal, I
couldn't say. I think I could highlight and copy URLs out of trn in the
same way, though, so it's likely a feature of the local host and its software, not the newsreader running on a remote host.
On Tue, 29 Aug 2023 15:55:58 GMT
scott@alfter.diespammersdie.us wrote:
I switched over to tin a while back when I could no longer get trn to
compile. I have it running on a VPS that hosts my mail and websites. I
ssh into that VPS, whether from a Konsole (KDE terminal) window under Linux >> or a WSL window running Gentoo Linux under Windows 11. In either case,
double-clicking a URL will select it, upon which I can copy-and-paste it to >> transfer it into whatever browser I'm using.
Whether this behavior is part of tin or part of the host terminal, I
couldn't say. I think I could highlight and copy URLs out of trn in the
same way, though, so it's likely a feature of the local host and its
software, not the newsreader running on a remote host.
It's easy to test for this : just type a URL on the shell command line , click on it and see if it gets selected. If it's the terminal emulator
which offers the behaviour then its menus may offer options regarding
what happens when you click on a URL and possibly other things.
It almost certainly is the emulator. I can't even imagine how tin could achieve this running on a remote host. I mean what mechanism could it use
to place something on the local X selection ?
Spiros Bousbouras <spibou@gmail.com> wrote:
It's easy to test for this : just type a URL on the shell command line , click on it and see if it gets selected. If it's the terminal emulator which offers the behaviour then its menus may offer options regarding
what happens when you click on a URL and possibly other things.
It almost certainly is the emulator. I can't even imagine how tin could achieve this running on a remote host. I mean what mechanism could it use to place something on the local X selection ?
After the last post, I kinda suspected it was most likely the terminal emulator that was looking for something URL-ish when you click around in the window. That said, there seems to be some way for certain kinds of mouse events from the terminal to get passed through an SSH connection to be
picked up by curses/ncurses-based apps, as I remember being able to click subjects to select them in trn. I don't know if tin supports this behavior, but I wouldn't be surprised if it does.
As for tin and URLs, if it recognizes one, it usually highlights it as inverse text.
MacSOUP displays your "beautifully formatted" text as you
have sent it. It also quotes your text according to
custom and usage. That quotation process makes your
"beautiful" text look like a dogs dinner.
Just a small note here: my right-justrified text was quite
narrow -- 52 charactes per line -- which makes it quotable
over quite a few levels of nesting without any reflowing
whatsoever, but your client seems always to reflow.
Performing auto-hyphenation and space stuffing to make an
even right edge with a fixed width font and a character
cell terminal produces a very ugly output.
Since Usenet predates web, clients need not be aware of
URLs to such a degree as to make them clickable
(presumably to open them in the default browser). I
don't think such newsreaders as tin, trn, or slrn
recognise URLs at all.
What about News Message-IDs and References? If properly
delimited, MacSOUP can automatically search its stored
articles for a match on M-IDs.
MacSOUP displays your "beautifully formatted" text as you
have sent it. It also quotes your text according to
custom and usage. That quotation process makes your
"beautiful" text look like a dogs dinner.
As I said in an adjacent post:-
I've finished with this topic if you have?
--
|rom The Future. +++ Breaking News From The Future. +++ Breaking News F|
| The USoA are switching to the binary number system because |
| having more than 1+1 distinct digits is far too woke. |
|+ #MABA + #makeAmericaBinaryAgain + #USA + #USoA + #woke + #MABA + #ma|
I think we agree, Rich. If one cares enough about
formatting to try to achieve block (brick) text when
monospaced, the classical way is to use synonyms and word
order, not the facile method of inserting extraneous
spaces and hyphens.
That merely looks ridiculous when applied to Usenet News,
particularly if quoted or read using a proportional font.
Perhaps Anton is more concerned about how his words look
on his own screen rather than how they appear to his
readers.
Observe that your signature separator does not end with a
space, as it shall per paragraph 4.3 of RFC 2646.
Did anybody complain about your signatures because they must be
viewed in a monospace font?
Who died and made you net.cop? In any case, if your newsreader can't handle a URL within plain text, perhaps you should get a better newsreader. tin (to name just one example) has no problem with either
of the URLs given above (or below, in my sig).
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 307 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 51:33:07 |
| Calls: | 6,912 |
| Calls today: | 2 |
| Files: | 12,379 |
| Messages: | 5,430,028 |