Re: Including Fonts in 20.4
Found it, for some reason if I am not embedding fonts I need to encode the xml file with option -enc ansi once I did that it worked fine. Hi John, Just to clarify for my own info. Do you mean specify -enc ansi when you run TTFReader? _ Get faster connections -- switch to MSN Internet Access! http://resourcecenter.msn.com/access/plans/default.asp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: AW: Re: Bug 13699
Peter B. West wrote: I'm sorry Jeremias. It was a joke. See bugger and fop in a nearby dictionary. My one suggests dude as synonym for fop, lets make it project's internal name. :) So long, fop dudes! -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 13872] - images throws exception by using the embedded fop
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13872. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13872 images throws exception by using the embedded fop [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-10-23 12:50 --- That's not a fop bug as it works in command line. Looks like batik.jar is absent in your embedding environment or servlet engine fails to find it. Take a look at http://marc.theaimsgroup.com/?l=fop-userm=102270984419954w=2. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 13872] - images throws exception by using the embedded fop
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13872. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13872 images throws exception by using the embedded fop --- Additional Comments From [EMAIL PROTECTED] 2002-10-23 12:54 --- You should check the JARs you REALLY include and the libraries you HAVE TO include! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 3840] - System.exit() calls in FOP kill Tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3840. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3840 System.exit() calls in FOP kill Tomcat --- Additional Comments From [EMAIL PROTECTED] 2002-10-23 13:49 --- I'm quite curious as to know how this is killing Tomcat anyway. We used FOP in Tomcat without issue for months before we moved to Jetty for unrelated reasons. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
20.4rc src dist?
Guys, Color me ignorant or just plain dumb, but the fop-0.20.4rc-src.tar.gz file doesn't seem to have any .java files in it that I can see. Just .class files. Did I seriously miss something here? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
AW: Re: AW: Re: Bug 13699
Hmmm. I will. Don't have one handy where I am this week. Funny things happen when non-english people write in english. :-) I'm sorry Jeremias. It was a joke. See bugger and fop in a nearby dictionary. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: awt viewer issues
Keiron Liddle wrote: 2. awt viewer should take over caching of rendered pages in order to simplify awt renderer. It should be possible to use a cached store pages model that can handle that. See the CachedRenderPagesModel, it would be very similar except it would not dispose of the page and would need some way to indicate the page does not need to be held in memory. I will, thanks for pointing the direction If you could submit a patch that would be great. Ahem, against HEAD or maintenance branch? PS. Glad to see you back Keiron, I had a feeling fop development was slowed down this month. -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: automated testing
Keiron Liddle wrote: Is this refactoring on branch? (I've probably missed some important discussion so bear with me :) I am not sure I understand your question. My current plan is to do the refactoring on the maintenance branch, then bring it over to trunk when complete. Otherwise, I am going to have difficulty testing it. If you are asking whether the refactoring will be done on a branch from the maintenance branch, that has not been discussed, but I have no objection to it, and it might make things cleaner with the 0.20.5 release on the horizon. I doubt the tests would check much beyond the basic fonts, I suppose it depends what you are going to change. My intention is to try to consolidate all of the font classes that are floating around into a handful of more intuitive classes. For example, the first installment eliminates the layout.FontInfo class and moves its contents into static fields in new font.TypeFace and font.TypeFaceFamily classes. Future installments will move almost all of layout.FontState into font.FOPFont (or possibly font.Font), protect most of its innards, and provide methods for working with those innards. (FontState has a _letterSpacing field which, as far as I can tell, is outside of a Font concept, so FontState will need to exist until I can find a better home for that.) I also think most of the font-specific stuff that is in the render package can be consolidated and simplified (and moved), but I haven't grasped all of what is going on there yet. The ultimate purpose is to make it easier to 1) follow what is going on, 2) add support for other font sources, including OpenType and fonts registered at the OS level. In general, I am trying to address some of what you wrote in your July 18 post on this subject, as well as some of my own ideas. The idea is that the tests are run against a version with an expected result. If the new output is different and the test passed before then there is a problem. This hasn't really been setup properly yet. Understood. Since I am going to be doing a fair amount of refactoring, does it make sense for me to stop work on the testing first, or do we generally prefer to field test? BTW, it is good to hear your voice again. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Latest FO schema
Chuck, Thanks for this. I noticed that that file has hard tabs, and I assume that you are using an editor which allows you to set soft interpretations for these. What setting do you use? I have stripped the TABs, replacing with spaces at stops of 2. I have also replaced the CRLF pairs with LFs. Does your editor allow you to replace TABs with spaces? Does it allow you to choose a line-ending for the output file? If so, it would be useful if you could produce such a file. If you are using a tab width other than 2, let me know. I will commit the changed file unless you would prefer I use a different tab stop. Your schema raised another issue for me. In alt.design, I have a configuration file xml-lang.xml. It has no DTD, but it would be: ?xml version=1.0 ? !ELEMENT xml-lang countrycodes, languagecodes, scriptcodes !ELEMENT countrycodes country+ !ELEMENT country EMPTY !ATTLIST country name CDATA #REQUIRED code ID #REQUIRED !ELEMENT languagecodes language+ !ELEMENT language EMPTY !ATTLIST language name CDATA #REQUIRED code ID #REQUIRED !ELEMENT scriptcodes script+ !ELEMENT script EMPTY !ATTLIST script name CDATA #REQUIRED code ID #REQUIRED Currently, the xml-lang.xml file is processed at startup to produce HashMaps for validation. Not a good idea. I need to generate an appropriate class from the file. N.B. Not to be used during the normal build process, but as a developer tool to generate a new version of the class for checkin when changes occur in the relevant standards. It would be useful if we could decide on a common format that you can include in your schema and that I can use for code generation. Peter Chuck Paussa wrote: Oleg and Peter, Here's the latest iteration of the fo schema. Could someone commit it? The only change is to allow % in length attributes. I believe that the schematron folks are working on a schematron validator that works as an extension to the schema (By adding schematron extensions to the documentation element.) I cetainly can't work on anything of that magnitude for a while (months+) since this one catches all of the mistakes that my team is likely to make. If anyone wants to take on the task of extending the schema with schematron asserts. Feel free. -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 3840] - System.exit() calls in FOP kill Tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3840. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3840 System.exit() calls in FOP kill Tomcat --- Additional Comments From [EMAIL PROTECTED] 2002-10-23 15:44 --- I am the original poster of this bug. I am using FOP (I think it's v2.1) with Tomcat v3.2 and FOP would sometimes kill Tomcat's JVM. I traced the problem to the System.exit() call in BufferManager.java. I removed this call in my local build and the problem went away. I have been using my modified FOP build ever since (over a year) with no problems. I cannot comment on whether or not the bug is fixed in later FOP versions, as I have not tried them. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Including Fonts in 20.4
John Gentilin wrote: Found it, for some reason if I am not embedding fonts I need to encode the xml file with option -enc ansi once I did that it worked fine. For this next version of FOP, can we make the change to FontInfo.java ?? Its on the list. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: font state and associates
Keiron Liddle wrote (a long time ago, July 18 to be exact): Has anyone looked at the font state stuff. It appears we could make some changes to improve the way fonts are handled. - handle font information easily - handle font lists, resolving on a char basis - reduce number of FontState objects if information is the same (or similar?) - allow for serialization as part of area tree Do we need the FontInfo and FontMetric inside the FontState? Can we have a list of all font states so that it can be retrieved when needed for a particular layout of area? My refactoring work will eventually handle most of this. However, I do not understand item 2: handle font lists, resolving on a char basis. There are some lists in the FontInfo class now, which will end up as static fields in the new Typeface class (with Typeface instances behind them), and I will clean them up in the stage 2 work. The part I don't understand is the resolving on a char basis. What does this mean? Thanks. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Feature Request: font-dir
I am currently working on a project where FOP is embedded in my Servlet and I have got to say it all works really slick. One of the issues I ran into was keeping a balance between where I kept my XML/XSL Files and the XML Font files. I think it would of been much cleaner / easier if I could of specified two directories, BaseDir and FontDir. If backwards compatibility is an issue, the FontInfo class could fallback from FontDir to BaseDir. My $.02 Regards John G -- -- John Gentilin Eye Catching Solutions Inc. 18314 Carlwyn Drive Castro Valley CA 94546 Contact Info [EMAIL PROTECTED] Ca Office 1-510-881-4821 NJ Office 1-732-422-4917 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
External Image error
Hi, I am trying load an image through an URL as shown below. fo:external-graphic src="http://www.cafeconleche.org/cup.gif"/ But I am getting following error. Exception in thread "main" java.lang.NoClassDefFoundError at sun.net.www.http.HttpClient.init(Unknown Source) at sun.net.www.http.HttpClient.init(Unknown Source) at sun.net.www.http.HttpClient.New(Unknown Source) at sun.net.www.http.HttpClient.New(Unknown Source) at sun.net.www.http.HttpClient.New(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.connect(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source) at java.net.URL.openStream(Unknown Source) at org.apache.fop.image.FopImageFactory.Make(FopImageFactory.java:78) at org.apache.fop.fo.flow.ExternalGraphic.layout(ExternalGraphic.java:125) at org.apache.fop.fo.flow.Block.layout(Block.java:262) at org.apache.fop.fo.flow.TableCell.layout(TableCell.java:269) at org.apache.fop.fo.flow.TableRow.layout(TableRow.java:344) at org.apache.fop.fo.flow.TableBody.layout(TableBody.java:172) at org.apache.fop.fo.flow.Table.layout(Table.java:247) at org.apache.fop.fo.flow.Block.layout(Block.java:262) at org.apache.fop.fo.flow.Flow.layout(Flow.java:156) at org.apache.fop.fo.flow.Flow.layout(Flow.java:113) at org.apache.fop.fo.pagination.PageSequence.format(PageSequence.java:296) at org.apache.fop.apps.StreamRenderer.render(StreamRenderer.java:200) at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:182) at org.apache.xalan.transformer.ResultTreeHandler.endElement(Unknown Source) at org.apache.xalan.templates.ElemLiteralResult.execute(Unknown Source) at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Unknown Source) at org.apache.xalan.transformer.TransformerImpl.applyTemplateToNode(Unknown Source) at org.apache.xalan.transformer.TransformerImpl.transformNode(Unknown Source) at org.apache.xalan.transformer.TransformerImpl.run(Unknown Source) at org.apache.xalan.transformer.TransformerHandlerImpl.endDocument(Unknown Source) at org.apache.xerces.parsers.SAXParser.endDocument(SAXParser.java:1225) at org.apache.xerces.validators.common.XMLValidator.callEndDocument(XMLValidator.java:7 at org.apache.xerces.framework.XMLDocumentScanner$EndOfInputDispatcher.dispatch(XMLDocucanner.java:1546) at org.apache.xerces.framework.XMLDocumentScanner.parseSome(XMLDocumentScanner.java:381 at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:948) at org.apache.xalan.transformer.TrAXFilter.parse(Unknown Source) at org.apache.fop.apps.Driver.render(Driver.java:481) at org.apache.fop.apps.CommandLineStarter.run(CommandLineStarter.java:72) at org.apache.fop.apps.Fop.main(Fop.java:19) My CLASSPATH looks like this. CLASSPATH=D:\Program Files\PhotoDeluxe 2.0\AdobeConnectables;D:\Program Files\FOP\build\fop.jar;D:\Program Files\FOP\lib\batik.jar;D:\Program Files\FOP\lib\xerces-1.2.3.jar;D:\Program Files\FOP\lib\avalon-framework-4.0.jar;D:\Program Files\FOP\lib\logkit-1.0.jar;D:\Program Files\FOP\lib\xalan-2.0.0.jar;D:\Program Files\FOP\lib\jimi-1.0.jar Can somebody help me in figuring out why I am getting this error? Thanks, Venkat This e-mail is the property of NewRiver, Inc. The information transmitted is confidential and may be privileged, and is only intended for the recipient to whom it is addressed. Any review, distribution, dissemination, reliance upon or other use of this information by persons other than the intended recipient is prohibited. NewRiver makes no representations or warranties of any kind, whether express or implied, with respect to the information. NewRiver and the sender shall have no responsibility or liability for any reliance on the information. If you have received this e-mail in error, please notify the sender by reply e-mail and delete and destroy any copies of this e-mail.
Re: [Fwd: Regarding your comment about inline building onxsl-editors]
Hi Peter and others, The answer appears to be a clarification of the the spec authors had in the minds when writing it. The answer is what I was originally thinking it meant, that is that a block area under an inline is not wrapped by an inline area but rather the block area becomes a sibling of the lines areas created for the inline areas. so: block inlinesome text blocka block/block more text/inline /block is the same as: block inlinesome text /inline blocka block/block inline more text/inline /block The block may inherit some properties from the inline but it is not wrapped by the properties of the inline or wrapped by an inline area that has traits. Here are some references that I could find: http://marc.theaimsgroup.com/?l=fop-devm=97951301002986w=2 http://marc.theaimsgroup.com/?l=fop-devm=102011250524180w=2 On Mon, 2002-09-23 at 04:33, Peter B. West wrote: Fopdevs, For those of you who are not subscribed to the xsl-editors list. Comments please. I've been trying to track down the original discussion that triggered my request ot the editors, in hopes of being able to enter into the mind-set of inline-building again, but at the moment I'm just confused. Peter Original Message Subject: Regarding your comment about inline building on xsl-editors Date: Wed, 18 Sep 2002 18:37:10 -0500 From: Paul Grosso [EMAIL PROTECTED] To: Peter B. West [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Peter, Thank you for your comment to [EMAIL PROTECTED] archived at http://lists.w3.org/Archives/Public/xsl-editors/2002AprJun/0031 We determined that the spec required some corrections to address your question. We would appreciate it if you could let us know if you feel that our proposed changes sufficiently address your questions. The following is our proposed disposition of your above comment: --- We propose the following corrections to the spec: 1. the Areas portion of 6.9.2 [fo:basic-link] be changed from: The fo:basic-link formatting object generates one or more normal inline-areas. The fo:basic-link returns these areas, any page-level-out-of-line areas, and any reference-level-out-of-line areas returned by the children of the fo:basic-link. to: The fo:basic-link formatting object generates one or more normal inline-areas. The fo:basic-link returns these areas, together with any normal block-areas, page-level-out-of-line areas, and reference-level-out-of-line areas returned by the children of the fo:basic-link. 2. The same changes should be made to 6.6.2 [fo:bidi-override] and 6.6.7 [fo:inline], which have the same difficulty. 3. In section 4.7.3 [Inline-building] the following phrase (that describes the subject of the ordering constraints): the normal and/or anchor inline-areas returned by the child formatting objects, should be changed to: the normal and/or anchor inline-areas and normal block-areas returned by the child formatting objects, --- Please Reply (cc-ing [EMAIL PROTECTED]) if you wish to make an objection to our resolution. Thank you for your interest in XSL. Paul Grosso for the XSL FO Subgroup of the XSL WG - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Fix for bug #8778
On Tue, 2002-09-24 at 16:42, Rhett Aultman wrote: Foppers, I've implemented some code in the TextLayoutManager that keeps an eye on the TLM's lack of progress in laying out its content and that, after 100 repeated attempts with no progress, gives up the ghost, assuming that, after 100 tries with no progress, chances are good that it's going to never progress (causing an infinite loop). I've run this against the tests and it doesn't seem to have any adverse behavior. It also properly bails out of the testcases for bug #8778. However, since exception throwing is currently not permitted in the LayoutManager interface, the TLM gives up by throwing a RuntimeException, which I don't have to specify in a throws clause. Before I offer the patch, I thought I'd ask those with more seniority than me- would a checked exception be preferred? I can make the necessary changes, but it'd change a LOT more code (since there'd been a need for try/catch blocks and the like all over the place), and this patch is to fix up an infrequent condition on a branch of code we're not going to progress down much further. Comments? I'm a bit confused, the TextLayoutManager is only in HEAD. It does have a couple of proplems at the moment with wide areas and whitespace handling at the end. However the code should be selecting a correct break only once and there should never be a situation where keeps trying to add the same areas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: documentation
On Thu, 2002-10-10 at 00:00, J.Pietschmann wrote: Christian Geisert wrote: Ok. IMHO the next step should be the migration of the current docs to forrest (Joerg?) Migration to forrest DTDs. I seem to have lost track of recent changes, and I'm still unwilling to force everyone to use forrest, which includes Cocoon, simply to build the docs, which is unfortunately required if you want to use forrest's XSLT unchanged. I'm almost done, only a few small issues remain (one is that I'm in horror of doing large additions and deletions to the source tree). I wouldn't think that many people do or need to create the html from the source docs. I think it is reasonable to ask those that do to use forrest. We could let them download a forrest runtime, set up the path and call forrest, the docs would then be created. I really want the new docs in cvs so we can start to clear up many of the issues that keep getting asked on the lists. Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 13872] New: - images throws exception by using the embedded fop
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13872. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13872 images throws exception by using the embedded fop Summary: images throws exception by using the embedded fop Product: Fop Version: 0.20.3 Platform: PC OS/Version: Other Status: NEW Severity: Blocker Priority: Other Component: images AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have a fo-file which includes a graphic with fo:external-graphic/. Using the fop.bat file works fine, but creating a pdf with the embedded method throws the following exception. java.lang.NoClassDefFoundError: org/w3c/dom/svg/SVGDocument at org.apache.fop.image.analyser.ImageReaderFactory.Make (ImageReaderFactory.java:46) at org.apache.fop.image.FopImageFactory.Make (FopImageFactory.java:109) at org.apache.fop.fo.flow.ExternalGraphic.layout (ExternalGraphic.java:125) at org.apache.fop.fo.flow.Block.layout(Block.java:262) at org.apache.fop.fo.flow.TableCell.layout(TableCell.java:269) at org.apache.fop.fo.flow.TableRow.layout(TableRow.java:344) at org.apache.fop.fo.flow.TableBody.layout(TableBody.java:172) at org.apache.fop.fo.flow.Table.layout(Table.java:247) at org.apache.fop.fo.flow.Block.layout(Block.java:262) at org.apache.fop.fo.flow.StaticContent.layout (StaticContent.java:79) at org.apache.fop.fo.pagination.PageSequence.layoutStaticContent (PageSequence.java:415) at org.apache.fop.fo.pagination.PageSequence.formatStaticContent (PageSequence.java:364) at org.apache.fop.fo.pagination.PageSequence.format (PageSequence.java:304) at org.apache.fop.apps.StreamRenderer.render (StreamRenderer.java:200) at org.apache.fop.fo.FOTreeBuilder.endElement (FOTreeBuilder.java:182) at org.apache.xerces.parsers.SAXParser.endElement (SAXParser.java:1398) at org.apache.xerces.validators.common.XMLValidator.callEndElement (XMLValidator.java:1019) at org.apache.xerces.framework.XMLDocumentScanner$ContentDispatcher.dispatch (XMLDocumentScanner.java:1256) at org.apache.xerces.framework.XMLDocumentScanner.parseSome (XMLDocumentScanner.java:381) at org.apache.xerces.framework.XMLParser.parse (XMLParser.java:948) at org.apache.fop.apps.Driver.render(Driver.java:481) at org.apache.fop.apps.Driver.run(Driver.java:554) at com.gedys.opel.filou.servlet.page.PageFinancingContractPrint.doPage (PageFinancingContractPrint.java:197) at com.gedys.opel.filou.servlet.Servlet.doPage (Servlet.java:324) at com.gedys.servlet.moduleservlet.ModuleServlet.doPage (ModuleServlet.java:501) at com.gedys.servlet.moduleservlet.ModuleServlet.doGet (ModuleServlet.java:441) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke (StandardWrapperValve.java:243) at org.apache.catalina.core.StandardPipeline.invokeNext (StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke (ContainerBase.java:943) at org.apache.catalina.core.StandardContextValve.invoke (StandardContextValve.java:190) at org.apache.catalina.core.StandardPipeline.invokeNext (StandardPipeline.java:566) at org.apache.catalina.valves.CertificatesValve.invoke (CertificatesValve.java:246) at org.apache.catalina.core.StandardPipeline.invokeNext (StandardPipeline.java:564) at org.apache.catalina.core.StandardPipeline.invoke (StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke (ContainerBase.java:943) at org.apache.catalina.core.StandardContext.invoke (StandardContext.java:2343) at org.apache.catalina.core.StandardHostValve.invoke (StandardHostValve.java:180) at org.apache.catalina.core.StandardPipeline.invokeNext
RE: storing metadata
On Tue, 2002-10-22 at 16:52, Victor Mote wrote: Paul Hussein wrote: I believe the adobe pdf standard includes the ability to store metadata with the pdf. XMP i think they call it. I would like to extend FOP to allow storing of this metadata within the produced PDF. I could then store the FO inside the PDF for later reference. Any ideas if this feasible and how I could go about it ?? It sure looks feasible to me, and is something I have thought about adding. Others have already given some thoughts on how to get the information into the PDF. I agree with Dirk-Willem that that writing it directly into the PDF (along with all of the other FOP output) is the better way to go. The other issue is how to get the info into the FO file. It seems to me that this will require an extension, so be sure to check out http://xml.apache.org/fop/extensions.html if you haven't already. Getting the data into the PDF should be quite easy with an extension. The bookmark extension is a more complicated example of the sort of thing needed. Your extension element would contain the xmp data xml information which is put into a pdf stream of type Metadata. The difficult part is creating the xmp data, whatever it is. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 3840] - System.exit() calls in FOP kill Tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3840. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3840 System.exit() calls in FOP kill Tomcat [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2002-10-23 10:05 --- [EMAIL PROTECTED] I checked the system.exit entries in fop0.20.2 and also the latest released version of fop ie fop0.20.4. I got System.exit entries in the following java files. System.exit entries in fop0.20.2: 1)CommandLineStarter.java 2)Options.java 3)PrintStarter.java 4)FOText.java 5)BufferManager.java 6)SerializeHyphPattern.java 7)PreviewDialog.java System.exit entries in fop0.20.4: 1)AWTStarter.java 2)Fop.java 3)Options.java 4)PrintStarter.java 5)FOText.java 6)BufferManager.java 7)SerializeHyphPattern.java Still in fop0.20.4, BufferManager.java has System.exit(), which needs to removed, since it may cause the JVM to exit, which is not desirable. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: automated testing
On Wed, 2002-10-23 at 17:08, Victor Mote wrote: I am not sure I understand your question. My current plan is to do the refactoring on the maintenance branch, then bring it over to trunk when complete. Otherwise, I am going to have difficulty testing it. If you are asking whether the refactoring will be done on a branch from the maintenance branch, that has not been discussed, but I have no objection to it, and it might make things cleaner with the 0.20.5 release on the horizon. It is just that I have done some things with the FontState and FontInfo on trunk. You may want to take a look at that. The font-weight is a number and it uses a string key to specify the font for serialization. But there is a lot more to do. I doubt the tests would check much beyond the basic fonts, I suppose it depends what you are going to change. My intention is to try to consolidate all of the font classes that are floating around into a handful of more intuitive classes. For example, the first installment eliminates the layout.FontInfo class and moves its contents into static fields in new font.TypeFace and font.TypeFaceFamily classes. Future installments will move almost all of layout.FontState into font.FOPFont (or possibly font.Font), protect most of its innards, and provide methods for working with those innards. (FontState has a _letterSpacing field which, as far as I can tell, is outside of a Font concept, so FontState will need to exist until I can find a better home for that.) I also think most of the font-specific stuff that is in the render package can be consolidated and simplified (and moved), but I haven't grasped all of what is going on there yet. The ultimate purpose is to make it easier to 1) follow what is going on, 2) add support for other font sources, including OpenType and fonts registered at the OS level. In general, I am trying to address some of what you wrote in your July 18 post on this subject, as well as some of my own ideas. That sounds like a good approach. I particularly like the make it easier to follow what is going on. Understood. Since I am going to be doing a fair amount of refactoring, does it make sense for me to stop work on the testing first, or do we generally prefer to field test? I think the field test is the best for now. It would probably be a waste of effort sorting out the testing now. If possible it might be better if some of these areas could have unit testing rather than relying on the system testing. BTW, it is good to hear your voice again. Thanks. When these fonts things a sorted out it will be really good. So it is good to see you working on it. Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
