Re: small font

[tomas]

On Sat, Jul 06, 2024 at 07:17:51PM -0400, Felix Miata wrote:

[...]

> FWIW to any not familiar with how email was 30+ years ago, M$ and Win95 seem 
> to be
> the root blame for the practice of both use of not only HTML for email by 
> default,
> but also of defaulting to imposition of a smaller than default font size in 
> those
> HTML emails, apparently to match what web designers were doing, making email
> mousetype similar to the web page mousetype those eagle-eyed designers were 
> fond
> of imposing on everyone in the days before zoom was invented.

[...]

Don't blame the designers. There has always been a struggle over control
of the end user's computer -- just as a means of reaching the end user's
perception. The companies are winning.

That's what we get when the companies financing the infrastructure are all,
basically, advertising companies (Microsoft? They don't make tech. They sell
tech).

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: small font

[Felix Miata]

Van Snyder composed on 2024-07-06 14:13 (UTC-0700):

> I know what to do to read messages with tiny fonts -- if I can see
> enough of it to decide they're interesting.

> So far, only one correspondent, whom I have by-and-large concluded
> doesn't have anything interesting to way.

> What I'm offering to those who send messages that they seriously
> consider to be worth reading: You ought to make them readable. If you
> make it hard for recipients to read them, they'll ignore your wisdom.

FWIW to any not familiar with how email was 30+ years ago, M$ and Win95 seem to 
be
the root blame for the practice of both use of not only HTML for email by 
default,
but also of defaulting to imposition of a smaller than default font size in 
those
HTML emails, apparently to match what web designers were doing, making email
mousetype similar to the web page mousetype those eagle-eyed designers were fond
of imposing on everyone in the days before zoom was invented. Most GUI email
clients, as well as webmail apps, seem to have followed this stupid, rude lead.
It's the sender not changing the rude default, typically not knowing it even
exists, or can be changed (though in some cases default cannot be changed), 
which
is the immediate locus for blame.
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

Re: small font

[Van Snyder]

On Sat, 2024-07-06 at 15:41 +0100, debian-u...@howorth.org.uk wrote:
> > It's not my responsibility to deal with messages the senders aren't
> > serious about being read.
> 
> It's up to you of course but if that's your opinion then you always
> have the option of simply not reading messages that are sent (against
> list guidelines) with HTML parts that suggest using fonts that are
> too
> small for you.

I know what to do to read messages with tiny fonts -- if I can see
enough of it to decide they're interesting.

So far, only one correspondent, whom I have by-and-large concluded
doesn't have anything interesting to way.

What I'm offering to those who send messages that they seriously
consider to be worth reading: You ought to make them readable. If you
make it hard for recipients to read them, they'll ignore your wisdom.

Re: small font

[debian-user]

Van Snyder  wrote:
 
> It's not my responsibility to deal with messages the senders aren't
> serious about being read.

It's up to you of course but if that's your opinion then you always
have the option of simply not reading messages that are sent (against
list guidelines) with HTML parts that suggest using fonts that are too
small for you.

Alternatively:

- you could search for how to adjust font sizes in evolution (hint
  edit/ preferences/ mail preferences/ general tab)

- you could set evolution to display the plain text version of emails

- you could choose another mail reader

Sadly whilst it is your opinion that it's not your responsibility, I
doubt many other people share your opinion, so I think your options are
limited to those within your own control, such as the four above.

Re: small font

[Max Nikulin]

On 06/07/2024 01:01, Van Snyder wrote:

I'm not able to read this message.


I do not think you will manage to achieve anything on this way. The 
person has clearly expressed that their are not going to follow 
recommendations concerning message format and do not care if messages 
cause trouble for some readers. Better options may be:


- Silently ignore.
- If you still expect something useful then find a way to deal with this 
kind of messages: temporary switch to plain text part, configure fonts, 
copy-paste text to an editor.
- Discuss with the mailer developers if they can implement some kind of 
workaround.

- Switch to another mail user agent.

P.S. Please, read
- 
- Monthly FAQ for Debian-user mailing list
  

Re: small font

[Van Snyder]

On Fri, 2024-07-05 at 15:04 -0400, Felix Miata wrote:
> I don't use Evolution, but I suspect being a Gnome application that
> it works like
> web browsers, where fonts can be enlarged using Ctrl-+ as many times
> as it takes
> to grow the fonts adequately. Possibly it also has a minimum
> displayed text size
> option as web browsers offer.

Ctrl-+ works on the entire window. So if the tiniest font is enlarged
enough to be readable, the rest of the message doesn't fit anymore. And
Evolution remembers it, so you have to be careful to count the number
of times you do it so you can get back to normal without a lot more
experimenting.

It's not my responsibility to deal with messages the senders aren't
serious about being read.

Re: small font

[Felix Miata]

Van Snyder composed on 2024-07-05 11:45 (UTC-0700):

> On Fri, 2024-07-05 at 14:07 -0400, Felix Miata wrote:

>> > I'm not able to read this message. 

>> Can you suggest to us why you think that might be?

> Because the message was composed in html using a very small font, and
> my mail reader (evolution) automatically prefers to read mail in html.

> I've never before had to make an explicit request to the mail reader to
> switch to plain text, so I haven't taken the trouble to work out how to
> do it. It's easier to ignore messages that are either incompetently or
> intentionally composed so as to be unreadable without special actions
> taken by the recipients.

I don't use Evolution, but I suspect being a Gnome application that it works 
like
web browsers, where fonts can be enlarged using Ctrl-+ as many times as it takes
to grow the fonts adequately. Possibly it also has a minimum displayed text size
option as web browsers offer.

Evolution may also be able to do as I have done since last century, starting 
with
Netscape 2 email, then Netscape 3 email, then Netscape 4 email, then Mozilla
email, and eventually as now, SeaMonkey, the replacement name for Mozilla. That
is, to set select mail reading in plain text only mode via menu option

view message body as plain text

Sometimes email is sent in multipart with no plain text content. Unless those 
come
from doctors or financial institutions, I consider them spam and delete without
attempting to read any included content. When necessary, I temporarily switch 
from
view message body as plain text to as simple HTML.
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

Re: small font

[Van Snyder]

On Fri, 2024-07-05 at 14:07 -0400, Felix Miata wrote:
> > I'm not able to read this message. 
> 
> Can you suggest to us why you think that might be?

Because the message was composed in html using a very small font, and
my mail reader (evolution) automatically prefers to read mail in html.

I've never before had to make an explicit request to the mail reader to
switch to plain text, so I haven't taken the trouble to work out how to
do it. It's easier to ignore messages that are either incompetently or
intentionally composed so as to be unreadable without special actions
taken by the recipients.

Re: small font

[Felix Miata]

Van Snyder composed on 2024-07-05 11:01 (UTC-0700):

> I'm not able to read this message. 

Can you suggest to us why you think that might be?

> On Fri, 2024-07-05 at 14:01 +0200, Richard wrote:

>> You really need to better read who writes what. I didn't start the
>> discussion on message sizes due to HTML, I simply ended it because of
>> irrelevance.

