RE: FOP 1.1 RTF Output empty
> RTF support is a bit broken in 1.1, see also > https://issues.apache.org/jira/browse/FOP-2182 > You can workaround by not using a PageSequenceMaster, so use your simple page > master's name "first" as "master-reference" on the fo:page-sequence element > and it should process again without errors. Many thanks Matthias, this did the trick! - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 1.1 RTF Output empty
Hi, RTF support is a bit broken in 1.1, see also https://issues.apache.org/jira/browse/FOP-2182 You can workaround by not using a PageSequenceMaster, so use your simple page master's name "first" as "master-reference" on the fo:page-sequence element and it should process again without errors. Regards, Matthias On 20.05.2015 06:03, Marc Wiest wrote: I just tried to upgrade from FOP 1.0 to 1.1 and while most things work, one RTF document doesn't. It worked smoothly with the 1.0 version, but now produces an empty zero-byte OutputStream (ByteArrayOutputStream in my case). No errors in the log, nothing. The upgrade notes https://xmlgraphics.apache.org/fop/1.1/upgrading.html don't state anything about incompatibilities with RTF. Any idea? Attached are the xml, xsl and the working output from FOP 1.0. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
FOP 1.1 RTF Output empty
I just tried to upgrade from FOP 1.0 to 1.1 and while most things work, one RTF document doesn't. It worked smoothly with the 1.0 version, but now produces an empty zero-byte OutputStream (ByteArrayOutputStream in my case). No errors in the log, nothing. The upgrade notes https://xmlgraphics.apache.org/fop/1.1/upgrading.html don't state anything about incompatibilities with RTF. Any idea? Attached are the xml, xsl and the working output from FOP 1.0. http://www.w3.org/1999/XSL/Transform"; xmlns:fo="http://www.w3.org/1999/XSL/Format";> http://www.w3.org/1999/XSL/Format";> Book Information Title: Subtitle: Author: Copyright: Year: Pages: ISBN-13: Teaser: Email text: Key Words: getAbstract Ratings Push: Shelf Life: : Focus Bestseller: Classic: Audio: Take-Aways • Relevance What You Will Learn
RE: table of contents page number not showing in RTF output
Sorry for the confusion, just like Glenn said earlier the issue I am facing right now it's when I open the rtf document in M$ word, # is displayed instead of page numbers. The # won't go away until I take more action (print or saved as PDF). This only happened in TOC, in the header part of the document everything is displaying correctly (page? Of ?). Any help is appreciated, Chen Yang. -Original Message- From: John Brown [mailto:johnbrown...@hotmail.com] Sent: May-24-12 5:33 AM To: fop-users@xmlgraphics.apache.org Subject: RE: table of contents page number not showing in RTF output Hello Glenn, Glenn Adams wrote: > > On Wed, May 23, 2012 at 2:21 PM, Chen Yang wrote: >> >> Hey guys, > > >>I am converting xml to rtf using fop trunk ver. page numbers (table of >>content to be exact) showing up as # symbol but field codes are >>correct, if I print the document, Word will display the numbers, what >>is it that I need to do to display the numbers immediately? > > > > > > >>example: > > >>CONFLICT >>MANAGEMENT# >>DEVELOPING >>OTHERS# >>FOSTERING >>LEARNING...# >>IMPACT AND >>INFLUENCE...# >> > > > > what do you mean by "Word will display the numbers"? > He probably means that when he opens the document for the first time, # is displayed instead of page numbers, but if he refreshes the table of contents, the numbers will appear. Regards, John Brown. - 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: table of contents page number not showing in RTF output
Hello Glenn, Glenn Adams wrote: > > On Wed, May 23, 2012 at 2:21 PM, Chen Yang wrote: >> >> Hey guys, > > >>I am converting xml to rtf using fop trunk ver. page numbers (table of >>content to be exact) showing up as # symbol but field codes are >>correct, if I print the document, Word will display the numbers, what >>is it that I need to do to display the numbers immediately? > > > > > > >>example: > > >>CONFLICT MANAGEMENT# >>DEVELOPING OTHERS# >>FOSTERING LEARNING...# >>IMPACT AND INFLUENCE...# >> > > > > what do you mean by "Word will display the numbers"? > He probably means that when he opens the document for the first time, # is displayed instead of page numbers, but if he refreshes the table of contents, the numbers will appear. Regards, John Brown. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: table of contents page number not showing in RTF output
what do you mean by "Word will display the numbers"? On Wed, May 23, 2012 at 2:21 PM, Chen Yang wrote: > Hey guys, > > I am converting xml to rtf using fop trunk ver. page numbers (table of > content to be exact) showing up as # symbol but field codes are correct, if > I print the document, Word will display the numbers, what is it that I need > to do to display the numbers immediately? > > ** ** > > example: > > CONFLICT > MANAGEMENT > # > > DEVELOPING > OTHERS > # > > FOSTERING > LEARNING.. > # > > IMPACT AND > INFLUENCE.. > # > > ** ** > > thanks > > ** ** > > ** ** > > ** ** > > **- **Chen Yang** > > ** ** >
table of contents page number not showing in RTF output
Hey guys, I am converting xml to rtf using fop trunk ver. page numbers (table of content to be exact) showing up as # symbol but field codes are correct, if I print the document, Word will display the numbers, what is it that I need to do to display the numbers immediately? example: CONFLICT MANAGEMENT.. .. # DEVELOPING OTHERS.. .. # FOSTERING LEARNING .. # IMPACT AND INFLUENCE... ... # thanks - Chen Yang
Re: RTF output: spaces added after { } \ characters
cbowditch wrote: > > What version of FOP are you using? Can you attach a sample FO File that > can be used to demonstrate the issue? > > Thanks, > > Chris > I'm using FOP 0.95. I've attached a stripped down FO file that illustrates the issue. http://old.nabble.com/file/p27989770/test.fo test.fo When you generate the RTF file you'll notice a space after the { } and \ characters. Here's the command I'm using to generate the RTF file: fop test.fo -rtf testoutput.rtf -- View this message in context: http://old.nabble.com/RTF-output%3A-spaces-added-after-%7B-%7D-%5C-characters-tp27937568p27989770.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
Re: RTF output: spaces added after { } \ characters
JoshC wrote: Hi Everyone, I'm using FOP to generate RTF output. The problem I'm having is that FOP adds a space after each of the following three characters in RTF output: { } \. In PDF output it does not add spaces after these characters. It seems to only be on these characters, though I haven't done a thorough test of other characters. Does anyone know why FOP might be doing this or if there is a workaround to make it stop adding spaces in RTF output? What version of FOP are you using? Can you attach a sample FO File that can be used to demonstrate the issue? Thanks, Chris - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
RTF output: spaces added after { } \ characters
Hi Everyone, I'm using FOP to generate RTF output. The problem I'm having is that FOP adds a space after each of the following three characters in RTF output: { } \. In PDF output it does not add spaces after these characters. It seems to only be on these characters, though I haven't done a thorough test of other characters. Does anyone know why FOP might be doing this or if there is a workaround to make it stop adding spaces in RTF output? Thanks, Josh -- View this message in context: http://old.nabble.com/RTF-output%3A-spaces-added-after-%7B-%7D-%5C-characters-tp27937568p27937568.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
Issues with RTF Output
Hi List, formatting my documents to PDF works great, but when I try to export to RTF, I experience the following issues, which i think are bugs: 1. if I put a table within a block that has a start-intend attribute, it is ignored and the table is drawn in Word2003 at the left border of the page. start-intend should be inherited and is displayed correctly in PDF. 2. when specifying width OR height in external-graphics, the proportions of the image should not be changed. But specifying width doesn't change height. Well, as i could fix these issues with margin-left in the table and manually calculating the height in the image, I were not able to display overlapping text in my document. This works with PDF, but not with RTF. The b is not displayed: a b I assume that this is a limitation of RTF. I tried to overlap the text with Word, but could not find other solutions than text boxes. Has anyone had luck in displaying overlapping text with RTF? Or is there a trick to let FOP produce text boxes? Thanks in advance, Alexander Simon This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
reference-orientation and rtf output
Hi, I was wondering if reference-orientation is supported in Rich Text output. I can get it work fine when producing a PDF, but the same xsl:fo doesn't work for RTF output and the console doesn't flag any errors. Here's a fragment of the xsl:fo If it isn't supported, I was wondering if there might be a work around that anyone could suggest. I'm using 0.93 but I can also just compile my own version from svn if need be. Thanks Richard _ The next generation of Hotmail is here! http://www.newhotmail.co.uk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: RTF-Output with FOP 0.93 looks terrible
Hi Vincent, great :-) But the Stylesheet for generating an OpenOffice- or better OpenDocument has not finished at all. That's a pitty :-( Have you tried to open an OpenDocument-file in Microsoft Word? Most users are using word (a terrible application) and want to have a modifiable document which can be opened in Microsoft Word. So the only way is RTF at the moment :-( I have to find another way to make it looks better in word. Thanks for the link to the docbook2odf-project. Best Regards, Kerstin Vincent Hennebert schrieb: Hi, leeloo5e79-devel yahoo de a écrit : > Hi Jeremias, > > you are correct: RTF is a terrible format. But seems to be the only way to > get a modifiable document. There are also tools like which convert PDF to > Word-Documents. But these tools also had the problem in correct converting > PDF. > In this case I'm using DocBook to create complex documentations. With the > DocBook-Stylesheets I want to generate e.g. HTML, PDF and also an for > Microsoft Word applicable Document. If you want to generate a modifiable format from DocBook you will probably have much more success with the docbook2odf [1] or the roundtrip part of the DocBook stylesheets. I haven't looked at either of those. The link below might be interesting. The DocBook stylesheets allow to convert DocBook to WordML (and also ODF now, I believe) and vice-versa. Have a look at the docbook-apps@ archives and the DocBook website. Anyway, if I had to produce modifiable documents from DocBook sources I would certainly invest my time on such solutions rather than dealing with RTF. [1] http://open.comsultia.com/docbook2odf/ HTH, Vincent - Wissenswertes zum Thema PC, Zubehör oder Programme.BE A BETTER INTERNET-GURU!
Re: RTF-Output with FOP 0.93 looks terrible
Hi, leeloo5e79-devel yahoo de a écrit : > Hi Jeremias, > > you are correct: RTF is a terrible format. But seems to be the only way to > get a modifiable document. There are also tools like which convert PDF to > Word-Documents. But these tools also had the problem in correct converting > PDF. > In this case I'm using DocBook to create complex documentations. With the > DocBook-Stylesheets I want to generate e.g. HTML, PDF and also an for > Microsoft Word applicable Document. If you want to generate a modifiable format from DocBook you will probably have much more success with the docbook2odf [1] or the roundtrip part of the DocBook stylesheets. I haven't looked at either of those. The link below might be interesting. The DocBook stylesheets allow to convert DocBook to WordML (and also ODF now, I believe) and vice-versa. Have a look at the docbook-apps@ archives and the DocBook website. Anyway, if I had to produce modifiable documents from DocBook sources I would certainly invest my time on such solutions rather than dealing with RTF. [1] http://open.comsultia.com/docbook2odf/ HTH, Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RTF-Output with FOP 0.93 looks terrible
Hi Jeremias, you are correct: RTF is a terrible format. But seems to be the only way to get a modifiable document. There are also tools like which convert PDF to Word-Documents. But these tools also had the problem in correct converting PDF. In this case I'm using DocBook to create complex documentations. With the DocBook-Stylesheets I want to generate e.g. HTML, PDF and also an for Microsoft Word applicable Document. Because of Adrian's question of what RTF viewing application I'm using (I used Microsoft Word), I used OpenOffice and hey it looks good - relativley. Only some XSL-FO-Features are missing (I described them in my answer of Adrians answer). I will create a small DocBook-Document with some XSL-FO-Features which shows the occured problems. So maybe we find a solution ;-) Thanks a lot. Best Regards, Kerstin ### Let me start by stating that RTF is a terrible format to begin with (well, that's a personal opinion). Generally, it's not possible to map every feature in XSL-FO into RTF. But then, RTF is probably also the weakest output format in Apache FOP. I would only recommend RTF output for relatively simple business letters where people have to do some modifications before they are sent to the client. I'd be interested in the use case you have to convert DocBook to RTF. Please note that the RTF output is optimized for Microsoft Word. It will definitely look terrible in OpenOffice. On 28.06.2007 14:04:32 leeloo5e79-devel wrote: > I'm using FOP 0.93 to generate e.g. PDF from DocBook-XML with > DocBook-XSL. Everything looks fine in PDF. 71 sites are generated in > PDF :-))) > But the RTF-Output just looks terrible and has about 1900 !!! sites. > Seems on every page is one line or one table row printed out. The > content (e.g. lines) should be keep together or something else. Is > still working on this feature or has i just configure something to make it > work better? > > Thanks, > Kerstin Jeremias Maerki - Yahoo! Messenger - kostenlos* mit Familie und Freunden von PC zu PC telefonieren.
Re: Re: RTF-Output with FOP 0.93 looks terrible
Hi Adrian, sorry for my late reply. Seems my email-provider are sorting out some messages. I just find the list on nabbles.com. I used Microsoft Word to display the generated RTF-Output. So I assumed Microsoft Word would display the RTF in the correct way. But seems it didn't. Because of your question, which application I'm using, I just used OpenOffice and hey it looks good - relatively ;-) Page breaks doesn't work.There are no page numbers in the TOC, but links to the chapters are fine :-) In every case tables have a width of 3,53cm. But shouldn't they display on the whole available width of the page?! I'm using processing-instructions at my xml file to set e.g. the last page number or background-colors. These settings are displayed correctly in the PDF-Output, so the FO seems to be correctly. It supposed to be missing features for generating RTF with FOP. Thanks, Best Regards, Kerstin ## Hi Kerstin, Sorry but could you be a little more descriptive of the problem you are having? Providing some FO source examples would be of great help in examining any problems you are experiencing with the RTF output. Incidentally which RTF viewing application are you using to display/test the RTF output? Cheers, Adrian. [EMAIL PROTECTED] wrote: > I'm using FOP 0.93 to generate e.g. PDF from DocBook-XML with > DocBook-XSL. Everything looks fine in PDF. 71 sites are generated in PDF > :-))) > But the RTF-Output just looks terrible and has about 1900 !!! sites. > Seems on every page is one line or one table row printed out. The > content (e.g. lines) should be keep together or something else. Is still > working on this feature or has i just configure something to make it > work better? > > Thanks, > Kerstin > > > > *BE A BETTER WELTENBUMMLER:* Jetzt Frage stellen und einen von 44 iPods > gewinnen! > <http://de.rd.yahoo.com/evt=48734/*http://de.promotions.yahoo.com/clever/be-a-better/weltenbummler.html> > > - Alles was der Gesundheit und Entspannung dient.BE A BETTER MEDIZINMANN!
Re: RTF-Output with FOP 0.93 looks terrible
Let me start by stating that RTF is a terrible format to begin with (well, that's a personal opinion). Generally, it's not possible to map every feature in XSL-FO into RTF. But then, RTF is probably also the weakest output format in Apache FOP. I would only recommend RTF output for relatively simple business letters where people have to do some modifications before they are sent to the client. I'd be interested in the use case you have to convert DocBook to RTF. Please note that the RTF output is optimized for Microsoft Word. It will definitely look terrible in OpenOffice. On 28.06.2007 14:04:32 leeloo5e79-devel wrote: > I'm using FOP 0.93 to generate e.g. PDF from DocBook-XML with > DocBook-XSL. Everything looks fine in PDF. 71 sites are generated in > PDF :-))) > But the RTF-Output just looks terrible and has about 1900 !!! sites. > Seems on every page is one line or one table row printed out. The > content (e.g. lines) should be keep together or something else. Is > still working on this feature or has i just configure something to make it > work better? > > Thanks, > Kerstin Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RTF-Output with FOP 0.93 looks terrible
Hi Kerstin, Sorry but could you be a little more descriptive of the problem you are having? Providing some FO source examples would be of great help in examining any problems you are experiencing with the RTF output. Incidentally which RTF viewing application are you using to display/test the RTF output? Cheers, Adrian. [EMAIL PROTECTED] wrote: I'm using FOP 0.93 to generate e.g. PDF from DocBook-XML with DocBook-XSL. Everything looks fine in PDF. 71 sites are generated in PDF :-))) But the RTF-Output just looks terrible and has about 1900 !!! sites. Seems on every page is one line or one table row printed out. The content (e.g. lines) should be keep together or something else. Is still working on this feature or has i just configure something to make it work better? Thanks, Kerstin *BE A BETTER WELTENBUMMLER:* Jetzt Frage stellen und einen von 44 iPods gewinnen! <http://de.rd.yahoo.com/evt=48734/*http://de.promotions.yahoo.com/clever/be-a-better/weltenbummler.html> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RTF-Output with FOP 0.93 looks terrible
I'm using FOP 0.93 to generate e.g. PDF from DocBook-XML with DocBook-XSL. Everything looks fine in PDF. 71 sites are generated in PDF :-))) But the RTF-Output just looks terrible and has about 1900 !!! sites. Seems on every page is one line or one table row printed out. The content (e.g. lines) should be keep together or something else. Is still working on this feature or has i just configure something to make it work better? Thanks, Kerstin - BE A BETTER WELTENBUMMLER: Jetzt Frage stellen und einen von 44 iPods gewinnen!
RTF output with images
Hi, I'm trying to produce RTF output with embedded images from within a servlet. The RTF output document is missing the images. In their place is a stack trace like the following (text in the RTF document is unaffected): org.apache.fop.render.rtf.rtflib.rtfdoc.RtfExternalGraphic$ExternalGraphicEx ception org.apache.fop.render.rtf.rtflib.rtfdoc.RtfExternalGraphic$ExternalGraphicEx ception: The attribute 'url' of is null. My interpretation of this is that the RTF formatter is trying to access the 'url' attribute of element and the reason it can't find it is that the attribute is actually called 'src'. Due to the environment the servlet operates in, I'm using my own URIResolver to actually get the images, but since this works fine for PDF output, I assume the problem is with the RTF output classes. Has anyone seen this problem before? Is there a work around? Thanks Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: RTF output
There's the intention to use the wrapper classes, which are already used by rest of FOP. Jeremias made a similiar suggestion on 4th Oct. I will see, if i can invest some time on that task this week-end. Kind regards, Peter Herweg -Ursprungliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag von Andreas L Delmelle Gesendet: Dienstag, 25. Oktober 2005 21:10 An: fop-users@xmlgraphics.apache.org Cc: fop-dev@xmlgraphics.apache.org Betreff: Re: RTF output On Oct 25, 2005, at 00:20, Tony Morris wrote: > I don't have my test case with me, since I am at work at the moment. > Otherwise, what I recall is setting the size of an external-graphic > to the > exact number of pixels (I think if I didn't, the RTF renderer > wasn't happy), > the image appeared scaled down, but if I set the image size to say, > 10x the > number of pixels, it would not appear 10x bigger than the scaled > down image, > but about the size I would expect normally. Granted, I was using MS > Word > 2003 for verification, which may well be the culprit. (cc'ing fop-dev, since the message contains pointers on the causes of this problem, and may help someone devise a solution for it) Well, we shouldn't be blaming M$ for everything --however tempting it may be ;-) All I can say is that the other renderers all use the same set of image library wrappers. The RTF renderer currently is the only exception (support for external-graphics was reintroduced for RTF about a month ago). AFAICT, in the long run, it's the intention of switching to the same set of wrappers for the RTF renderer. Doing so could mean that your problem disappears, I'm not sure. What is more than certain is that the current code in the RTF lib is not 100% correct, and even seems to make the same mistake in interpretation of the related properties (height/width) that FOP 0.20.5 made, namely interpreting the value of these properties as the dimensions of the image itself instead of taking them to be the dimensions of the image's surrounding box. Looking at the related code in the RTF library, it seems the 'height' and 'width' of the external-graphic are interpreted as 'desired height' and 'desired width', which is wrong if neither content-height nor content-width were specified as 'scale-to-fit'. One can define an external-graphic with height="10cm" and still have the content take up only 3cm. Roughly, it seems line 952 in the RTFHandler: newGraphic.setWidth(eg.getWidth().getValue() / 1000f + "pt"); is too simplistic, and should at least become something like: if (eg.getWidth().getEnum() != Constants.EN_AUTO) { if (eg.getContentWidth().getEnum() == Constants.EN_SCALE_TO_FIT) { newGraphic.setWidth(eg.getWidth().getValue() / 1000f + "pt"); } ... ... } So, only if width is not specified as "auto" *and* content-width is specified as "scale-to-fit" (or is of length equal to the non-auto width) does the external-graphic's width become the desired width for the image. If, for instance, width="auto" *and* content-width="auto", the following could be used (instrinsic width of the image): newGraphic.setWidth("100%"); I don't think it's all that difficult to tweak the RTFHandler into handling these properties correctly, but then again, the question can be asked whether it's all worth it. If the RTF renderer is going to switch to the default image lib wrappers anyway, this effort would perhaps be completely in vain. Anyone? Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RTF output
On Oct 25, 2005, at 00:20, Tony Morris wrote: I don't have my test case with me, since I am at work at the moment. Otherwise, what I recall is setting the size of an external-graphic to the exact number of pixels (I think if I didn't, the RTF renderer wasn't happy), the image appeared scaled down, but if I set the image size to say, 10x the number of pixels, it would not appear 10x bigger than the scaled down image, but about the size I would expect normally. Granted, I was using MS Word 2003 for verification, which may well be the culprit. (cc'ing fop-dev, since the message contains pointers on the causes of this problem, and may help someone devise a solution for it) Well, we shouldn't be blaming M$ for everything --however tempting it may be ;-) All I can say is that the other renderers all use the same set of image library wrappers. The RTF renderer currently is the only exception (support for external-graphics was reintroduced for RTF about a month ago). AFAICT, in the long run, it's the intention of switching to the same set of wrappers for the RTF renderer. Doing so could mean that your problem disappears, I'm not sure. What is more than certain is that the current code in the RTF lib is not 100% correct, and even seems to make the same mistake in interpretation of the related properties (height/width) that FOP 0.20.5 made, namely interpreting the value of these properties as the dimensions of the image itself instead of taking them to be the dimensions of the image's surrounding box. Looking at the related code in the RTF library, it seems the 'height' and 'width' of the external-graphic are interpreted as 'desired height' and 'desired width', which is wrong if neither content-height nor content-width were specified as 'scale-to-fit'. One can define an external-graphic with height="10cm" and still have the content take up only 3cm. Roughly, it seems line 952 in the RTFHandler: newGraphic.setWidth(eg.getWidth().getValue() / 1000f + "pt"); is too simplistic, and should at least become something like: if (eg.getWidth().getEnum() != Constants.EN_AUTO) { if (eg.getContentWidth().getEnum() == Constants.EN_SCALE_TO_FIT) { newGraphic.setWidth(eg.getWidth().getValue() / 1000f + "pt"); } ... ... } So, only if width is not specified as "auto" *and* content-width is specified as "scale-to-fit" (or is of length equal to the non-auto width) does the external-graphic's width become the desired width for the image. If, for instance, width="auto" *and* content-width="auto", the following could be used (instrinsic width of the image): newGraphic.setWidth("100%"); I don't think it's all that difficult to tweak the RTFHandler into handling these properties correctly, but then again, the question can be asked whether it's all worth it. If the RTF renderer is going to switch to the default image lib wrappers anyway, this effort would perhaps be completely in vain. Anyone? Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RTF output
> Tony Morris escribió: > >> Thanks, by explicitly setting a width and height, the problem >> disappeared - it only occurred for the RTF renderer (though I only >> tried the PDF one as well). The sizes themselves seem to be a tad >> obscure though. Tony, can you be a bit more precise as to what you mean by this last sentence? All I know is that, in FOP Trunk, with 'height' and 'width' you only specify the dimension of the area. Use them in combination with 'content-height' and 'content-width' to get appropriate results. I don't have my test case with me, since I am at work at the moment. Otherwise, what I recall is setting the size of an external-graphic to the exact number of pixels (I think if I didn't, the RTF renderer wasn't happy), the image appeared scaled down, but if I set the image size to say, 10x the number of pixels, it would not appear 10x bigger than the scaled down image, but about the size I would expect normally. Granted, I was using MS Word 2003 for verification, which may well be the culprit. I will get more exact details when I go home. Tony Morris Software Engineer IBM Software Group, Tivoli Software Gold Coast, Australia (GMT +10) Sun Certified Programmer for the Java 2 Platform 1.4 Sun Certified Programmer for the Java 2 Platform 5.0 Sun Certified Developer for the Java 2 Platform "I am an engineer. If I fail to accept what others accept, I earn their opprobrium." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RTF output
On Oct 22, 2005, at 15:01, Glen Mazza wrote: I wonder if setting the margins on the fo:region-body (instead of the fo:external-graphic) would also have solved this. The example you gave had an empty without dimensions, but you may have been just abbreviating the sample by removing those dimensions. I doubt it, since many of our own layout-engine testcases have similar, minimal page-masters. If this were a problem, it would have surfaced much sooner... In the meantime, I've pinpointed the culprits. Seems it's the two calls one lines 952 and 955 in RTFHandler. These should first check whether the respective property has an enum value of "auto" instead of assuming that an explicit dimension will always be available, but what exactly should happen in case either value is "auto", I'm not sure about that. I'd say the values of content-height and content- width should also be checked, and subsequently, the total bpd/ipd of the area containing the graphic can be inferred from its original size (?) Tony Morris escribió: Thanks, by explicitly setting a width and height, the problem disappeared - it only occurred for the RTF renderer (though I only tried the PDF one as well). The sizes themselves seem to be a tad obscure though. Tony, can you be a bit more precise as to what you mean by this last sentence? All I know is that, in FOP Trunk, with 'height' and 'width' you only specify the dimension of the area. Use them in combination with 'content-height' and 'content-width' to get appropriate results. HTH! Greetz, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RTF output
I wonder if setting the margins on the fo:region-body (instead of the fo:external-graphic) would also have solved this. The example you gave had an empty without dimensions, but you may have been just abbreviating the sample by removing those dimensions. Glen Tony Morris escribió: Thanks, by explicitly setting a width and height, the problem disappeared - it only occurred for the RTF renderer (though I only tried the PDF one as well). The sizes themselves seem to be a tad obscure though. At 07:32 PM 22/10/2005, Andreas L Delmelle wrote: On Oct 22, 2005, at 11:12, Tony Morris wrote: Hi, I attempt to generate RTF using the Ant task: I receive the following error: [fop] 22/10/2005 19:04:42 org.apache.fop.fo.properties.EnumLength getValue [fop] SEVERE: getValue() called on AUTO length [fop] 22/10/2005 19:04:42 org.apache.fop.fo.properties.EnumLength getValue [fop] SEVERE: getValue() called on AUTO length Can anyone provide any pointers to what might be the issue? I'm not absolutely sure, but most likely, this message is caused by the default values of height/content-height/content-width... on fo:external-graphic. All these properties default to a value of "auto" and somewhere the property is being queried for its value without checking first whether it has an enum value. Have you tried different output targets? Same problem? If not, the cause of this would be somewhere in the RTFRenderer. To remove these errors, I guess you could try specifying explicit values for height/content-height etc. It's not ideal, but should suffice as a workaround until we manage to track down the unchecked call to getValue(). Greetz, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tony Morris http://www.tmorris.net/ - 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: RTF output
Thanks, by explicitly setting a width and height, the problem disappeared - it only occurred for the RTF renderer (though I only tried the PDF one as well). The sizes themselves seem to be a tad obscure though. At 07:32 PM 22/10/2005, Andreas L Delmelle wrote: On Oct 22, 2005, at 11:12, Tony Morris wrote: Hi, I attempt to generate RTF using the Ant task: I receive the following error: [fop] 22/10/2005 19:04:42 org.apache.fop.fo.properties.EnumLength getValue [fop] SEVERE: getValue() called on AUTO length [fop] 22/10/2005 19:04:42 org.apache.fop.fo.properties.EnumLength getValue [fop] SEVERE: getValue() called on AUTO length Can anyone provide any pointers to what might be the issue? I'm not absolutely sure, but most likely, this message is caused by the default values of height/content-height/content-width... on fo:external-graphic. All these properties default to a value of "auto" and somewhere the property is being queried for its value without checking first whether it has an enum value. Have you tried different output targets? Same problem? If not, the cause of this would be somewhere in the RTFRenderer. To remove these errors, I guess you could try specifying explicit values for height/content-height etc. It's not ideal, but should suffice as a workaround until we manage to track down the unchecked call to getValue(). Greetz, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tony Morris http://www.tmorris.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RTF output
On Oct 22, 2005, at 11:12, Tony Morris wrote: Hi, I attempt to generate RTF using the Ant task: force="true"/> I receive the following error: [fop] 22/10/2005 19:04:42 org.apache.fop.fo.properties.EnumLength getValue [fop] SEVERE: getValue() called on AUTO length [fop] 22/10/2005 19:04:42 org.apache.fop.fo.properties.EnumLength getValue [fop] SEVERE: getValue() called on AUTO length Can anyone provide any pointers to what might be the issue? I'm not absolutely sure, but most likely, this message is caused by the default values of height/content-height/content-width... on fo:external-graphic. All these properties default to a value of "auto" and somewhere the property is being queried for its value without checking first whether it has an enum value. Have you tried different output targets? Same problem? If not, the cause of this would be somewhere in the RTFRenderer. To remove these errors, I guess you could try specifying explicit values for height/content-height etc. It's not ideal, but should suffice as a workaround until we manage to track down the unchecked call to getValue(). Greetz, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RTF output
Using the following fo file: http://www.w3.org/1999/XSL/Format";> I attempt to generate RTF using the Ant task: I receive the following error: [fop] 22/10/2005 19:04:42 org.apache.fop.fo.properties.EnumLength getValue [fop] SEVERE: getValue() called on AUTO length [fop] 22/10/2005 19:04:42 org.apache.fop.fo.properties.EnumLength getValue [fop] SEVERE: getValue() called on AUTO length Can anyone provide any pointers to what might be the issue? -- Tony Morris http://www.tmorris.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]