Re: Problem while trying to generate Multilingual PDF

2010-05-17 Thread Glenn Adams
I am working on adding general support for complex scripts, such as Arabic, Indic, etc. See the following comments on bug 32789: https://issues.apache.org/bugzilla/show_bug.cgi?id=32789#c17 https://issues.apache.org/bugzilla/show_bug.cgi?id=32789#c19 It requires fairly extensive enhancements to

Re: svn commit: r946585 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/fonts: AFPFont.java AbstractOutlineFont.java CharacterSet.java CharacterSetBuilder.java CharacterSetOrientation.java D

2010-05-21 Thread Glenn Adams
I concur with this change, and have already made some changes in this direction in my work on adding complex script support. Please note that it is not quite so simple as merely changing from char to int in some locations. It is also necessary to convert from UTF-16 to UTF-32, i.e., to the full

Re: svn commit: r946585 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/fonts: AFPFont.java AbstractOutlineFont.java CharacterSet.java CharacterSetBuilder.java CharacterSetOrientation.java D

2010-05-21 Thread Glenn Adams
by this discussion. AFAIK, Java has rejected moving to 32 bits in Java 5. Instead, they are supporting supplementary characters. There's a discussion here: http://java.sun.com/developer/technicalArticles/Intl/Supplementary/ Peter West Lord, to whom shall we go? On 21/05/2010, at 11:11 PM, Glenn

Re: OPen Type Korean (Hangul) Fonts

2010-07-06 Thread Glenn Adams
On Wed, Jul 7, 2010 at 2:26 AM, Vincent Hennebert vhenneb...@gmail.comwrote: It must be seen whether advanced typography is needed to properly typeset Korean (for example, glyph shaping like in Arabic). Advanced typographic tables are not used by FOP’s layout engine at the moment. That may

request for complex scripts branch with commit access

2010-07-06 Thread Glenn Adams
/modified files listed below. Regards, Glenn Adams A src/java/org/apache/fop/fonts/DiscontinuousAssociationException.java M src/java/org/apache/fop/fonts/apps/TTFReader.java A src/java/org/apache/fop/fonts/GlyphTable.java M src/java/org/apache/fop/fonts/MultiByteFont.java

PageViewport/Page as subclasses of Area rather than AreaTreeObject?

2010-07-06 Thread Glenn Adams
Is there a good/strong reason why PageViewport and Page are defined as subclasses of AreaTreeObject rather than Area? In my recent work to add full support for the writing-system trait, I found it to be more consistent to redefine these as subclasses of Area. After all, the XSL-FO spec defines

Re: request for complex scripts branch with commit access

2010-07-07 Thread Glenn Adams
bombard us with good contributions, you can be pretty sure to be fast-tracked to committership. At least, you already have one task behind you: Your ICLA is on file with the ASF. That's good. On 07.07.2010 07:08:29 Glenn Adams wrote: What is the policy for branch creation? In particular

nomenclature - property vs trait

2010-07-08 Thread Glenn Adams
The following is for consideration only. I am not proposing any specific action be taken at this time. I've notice some inconsistencies in naming as pertains to referring to the category of properties versus traits. The XSL FO semantic model (e.g., see

Re: Font Glyph?

2010-07-19 Thread Glenn Adams
Unicode does not prescribe how to render characters for which the assigned font(s) have no corresponding glyph(s). It does, however, make recommendations on how an application or system should handle this case, about which see Unicode 5.1 Section 5.3 Unknown and Missing Characters, under the

Re: Font Glyph?

2010-07-20 Thread Glenn Adams
) fonts have a dedicated glyph for unsupported characters. I think this is what FOP should fall back to in case of a missing glyph. Yes, that is well when there is no last resort font, but it is not really adequate. Vincent Glenn Adams wrote: Unicode does not prescribe how to render

Re: Font Glyph?

2010-07-21 Thread Glenn Adams
integration using embedded code, there should be an option for all custom font setup in the API. -- *From:* Glenn Adams [mailto:gl...@skynav.com] *Sent:* Tuesday, July 20, 2010 8:59 PM *To:* fop-dev@xmlgraphics.apache.org *Subject:* Re: Font Glyph? Comment inline

Re: Font Glyph?

2010-07-26 Thread Glenn Adams
transparent to the user. At the moment a warning is issued when glyphs are missing, listing the affected code points. Along with using the .notdef glyph, I think that’s user-friendly enough. Vincent Glenn Adams wrote: I agree that one should not simply add new configuration specifications willy

Complex Script Support - Trac Site Access

2010-08-03 Thread Glenn Adams
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

Re: fixing and maintaining zero reported warnings policy?