>> On Fri, Jul 5, 2024 at 1:30 PM Greg Wooledge  wrote:
>> > [...] you chose to shift the topic to message
>> > sizes (which isn't the primary reason HTML email is frowned upon)
>> > [...]-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

Re: small font

[Van Snyder]

I'm not able to read this message.

On Fri, 2024-07-05 at 14:01 +0200, Richard wrote:
> You really need to better read who writes what. I didn't start the
> discussion on message sizes due to HTML, I simply ended it because of
> irrelevance.
> 
> On Fri, Jul 5, 2024 at 1:30 PM Greg Wooledge 
> wrote:
> > [...] you chose to shift the topic to message
> > sizes (which isn't the primary reason HTML email is frowned upon)
> > [...]
> > 

Re: small font

[Richard]

Thank god nobody needs help from people so hung up on absolute irrelevant
stuff and rules that haven't made sense in decades - if ever. As you may
have read from the threads, those rules aren't undisputed at all. If they
where seen as relevant as some people want to make believe, the list
maintainers had automated the compliance on the server side long ago. They
didn't, so it can't be that relevant.

Also, you implying rudeness because of an unnoticed bug is just
hilarious and only shows that you just have no clue about what you are
writing and don't even bother properly reading threads before making up
accusations. So better hope nobody remembers your bad attitude if you ever
need help. Now stop spamming.

On Fri, Jul 5, 2024 at 2:05 PM Nicolas George  wrote:

> And that ended the willingness of many people to help you.
>
> Good luck with your problems.
>
> --
>   Nicolas George
>
>

Re: small font

[Nicolas George]

Richard (12024-07-05):
> You really need to better read who writes what. I didn't start the
> discussion on message sizes due to HTML, I simply ended it because of
> irrelevance.

And that ended the willingness of many people to help you.

Good luck with your problems.

-- 
  Nicolas George

Re: small font

[Richard]

You really need to better read who writes what. I didn't start the
discussion on message sizes due to HTML, I simply ended it because of
irrelevance.

On Fri, Jul 5, 2024 at 1:30 PM Greg Wooledge  wrote:

> [...] you chose to shift the topic to message
> sizes (which isn't the primary reason HTML email is frowned upon) [...]
>
>

Re: small font

[Greg Wooledge]

On Fri, Jul 05, 2024 at 10:51:12 +0200, Richard wrote:
> And who was talking about transport? The whole discussion was about
> storage, and storing mail compressed is hardly a security issue.

The discussion was originally about your messages containing directives
to render all of your text in a small font.  Some readers found your
messages difficult to read for that reason, and we politely pointed it
out to you.

Everything after that has been you ranting against everyone who talks to
you, shifting the goalposts, and refusing to acknowledge that *any* of
your etiquette violations are your responsibility, or even a problem.

Your messages:

 * Are multipart text/html and text/plain.

 * Consistently use top-posting of your reply above the quoted text.

 * Contain directives to use small fonts that make reading them difficult
   for some people.

Two of these issues are breaches of list's established rules of etiquette,
and the third one is an unfortunate rudeness.  Yet, instead of taking
steps to correct any of them, you chose to shift the topic to message
sizes (which isn't the primary reason HTML email is frowned upon), and
then to compression efficiency (completely irrelevant, as email is
generally neither transmitted nor stored in a compressed form).

Anyway, this is pretty clearly a lost cause.  You're using gmail, which
is notoriously horrible, and it seems you are not willing to change your
behavior.  There's nothing more I can do to help you.

Re: small font

[Richard]

And who was talking about transport? The whole discussion was about
storage, and storing mail compressed is hardly a security issue.

On Fri, Jul 5, 2024 at 5:02 AM Jeffrey Walton  wrote:

> Compression is a security hole. It leaks information. It should be
> disabled. Infact, TLS v1.3 removed it from the protocol. Also see
>  and
> .
>

Re: small font

[Richard]

Not how lossless compression works. The final size depends much more on the
content than on how much content there is. By no means it's "proportional".

On Thu, Jul 4, 2024 at 10:09 PM Michel Verdier  wrote:

> Compression reduces the size but it's proportionnal so don't negate the
> extra html size. The global size will always be 4-10x.
>

Re: small font

[Stefan Monnier]

> Compression reduces the size but it's proportionnal so don't negate the
> extra html size. The global size will always be 4-10x.

No, the compression is not proportional.  HTML is naturally very
redundant, and machine-generated HTML like the one seen in Richard's
email tends to be excruciatingly redundant, so it compresses even much
better than plain text.  Plus the part of the plain/text that's in
common with the text/html (i.e. the actual useful part) would usually be
recognized as a redundancy, so all in all you'll typically get a much
smaller size difference after compression.

Of course, that's if compression takes place, which is not necessarily
the case.  In practice, for most emails like the ones exchanged on this
mailing-list, the precise size of the message is largely irrelevant:
even if multiplied by 10x, the cost of the actual content is lost in the
noise of the rest of the protocol.


Stefan

Re: small font

[Jeffrey Walton]

On Thu, Jul 4, 2024 at 2:58 PM Richard  wrote:
>
> Right, because 4x = 10x. Jesus, stop being so ridiculous. Also, there's some 
> magic trick called compression.

Compression is a security hole. It leaks information. It should be
disabled. Infact, TLS v1.3 removed it from the protocol. Also see
 and
.

> Human readable text is especially easy to compress, basically negating all 
> those effects. So just stick to reality, everything else is just embarrassing.

Jeff

> On Thu, Jul 4, 2024, 16:48 Greg Wooledge  wrote:
>>
>> The HTML part is more than double the size of the plain text part, and
>> when you include all of the MIME metadata needed to set up the multipart
>> message, the overall size of the body is about 4x what it would have been
>> if you'd only sent plain text (0.5k -> 2.0k).
>>
>> Granted, this is not the 10x increase that Michel predicted, but it's
>> easy to see how a *different* HTML message, with a lot more markup,
>> could certainly reach that threshold.

Re: small font

[Jeffrey Walton]

On Thu, Jul 4, 2024 at 9:58 AM jeremy ardley  wrote:
>
> On 4/7/24 17:13, Roger Price wrote:
> >
> > The Debian mailing list Code of Conduct at
> > https://www.debian.org/MailingLists/
> > is clear:
> >
> > « Please don't send your messages in HTML; use plain text instead »
>
> I presume there is some compelling reason that the mailing list doesn't
> filter html emails and only resend the text only version?

Yeah, the policy should be enforced at the list server if it is an
important policy. As an example, Vger will reject HTML messages since
the kernel folks feel HTML emails are a characteristic of spam. See
.

If it is not an important policy, then it should probably be removed
from the FAQ.

Jeff

Re: small font

[Michel Verdier]

On 2024-07-04, Richard wrote:

> Right, because 4x = 10x. Jesus, stop being so ridiculous. Also, there's
> some magic trick called compression. Human readable text is especially easy
> to compress, basically negating all those effects. So just stick to
> reality, everything else is just embarrassing.

Please don't be rude.

Ok I over estimate the gap in *your* mails but not in other html mails
I've seen (as Greg correctly supposed).

Compression reduces the size but it's proportionnal so don't negate the
extra html size. The global size will always be 4-10x.

The *reality* is that you need to change just one option in your MUA.
And I stop here this thread.

Re: small font

[Richard]

Right, because 4x = 10x. Jesus, stop being so ridiculous. Also, there's
some magic trick called compression. Human readable text is especially easy
to compress, basically negating all those effects. So just stick to
reality, everything else is just embarrassing.

On Thu, Jul 4, 2024, 16:48 Greg Wooledge  wrote:

> The HTML part is more than double the size of the plain text part, and
> when you include all of the MIME metadata needed to set up the multipart
> message, the overall size of the body is about 4x what it would have been
> if you'd only sent plain text (0.5k -> 2.0k).
>
> Granted, this is not the 10x increase that Michel predicted, but it's
> easy to see how a *different* HTML message, with a lot more markup,
> could certainly reach that threshold.
>
>

Re: small font

[Greg Wooledge]

On Thu, Jul 04, 2024 at 16:19:44 +0200, Richard wrote:
> If you ever want to be taken seriously, stop spreading such bogus nonsense.
> Even base64 encoding wouldn't blow up the size that much. No idea what bs
> mail you are talking about, but for me, both the plain text and html
> version are said to be 4k in size (by du). Even though that's not that
> exact, simple logic is enough to be able to tell your claim is pretty much
> impossible.
> 
> Best
> 
> On Thu, Jul 4, 2024 at 3:43 PM Michel Verdier  wrote:
> 
> > As the html part is useless and multiply
> > the mail size by almost 10.

Richard, your message to which I'm replying shows the following sizes:

  I 1  [multipa/alternativ, 7bit, 2.0K] 
  I 2 ├─> [text/plain, quoted, utf-8, 0.5K] 
  I 3 └─>  [text/html, quoted, utf-8, 1.2K] 

The HTML part is more than double the size of the plain text part, and
when you include all of the MIME metadata needed to set up the multipart
message, the overall size of the body is about 4x what it would have been
if you'd only sent plain text (0.5k -> 2.0k).

Granted, this is not the 10x increase that Michel predicted, but it's
easy to see how a *different* HTML message, with a lot more markup,
could certainly reach that threshold.

Also, please stop top-posting your replies.

Re: small font

[Richard]

If you ever want to be taken seriously, stop spreading such bogus nonsense.
Even base64 encoding wouldn't blow up the size that much. No idea what bs
mail you are talking about, but for me, both the plain text and html
version are said to be 4k in size (by du). Even though that's not that
exact, simple logic is enough to be able to tell your claim is pretty much
impossible.

Best

On Thu, Jul 4, 2024 at 3:43 PM Michel Verdier  wrote:

> As the html part is useless and multiply
> the mail size by almost 10.
>
>

Re: small font

[Richard]

The bug is reported already, as that's by no means what's intended or what
the settings would suggest. Anything beyond that is out of my hands. And as
already explained, since there are enough tools out there to have messages
look the way you want, this simply doesn't have any priority.

Best

On Thu, Jul 4, 2024, 14:26 Greg Wooledge  wrote:

> "Richard", for example, seemed to be
> unaware that the HTML parts of his multipart messages were being sent
> with the font size set to "small".
>

Re: small font

[Greg Wooledge]

On Thu, Jul 04, 2024 at 11:29:43 +0200, Thomas Schmitt wrote:
> Regrettably the list archives seem to have a preference for publishing
> the HTML version of list mails. At least i see two different fonts in
> an archived mail of Richard:
>   https://lists.debian.org/debian-user/2024/07/msg00124.html

In a way, this is good.  It lets Richard see what his messages look like
to other people.  At least, assuming his browser isn't configured to
ignore his own font size directives

If you still have one of Richard's messages in your inbox, you can
look at the raw HTML.  An excerpt of it has been posted a couple
times in this thread already.  A bit of it is also included in the HTML
source of the list archive page (hence you seeing the font size
difference), but that's after the archives have wrapped another layer
of HTML encoding around the original, so take that with a grain of salt.

Re: small font

[Greg Wooledge]

On Thu, Jul 04, 2024 at 19:09:47 +0800, jeremy ardley wrote:
> Unless there is a compelling reason to accept mixed format ( HTML ) I can't
> see why the list can't filter submissions to text only - which is the list
> policy anyway - and by doing so provide education to users about what the
> list format is.

That would be a drastic change.  The main purpose of debian-user, as I
see it, is to offer help to Debian users who need it.  As such, the
posting etiquette expectations need to be lowered a bit for this list.
Users who need help may have lower technical proficiency than one would
expect on, say, a Debian developers' list.

As long as people are not intentionally being rude about it, I'd give
them the benefit of the doubt.  "Richard", for example, seemed to be
unaware that the HTML parts of his multipart messages were being sent
with the font size set to "small".  Now that he knows about it, he might
be able to get that taken care of.

Lots of other people may be facing similar technological challenges,
and yet they may still be capable of contributing to the discussion.

Re: small font

[Michel Verdier]

On 2024-07-04, jeremy ardley wrote:

> The problem is mostly because users have email software that automatically
> uses mixed format. That's not their fault as they are probably unaware of the
> problem.

And lots of MUA only show HTML version, hiding the text copy and the
problem.

> Unless there is a compelling reason to accept mixed format ( HTML ) I can't
> see why the list can't filter submissions to text only - which is the list
> policy anyway - and by doing so provide education to users about what the list
> format is.

Perhaps because users needing "education" usually don't read policy and
don't read MUA options... Or just perhaps some mails could be HTML
only.

PS : for your eyes (almost) only : don't reply to list AND to author as
it creates duplicates :)

Re: small font

[Richard Owlett]

On 07/04/2024 06:09 AM, jeremy ardley wrote:



On 4/7/24 18:34, to...@tuxteam.de wrote:

But let me try: perhaps because the people who set up the mailing
list don't believe in enforcing behavior by technological means,
but rather by convincing people?


If I understand the history correctly:

- All early email lists were text only

- After some long time people started sending mixed format emails to lists

- Shortly afterwards list administrators asked people to not send mixed 
format emails


- Since then people either in ignorance of list etiquette or ignorance 
of their mailer properties kept on sending mixed format emails to lists


The problem is mostly because users have email software that 
automatically uses mixed format. That's not their fault as they are 
probably unaware of the problem.


List administrators have the ability to ban users who violate etiquette 
and in this list actively do so. Banning a user for using mixed format 
in violation of list etiquette is obviously not an option.


Unless there is a compelling reason to accept mixed format ( HTML ) I 
can't see why the list can't filter submissions to text only - which is 
the list policy anyway - and by doing so provide education to users 
about what the list format is.





Another problem is that nothing intrinsically forces the "plain text 
format content" to match the "HTML format content". There's one 
obnoxious individual who puts sarcastic comments in the "plain text 
format content" about mail programs that enforce "plain text only".

Re: small font

[jeremy ardley]

On 4/7/24 18:34, to...@tuxteam.de wrote:

But let me try: perhaps because the people who set up the mailing
list don't believe in enforcing behavior by technological means,
but rather by convincing people?


If I understand the history correctly:

- All early email lists were text only

- After some long time people started sending mixed format emails to lists

- Shortly afterwards list administrators asked people to not send mixed 
format emails


- Since then people either in ignorance of list etiquette or ignorance 
of their mailer properties kept on sending mixed format emails to lists


The problem is mostly because users have email software that 
automatically uses mixed format. That's not their fault as they are 
probably unaware of the problem.


List administrators have the ability to ban users who violate etiquette 
and in this list actively do so. Banning a user for using mixed format 
in violation of list etiquette is obviously not an option.


Unless there is a compelling reason to accept mixed format ( HTML ) I 
can't see why the list can't filter submissions to text only - which is 
the list policy anyway - and by doing so provide education to users 
about what the list format is.

Re: small font

[tomas]

On Thu, Jul 04, 2024 at 06:20:22PM +0800, jeremy ardley wrote:
> 
> 
> On 4/7/24 17:13, Roger Price wrote:
> > 
> > The Debian mailing list Code of Conduct at
> > https://www.debian.org/MailingLists/
> > is clear:
> > 
> > « Please don't send your messages in HTML; use plain text instead »
> 
> I presume there is some compelling reason that the mailing list doesn't
> filter html emails and only resend the text only version?

Strange question, and even stranger way to pose it.

But let me try: perhaps because the people who set up the mailing
list don't believe in enforcing behavior by technological means,
but rather by convincing people?

That's at least how I'd think.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: small font

[jeremy ardley]

On 4/7/24 17:13, Roger Price wrote:


The Debian mailing list Code of Conduct at 
https://www.debian.org/MailingLists/

is clear:

« Please don't send your messages in HTML; use plain text instead »


I presume there is some compelling reason that the mailing list doesn't 
filter html emails and only resend the text only version?

Re: small font

[Roger Price]

On Thu, 4 Jul 2024, Michel Verdier wrote:


Tell that to your mail progra=


---^^^


I would add that it's up to the *sender* mail program to send text only
mail to this list (and others). As the html part is useless and multiply
the mail size by almost 10.


The Debian mailing list Code of Conduct at https://www.debian.org/MailingLists/
is clear:

« Please don't send your messages in HTML; use plain text instead »

Roger

Re: small font

[Thomas Schmitt]

Hi,

Michel Verdier wrote:
> I would add that it's up to the *sender* mail program to send text only
> mail to this list (and others).

I found this link in the monthly list FAQ:

  https://www.debian.org/MailingLists/#codeofconduct

where i read:

  "Please don't send your messages in HTML; use plain text instead."

(I cannot judge how hard it is to fulfill this request on a contemporary
desktop.)


Regrettably the list archives seem to have a preference for publishing
the HTML version of list mails. At least i see two different fonts in
an archived mail of Richard:
  https://lists.debian.org/debian-user/2024/07/msg00124.html


Have a nice day :)

Thomas

Re: small font

[Michel Verdier]

On 2024-07-04, Max Nikulin wrote:

>> Tell that to your mail program. If it chooses to show you the mail that way,
>> don't blame me.
>
> - insisting on an "industry standard" mail style
>
>> > y:arial,helvetica,sans-serif;font-size:small">Tell that to your mail progra=
>
> ---^^^

I would add that it's up to the *sender* mail program to send text only
mail to this list (and others). As the html part is useless and multiply
the mail size by almost 10.

small font (was: Re: Creating PDF/A from LaTeX source and from existing PDF)

[Max Nikulin]

I am in doubts what is more rude:

On 04/07/2024 04:02, Richard wrote:

Please stop using such a dinky font. There are plenty of old farts
trying to read this list.


- writing this before an attempt to hijack the thread using an already 
discussed question,


Tell that to your mail program. If it chooses to show you the mail that 
way, don't blame me.


- insisting on an "industry standard" mail style


Tell that to your mail progra=


---^^^

Re: htmldoc default font size

[Roger Price]

On Sun, 23 Jun 2024, Dan Ritter wrote:


Use this as a test file:

testfile
here is the base text

run it through htmldoc without using a --fontsize option, open
the resulting pdf and measure?


I no longer have a working printer, but when I get access to one, I'll do 
some measurements.



htmldoc is very badly outdated; if you want proper control, you
want to use pandoc (yes, Debian packages it) and a CSS file.


I see at https://pandoc.org/MANUAL.html#variables-for-latex that pandoc has the 
linestretch and fontsize controls for the LaTeX used to produce PDF.


Roger

Re: htmldoc default font size

[eben]

On 6/23/24 10:32, Roger Price wrote:

I'm using htmldoc 1.9.11-4+deb11u3 to convert html files to pdf.  When
playing with the fontsize option I discover that the default is not a whole
number, more like 11.2 points.


Hmm, maybe the author used something in mm?  Weird.  4mm is 11.33 points.

--
An ASCII character walks into a bar and orders a double. "Having a bad
day?" asks the barman. "Yeah, I have a parity error," replies the ASCII
chrcter. The barman says, "Yeah, I thought you looked a bit off." - Skud

Re: htmldoc default font size

[Dan Ritter]

Roger Price wrote: 
> I'm using htmldoc 1.9.11-4+deb11u3 to convert html files to pdf.  When
> playing with the fontsize option I discover that the default is not a whole
> number, more like 11.2 points.  Is this the expected behaviour ?
> 
> Background: The manual at https://www.msweet.org/htmldoc/htmldoc.html#3_2_23
> says “The --fontsize option specifies the base font size for the entire
> document in points (1 point = 1/72nd inch)”, but doesn't say what the
> default value is if the option is omitted.
> 
> What is the default font size?

Use this as a test file:

testfile
here is the base text

run it through htmldoc without using a --fontsize option, open
the resulting pdf and measure?

htmldoc is very badly outdated; if you want proper control, you
want to use pandoc (yes, Debian packages it) and a CSS file.

-dsr-

htmldoc default font size

[Roger Price]

I'm using htmldoc 1.9.11-4+deb11u3 to convert html files to pdf.  When playing 
with the fontsize option I discover that the default is not a whole number, more 
like 11.2 points.  Is this the expected behaviour ?


Background: The manual at https://www.msweet.org/htmldoc/htmldoc.html#3_2_23 
says “The --fontsize option specifies the base font size for the entire document 
in points (1 point = 1/72nd inch)”, but doesn't say what the default value is if 
the option is omitted.


What is the default font size?

Roger

Re: Zutty fonts - zutty always uses the same font and fontsize

[Max Nikulin]

On 02/05/2024 15:17, Richmond wrote:


It understands the font names from xfontsel which is a major improvement
on zutty.


I have nothing against raster fonts for terminal applications, but I am 
surprised that support of X Logical Font Description may be considered 
as an improvement in comparison with an application relying on fontconfig.


I have never tried zutty, but I would expect something like (assuming 
fonts-liberation2 installed)


zutty -font LiberationMono -fontsize 24

However applications are usually more liberal concerning specifying 
vector fonts and use various fallbacks and substitutions.

Re: Zutty fonts - zutty always uses the same font and fontsize

[Richmond]

Sirius  writes:


> Good old urxvt is quite lightweight compared to kitty.

It understands the font names from xfontsel which is a major improvement
on zutty.

urxvt -bg black -fn -*-courier-*-r-*-*-24-*-*-*-*-*-*-*

8)

Re: Zutty fonts - zutty always uses the same font and fontsize

[Sirius]

In days of yore (Thu, 02 May 2024), Sirius thus quoth: 
> Tab-handling is one of the things that kitty does well that I
> really like. But when it takes over ten times the memory for a single
> instance compared to urxvt - I can forego the tab-handling and have
> multiple windows instead. (Not looked yet if there is urxvt patches for
> kitty style tab handling - which would be awesome if it exists.)

To follow up on this:
  https://github.com/gryf/tabbedalt

$ mkdir -p ~/.urxvt/ext/
$ wget -O ~/.urxvt/ext/tabbedalt 
https://raw.githubusercontent.com/gryf/tabbedalt/master/tabbedalt
$ echo "URxvt.perl-ext: tabbedalt" >> .Xdefaults

Now you have tabs in urxvt.

-- 
Kind regards,

/S

Re: Zutty fonts - zutty always uses the same font and fontsize

[Sirius]

In days of yore (Wed, 01 May 2024), Karl Vogel thus quoth: 
> On Wed, May 01, 2024 at 08:32:31AM -0400, Sirius wrote:
> > If Debian still packages it, look for rxvt instead, or use xterm. Both
> > are well tried and well tested for when you want something.. dated. ;)
> 
>   I resemble that remark.  Xterm v390 was released on 19 Feb 2024, and
>   building it from source is easy.
> 
>   https://invisible-island.net/archives/xterm/xterm-390.tgz{,.asc}

