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. ?xml version=1.0 encoding=UTF-8? xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xmlns:fo=http://www.w3.org/1999/XSL/Format; xsl:output indent=yes / xsl:template match=/ fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; !-- defines page layout -- fo:layout-master-set fo:simple-page-master master-name=first page-height=29.7cm page-width=21cm margin-top=2.54cm margin-bottom=2.54cm margin-left=3.17cm margin-right=3.17cm fo:region-body margin-top=0cm / fo:region-before extent=0cm / fo:region-after extent=0cm / /fo:simple-page-master fo:page-sequence-master master-name=psmA fo:repeatable-page-master-alternatives fo:conditional-page-master-reference master-reference=first / /fo:repeatable-page-master-alternatives /fo:page-sequence-master /fo:layout-master-set fo:page-sequence master-reference=psmA xsl:variable name=title select=/getabstract/header/title / fo:flow flow-name=xsl-region-body fo:block font-size=11pt font-family=Times, ArialUni fo:block font-size=14pt font-family=Times, ArialUni font-weight=bold color=#FF Book Information /fo:block fo:block Title: xsl:value-of select=/getabstract/header/title / /fo:block fo:block Subtitle: xsl:value-of select=/getabstract/header/subtitle / /fo:block fo:block Author: xsl:value-of select=/getabstract/header/authors / /fo:block fo:block Copyright: xsl:value-of select=/getabstract/header/copyright / /fo:block fo:block Year: xsl:value-of select=/getabstract/header/year / /fo:block fo:block Pages: xsl:value-of select=/getabstract/header/pages / /fo:block fo:block ISBN-13: xsl:value-of select=/getabstract/header/isbn / /fo:block xsl:if test=/getabstract/langRights fo:block xsl:value-of select=/getabstract/langRights / /fo:block /xsl:if xsl:if test=/getabstract/formatsLine fo:block xsl:value-of select=/getabstract/formatsLine / /fo:block /xsl:if fo:block#xA0;/fo:block fo:block Teaser: /fo:block fo:block xsl:value-of select=/getabstract/editorialinfo/emailsentence / /fo:block fo:block#xA0;/fo:block fo:block Email text: /fo:block fo:block xsl:value-of select=/getabstract/editorialinfo/emailsentenceweekly / /fo:block fo:block#xA0;/fo:block fo:block Key Words: /fo:block fo:block xsl:value-of select=/getabstract/editorialinfo/keywords / /fo:block fo:block#xA0;/fo:block /fo:block fo:block font-size=11pt font-family=Times, ArialUni fo:block font-size=14pt font-family=Times, ArialUni font-weight=bold color=#FF getAbstract Ratings /fo:block
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
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
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: 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 cy...@hrsg.ca 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** ** **
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: fo:block a /fo:block fo:block margin-top=-9mm b /fo:block 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 fo:table-cell display-align=center border=0.5pt solid black fo:block-container reference-orientation=0 fo:block text-align=center 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: 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
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: 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]
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!
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]
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
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 fo:region-body/ 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
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]
RTF output
Using the following fo file: ?xml version=1.0 encoding=utf-8? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master master-name=content page-height=29.7cm page-width=21cm fo:region-body/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=content fo:flow flow-name=xsl-region-body fo:block fo:external-graphic src=images/JavaCrtfd_Prg.gif/ /fo:block /fo:flow /fo:page-sequence /fo:root I attempt to generate RTF using the Ant task: fop format=application/rtf fofile=in.fo outfile=out.rtf 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? -- Tony Morris http://www.tmorris.net/ - 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: fop format=application/rtf fofile=in.fo outfile=out.rtf 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] -- Tony Morris http://www.tmorris.net/ - 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 fo:region-body/ 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: fop format=application/rtf fofile=in.fo outfile=out.rtf 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] -- 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]
