Am 15.07.2010 16:53, schrieb Idris Samawi Hamid ادريس   سماوي حامد:
> On Thu, 15 Jul 2010 02:33:03 -0600, Peter Rolf <indiego@gmx.net> wrote:
> 
>> has to do with the way the column width is calculated. the combined
>> entries (2+3,4+5) in row one can only influence (increase) the total
>> width of the involved columns, but they can not give an answer to the
>> question how wide the single columns should be.
>> in the end you need a linear system of equations (and metapost) to solve
>> this. and there is also no guarantee that it is solvable in all (more
>> complex) cases.
>> col2=col3; col4=col5;
>> col2+col3= ....;
>> col4+col5= ....;
> 
> Ok... But it seems inescapable that this is a bug in some sense. If we
> simplify things, compare
> 
> ======================================
> \starttext
> \starttables[|c|c|]
> \HL
> \VL \Use{2}[c]{B} \VL\AR
> \HL
> \VL  B \VL B                \VL\AR
> \HL
> \stoptables
> \blank
> \starttables[|c|c|]
> \HL
> \VL \Use{2}[c]{BBBBBBB} \VL\AR
> \HL
> \VL  B \VL B                \VL\AR
> \HL
> \stoptables
> \stoptext
> ====================================
> 
> Your mathematical explanation makes sense, but to a new user I doubt one
> could convince him/her that the second table is a feature and not a bug.

it's more a limitation of this table implementation. you have some
additional space from the multicolumn entry that must be added to the
involved columns somehow. the current implementation is probably
something like this: use the natural width (maxima) for all but the last
involved column and add the complete additional space to the last one.

> But I understand that the challenge may be complicated.
> 
> Till then, we need a simple workaround if that's possible.
> 
>> also: i can't imagine how a user interface for this should look like.
> 
> \setuptables[spanalign=balance]
>

right. you can implement all kind of different spanning algorithms. i
would expect that 'balance' would share the additional space equally on
all involved columns.

but table macros in tex are really ugly. you need tons of bookkeeping
data for maxima, styles, multi-column|row, whatever. and tex has no data
types for bookkeeping (like a programming language), so you have to
store all the data in macros, dimens... it's a complete mess. have a
look at the macro definitions and you will agree :)

anyhow, i expect much better functionality (e.g. clever spanning
alternatives) with a lua based table implementation. we have to wait for
that.

> or something....
> 
>>>> maybe like this...
>>>
>>> That's a great workaround, and I appreciate it. But what about new
>>> users? There has got to be a more elegant solution to this seemingly
>>> simple table. Row two just does not look right...
>>>
>> true, but this is font related. you can see this by using
>> \ruledhbox{ʿAlī}. you have to add some manual kerning (\kern-0.??em ...)
>> then.
> 
> I don't see the font-relatedness, even with \ruledhbox... Hence the
> above simple test case.
> 

see attached pdf (the box looks centered). the \ruledhbox breaks the
width calculation of the second column somehow, but you can see that
there is some additional space in front of the first character. use a
negative kern in front of it for compensation.

> As we work to bring ConTeXt to a wider audience -- I'm currently
> involved with such efforts, we should keep track of outwardly "simple"
> cases like the above ...
>

not an easy task, as it's more a 'special' than a 'simple' case ;)
but i know what you mean. my best wishes for that.

Peter