howardr101@h... wrote:
> Hi Jean-Fran=E7ois,
>
> Thanks very much for your reply.  Naively, I hadn't factored in the
> "just make it work" methodology to solving the formatting problems, I
> was expecting FO to provide mechanisms to handle the functionality I
> mentioned in my post - they didn't seem that obscure.

Glad I could be of help ;-). Yeah, we always like to assume the tools
we are using will at least do the job, but the truth is most of the
time they only do part of the job and you have to patch up what's left.
It is unfortunate, but very frequent. Revision indicators aren't that
obscure either when you think about it (having a bar on the side of the
document to indicate that a portion of text has changed, but it is only
supported as of XSLT v1.1, and nearly nobody implements it just yet).
Companies usually offer company specific extensions to FO as an add on
to paliate the deficiencies of the standard. XSLT still has a long way
to go. All and all, it still is a very interresting and powerful tool.

> I'm looking into XML / XSL as a replacement to an inhouse developed
> reporting solution and one of the requirements was this pagination
> control.  Additionally, this potential reporting solution is to be used
> by people who aren't primarily developers, but accountants - so the
> solution mustn't be too challenging to use.  Do you have any thoughts /
> comments on XSL as a reporting solution.  I've had a look at the
> Altova, XSLFast and StylusStudio tools, however, if I put these
> applications in front of the end users, capable as the applications
> are, I'm fairly certain the users would not thank me for it.

I don't know exactly what your requirements are, but you might want to
look the XML way in that case. Instead of creating creating a custom
XSLT for an XML everytime a new report has to be emitted, you put
together a single more flexible XSLT stylesheet in which all XMLs will
go through to generate your report. The tools you mentioned, Altova,
XSLFast and Stylus Studio are graphics frontends sitting on XSLT
processors to aid in stylesheet development. I personally wouldn't have
end users use those to format their reports.

Using for example an XML editor such as open-source VEX (XML which
would have to contain enough information for you to properly format the
end product in either .pdf or .rtf. font size, bold, italic,
indentation, table column width, etc.) might be what you are looking
for. VEX is a strange hybrid though. Using a combination of XML and CSS
for display (CSS which is usually only used in combination with HTML).
It is a very interresting tool though and might be just what you are
looking for. Otherwise, any XML editor that takes in an XML + XSLT to
output on display will do the trick. The same XSLT that would be used
for display could be used for transformation into the final .rtf or
.pdf product.

> I'm coming to the conclusion that XSL et al are powerful tools, but
> there is a need for a seasoned XSL et al developer to create the
> solutions - it's not the sort of thing you just dive into.

Somebody definately needs to sit there and put together the stylesheet,
depending on the complexity of the reports, it might very well turn out
to be very easy, or very complex.
Once the flexible stylesheet is done though, everything that goes
through it should be fine.

> Google is indeed a powerful friend, it's a shame he / she's not psychic
> - though I'm sure that's only a matter of time :)  I've spent so long
> trying to phrase my searches in google to try and get the answer I'm
> looking for that I'm thinking of doing a Phd in frustration management
> techniques..

Heheh, its just a question of practice. It took me one try to hit the
answer you were looking for, but then again I'm ALWAYS searching stuff
on google so I kindda know how to make it squeeze the answers out.
Google in "using google efficiently". It pays off like you wouldn't
beleive to have google do what you want.

> I've been using Apache FOP for the rendering and it does seem OK.
> However, one of the other requirements for this reporting solution was
> to be able to create RTF, which the latest beta does, however, it
> renders the same FO document differently to RTF and PDF - which is a
> little frustrating..  I know you can generate RTF straight out of the
> XSL transform, however, do you not then forfeit the layout capabilities
> built into FO? - specifically the pagination control.

