DO NOT REPLY [Bug 49687] [PATCH] Complex Script Support
https://issues.apache.org/bugzilla/show_bug.cgi?id=49687 --- Comment #9 from Pascal Sancho pascal.san...@takoma.fr 2010-08-03 03:14:45 EDT --- (In reply to comment #8) Glenn, build is OK, now. I didn't made Junit tests, I have to check my config before. Thx. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Complex Script Support - Trac Site Access
In order to better communicate with those interested in this work, I have enabled an anonymous reas access to the following Trac site, with wiki, ticket, and report views enabled. https://skynav.trac.cvsdude.com/fop/wiki I will be using this site during the development process to aid in documentation of this feature and to track related issues. I intend to also use it for other FOP related work I plan or may accomplish. Regards, Glenn
DO NOT REPLY [Bug 49687] [PATCH] Complex Script Support
https://issues.apache.org/bugzilla/show_bug.cgi?id=49687 --- Comment #10 from Glenn Adams gl...@skynav.com 2010-08-03 03:59:31 EDT --- For further documentation and issue tracking for this patch, see the following: https://skynav.trac.cvsdude.com/fop Regards, Glenn -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 49687] [PATCH] Complex Script Support
https://issues.apache.org/bugzilla/show_bug.cgi?id=49687 --- Comment #11 from Glenn Adams gl...@skynav.com 2010-08-03 04:45:56 EDT --- Created an attachment (id=25831) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=25831) Simple test Arabic output PDF file. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: fixing and maintaining zero reported warnings policy?
Hi Glenn, (Moving to general@ as maybe this is something we want to do at the XML Graphics project level. Please continue discussion there.) Thanks for bringing up this topic. I personally agree that a zero-warning policy would be A Good Thing. In theory newly committed code should have no Checkstyle warning, but I’m not sure that policy is thoroughly followed. Before enforcing such a policy it is necessary to come up with a Checkstyle file on which everyone agrees. The current one is not properly customized IMO. I started to create a new one from scratch a long time ago but never got round to finishing and testing it. Feel free to submit such a file. Once everyone is happy with it then you can start removing all the warnings on the current code if you feel like doing it. But doing it now would be a bit premature. I can’t really comment on findbugs, I must admit that I’ve never used it (me blushing with shame). This would probably also be a good thing to enforce its usage, but I suppose it also needs some customization. Thanks, Vincent Glenn Adams wrote: 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
RE: fixing and maintaining zero reported warnings policy?
I've wondered about that myself. I tried working with the Trunk and got countless warnings. They included dead code, deprecated methods, and unused assigned variables among other things. To sift through you could go into project specific compile options in Eclipse and tell it to ignore them if you have the project created as source. There may be an option to ignore on the ant build that's not as obvious but clean code would be appreciated, even as much as I appreciate the dirty code if the warnings don't crash anything and it got some useful features implemented faster. I would hope there's less urgency to implement now that the project has passed the 1.0 mark and code can be kept clean. From: Glenn Adams [mailto:gl...@skynav.com] Sent: Tuesday, August 03, 2010 4:27 AM To: FOP Developers Subject: fixing and maintaining zero reported warnings policy? 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
Files in Jar
I'm using Eclipse if that matters. I'm trying to create a jar file containing my TTF files, so I can load them in at runtime from the classpath rather than worry about physical file paths. I would like to do the same for images. When I create a project it lets me put in any file type, but when I try to create a JAR from it, those files don't get into that JAR. I've tried a new regular Project with the Export as JAR option. I've tried modifying the build.xml for the FOP project. I can't seem to get it to include the files. How should I go about doing this?
Re: fixing and maintaining zero reported warnings policy?
it may be difficult to agree on a particular checkstyles policy, and I really don't want to force creating or agreeing on such a policy, e.g., i don't like to break lines for some arbitrary limit and i use nested blocks and inline assignment, while others may not like that; however, i try to respect the style of the author of a given file, so if the author uses a line length limit, i will keep to it as well as other styles; for me, it is more important to create and maintain a zero warning policy; i don't care if the warnings are suppressed as long as an author gave them legitimate review and decided they were acceptable; both checkstyle and findbugs provides mechanisms for filtering the output to suppress warnings, and that is what i would prefer using, to permit what i call blessed warnings, etc. the important thing is that some author/contributor has taken the effort to review warnings and bless them if they are to be allowed or to remove their underlying cause if not; that is what i propose to do and to maintain; G. On Tue, Aug 3, 2010 at 6:45 PM, Vincent Hennebert vhenneb...@gmail.comwrote: Hi Glenn, (Moving to general@ as maybe this is something we want to do at the XML Graphics project level. Please continue discussion there.) Thanks for bringing up this topic. I personally agree that a zero-warning policy would be A Good Thing. In theory newly committed code should have no Checkstyle warning, but I’m not sure that policy is thoroughly followed. Before enforcing such a policy it is necessary to come up with a Checkstyle file on which everyone agrees. The current one is not properly customized IMO. I started to create a new one from scratch a long time ago but never got round to finishing and testing it. Feel free to submit such a file. Once everyone is happy with it then you can start removing all the warnings on the current code if you feel like doing it. But doing it now would be a bit premature. I can’t really comment on findbugs, I must admit that I’ve never used it (me blushing with shame). This would probably also be a good thing to enforce its usage, but I suppose it also needs some customization. Thanks, Vincent Glenn Adams wrote: 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
Re: DO NOT REPLY [Bug 49687] [PATCH] Complex Script Support
(1) do you have all of the following fonts on your system? simpo.ttf, simbdo.ttf, arialuni.ttf? (2) if so, are they new versions, e.g., from Win7? (3) if so, then please send me info on the platform you are using and include the output PDF file so I may verify, also send any warnings/errors you receiving when running FOP, since when I run the test file I include, I do not encounter any warnings/errors; note also that the Temp_ComplexScripts branch does not yet include the patch, which may be the cause; i have no control over when the patch will be applied, as I am not a committer, so have no means to update; G. On Tue, Aug 3, 2010 at 4:49 PM, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=49687 --- Comment #12 from Pascal Sancho pascal.san...@takoma.fr 2010-08-03 04:49:43 EDT --- (In reply to comment #8) Glenn, I do not get Character shaping when applying patch (against either trunk r981406 or Temp_ComplexScripts). The output is the same as FOP 1.0 without patch. I've tested it with Arial UNI (I didn't get Simplified Arabic). -- Pascal -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: Complex Script Support - Trac Site Access
i hear you, but I prefer to use the mechanism I described, since I have control over it; until I am granted committer status, I don't have that control within ASF; i would be happy to transition when I am granted committer status; in the mean time, i will use the mechanism i described; regards, glenn On Tue, Aug 3, 2010 at 6:30 PM, Vincent Hennebert vhenneb...@gmail.comwrote: Hi Glenn, That sounds good but it would be preferable to work in the ASF area, mainly use FOP’s wiki: http://wiki.apache.org/xmlgraphics-fop/DeveloperPages Anyone can add content to the wiki, you just need to create an account. You can create a new page related to your work on complex scripts and add a link to it on the above page. For issues, Bugzilla should cover your needs. If you deem necessary you can use bug #49687 as a meta-bug and create individual issues on which that bug would depend. Thanks, Vincent Glenn Adams wrote: In order to better communicate with those interested in this work, I have enabled an anonymous reas access to the following Trac site, with wiki, ticket, and report views enabled. https://skynav.trac.cvsdude.com/fop/wiki I will be using this site during the development process to aid in documentation of this feature and to track related issues. I intend to also use it for other FOP related work I plan or may accomplish. Regards, Glenn
DO NOT REPLY [Bug 44460] [PATCH] PDF Embedded files implementation
https://issues.apache.org/bugzilla/show_bug.cgi?id=44460 Jeremias Maerki jerem...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Jeremias Maerki jerem...@apache.org 2010-08-03 09:51:30 EDT --- I've taken Andrejus' patch and addressed my concerns on the original patch. I also extended the functionality somewhat and added documentation. Thanks for your initial work, Andrejus. It was definitely useful as a starting point. Please note that I've changed the desc attribute to description and name to filename. SVN revision: http://svn.apache.org/viewvc?rev=981875view=rev -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. You are the assignee for the bug.
Re: Complex Script Support - Trac Site Access
Glenn Adams wrote: Hi Glenn, i hear you, but I prefer to use the mechanism I described, since I have control over it; until I am granted committer status, I don't have that control within ASF; i would be happy to transition when I am granted committer status; in the mean time, i will use the mechanism i described; I don't want to discourage you from documenting your work but I agree with Vincent, using the Wiki is the preferred place to document your progress. I don't understand why committership status would matter? As Vincent already indicated anyone can view/modify the Wiki. Thanks, Chris regards, glenn On Tue, Aug 3, 2010 at 6:30 PM, Vincent Hennebert vhenneb...@gmail.com mailto:vhenneb...@gmail.com wrote: Hi Glenn, That sounds good but it would be preferable to work in the ASF area, mainly use FOP’s wiki: http://wiki.apache.org/xmlgraphics-fop/DeveloperPages Anyone can add content to the wiki, you just need to create an account. You can create a new page related to your work on complex scripts and add a link to it on the above page. For issues, Bugzilla should cover your needs. If you deem necessary you can use bug #49687 as a meta-bug and create individual issues on which that bug would depend. Thanks, Vincent Glenn Adams wrote: In order to better communicate with those interested in this work, I have enabled an anonymous reas access to the following Trac site, with wiki, ticket, and report views enabled. https://skynav.trac.cvsdude.com/fop/wiki I will be using this site during the development process to aid in documentation of this feature and to track related issues. I intend to also use it for other FOP related work I plan or may accomplish. Regards, Glenn
DO NOT REPLY [Bug 49695] New: [PATCH] Fop - replaced vars w UnitConv and GraphicsConstants
https://issues.apache.org/bugzilla/show_bug.cgi?id=49695 Summary: [PATCH] Fop - replaced vars w UnitConv and GraphicsConstants Product: Fop Version: all Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: general AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: joshua.marqu...@firstdata.com Created an attachment (id=25833) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=25833) Replaces many variables with constants from UnitConv and GraphicsConstants Replace several variable constants with appropriate constants from xmlgraphics UnitConv and GraphicsConstants. Searched on 25.4, 2.54, and 72 (for both UnitConv and GraphicsConstants) Questions regarding additional constants: 1) UnitConv vs. org.apache.fop.fo.properties.FixedLength FixedLength contains redundant constants. Fix? 2) Variable 72000 is used in multiple places in conjunction with variable 300. Fix? 3) PCL uses var 300 many times; no constant set to represent as default. Fix? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 49695] [PATCH] Fop - replaced vars w UnitConv and GraphicsConstants
https://issues.apache.org/bugzilla/show_bug.cgi?id=49695 Joshua Marquart joshua.marqu...@firstdata.com changed: What|Removed |Added Priority|P2 |P5 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: Complex Script Support - Trac Site Access
I added a Complex Scripts link under Design Documents heading in the FOP's wiki. G. On Tue, Aug 3, 2010 at 11:14 PM, Chris Bowditch bowditch_ch...@hotmail.comwrote: Glenn Adams wrote: Hi Glenn, i hear you, but I prefer to use the mechanism I described, since I have control over it; until I am granted committer status, I don't have that control within ASF; i would be happy to transition when I am granted committer status; in the mean time, i will use the mechanism i described; I don't want to discourage you from documenting your work but I agree with Vincent, using the Wiki is the preferred place to document your progress. I don't understand why committership status would matter? As Vincent already indicated anyone can view/modify the Wiki. Thanks, Chris regards, glenn On Tue, Aug 3, 2010 at 6:30 PM, Vincent Hennebert vhenneb...@gmail.commailto: vhenneb...@gmail.com wrote: Hi Glenn, That sounds good but it would be preferable to work in the ASF area, mainly use FOP’s wiki: http://wiki.apache.org/xmlgraphics-fop/DeveloperPages Anyone can add content to the wiki, you just need to create an account. You can create a new page related to your work on complex scripts and add a link to it on the above page. For issues, Bugzilla should cover your needs. If you deem necessary you can use bug #49687 as a meta-bug and create individual issues on which that bug would depend. Thanks, Vincent Glenn Adams wrote: In order to better communicate with those interested in this work, I have enabled an anonymous reas access to the following Trac site, with wiki, ticket, and report views enabled. https://skynav.trac.cvsdude.com/fop/wiki I will be using this site during the development process to aid in documentation of this feature and to track related issues. I intend to also use it for other FOP related work I plan or may accomplish. Regards, Glenn
Re: fixing and maintaining zero reported warnings policy?
It seems to me the following: Glenn, perhaps you could submit a separate de-warning patch or patches against trunk. That could be reviewed, applied, and downmerged into the complex script work. That might make this more manageable to the committers. I would also respectfully wonder if diffing the build output before and after your patches might be sufficient for your purposes. On Tue, Aug 3, 2010 at 8:20 PM, Glenn Adams gl...@skynav.com wrote: I don't plan to do any refactoring, just fixing warnings. The point of this is to be able to easily find new warnings introduced, and doing so is quite impractical with the current number of extant warnings. If we can get to a state of no warnings, then perhaps we can attempt to maintain that state of affairs for future commits, at least on the trunk. G. On Wed, Aug 4, 2010 at 6:30 AM, spepp...@leverkruid.eu wrote: 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 gl...@skynav.com: 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.
QR Barcode in FOP
We have a requirement to support QR barcode (it’s a 2D barcode type) in FOP. Does anyone know any open source product that works with FOP that generates QR barcode? FYI: barcode4j does not generate QR barcode or at least it’s not listed on their website. http://barcode4j.sourceforge.net/ Thanks for helping. -- View this message in context: http://old.nabble.com/QR-Barcode-in-FOP-tp29341838p29341838.html Sent from the FOP - Dev mailing list archive at Nabble.com.
The complex script patch per se
I'm a bit confused at this point. Is there a barrier to committing the patch-to-far to the designated interim branch?
Re: Complex Script Support - Trac Site Access
Vincent, Chris, et al. to clarify my earlier message, lest it be misread, i was not asking for (premature) commit access to FOP; i understand the ASF process, and have no issue with the fact that it will take time and contributions on my part to be deemed a candidate as committer; what i was doing was merely citing the fact that i am not a committer, and assumed (wrongly as it turns out) that one had to be a committer to add documentation to the FOP wiki; my intention in setting up a trac database was to satisfy my immediate need for documenting my work, and further, to integrate this documentation with my ongoing issue resolution process, which is handled nicely by the system I refer to below; for me, it will be easier and more productive to use this system; in the interim, i've create a simple FOP wiki page which refers to this site; as the work is completed, stabilized, and merged into the FOP trunk, i can easily migrate my design and other useful documentation into the FOP wiki directly; is that acceptable? G. On Wed, Aug 4, 2010 at 9:09 AM, Glenn Adams gl...@skynav.com wrote: I added a Complex Scripts link under Design Documents heading in the FOP's wiki. G. On Tue, Aug 3, 2010 at 11:14 PM, Chris Bowditch bowditch_ch...@hotmail.com wrote: Glenn Adams wrote: Hi Glenn, i hear you, but I prefer to use the mechanism I described, since I have control over it; until I am granted committer status, I don't have that control within ASF; i would be happy to transition when I am granted committer status; in the mean time, i will use the mechanism i described; I don't want to discourage you from documenting your work but I agree with Vincent, using the Wiki is the preferred place to document your progress. I don't understand why committership status would matter? As Vincent already indicated anyone can view/modify the Wiki. Thanks, Chris regards, glenn On Tue, Aug 3, 2010 at 6:30 PM, Vincent Hennebert vhenneb...@gmail.commailto: vhenneb...@gmail.com wrote: Hi Glenn, That sounds good but it would be preferable to work in the ASF area, mainly use FOP’s wiki: http://wiki.apache.org/xmlgraphics-fop/DeveloperPages Anyone can add content to the wiki, you just need to create an account. You can create a new page related to your work on complex scripts and add a link to it on the above page. For issues, Bugzilla should cover your needs. If you deem necessary you can use bug #49687 as a meta-bug and create individual issues on which that bug would depend. Thanks, Vincent Glenn Adams wrote: In order to better communicate with those interested in this work, I have enabled an anonymous reas access to the following Trac site, with wiki, ticket, and report views enabled. https://skynav.trac.cvsdude.com/fop/wiki I will be using this site during the development process to aid in documentation of this feature and to track related issues. I intend to also use it for other FOP related work I plan or may accomplish. Regards, Glenn
