Why is tab unaffected by font whereas space is affected?

Asmus Freytag (c) asmusf at ix.netcom.com
Wed Apr 22 21:30:05 CDT 2020


On 4/22/2020 5:13 PM, Kent Karlsson wrote:
>
>
>> 20 apr. 2020 kl. 22:48 skrev Asmus Freytag via Unicode 
>> <unicode at unicode.org <mailto:unicode at unicode.org>>:
>>
>> On 4/20/2020 7:36 AM, Eli Zaretskii via Unicode wrote:
>>>> In summary, tab stops are at particular positions in a displayed line of text, and do not depend on
>>>> font changes, or font size changes. In some contexts one can set the tab stops (not just using
>>>> default positions), and they ”stay” over font changes and font size changes, until tab stops are
>>>> (re)set by a tab setting ”command” (or paragraph property, or similar mechanism, depending
>>>> on system).
>>> That would mean, for example, that if you make the font smaller, the
>>> tab stops stay in the same positions, pixel-wise?  isn't that strange?
>>>
>> No, that's how every word processor and text layout system has worked 
>> from day one (except apparently programming editors).
>>
>> On typewriters, if your machine had adjustable tabs, you could change 
>> your mind about tab stop positions at any time while in the middle of 
>> a line.
>>
> For a manual (non-electric) typewriter I once had, that was true. (I 
> did not keep it, which I now regret…)
>
> For the Diablo typewriter terminal (Diablo 1620), yes I have used one, 
> it had *no* tab stops set at power-up (it then moved the print 
> position to the ”far right” when outputting a tab character). One 
> /had/ to *explicitly* set tab stops (with proprietary escape 
> sequences) to get any tab stops. So I would agree that having some 
> default tab stops is handy...
>>
>> But generally, in rich text environment, these are properties of 
>> blocks of text (paragraphs) and don't track with font size.
>>
> Indeed (in principle, not so sure tab stops need be bundled with 
> paragraph properties). But one can say like this:
>
>   * changing the *default* font (typeface and/or em size), as a
>     /preference/ setting that apply ”globally” (i.e. not just to a
>     text ”run” (substring), for some notion of ”globally"), if the
>     application allows for such a preference setting:
>       o that may imply a change of /default/ tab stops (and some
>         applications might have only the default tab stops, not any
>         explicitly set ones).
>
>
> So in this case one can eat the cake and have it too… Changing the 
> *default font *preference** (implicitly changing default tab 
> stops ”globally”, but not changing any explicitly set tab stops) is 
> different from changing the *font for a text *run** (which would never 
> change any tab stops, whether default or explicit). (For emacs, there 
> would only be the (currently set) default font, and (the currently 
> set) default tab stops. A ”word processor” may or may not allow user 
> setting of the /default/ font as a preference.)
>
Such global properties work well for uni-font displays like programming 
editors, notepad etc. where there's a corresponding single, global font 
setting. At that point, letting the font choice influence the 
"step-width" for the tab stop isn't too far fetched. But it would be a 
very specific use case and one that doesn't generalize well to editing 
rich text documents.

A./

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://corp.unicode.org/mailman/private/unicode/attachments/20200422/267eb8f9/attachment-0001.htm>


More information about the Unicode mailing list