RTF. There's an interresting requirement. If you want your FO and RTF
to by synchronized, some work will have to be done to make them
synchronized (2 different stylesheets might be required in this case.
One to output PDF through FO and one to output RTF). I never compared
the expressing capabilities of RTF vs FO, but if one is more expressive
than the other, if you want them to be in synch, you might have to
leave behind some functionalities from either one or the other. Or if
its not such a big issue, the RTF can be different from the PDF if
thats okay with the customers. If you were go to down the VEX path, you
are probably looking at a custom made DTD for your XML, a CSS to
display the XML properly under VEX and 2 different stylesheets. One to
output PDF through FO and one to output RTF.

Here's a link to the RTF spec 1.6:

http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/dnrtfspe=
c/html/rtfspec.asp


and a little discussion about this issue you are facing with RTF:

www.---.com=
8&style=3DWebBoard

> Thanks again for your assistance.

You are most welcome

Regards
Jean-Francois Michaud

> Regards,
> Howard
>
>
>
> Jean-Fran=E7ois Michaud wrote:
> > Hello Howard,
> >
> > howardr101@h... wrote:
> > > Hi,
> > >
> > > I'm really new to this XSL stuff and there's a lot of information out
> > > there on the web, I just can't seem to find a definitive answer to my
> > > question, hence......
> > >
> > > In FO, I know that you define a block and use the keep-together
> > > attribute to specify whether or not the block should be split over
> > > multiple pages - unless the block itself is longer than a page.
> > >
> > > However, if you allow the block to be split over two pages, is there a
> > > mechanism to put some text at the top of the split piece of the block.
> > >
> >
> > As far as splitting text goes, you want to look at orphans/widows. When
> > the attribute is set to a certain value, it garanties that you will get
> > at least what you are asking for or else the whole content of the block
> > carries over to the next page. Not all XSLT processors support this
> > feature, you want to make sure that the processor you use supports all
> > the features you are looking for. Most of the time, they support one
> > feature, but not the other and vice versa. Its difficult to get a very
> > good one that supports all the important features.
> >
> > If you are not in for hardcore technical publications, FOP (open
> > source) is actually not so bad (it doesn't support orphans/widows
> > though).
> >
> > > Specifically, say I have a table and the table gets split over two
> > > pages half way down its body. So the top half of the table is at the
> > > bottom of page 1 and the bottom half of the table is at the top of pa=
ge
> > > 2.  Is there a mechanism in FO to reprint the table column headers at
> > > the top of the chunk of table on page 2.
> > >
> > > I read somewhere that this might be possible by writing another XSLT =
to
> > > do some post processing, additionally, I've read that XSL is a fire a=
nd
> > > forget kind of technology and you can't do this.  If you don't know
> > > that this table splitting is going to happen until it's run through t=
he
> > > FO processor and once it's gone through the processor you've got (in
> > > this case) a PDF file - how would you then insert the column headers =
in
> > > again, by the time the table has been split, it's too late to easily
> > > insert the column headers.
> >
> > Google is a very powerful friend ;-). This seems to be what you are
> > looking for:
> >
> > http://www.idealliance.org/papers/dx_xmle04/papers/04-02-01/04-02-01.ht=
ml#s6
> >
> > > I'd like to ask the same question with regards to a table caption, in
> > > order to achieve a table title at the top of the split chunk of table
> > > on page 2. e.g.
> >
> > Something to keep in mind also, often you will have to use tricks to
> > pull off certain effects (nested indentation using lists for example
> > even though the content of your XML isn't contained in lists; to get
> > sequencial labeling across multiple sections for example. An invisible
> > table column for which you set the width to align a table exactly like
> > you want on a page). Don't be afraid to use constructs that don't seem
> > to be "appropriate" or that look very different (under FO) than what
> > you have in your XML. Whatever works, works. If there is not direct way
> > to do something by using the functionalities of the language directly,
> > you might be able to achieve the desired result through indirect means
> > (oddly enough, when you are working on solid projects, this happens
> > very often). Currently, the language is simply not descriptive enough
> > (functional only). A functional/procedural language hybrid would be
> > much more appropriate.
> >
> > In the case of your table caption, you could use an borderless row in a
> > fo:table-header.
> > =20
> > [snip]
> >=20
> > Regards
> > Jean-Francois Michaud