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
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
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
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
/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
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
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
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
) 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
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
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
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
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
(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
.
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
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
, 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
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
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
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
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,
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
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
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
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
.
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
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
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
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
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
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
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
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;
-
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
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
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
@ 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:
--- 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
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
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
) {
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
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
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
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
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
, 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
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
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
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
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
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
://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
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
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
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
+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
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
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
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
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
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
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
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
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
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
,
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
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
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,
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
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
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
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
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
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
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
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
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:
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
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
, 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
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
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
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
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
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
...@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
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
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
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
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
, 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
-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
, 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
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
On Sun, Feb 27, 2011 at 4:18 PM, J.Pietschmann j3322...@yahoo.de wrote:
However, saying all of the above, the largest barrier I see to fixing bugs
in FOP and improving its quality is the reticence of the clique of FOP
committers to accept new committers.
Uh oh. As a PMC member I'm
My apologies for mixing the FB discussion and the commitership issue, which
are indeed separate.
Of course, I have never said FB is a magic wand, etc., and indeed no such
tool is. One makes use of these tools as helpers, and not as determiners. Is
the trouble of using FB regularly worth it? I
:
On 02/03/11 22:44, Glenn Adams wrote:
My apologies for mixing the FB discussion and the commitership issue,
which
are indeed separate.
snip/
Now, regarding commitership, I must say that if I were already a
committer,
I would probably have already fixed all the current FB exclusions
On Thu, Mar 3, 2011 at 5:58 AM, Chris Bowditch
bowditch_ch...@hotmail.comwrote:
Please send me a short bio and I will add you to the team page.
Chris, per your request, an abridged bio follows:
Dr. Glenn Adams is an independent consultant with 45+ years of professional
software design
Actually, many fonts from MSFT, Adobe, and others are starting to take
advantage of the OpenType GSUB/GPOS and related advanced typographic tables,
even for fonts used with Latin and other Western scripts. Since (generic)
support for these mechanisms has been added in the Temp_ComplexScripts
wrote:
Glenn Adams wrote:
Actually, many fonts from MSFT, Adobe, and others are starting to take
advantage of the OpenType GSUB/GPOS and related advanced typographic tables,
even for fonts used with Latin and other Western scripts. Since (generic)
support for these mechanisms has been added
1 - 100 of 868 matches
Mail list logo
