Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #184542 > unrolled thread

Arial vs. Helvetica.

Back to article view | Back to linux.debian.user

Contents

  Arial vs. Helvetica. peter@easthope.ca - 2017-08-02 16:40 +0200
    Re: Arial vs. Helvetica. <tomas@tuxteam.de> - 2017-08-02 16:50 +0200
    Re: Arial vs. Helvetica. Joe <joe@jretrading.com> - 2017-08-02 17:40 +0200
      Re: Arial vs. Helvetica. Martin Read <zen75502@zen.co.uk> - 2017-08-03 10:30 +0200
        Fonts readability (was: Arial vs. Helvetica.) Nicolas George <george@nsup.org> - 2017-08-03 14:30 +0200
          Re: Fonts readability (was: Arial vs. Helvetica.) rhkramer@gmail.com - 2017-08-03 15:50 +0200
            Re: Fonts readability (was: Arial vs. Helvetica.) Nicolas George <george@nsup.org> - 2017-08-03 17:40 +0200
              Re: Fonts readability (was: Arial vs. Helvetica.) rhkramer@gmail.com - 2017-08-04 15:00 +0200
                Re: Fonts readability (was: Arial vs. Helvetica.) Jude DaShiell <jdashiel@panix.com> - 2017-08-04 15:40 +0200
          Re: Fonts readability (was: Arial vs. Helvetica.) Henrique de Moraes Holschuh <hmh@debian.org> - 2017-08-03 18:00 +0200
    Re: Arial vs. Helvetica. Felix Miata <mrmazda@earthlink.net> - 2017-08-03 22:50 +0200

#184542 — Arial vs. Helvetica.

I want to specify a variable pitch font in a wiki. The font should be 
widely available and acceptable to commonly used browsers.  
https://en.wikipedia.org/wiki/Arial explains, "It [Arial] was created 
to be metrically identical to the popular typeface Helvetica, with all 
character widths identical, so that a document designed in Helvetica 
could be displayed and printed correctly without having to pay for a 
Helvetica license."  That suggests that Arial is a good choice.  
Conversely, font substitution appears to be handled well in many 
contexts and licensing might no longer be a concern.

What is the conclusion.  Should I specify, Arial or Helvetica or 
something else?

 Thanks,                               ... Peter E.
  



-- 

123456789 123456789 123456789 123456789 123456789 123456789 123456789
Tel: +1 360 639 0202                      Pender Is.: +1 250 629 3757
http://easthope.ca/Peter.html              Bcc: peter at easthope. ca

[toc] | [next] | [standalone]

#184543

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Aug 02, 2017 at 06:26:13AM -0700, peter@easthope.ca wrote:
> I want to specify a variable pitch font in a wiki. The font should be 
> widely available and acceptable to commonly used browsers.  

See [1]. My take is: use first generic font families: the browser
will substitute something close. The less you force your users to
"see" something the way you see it, the better.

If you want to be more specific, tend to one of the "safe"
families. Browsers are supposed to have that on-board.

If your work is a "typographical work of art" and you do want one
concrete font, try to find a free one.

Take into account that if your user's browser has to download
the font it costs time and exposes your user to some information
leakage (unless you yourself serve the font).

[1] https://en.wikipedia.org/wiki/Web_typography

regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlmB5akACgkQBcgs9XrR2kaiSwCffFLgH5WkhCwgQ/eXjA7n0Tk2
LP4An12vV5cymrs2R2Q8uaJhwmEBt98N
=vzkg
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#184545

On Wed, 02 Aug 2017 06:26:13 -0700
peter@easthope.ca wrote:

> I want to specify a variable pitch font in a wiki. The font should be 
> widely available and acceptable to commonly used browsers.  
> https://en.wikipedia.org/wiki/Arial explains, "It [Arial] was created 
> to be metrically identical to the popular typeface Helvetica, with
> all character widths identical, so that a document designed in
> Helvetica could be displayed and printed correctly without having to
> pay for a Helvetica license."  That suggests that Arial is a good
> choice. Conversely, font substitution appears to be handled well in
> many contexts and licensing might no longer be a concern.
> 
> What is the conclusion.  Should I specify, Arial or Helvetica or 
> something else?
> 

Does your wiki software require one specific named font, without
allowing you to tweak the CSS for it if you wish? Does it not have a
'sans-serif' value available, which will call for a browser to use its
default sans-serif font? 

If you can customise the CSS for the text elements, you can specify
multiple font families in order of preference 