It was meant tongue-in-cheek. OP's post prompted me to start digging into
urxvt and it is now my default terminal. :)

Modern terminals like Gnome-terminal, Konsole, alacritty, kitty and others
are essentially slapping a spruced-up UI on top of something that is 40+
years old. Tab-handling is one of the things that kitty does well that I
really like. But when it takes over ten times the memory for a single
instance compared to urxvt - I can forego the tab-handling and have
multiple windows instead. (Not looked yet if there is urxvt patches for
kitty style tab handling - which would be awesome if it exists.)

And as someone pointed out about the control character handling, there is
a security aspect to pay attention to as well. Xterm and Rxvt have both
been down this road for so long that they have that side of things
relatively well handled.

I've seen zutty because it was installed by default, but I have no idea
why it is installed by default. It does not strike me as the best choice
when both xterm and rxvt are available.

> My mind is like my browser: 19 open tabs, three of them are frozen, and
> I have no clue where the music is coming from.

Oh, I s identify with this one.

-- 
Kind regards,

/S

Re: Zutty fonts - zutty always uses the same font and fontsize

[Max Nikulin]

On 02/05/2024 10:11, Greg Wooledge wrote:

On Thu, May 02, 2024 at 09:34:13AM +0700, Max Nikulin wrote:

On 01/05/2024 21:58, Sirius wrote:


I was right about .Xresources that it is one of the files used for loading
settings into the X server, but urxvt looks at .Xdefaults instead.


It is a bit strange. Applications should not read these files directly.
Content should be loaded during X session startup, see
/etc/X11/Xsession.d/30x11-common_xresources

After modification of .Xresources it is necessary to invoke xrdb(1).


I'm not sure about rxvt-unicode, but the original rxvt definitely
worked that way.


Almost certainly I was wrong. .Xresources should be read by xrdb, while 
.Xdefaults (older method) is read by applications.

https://superuser.com/questions/243914/what-is-the-difference-between-xresources-and-xdefaults


  1. app-defaults file in $XAPPLRESDIR
  2. $HOME/.Xdefaults
  3. RESOURCE_MANAGER property on root-window of screen 0
  4. SCREEN_RESOURCES property on root-window of the current screen
  5. $XENVIRONMENT file OR $HOME/.Xdefaults-
  6. resources specified via -xrm on the commandline

It says you can use xrdb, but then lists the places it looks, and that
list does not include xrdb(?).  I don't understand what this means.


Items 3 and 4 in this list are places where xrdb stores properties.

Re: Zutty fonts - zutty always uses the same font and fontsize

[Karl Vogel]

On Wed, May 01, 2024 at 08:32:31AM -0400, Sirius wrote:
> If Debian still packages it, look for rxvt instead, or use xterm. Both
> are well tried and well tested for when you want something.. dated. ;)

  I resemble that remark.  Xterm v390 was released on 19 Feb 2024, and
  building it from source is easy.

  https://invisible-island.net/archives/xterm/xterm-390.tgz{,.asc}

-- 
Karl Vogel  I don't speak for anyone but myself

My mind is like my browser: 19 open tabs, three of them are frozen, and
I have no clue where the music is coming from.

Re: Zutty fonts - zutty always uses the same font and fontsize

[Greg Wooledge]

On Thu, May 02, 2024 at 09:34:13AM +0700, Max Nikulin wrote:
> On 01/05/2024 21:58, Sirius wrote:
> > 
> > I was right about .Xresources that it is one of the files used for loading
> > settings into the X server, but urxvt looks at .Xdefaults instead.
> 
> It is a bit strange. Applications should not read these files directly.
> Content should be loaded during X session startup, see
> /etc/X11/Xsession.d/30x11-common_xresources
> 
> After modification of .Xresources it is necessary to invoke xrdb(1).

I'm not sure about rxvt-unicode, but the original rxvt definitely
worked that way.  This was part of the lightweight design of rxvt.
The author didn't want the bloat involved in reading the X resource
database, so he chose to read the source files directly.

According to :

  RESOURCES (available also as long-options)

  Note: 'rxvt --help' gives a list of all resources (long options)
  compiled into your version. If compiled with internal Xresources
  support (i.e. rxvt -h lists .Xdefaults) then rxvt accepts application
  defaults set in XAPPLOADDIR/Rxvt (compile-time defined: usually
  /usr/lib/X11/app-defaults/Rxvt) and resources set in ~/.Xdefaults,
  or ~/.Xresources if ~/.Xdefaults does not exist.


The corresponding section of the rxvt-unicode man page (in Debian 12)
is a bit confusing to me:

   You can set and change the resources using X11 tools like xrdb. Many
   distribution do also load settings from the ~/.Xresources file when X
   starts. urxvt will consult the following files/resources in order, with
   later settings overwriting earlier ones:

 1. app-defaults file in $XAPPLRESDIR
 2. $HOME/.Xdefaults
 3. RESOURCE_MANAGER property on root-window of screen 0
 4. SCREEN_RESOURCES property on root-window of the current screen
 5. $XENVIRONMENT file OR $HOME/.Xdefaults-
 6. resources specified via -xrm on the commandline

It says you can use xrdb, but then lists the places it looks, and that
list does not include xrdb(?).  I don't understand what this means.

Re: Zutty fonts - zutty always uses the same font and fontsize

[Max Nikulin]

On 01/05/2024 21:58, Sirius wrote:


I was right about .Xresources that it is one of the files used for loading
settings into the X server, but urxvt looks at .Xdefaults instead.


It is a bit strange. Applications should not read these files directly. 
Content should be loaded during X session startup, see 
/etc/X11/Xsession.d/30x11-common_xresources


After modification of .Xresources it is necessary to invoke xrdb(1).

Per-application files are in /etc/X11/app-defaults/


Good old urxvt is quite lightweight compared to kitty.


I am unsure concerning real degree of danger, just a warning:

https://dgl.cx/2023/09/ansi-terminal-security

Additionally some terminals support C1 controls in UTF-8 encoded text,
which per this 2015 posting to oss-security is problematic. Some
terminals have the ability to turn this off, if they do not such as
Kitty I cannot recommend their use.

Re: Zutty fonts - zutty always uses the same font and fontsize

[Richmond]

Sirius  writes:

> I can get it working with "zutty -font 12x24" and other numerically
> named fonts.

Wow that one actually worked. That's the first time I've seen a
different font in zutty!



> Trying with something like 'lucidasans-24' will make it dump core
> however.

I got this error:

