Re: Batik Extension/FOP problem
Hi Glen, So there already is such a constant: batik.extension.svg.BatikExtConstants.BATIK_EXT_NAMESPACE_URI. I shouldn't add this to ExtensibleSVGDOMImplementation as it is exactly that extensible. The set of Namespaces it supports is determined at run time based on the Service Provider Interface. I could add methods to query what namespaces have been registered with it but registration is actually on a per-element basis (namespace + localName) - so it might have one or two elemets borrowed from other namespaces. This isn't that big an issue at this point since the only extensions I am aware of are the Batik ones which are all in the above namespace. Do you want to add an interface for getting the list of namespaces that it has elements registered under (just SVG, Batik for right now)? Glen Mazza wrote: Jay, Please type this up in Bugzilla so we don't forget it. (http://xml.apache.org/fop/bugs.html)--Also include this sample as an attachment to the bug. No time guarantees can be given, however. In the meantime, Thomas, I don't think I can just switch our SVGElementMapping implementation from SVGDOMImplementation to ExtensibleSVGDOMImplementation because the namespaces are different. I'll need to add another ElementMapping to production and development. *But*, as you can see in our SVGElementMapping implementation, we rely on a constant SVGDOMImplementation.SVG_NAMESPACE_URI. File below: http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/fo/extensions/svg/SVGElementMapping.java?rev=1.1&content-type=text/vnd.viewcvs-markup To facilitate this change, could you create a similar--of whatever name--namespace constant in your ExtensibleSVGDOMImplementation class--probably it should be "http://xml.apache.org/batik/ext";. Thanks, Glen --- Jay Chiu <[EMAIL PROTECTED]> wrote: Attached please find a sample fo file with embedded svg object. You may also take a look at the batik samples, xml-batik/samples/extensions/flow/flowtext.svg FOP does support the base SVG 1.1 funcationality as Batik supports. But SVG 1.1 does not support more flexible text feature, such as text can not wrap onto multiple lines. --- Thomas DeWeese <[EMAIL PROTECTED]> wrote: I have to have a different root document for all the batik extension elements, otherwise the system uses SVGDOMImplementation to create generic DOM element. It sounds like you want to make a small change so FOP uses the ExensibleSVGDOMImplementation instead of SVGDOMImplementation for all the elements. __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Re: SVG Text layout/modification patch
Glen Mazza wrote: 1.) Please go ahead and commit the code on your side right now--Gump will complain for the next couple of days before the change is made on our side, however. But it's easiest for me to code against something already made. This is done. The commit includes a couple of other more minor fixes - but the patch I gave you has just the TextPainter fixes. 2.) I'd love to hand off the transcoders to your team on a silver platter--[...] Let's hold this as a hopeful goal for 1.0 though, once it stabilizes (and works!, which may be far off). Ok that is fine with me. 3.) Be ready to answer questions I may have over the next few days to fix the transcoders--on 0.20.x production and 1.0 development. (I suspect though, the changes will turn out to be quite simple.) Certainly don't hesitate to ask. 4.) Let us know when this change will appear in the next beta release--we will update our library distributed in production & development. Will do. Thanks, Glen I've attached the patch (hope it isn't too large), I'll commit it if it is easier for you (let me know). For examples of the type of changes you will need to make take a look at batik.gvt.font.AWTGVTGlyphVector. All the aci.getAttribute(FOREGROUND) need to be fixed. While some changes are needed in the PDFTranscoder (from a while ago actually - these aren't as severe and I will try and put togeather a patch for you). Most of these changes will be in the PDFTextPainter ( there may be other TextPainters that need updating in FOP as well). __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Re: SVG Text layout/modification patch
I wish I could--production is a complete mess to work with! But what about Gump? It will be complaining each and every day about fop-maintenance (although it won't care about fop-development once we update *it*.) Gump wants compliance with the latest library versions--this is the problem Jeremias ran into last June with the last Batik change, so he had to update both maintenance & development. If its 10/15 lines of code to change, I'll do it. A daily Gump error message will degenerate into Chinese water torture for us. (And anything that depends on FOP maintenance will fail in Gump as well.) Glen --- "J.Pietschmann" <[EMAIL PROTECTED]> wrote: > Glen Mazza wrote: > > next few days to fix the transcoders--on 0.20.x > > production > > Skip this, it's not worth. We should finally > concentrate > on HEAD. > > J.PIetschmann > __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: RE: Batik Extension/FOP problem
Jay, Please type this up in Bugzilla so we don't forget it. (http://xml.apache.org/fop/bugs.html)--Also include this sample as an attachment to the bug. No time guarantees can be given, however. In the meantime, Thomas, I don't think I can just switch our SVGElementMapping implementation from SVGDOMImplementation to ExtensibleSVGDOMImplementation because the namespaces are different. I'll need to add another ElementMapping to production and development. *But*, as you can see in our SVGElementMapping implementation, we rely on a constant SVGDOMImplementation.SVG_NAMESPACE_URI. File below: http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/fo/extensions/svg/SVGElementMapping.java?rev=1.1&content-type=text/vnd.viewcvs-markup To facilitate this change, could you create a similar--of whatever name--namespace constant in your ExtensibleSVGDOMImplementation class--probably it should be "http://xml.apache.org/batik/ext";. Thanks, Glen --- Jay Chiu <[EMAIL PROTECTED]> wrote: > Attached please find a sample fo file with embedded > svg object. > You may also take a look at the batik samples, > xml-batik/samples/extensions/flow/flowtext.svg > > FOP does support the base SVG 1.1 funcationality as > Batik > supports. But SVG 1.1 does not support more flexible > text > feature, such as text can not wrap onto multiple > lines. --- Thomas DeWeese <[EMAIL PROTECTED]> wrote: > I have to have a > different root document > > for all the batik extension elements, otherwise > the system uses > > SVGDOMImplementation to create generic DOM > element. > >It sounds like you want to make a small change so > FOP uses the > ExensibleSVGDOMImplementation instead of > SVGDOMImplementation for all > the elements. > __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: SVG Text layout/modification patch
Glen Mazza wrote: next few days to fix the transcoders--on 0.20.x production Skip this, it's not worth. We should finally concentrate on HEAD. J.PIetschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: SVG Text layout/modification patch
--- Thomas DeWeese <[EMAIL PROTECTED]> wrote: > > Thanks, there isn't a huge rush but I wanted to > make > sure this wasn't a really bad time for you. > It's always a bad time! ;) 1.) Please go ahead and commit the code on your side right now--Gump will complain for the next couple of days before the change is made on our side, however. But it's easiest for me to code against something already made. 2.) I'd love to hand off the transcoders to your team on a silver platter--we have more than enough on our hands--problem is that currently the internal code for 1.0 is changing many, many times--we would have to keep working with you to get the code updated on your side. For the production side the problem is the code is not very well encapsulated, you would be ripping out & duplicating too much of the application. Let's hold this as a hopeful goal for 1.0 though, once it stabilizes (and works!, which may be far off). 3.) Be ready to answer questions I may have over the next few days to fix the transcoders--on 0.20.x production and 1.0 development. (I suspect though, the changes will turn out to be quite simple.) 4.) Let us know when this change will appear in the next beta release--we will update our library distributed in production & development. Thanks, Glen > > I've attached the patch (hope it isn't too large), > I'll > commit it if it is easier for you (let me know). > For > examples of the type of changes you will need to > make take > a look at batik.gvt.font.AWTGVTGlyphVector. > >All the aci.getAttribute(FOREGROUND) need to be > fixed. While some changes are needed in the > PDFTranscoder > (from a while ago actually - these aren't as severe > and > I will try and put togeather a patch for you). Most > of these > changes will be in the PDFTextPainter ( there may be > other > TextPainters that need updating in FOP as well). > __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
(Victor) RE: import statements
Victor, Your IDE tool created another ".*" invalid import at http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/fo/extensions/svg/SVGElementMapping.java?rev=1.1&content-type=text/vnd.viewcvs-markup. Please fix it up--the Batik team is requesting changes to this file. When I have moved classes in the past, I just do a file-wide add & search-and-replace on import statements so that no invalid imports need be created. You would be correct if you were to presume that this takes 5 mins. vs. perhaps 3 seconds for your "nice" IDE class-moving tool--problem is, trying to retroactively figure out which classes are in which file takes far more effort than the 4:57 saved. If you don't feel this way, fine, go ahead and retroactively fit all classes you created w/invalid imports to our coding standards, but from now on please make the changes *before* checking the file in. It is important that the time involved in this retrofitting be part of the calculations in your decision to use the IDE refactoring tool. Just leaving the code invalid and "hiding in the tall grass"--to use your phrase--should not be considered an option, as it would result in disasterous overuse of that IDE function. Glen > On another issue, Victor, *please* don't forget to > fully qualify the import statements -- that's one of > our coding conventions and very helpful in grokking > code -- a "import org.apache.fop.apps.*;" was added > last week in the PDFRenderer.java: Well, it isn't a matter of forgetting. I know all about it, and there are lots more than the one you point out. My IDE is doing this when it does its nice move and rename refactorings. It is even adding them in classes where they are not needed. I have also introduced many other checkstyle problems along the way, mostly missing javadoc comments for new accessor methods, etc. I'll fix them in batch mode when I can come up for air. If all of our checkstyle problems were fixed, it would be easy to just run the report before doing a commit and fix any that showed up. But there is no practical way to do this with hundreds still out there. Victor Mote __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: RE: Batik Extension/FOP problem
1. This is an alternative way I try to solve the FOP absolute positoned block-container issue. 2. The FOP version is fop-0.20.5 with batik jar and tried with batik version 1.5. 3. As we have sent back and forth the question and answers so many times, can someone doing the SVG for FOP please take a look at my batik extension code and help me solve the problem? I hope someone know the details of both FOP and SVG may help me. I am affraid that FOP does not contain Batik extension because FOP developor did not feel it is easy to add. Thanks a lot. Jay > > Jihai Qiu wrote: > > > The CCS engine for the document is set in > > > BridgeContext.initializeDocument(), which is called by > > > org.apache.batik.bridge.GVTBuilder.build(). But it seems there is no way > > > to set CCS engine from FOP classes(such as BatikElement). (I do > > not want to > > > modify Batik source code). > > > > > > > > >>It also appears that you are trying to map just the flowText element. > > > > > > For the svg elements, FOP extension maps to SVGElement > > and all other > > > tags to SVGObj. I am using the same approach for batik extensions: > > > to BatikElement and all other tags to BatikObj. BatikElement > > > creates the root document for batik namespace. > > > > You can't really render an SVG document as a bunch of > > disconnected pieces. > > > > If this *is* related to the 'absolute positioned block-container' issue, I > think the SVG approach, in this case, might be complicating matters > unnecessarily (though I must admit, it might seem the only viable > alternative right now, apart from somehow 'preprocessing' your fo to make it > contain 'exact' coordinates where needed...) > > > >> The SVG specification is pretty clear that SVG elements must have a > > >> parent SVG element > > > It seems Batik requires each child of SVG element must be SVG > > element( or > > > belongs to same document). > > > Batik DOM element is created through SVGDOMImplmentation, while > > > Batik DOM element is created through > > > ExtensibleSVGOMImplementation. I have to have a different root document > > > for all the batik extension elements, otherwise the system uses > > > SVGDOMImplementation to create generic DOM element. > > > >It sounds like you want to make a small change so FOP uses the > > ExensibleSVGDOMImplementation instead of SVGDOMImplementation for all > > the elements. > > > > >>I think you really want to try and "fix" the existing SVG element > > >> mapping stuff in FOP. > > > How to do this? I stuck in this problem now and do not know > > what to do the > > > next. Can someone please help me implement this batik extension in FOP? > > > >I don't think you can really fix this without making changes in FOP. > > It looks like you might be able to just change the init method in > > SVGElement. > > > > Just to be on the safe side: in the meantime, we still don't know which > version(s) of batik/fop are being used here... ;) > > but apart from that, if the ExtensibleSVGDOMImplementation behaves > completely the same way... this might be worth a little patch. The > svg-embedding example coming with FOP works if you make this change. ( to > FOP 0.20.5 release ) > > Greetz, > > Andreas Delmelle > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Bug report for Fop [2003/09/07]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=CriticalMAJ=Major | | | | MIN=Minor NOR=Normal ENH=Enhancement | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 635|Opn|Nor|2001-02-18|Doesn't support id= attribute in fo:page-sequence | | 953|Opn|Nor|2001-03-12|Incorrect hyperlinks area rendering in justified t| | 1063|New|Nor|2001-03-21|fop does not handle large fo files| | 1180|New|Maj|2001-04-02|Problem with monospaced font | | 1859|Opn|Min|2001-05-22|org.apache.fop.apps.Driver.reset() doesn't fully r| | 1998|New|Nor|2001-06-05|linefeed-treatment not understood | | 2150|Ass|Maj|2001-06-13|New page with a table-header but without any tabl| | 2475|Ass|Nor|2001-07-06|Borders don't appear to work in | | 2740|New|Maj|2001-07-23|multi-page tables sometimes render badly | | 2909|New|Maj|2001-07-30|Gradient render error | | 2964|Ass|Nor|2001-08-02|problems with height of cells in tables | | 2988|New|Maj|2001-08-03|0.19: list-item-label does not stick to list-item-| | 3044|Ass|Maj|2001-08-08|keep-together not functioning | | 3280|New|Nor|2001-08-27|PCL Renderer doesn't work | | 3305|Opn|Nor|2001-08-28|list-block overlapping footnote body | | 3497|New|Maj|2001-09-07|id already exists error when using span="all" attr| | 3824|New|Blk|2001-09-25|MIF option with tables| | 4030|New|Nor|2001-10-08|IOException creating Postscript with graphics on S| | 4126|New|Nor|2001-10-12|FontState.width() returns pts instead of millipts | | 4226|New|Nor|2001-10-17|The orphans property doesn't seem to work | | 4388|New|Nor|2001-10-24|Nullpointer exception in the construction of new D| | 4415|New|Nor|2001-10-25|scaling="uniform" does not work on images... | | 4510|New|Nor|2001-10-30|fo:inline common properties ignored? | | 4535|New|Maj|2001-10-31|PCL renderer 1.13 not rendering SVG | | 4614|New|Maj|2001-11-03|wrap property combined with Chinese | | 4767|New|Nor|2001-11-09|SVG text is distored in PDF output| | 5001|New|Nor|2001-11-21|content-width and content-height ignored? | | 5010|New|Enh|2001-11-21|Better error reporting needed | | 5047|Ass|Nor|2001-11-23|Dotted border style is not supported | | 5124|New|Maj|2001-11-27|fo:block-container is not rendered properly using | | 5335|Opn|Min|2001-12-10|Text with embedded CID fonts not retrievable from | | 5655|Ass|Nor|2002-01-02|text-decoration cannot take multiple values | | 6094|Opn|Maj|2002-01-29|0.20.3rc hangs in endless loop| | 6237|Opn|Nor|2002-02-05|fi (fi ligature) produces a "sharp"? | | 6305|New|Nor|2002-02-07|Using fo:table-and-caption results in empty output| | 6427|New|Enh|2002-02-13|Adding additional Type 1 fonts problem| | 6437|New|Maj|2002-02-13|Tables without fo:table-column don't render | | 6483|New|Nor|2002-02-15|Table, Loop, "footer could not fit on page, moving| | 6844|New|Nor|2002-03-04|No line breaks inserted in list-item-label| | 6918|New|Enh|2002-03-06|reference-orientation has no effect | | 6929|New|Nor|2002-03-06|Cells border hidden by cells background | | 6997|New|Nor|2002-03-09|Row-spanned row data breaks over a page within a c| | 7140|New|Enh|2002-03-15|page-position attribute set to "last" on condition| | 7241|New|Nor|2002-03-19|keep-with-previous, keep-with-next only working on| | 7283|New|Nor|2002-03-20|Table border misaligned when using margin-left in | | 7337|New|Nor|2002-03-21|border around external image leaves empty space | | 7487|New|Nor|2002-03-26|break-before="page" for table inserts empty page | | 7496|New|Nor|2002-03-26|The table header borders are not adjusted to the b| | 7525|New|Cri|2002-03-27|table with spans inside a list-block | | 7919|New|Cri|2002-04-10|problem to use attribute linefeed-treatment and li| | 8003|Ass|Maj|2002-04-12|FopImageFactory never releases cached images | | 8050|New|Nor|2002-04-13|S
Re: Batik Extension/FOP problem
Jihai Qiu wrote: The CCS engine for the document is set in BridgeContext.initializeDocument(), which is called by org.apache.batik.bridge.GVTBuilder.build(). But it seems there is no way to set CCS engine from FOP classes(such as BatikElement). (I do not want to modify Batik source code). It also appears that you are trying to map just the flowText element. For the svg elements, FOP extension maps to SVGElement and all other tags to SVGObj. I am using the same approach for batik extensions: to BatikElement and all other tags to BatikObj. BatikElement creates the root document for batik namespace. You can't really render an SVG document as a bunch of disconnected pieces. The SVG specification is pretty clear that SVG elements must have a parent SVG element It seems Batik requires each child of SVG element must be SVG element( or belongs to same document). Batik DOM element is created through SVGDOMImplmentation, while Batik DOM element is created through ExtensibleSVGOMImplementation. I have to have a different root document for all the batik extension elements, otherwise the system uses SVGDOMImplementation to create generic DOM element. It sounds like you want to make a small change so FOP uses the ExensibleSVGDOMImplementation instead of SVGDOMImplementation for all the elements. I think you really want to try and "fix" the existing SVG element mapping stuff in FOP. How to do this? I stuck in this problem now and do not know what to do the next. Can someone please help me implement this batik extension in FOP? I don't think you can really fix this without making changes in FOP. It looks like you might be able to just change the init method in SVGElement. Thanks a lot. Jay On Fri, 5 Sep 2003, Thomas DeWeese wrote: Hi Jay, Well the problem you are having is because you haven't setup the CSS engine for Batik. This is normally done by the batik.bridge.BridgeContext class in Batik. However, it also appears that you are trying to map just the flowText element - The SVG specification is pretty clear that SVG elements must have a parent SVG element - of course you can try and do it without this but I think it's a mistake. I think you really want to try and 'fix' the existing SVG element mapping stuff in FOP rather than try and reproduce this work. Jay Chiu wrote: I solved the element class mapping issue, but still get exception at org.apache.batik.bridge.CSSUtilities.convertDisplay() because getComputedStyle(e, SVGCSSEngine.DISPLAY_INDEX) returns null on flowTextElement. If I set the method to return true, then I get exception at org.apache.batik.bridge.CSSUtilities.convertVisibility() for the same reason. I have added the attached three files: (1) BaticElement.java (2) BatikElementMapping.java (3) BatikObj.java and registered BatikElementMapping class with fop. Because flowTextElement needs its own document object for using ExtensibleSVGDOMImplementation to create child elements, I have to add addGraphic() into the BatikElement.java file. Also org.apache.batik.dom.AbstractParentNode does not allow adding child with different document object, I have to comment out if (n.getOwnerDocument() != getCurrentDocument()) in checkAndRemove() method. Pleae help me check what is wrong here. Probably you have add the batik extension into next release of FOP. Thanks. Jay On Fri, 5 Sep 2003, Andreas L. Delmelle ([EMAIL PROTECTED]) wrote: From: Jay Chiu [mailto:[EMAIL PROTECTED] I got the same exception as what Swapan got. I think the problem Difficult to tell... ( also because I haven't used Batik directly ) Does this happen with other graphic formats too? What versions (FOP & Batik) are you using? Is FOP being run from the command-line - using the supplied shell script to set its classpath - or embedded? Check http://xml.apache.org/fop/graphics.html#batik to find out why I think these questions are important. Hope this helps ( you both ) Greetz, Andreas Delmelle - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
