As I believe has been mentioned before, any part of the process of translating from arbitrary XML into XSL-FO proper is effectively out of scope for this ML and group unless it is a real bug in the convenience mechanism provided by FOP to invoke XSLT for you.
If there is a problem parsing or formatting XSL-FO input, then you need to focus on creating the smallest possible example of XSL-FO document that demonstrates the problem. Everything else that happens up to providing XSL-FO input should be viewed as secondary as far as FOP is concerned. Cheers, Glenn On Mon, Sep 22, 2014 at 12:18 PM, MartinKl <klapec.mar...@hotmail.com> wrote: > Hello, > I havent meantion one important thing about how we produce document. We do > it in two ways. The first we use xsl-fo and xml with data. The second one > is > that we have a "special" markup language which produce xls transformation. > The markup language is even simplier than hmtl and serves good for simple > documents mostly with static content. Lots of people in the bank can use it > but they also make mistakes in it. > > > And that the problem causing retesting a big group of real templates. With > automatic test I can cover most of the mistakes but not those user made > ones. > > Another problem is the upgrade doesnt bring much new for us from bussines > side so it is hard to get a budget because bussines managers do not see any > added value. > > I hope I explained it well :) Who work for bank probably smile now because > he knows what I am talking about :) > > > > > > -- > View this message in context: > http://apache-fop.1065347.n5.nabble.com/Loading-fonts-problem-tp41009p41239.html > Sent from the FOP - Users mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org > For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org > >
