- From: Stan Devitt <jsdevitt@stratumtek.com>
- Date: Tue, 28 Oct 2003 12:18:53 -0500
- To: silverbanana@gmx.de
- Cc: www-math@w3.org
Actually, my point was that XSLT could NOT do it even with tables because there is not enough information in the multistep model. The xhtml construction I had in mind and which captures your troublesome cell was (Up to padding) <tr> <td>implies</td> <td colspan="3"> first part of first expression</td> </tr> <tr> <td> </td> <td>colspan="3"</td>second part of first expression</td> <tr> <tr> <td> </tdL <td >end of first expression</td> <td>=</td> <td >right hand side</td> </tr> Basically, XSLT would not be able to use automatic line wrapping info to determine the mathml fragments that go into each row from a single mathml expression. Once I have know the fragments, this could be made to look good. Stan. Bernd Fuhrmann wrote: > > > > > This example helps. The layout you prefer could be done now using > something like 4 columns, 6 rows, some appropriate colspan attribute > values, and some careful alignment and/or padding. > > Yes and no: it would work, but it would be bad, though it might be the > best solution. However, I tend to use good solutions only, so I will > rather risk a more confusing formating that using tables to do sth. > that I'm not supposed to do with them. > > [...] > > XSLT could do that. > But it is really dificult to get this to work since I do not know if > this problem will ever be treated so that tables can be avoided. If I > hadn't that hope, XSLT would be useless since there would be never any > better (feasable) solution. So let's assume MathML 3.0 (or whatever) > could fix this problem. This might require a significant structural > change in all my content which would make XSLT somehow useless. > > > For example, to mark up Term 7 entirely in a single MathML table > cell we would need some sort of malign which interacted > with automatic line-wrapping in a new way > > Yep, we need a new way of treating this, exactly. Well, patience is a > virtue! Let's see what future versions of MathML will bring... > > >
Received on Tuesday, 28 October 2003 12:22:43 UTC