zutty -font lucidasans-24 E [fontpack.cc:218] Error: No Regular variant
of the requested font 'lucidasans-24' could be identified.  terminate
called after throwing an instance of 'std::runtime_error' what(): No
suitable files for 'lucidasans-24' found!

Re: Zutty fonts - zutty always uses the same font and fontsize

[Sirius]

In days of yore (Wed, 01 May 2024), Greg Wooledge thus quoth: 
> On Wed, May 01, 2024 at 02:31:49PM +0200, Sirius wrote:
> > zutty is kind of only necessary when you want something *really*
> > lightweight and you do not need to worry about UTF-8. Just writing this
> > means a trip down memory lane and back to configuring CTWM on old Sun 5
> > workstations back in the 90's. If Debian still packages it, look for rxvt
> > instead, or use xterm. Both are well tried and well tested for when you
> > want something .. dated. ;)
> 
> The original rxvt is no longer packaged in Debian, as far as I can see.
> There's rxvt-unicode, which is what I use, which has most of the same
> look and feel as rxvt, but is substantially larger.

I pulled down rxvt-unicode and started looking at how to configure it up
so that it works more or less like kitty (which is what I normally use).

> Between xterm and rxvt-unicode you should have most of your "basic
> no-frills terminal" needs met by one or the other.

I was right about .Xresources that it is one of the files used for loading
settings into the X server, but urxvt looks at .Xdefaults instead. If one
puts something like the below into .Xdefaults in $HOME, it works with
Powerline and it does not look too terrible.

Rxvt.depth: 24
Rxvt.jumpScroll: on
Rxvt.fading: 20
Rxvt.background: #101010
Rxvt.foreground: #efefef
Rxvt.cursorColor: #dd
Rxvt.font: xft:Hack:pixelsize=16,xft:Powerline:pixelsize=16
Rxvt.boldFont: xft:Hack Bold:pixelsize=16,xft:Powerline:pixelsize=16
Rxvt.italicFont: xft:Hack Italic:pixelsize=16,xft:Powerline:pixelsize=16
Rxvt.boldItalicFont: xft:Hack BoldItalic:pixelsize=16,xft:Powerline:pixelsize=16
Rxvt.loginShell: on
Rxvt.visualBell: on
Rxvt.scrollBar_right: on
Rxvt.scrollBar_floating: on
Rxvt.saveLines: 5000
Rxvt.termName: xterm-256color
Rxvt.disablePasteBrackets: off

As per usual, getting the fonts right was the hardest part. As for memory
use..

USER PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
sirius 56392  0.1  0.1  48136 28160 ?S16:48   0:00 
/usr/bin/urxvt
sirius 56393  0.0  0.0  21928   816 ?S16:48   0:00 
/usr/bin/urxvt
sirius 56465  0.1  0.1  43192 23232 ?S16:52   0:00 
/usr/bin/urxvt
sirius 56466  0.0  0.0  21928   820 ?S16:52   0:00 
/usr/bin/urxvt
sirius 56532  2.5  1.0 745480 150828 ?   Sl   16:54   0:02 
/usr/bin/kitty
sirius 56533  1.5  0.2  61388 35692 ?Ss   16:54   0:01 
/usr/bin/kitty
sirius 56595  0.0  0.0   9212  2096 pts/2S+   16:55   0:00 grep 
kitty\|rxvt\|USER

Good old urxvt is quite lightweight compared to kitty.

-- 
Kind regards,

/S

Re: Zutty fonts - zutty always uses the same font and fontsize

[Greg Wooledge]

On Wed, May 01, 2024 at 02:31:49PM +0200, Sirius wrote:
> zutty is kind of only necessary when you want something *really*
> lightweight and you do not need to worry about UTF-8. Just writing this
> means a trip down memory lane and back to configuring CTWM on old Sun 5
> workstations back in the 90's. If Debian still packages it, look for rxvt
> instead, or use xterm. Both are well tried and well tested for when you
> want something .. dated. ;)

The original rxvt is no longer packaged in Debian, as far as I can see.
There's rxvt-unicode, which is what I use, which has most of the same
look and feel as rxvt, but is substantially larger.

Between xterm and rxvt-unicode you should have most of your "basic
no-frills terminal" needs met by one or the other.

Re: Zutty fonts - zutty always uses the same font and fontsize

[Sirius]

In days of yore (Wed, 01 May 2024), Richmond thus quoth: 
> I am puzzled by the zutty terminal emulator. I have tried:
> 
>  1186  zutty -fontpath /usr/share/fonts/X11/ -fontsize 20
>  1187  zutty -fontpath /usr/share/fonts/X11/ -font adobe
>  1190  zutty -fontpath /usr/share/fonts/X11/misc/ -fontsize 20
>  1191  zutty -fontpath /usr/share/fonts/X11/misc/ -fontsize 24
>  1192  zutty -fontpath /usr/share/fonts/X11/misc/ -fontsize 12
>  1193  zutty -font 9x20
>  1198  zutty -fontsize 10x20
>  1199  zutty -fontpath /usr/share/fonts/X11/misc/ -fontsize 10x20
>  1200  zutty -font 10x20
> 
> I clearly have fonts:
> 
> find /usr/share/fonts -print|grep "x20"
> /usr/share/fonts/X11/misc/10x20-ISO8859-9.pcf.gz
> /usr/share/fonts/X11/misc/10x20-ISO8859-3.pcf.gz
> /usr/share/fonts/X11/misc/10x20-ISO8859-11.pcf.gz

Use 'xlsfonts' to see what fonts are available and use those names.
I can get it working with "zutty -font 12x24" and other numerically named
fonts. Trying with something like 'lucidasans-24' will make it dump core
however.

Maybe it respects what you tell it via .Xresources or what the file used
to be called, when you had to configure fonts by sitting with xfontsel and
try and work out what would look decent. The manual pages for xterm should
have enough clues for how to configure that - I have already forgotten all
that stuff as it no longer is required with the more modern terminal
emulators.

> Nothing I have tried works, zutty always uses the same rather small
> font.
> 
> https://tomscii.sig7.se/zutty/doc/USAGE.html#Font%20selection
> 
> Has this package been implemented correctly?
> 
> aptitude show zutty
> Package: zutty   
> Version: 0.14.0.20230218+dfsg1-1
> 
> cat /etc/issue
> Debian GNU/Linux 12 \n \l

zutty is kind of only necessary when you want something *really*
lightweight and you do not need to worry about UTF-8. Just writing this
means a trip down memory lane and back to configuring CTWM on old Sun 5
workstations back in the 90's. If Debian still packages it, look for rxvt
instead, or use xterm. Both are well tried and well tested for when you
want something .. dated. ;)

-- 
Kind regards,

/S

Zutty fonts - zutty always uses the same font and fontsize

[Richmond]

I am puzzled by the zutty terminal emulator. I have tried:

 1186  zutty -fontpath /usr/share/fonts/X11/ -fontsize 20
 1187  zutty -fontpath /usr/share/fonts/X11/ -font adobe
 1190  zutty -fontpath /usr/share/fonts/X11/misc/ -fontsize 20
 1191  zutty -fontpath /usr/share/fonts/X11/misc/ -fontsize 24
 1192  zutty -fontpath /usr/share/fonts/X11/misc/ -fontsize 12
 1193  zutty -font 9x20
 1198  zutty -fontsize 10x20
 1199  zutty -fontpath /usr/share/fonts/X11/misc/ -fontsize 10x20
 1200  zutty -font 10x20

I clearly have fonts:

find /usr/share/fonts -print|grep "x20"
/usr/share/fonts/X11/misc/10x20-ISO8859-9.pcf.gz
/usr/share/fonts/X11/misc/10x20-ISO8859-3.pcf.gz
/usr/share/fonts/X11/misc/10x20-ISO8859-11.pcf.gz
...


Nothing I have tried works, zutty always uses the same rather small
font.

https://tomscii.sig7.se/zutty/doc/USAGE.html#Font%20selection

Has this package been implemented correctly?

aptitude show zutty
Package: zutty   
Version: 0.14.0.20230218+dfsg1-1

cat /etc/issue
Debian GNU/Linux 12 \n \l

Re: Looking for a good "default" font (small 'L' vs. capital 'i' problem)

[Christoph K.]

Hi Marco,
thanks for taking the time to reply.

Am Tue, 22 Aug 2023 20:24:39 +0200
schrieb Marco Möller :

> Having had the same problem to solve for myself I ended up to use:
> Noto sans for all my GUI
> Liberation Mono   for coding

The "Noto Sans" has an almost identical glyph for the capital 'i' and the
small 'L'. It's just a straight line and as such doesn't solve my problem.

Christoph

Re: Looking for a good "default" font (small 'L' vs. capital 'i' problem)

[Marco Möller]

On 19.08.23 21:19, Christoph K. wrote:

Could you please recommend a "suitable" sans-serif font that
a) (...)
b) (...)
c) (...)
d) (...)
Thanks,
Christoph


Having had the same problem to solve for myself I ended up to use:
Noto sans   for all my GUI
Liberation Mono for coding

Especially the "Liberation Mono" font is nicely readable for avoiding 
any letter misunderstanding when coding, and I tested much more 
problematic cases than only T71Iil15So0QOUuwWMNmn (this are just the 
ones I spontaneously remember). There are more Liberation fonts, but I 
didn't check them out. "Noto sans", which I selected already before for 
the GUI decorations, was already clear enough for that purpose.

Good luck!
Marco

Re: Looking for a good "default" font (small 'L' vs. capital 'i' problem)

[Michael Stone]

On Sat, Aug 19, 2023 at 09:19:48PM +0200, Christoph K. wrote:

Could you please recommend a "suitable" sans-serif font that


A lot of your criteria are rather subjective. For packaged fonts you 
might look at "hack" 
(https://source-foundry.github.io/Hack/font-specimen.html)

or "go"
(https://go.dev/blog/go-fonts)

There's also the not-packaged https://github.com/intel/intel-one-mono 


But you'd have to be the judge of what you like the look of.

Re: Looking for a good "default" font (small 'L' vs. capital 'i' problem)

[Charlie Gibbs]

On Mon Aug 21 16:23:25 2023 "Christoph K."  wrote:

> Am Sun, 20 Aug 2023 21:41:04 +
> schrieb "Russell L. Harris" :
>
>> On the 3, 5, 6, and 9, open the end of the loops, and shorten the
>> horizontal stroke on top of the 5 so the 5 is not mistaken for an S.
>> Always put horizontal strokes on I.  Make the 1 with a flag on the
>> upper end and put a horizontal stroke on the 7, German-style.  My
>> handwriting is a odd mixture of cursive script and printing.
>
> Thanks for sharing!
>
> Really interesting ... I'm already implementing all of these "rules".
> I learnt to write the 7 in German style because I live in Germany ;-)

Here on the west coast of Canada the stroke through the 7 isn't too
common, although I do see it from time to time.  I avoid it because
it makes a 7 look like certain script forms of the letter F (see the
Fender guitar logo, for instance).

> We also learned to put a "flag" on the 1 in school. I was surprised to
> see other people don't. To me it's quite confusing to see 1 just as a
> straight line.

When I was 8 years old I started writing the numeral 1 with the "flag".
I quickly stopped, because everyone confused it with 7.

This leaves the lower-case L.  It was a long time before this became
a problem, either because I didn't use them frequently or because
readers could figure it out from context.  (This was in my pre-computer
days.)  Now if there's a potential problem I'll put a little hook on
the bottom, similar to many computer fonts.  The vertical bar... well,
I'll either make it noticeably taller than other characters on the line,
or I'll write nearby 1s with both a flag and a bottom line.  It's a
bit of a compromise that I deal with on an individual basis.

> I don't remember when I startet to put bars on the 'I', probably
> during my studies of electrical engineering when we used lots of
> formulas.

I think I used them right from the beginning, so that wasn't a problem.

> I also have a "mixed handwriting" with some ligatures (for example on
> the double 'l'). For the small 's' I use two different glyphs (not on
> purpose) that usually depend on my mood. For a long time I wasn't even
> aware I was doing this :-)

