DO NOT REPLY [Bug 33760] - [Patch] current AWTRenderer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33760. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33760 --- Additional Comments From [EMAIL PROTECTED] 2005-06-09 10:52 --- Patch applied. This stuff looks very good now. Thank you very much for your effort and the quick response, Renaud! -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: Fop Viewer
Renaud Richardet writes: I just cleaned the patch that I submitted some long time ago. It should work now. Please see my other mail to the list for details. Thanks to both you and Jeremias for moving so quickly on this. I've checked out the new code and am working on the changes now, PS: My apologies for not showing up on the FOP-list for a long time. I just started a new job at Wyona Good luck, Richard
Re: Renderers: work in progress
On 08.06.2005 23:16:15 Renaud Richardet wrote: Bonjour, I've cleaned the patch that I commited a long time ago, and posted a new one to http://issues.apache.org/bugzilla/show_bug.cgi?id=33760 Basically, I did 2 things: - I splitted the AWTRenderer from the Java2DRenderer and did some clean up. Hopefully, this will make Robert's work easier and cleaner. - I also implemented the PrintRenderer, PNGRenderer and TIFFRenderer. Great work! There are still some issues, but it basically works. I think it would be good to polish it and commit it, and fix the remaining issues. Right. I've already done a few things. Here is some (internal) discussion in response to the last feedback of Jeremias. snip/ Furthermore, I'd remove the JPSPrintRenderer as it might be cause for confusion with the PrintRenderer. It's of not much use anyway. I'd rather create examples in examples/embedding that show how to use the PrintRenderer with JPS both with normal printers and StreamPrintServices. I'd also rename Java2DPrintRenderer to PrintRenderer even though there's a class with the same name one package higher up. Done I think that base class should rather be renamed to something less misleading. But that'll take some opinion-gathering first. Still open Let's leave it for now. It's not that bad. If we see a problem it is fixed quickly. Renderer registration: I'm unsure if I've registered the 2 new Renderers (TIFF and PNG) correctly in the front-end. Could you give it a look, especially RendererFactory.createFOEventHandler(), thanks. Looks ok. Please check it again, as thing might have changed since then. It's still ok. The PNG-Renderer outputs 1 picture per page (right?), so we end up with several files. My pragmatic approach is to let the user specify the first file name on the command line (eg. image1.png). FOP then creates the next images using the same directory and name pattern (image2.png, ASO). For this, I had to register the outfile in FOUserAgent. We could offer more configuration possibilities, but I think it's sufficient ATM. I don't feel like changing the front end, which looks very clean and robust. I agree it's ok for now. It can always be improved as need arises. OK I've made the whole thing here a bit safer and fixed a bug. I've got some ideas here but will need some more time to do this. For PNG, TIFF and Print, the quality of the output is _very_ poor. Am I using the right image type in Java2DRenderer.getPageImage(PageViewport pageViewport) ? Oleg used a TYPE_BYTE_BINARY, which seems to be the only type which works with the TIFFEncoder from Batik. See TIFFRenderer$LazyPageImagesIterator.next(). But the quality is poorer. Any hints? Yes. Simply increase the bitmap size. Use FOUserAgent.getPixelUnitToMillimeter() to calculate an enhanced scaleFactor in Java2DRenderer.getPageImage() to support bigger resolutions. Default resolution is 72dpi which explains the poor quality. You should probably support an additional command line parameter that enables the user to specify the resolution for the generated image. Compare with [1] [1] http://barcode4j.krysalis.org/cli.html I haven't look at it yet. DONE. AWTRenderer: I had to modify PageViewport.isResolved(), so that the flag done in RenderPageModel.addPage() gets a chance to be set to true. The Map unresolvedID is sometimes empty, but not set to null. This way, the user can see the first page while the layout engine is still rendering the other pages in background. Please let me know if there's a better way to define isResolved(). I'd have to invest more time to answer that. I'll see what I can do. Maybe someone else has some input here. Please do. I only had to make 2 minor changes in PageViewport, but I'm not certain about the implications. I'll postpone this for the moment. Maybe Robert can have a look. snip/ Thanks again, Renaud, for your work. FOP is again a step closer to where I want to see it. Jeremias Maerki
Re: cvs commit: xml-fop/src/java/org/apache/fop/render RendererFactory.java
You're right. I didn't check them when reviewing the patch. I tried again but I don't get valid images. Renaud, would you please post the two images separately? Thank you. On 09.06.2005 16:33:59 richardw wrote: [EMAIL PROTECTED] writes: jeremias2005/06/09 01:49:27 Modified: src/java/org/apache/fop/render/awt/viewer/images fopLogo.gif logo_big.jpg Submitted by:Renaud Richardet renaud.richardet.at.gmail.com Both of these files appear to be corrupt. Can you please confirm this and either upload the correct versions or point me to them, Richard Jeremias Maerki
The need for a Contributor License Agreement (was: cvs commit: xml-fop/src/java/org/apache/fop/render RendererFactory.java)
Richard, to put what Glen wrote a little more politely: The Apache Software Foundation established a policy after which every contributor who submits more than just a little bugfix or patch (i.e. who is contributing substantially), should send a signed Contributor License Agreement to the Foundation. Small contributions such as bugfixes are covered by the Apache license v2.0 (section 5). Since your work will likely not fit the latter category, we'd be grateful if you would send in a signed CLA in due time. You can find it here: http://www.apache.org/licenses/icla.pdf You can find more info on the following page (scroll to bottom): http://www.apache.org/licenses/ Thank you. Glen, couldn't you just have asked Richard politely to state his full name and to send in a CLA? I don't think we can afford to scare potential contributors away by writing messages like yours. On 09.06.2005 19:19:05 Glen Mazza wrote: I think we're going to need to know Richard's last name, as well as have a CLA from him, before we can accept work from him. I don't know the situation, but if he would rather stay anonymous because he can't donate work to Apache, it would appear then he can't donate work to Apache. Jeremias Maerki
Re: Direct support for data: URL format in fo:external-graphics
I've published a solution a few weeks ago. You can find it here: http://marc.theaimsgroup.com/?l=fop-userm=110875657902117w=2 I will look to it that direct RFC2397 support will make into the next release. HTH On 09.06.2005 19:29:03 Rick Bullotta wrote: Any plans to support/implement the data:image/xxx;base64,... format for inlining graphics (without needing to further wrap in an SVG, a very unnecessary step, IMO)? I could look at implementing this if it doesn't already exist or isn't in process. Jeremias Maerki
RE: Direct support for data: URL format in fo:external-graphics
Perfect, Jeremias! Amazing that Google passed it by... g -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: Thursday, June 09, 2005 2:26 PM To: fop-dev@xmlgraphics.apache.org Subject: Re: Direct support for data: URL format in fo:external-graphics I've published a solution a few weeks ago. You can find it here: http://marc.theaimsgroup.com/?l=fop-userm=110875657902117w=2 I will look to it that direct RFC2397 support will make into the next release. HTH On 09.06.2005 19:29:03 Rick Bullotta wrote: Any plans to support/implement the data:image/xxx;base64,... format for inlining graphics (without needing to further wrap in an SVG, a very unnecessary step, IMO)? I could look at implementing this if it doesn't already exist or isn't in process. Jeremias Maerki
Re: FOP Supports Multiple Charset ?
Lalitha Prasad wrote: Yes , we can print the special characters using different fonts ( ie. Symbol ). But i need to print original chars also.It seems very difficult to apply muliple font for muliple occurences of special Characters. Do you have any easy method to print one paragraph with different font-families?. If you install and use a user font which has all necessary glyphs, for example the well known Arial Unicode font, you don't have to switch the font family in the FO source. J.Pietschmann
Re: Remove LayoutManager.initialize() method?
On Tue, Jun 07, 2005 at 12:18:50AM -0400, Glen Mazza wrote: Team, Anyone have a problem if I remove the initialize() method from the LayoutManager interface (and assorted related code from AbstractLayoutManager), by having the eight LM's currently using it initialize themselves internally instead? Currently, for those 8 LM's using external initialization (i.e., LM.initialize()), it is done immediately after the ParentLM is set for the LM in AbstractLayoutManager.addChildLM(). So, at a minimum, I think I can equivalently do this by having each class call initialize() within an overridden setParent() implementation. However, for most of the eight it appears I can just call initialize() from the class' constructor without needing a setParent() override. I seem to recall that initialization in LMs was not very consistent. If you can unify the required initializations, it would be nice. Regards, Simon This change will not prohibit specific LM's with unique requirements from having a public initialize() method, if ever needed, it would just require that a specific class variable be used instead of the generic LayoutManager interface variable (i.e., for WidgetLayoutManager wlm, call wlm.initialize() instead of LM.initialize().) Thanks, Glen -- Simon Pepping home page: http://www.leverkruid.nl
layoutengine test text-transform2.xml
Why is this expectation in text-transform2 correct: fo:block2: fo:wrapper text-transform=capitalizeThis tExT is cafo:wrapper color=redpit/fo:wrapperAfo:inline color=blueliZ/fo:inlineed./fo:wrapper/fo:block eval expected=2: This Text Is CaPitALizEd. xpath=//flow/block[2]/ Reading the XSL spec, section 7.16.6, I expect 'This Text Is Capitalized' despite the wrapper and inline elements. The spec only speaks about words. There is no mention that fo child elements would make a difference. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
RE: layoutengine test text-transform2.xml
Simon Pepping wrote: Why is this expectation in text-transform2 correct: fo:block2: fo:wrapper text-transform=capitalizeThis tExT is cafo:wrapper color=redpit/fo:wrapperAfo:inline color=blueliZ/fo:inlineed./fo:wrapper/fo:block eval expected=2: This Text Is CaPitALizEd. xpath=//flow/block[2]/ Reading the XSL spec, section 7.16.6, I expect 'This Text Is Capitalized' despite the wrapper and inline elements. The spec only speaks about words. There is no mention that fo child elements would make a difference. You are correct. The result should be: This TExT Is CapitAliZed. Victor Mote
RE: layoutengine test text-transform2.xml
Simon Pepping wrote: Why is this expectation in text-transform2 correct: fo:block2: fo:wrapper text-transform=capitalizeThis tExT is cafo:wrapper color=redpit/fo:wrapperAfo:inline color=blueliZ/fo:inlineed./fo:wrapper/fo:block eval expected=2: This Text Is CaPitALizEd. xpath=//flow/block[2]/ Reading the XSL spec, section 7.16.6, I expect 'This Text Is Capitalized' despite the wrapper and inline elements. The spec only speaks about words. There is no mention that fo child elements would make a difference. You are correct. The result should be: This TExT Is CapitAliZed. Victor Mote
Re: layoutengine test text-transform2.xml
So I misunderstood and actually changed the wrong thing. Oh welll. On 09.06.2005 22:25:01 Victor Mote wrote: Simon Pepping wrote: Why is this expectation in text-transform2 correct: fo:block2: fo:wrapper text-transform=capitalizeThis tExT is cafo:wrapper color=redpit/fo:wrapperAfo:inline color=blueliZ/fo:inlineed./fo:wrapper/fo:block eval expected=2: This Text Is CaPitALizEd. xpath=//flow/block[2]/ Reading the XSL spec, section 7.16.6, I expect 'This Text Is Capitalized' despite the wrapper and inline elements. The spec only speaks about words. There is no mention that fo child elements would make a difference. You are correct. The result should be: This TExT Is CapitAliZed. Victor Mote Jeremias Maerki
