Perhaps it would be useful to set up a "user" mailing list separate from the "dev" list. It seems like 80%+ of the messages are on how to use FOP. Which is realy helpful and great, I try to help out when I can. Separate lists might be more useful for users and developers. I'm more of a user myself, but I can't imagine how the developers weed through all the input.
While the Euro languages are probably not the best supported. We are able to generate pdf's of high enough quality for our printer to utilize OMR marks and other institutions to use OCR. Useful stuff when bulk processing. Our images are preprinted and our PDF's are text based so we avoid many high resolution issues. It took research, trail and error, tweaking and posting to the list to get pages we could generate correctly and consistantly. Once it was done, FOP generates our PDF's very consistently. With that experience we're able to create other PDF solutions with FOP rapidly. The documentation on the site has improved over the last several months. Traffic on the development list has been on a steady rise too (see above). So...many many thanks to the dev team. JohnPT fop-dev-return-12148-jthaemlitz=oreillyauto.com@XML. APACHE.ORG To: <[EMAIL PROTECTED]> cc: 12/13/01 07:50 AM Subject: Re: Basic aspects Please respond to fop-dev If I can specifically address one point, it is that I am curious about why you think FOP is web-oriented at all. If FOP is invoked from a servlet, which seems to be a popular mechanism, then the output is indeed being delivered to Web browsers. Unless things are different in Cocoon 2, Cocoon itself is nothing but a high-powered servlet that uses FOP just like this. But FOP itself has never been Web-oriented. HTML has never been produced by any of the renderers. Nor WML or HDML or anything else Webbish. The initial paragraphs on the main page (http://xml.apache.org/fop/index.html) do not mention these formats at all. Speaking for myself I have always viewed FOP as a print publishing tool, focused on producing print-quality documents. I would not characterize PDF as web-oriented, not in the sense you mean. It started out as a page description language, and it is stil a page description language. It has design features that promote electronic delivery, and this if anything makes it "web-compatible". Now, I've used PDF since Reader 2.0, I worked for 2 years at a shop where we were intimately familiar with PDF and did lots of early programmatic stuff with PDF (in Perl, mostly) before the explosion of useful tools (including any Perl PDF modules), and the PDF we produced had to be very high-quality for print purposes. We also used extremely large TIFF files as the basis for PDF images in those documents. So PDF may have some limitations, but I agree that if anyone is bottlenecked right now they are probably bottlenecked because of FOP, not because of PDF. That is, performance limitations. I think Keiron and Karen, among others, would agree that the object of the rewrite that they are spearheading is to allow other developers to more usefully contribute. This should go a long ways to letting more people get at the code. When you say "documentation", I take it you mean operating instructions, rather than stuff about XSL per se. Correct? Regards, Arved Sandstrom ----- Original Message ----- From: "Matthias Fischer" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, December 13, 2001 5:27 AM Subject: Basic aspects > Hallo developers, > > I think I should give my contribution in backing Keiron's statement. Please > note that this is not some kind of a stuck-up, disengaged spectator's point > of view. I think the FOP developers have done a great job, sacrificing time > and money to achieve what has been achieved, and - as a beneficiary of it - > I'd like to thank you for it cordially. I also would like to express > gratefulness towards those who helped my colleagues and me in our wading > through the difficulties we met on our way. > > To help you to understand better who speaks: I am not a thorough-bred > programmer. As a consultant, I'm trying to analyze different customers's > needs, and as the mentor of my own company's programmers I develop ideas and > help my colleagues in persuing these objectives. > > There are no programmers in our company capable of messing with the source > code of Cocoon, or FOP, or anything linked to it. Therefore, sometimes FOP > is to us like a black box, which doesn't make things easier. > > As a user, or "customer", however, I could express some clearcut opinions > which might be interesting feedback for FOP developers: > > - Documentation. I know, there is no entitlement to documentation, or to > anything else, in an open-source project. Nevertheless, I found that (a) W3C > specs are great, but envisage no practical approach for those, like us, who > are not the ultimate specialists; (b) books seem to be scarce, contain > sometimes wrong or misleading information, are too superficial in their > examples, i.e. show what anyone would retrieve from somewhere in the > internet anyhow, and not always are systematic. It has cost us thousands and > thousands of Euros to get hold of simple, necessary-to-operate information. > Something like "SelfHTML", a site very popular among German HTML designers, > would be needed. > - Sometimes, I have the impression that FOP is a bit too web-oriented. I > don't know whether it's true, but both my colleagues and I, at a certain > point, got the impression that, when the HTML output side was finished, > somebody said: "And what are we going to do next?", with someone else > answering: "Let's do PDF". Of course, PDF is, first of all, a "portable" > data format, i.e. it's web-oriented. But, more and more, it is used for > typographical purposes. However, it is not possible to get anywhere near to > printshop quality unless EPS and TIFF files of a certain resolution rate can > be used. However, using twenty TIFFs of 1MB each puts FOP k.o. in a few > milliseconds. due to my own experience, FOP seems designed to be uses with > JPG/GIF pictures at 72dpi which look fine through the internet and on an > ordinary office printer. Or take hyphenation: given the number of languages > involved, certainly not an easy task. On the other hand, if hyphenation does > not work properly - and we havent't got it to work properly with the W3C > spec's language and country attributes for German and Germany - the output > scores a further little minus > (thinkofthoselongGermanwordswhich-iftheysliptothenextline-dontlooktoowell... > ), and these minus points accumulate. > > Please let me underline at this point that FOP is held by us a valuable and > very useful invention. We'll continue to utilize it, and we'll propagate the > use of it. Nevertheless, it would be encouraging to see the effort, which is > necessary to get it on its way, being reduced. > You might reply: "So, why don't you get involved and help making it better?" > Rightly so. The answer is: I can't, I haven't got the expertise. What I can > do, I've done - to utter my point of view with some detail. > > Cordially > > Matthias > > > -----Original Message----- > From: Keiron Liddle [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, December 12, 2001 3:55 PM > To: [EMAIL PROTECTED] > Subject: Re: need help > > > [...] > > While that is true there are certain things you need to realise. > - there are serious layout issues that need to be addressed > - performance and memory is very much tied up to how the whole system > works, this makes it difficult to fix > - getting FOP to a stage where there is a clear development direction is > difficult > - none of this will happen by itself > > It appears that more effort needs to be put towards communicating the > issues involved and the way in which FOP can be improved. > > Yes it does need to be much better. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]