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

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

Reply via email to