tab width

> On 09-05-2016, at 3:26 PM, Eliot Miranda <[hidden email]> wrote:
>     how do people think about the minimum tab with being a pixel?  I think this is wrong and should be a space.

Depends on what you see a tab as meaning I guess.

If, for example, a tab is a character of indeterminate width used to space the following character to a certain y position according to a table, a rule or signs from the stars, then inevitably (ooh, an accidental pun!) there will be case where it gets rendered as a 1 pixel wide lump. I suppose under certain rules it could strictly be 0 pixels?

With fixed width chars it seems ‘natural’ that a tab should be at least a space wide but a proportional spaced font? Dunno. Maybe the real problem is our habit of using tabs to align code?


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: NBRM: Unconditional No BRanch Multiple

Hi, there.

Tab widths are specified in terms of a TextStyle, which is basically a set of fonts plus extras. So, at the moment there seem to be no direct means to fetch tab widths with respect to a character width of a specific font. For details, see CharacterScanner >> #plainTab.

Still, tabs are characters that should have some font information associated with them.... hmmm...

There is a pool dictionary "TextConstants", which includes "DefaultTab", "DefaultTabsArray", and "DefaultMarginTabsArray". Changing DefaultTab should recompute both arrays/caches. In my image, DefaultTab is 24 pixels.

In my experience, some tools offer an configuration to say how much spaces a tab character should span. So, for a proportional font, users could easily account for very small spaces by just raising that factor.

Hence, I see no need for specifying tabs pixel-wise. We should rather switch to "the width of the space character in the current font times X" where X remains configurable throughout the system. One might think of overriding such global property with a parameter in CharacterScanner. Use such global state just for initialization purposes, not throughout the computation.

Best,
Marcel

Hi Marcel,


With fixed width fonts defining a tab as a variable width character from 1 to N, such that the width of the line is a multiple of N makes sense.  In a proportional don't if does not.  In a proportional font it makes sense to visualize the line as divided into columns, each a tab width apart, and that a tab moved us to the next column.  This gives us the problem of a one pixel wide tab.

If you use a good document editor such as Mac OS X's Pages you'll see that it uses a column model for tabs, and allows the setting of columns so that tabs change the width of a line to an arbitrary position.  We also have this with a tabs array; tabs do not have to have a consistent width.  But in addition, a document editor such as Pages ensures that a tab has a minimum width, that if a space, so that if the width of a line before a tab is less than the width of a space, then the effect of a tab is to extend the width not to the next tab, but to the next tab plus one, which has the visual effect of ensuring a tab has at least the width of a space.  This is a much more useful and visually pleasing definition of a tab, that a tab is a character that is as least as width as a space but no wider than from the width of a space up to the next tab column at or after the width of a space.

So the difference is not in whether we have a  tabs array or not.  It is in how we compute the width of a tab.

> Best,
> Marcel


_,,,^..^,,,_ (phone)