Hi Marcel,

> On May 10, 2016, at 12:01 AM, marcel.taeumel <Marcel.Taeumel at hpi.de> wrote:
> 
> 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.


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)