2010-08-03 Thread Glenn Adams
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

Re: DO NOT REPLY [Bug 49687] [PATCH] Complex Script Support

2010-08-03 Thread Glenn Adams
(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

Re: Complex Script Support - Trac Site Access

2010-08-03 Thread Glenn Adams
. 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

Re: Complex Script Support - Trac Site Access

2010-08-03 Thread Glenn Adams
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

Re: Complex Script Support - Trac Site Access

2010-08-03 Thread Glenn Adams
, 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

Re: DO NOT REPLY [Bug 49687] [PATCH] Complex Script Support

2010-08-04 Thread Glenn Adams
font familly). I'll be back after holidays to adapt my FOs (to use ArialUni) to make further tests and feedbacks. Good job, Glenn. Pascal Le 04/08/2010 02:33, Glenn Adams a écrit : OK, I see from your output file that it is indeed working correctly for ArialUni, peforming both bidi

Re: Complex Script Support - Trac Site Access

2010-08-04 Thread Glenn Adams
in the ASF area... Thanks, Vincent Glenn Adams wrote: 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

Re: Complex Script Support - Trac Site Access

2010-08-04 Thread Glenn Adams
on a personal note, perhaps I should add that I've been writing code for 40 years, and am nearing 60 myself, so i'm not quite as nimble as some in making transitions, especially with dev tool chains... :) g. On Wed, Aug 4, 2010 at 6:56 PM, Glenn Adams gl...@skynav.com wrote: i am using

Re: Complex Script Support - Trac Site Access

2010-08-05 Thread Glenn Adams
On Thu, Aug 5, 2010 at 7:18 PM, Vincent Hennebert vhenneb...@gmail.comwrote: Hi Glenn, From you first message I had the impression that you wanted to keep using that tool for future documentation as i've said, i intend to transition the documentation to the FOP wiki over a period of time,

Re: Complex Script Support - Trac Site Access

2010-08-05 Thread Glenn Adams
more On Thu, Aug 5, 2010 at 8:20 PM, Glenn Adams gl...@skynav.com wrote: On Thu, Aug 5, 2010 at 7:18 PM, Vincent Hennebert vhenneb...@gmail.comwrote: Hi Glenn, From you first message I had the impression that you wanted to keep using that tool for future documentation as i've said, i

Re: fixing and maintaining zero reported warnings policy?

2010-08-09 Thread Glenn Adams
mods. Note that one compile warning wiill remain (a deprecation) until my recent patch to xmlgraphics-commons is merged and a new build of commons is used with fop builds. G. On Wed, Aug 4, 2010 at 8:20 AM, Glenn Adams gl...@skynav.com wrote: I don't plan to do any refactoring, just fixing

[Bug 49733] [PATCH] resolve compilation, checkstyle, javadoc warnings

2010-08-09 Thread Glenn Adams
Regarding the patch I just posted, I would recommend applying CBR policy to get it into the trunk ASAP before other changes are committed. Of course, the present committers will decide the appropriate process yourselves, but that is my input. Regards, Glenn

Re: [Bug 49733] [PATCH] resolve compilation, checkstyle, javadoc warnings

2010-08-10 Thread Glenn Adams
a.k.a. CTR (commit then review) On Tue, Aug 10, 2010 at 1:54 PM, Glenn Adams gl...@skynav.com wrote: Regarding the patch I just posted, I would recommend applying CBR policy to get it into the trunk ASAP before other changes are committed. Of course, the present committers will decide

[Bug 49733] [PATCH] resolve compilation, checkstyle, javadoc warnings

2010-08-10 Thread Glenn Adams
Vincent, I disagree with your proposed delay. First, there is an established consensus on the rules, namely those that are in the existing checkstyle-5.0.xml file. The reason they are the current consensus is that they are there in the trunk, and nobody has objected to them. I do not care to

Re: [Bug 49733] [PATCH] resolve compilation, checkstyle, javadoc warnings

2010-08-10 Thread Glenn Adams
. On 10.08.2010 13:13:08 Glenn Adams wrote: Vincent, I disagree with your proposed delay. First, there is an established consensus on the rules, namely those that are in the existing checkstyle-5.0.xml file. The reason they are the current consensus is that they are there in the trunk, and nobody

Re: [Bug 49733] [PATCH] resolve compilation, checkstyle, javadoc warnings

2010-08-12 Thread Glenn Adams
On Thu, Aug 12, 2010 at 3:18 PM, Glenn Adams gl...@skynav.com wrote: that is a reasonable objection to removing the file, so indeed i would not object to leaving it in place; however, i did not test checkstyle 1.4, and indeed, there are a few changes that appear at the end of the new