e.g.   font-family: "Times New Roman", Times, serif;

Incidentally, serifs were invented to make blocks of text easier to
read, so Times or similar would be a better choice for paragraphs, with
a sans-serif font more suited to bold headings. Newspaper sites (not
surprisingly including The Times) use serif fonts.

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#184562

On 02/08/17 16:34, Joe wrote:
> Incidentally, serifs were invented to make blocks of text easier to
> read, so Times or similar would be a better choice for paragraphs, with
> a sans-serif font more suited to bold headings. Newspaper sites (not
> surprisingly including The Times) use serif fonts.

On a computer screen, I tend to find that sans or quasi-sans (e.g. fonts 
where 'I' and 'l' have serifs but other letters mostly don't) fonts are 
more comfortable to read (and, in particular, hold up better at small 
point sizes).

[toc] | [prev] | [next] | [standalone]

#184563 — Fonts readability (was: Arial vs. Helvetica.)

[Multipart message — attachments visible in raw view] — view raw

Le sextidi 16 thermidor, an CCXXV, Martin Read a écrit :
> On a computer screen, I tend to find that sans or quasi-sans (e.g. fonts
> where 'I' and 'l' have serifs but other letters mostly don't) fonts are more
> comfortable to read (and, in particular, hold up better at small point
> sizes).

At small point sizes, the bitmap fonts still beat the vectorial fonts in
terms of readability.

For my XTerms, I use courR12.pcf.gz from xfonts-75dpi, aka
-adobe-courier-medium-r-normal--12-120-75-75-m-70-iso10646-1; its glyphs
are 7×13 pixels. I would not change it for a vectorial font. I sometimes
also use 7x13.pcf.gz from xfonts-base, aka
-misc-fixed-medium-r-normal--13-120-75-75-c-70-iso10646-1 because it is
more complete.

Notice that -adobe-courier-* is a serif font while -misc-fixed- is a
sans-serif font. But I find -adobe-courier-* much more readable,
especially for long text (and when I say long, I mean MBOTF-long).

Another point where the bitmap fonts beat the vectorial fonts at tiny
sizes: you usually want your vectorial fonts anti-aliased, but at tiny
sizes it hurts readability. Even worse, the anti-aliasing is done wrong:
it is done without taking gamma correction into account. That means that
when 50% intensity is wanted, it produces 22% intensity instead:
black-on-white is too thick, white-on-black is too thin.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#184570 — Re: Fonts readability (was: Arial vs. Helvetica.)

On Thursday, August 03, 2017 08:23:37 AM Nicolas George wrote:
> Even worse, the anti-aliasing is done wrong:
> it is done without taking gamma correction into account. That means that
> when 50% intensity is wanted, it produces 22% intensity instead:
> black-on-white is too thick, white-on-black is too thin.

Thank you for confirming something I suspected for a long time.

Do you know what program(s) is responsibe for the anti-aliasing, against which 
a bug might be filed (or maybe a bug has already been filed)?

[toc] | [prev] | [next] | [standalone]

#184579 — Re: Fonts readability (was: Arial vs. Helvetica.)

[Multipart message — attachments visible in raw view] — view raw

Le sextidi 16 thermidor, an CCXXV, rhkramer@gmail.com a écrit :
> > Even worse, the anti-aliasing is done wrong:
> > it is done without taking gamma correction into account. That means that
> > when 50% intensity is wanted, it produces 22% intensity instead:
> > black-on-white is too thick, white-on-black is too thin.
> 
> Thank you for confirming something I suspected for a long time.
> 
> Do you know what program(s) is responsibe for the anti-aliasing,
> against which a bug might be filed (or maybe a bug has already been
> filed)?

It is hard to tell, there are several components working together, and
they all will try to shift the blame to each other. I tried filling it
years ago, and it gave me that:

http://bugs.freedesktop.org/show_bug.cgi?id=13431

If somebody dares tell me that the way of reading text that I chose is
"wrong", I think it is worthless to try to discuss.

The components in play are:

- fontconfig: at some point, the user needs to be able to tell that
  gamma correction must be taken into account and what the gamma value
  should be. Despite what kp wrote, it belongs in fontconfig, just as
  much as lcdfilter or rgba.

- Freetype: it is the component that rasterizes the vector fonts,
  including anti-aliasing, so it would be an easy place to adjust for
  gamma. Unfortunately, Freetype does not know the color of the text and
  background, its output could be considered an alpha map.

- The X11 RENDER extension: it is the component that performs the alpha
  blending. It would be the correct place to implement the gamma
  adjustment. Unfortunately, it has no provisions to do so.

- Xft: it is the glue that holds everything together. I do not think it
  needs any work for this issue.

Good luck if you want to get things moving.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#184631 — Re: Fonts readability (was: Arial vs. Helvetica.)

Thanks for the reply!

It looks like you're right--getting this changed sounds like paddling upstream 
against a fairly high current!

On Thursday, August 03, 2017 11:30:35 AM Nicolas George wrote:
> Le sextidi 16 thermidor, an CCXXV, rhkramer@gmail.com a écrit :
> > > Even worse, the anti-aliasing is done wrong:
> > > it is done without taking gamma correction into account. That means
> > > that when 50% intensity is wanted, it produces 22% intensity instead:
> > > black-on-white is too thick, white-on-black is too thin.
> > 
> > Thank you for confirming something I suspected for a long time.
> > 
> > Do you know what program(s) is responsibe for the anti-aliasing,
> > against which a bug might be filed (or maybe a bug has already been
> > filed)?
> 
> It is hard to tell, there are several components working together, and
> they all will try to shift the blame to each other. I tried filling it
> years ago, and it gave me that:
> 
> http://bugs.freedesktop.org/show_bug.cgi?id=13431
> 
> If somebody dares tell me that the way of reading text that I chose is
> "wrong", I think it is worthless to try to discuss.
> 
> The components in play are:
> 
> - fontconfig: at some point, the user needs to be able to tell that
>   gamma correction must be taken into account and what the gamma value
>   should be. Despite what kp wrote, it belongs in fontconfig, just as
>   much as lcdfilter or rgba.
> 
> - Freetype: it is the component that rasterizes the vector fonts,
>   including anti-aliasing, so it would be an easy place to adjust for
>   gamma. Unfortunately, Freetype does not know the color of the text and
>   background, its output could be considered an alpha map.
> 
> - The X11 RENDER extension: it is the component that performs the alpha
>   blending. It would be the correct place to implement the gamma
>   adjustment. Unfortunately, it has no provisions to do so.
> 
> - Xft: it is the glue that holds everything together. I do not think it
>   needs any work for this issue.
> 
> Good luck if you want to get things moving.
> 
> Regards,

[toc] | [prev] | [next] | [standalone]

#184634 — Re: Fonts readability (was: Arial vs. Helvetica.)

Understand since I've never seen anything in this life I cannot state 
what I'm about to from personal experience.  However while I worked for 
the Navy, one day the building in which I worked had a short meeting and 
it was recommended by management that everybody switch over to Lucida 
Bright font since it was the most readable font available within windows 
at that time.  If anyone needs an alternative and this font is available 
it may be worth a try.

On Fri, 4 Aug 2017, rhkramer@gmail.com wrote:

> Date: Fri, 4 Aug 2017 08:51:56
> From: rhkramer@gmail.com
> To: debian-user@lists.debian.org
> Subject: Re: Fonts readability (was: Arial vs. Helvetica.)
> Resent-Date: Fri,  4 Aug 2017 12:52:14 +0000 (UTC)
> Resent-From: debian-user@lists.debian.org
> 
> Thanks for the reply!
>
> It looks like you're right--getting this changed sounds like paddling upstream
> against a fairly high current!
>
> On Thursday, August 03, 2017 11:30:35 AM Nicolas George wrote:
>> Le sextidi 16 thermidor, an CCXXV, rhkramer@gmail.com a ?crit :
>>>> Even worse, the anti-aliasing is done wrong:
>>>> it is done without taking gamma correction into account. That means
>>>> that when 50% intensity is wanted, it produces 22% intensity instead:
>>>> black-on-white is too thick, white-on-black is too thin.
>>>
>>> Thank you for confirming something I suspected for a long time.
>>>
>>> Do you know what program(s) is responsibe for the anti-aliasing,
>>> against which a bug might be filed (or maybe a bug has already been
>>> filed)?
>>
>> It is hard to tell, there are several components working together, and
>> they all will try to shift the blame to each other. I tried filling it
>> years ago, and it gave me that:
>>
>> http://bugs.freedesktop.org/show_bug.cgi?id=13431
>>
>> If somebody dares tell me that the way of reading text that I chose is
>> "wrong", I think it is worthless to try to discuss.
>>
>> The components in play are:
>>
>> - fontconfig: at some point, the user needs to be able to tell that
>>   gamma correction must be taken into account and what the gamma value
>>   should be. Despite what kp wrote, it belongs in fontconfig, just as
>>   much as lcdfilter or rgba.
>>
>> - Freetype: it is the component that rasterizes the vector fonts,
>>   including anti-aliasing, so it would be an easy place to adjust for
>>   gamma. Unfortunately, Freetype does not know the color of the text and
>>   background, its output could be considered an alpha map.
>>
>> - The X11 RENDER extension: it is the component that performs the alpha
>>   blending. It would be the correct place to implement the gamma
>>   adjustment. Unfortunately, it has no provisions to do so.
>>
>> - Xft: it is the glue that holds everything together. I do not think it
>>   needs any work for this issue.
>>
>> Good luck if you want to get things moving.
>>
>> Regards,
>
>

-- 

[toc] | [prev] | [next] | [standalone]

#184581 — Re: Fonts readability (was: Arial vs. Helvetica.)

On Thu, 03 Aug 2017, Nicolas George wrote:
> Another point where the bitmap fonts beat the vectorial fonts at tiny
> sizes: you usually want your vectorial fonts anti-aliased, but at tiny
> sizes it hurts readability. Even worse, the anti-aliasing is done wrong:
> it is done without taking gamma correction into account. That means that
> when 50% intensity is wanted, it produces 22% intensity instead:
> black-on-white is too thick, white-on-black is too thin.

Professional, high-quality fonts *optimized for small sizes* will have
specific glyph variations and "rendering rules" for the small sizes, and
do not suffer from the annoying misplaced anti-aliasing effects (i.e.
they will render about as nicely as a pixel-optimized bitmapped font).

However that also requires that the font rendering engine do it
perfectly (which in turn requires it to implement everything required,
for whatever is using it to *enable* all of that and not screw it up
when blitting the result, etc).

So, I am not at all surprised that it is far easier to get better
results for small sizes and terminal fonts using bitmapped fonts :-)  It
should be much faster for the terminal to use the bitmapped ones, too.

-- 
  Henrique Holschuh

[toc] | [prev] | [next] | [standalone]

#184604

peter@easthope.ca composed on 2017-08-02 06:26 (UTC-0700):

> I want to specify a variable pitch font in a wiki. The font should be 
> widely available and acceptable to commonly used browsers.  
> https://en.wikipedia.org/wiki/Arial explains, "It [Arial] was created 
> to be metrically identical to the popular typeface Helvetica, with all 
> character widths identical, so that a document designed in Helvetica 
> could be displayed and printed correctly without having to pay for a 
> Helvetica license."  That suggests that Arial is a good choice.  
> Conversely, font substitution appears to be handled well in many 
> contexts and licensing might no longer be a concern.

> What is the conclusion.  Should I specify, Arial or Helvetica or 
> something else?

Something else:

	sans-serif

For the first Internet decade at least, Arial was the default sans-serif font on
Windows, and Helvetica(Neue) was the default sans-serif on Mac. Arial is a
functional clone of Helvetica, both of which are scalable font types. The
defaults may have since changed, but those two will still be available, and if
the defaults were changed, either by Microsoft or Apple, or /users/ (which has
always been a principle of the personalization of personal computing devices),
the change would have been for the better, meaning good if not excellent choice
for the user's environment. Linux users have often been able to install the
Windows fonts, but those who haven't have nevertheless been supplied with metric
equivalents (e.g. Liberation Sans), so also find their defaults to be suitable.
Licensing issues are only of concern on the user end, unless your documents are
using embedded fonts that are limited by license.

Wiki software tends to differ rather little from styles create by stylists
themselves by including similarly long styles in their various themes.

All that said, too few web stylists style fonts so simply. It's typical to see
font declaration lists too long to fit an 80 character window, over-controlling,
which typically means the optimal font for the stylist, and too commonly
blocking the font that the user or his OS vendor has determined to be optimal.
Additionally, all modern browsers provide stylists support for web fonts
downloaded along with the markup, styles and scripts, instead of being limited
to fonts already installed on the users' systems. An example would be
<link href='http://fonts.googleapis.com/css?family=Russo+One' rel='stylesheet'
type='text/css'>
included in the HTML document head and 'russo one' among the document's styles.

It ultimately comes down to how much control you feel is appropriate to impose.
Just remember users can veto everything by disabling styles, or override
particular styles via browser add-ons or CSS customization. In theory, CSS
styles are merely suggestions.
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

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

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web