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