RE: rtf-external-graphics
Did you meet any difficulties?
-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 29, 2005 12:33 AM
To: fop-dev@xmlgraphics.apache.org
Cc: Danila Ermakov
Subject: Re: rtf-external-graphics
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.
On 28.09.2005 17:10:23 Sergey Simonchik wrote:
Hi,
After patch of Peter Herweg, adding support of external-graphics in Rtf
(25.09.2005, revision 291449) some problems are still unresolved.
I'm talking about using url's in src attribute of fo:external-graphic
tag.
Take a look at fo-file below:
...
fo:flow flow-name=xsl-region-body
fo:block start-indent=12pt space-before=3pt
fo:external-graphic src=url('01.jpg')/
/fo:block
/fo:flow
...
Rtf renderer produced file 01a.rtf (see in attach).
After changing in file RTFHandler.java string
newGraphic.setURL(eg.getSrc());
to string
newGraphic.setURL(eg.getURL());
Rtf renderer produced another file 01b.rtf (in attach too).
File 01b.rtf seems to be correct whether 01a.rtf is not.
What do you think about it?
Thanks for attention!
Jeremias Maerki
rtf-external-graphics
Hi,
After patch of Peter Herweg, adding support of external-graphics in Rtf
(25.09.2005, revision 291449) some problems are still unresolved.
I'm talking about using url's in src attribute of fo:external-graphic tag.
Take a look at fo-file below:
...
fo:flow flow-name=xsl-region-body
fo:block start-indent=12pt space-before=3pt
fo:external-graphic src=url('01.jpg')/
/fo:block
/fo:flow
...
Rtf renderer produced file 01a.rtf (see in attach).
After changing in file RTFHandler.java string
newGraphic.setURL(eg.getSrc());
to string
newGraphic.setURL(eg.getURL());
Rtf renderer produced another file 01b.rtf (in attach too).
File 01b.rtf seems to be correct whether 01a.rtf is not.
What do you think about it?
Thanks for attention!
01.fo
Description: Binary data
attachment: 01.jpg
01a.rtf
Description: MS-Word document
01b.rtf
Description: MS-Word document
RE: question
Thank you. -Исходное сообщение- От: Jeremias Maerki [mailto:[EMAIL PROTECTED] Отправлено: Вт 27.09.2005 12:12 Кому: fop-dev@xmlgraphics.apache.org Копия: Тема: Re: question On 27.09.2005 09:25:15 Jeremias Maerki wrote: On 26.09.2005 19:09:59 Sergey Simonchik wrote: Hi, Letters A and B have same indent from the left edge of page in this example: ... fo:block border-style=solid border-width=20pt border-color=redA fo:block border-style=solid border-width=20pt border-color=blackB /fo:block /fo:block ... Here behaviors of block-progression and inline-progression are different. Is it correct? Yes, that's right. In your example the start-indent and end-indent trait is the same for both blocks. This has to do with the rules established in 5.3.2 in XSL 1.0. I may need to add something to that. You can modify the behaviour to that which I assume you expect: Just add margin=0pt to your example. fo:block margin=0pt border-style=solid border-width=20pt border-color=redA fo:block margin=0pt border-style=solid border-width=20pt border-color=blackB /fo:block /fo:block Extensive documentation about indents can be found here: http://wiki.apache.org/xmlgraphics-fop/IndentInheritance Jeremias Maerki winmail.dat
RE: txt-rendering
Hi Jeremias, May be it's impossible to understand our idea perfectly. Furthermore, we still haven't ICLA and so we can't commit patch with new file (unfortunately such file is 'TxtHandler.java'). Good luck. -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: Friday, September 23, 2005 7:10 PM To: fop-dev@xmlgraphics.apache.org Cc: 'Danila Ermakov' Subject: Re: txt-rendering Hi Sergey, that certainly sounds better although I'm not sure I really understand why exactly you need to do these refinements. I assume that the TextRenderer will also work for most cases without the special AreaTreeHandler. I'm looking forward to having a look at your patch when it's ready. On 23.09.2005 12:41:36 Sergey Simonchik wrote: Hi Jeremias, We don't have in mind to change or modify any code in layout engine or code of formatting objects itself. It's just suggested to have our own handler which extends AreaTreeHandler. This handler should do some refinement for txt (modifying tree of formatting objects, for example changing font-size, etc). We emphasize that TxtHandler, which extends AreaTreeHandler, is used only in txt case. The method createFOEventHandler() return different FOEventHandler and in case of txt output it should return TxtHandler. Good luck. -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: Thursday, September 22, 2005 7:11 PM To: fop-dev@xmlgraphics.apache.org Cc: 'Danila Ermakov' Subject: Re: txt-rendering Hi Sergey, would you please elaborate the modifications you suggest? I'd be very unhappy if we had to do changes in the layout engine just to accomodate the text renderer. I think I don't quite understand what you have in mind. Furthermore, I'm not sure if using different font-sizes in the case of the text renderer is a good idea. See also: http://xmlgraphics.apache.org/fop/output.html#txt On 22.09.2005 10:21:32 Sergey Simonchik wrote: Hi, We've got into TxtRenderer that was in 0.20.5. It works fine for most of examples but in some cases there are problems. For instance: ... fo:block text-align=right font-size=10ptHi/fo:block fo:block text-align=right font-size=50ptHelloworld/fo:block ... Align doesn't correct. It's seems that modifying formatting objects before constructing area tree model may help to cope with such problems. --Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: Saturday, September 17, 2005 3:29 PM To: fop-dev@xmlgraphics.apache.org Cc: Danila Ermakov Subject: Re: txt-rendering Hi Sergey, unfortunately, you didn't notice the TXTRenderer that was in 0.20.5 [1]. The text renderer seems to work fine for many people who work with FOP 0.20.5. IMO it should be simple to port that renderer to FOP Trunk. The TXTRenderer currently found in FOP Trunk is only an empty shell which needs to be filled. I'd investigate that before doing any serious coding on a completely new TextRenderer. Please have a look at TXTRenderer and get back to us so we can sort out any details. The old TXTRenderer is capable of creating good output without any special handling in the area tree. You will also find discussion snippets around the TXTRenderer in the mailing list archives which should give you an idea about its design. BTW, I'm glad that you're going to reintroduce the TextRenderer. AFAIK, there's still a open issue with a patch [2] where I asked you to send in an ICLA so I can commit the patch. So far, I haven't seen an ICLA being recorded with your name. [1] http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/branches/fop- 0_20_2- maintain/src/org/apache/fop/render/txt/ [2] http://issues.apache.org/bugzilla/show_bug.cgi?id=36480 Jeremias Maerki Jeremias Maerki
RE: txt-rendering
Hi, We've got into TxtRenderer that was in 0.20.5. It works fine for most of examples but in some cases there are problems. For instance: ... fo:block text-align=right font-size=10ptHi/fo:block fo:block text-align=right font-size=50ptHelloworld/fo:block ... Align doesn't correct. It's seems that modifying formatting objects before constructing area tree model may help to cope with such problems. --Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: Saturday, September 17, 2005 3:29 PM To: fop-dev@xmlgraphics.apache.org Cc: Danila Ermakov Subject: Re: txt-rendering Hi Sergey, unfortunately, you didn't notice the TXTRenderer that was in 0.20.5 [1]. The text renderer seems to work fine for many people who work with FOP 0.20.5. IMO it should be simple to port that renderer to FOP Trunk. The TXTRenderer currently found in FOP Trunk is only an empty shell which needs to be filled. I'd investigate that before doing any serious coding on a completely new TextRenderer. Please have a look at TXTRenderer and get back to us so we can sort out any details. The old TXTRenderer is capable of creating good output without any special handling in the area tree. You will also find discussion snippets around the TXTRenderer in the mailing list archives which should give you an idea about its design. BTW, I'm glad that you're going to reintroduce the TextRenderer. AFAIK, there's still a open issue with a patch [2] where I asked you to send in an ICLA so I can commit the patch. So far, I haven't seen an ICLA being recorded with your name. [1] http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/branches/fop-0_20_2- maintain/src/org/apache/fop/render/txt/ [2] http://issues.apache.org/bugzilla/show_bug.cgi?id=36480
RE: txt-rendering
-Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: Saturday, September 17, 2005 3:29 PM To: fop-dev@xmlgraphics.apache.org Cc: Danila Ermakov Subject: Re: txt-rendering AFAIK, there's still a open issue with a patch [2] where I asked you to send in an ICLA so I can commit the patch. So far, I haven't seen an ICLA being recorded with your name. Meanwhile, our lawer disallow ICLA using, but it's possible, soon we'll get modified ICLA.
txt-rendering
Hi, We've put mind to txt-rendering. :) Evidently converting to txt isn't implemented yet. So, before code writing, it will be useful to discuss different approaches of implementing it. By this moment we've found 3 possible basic approaches. Here they are: 1) TxtRender extends AbstractRender and try to render AbstractTreeModel to txt format. This approach similar to PDF. But unfortunately txt format is much less flexible than PDF. Thus we need to modify area tree model in order to render it to txt format. Details: TxtRender extends AbstractRender and overloads some methods which process model. 2) The second idea is similar to RTF approach. TxtHandler extends FOEventHandler and handles formatting objects by his own without AreaTreeModel. This doesn't allow us to use advantages of LayoutManager, for example lines fragmentation. 3) The third approach consist of modifying formatting objects before constructing area tree model. After getting formatting objects we make a refinement consisting of some procedures. One of them is converting font's attributes to default value which most appropriate for txt render. As we have already realized its Courier 10. Details: TxtHandler extends AreaTreeHandler and overloads only one method - endPageSequence where refinement takes place. TxtRender extends AbstractRender and overloads some methods which process model. But unlike first approach we have to do much less because LayoutManager gets modified formatting objects and returns better result. We started developing third approach. Good luck.
