Re: Problem with wordwrapping in a PDF with japanese language
Hi Louisa, You need to insert ZWSP char (#x200b;) where you expect a line break. This will add a break opportunity in your text line. Le 02/08/2011 17:36, Louisa M a écrit : Hi All, and sorry for my english, I generate PDF with XML, XSLT and Apache-FOP. The text-content for this PDF, is making by users in a interface. But I have a problem with users from Japan. When they write text, they are using apparently no blanks between the words. So the line are not wrapped and crashes my PDF layout. Can I solve this problem with the XSLT stylesheet? Thank you very much in advance. Louisa -- Pascal - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Regarding Retrieve binary images from database
Hi, FOP-core input is XSL-FO and XSL-FO needs URI to carry images. you have many options to feed XSL-FO: - URL to a temp file that contains image data; - URL to a script that carries image data; - URI that encodes image data as base64 encoding. - etc. How image data is retrieved from DB is out of the FOP-User list topic. You should find an appropriate list for such demand. Le 02/08/2011 21:36, raghuram256 a écrit : Hi , Can anyone have the sample code for retrieving binary images from database and converted to pdf? -- Pascal - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
FOP and large documents (again)
Hello, as we all know, FOP has performance issues when handling documents with a lot of pages in a page-sequence and/or when pages contain forward references to pages or bookmarks. Unfortunately, producing shorter page-sequences is not always a viable option, nor is leaving out forward references. In my setting, e.g., a TOC is required in the document, which adds forward references to bookmarks and pages for all page-sequences; also, formal requirements mandate that page numbers are given in the form page x of y, which adds a forward reference on every page for the last page of the document. Bluntly, I think FOP should be able to handle this. Looking at the code (as far as I understand it), for each page-sequence all KnuthElements are computed first by the layout managers. This is split only for forced page breaks. Then on the whole sequence, possible page break positions are searched for. Only after this are the actual output areas computed and pages produced. Clearly, this doesn't scale for large page-sequences... Is there a reason why this approach was chosen, instead of lazily (or on-demand)computing KnuthElements, putting them on the page and as soon as it is filled, pass it to the renderer? Naturally, this does not solve the problem of forward references, where one either needs a Renderer that can handle resolution after the actual page has already been rendered, or one needs two layout passes (as TeX does), where the first pass collects references and ids, which the second pass can then use. I am sure I overlooked something, so if there is additional information, I would be grateful for a pointer... Please let me know your view on this:-) Best regards Stephan -- Dr.-Ing. Stephan Thesing Elektrastr. 50 81925 München GERMANY Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP and large documents (again)
On Wed, Aug 03, 2011 at 10:23:48AM +0200, Stephan Thesing wrote: Looking at the code (as far as I understand it), for each page-sequence all KnuthElements are computed first by the layout managers. This is split only for forced page breaks. Then on the whole sequence, possible page break positions are searched for. Only after this are the actual output areas computed and pages produced. Clearly, this doesn't scale for large page-sequences... Is there a reason why this approach was chosen, instead of lazily (or on-demand)computing KnuthElements, putting them on the page and as soon as it is filled, pass it to the renderer? Both line and page breaking use the Knuth algorithm of a total fit. The algorithm requires the complete content before it can be applied. Clearly TeX does not do this; for page breaking it uses a best fit approach. For FOP it would be better if it could apply either strategy, at the demand of the user. But FOP is coded such that it first collects all content, in the process doing all line breaking in paragraphs, before it starts its page breaking algorithm. Therefore a best fit page breaking algorithm does not solve the memory problem. Changing this so that page breaking (best or total fit at the user's choice) is considered while collecting content has proven too hard (or too time-consuming) until now. See e.g. http://svn.apache.org/viewvc/xmlgraphics/fop/branches/Temp_Interleaved_Page_Line_Breaking/. There is a best fit page breaking algorithm, which is mainly used for cases with varying page widths. But it is a hack in the sense that it throws away all collected content beyond the current page, and restarts the process. So, help needed. Simon - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Problem with wordwrapping in a PDF with japanese language
thanks Pascal, but how I insert this ZWSP char () in the text. Do I have to count the japanaese characters of one line and then I insert the ZWSP char ()? Or is there a function, who insert the ZWSP char automatically after every character? Greetings Louisa -- View this message in context: http://old.nabble.com/Problem-with-wordwrapping-in-a-PDF-with-japanese-language-tp32178905p32184851.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
Is FOP unmaintained?
It seems as if it's been a year since a 1.0 was released, with bunches of known bugs. Is this software still maintained? - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
AW: Is FOP unmaintained?
Hi Jerome, Yes, FOP is still maintained even though there are rarely releases. Nightly builds usually have production grade quality, in case you run into a known bug from 1.0. Regards, Georg Datterl -- Kontakt -- Georg Datterl Geneon media solutions gmbh Gutenstetter Straße 8a 90449 Nürnberg HRB Nürnberg: 17193 Geschäftsführer: Yong-Harry Steiert Tel.: 0911/36 78 88 - 26 Fax: 0911/36 78 88 - 20 www.geneon.de Weitere Mitglieder der Willmy MediaGroup: IRS Integrated Realization Services GmbH:www.irs-nbg.de Willmy PrintMedia GmbH: www.willmy.de Willmy Consult Content GmbH: www.willmycc.de -Ursprüngliche Nachricht- Von: Jerome Haltom [mailto:jhal...@isillc.com] Gesendet: Dienstag, 2. August 2011 22:13 An: fop-users@xmlgraphics.apache.org Betreff: Is FOP unmaintained? It seems as if it's been a year since a 1.0 was released, with bunches of known bugs. Is this software still maintained? - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Problem with wordwrapping in a PDF with japanese language
Louis, you can add the ZWSP at XSLT stage, before and/or after each Japanese glyph. You can do that in a pure XSLT recursive loop, or using an embedded script (technology will depend on what XSLT engine you use). Le 03/08/2011 11:54, Louisa M a écrit : thanks Pascal, but how I insert this ZWSP char () in the text. Do I have to count the japanaese characters of one line and then I insert the ZWSP char ()? Or is there a function, who insert the ZWSP char automatically after every character? Greetings Louisa -- Pascal - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
