AW: RTF export enhancement
Jeremias Maerki wrote: Point 3: Yes, for tables, you will somehow need to keep track of the various columns. I don't know the details of the current table support in RTF in detail so I can't help off-hand. Maybe Peter Herweg can help some more. Currently the class TableContext keeps track of the various columns. It's also responsible for cell-spannings and widths. Kind regards, Peter Herweg
AW: svn commit: r372916 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/render/rtf/RTFHandler.java
Right now, it works, and it enhances our RTF output, so there's no need to revert, but I'm wondering if there isn't an alternative solution that would look/feel better. Yes, but it does not work very good. There is no exception anymore, but column width are not calculated correctly. I would not mind to remove usage of TableLayoutManager and simply pass a SimplePercentBaseContext with base length always being 0, until we find a better solution. Kind regards, Peter Herweg -Ursprungliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag von Andreas L Delmelle Gesendet: Freitag, 27. Januar 2006 18:28 An: fop-dev@xmlgraphics.apache.org Betreff: Re: svn commit: r372916 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/render/rtf/RTFHandler.jav a On Jan 27, 2006, at 18:10, [EMAIL PROTECTED] wrote: Hi Peter and others, I really don't mean to be a pest, but this somehow doesn't feel right. I just wonder if any of you share the same concern, or can offer me some solid justification... Although I do see the necessity of it to make percentage values work right, it seems a bit hybrid (if you catch the drift) to bypass the whole layoutengine for RTF output on the one hand, and on the other hand import classes from the layoutmgr package into the RTFHandler. Right now, it works, and it enhances our RTF output, so there's no need to revert, but I'm wondering if there isn't an alternative solution that would look/feel better. Any thoughts? Cheers, Andreas Author: pherweg Date: Fri Jan 27 09:10:31 2006 New Revision: 372916 URL: http://svn.apache.org/viewcvs?rev=372916view=rev Log: RTF: testcase 'tableunits.fo' failed because there was no PercentBaseContext passed. Modified: xmlgraphics/fop/trunk/src/java/org/apache/fop/render/rtf/ RTFHandler.java Modified: xmlgraphics/fop/trunk/src/java/org/apache/fop/render/rtf/ RTFHandler.java URL: http://svn.apache.org/viewcvs/xmlgraphics/fop/trunk/src/java/ org/apache/fop/render/rtf/RTFHandler.java? rev=372916r1=372915r2=372916view=diff == --- xmlgraphics/fop/trunk/src/java/org/apache/fop/render/rtf/ RTFHandler.java (original) +++ xmlgraphics/fop/trunk/src/java/org/apache/fop/render/rtf/ RTFHandler.java Fri Jan 27 09:10:31 2006 @@ -63,6 +63,8 @@ import org.apache.fop.fo.pagination.StaticContent; import org.apache.fop.fo.Constants; import org.apache.fop.fo.FOText; +import org.apache.fop.layoutmgr.table.TableContentLayoutManager; +import org.apache.fop.layoutmgr.table.TableLayoutManager;
AW: Size of images incorrect?
Yes, you are right. I'm quite surprised by myself. I will try to fix this the next few days. But while playing with the rtf code i noticed following behaviour (Word2000 SP3): If i write \picscalex75 \picscaley75 \picwgoal1500 \pichgoal900 i get an image width of about 2cm in Word2000 (as expected), but when i write \picscalex100 \picscaley100 \picwgoal1125 \pichgoal675 it's larger. Can anybody explain this? Kind regards, Peter Herweg -Ursprungliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag von Jeremias Maerki Gesendet: Montag, 12. Dezember 2005 17:51 An: fop-dev@xmlgraphics.apache.org Betreff: RTF: Size of images incorrect? (Mostly for Peter Herweg, I guess) I tried to implement SVG support for RTF output by converting the SVG images through Batik's JPEGTranscoder to a JPEG. That part was easy and done in 10 minutes. However, I noticed that all images are currently painted much too small in MS Word Viewer 2003 and OpenOffice 2.0. In RTFHandler, the image size is set in points. However, it looks like RtfExternalGraphic just ignores the pt at the end of the string. It only looks for percentages. Otherwise, it calculates with twips internally (1 twip = 1/20 pt). IMO, picscalex and picscaley should always be 100 and picwgoal and pichgoal should be set to the right dimension in twips, i.e. convert to twips already in the RTFHandler to keep the RTF library FOP-independant. Any ideas? Can anybody confirm that I'm not seeing ghosts here? :-) Thanks. Jeremias Maerki
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
AW: rtf-external-graphics
Jeremias Maerki wrote: I'll look into it tomorrow. Peter's last change for external-graphics in RTF made me wonder if we shouldn't actually change the whole code there and use the image library wrappers the normal renderers use. Like this we could use the image cache, more image formats and URI resolution the same way as for the other output formats. I have played around with JAI to support other file formats (e.g. GIF, BMP). This works good but it's quite slow. I did not know that there are image library wrappers. Can you point me to them? Are they contained in XML Graphics Commons? Regards, Peter Herweg
AW: rtf ignoring TableBody et al
I am checking the rtf results with Word 2000 SP3. Regards, Peter Herweg -Ursprungliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag von Matthew L Daniel Gesendet: Dienstag, 20. September 2005 17:50 An: fop-dev@xmlgraphics.apache.org Betreff: Re: rtf ignoring TableBody et al The warning is an indicator that there are still a few things in RTF support that need fixing. So is there someone who owns this class? How long has it been out-of-sync - that is, is it in the same condition as TXTRenderer? Also, while this is probably not the correct forum for this question, what has been the reference tool for checking the RTF output? OpenOffice.org 2.0 beta won't even correctly render the SimpleTable from jfor. Since Word Viewer 2003 does, I'm inclined to think it's an OOo bug more than a jfor bug. However, I hope this he-said-she-said illustrates my correctness concern for the RTF output. -- /v\atthew
AW: rtf ignoring TableBody et al
Yes, there are few nodes types missing, because i just added the node types,
which are implemented in rtf module.
But you are right: TableBody is implemented, but is missing in the
if-structure. I'll add it.
There is also support for ExternalGraphics, but i guess this won't work so i
did not add it to if-structure. This will be my next task in rtf module.
Regards,
Peter Herweg
-Ursprungliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Auftrag von Andreas L Delmelle
Gesendet: Dienstag, 20. September 2005 00:58
An: fop-dev@xmlgraphics.apache.org
Betreff: Re: rtf ignoring TableBody et al
On Sep 20, 2005, at 00:28, Matthew L Daniel wrote:
I am using trunk code and with an input FO that produces excellent PDF
output, I am seeing the following messages about lots of ignored
instances.
After checking RTFHandler.java, it seems they are omitted from the very
large instance-switch in invokeDeferredEvent.
My question is if this is in progress code or if RTFHandler has been
broken like this for a while?
Seems like it's broken. At least, there's a few node-types missing,
amongst which precisely TableBody, TableHeader, TableFooter,
InstreamForeignObject, SVGElement, ExternalGraphic...
I'm going to leave this for now, since I don't know too much about the
RTF Rendering code --maybe those node-types were left out for a good
reason, I'm not sure.
At first glance, the whole structure:
if( fo instanceof PageSequence ) {
//do something
} else if( fo instanceof Flow ) {
//do something
} ...
would probably better be replaced by one
switch( fo.getNameId() ) {
case Constants.FO_PAGE_SEQUENCE:
//do something
break;
case Constants.FO_FLOW:
//do something
break;
...
}
The least this would do is avoid a number of unnecessary calls to
instanceof.
Note to Peter Herweg: I think I see now what you meant by the many
'if-then-else-if's. I hope you can put the above comment to good use...
Cheers,
Andreas
AW: svn commit: r264856 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/render/rtf: TextAttributesConverter.java rtflib/rtfdoc/RtfText.java
Thank you, Finn!
Regards,
Peter Herweg
-Ursprungliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Auftrag von Finn Bock
Gesendet: Mittwoch, 31. August 2005 01:10
An: fop-dev@xmlgraphics.apache.org
Betreff: Re: svn commit: r264856 - in
/xmlgraphics/fop/trunk/src/java/org/apache/fop/render/rtf:
TextAttributesConverter.java rtflib/rtfdoc/RtfText.java
[EMAIL PROTECTED] wrote:
+
+ private static void attrBaseLineShift(EnumLength baselineShift,
RtfAttributes rtfAttr) {
+
+ String s = baselineShift.getString();
Use baselineShift.getEnum() to get the enum values that is assigned to a
length. Never ever use the getString() method, it is purely there for
debugging and for use by the testing frameworks.
I have also fixed this in SVN.
regards,
finn
AW: enhancing rtf support
I don't like the idea of removing functionality. Yes, I agree with you. (2) I want to test support for fo:table. This had worked quite good before i introduced the delaying. But now the table-columns get not processed. This will be fixed when (1) is finished. Sorry, i didn't notice this malfunction. Can this not be achieved with (1) still in place? I'm sure, this is possible. But i don't think the current one is the best way. The tables don't work because I iterate recursivly through the FO and its child-nodes. But the TableColumn objects are not added to ChildNodes of the Table object. Instead they are added to a separate Array, so do also TableFooter and TableHeader (refer to Table.addChildNode). Of course i can consider this when I iterate the FO and additionaly iterate these arrays. But I'am afraid this will end up with a lot of ifs and else if's in order to process all necesarry FOs. Sounds like a lot of work to me and prone to the sorts of problems you mentioned above. Maybe you are right. Guess i have to decide this very carefully. Thank you for your advice. Kind regards, Peter Herweg -Ursprungliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag von Chris Bowditch Gesendet: Mittwoch, 24. August 2005 09:44 An: fop-dev@xmlgraphics.apache.org Betreff: Re: enhancing rtf support Peter Herweg wrote: Hello fop-team, i'd like to spend again some time with enhancing the RTF support. I have been inactive for over a year now (sorry, i was quite busy). Do you want me to send patches, because i was inactive for such a long time? Or can i access the svn repository? I have received the fop-dev-mailing list, but usually have only read the subject lines. Welcome back and as Jeremias said, its okay to commit without sending patches. I'd like to accomplish following tasks: (1) FOP has already support for white-space-treatment, linefeed-treatment and white-space-collapse. But the results of these implementations are only availabe in RTFHandler.endBlock. So i had introduced delaying processing of the FOs until endBlock. Unfortunatelly this makes the code quite complex and buggy, so i want to remove this (of course the rtf module won't support above mentioned attributes any longer). I don't like the idea of removing functionality. I read point (4) below and see that you intend to support for white-space-treatment again, but you can't think of a new approach. I think I understand the problem and I also think the current solution is the only one! So stick with it and see if you can fix the bugs. (2) I want to test support for fo:table. This had worked quite good before i introduced the delaying. But now the table-columns get not processed. This will be fixed when (1) is finished. Sorry, i didn't notice this malfunction. Can this not be achieved with (1) still in place? (3) Add support for baseline-shift=sub and baseline-shift=super. Cool. (4) After all that i have to think about how we can get white-space-treatment, linefeed-treatment and white-space-collapse to work. The difficulty is that RTFHandler handles text nodes in its implementation of FOEventHandler.characters. But at this time FOP's algorithms have not been run. Currently i see three possibilities (just ideas: any comment appreciated): a. Find a solution without delaying processing any FOs. (I don't know how this could work, in spite of implementing the complete algorithm by myself just for the RTFHandler. Maybe this is the worst solution.) IIUC you are saying you don't know how to solve (1) another way, which is why I think you should not remove that code. b. Find a solution by delaying *every* FO. This would make the FOInputHandler interface useless, because i just had to wait for a particular event (e. g. endPageSequence) and then iterate the passed PageSequence object. Would be a great effort and would introduce the same problems as described in (1). This is the current solution and the only realistic one IMHO. c. Maybe i should not process the text nodes in FOEventHandler.characters but simply add a placeholder to my rtf. When i reach endBlock i have to iterate the passed Block object and search only for FOText objects. The contents of these FOText's have to replace the placeholders. Sounds like a lot of work to me and prone to the sorts of problems you mentioned above. Chris
enhancing rtf support
Hello fop-team, i'd like to spend again some time with enhancing the RTF support. I have been inactive for over a year now (sorry, i was quite busy). Do you want me to send patches, because i was inactive for such a long time? Or can i access the svn repository? I have received the fop-dev-mailing list, but usually have only read the subject lines. I'd like to accomplish following tasks: (1) FOP has already support for white-space-treatment, linefeed-treatment and white-space-collapse. But the results of these implementations are only availabe in RTFHandler.endBlock. So i had introduced delaying processing of the FOs until endBlock. Unfortunatelly this makes the code quite complex and buggy, so i want to remove this (of course the rtf module won't support above mentioned attributes any longer). (2) I want to test support for fo:table. This had worked quite good before i introduced the delaying. But now the table-columns get not processed. This will be fixed when (1) is finished. Sorry, i didn't notice this malfunction. (3) Add support for baseline-shift=sub and baseline-shift=super. (4) After all that i have to think about how we can get white-space-treatment, linefeed-treatment and white-space-collapse to work. The difficulty is that RTFHandler handles text nodes in its implementation of FOEventHandler.characters. But at this time FOP's algorithms have not been run. Currently i see three possibilities (just ideas: any comment appreciated): a. Find a solution without delaying processing any FOs. (I don't know how this could work, in spite of implementing the complete algorithm by myself just for the RTFHandler. Maybe this is the worst solution.) b. Find a solution by delaying *every* FO. This would make the FOInputHandler interface useless, because i just had to wait for a particular event (e. g. endPageSequence) and then iterate the passed PageSequence object. Would be a great effort and would introduce the same problems as described in (1). c. Maybe i should not process the text nodes in FOEventHandler.characters but simply add a placeholder to my rtf. When i reach endBlock i have to iterate the passed Block object and search only for FOText objects. The contents of these FOText's have to replace the placeholders. Kind regards, Peter Herweg