Interesting.  I went through something like that when I started cursive
writing.  When writing a contraction I'd write the whole word and then
go back and place the apostrophe between the appropriate two letters -
except when writing "o'clock", where for some reason I would leave a
break after the "o".  Go figure.

--
/~\  Charlie Gibbs  |  Life is perverse.
\ /|  It can be beautiful -
 X   I'm really at ac.dekanfrus |  but it won't.
/ \  if you read it the right way.  |-- Lily Tomlin

Re: xterm font and other options

[Max Nikulin]

On 21/08/2023 16:16, Karl Vogel wrote:

On Sun, Aug 20, 2023 at 10:38:34PM -0400, Max Nikulin wrote:

Xterm configuration options may be put to ~/.Xresources, e.g.

xterm*VT100.faceName: ...

I am curious if there are actual advantages of usage a wrapper script
instead of xresources.

...

 # Don't override COLUMNS and LINES if already set; when my eyes are
 # tired, I use an xterm with characters two pixels larger:
 ##  FONT=xft:Cascadia:pixelsize=22:bold LINES=35 xt

 : ${COLUMNS=80}
 : ${LINES=40}


Thank you for clarification. Certainly it is aside from my use cases. 
Terminal applications usually occupy either the whole screen or its 
half, so I do not care concerning precise values of COLUMNS and LINES. 
Font size may be changed for a running instance of xterm through menu. I 
have not bothered to define keyboard shortcuts for that.


xterm*VT100.faceSize2: 7
xterm*VT100.faceSize3: 9
xterm*VT100.faceSize:  11
xterm*VT100.faceSize4: 11
xterm*VT100.faceSize5: 14
xterm*VT100.faceSize6: 18

There is another degree of freedom: -class. I still do not see 
advantages of $FONT over xterm*VT100.faceName as the default and -fa for 
ad-hoc override, but I admit it may be convenient for you.

Re: Looking for a good "default" font (small 'L' vs. capital 'i' problem)

[Richmond]

debian-u...@howorth.org.uk wrote:

> Cindy Sue Causey  wrote:
>> My own mind went to the place of thinking sans serif was about those
>> very lines. I just didn't make it to thinking that would make it hard
>> to find any alternate in that family. My long time preference is
>> developer-weary-eye-friendly fonts-anonymous-pro for whatever
>> applications will accept it. Found it accidentally a few years ago.
>> Its differences are noticeable enough that I instantly miss it on new
>> operating system installs. The "apt-cache show" description for
>> fonts-anonymous-pro specifically references both 0 v. O and I v. l v.
>> 1: "Description-en: fixed width font designed for coders This package
>> contains two Font Families. - Anonymous Pro - Anonomous Pro Minus .
>> 'Anonymous Pro' is a family of four fixed-width fonts designed
>> especially with coding in mind. Characters that could be mistaken for
>> one another (O, 0, I, l, 1, etc.) have distinct shapes to make them
>> easier to tell apart in the context of source code.
> Terminal fonts tend to be fixed width since that's a property of
> terminals. Fixed width fonts tend to have serifs because it's easier
> to make the spacing look more even between inherently narrow
> characters and inherently wide ones using details like serifs. So
> finding a sans serif font amongst terminal fonts is likely a difficult
> cause.

The font I have in Gnome terminal is called 'Monospace'. It doesn't have
serifs generally, but there is on I and l, and on J. And the 0 has a dot
in it.

The Gnome Tweaks program has a font selector which shows 'The quick
brown fox jumps over the lazy dog', searching for 'sans' I found only
'Noto Sans Mono Regular' which distinguished the I and l.

Re: Looking for a good "default" font (small 'L' vs. capital 'i' problem)

[Christoph K.]

Am Sun, 20 Aug 2023 21:41:04 +
schrieb "Russell L. Harris" :

> On the 3, 5, 6, and 9, open the end of the loops, and shorten the
> horizontal stroke on top of the 5 so the 5 is not mistaken for an S.
> Always put horizontal strokes on I.  Make the 1 with a flag on the
> upper end and put a horizontal stroke on the 7, German-style.  My
> handwriting is a odd mixture of cursive script and printing.

Thanks for sharing!

Really interesting ... I'm already implementing all of these "rules".
I learnt to write the 7 in German style because I live in Germany ;-)
We also learned to put a "flag" on the 1 in school. I was surprised to see
other people don't. To me it's quite confusing to see 1 just as a straight
line.

I don't remember when I startet to put bars on the 'I', probably during
my studies of electrical engineering when we used lots of formulas.

I also have a "mixed handwriting" with some ligatures (for example on the
double 'l'). For the small 's' I use two different glyphs (not on
purpose) that usually depend on my mood. For a long time I wasn't even
aware I was doing this :-)

Best regards,
Christoph

Re: xterm font and other options

[Karl Vogel]

On Sun, Aug 20, 2023 at 10:38:34PM -0400, Max Nikulin wrote:
> On 20/08/2023 14:55, Karl Vogel wrote:
> >  #!/bin/sh
> ...
> >  #   -fa 'xft:...'   font size and weight
> ...
> >  ( $XTERM $geo $topts -fa "$FONT" -title "Remote" ) &
> 
> Xterm configuration options may be put to ~/.Xresources, e.g.
> 
> xterm*VT100.faceName: ...
> 
> I am curious if there are actual advantages of usage a wrapper script
> instead of xresources.

  For me, being able to select or change a font based on an environment
  variable is very convenient.

  The script I included is simplified because I didn't want the post to
  get too long.  My production version has other conveniences:

# Don't override COLUMNS and LINES if already set; when my eyes are
# tired, I use an xterm with characters two pixels larger:
##  FONT=xft:Cascadia:pixelsize=22:bold LINES=35 xt

: ${COLUMNS=80}
: ${LINES=40}

  I can check a font and set LINES, COLUMNS, or geometry on the fly without
  having to mess with any configuration options.

-- 
Karl Vogel  I don't speak for the USAF or my company

Tent poles are not for pole dancing.  Please find
alternative ways to disappoint your father.  --seen on boredpanda.com

xterm font and other options

[Max Nikulin]

On 20/08/2023 14:55, Karl Vogel wrote:

 #!/bin/sh

...

 #   -fa 'xft:...'   font size and weight

...

 ( $XTERM $geo $topts -fa "$FONT" -title "Remote" ) &


Xterm configuration options may be put to ~/.Xresources, e.g.

xterm*VT100.faceName: ...

I am curious if there are actual advantages of usage a wrapper script 
instead of xresources.

Re: Looking for a good "default" font (small 'L' vs. capital 'i' problem)

[Tom Browder]

On Sun, Aug 20, 2023 at 15:45 James H. H. Lampert 
wrote:

> What Herr Rönnquist said.
> And given that I actually *do* set type with some regularity,

...

> (And for the record, my "go-to fonts" are all versions of Garamond.)


