Why is tab unaffected by font whereas space is affected?

[Tex]

I always thought the BEL sound should Doppler shift when the font character width expanded, so that it was deeper and lasted longer. Skinny fonts should be more of a chirp.

 

 

 

From: Unicode [mailto:unicode-bounces at unicode.org] On Behalf Of Asmus Freytag via Unicode
Sent: Sunday, April 19, 2020 2:36 PM
To: unicode at unicode.org
Subject: Re: Why is tab unaffected by font whereas space is affected?

 

On 4/18/2020 7:30 PM, Eli Zaretskii via Unicode wrote:

Date: Sat, 18 Apr 2020 15:26:13 -0700
From: Jonathan Coxhead via Unicode  <mailto:unicode at unicode.org> <unicode at unicode.org>
 
   Surely the reason is that tab is a control character, but space is a printing character.

 
No.  On a GUI display, Emacs shows a TAB as a stretch of white space
of a suitable width, not as a string of space characters.

On a GUI display, no whitespace character is a rendered glyph. All are effectively control functions.

However, for the spaces, the font would be queried for width and the layout would advance by that width (after it's been adjusted perhaps by processes such as justification).

TAB requests that layout proceed from the next tab position beyond the width of the already laid out text.

The locations of tab positions are not defined locally, inline, as is the amount to advance for a space character. Instead, there is an explicit or implicit property for the block of text (paragraph). If specific tab positions have not been provided (via user input, document temaplat or whatever), it's common to assume a regular grid of default positions.

There is no standard for choosing these, but setting them apart by 5 or 8 times the typical width of a space character seems a common choice.

Now, on the typewriter, where this technology originated, the widths of all characters, including spaces were fixed, and except for later advances like the IBM Selectric, there was also only ever a single typeface per machine.

Even for plaintext editors, it's possible nowadays to globally change fonts (and sizes), so it's not surprising to see such choices affect the default tab positioning, as it appears to do in Emacs. This behavior is however still a "fallback" to the case of a full-featured text display, where tab stops and fonts can be explicitly set (per paragraph and per font-run respectively).

Just because it's proven a useful workaround to scale default tab positions based on font size and typical width (using the space character as a proxy) it does not follow that tab-stop positioning is now a per-font run property. It is not.

A./

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://corp.unicode.org/mailman/private/unicode/attachments/20200419/60e20598/attachment.htm>