Re: Re: RTF and table/column widths - table width attribute
- original Nachricht Betreff: Re: RTF and table/column widths - table width attribute Gesendet: Mi 15 Mär 2006 19:33:17 CET Von: "Andreas L Delmelle"<[EMAIL PROTECTED]> > On Mar 14, 2006, at 20:37, [EMAIL PROTECTED] wrote: > > > Von: "Andreas L Delmelle"<[EMAIL PROTECTED]> > > > >> Anyway, you'd have to go: > >> > >> Object o = property; > >> CompoundDatatype c = (CompoundDatatype) o; > > No, you don't have to. The property would have a method 'getCompound > > ()' returning a CompoundDatatype. Either it returns this, 'cause it > > is a CompoundDatatype or it returns a previously set instance > > (constructor, set-method) or it creates an instance, if necessary > > (maybe with default types) or even returns 'null' 'cause it's not > > able to deal with CompoundDatatype. So the only thing you need is a > > null-check on abstract levels, not a cast or instanceof. It may > > return a non-null value which maybe this, maybe an attribute, maybe > > a Singleton, whatever... > > OK. Now I see... Just like it is currently done with, for example, > Property.getList(), Property.getEnum() etc. (Correct?) Exactly > > Anyway, I thought about starting off with making that getObject() > method protected. AFAICT, it's never used outside of the properties > package, so in preparation for an eventual revision of this part of > the code, it seems wise to reduce that method's visibility to > indicate that it is meant for internal use only, so as not to > encourage its use elsewhere. > > WDYT? Sounds good to me, btw I think due to the strange naming and return value, most of the programmers won't call this method. But why not limiting access and mentioning something in the javadocs like "will be removed in future releases". There's no need to make it deprecated. If it's only used in the property-package, it 's not that hard to apply the changes to the necessary classes. > > Cheers, > > Andreas > > --- original Nachricht Ende "Jetzt Handykosten senken mit klarmobil - 14 Ct./Min.! Hier klicken" www.klarmobil.de/index.html?pid=73025
[EMAIL PROTECTED]: Project xml-fop (in module xml-fop) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project xml-fop has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 18 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - xml-fop : XSL-FO (Formatting Objects) processor Full details are available at: http://vmgump.apache.org/gump/public/xml-fop/xml-fop/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [fop.jar] identifier set to project name -INFO- Made directory [/usr/local/gump/public/workspace/xml-fop/build/classes] -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/xml-fop/xml-fop/gump_work/build_xml-fop_xml-fop.html Work Name: build_xml-fop_xml-fop (Type: Build) Work ended in a state of : Failed Elapsed: 43 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/build/xalan-unbundled.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only package [Working Directory: /usr/local/gump/public/workspace/xml-fop] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/xml-fop/build/classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/junit3.8.1/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/xml-batik/batik-16032006/lib/batik-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-16032006/lib/batik-swing.jar:/usr/local/gump/public/workspace/xml-batik/batik-16032006/lib/batik-css.jar:/usr/local/gump/public/workspace/xml-batik/batik-16032006/lib/batik-bridge.jar:/usr/local/gump/public/workspace/xml-batik/batik-16032006/lib/batik-xml.jar:/usr/local/gump/public/workspace/xml-batik/batik-16032006/lib/batik-svg-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-16032006/lib/batik-awt-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-16032006/lib/batik-transcoder.jar:/usr/local/gump/public/workspace/xml-batik/batik-16032006/lib/batik-gui-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-16032006/lib/batik-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-16032006/lib/batik-ext.jar:/usr/local/gump/public/workspace/xml-batik/batik-16032006/lib/batik-script.jar:/usr/local/gump/public/workspace/xml-batik/batik-16032006/lib/batik-svggen.jar:/usr/local/gump/public/workspace/xml-batik/batik-16032006/lib/batik-parser.jar:/usr/local/gump/public/workspace/xml-batik/batik-16032006/lib/batik-extension.jar:/usr/local/gump/public/workspace/xml-batik/batik-16032006/lib/batik-gvt.jar:/usr/local/gump/public/workspace/excalibur/framework/api/target/excalibur-framework-api-16032006.jar:/usr/local/gump/public/workspace/excalibur/framework/impl/target/excalibur-framework-impl-16032006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-16032006.jar:/usr/local/gump/public/workspace/jakarta-commons/io/build/jakarta-commons-io-16032006.jar:/usr/local/gump/public/workspace/jakarta-servletapi/dist/lib/servlet.jar - [javac] PNGRed red = new PNGRed(stream, param); [javac] ^ [javac] /x1/gump/public/workspace/xml-fop/src/java/org/apache/fop/image/PNGImage.java:57: cannot find symbol [javac] symbol : class PNGRed [javac] location: class org.apache.fop.image.PNGImage [javac] PNGRed red = new PNGRed(stream, param); [javac] ^ [javac] /x1/gump/public/workspace/xml-fop/src/java/org/apache/fop/layoutmgr/inline/CharacterLayoutManager.java:149: warning: [deprecation] org.apache.fop.area.inline.Character in org.apache.fop.area.inline has been deprecated [javac] (((org.apache.fop.area.inline.Character) curArea).getChar()); [javac] ^
[EMAIL PROTECTED]: Project xml-fop (in module xml-fop) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project xml-fop has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 18 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - xml-fop : XSL-FO (Formatting Objects) processor Full details are available at: http://vmgump.apache.org/gump/public/xml-fop/xml-fop/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [fop.jar] identifier set to project name -INFO- Made directory [/usr/local/gump/public/workspace/xml-fop/build/classes] -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/xml-fop/xml-fop/gump_work/build_xml-fop_xml-fop.html Work Name: build_xml-fop_xml-fop (Type: Build) Work ended in a state of : Failed Elapsed: 43 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/build/xalan-unbundled.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only package [Working Directory: /usr/local/gump/public/workspace/xml-fop] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/xml-fop/build/classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/junit3.8.1/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/xml-batik/batik-16032006/lib/batik-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-16032006/lib/batik-swing.jar:/usr/local/gump/public/workspace/xml-batik/batik-16032006/lib/batik-css.jar:/usr/local/gump/public/workspace/xml-batik/batik-16032006/lib/batik-bridge.jar:/usr/local/gump/public/workspace/xml-batik/batik-16032006/lib/batik-xml.jar:/usr/local/gump/public/workspace/xml-batik/batik-16032006/lib/batik-svg-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-16032006/lib/batik-awt-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-16032006/lib/batik-transcoder.jar:/usr/local/gump/public/workspace/xml-batik/batik-16032006/lib/batik-gui-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-16032006/lib/batik-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-16032006/lib/batik-ext.jar:/usr/local/gump/public/workspace/xml-batik/batik-16032006/lib/batik-script.jar:/usr/local/gump/public/workspace/xml-batik/batik-16032006/lib/batik-svggen.jar:/usr/local/gump/public/workspace/xml-batik/batik-16032006/lib/batik-parser.jar:/usr/local/gump/public/workspace/xml-batik/batik-16032006/lib/batik-extension.jar:/usr/local/gump/public/workspace/xml-batik/batik-16032006/lib/batik-gvt.jar:/usr/local/gump/public/workspace/excalibur/framework/api/target/excalibur-framework-api-16032006.jar:/usr/local/gump/public/workspace/excalibur/framework/impl/target/excalibur-framework-impl-16032006.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-16032006.jar:/usr/local/gump/public/workspace/jakarta-commons/io/build/jakarta-commons-io-16032006.jar:/usr/local/gump/public/workspace/jakarta-servletapi/dist/lib/servlet.jar - [javac] PNGRed red = new PNGRed(stream, param); [javac] ^ [javac] /x1/gump/public/workspace/xml-fop/src/java/org/apache/fop/image/PNGImage.java:57: cannot find symbol [javac] symbol : class PNGRed [javac] location: class org.apache.fop.image.PNGImage [javac] PNGRed red = new PNGRed(stream, param); [javac] ^ [javac] /x1/gump/public/workspace/xml-fop/src/java/org/apache/fop/layoutmgr/inline/CharacterLayoutManager.java:149: warning: [deprecation] org.apache.fop.area.inline.Character in org.apache.fop.area.inline has been deprecated [javac] (((org.apache.fop.area.inline.Character) curArea).getChar()); [javac] ^
Re: Combine FOP & PDFBox efforts?
Great, I will start updating PDFBox to use the FOrayFont, I believe this will go pretty smoothly because FOrayFont is already being used for PDF creation. More details on the FOray list. We have had some recent discussions about supported JRE's, from the main page of FOray[1] it says that 1.4 is used. There is a desire among the FOP developers to maintain compatibility with 1.3. Do you know if FOrayFont compatible with 1.3? Actually I haven't taken care of this issue yet. I'm hoping that it won't be too difficult to make it 1.3-compliant, we only use basic classes of the standard library. My goal is to first have it accepted in Fop, and then do what is necessary to achieve 1.3 compliance (actually, if someone else would volounteer to take care of that last step, even better ;-) ) Vincent
Re: Combine FOP & PDFBox efforts?
Great, I will start updating PDFBox to use the FOrayFont, I believe this will go pretty smoothly because FOrayFont is already being used for PDF creation. More details on the FOray list. We have had some recent discussions about supported JRE's, from the main page of FOray[1] it says that 1.4 is used. There is a desire among the FOP developers to maintain compatibility with 1.3. Do you know if FOrayFont compatible with 1.3? Ben [1]http://foray.sourceforge.net/ > Hi Ben, hi All, > > I finally have some time to chime in, sorry for the delay. Thank you for > your interest in the font subsystem. > > My goal is to adapt the FOrayFont library to Fop. The main advantage of > FOrayFont over the Fop code is its ability to directly parse font files, > whereas currently with Fop there is a two-step process: first convert > the font metrics into an xml file, then use it within Fop through a > configuration file. You can have the process in [1]. > > I've submitted a first patch in december [2], that was refused because > of unacceptable shortcomings of FOrayFont. The main reasons were: > * lack of a default config file; > * configuration too complicated. > You will find all the details in [3]. Since that I'm working with Victor > on FOrayFont's improvement. We have recently ended the design phase and > have agreed on a set of changes that I still have to apply (you will > find the discussion on the FOray-dev mailing list archive from the last > two months. I'll add more on this on FOray-dev.). After that I believe > that the main shortcomings will be corrected and that an updated patch > can be submitted. > > PDFBox is pretty independant of my work. I currently rely entirely on > the Fop PDF library for PDF outputs, and I'm only adapting necessary > things to make it use FOrayFont. FOrayFont is a low-level library that > tries to be independent of any output format, and thus may be used by > whatever renderer. So if PDFBox were to be used by Fop, for me it would > just mean that I would have to adapt PDFBox instead of the Fop library. > > For FontBox this is different, and I think there is a possibility to > share resources in this area. I'll put more details on FOray-dev, but in > short it would be great if we could achieve the following: > * merge the best of FontBox and FOrayFont to obtain a good font library; > * agree on a common interface (i.e., an API) for the font library, that >would be used conjointly by Fop, PDFBox and FOray; > * adapt PDFBox to make it use this resulting library; > * make it work with Fop in some manner. > > I would like to work with you on the two first points. As you have > probably already noticed the discussion will be mainly held in the FOray > area. We will chime in here for Fop-specific things and to notify Fop > devs of advancements of the adaptation work. > > I'm glad to see that there is place for collaboration. I'm sure that we > will be able to achieve Great Things ;-) > > Cheers, > Vincent > > > Current way to configure fonts in Fop: > [1] http://xmlgraphics.apache.org/fop/trunk/fonts.html > > Patch for the adaptation of FOrayFont to Fop (now outdated): > [2] http://issues.apache.org/bugzilla/show_bug.cgi?id=35948 > > Reasons of the patch refusal: > [3] > http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop- dev/200512.mbox/browser > > > > Ben Litchfield a écrit : > > Jeremias, > > > > I'll start by answering your questions > > > > 1)What is minimum JDK required by PDFBox? > > > > PDFBox currently requires 1.4, because it uses ImageIO and a couple > > other things that make development much easier. PDFBox was compatible > > with 1.3 for a long time, but I made a decision that sticking with 1.3 > > would cost too much in development time versus using existing stuff in > > 1.4. In addition 1.3 is now two major versions old and in the EOL > > phase. As this effort will take some time before it could be released > > would it be reasonable to move the minimum requirement up to 1.4 for > > Batik and FOP at that time? > > > > 2)Does PDFBox require log4j? > > > > PDFBox used to be dependent on log4j, 0.7.2 has an optional dependency, > > the soon to be released 0.7.3 version will not use log4j at all. > > Currently PDFBox's only dependency is FontBox(see comments below), > > although bouncy castle will soon become an optional dependency for > > certificate based encryption and rhino(looks like Batik uses this as > > well) will also be an optional dependency for Javascript execution. > > > > > > Some additional comments, > > *After the 0.7.2 release, PDFBox split the font infrastructure into > > another project, so aptly named FontBox. No official version has been > > released yet but the project was created and all font parsing logic was > > separated from PDFBox. As far as I can tell there is no open source > > font library and for many of the same reasons we have discussed I > > thought it would b