Wow, another Garamond lover! I do, too, love it (and bought a copy of
Adobe's version). I think Dr. Donald Knuth was the first person I may have
heard mention it.

How do you "set type" now? I have been "setting type" with Perl and raw
PostScript (then converting it to PDF) for many years.  I am now using Raku
PDF modules to "set type" directly in PDF documents. All CLI products.

-Tom

Re: Looking for a good "default" font (small 'L' vs. capital 'i' problem)

[Russell L. Harris]

On Sun, Aug 20, 2023 at 10:14:20PM +0200, Christoph K. wrote:

And I loathe fonts in which the numerals 3, 5, 6, and 9
are not radically different.


Interesting point. Didn't pay much attention to these numerals, yet.


Back in the 1970's, I ran across a detailed study of character shape
with respect to the problem of readability after photographic
reduction (microfilm and microfische) in hand-lettered engineering
drawings (24in x 36in).  Reading that study brought about a change in
my own handwriting.  The study was by a oil company; perhaps it was
Shell Oil.


That would be really interesting to read. Do you have any (more) hints on
how to find that study? Do you remember what change you did in your
handwriting?


If we (Texas, near Austin) end up with an Autumn with moderate
temperatures, I should have a copy in the boxes of papers stored in
the garage.  I need to sort and cull, anyway.  But within a few years
(circa A.D. 1980), computerized drafting was introduced and quickly
became dominant.  I think I was in the very last generation which
learned to letter by hand.

On the 3, 5, 6, and 9, open the end of the loops, and shorten the
horizontal stroke on top of the 5 so the 5 is not mistaken for an S.
Always put horizontal strokes on I.  Make the 1 with a flag on the
upper end and put a horizontal stroke on the 7, German-style.  My
handwriting is a odd mixture of cursive script and printing.

Years ago, in the days when you used pencil to write computer code on
a paper form, for conversion to punched cards by a keypunch operator,
I got used to writing zeros with a slash.  But if most of your writing
is numerals (as in spreadsheets), then you may prefer to slash the
alphabetic O.  


The keypunch operators used ``double-entry'' -- the code was typed a
second time by a different operator, to guard against error.  I read
somewhere that the double-entry scheme is used for obtaining an
accurate digital version of material which originally was typeset by
hand.  And, that better accuracy is obtained if the language of the
document is foreign to the typists.

RLH

Re: Looking for a good "default" font (small 'L' vs. capital 'i' problem)

[Christoph K.]

Am Sat, 19 Aug 2023 20:16:25 +
schrieb "Russell L. Harris" :

> I am concerned primarily with the distinction between numeral 1 and
> lower case L.

Of course, 'l' and 'I' was just the most prominent example.
Usually I look at 1lI|
(numeral one, small 'L' capital 'L', Pipe)


> And I loathe fonts in which the numerals 3, 5, 6, and 9
> are not radically different.

Interesting point. Didn't pay much attention to these numerals, yet.


> Back in the 1970's, I ran across a detailed study of character shape
> with respect to the problem of readability after photographic
> reduction (microfilm and microfische) in hand-lettered engineering
> drawings (24in x 36in).  Reading that study brought about a change in
> my own handwriting.  The study was by a oil company; perhaps it was
> Shell Oil.

That would be really interesting to read. Do you have any (more) hints on
how to find that study? Do you remember what change you did in your
handwriting?


> For Debian, I searched by opening EDIT > PREFERENCES > APPEARANCE in a
> terminal.  I currently am using `go mono regular'.  But `liberation
> mono regular' looks promising.

I do admit that I wasn't specific enough in my first question.
When I wrote "sans serif", I meant "a not serif font".
Actually I wasn't looking for a monospace font either
(but didn't state that explicitly).

For now "IBM Plex" seems to do a good job.

Thanks,
Christoph

Re: REeLooking for a good "default" font (small 'L' vs. capital 'i' problem)

[James H. H. Lampert]

Hmm. IBM Plex. Not bad-looking, and it does solve the stated problem.

I will note that like Bistream Swiss Monospaced, it's only *nominally* 
sans-serif, in that it has slab-serifs (Stymie-style, rather than 
Clarendon-style) on the capital I, and one small slab-serif on the 
lowercase l.


--
JHHL

Re: REeLooking for a good "default" font (small 'L' vs. capital 'i' problem)

[Christoph K.]

> Have a look at: https://github.com/IBM/plex
> it is very readable.
> Rolf
> 

Thank you, that's something I've been looking for.
There's even a debian package ...

apt-get install fonts-ibm-plex

... did do the job.

Best regards,
Christoph

Re: Looking for a good "default" font (small 'L' vs. capital 'i' problem)

[James H. H. Lampert]

What Herr Rönnquist said.

And given that I actually *do* set type with some regularity, I can say 
from experience that, with the exception of some monospaced examples 
that are only *nominally* sans-serif (e.g., Bitstream Swiss Monospaced), 
sans-serif fonts in which uppercase I and lowercase l are readily 
distinguishable are about as scarce as the proverbial hen's teeth, 
whether you're talking digital, photo, hot metal, foundry, or wood.


--
James H. H. Lampert

(And for the record, my "go-to fonts" are all versions of Garamond.)

Re: Looking for a good "default" font (small 'L' vs. capital 'i' problem)

[Frank]

Op 19-08-2023 om 21:19 schreef Christoph K.:

I'm unsatisfied with the default sans font in debian for use in the
graphical user interface (in my case XFCE).


To be honest, I've long since forgotten what the default is. I've used
Liberation Mono Regular everywhere in my Xfce DE for ages and I have
never mistaken an l for an I or vice versa.

Regards,
Frank

Re: Looking for a good "default" font (small 'L' vs. capital 'i' problem)

[Karl Vogel]

On Sat, Aug 19, 2023 at 03:29:22PM -0400, Christoph K. wrote:
> 
> I'm unsatisfied with the default sans font in debian for use in the
> graphical user interface (in my case XFCE).

I use BSD and Linux, and my eyesight sucks.  For console work (23" monitor
that's about 2 feet away) I use an Xterm with one of the following fonts
(in order of preference):

* xft:Menlo-Regular:pixelsize=20:bold
* xft:Cascadia:pixelsize=22:bold
* xft:Bitstream Vera Sans Mono:pixelsize=21:bold

For browsing (Firefox), my "prefs.js" file holds:

user_pref("browser.display.use_document_fonts", 0);
user_pref("font.default.x-western", "sans-serif");
user_pref("font.internaluseonly.changed", false);
user_pref("font.minimum-size.x-western", 18);
user_pref("font.name.monospace.x-western", "DejaVu Sans");
user_pref("font.name.sans-serif.x-western", "sans-serif");
user_pref("font.name.serif.x-western", "DejaVu Serif");
user_pref("font.size.fixed.x-western", 18);
user_pref("font.size.variable.x-western", 18);

Others I've liked:

* xft:Edlo:pixelsize=21:bold
* xft:FiraMono-Regular:pixelsize=22:bold
* xft:Inconsolata-Bold:pixelsize=25:bold
* xft:Meslo LG S:pixelsize=20:bold
    * xft:Meslo LG S:pixelsize=21:bold
* xft:UbuntuMono-B:pixelsize=25:bold

If you get your FONT setting from the environment, it's easy to experiment:

me% echo $FONT   
xft:Cascadia:pixelsize=20:bold

This script starts a new xterm with some tweaks to make it a little nicer:

#!/bin/sh
#https://invisible-island.net/archives/xterm/xterm-384.tgz
https://invisible-island.net/archives/xterm/xterm-384.tgz.asc

To build, unpack the source:

dest=/usr/local
export TERMINFO=/usr/local/share/terminfo

./configure  \
--disable-setgid \
--disable-setuid \
--enable-256-color   \
--enable-narrowproto \
--mandir=$dest/man   \
--with-x \
--with-own-terminfo=$TERMINFO
make
make check
make install

It comes with a nice terminfo file.  I've had problems with "tic" for
ncurses >= version 6, so I use the ncurses-5.9 version to compile it:

root# tic59 -V
ncurses 5.9.20110404

root# tic59 -s -o $TERMINFO terminfo

Hope this gives you some ideas.

-- 
Karl Vogel / vogelke AT pobox DOT com / I don't speak for anyone but myself

The Beatles: "I Get By with a Little Help From Depends"
--Re-released hits for an aging audience

Re: Looking for a good "default" font (small 'L' vs. capital 'i' problem)

[Nate Bargmann]

For a proportional font, Verdana, Regular seems to come close with, it
seems to me, good differentiation between l, I, and 1.  O and 0 are a
bit problematic as 0 is not dotted or slashed but is more of an ellipse.

On this GNOME desktop the interface is set to Cantarell, Regular, and
while it has a small serif at the bottom of l, I is simple vertical
line, and 1 has the customary serif at the top.  O and 0 are not well
differentiated except 0 being a slightly narrower oval.

There are times when I've pasted something like a random character
combination password into a terminal just so I could see what the exact
characters are.

In my terminals I have switched to Fira Code, Regular as well as in the
GNOME settings.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Looking for a good "default" font (small 'L' vs. capital 'i' problem)

[Tom Browder]

On Sat, Aug 19, 2023 at 16:15 Russell L. Harris 
wrote:

> bumper sticker:  DYSLEXICS UNTIE!


I concur on sans comments. You might take a look at the Free* fonts family
(Debian packages “fonts-freefont-ttf” and “fonts-freefont-otf”).

-Tom

REeLooking for a good "default" font (small 'L' vs. capital 'i' problem)

[Rolf Blum]

Have a look at: https://github.com/IBM/plex
it is very readable.
Rolf

Re: Looking for a good "default" font (small 'L' vs. capital 'i' problem)

[Russell L. Harris]

bumper sticker:  DYSLEXICS UNTIE!

Re: Looking for a good "default" font (small 'L' vs. capital 'i' problem)

[debian-user]

Cindy Sue Causey  wrote:

> My own mind went to the place of thinking sans serif was about those
> very lines. I just didn't make it to thinking that would make it hard
> to find any alternate in that family.
> 
> My long time preference is developer-weary-eye-friendly
> fonts-anonymous-pro for whatever applications will accept it. Found it
> accidentally a few years ago. Its differences are noticeable enough
> that I instantly miss it on new operating system installs.
> 
> The "apt-cache show" description for fonts-anonymous-pro specifically
> references both 0 v. O and I v. l v. 1:
> 
> "Description-en: fixed width font designed for coders
>  This package contains two Font Families.
>   - Anonymous Pro
>   - Anonomous Pro Minus
>  .
>  'Anonymous Pro' is a family of four fixed-width fonts designed
>  especially with coding in mind. Characters that could be mistaken for
>  one another (O, 0, I, l, 1, etc.) have distinct shapes to make them
>  easier to tell apart in the context of source code.

Terminal fonts tend to be fixed width since that's a property of
terminals. Fixed width fonts tend to have serifs because it's easier to
make the spacing look more even between inherently narrow characters
and inherently wide ones using details like serifs.

So finding a sans serif font amongst terminal fonts is likely a
difficult cause.

Re: Looking for a good "default" font (small 'L' vs. capital 'i' problem)

[Cindy Sue Causey]

On 8/19/23, Andreas Rönnquist  wrote:
> On Sat, 19 Aug 2023 21:19:48 +0200,
> Christoph K. wrote:
>>
>>I'm unsatisfied with the default sans font in debian for use in the
>>graphical user interface (in my case XFCE).
>>
>>My main concern with the default sans font (I guess it's Bitsream Vera,
>>but that doesn't really matter) is the the small 'L' and the capital 'i'
>>look the same (mostly).
>>
>>Everyone who has tried to read unknown characters (e.g. a password
>>generated automatically oder base64 encoded data) knows what pain it is to
>>distinguish these characters.
>>
>>Could you please recommend a "suitable" sans-serif font that
>>a) has "proper" 'l' and 'I' characters
>>
>
> I'm probably not the right person to answer, but doesn't the
> _sans_-serif requirement pretty much make this impossible? It means
> _without_ serifs, which are (according to wikipedia) "small line or
> stroke regularly attached to the end of a larger stroke in a letter or
> symbol within a particular font or family of fonts."
>
> Which to me seems like pretty much only way to separate a small 'l'
> from a big 'i',
>
> To me, without the serifs, both those characters are simply a line from
> top to bottom.


My own mind went to the place of thinking sans serif was about those
very lines. I just didn't make it to thinking that would make it hard
to find any alternate in that family.

My long time preference is developer-weary-eye-friendly
fonts-anonymous-pro for whatever applications will accept it. Found it
accidentally a few years ago. Its differences are noticeable enough
that I instantly miss it on new operating system installs.

The "apt-cache show" description for fonts-anonymous-pro specifically
references both 0 v. O and I v. l v. 1:

"Description-en: fixed width font designed for coders
 This package contains two Font Families.
  - Anonymous Pro
  - Anonomous Pro Minus
 .
 'Anonymous Pro' is a family of four fixed-width fonts designed
 especially with coding in mind. Characters that could be mistaken for
 one another (O, 0, I, l, 1, etc.) have distinct shapes to make them
 easier to tell apart in the context of source code.

Apparently my Firefox is using sans serif because I just typed that "l
v. I", and I can't tell them apart!

Found a new toy because of this thread. It's a presumably massive
online database that shows how fonts display in elaborate use cases. I
used their search feature to (hopefully) focus on sans serif:

https://fontsinuse.com/search/advanced?v=2&match0=all&keyword0=sans%20serif

Disclaimer: I dropped their categories down to perform CTRL+F for
"sans serif" and came up empty so maybe their search is focusing on
only sans.

That reminded me to reinstall font-manager before also mentioning it
(needed to make sure it was the right program). It's developed for
GNOME/Gtk+ but/and is working well on the LXQt desktop environment.

Font-manager is not just a font viewer. It presents a lot of
information that can make it a little overwhelming for a first time
visit into a program like it.

There's an option to install fonts through font-manager's GUI. I don't
have a test case to try first, but I do remember using it successfully
in the past, most likely while focused on typeface in GIMP.

An afterthought just came to mind. Fonts are being created to
specifically aid persons with dyslexia. Maybe a search on that will
land a desired user-friendly font..

Cindy :)
-- 
Talking Rock, Pickens County, Georgia, USA
* runs with birdseed *

Re: Looking for a good "default" font (small 'L' vs. capital 'i' problem)

[Russell L. Harris]

I am a XFCE user with a similar taste in fonts, but I have no need for
umlaut.

I am concerned primarily with the distinction between numeral 1 and
lower case L.  And I loathe fonts in which the numerals 3, 5, 6, and 9
are not radically different.  


Back in the 1970's, I ran across a detailed study of character shape
with respect to the problem of readability after photographic
reduction (microfilm and microfische) in hand-lettered engineering
drawings (24in x 36in).  Reading that study brought about a change in
my own handwriting.  The study was by a oil company; perhaps it was
Shell Oil.

For Debian, I searched by opening EDIT > PREFERENCES > APPEARANCE in a
terminal.  I currently am using `go mono regular'.  But `liberation
mono regular' looks promising.

RLH

--
He turneth rivers into a wilderness, and the watersprings into dry
ground; a fruitful land into barrenness, for the wickedness of them
that dwell therein. - Psalm 107:33-34

Re: Looking for a good "default" font (small 'L' vs. capital 'i' problem)

[Andreas Rönnquist]

On Sat, 19 Aug 2023 21:19:48 +0200,
Christoph K. wrote:

>Hi all,
>
>I'm unsatisfied with the default sans font in debian for use in the
>graphical user interface (in my case XFCE).
>
>My main concern with the default sans font (I guess it's Bitsream Vera,
>but that doesn't really matter) is the the small 'L' and the capital 'i'
>look the same (mostly).
>
>Everyone who has tried to read unknown characters (e.g. a password
>generated automatically oder base64 encoded data) knows what pain it is to
>distinguish these characters.
>
>Could you please recommend a "suitable" sans-serif font that
>a) has "proper" 'l' and 'I' characters
>

I'm probably not the right person to answer, but doesn't the
_sans_-serif requirement pretty much make this impossible? It means
_without_ serifs, which are (according to wikipedia) "small line or
stroke regularly attached to the end of a larger stroke in a letter or
symbol within a particular font or family of fonts."

Which to me seems like pretty much only way to separate a small 'l'
from a big 'i',

To me, without the serifs, both those characters are simply a line from
top to bottom.

But I'll admit that I'm far from an expert on the subject.

-- Andreas Rönnquist
mailingli...@gusnan.se
andr...@ronnquist.net

Looking for a good "default" font (small 'L' vs. capital 'i' problem)

[Christoph K.]

Hi all,

I'm unsatisfied with the default sans font in debian for use in the
graphical user interface (in my case XFCE).

My main concern with the default sans font (I guess it's Bitsream Vera,
but that doesn't really matter) is the the small 'L' and the capital 'i'
look the same (mostly).

Everyone who has tried to read unknown characters (e.g. a password
generated automatically oder base64 encoded data) knows what pain it is to
distinguish these characters.

Could you please recommend a "suitable" sans-serif font that
a) has "proper" 'l' and 'I' characters

b) looks harmonious on screen, even for small (8pt, 10pt) font sizes
   e.g. not too narrow, not too wide, no weird characters, etc.,
   maybe even beautiful, without being "artistic" / fancy
   (I noticed how different the interaction with my computer feels
   after changing fonts – and I really don't want to accept any font too
   stiff, too thin, etc.)

c) has german Umlaute and other regular "foreign language
   characters" (no need for a "large" range of Unicode support)