Re: [Bug 49733] [PATCH] resolve compilation, checkstyle, javadoc warnings

2010-08-12 Thread Glenn Adams
vincent, my apologies if I offended, as that was not my intent; i'm sure we will manage to work our way through this towards a successful conclusion; respectfully, glenn On Thu, Aug 12, 2010 at 7:41 PM, Vincent Hennebert vhenneb...@gmail.comwrote: This message lacks of courtesy, therefore I

Re: [Bug 49733] [PATCH] resolve compilation, checkstyle, javadoc warnings (a proposal for next steps)

2010-08-12 Thread Glenn Adams
inline On Thu, Aug 12, 2010 at 8:25 PM, Jeremias Maerki d...@jeremias-maerki.chwrote: 1. Clarify the thing with LineBreak*. It was necessary to update the line break data in order to regenerate LineBreakUtils.java; otherwise, the generation process failed to to a missing column ('CP') when

Re: [Bug 49733] [PATCH] resolve compilation, checkstyle, javadoc warnings (a proposal for next steps)

2010-08-12 Thread Glenn Adams
On Fri, Aug 13, 2010 at 10:57 AM, Glenn Adams gl...@skynav.com wrote: 3. Adjust the Checkstyle profile to allow log and disallow whitespace before and after parantheses. Then remove log-related //CS constants and excessive whitespace. I would not agree to restricting the style rules

Re: [Bug 49733] [PATCH] resolve compilation, checkstyle, javadoc warnings (a proposal for next steps)

2010-08-13 Thread Glenn Adams
On Fri, Aug 13, 2010 at 4:32 PM, Simon Pepping spepp...@leverkruid.euwrote: Glenn notes that he used comments to suppress checkstyle warnings in such cases as: - certain uses of package, protected, or public visibility of fields, which would have required a fairly large number of changes to

Re: Complex Script Support - working procedure

2010-08-13 Thread Glenn Adams
What I had in mind was as follows: 1. after the cleanup/warnings patch is applied to trunk, it should be merged into the complex scripts branch (which still does not have the complex scripts patch applied); 2. I merge the head of the updated complex scripts branch with my existing

a bit of bio info

2010-08-13 Thread Glenn Adams
It has been suggested to me that I provide a few C.V. details to the group, to help introduce my background that may be of some use in FOP work, so here are a few details. If anyone would like a fuller bio, let me know and I will happily send. - began working with TeX78 in the late 70's; -

Re: Complex Script Support

2010-08-14 Thread Glenn Adams
that fixes these issues. Regards, Glenn Adams 2010/8/14 أبو عبد الله محمد يوسف الرابحي youcef...@gmail.com hi all, i have compiled the new Fop source with glenn's patch... i have Foped a test fo file with some Arabic text (see the attached ara.fo and ara.pdf); and at the moment i can give

Re: DO NOT REPLY [Bug 49733] [PATCH] resolve compilation, checkstyle, javadoc warnings

2010-08-14 Thread Glenn Adams
Jeremias, Thanks for following through on this patch in a timely manner. I expect to follow up with a further update to the complex scripts patch which leverages the result of this cleanup patch. Also, though I have mentioned in previously, there remains the task of addressing the ~1000

Re: findbugs results

2010-08-16 Thread Glenn Adams
On Mon, Aug 16, 2010 at 9:34 PM, Simon Pepping spepp...@leverkruid.euwrote: I noted that the problems reported here are harder to fix. They often touch upon design issues. yes, which is one reason I have not (yet) attempted to fix them, as fixes will require greater attention to intended

Re: svn commit: r986451 [1/13] - in /xmlgraphics/fop/branches/Temp_ComplexScripts: ./ examples/plan/src/org/apache/fop/plan/ src/codegen/java/org/apache/fop/tools/ src/codegen/unicode/data/ src/codege

2010-08-17 Thread Glenn Adams
@ vincent thanks for merging from trunk; i'm preparing an updated complex scripts patch that includes the merge and a few fixes, so hold off a bit on applying the original complex scripts patch until i update it; regards, glenn On Wed, Aug 18, 2010 at 2:57 AM, vhenneb...@apache.org wrote:

Re: DO NOT REPLY [Bug 49687] [PATCH] Complex Script Support

2010-08-19 Thread Glenn Adams
--- Comment #16 from Glenn Adams gl...@skynav.com 2010-08-19 06:14:14 EDT --- Created an attachment (id=25912) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=25912) Patch to revision 987110 of branch Temp_ComplexScripts. This patch file replaces the prior patch against trunk

upcoming change to IFPainter.drawText()

