At any rate, this FO could not be called fo:tab because it's non-standard and must not be in the fo namespace. ODF uses text:tab-stop (Namespace URI: urn:oasis:names:tc:opendocument:xmlns:text:1.0).
Something like that could make sense for RTF output in certain situations (as output element) but definitely not for the other output formats (as input/control element). If you told your idea to the XSL working group, they'd probably strangle you. :-) It was a very conscious decision not to support tabs in XSL-FO. Besides that I think it would be rather difficult to implement. I'd rather not introduce tab stops in FOP. But I don't know what the others think. Maybe if you illustrated your problem with some visuals we could give a few suggestions. I'm pretty sure your problem can be solved without tabs. On 09.11.2006 09:27:05 Andrejus Chaliapinas wrote: > Hi, > > Sorry, I was very busy with other stuff to work on table auto layout (plan > to return to that next week), but right now another additional issue is > bothering me - how could I have simple enter form (in which you have column > of labels and column of aligned input fields) converted? I saw already > suggestion of using table for that purposes, but it's not suitable for my > situation, cause I'd like in this case to have mostly one row of such table > independent from another and making such calculations a little bit ahead is > difficult. > > So, I have proposal (please correct me if it's already decided on similar > one what to do) to implement something like fo:tab tag, which will at the > first stage of implementation work mostly like fo:leader, but with > additional knowledge of what is the default tab step is and will calculate > where is nearest tab stop should be placed based on the text block sizes > under processing. > > Does it make sense in terms of FOP at all? > > Any help would be appreciated. > > Andrejus Jeremias Maerki