d) has no technical flaws
   (a lot of free fonts I tried do have weird quirks, like improper
   rendering in specific font sizes, missing characters when printing,
   etc. ("Signika" is an example of this))

I'm close to hiring a font designer to design a font according to my
needs, which – in some way – seems ridiculous to me :-)
(On the other hand I like the idea)

The fonts I tried so far and somewhat suit my needs are "Shanti" and
"Share". Both are a bit too narrow for my taste and Share definitly is
too "stiff".

I hope you have a good recommendation for me.

Thanks,
Christoph

Re: Thunderbird and font size used to display plain text e-mails?

[Virgo Pärna]

On Sun, 30 Apr 2023 14:26:12 -0600, D. R. Evans  wrote:
> I have TB configured so as to display incoming e-mail as plain text. They 
> display correctly, BUT the font used to display the contents in the third 
> pane 
> is too large on the new monitor. How *exactly* do I control the size of the 
> font used to display the contents of received plain text e-mails?
>

In Settings, General under Language & Appearance there is Fonts
& Colors. After it there is Advanced... button. There you can select
font face and font size and if plain text messages are shown in fixed
width. Especially check Latin and "Other Writing Systems". 

-- 
Virgo Pärna 
virgo.pa...@mail.ee

Re: Thunderbird and font size used to display plain text e-mails?

[Default User]