2010-08-30 Thread Glenn Adams
Folks, I'd like to mention a change I will implement on IFPainter#drawText method in order to accommodate complex scripts (as well as non-complex script usage in a variety of written languages). I'm bringing this up now so there can be discussion ahead of time if needed. Basically, the change is

Re: upcoming change to IFPainter.drawText()

2010-08-30 Thread Glenn Adams
back, e.g., to (1), at a future date. Comments? G. On Mon, Aug 30, 2010 at 8:19 PM, Glenn Adams gl...@skynav.com wrote: Folks, I'd like to mention a change I will implement on IFPainter#drawText method in order to accommodate complex scripts (as well as non-complex script usage in a variety

Re: upcoming change to IFPainter.drawText()

2010-08-30 Thread Glenn Adams
) { gpos[i][0] += d; // reconcile x placement adjustment gpos[i][2] += d; // reconcile x advance adjustment } } } } On Tue, Aug 31, 2010 at 4:51 AM, Glenn Adams gl...@skynav.com wrote: Perhaps it is useful to indicate how the existing dx[] adjustments map into the more

Re: TODO tag [was: Re: svn commit: r990148 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: area/ fo/ fo/flow/ fo/flow/table/ fo/pagination/ fo/properties/ hyphenation/ layoutmgr/ layoutmgr/inline

2010-08-31 Thread Glenn Adams
and a large set of authors. Simon On Sat, Aug 28, 2010 at 09:28:06AM +0800, Glenn Adams wrote: Vincent, Could you explain your rationale for this change? Originally, these were all marked with a non-standard '@todo' javadoc tag, which javadoc complained about, indicating

Re: TODO tag [was: Re: svn commit: r990148 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: area/ fo/ fo/flow/ fo/flow/table/ fo/pagination/ fo/properties/ hyphenation/ layoutmgr/ layoutmgr/inline

2010-09-02 Thread Glenn Adams
On Thu, Sep 2, 2010 at 6:04 PM, Jeremias Maerki d...@jeremias-maerki.chwrote: I'm not sure we have the tooling to make sure noone uses @todo. Actually, checkstyle 5.1 will report warnings for any use of a non-standard tag that is not qualified with a dotted prefix. Also the standard Doclet in

base 14 font kerning

2010-09-05 Thread Glenn Adams
Is there a reason that kerning of the base 14 fonts is disabled by default? Furthermore, except by programmatic means, there does not seem to be a way to enable it except by using FontManager.setBase14KerningEnabled() or the deprecated method FopFactory.setBase14KerningEnabled(). This technique

Re: base 14 font kerning

2010-09-06 Thread Glenn Adams
to it. On 06.09.2010 07:58:41 Glenn Adams wrote: Is there a reason that kerning of the base 14 fonts is disabled by default? Furthermore, except by programmatic means, there does not seem to be a way to enable it except by using FontManager.setBase14KerningEnabled() or the deprecated method

Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support

2010-09-06 Thread Glenn Adams
Having gone through the process of creating this working maven build configuration, it seems that the potential benefits of its use include: - dependency management of the use of external artifacts, which is not managed by ant, and causes us to include external dependencies as part of

Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support

2010-09-06 Thread Glenn Adams
, Sep 7, 2010 at 10:33 AM, Craig Ringer cr...@postnewspapers.com.auwrote: On 09/07/2010 04:25 AM, Glenn Adams wrote: Having gone through the process of creating this working maven build configuration, it seems that the potential benefits of its use include: * dependency management of the use

Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support

2010-09-07 Thread Glenn Adams
with no outside connection. I like that and would like it to stay that way. On 07.09.2010 04:33:02 Craig Ringer wrote: On 09/07/2010 04:25 AM, Glenn Adams wrote: Having gone through the process of creating this working maven build configuration, it seems that the potential benefits of its use

Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support

2010-09-07 Thread Glenn Adams
have not and am not proposing to substitute maven for ant. I only wish to share a useful build process with others that are comfortable with using maven. Those that are not can ignore this feature. Regards, G. On Tue, Sep 7, 2010 at 3:29 PM, Glenn Adams gl...@skynav.com wrote: ok; but is there any

Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support

2010-09-07 Thread Glenn Adams
time maintaining it. On 07.09.2010 09:29:15 Glenn Adams wrote: ok; but is there any reason not to commit the patch to permit those who find maven useful to use it? there are many features in FOP that cater to specific interests, why not permit that with the build process as well

Re: base 14 font kerning

2010-09-07 Thread Glenn Adams
Agreed. That is why I thought it best not to change that, while still adding the ability for the user to configure it. G. On Tue, Sep 7, 2010 at 5:00 PM, Chris Bowditch bowditch_ch...@hotmail.comwrote: Glenn Adams wrote: Hi Glenn/Jeremias, I've already implemented in my complex scripts

Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support

2010-09-07 Thread Glenn Adams
On Tue, Sep 7, 2010 at 4:40 PM, Jeremias Maerki d...@jeremias-maerki.chwrote: Due to its inflexibility, projects are almost forced to adopt it to keep everyone happy, just because Maven can't include a simple JAR that is not in a repository. Perhaps this has changed, because while I was

Re: DO NOT REPLY [Bug 49881] [PATCH] add maven build support

2010-09-08 Thread Glenn Adams
://issues.apache.org/bugzilla/show_bug.cgi?id=49881 --- Comment #1 from Glenn Adams gl...@skynav.com 2010-09-04 06:42:53 EDT --- Created an attachment (id=25986) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=25986) Patch to add maven build support. This patch has been verified

Re: base 14 font kerning

2010-09-08 Thread Glenn Adams
On 06/09/10 06:58, Glenn Adams wrote: Is there a reason that kerning of the base 14 fonts is disabled by default? Furthermore, except by programmatic means, there does not seem to be a way to enable it except by using FontManager.setBase14KerningEnabled() or the deprecated method

Re: TODO tag

2010-09-08 Thread Glenn Adams
Of the three options: 1. @todo 2. @asf.todo 3. //TODO I prefer @todo, even if it means having a javadoc warning, but perhaps that warning can be suppressed. G. On Thu, Sep 9, 2010 at 1:24 AM, Simon Pepping spepp...@leverkruid.euwrote: //TODO is unstructured. @todo fits into an existing

Re: svn commit: r995176 - in /xmlgraphics/fop/branches/Temp_ComplexScripts: ./ src/java/org/apache/fop/afp/ src/java/org/apache/fop/afp/modca/ src/java/org/apache/fop/area/ src/java/org/apache/fop/dat

2010-09-08 Thread Glenn Adams
Simon, Thanks for keeping the branch up to date! It is a big help. FYI, I'm expecting to post a new follow-on patch for the branch (perhaps over the next week) in order to add support for non-spacing marks (and generalized position adjustments - namely the OpenType GPOS table). G. On Thu, Sep

Re: DO NOT REPLY [Bug 49881] [PATCH] add maven build support

2010-09-08 Thread Glenn Adams
+0800, Glenn Adams wrote: If I understand you correctly, the answer is no. The file maven/pom.xml in the patch explicitly references revision 1.7 of the batik artifacts. So any use of upward revisions of those artifacts would require updating the pom.xml file to reflect use of a newer

Re: DO NOT REPLY [Bug 49881] New: [PATCH] add maven build support

2010-09-10 Thread Glenn Adams
On Fri, Sep 10, 2010 at 3:51 AM, Vincent Hennebert vhenneb...@gmail.comwrote: On 07/09/10 10:10, Craig Ringer wrote: On 7/09/2010 4:40 PM, Jeremias Maerki wrote: snip/ ... then it'd look for local/somejar-2.2.jar within my local repository. If I put the jar where it should be found, no

gsub/gpos opentype table functions

2010-09-11 Thread Glenn Adams
For those following the work on complex script support, attached is a sample showing a combination of GSUB (glyph substitution) and GPOS (glyph position) table functions operating on Arabic text as produced by FOP 1.0 with complex script features enabled: In this sample, the following GSUB

Re: gsub/gpos opentype table functions

2010-09-13 Thread Glenn Adams
={ 0, 0, 0, 0 } { 5600, 1952, -6432, 0 } { 0, 0, 0, 0 } { 608, -9664, -6400, 0 } { 0, 0, 0, 0 }, which would make understanding of the code to interpret it easier. Regards, Simon On Sun, Sep 12, 2010 at 11:42:37AM +0800, Glenn Adams wrote: For those following the work on complex script support

Re: Nightly snapshots

2010-09-21 Thread Glenn Adams
Do these snapshots include the successful running of junit tests? Or are they merely the result of compilation without any testing? G. On Tue, Sep 21, 2010 at 7:02 PM, Simon Pepping spepp...@leverkruid.euwrote: I am pleased to inform you that every night a snapshot of Apache FOP's main

Complex Chained Contextual Substitution (GSUB) and Positioning (GPOS) Example

2010-09-21 Thread Glenn Adams
Attached is a sample input FO, output IF, and output PDF example showing the functioning of complex chained contextual glyph substitution and glyph positioning operations, now available on my working dev branch at git:// github.com/skynavga/fop.git. The GDEF (glyph definition) table is now

Re: Complex Chained Contextual Substitution (GSUB) and Positioning (GPOS) Example

2010-09-23 Thread Glenn Adams
distribution, but I cannot post it on my ASF page; I could post it on your Trac site. OTOH, why do you not (yet) submit a patch? Then I could do both easily. Simon On Tue, Sep 21, 2010 at 11:30:41PM +0800, Glenn Adams wrote: Attached is a sample input FO, output IF, and output PDF example showing

Re: Complex Chained Contextual Substitution (GSUB) and Positioning (GPOS) Example

2010-09-25 Thread Glenn Adams
which are not in version 5.00. I think you should reflect this version on your Trac site. I see on the web that v 5.92 is distributed with Windows 7. I do not have that. Simon On Fri, Sep 24, 2010 at 09:13:50AM +0800, Glenn Adams wrote: If you want to see what FOP thinks is in the font

Re: TrueType Font Embedding

2010-11-11 Thread Glenn Adams
I haven't been following this thread very closely, but subset fonts are and will be important for complex script support, since some Arabic and related fonts have thousands of glyphs, of which only a small subset is typically used on a given page or in a document. One further issue with complex

new findbug errors

2010-11-16 Thread Glenn Adams
I notice a few new findbugs errors creeping into trunk. Please try to run the findbugs target before commiting in order to fix any newly introduced bugs. Here are the new ones I see: a href=#MS_SHOULD_BE_FINALBug type MS_SHOULD_BE_FINAL (click for details)/a br/In class

Re: svn commit: r1036179 [1/2] - in /xmlgraphics/fop/trunk

2010-11-18 Thread Glenn Adams
I agree with Vincent that common acronyms should not be changed to words (initial cap only) just to satisfy findbugs; this is a case where exclusions to findbugs should be used, or even a blanket exclusion; furthermore, the term Namespace in XML is well established as a single word and should not

Re: new findbug errors

2010-11-19 Thread Glenn Adams
Thanks! You say: I note that we have not accepted findbugs as a tool of the project. I think that not all developers are a fan of the tool. Is there an alternative, and equally or more effective tool that is acceptable to more developers, e.g., PMD? If there is, then perhaps we should migrate to

Re: new findbug errors

2010-11-19 Thread Glenn Adams
, One note: You introduced findbugs as a tool, and you created the findbugs target in the build file. Simon On Fri, Nov 19, 2010 at 08:28:09AM -0700, Glenn Adams wrote: Thanks! You say: I note that we have not accepted findbugs as a tool of the project. I think that not all developers

Re: DO NOT REPLY [Bug 50492] New: Mapping of glyphs in the private area of TTF symbol fonts is only done if cmapRangeOffsets is not zero

2010-12-17 Thread Glenn Adams
I'm not sure what the rationale for mapping to the ASCII range is in either case. On Fri, Dec 17, 2010 at 1:03 AM, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=50492 Summary: Mapping of glyphs in the private area of TTF symbol

Re: How much work is needed for FOP to support OpenType fonts?

2011-01-18 Thread Glenn Adams
What do you mean by fully? If you are referring to the OpenType GDEF, GSUB, GPOS support, then work is already underway to add that functionality. See the following for further info: http://people.apache.org/~spepping/ http://wiki.apache.org/xmlgraphics-fop/ComplexScripts Regards, Glenn On Tue,

Re: How much work is needed for FOP to support OpenType fonts?

2011-01-18 Thread Glenn Adams
Resending to original sender. On Tue, Jan 18, 2011 at 2:27 PM, Glenn Adams gl...@skynav.com wrote: What do you mean by fully? If you are referring to the OpenType GDEF, GSUB, GPOS support, then work is already underway to add that functionality. See the following for further info: http

Re: How much work is needed for FOP to support OpenType fonts?

2011-01-18 Thread Glenn Adams
appreciate the re-send, but I have subscribed to the list and will stay subscribed for the duration of this email thread.] On Tue, Jan 18, 2011 at 9:27 PM, Glenn Adams gl...@skynav.com wrote: What do you mean by fully? If you are referring to the OpenType GDEF, GSUB, GPOS support, then work

Re: How much work is needed for FOP to support OpenType fonts?

2011-01-18 Thread Glenn Adams
That is a better question, but one I cannot answer, as I have not looked into the CFF support issue. Perhaps another DEV would care to respond. G. On Tue, Jan 18, 2011 at 4:03 PM, Ivan Ristic ivan.ris...@gmail.com wrote: On Tue, Jan 18, 2011 at 10:51 PM, Glenn Adams gl...@skynav.com wrote

Re: OpenType font library [was: Re: How much work is needed for FOP to support OpenType fonts?]

2011-01-19 Thread Glenn Adams
I think we are taking the only reasonable route available w.r.t. complex script support, namely reading the OTF font directly to extract and use the advanced typographic tables. The same mechanisms can be used for the TTF AAT tables as well. The inquiry that started this thread seems most

zero checkstyle/findbugs warnings!!

2011-01-19 Thread Glenn Adams
i just fast forwarded 31 checkins into my copy of trunk and built, tested, checked styles and ran findbugs, and ZERO style errors or findbugs warnings are reported!! i'm very happy to see that we are now paying attention to code quality testing in a real way, so congratulations dev team! best

fop.cmd doesn't handle path with whitespace

2011-01-20 Thread Glenn Adams
Carl sent me this fix for fop.cmd, which breaks if the path to fop.cmd contains a whitespace. Perhaps a committer can fix this faster than having me submit a patch, etc. Regards, Glenn -- Forwarded message -- From: Carl Hoffman Date: Thu, Jan 20, 2011 at 8:26 PM To: Glenn Adams

testing bug fixes - not!

2011-01-24 Thread Glenn Adams
Is there a reason why *all* bug fixes are not accompanied by one or more new test cases that demonstrate the presence and absence of the bug before and after the fix? Adding such test cases should be mandatory for all bug fix commits. I wouldn't quite go that far for performance and clean up

Re: testing bug fixes - not!

2011-01-24 Thread Glenn Adams
showing the performance delta, then that would be welcome; Of the above, I'm mostly concerned with the first and second cases. Regards, Glenn On Mon, Jan 24, 2011 at 3:42 PM, Andreas Delmelle andreas.delme...@telenet.be wrote: On 24 Jan 2011, at 23:17, Glenn Adams wrote: Hi Glenn

Re: The base of relative URIs in fop.xconf

2011-02-04 Thread Glenn Adams
note that the file: URL scheme does not technically support relative URLs; however, that hasn't prevented some implementations from making non-standard extensions to provide such support On Fri, Feb 4, 2011 at 7:08 AM, Jeremias Maerki d...@jeremias-maerki.chwrote: I found a potential problem:

Re: The base of relative URIs in fop.xconf

2011-02-04 Thread Glenn Adams
relative URIs. The file URIs are eventually resolved to file URLs which are then absolute. On 04.02.2011 15:50:09 Glenn Adams wrote: note that the file: URL scheme does not technically support relative URLs; however, that hasn't prevented some implementations from making non-standard

new checkstyle warnings, findbugs in trunk

2011-02-15 Thread Glenn Adams
Please fix the 2 new checkstyle warnings and 9 new findbug errors in trunk. In the future, please check and fix before committing. Thanks, Glenn

Re: new checkstyle warnings, findbugs in trunk

2011-02-15 Thread Glenn Adams
, Glenn Adams wrote: Please fix the 2 new checkstyle warnings and 9 new findbug errors in trunk. In the future, please check and fix before committing. People, when are we going to vote Glenn a committer, so we can answer with three simple words/letters... DIY ;-) Just kidding, Glenn. Again, I

Re: Solving FindBugs issues [was: Re: svn commit: r1071912 - in /xmlgraphics/fop/trunk: findbugs-exclude.xml src/java/org/apache/fop/render/pdf/PDFImageHandlerSVG.java]

2011-02-21 Thread Glenn Adams
Yes, there is are good reasons to continue using findbugs: (1) it does find bugs (2) they should not be added the exclude file without careful evaluation (3) when evaluating, real bugs should be fixed; however, there are some cases where findbugs reports a warning or error that is in fact not a

Re: Solving FindBugs issues [was: Re: svn commit: r1071912 - in /xmlgraphics/fop/trunk: findbugs-exclude.xml src/java/org/apache/fop/render/pdf/PDFImageHandlerSVG.java]

2011-02-21 Thread Glenn Adams
First, the point of the exclusion file is to bless warnings that, *by design*, do not correspond with findbugs set of default warnings. The presumption is that findbugs actually does identify real or potential bugs, and there should be no argument about whether this is true or not. What we are

Re: Solving FindBugs issues [was: Re: svn commit: r1071912 - in /xmlgraphics/fop/trunk: findbugs-exclude.xml src/java/org/apache/fop/render/pdf/PDFImageHandlerSVG.java]

2011-02-21 Thread Glenn Adams
The current trunk shows no warnings during ANT compile. Please make reference to the current trunk/HEAD as 1.0 is published and history at this time. It's a different matter with certain IDEs, e.g., Eclipse, which set their warning levels to a more sensitive level than the ANT build. Although it

Re: Solving FindBugs issue

2011-02-22 Thread Glenn Adams
clean findbugs' I get 0 errors and warnings. With eclipse clean and build project, I get 23 low priority warnings. Simon On Mon, Feb 21, 2011 at 12:58:06PM -0700, Glenn Adams wrote: The current trunk shows no warnings during ANT compile. Please make reference to the current trunk/HEAD as 1.0

Re: Assertions in junit tests [was: Re: Solving FindBugs issue]

2011-02-22 Thread Glenn Adams
I support enabling assertions by default on junit tests. More testing is a good thing. G. On Tue, Feb 22, 2011 at 3:40 PM, Andreas Delmelle andreas.delme...@telenet.be wrote: On 22 Feb 2011, at 19:25, Andreas Delmelle wrote: One way to enable assertions I found so far, and that seems to

Re: junit tests in nightly builds [was: Re: Solving FindBugs issue]

2011-02-23 Thread Glenn Adams
...@leverkruid.euwrote: On Tue, Feb 22, 2011 at 11:25:20AM -0700, Glenn Adams wrote: I notice also that the nightly build target does not run all the junit tests. It would be better if it run all of them plus checkstyle and findbugs. Many junit tests require a display. Nightly builds are run

Re: junit tests in nightly builds [was: Re: Solving FindBugs issue]

2011-02-23 Thread Glenn Adams
BTW, if someone would bother to nominate me as a committer, I would be happy to do this work directly. I don't like depending on the other committers to make progress in this area any more than you like having to address it. G. On Wed, Feb 23, 2011 at 1:15 AM, Glenn Adams gl...@skynav.com wrote

Re: junit tests in nightly builds

2011-02-23 Thread Glenn Adams
at 01:15:34AM -0700, Glenn Adams wrote: OK, understand on the junit headless issue. For checkstyle/findbugs it would be useful to fail the nightly build if they do not pass. I will investigate the necessary changes to enable this option, which I hope can be adopted. I would not agree

Re: junit tests in nightly builds

2011-02-23 Thread Glenn Adams
Right now the nightly build is our CI process. On Wednesday, February 23, 2011, Vincent Hennebert vhenneb...@gmail.com wrote: On 23/02/11 14:42, Glenn Adams wrote: I guess we disagree, since I believe application quality and code quality are related. And, further, I believe findbugs at least

Re: FindBugs exclusion policy proposal (was: Re: junit tests in nightly builds etc.)

2011-02-24 Thread Glenn Adams
I think the existing exclusions should be left in trunk, and that no new ones should be permitted in (or should be fixed immediately). If you do as you suggest below, then the list of findbugs errors will just continue to grow because nobody will pay attention to them. We are at a known, stable

Re: FindBugs exclusion policy proposal

2011-02-24 Thread Glenn Adams
, or code changes that I make. Note that the use of the findbugs code analysis tool is not a policy of the FOP project, and that consequently FOP committers are not bound to use findbugs and fix its errors or warnings. Simon On Thu, Feb 24, 2011 at 04:57:57PM -0800, Glenn Adams wrote: I

Re: FindBugs exclusion policy proposal

2011-02-25 Thread Glenn Adams
-maerki.chwrote: Possibly a vote to establish such a policy falling through. Just a hunch. On 25.02.2011 08:09:11 Glenn Adams wrote: Well then, let's make it a policy. What's preventing that? On Thu, Feb 24, 2011 at 11:07 PM, Simon Pepping spepp...@leverkruid.eu wrote: As before, I

Re: FindBugs exclusion policy proposal

2011-02-25 Thread Glenn Adams
, yet, but I expect one to happen if we were to install a new policy. I'm just predicting a possible outcome. ;-) On 25.02.2011 16:57:25 Glenn Adams wrote: Did I miss seeing such a vote? Could you give me an approximate date when it occurred so I can check the archives for background? Even

Re: FindBugs exclusion policy proposal

2011-02-26 Thread Glenn Adams
Glenn Adams wrote: ah, in that case, I wonder who would oppose a policy to use checkstyle and findbugs prior to commits in order to maintain a zero warnings state? and if opposed, then a rationale for that position? /g On Friday, February 25, 2011, Jeremias Maerki d...@jeremias

Re: FindBugs exclusion policy proposal

2011-02-26 Thread Glenn Adams
On Sat, Feb 26, 2011 at 2:14 PM, J.Pietschmann j3322...@yahoo.de wrote: On 26.02.2011 15:05, Glenn Adams wrote: Establishing a zero-FindBugs policy at build level: absolutely not. So you offer no rationale or reason for such an opinion? Or your only reason for this is that FindBugs

  1   2   3   4   5   6   7   8   9   >