Re: fixing and maintaining zero reported warnings policy?
We have two outstanding branches. All changes you make in this work will, after they have been merged into trunk, be propagated to those branches. I would prefer to restrict the work to the new functionality, and not include other refactoring/correction of warnings. Although I admit that correcting warnings would in itself be very valuable; I guess most warnings were just neglected by their authors, or are in older code. Simon Quoting Glenn Adams : Would anyone mind if I submit a patch that fixes all the outstanding warnings, etc., reported during the build process and by checkstyles and findbugs on the trunk? More importantly, if I do this, is it possible to adhere to a zero tolerance policy on warnings for future commits? I find the 3000 or so warnings currently produced to be a rather significant impediment to doing work on this code base, or at least, in preventing an avalanche of new warnings upon future commits, given the trouble required to determine the diffs between new warnings and old warnings. Perhaps this isn't a problem for changes to one file, but for changes to a hundred files, it is a major headache. Anyway, some of these 3000 are actually real, lurking bugs. I'm willing to do the cleanup work if others will help maintain cleanliness going forward. Regards, Glenn This message was sent using IMP, the Internet Messaging Program.
RE: Support for Arabic in FOP
Quoting Prakash sen : Hi, I am not sure on the licensing part as sebastian did some changes in FOP code and he provided me the jars. And as per what i had checked those jar print arabic correctly. Possibly he will only be able to answer and I am nots ure whether the change was made keeping FOP standards. He was planning to do bidi algorithm, no idea whether he worked on it later and whether he contribuited the below change to FOP. He did not commit any change to FOP. Simon This message was sent using IMP, the Internet Messaging Program.
RE: Support for Arabic in FOP
Licensing is not that easy. The ASF requires that the code be submitted under a Contributor License Agreement, see http://www.apache.org/licenses/. Even under more liberal regimes, having no license would not work, because there is nothing that states that it is open source. Simon Quoting Prakash sen : Thank you for your kind offer. What license applies to the jars? Best Regards, Jonathan S. Levinson Senior Software Developer Object Group InterSystems 617-621-0600 Hi, I am not sure on what changes sebastian had made in the source code, but i do have the jar files. If needed i can send them with some sample example. Regards, Prakash Sen. Hi, I dont think there is any license for it... Simply we can use it as it is opensource.. I hope it helps everyone.. Regards, Prakash Sen. This message was sent using IMP, the Internet Messaging Program.
RE: Volunteering to work on FOP development
> Arabic support is very important for us. > I looked in nabble for Sebastian's post that would allow FOP to work with > Arabic, but was unable to find his post, though I found a reference to it, > with a no longer valid hyper-link. This is a link to his message: http://markmail.org/message/qu534sfte3xaaosb#query:sebastian%20weber%20arabic+page:1+mid:tbj7vyt56wim4bfj+state:results, but the link to his work is no longer valid. Kia Teymourian also worked on Arabic support in FOP, and his work is available at http://user.cs.tu-berlin.de/~kiat/fop/. Regards, Simon
RE: Volunteering to work on FOP development
Sounds promising. Simon Quoting Jonathan Levinson : I'll forward your e-mail to management and tell them there are some license agreements we need to sign. We are an international company, and need to support non-Western documents including Greek, Thai and Chinese, amongst many others. We have technical people at work in every area of the globe. Best Regards, Jonathan S. Levinson Senior Software Developer Object Group InterSystems 617-621-0600 -Original Message- From: Simon Pepping [mailto:spepp...@leverkruid.eu] Sent: Tuesday, September 15, 2009 3:49 PM To: fop-dev@xmlgraphics.apache.org Subject: Re: Volunteering to work on FOP development On Mon, Sep 14, 2009 at 03:32:25PM -0400, Jonathan Levinson wrote: Hi, My management has asked me to volunteer to help fix FOP bugs and add FOP enhancements. I'm not yet familiar with FOP internals though I've read your design documents. That is good news indeed. Thanks to Intersystems for this contribution. Note that you need to sign an Individual Contributor License Agreement (ICLA), and most conveniently your company needs to sign a Corporate Contributor License Agreement (CCLA), see http://www.apache.org/licenses/#clas, before FOP or any other ASF project can accept your code contributions. One area in which FOP needs more work is the compliance with the FO spec, versions 1.0 and 1.1, see http://xmlgraphics.apache.org/fop/compliance.html. Another area where FOP needs more work is support for non-Western documents. I do not know where the problems are, but it probably does not work right now. Ideally, we would have contributors from regions with such problems. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.eu This message was sent using IMP, the Internet Messaging Program.
Re: svn commit: r757172 - in /xmlgraphics/fop/trunk: ./ src/documentation/content/xdocs/trunk/ src/java/org/apache/fop/tools/fontlist/
This is a cute tool. About the zapfdingbats page, I only see the scissors and to fox line. Is that te intended rendering? Simon Quoting jerem...@apache.org: Author: jeremias Date: Sun Mar 22 11:54:39 2009 New Revision: 757172 URL: http://svn.apache.org/viewvc?rev=757172&view=rev Log: Added a command-line tool to list all configured fonts (org.apache.fop.tools.fontlist.FontListMain). + + Font List Command-Line Tool + +FOP contains a small command-line tool that lets you generate a list of all configured +fonts. Its class name is: org.apache.fop.tools.fontlist.FontListMain. +Run it with the "-?" parameter to get help for the various options. + + This message was sent using IMP, the Internet Messaging Program.
Re: svn commit: r474387 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/fonts/ src/java/org/apache/fop/fonts/truetype/ src/java/org/apache/fop/fonts/type1/
> Jeremias Maerki a écrit :
>
>> I'd be grateful if anyone could test what happens if you load a Type 1
>> fonts on a Unix where the PFM file has an uppercase extension, e.g.
>> "FUTURA.PFM". I have to construct the URI to the PFM manually from the
>> PFB and use a lowercase extension (".pfm"). Maybe we have to improve
>> that to check with upper- and lowercase to account for case sensitive
>> file systems.
>
> This fails. IMO the safest solution is to require that the name of the
> pfm file is specified in the config file. All the more so it should also
> be possible to give an afm file instead of a pfm one (BTW, Fop can't
> read afm files, can it? Because FOrayFont can...).
Make that optional, if the pfm file name deviates from the normal pattern.
Simon
Re: Removing deprecated stuff in the High-level API
> Jeremias Maerki schrieb: >> On 13.11.2006 22:24:27 J.Pietschmann wrote: >> >>>Jeremias Maerki wrote: >>> If nobody objects I'm going to remove the deprecated elements in the apps package later this week. >>> >>>Umm, couldn't this wait until after the 0.93 release? Well, that's >>>a question, not a veto. If you think it's a good idea, go ahead. >> >> It sure could. I just thought I'd clean it up for the release. But I >> wouldn't mind leaving it in for another round. Other opinions? > > I'd rather remove it now than between the 0.93 (without beta tag) and > the 1.0 release. I share that preference. Simon
