Ok, so you don't just have a simple list of name/value pairs that happen to be separated by a tab element. You rather have arbitrary type-writer-style text. That makes it a lot more complicated, at least for XSL-FO.
In this case, if the XML format is fixed and cannot be changed at the source, I don't think that XSL-FO is capable of rendering this content. I'd check if you can't change the XML format to process in the first place. If not, I wouldn't use XSL-FO but another format which supports type-writing style, like ODF (OpenOffice) or Word XML (MS Word), to create the documents in PDF format. You asked earlier: > Why such natural requirement of tab stops is not included in FO? As I said, it was a concious decision by the XSL working group. I tried to find their reasoning as I remember having read about it somewhere a long time ago. But unfortunately, I couldn't find it anymore. Does HTML have tab support? No, either, probably because of the same reasons. If you wanted to convert your XML file to HTML, you'd have the same problem. On 11.11.2006 10:04:07 Andrejus Chaliapinas wrote: > Andreas, > > > Can you show us the non-transformed source nodes for those lines? > > The tab-stops, I presume, correspond to some marker in the source XML > > (a tab character?). > > Here is how that corresponding to my sample XML looks like: > > <par> > blabla: > <tab /> > text1 after one tab > </par> > <par> > blablabla: > <tab /> > text2 after one tab > </par> > <par> > blabla: > <tab /> > <tab /> > text3 after 2 tabs > </par> > <par> > <tab /> > blabla: > <tab /> > text4 when one tab exists before label and another it > </par> > <par> > <tab /> > blabla: > <tab /> > text5 first line > <break /> > text6 second line > <break /> > text7 third line > </par> > > > <par> means here new paragraph, so it's easy to convert it to fo:block or > fo:inline > <tab> means default tab stop, so following text should be positioned at the > nearest 0.5 inch position > <break> means line break inside paragraph (like shift+enter in text editors) > > Hope this could help for thinking - I'll really appreaciate that from you > actually. > > Maybe you could show me another XSL sample, in which second line of my > sample 'blablabla:' occupies not just first cell but also part of second > cell in the row and then you put some calculated space somehow before text > will start. > > Thank you. > > Andrejus Jeremias Maerki