On Sun, 2023-04-30 at 14:26 -0600, D. R. Evans wrote:
> I have looked everywhere I can think of, and have been unable to find
> an 
> answer -- among the ridiculous number of ways that fonts appear to be
> controlled in Thunderbird -- that works for this issue :-(
> 
> I recently changed to a larger monitor, and, after lots of twiddling,
> have 
> more-or-less got most programs looking reasonably sensible. But
> Thunderbird is 
> being recalcitrant.
> 
> I am using TB 102.10.0, which is the current version in the debian
> stable 
> repositories, on 64-bit debian stable.
> 
> Here is the issue:
> 
> When I open TB, I see three panes: one runs the full height of the TB
> window, 
> and is on the left of the screen. It contains a list of the TB e-mail
> folders. 
> The remaining space is divided into two panes, one vertically above
> the other. 
> The second pane, the top one of these two, shows the subjects of
> received 
> e-mails in whatever folder is selected in the first pane. The third
> pane, 
> below the second one, is where the contents of e-mails are displayed.
> 
> I have TB configured so as to display incoming e-mail as plain text.
> They 
> display correctly, BUT the font used to display the contents in the
> third pane 
> is too large on the new monitor. How *exactly* do I control the size
> of the 
> font used to display the contents of received plain text e-mails?
> 
> That is:
> 
> --
> >  | |
> >  | |
> >  |     |
> >  |-|
> >  | | <- how to control font size
> >  | | <- in this pane??
> --
> 
>    Doc
> 


Hi, D.R.,

If I understand your question correctly, try this:

Click on the pane that shows the message contents, to select it. 
Then Ctrl + and Ctrl - let's you resize the contents of the pane,
bigger or smaller, respectively. 

Works on my Thunderbird, 102.10.0. 

HTH!

Thunderbird and font size used to display plain text e-mails?

[D. R. Evans]

I have looked everywhere I can think of, and have been unable to find an 
answer -- among the ridiculous number of ways that fonts appear to be 
controlled in Thunderbird -- that works for this issue :-(


I recently changed to a larger monitor, and, after lots of twiddling, have 
more-or-less got most programs looking reasonably sensible. But Thunderbird is 
being recalcitrant.


I am using TB 102.10.0, which is the current version in the debian stable 
repositories, on 64-bit debian stable.


Here is the issue:

When I open TB, I see three panes: one runs the full height of the TB window, 
and is on the left of the screen. It contains a list of the TB e-mail folders. 
The remaining space is divided into two panes, one vertically above the other. 
The second pane, the top one of these two, shows the subjects of received 
e-mails in whatever folder is selected in the first pane. The third pane, 
below the second one, is where the contents of e-mails are displayed.


I have TB configured so as to display incoming e-mail as plain text. They 
display correctly, BUT the font used to display the contents in the third pane 
is too large on the new monitor. How *exactly* do I control the size of the 
font used to display the contents of received plain text e-mails?


That is:

--
|  | |
|  | |
|  | |
|  |-|
|  | | <- how to control font size
|  | | <- in this pane??
--

  Doc

--
Web:  http://enginehousebooks.com/drevans

X server crashes when changing font size in LibreOffice / 'Failed to compile FS'

[Stefan Pietsch]

Dear list,

when enlarging text in LibreOffice Writer (e.g. 96pt) so that the characters 
fill the screen, the X server reproducibly crashes.
I'm running Debian sid with the package xorg-server
 21.1.7-1. Hardware is a ThinkPad T410 with integrated Intel graphics.



Xorg.0.log:
###


[   331.177] Failed to compile FS: 0:1(10): error: GLSL 1.30 is not supported. 
Supported versions are: 1.10, 1.20, and 1.00 ES



[   331.177] Program source:

#version 130

#ifdef GL_ES

precision mediump float;

#endif

#define RepeatNone0

#define RepeatNormal 1

#define RepeatPad2

#define RepeatReflect3

#define RepeatFix 10

uniform int source_repeat_mode;

uniform int mask_repeat_mode;

vec2 rel_tex_coord(vec2 texture, vec4 wh, int repeat)

{

vec2 rel_tex;

rel_tex = texture * wh.xy;

if (repeat == RepeatFix + RepeatNone)

return rel_tex;

else if (repeat == RepeatFix + RepeatNormal)

rel_tex = floor(rel_tex) + (fract(rel_tex) / wh.xy);

else if (repeat == RepeatFix + RepeatPad) {

if (rel_tex.x >= 1.0)

rel_tex.x = 1.0 - wh.z * wh.x / 2.;

else if (rel_tex.x < 0.0)

rel_tex.x = 0.0;

if (rel_tex.y >= 1.0)

rel_tex.y = 1.0 - wh.w * wh.y / 2.;

else if (rel_tex.y < 0.0)

rel_tex.y = 0.0;

rel_tex = rel_tex / wh.xy;

} else if (repeat == RepeatFix + RepeatReflect) {

if ((1.0 - mod(abs(floor(rel_tex.x)), 2.0)) < 0.001)

[   331.177] (EE)

Fatal server error:

[   331.177] (EE) GLSL compile failure

[   331.177] (EE)

[   331.177] (EE)

Please consult the The X.Org Foundation support

 at http://wiki.x.org

 for help.

[   331.177] (EE) Please also check the log file at "/var/log/Xorg.0.log" for 
additional information.

[   331.177] (EE)

[   331.177] (II) AIGLX: Suspending AIGLX clients for VT switch

[   331.243] (EE) Server terminated with error (1). Closing log file.






Disabling "glamor" with a configuration file in /etc/X11/xorg.conf.d/ solves 
this and the X server does not crash:


#

Section "Device"

Identifier ""

Driver "modesetting"

Option "Accelmethod" "none"

EndSection



Section "Module"

Disable "glamoregl"

EndSection


#



If anybody is experiencing the same issue, this is the upstream bug: 
https://gitlab.freedesktop.org/xorg/xserver/-/issues/1336
A fix has been merged recently: 
https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1066

I have not been able to test it yet.


Regards,
Stefan

Re: System Font

[Curt]

On 2022-11-02, David Wright  wrote:
>
> Perhaps try https://support.mozilla.org/en-US/questions/1239467
> though I don't understand their "Don't choose a value below 1.0 or
> about [is that above?] 4.0", because the value I have is -1.5
> (ie negative, and I didn't choose it).

My understanding is that an extreme value might render the address bar
unusable, in which case you'd be unable to change the parameter back
again to some more sensible value. 

> But I don't know what this would have to do with i3wm or Plasma,
> or anything else outside FF. (I don't use a DE so I can't check.)
>
> Cheers,
> David.
>
>


-- 

Re: System Font

[David Wright]

On Tue 01 Nov 2022 at 15:53:56 (-0400), pa...@quillandmouse.com wrote:
> Folks:
> 
> Typically, I use i3wm, but I just got through sampling Plasma. Somehow
> it has reduced/changed what I guess I'd call my "system font". This
> shows up in Firefox menus, Claws-Mail menus and others. I don't really
> care about the font, but the size must be increased. The following is
> the rundown of my fonts, from fc-match:
> 
> serif: DejaVuSerif.ttf: "DejaVu Serif" "Book"
> sans-serif: DejaVuSans.ttf: "DejaVu Sans" "Book"
> monospace: DejaVuSansMono.ttf: "DejaVu Sans Mono" "Book"
> Arial: LiberationSans-Regular.ttf: "Liberation Sans" "Regular"
> Helvetica: NimbusSans-Regular.otf: "Nimbus Sans" "Regular"
> Verdana: DejaVuSans.ttf: "DejaVu Sans" "Book"
> Times New Roman: LiberationSerif-Regular.ttf: "Liberation Serif" "Regular"
> Courier New: LiberationMono-Regular.ttf: "Liberation Mono" "Regular"
> 
> My ~/.config/fontconfig/fonts.conf has nothing about the above in it.
> I'm running Debian testing.
> 
> I'd like to know what file or files specify font size and such, and/or
> how to fix this.

Perhaps try https://support.mozilla.org/en-US/questions/1239467
though I don't understand their "Don't choose a value below 1.0 or
about [is that above?] 4.0", because the value I have is -1.5
(ie negative, and I didn't choose it).

But I don't know what this would have to do with i3wm or Plasma,
or anything else outside FF. (I don't use a DE so I can't check.)

Cheers,
David.

System Font

[paulf]

Folks:

Typically, I use i3wm, but I just got through sampling Plasma. Somehow
it has reduced/changed what I guess I'd call my "system font". This
shows up in Firefox menus, Claws-Mail menus and others. I don't really
care about the font, but the size must be increased. The following is
the rundown of my fonts, from fc-match:

serif: DejaVuSerif.ttf: "DejaVu Serif" "Book"
sans-serif: DejaVuSans.ttf: "DejaVu Sans" "Book"
monospace: DejaVuSansMono.ttf: "DejaVu Sans Mono" "Book"
Arial: LiberationSans-Regular.ttf: "Liberation Sans" "Regular"
Helvetica: NimbusSans-Regular.otf: "Nimbus Sans" "Regular"
Verdana: DejaVuSans.ttf: "DejaVu Sans" "Book"
Times New Roman: LiberationSerif-Regular.ttf: "Liberation Serif" "Regular"
Courier New: LiberationMono-Regular.ttf: "Liberation Mono" "Regular"

My ~/.config/fontconfig/fonts.conf has nothing about the above in it.
I'm running Debian testing.

I'd like to know what file or files specify font size and such, and/or
how to fix this.

Paul

-- 
Paul M. Foster
Personal Blog: http://noferblatz.com
Company Site: http://quillandmouse.com
Software Projects: https://gitlab.com/paulmfoster

Re: alpine font size

[Pierre Frenkiel]

On Wed, 2 Feb 2022, Pierre Frenkiel wrote:


hi,
I'm looking for a way to increase the font size in alpine (Debian buster).
I was unable to find an answer with google...


   I found the answer: just add "-fn 10x20" to the xterm call

best regards,
--
Pierre Frenkiel

Re: font-colour on a bullseye desktop: (too) white

[Greg Wooledge]

On Thu, Aug 19, 2021 at 02:22:23PM +0200, steef van duin wrote:
> i am sorry. it is a long time i was mailing to this list for help
> 
> 
> OK.  Now we know which terminal you use, and this*probably*  also means
> you're running XFCE as your desktop environment.  That will be useful
> information for the thread back on the mailing list.
> 
> yes, that is right  i am using xfce, last version

This was after steef accidentally replied to me privately.  I asked
them to please reply to the list instead.

One of the other details they said in their private message was that
they're not interested in changing the terminal fonts.  They want to
change the "fonts under the little pictures on the desktop".

Those "little pictures" are called icons, so we can try this search:

https://www.google.com/search?q=xfce4%20change%20icon%20font%20color

I got these results as my first two:

https://unix.stackexchange.com/questions/233483/change-xfce-desktop-font-color

https://forum.xfce.org/viewtopic.php?id=6553

font-colour on a bullseye desktop: (too) white

[steef van duin]

i am sorry. it is a long time i was mailing to this list for help


OK.  Now we know which terminal you use, and this*probably*  also means
you're running XFCE as your desktop environment.  That will be useful
information for the thread back on the mailing list.

yes, that is right  i am using xfce, last version

regards

steef
 

Re: font-colour on desktop

[Greg Wooledge]

On Thu, Aug 19, 2021 at 09:52:47AM +0200, steef van duin wrote:
> hi folks
> 
> a small problem for me in using bullseye: how can I change the colours of the 
> fonts on the desktop??

Start by figuring out which desktop environment (if any) you're
running.  I would think most of them have some sort of "control panel"
or similar configuration program/applet which you can launch and then
click on with a mouse.

If you can't find it by clicking through menus, then try a Google search
which includes the name of your desktop environment, and a few keywords
that describe what you want to do.

I'm wondering, actually, what you mean by "fonts on the desktop".  Most of
the time, when people talk of fonts, they actually mean fonts within a
terminal emulator or a web browser, since that's where they see the
most text.  It's hard for me to wrap my head around a request to change
the font colors within a web browser, because those are so obviously
controlled by the page author.  So I'm thinking you mean a terminal
emulator.

If that's true, then you need to identify which terminal emulator you're
using.  In some cases, it may be obvious -- the terminal emulator's name
may appear in the window's title bar, or in the menu from which you
launch the terminal.  In other cases, it may not be obvious.

If you're unsure, you can *try* running this command:

ps -fp $PPID

inside a shell in a terminal.  This will show you the shell's parent
process, which is typically the terminal emulator.  Not always, but it's
worth a try.

Once you know which terminal emulator it is, you can try Googling for how
to change the default foreground and/or background colors of that terminal.
There may be something you click on with a mouse, or there may be settings
you can put into your ~/.Xresources file, etc.  It all depends on the
terminal emulator.

font-colour on desktop

[steef van duin]

hi folks

a small problem for me in using bullseye: how can I change the colours of the 
fonts on the desktop??
(if possible)
thanks a lot

cheers,

steef
groningen

Re: Font color selection in MATE terminal

[Richmond]

Siard  writes:

> On Thu, 1 Jul 2021 22:37 -0700, Marc Shapiro wrote:
>> On 6/22/21 9:23 AM, Siard wrote:
>> > In the MATE Terminal settings (Edit > Profile Preferences),
>> > tab 'Colors', under 'Palette', set 'Built-in schemes' to 'Custom'
>> > and change every color in the color palette to black.
>> >
>> > Here is a screenshot:
>> > https://i.postimg.cc/2yv17y3Y/mateterminalcolors.png
>> 
>> Why select 'Custom'?
>> 
>> Richard needs black on white, so he should select 'Black on white'.
>> It works for me.  I have been using 'Custom', Yellow on Black, like
>> my first monitor many years ago.  But selecting 'Black on white'
>> gives exactly that.
>
> Yes, but it did not work for Richard, and as 'Custom' worked for me,
> I came with this solution.
> Later, it turned out that it was caused by a glitch in MATE Terminal
> 1.16.3, used in Debian 9.  Later versions worked fine.
> So 'Black on white' is indeed the most obvious way.

Strangely, I am using MATE terminal 1.20 and now it is not working. I
have a profile called Black and White. I change the colour profile
preferences to the black and white scheme, but when I launch emacs -nw,
it displays blue underlined text in places. And when I go back and look
at the colour preferences in MATE it has gone back to custom.

Re: Font color selection in MATE terminal

[Siard]

On Thu, 1 Jul 2021 22:37 -0700, Marc Shapiro wrote:
> On 6/22/21 9:23 AM, Siard wrote:
> > In the MATE Terminal settings (Edit > Profile Preferences),
> > tab 'Colors', under 'Palette', set 'Built-in schemes' to 'Custom'
> > and change every color in the color palette to black.
> >
> > Here is a screenshot:
> > https://i.postimg.cc/2yv17y3Y/mateterminalcolors.png
> 
> Why select 'Custom'?
> 
> Richard needs black on white, so he should select 'Black on white'.
> It works for me.  I have been using 'Custom', Yellow on Black, like
> my first monitor many years ago.  But selecting 'Black on white'
> gives exactly that.

Yes, but it did not work for Richard, and as 'Custom' worked for me,
I came with this solution.
Later, it turned out that it was caused by a glitch in MATE Terminal
1.16.3, used in Debian 9.  Later versions worked fine.
So 'Black on white' is indeed the most obvious way.

Re: Font color selection in MATE terminal

[Marc Shapiro]

On 6/22/21 9:23 AM, Siard wrote:

On Tue, 22 Jun 2021 17:32:55, Andrei POPESCU wrote:

On Ma, 22 iun 21, 08:14:08, Richard Owlett wrote:

I have vision problems.
I *MUST* have black on white text in all cases.
The program I'm running gives out colored text.
The MATE Help screen is NOT helpful.
Help please.

This has already been addressed before: you must change the color scheme
in the setting for MATE Terminal, to have it use black/dark gray/etc. as
needed for everything related to text.

The exact steps are different for each terminal emulator and I don't
have MATE Terminal installed here.

Well, I have. In the MATE Terminal settings (Edit > Profile Preferences),
tab 'Colors', under 'Palette', set 'Built-in schemes' to 'Custom' and
change every color in the color palette to black.

Here is a screenshot:
https://i.postimg.cc/2yv17y3Y/mateterminalcolors.png


Why select 'Custom'?

Richard needs black on white, so he should select 'Black on white'.  It 
works for me.  I have been using 'Custom', Yellow on Black, like my 
first monitor many years ago.  But selecting 'Black on white' gives 
exactly that.


Marc

Re: how to change terminal (tty) font?

[Curt]

On 2021-06-28, Long Wind  wrote:
>
> i rather put up with ugly font than imperfect fixanyway Thanks to all that 
> reply!
>  

For me it's unequivocally the contrary. But then I'm not a perfectionist
about picayune things and would rather see the entire picture a little
faultily than focus on an orthogonal detail with clarity in the name of
rigor. 

Good luck.

Re: how to change terminal (tty) font?

[Gene Heskett]

On Monday 28 June 2021 11:46:00 Curt wrote:

> On 2021-06-28, Gene Heskett  wrote:
> >> The workaround at the bottom of the thread is to create a service
> >> file that systematically deletes the cache at shutdown.
> >
> > That sucks unless its a gracefull shutdown, power failures don't
> > leave time to do that, so why not clean the cache early in the
> > bootup. Sheesh...
>
> Well, here's the (simple) user-created unit file at the bottom of the
> bug thread, and maybe it would be as easy as replacing "ExecStop" by
> "ExecStart" for your wish to be fulfilled (or maybe not, I'm
> unfamiliar with systemd unit files and how they get that way, to tell
> the truth).
>
> But if something as trivial as this can't be hacked effectively by our
> illustrious system administrators, we may as well just abandon ship.
>
>  [Unit]
>  Description=Cleanup console-setup cache
>
>  [Service]
>  Type=oneshot
>  RemainAfterExit=true
>  ExecStop=/bin/bash -c "rm /etc/console-setup/cached_*"
>
>  [Install]
>  WantedBy=multi-user.target
>
> > Cheers, Gene Heskett

Welp, I expect you know more about it than I but if it works, the below 
looks like a suitable fix until some sanity infects the author(s). That 
doesn't alway act infectious though.

But "Illustrious System Administrators" are usually found in the mirror, 
and while I may have such a rep, its not always in the nuances of linux. 
Broadcast Engineering is a much better looking horse for me.

All I was trying to do was point out the folly of doing it as part of a 
gracefull shutdown. This is one of two boxes with a ups, all 4 of the 
others, are expected to survive a power failure, which they all did last 
evening for 15 seconds. Out of a quiet evening with clear blue skies. 
Funny part was that 15 seconds should have started the 20kw standby in 
the back yard but it did not. Still scratching my thinning grey hair 
over that.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: how to change terminal (tty) font?

[Curt]

On 2021-06-28, Gene Heskett  wrote:
>>
>> The workaround at the bottom of the thread is to create a service file
>> that systematically deletes the cache at shutdown.
>
> That sucks unless its a gracefull shutdown, power failures don't leave 
> time to do that, so why not clean the cache early in the bootup. 
> Sheesh...

Well, here's the (simple) user-created unit file at the bottom of the
bug thread, and maybe it would be as easy as replacing "ExecStop" by
"ExecStart" for your wish to be fulfilled (or maybe not, I'm unfamiliar
with systemd unit files and how they get that way, to tell the truth).

But if something as trivial as this can't be hacked effectively by our
illustrious system administrators, we may as well just abandon ship.

 [Unit]
 Description=Cleanup console-setup cache

 [Service]
 Type=oneshot
 RemainAfterExit=true
 ExecStop=/bin/bash -c "rm /etc/console-setup/cached_*"

 [Install]
 WantedBy=multi-user.target

> Cheers, Gene Heskett

Re: how to change terminal (tty) font?

[Gene Heskett]

On Monday 28 June 2021 08:19:37 Curt wrote:

> On 2021-06-28, Brian  wrote:
> > On Mon 28 Jun 2021 at 11:20:12 -, Curt wrote:
> >> On 2021-06-28, Long Wind  wrote:
> >> > Thank IL Ka and Cater!i've run console-setup,
> >> > but it's not persistent, after reboot, it uses ugly font again
> >> > PS: i reply a little late, because yahoo is partially blocked
> >>
> >> Looks like this four-year-old bug:
> >>
> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857132
> >
> > A distinct possibility. I wonder whether executing 'setupcon' after
> > rebooting restores the wanted terminal font?
>
> The workaround at the bottom of the thread is to create a service file
> that systematically deletes the cache at shutdown.

That sucks unless its a gracefull shutdown, power failures don't leave 
time to do that, so why not clean the cache early in the bootup. 
Sheesh...

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

Re: how to change terminal (tty) font?

[Curt]

On 2021-06-28, Brian  wrote:
> On Mon 28 Jun 2021 at 11:20:12 -, Curt wrote:
>
>> On 2021-06-28, Long Wind  wrote:
>> >
>> >  
>> > Thank IL Ka and Cater!i've run console-setup, 
>> > but it's not persistent, after reboot, it uses ugly font again
>> > PS: i reply a little late, because yahoo is partially blocked
>> >
>> 
>> Looks like this four-year-old bug:
>> 
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857132
>
> A distinct possibility. I wonder whether executing 'setupcon' after
> rebooting restores the wanted terminal font?
>

The workaround at the bottom of the thread is to create a service file
that systematically deletes the cache at shutdown.

Re: how to change terminal (tty) font?

[Brian]

On Mon 28 Jun 2021 at 11:20:12 -, Curt wrote:

> On 2021-06-28, Long Wind  wrote:
> >
> >  
> > Thank IL Ka and Cater!i've run console-setup, 
> > but it's not persistent, after reboot, it uses ugly font again
> > PS: i reply a little late, because yahoo is partially blocked
> >
> 
> Looks like this four-year-old bug:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857132

A distinct possibility. I wonder whether executing 'setupcon' after
rebooting restores the wanted terminal font?

-- 
Brian.

Re: how to change terminal (tty) font?

[Curt]

On 2021-06-28, Long Wind  wrote:
>
>  
> Thank IL Ka and Cater!i've run console-setup, 
> but it's not persistent, after reboot, it uses ugly font again
> PS: i reply a little late, because yahoo is partially blocked
>

Looks like this four-year-old bug:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857132