RTF Fonts
Hi, I'm using fop0.92 to export a xml document to PDF and RTF. When I use my xslt and xml file to generate a PDF using fop everything works fine, but if I try to generate a RTF, all the truetype fonts I'm using in the document are changed. Where the font should be "Times New Roman", it's "times", and the same thing happens for "Courier New" and "courier". Please, could anyone tell me how to fix this. Thanks. Este correo electrónico contiene información privada y confidencial. Si usted no es el destinatario del mensaje no está autorizado a leerlo, copiarlo o difundirlo. Si lo ha recibido por error, por favor contacte con el remitente y destruya su contenido. Privileged/confidential information may be contained in this e-mail. Any reading, copying o dissemination of this communication by persons or entities other than its intended recipient is prohibited. If you received this in error, please contact the sender and delete it.
Re: Keep-Together Problems
Ross, it's good to know that there are people out there with the right spirit. Normally, I'd be glad to take this on. There are a few things in this special case that we have to look at, though. Implementing the integer values for keep-* properties is not going to be a fix. We'll have to do some investigation first. The integer values (full integer value range) have to be mapped somehow into the penalty system (integer values from 0 to 999) used by FOP's layout engine. That may make it necessary to find out which set of values are really used in the whole document. Smells like two-pass processing. I'm not sure, yet. Note that, to my knowlegde, only AntennaHouse has implemented this feature, yet, and only in their latest version. It's not something simple. I guess one thing we can do arather quickly is to amend the keep implementation to better satisfy the specification text in XSL 1.0, 4.8 which seems to allow relaxing the keep conditions even if it's set to always. At the moment, we're using the INFINITE penalty value for always which doesn't allow the layout engine to break to blocks apart. If we lower that value to 900 (or 999 or so) like I've done for a special rule in the table layout manager, we can probably better match the 0.20.5 behaviour, although there might be side-effects which I cannot predict right now. Before we continue here I'd like to get at least one second opinion by one of my fellow fop-devs. If there's someone who would like to dive in here in my place, he/she's welcome to do so as I have more than enough on my plate. A rather large backlog and ApacheCon this month would delay this anyway. I don't think I can do the scaled-down version (second paragraph above) before mid-July. On 02.06.2006 18:47:28 Ross Nicholls wrote: Dear Jeremias (or other), As this is a commercial project I can offer to employ you (or one of the developers) to cure this problem that we are experiencing. If you are willing, please let me know your personal charge for completing the fix. I can be contacted directly at [EMAIL PROTECTED] if preferable. Regards, Ross - Original Message - From: Jeremias Maerki [EMAIL PROTECTED] To: fop-users@xmlgraphics.apache.org Sent: Monday, May 29, 2006 1:11 PM Subject: Re: Keep-Together Problems At the moment, only always is supported for keep values which causes the effect you've seen. So far nobody has implemented any refinements that will cause certain keep conditions to be relaxed if necessary as defined in XSL 1.0, chapter 4.8. The solution would be to implement finer rules to specify penalty values during element list generation. Currently, there's no work-around other than not to use keeps. On 23.05.2006 16:01:41 Ross Nicholls wrote: Hi there, I am currently working on migrating our large XSL-FO project from FOP v0.20.5 to the new v0.92. Everything is going great and the new version offers some excellent advantages over the older one, I'm really looking forward to the SVG and MIF (or similar) output implementations when they materialise. I do have one problem however: The new version (0.92 beta) doesn't seem to cope too well with Keep-Together on table-rows (or any block level area for that matter) when the contents are actually larger than a page. In the old version (0.20.5) I was able to put a keep-together on the table-row which meant that each product from the catalogue would not be split over 2 pages UNLESS the product was too big to fit on a page of it's own. But with the new version, when it encounters such a product (table-row, that contains multiple blocks and image content) it crashes with an error - something like Content does not fit in available area after 50 attempts, gave up to avoid an infinite loop. Unfortunately, this means that we can't go ahead with the upgrade to the new version of FOP and take advantage of all the wonderful improvements - as the keep-togethers are very important. Does anyone have any idea how I can get round this problem, or is there a fix available or possible??? I appreciate any help or comments anyone can give. Kindest Regards, Ross Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RTF Fonts
I've just committed a fix [1] that should avoid the conversion to lower case. However, the problem with the spaces in the font names is not easily fixed. You'll have to use simple quotes around the font names for now, i.e. font-family='Times New Roman' instead of font-family=Times New Roman. [1] http://svn.apache.org/viewvc?rev=411725view=rev On 05.06.2006 10:38:43 jegd wrote: Hi, I'm using fop0.92 to export a xml document to PDF and RTF. When I use my xslt and xml file to generate a PDF using fop everything works fine, but if I try to generate a RTF, all the truetype fonts I'm using in the document are changed. Where the font should be Times New Roman, it's times, and the same thing happens for Courier New and courier. Please, could anyone tell me how to fix this. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RTF Fonts
Thank you very much. -- View this message in context: http://www.nabble.com/RTF-Fonts-t1734031.html#a4712935 Sent from the FOP - Users forum at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Very large files to PDF
Thanks andreas, for twice the help: - probably my out of memory problem was caused by a forward-reference. - nevertheless i ever wanted to do processing in a more streaming fashion so the intermediate format should be my solution. Best regards, Stefan Andreas L Delmelle escreveu: FOP's Intermediate Format[*] might offer a solution here (?) Generate separate documents, and concatenate the area trees...? On another note: what exactly is the structure of your FO-source? Do you work with multiple, smaller page-sequences, or one huge flow containing everything? Do you use forward-references to the end of the document? [*] see: http://xmlgraphics.apache.org/fop/0.92/intermediate.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Preprocessing
Thanks, I have most stuff working again However, ... My SAXFilter does not work anymore (the one that performs syntax highlighting). It might be due to some ordering problem. The filter is injected using: CodeBlockXMLFilter filter = new CodeBlockXMLFilter(); filter.setContentHandler(fop.getDefaultHandler()); transformer.transform(xmlSource, new SAXResult(filter)); When the filter reaches my element, it writes all characters to a buffer, which is than processed in the endElement. The last step in the processing is inserting multiple fo:inline element (with the color of a specific keyword). I insert these elements using the methods of super (i.e., XMLFilterImpl): startElement, characters and endElement. It did work under 0.20.5... Any clues? -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 05 June 2006 11:30 To: fop-users@xmlgraphics.apache.org Subject: Re: Preprocessing On 05.06.2006 11:12:22 Raphael Parree wrote: Thanks yes I know the reason for the error, it is just that I didn't had so many with the 0.20.5 release. Probably has to do with the fact that 0.92 is more strict. Also many of my indentations have changed, and text seems to be more compressed. A few changes I see so far in the produced PDF: -Indentations (start-indent) is much larger. Is this because the start-indent from parent blocks are accumulated now? 0.20.5 had an awful compliance level in this area. The new codebase is a 100% compliant implementation for start-indent and friends. start-indent can accumulate if you cross reference-area boundaries (block-containers or tables in between. That is due to indent inheritance which is described in detail in: http://wiki.apache.org/xmlgraphics-fop/IndentInheritance -space-before seems to be ignored? No, no. 0.20.5 always behaved as if space-before.conditionality=retain were specified. The new codebase does full space resolution (XSL 1.0, 4.3) except in footnote areas. That's what you're seeing. Just set space-before.conditionality=retain and your spaces will miraculously appear again. :-) -Some (all?) images seem to be bigger than before (SVG, I use the external-graphic element default) Hmm, depends on your SVGs. If they have absolute width and height (not specified in pixels) attributes and a viewbox (which is preferred in the first place), they will be the same as 0.20.5 or even better. Try setting source-resolution96/source-resolution (default is 72) in the user configuration file or use FopFactory.setSourceResolution(96). This changes the way the size of images only made up by a number of pixels are determined. Most SVG editors seem to use 96dpi, but that's not a hard value. Therefore, it is best practice to specify the size of SVG images in centimeters or inches or whatever. (-Bookmarks don't work (I saw the note on the website)) Where? XSL 1.1 bookmarks are fully implemented for PDF output. You simple have to change from fox:outline to XSL 1.1 bookmarks. See: http://xmlgraphics.apache.org/fop/0.92/upgrading.html For the rest it looks promising. snip/ Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Preprocessing
Found it... The namespace on fo:inline's attributes must be NULL and not http://www.w3.org/1999/XSL/Format. -Original Message- From: Raphael Parree [mailto:[EMAIL PROTECTED] Sent: 05 June 2006 16:31 To: 'fop-users@xmlgraphics.apache.org' Subject: RE: Preprocessing Thanks, I have most stuff working again However, ... My SAXFilter does not work anymore (the one that performs syntax highlighting). It might be due to some ordering problem. The filter is injected using: CodeBlockXMLFilter filter = new CodeBlockXMLFilter(); filter.setContentHandler(fop.getDefaultHandler()); transformer.transform(xmlSource, new SAXResult(filter)); When the filter reaches my element, it writes all characters to a buffer, which is than processed in the endElement. The last step in the processing is inserting multiple fo:inline element (with the color of a specific keyword). I insert these elements using the methods of super (i.e., XMLFilterImpl): startElement, characters and endElement. It did work under 0.20.5... Any clues? -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 05 June 2006 11:30 To: fop-users@xmlgraphics.apache.org Subject: Re: Preprocessing On 05.06.2006 11:12:22 Raphael Parree wrote: Thanks yes I know the reason for the error, it is just that I didn't had so many with the 0.20.5 release. Probably has to do with the fact that 0.92 is more strict. Also many of my indentations have changed, and text seems to be more compressed. A few changes I see so far in the produced PDF: -Indentations (start-indent) is much larger. Is this because the start-indent from parent blocks are accumulated now? 0.20.5 had an awful compliance level in this area. The new codebase is a 100% compliant implementation for start-indent and friends. start-indent can accumulate if you cross reference-area boundaries (block-containers or tables in between. That is due to indent inheritance which is described in detail in: http://wiki.apache.org/xmlgraphics-fop/IndentInheritance -space-before seems to be ignored? No, no. 0.20.5 always behaved as if space-before.conditionality=retain were specified. The new codebase does full space resolution (XSL 1.0, 4.3) except in footnote areas. That's what you're seeing. Just set space-before.conditionality=retain and your spaces will miraculously appear again. :-) -Some (all?) images seem to be bigger than before (SVG, I use the external-graphic element default) Hmm, depends on your SVGs. If they have absolute width and height (not specified in pixels) attributes and a viewbox (which is preferred in the first place), they will be the same as 0.20.5 or even better. Try setting source-resolution96/source-resolution (default is 72) in the user configuration file or use FopFactory.setSourceResolution(96). This changes the way the size of images only made up by a number of pixels are determined. Most SVG editors seem to use 96dpi, but that's not a hard value. Therefore, it is best practice to specify the size of SVG images in centimeters or inches or whatever. (-Bookmarks don't work (I saw the note on the website)) Where? XSL 1.1 bookmarks are fully implemented for PDF output. You simple have to change from fox:outline to XSL 1.1 bookmarks. See: http://xmlgraphics.apache.org/fop/0.92/upgrading.html For the rest it looks promising. snip/ Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
list-item formatting in 0.92
The formatting of list-item has seemed to have changed from 0.20.5 to 0.92. I have a list item (code contained below) that is rending as follows in 0.92: - |item-body (block 1)| - |item-label| - |item-body (block 2)| - Here is what I am expecting and how 0.20.5 seemed to work (unless something else in the port is causing this changed behavior): - |item-label| |item-body (block 1)| - - |item-body (block 2)| - How can I get my desired behavior in 0.92? Regards, Dave fo:list-block fo:list-item fo:list-item-label fo:block text-align=left padding-before=0.15in width=3.50in fo:external-graphic src=intelligent_systems_logo.gif content-height=0.75in content-width=3.0in / /fo:block /fo:list-item-label fo:list-item-body fo:block fo:block text-align=right padding-before=0.15in font-size=14pt font-weight=bold color=#C0 vertical-align=middleCurrent Out Of Stock Report/fo:block fo:block text-align=right padding-before=0.0675in font-size=9pt font-weight=bold color=gray vertical-align=topJune 05, 2006 at 01:16 PM/fo:block /fo:block /fo:list-item-body /fo:list-item /fo:list-block __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
