However, if someone actually renamed my variables after I have declared my
position, then I would interpret that as doing bad things to the code. In
fact, i would revert such a change.
If folks aren't willing to respect my style of coding along with my promise
to document short names,
Ninth, spending time changing variable names is a waste of time when I
could
be working on adding support for other scripts.
So someone else is going to have to waste all that time converting those
names into more readable ones. That’s a bit unfair, isn’t it?
I would advise
On Thu, Oct 27, 2011 at 3:41 PM, Simon Pepping spepp...@leverkruid.euwrote:
Ninth, spending time changing variable names is a waste of time when
I
could
be working on adding support for other scripts.
So someone else is going to have to waste all that time converting
those
as long as they're
fixing a bug or enhancing something where the name change makes sense to
go with the new logic.
From: Glenn Adams [mailto:gl...@skynav.com]
Sent: Thursday, October 27, 2011 3:56 AM
To: fop-dev@xmlgraphics.apache.org
Subject: Re: Merge Request
On 21/10/11 08:29, Glenn Adams wrote:
On Thu, Oct 20, 2011 at 10:31 PM, Peter Hancock
peter.hanc...@gmail.comwrote:
From the surface I would have been very much in favor of supporting a
merge in the near future, however I have had the chance to review some
areas of the complex script
On 24/10/11 14:05, Glenn Adams wrote:
On Mon, Oct 24, 2011 at 8:26 PM, Georg Datterl georg.datt...@geneon.dewrote:
Hello Glenn,
(2) there is no standard for symbol length documented in FOP practice
or enforced by checkstyle; I decline to exchange my choice of symbols
with longer symbols
inline
On Wed, Oct 26, 2011 at 6:49 PM, Vincent Hennebert vhenneb...@gmail.comwrote:
On 21/10/11 08:29, Glenn Adams wrote:
On Thu, Oct 20, 2011 at 10:31 PM, Peter Hancock peter.hanc...@gmail.com
wrote:
From the surface I would have been very much in favor of supporting a
merge in the
On Mon, Oct 24, 2011 at 09:05:34PM +0800, Glenn Adams wrote:
are you claiming my code is not maintainable by other developers? if so,
then please prove it objectively; otherwise, let's stop talking about this,
and move on with the merge vote
How would one go about proving objectively that code
On Wed, Oct 26, 2011 at 8:36 PM, Peter Hancock peter.hanc...@gmail.comwrote:
On Mon, Oct 24, 2011 at 09:05:34PM +0800, Glenn Adams wrote:
are you claiming my code is not maintainable by other developers? if so,
then please prove it objectively; otherwise, let's stop talking about
this,
BTW, sometimes I choose to use longer names for local variables: see my
reimplementation of number to string conversion in
o.a.f.util.NumberConverter, which is a new (and large) class I added in the
CS branch. I use a few short names here, but not as many as longer names. So
you can see that
While you are at it, Peter, you may also take note that I have made liberal
use of *assert* in the file I reference below (NumberConverter). If we are
going to improve not only understandability but also real quality, how about
a campaign to maximize use of assertions to document code assumptions?
I wonder what you think about the code in o.a.f.hyphenation.TernaryTree,
where the author apparently did not know Java, and introduces the libc
functions strcmp, strcpy, and strlen, and which uses the Java char type
(within the String type) for coding tree pointers!
My apprehension about
On Wed, Oct 26, 2011 at 2:13 PM, Glenn Adams gl...@skynav.com wrote:
Notice also the considerable use of nested classes (and interfaces), which
tends to make the file longer, but nevertheless encapsulates abstractions in
smaller units. True, this file could be sub-divided into smaller files,
On Wed, Oct 26, 2011 at 9:34 PM, Peter Hancock peter.hanc...@gmail.comwrote:
I wonder what you think about the code in o.a.f.hyphenation.TernaryTree,
where the author apparently did not know Java, and introduces the libc
functions strcmp, strcpy, and strlen, and which uses the Java char
can be
enforced by such as abstract methods and interfaces.
-Original Message-
From: Peter Hancock [mailto:peter.hanc...@gmail.com]
Sent: Wednesday, October 26, 2011 9:34 AM
To: fop-dev@xmlgraphics.apache.org
Subject: Re: Merge Request - Temp_ComplexScripts into Trunk
I wonder what you
On 22/10/11 01:22, Glenn Adams wrote:
inline
On Sat, Oct 22, 2011 at 12:04 AM, Chris Bowditch bowditch_ch...@hotmail.com
wrote:
Since Thunderhead also needs this feature we are willing to invest some
time into it too. Currently my team are telling me it would take 9 person
months to
Vincent,
We apparently disagree on whether coding should be based on ideology or on
practical results. You appear to favor the former, I favor the latter. I
think we will have to leave it at that. I'm not going to alter my
programming style in order to adhere to your notion of ideal programming
On Mon, Oct 24, 2011 at 8:26 PM, Georg Datterl georg.datt...@geneon.dewrote:
Hello Glenn,
(2) there is no standard for symbol length documented in FOP practice
or enforced by checkstyle; I decline to exchange my choice of symbols
with longer symbols simply because you prefer it that way;
.
From: Glenn Adams [mailto:gl...@skynav.com]
Sent: Monday, October 24, 2011 9:06 AM
To: fop-dev@xmlgraphics.apache.org
Subject: Re: Merge Request - Temp_ComplexScripts into Trunk
On Mon, Oct 24, 2011 at 8:26 PM, Georg Datterl georg.datt...@geneon.de
wrote:
Hello Glenn
:* Monday, October 24, 2011 9:06 AM
*To:* fop-dev@xmlgraphics.apache.org
*Subject:* Re: Merge Request - Temp_ComplexScripts into Trunk
On Mon, Oct 24, 2011 at 8:26 PM, Georg Datterl georg.datt...@geneon.de
mailto:georg.datt...@geneon.de wrote:
Hello Glenn,
(2
On Mon, Oct 24, 2011 at 09:05:34PM +0800, Glenn Adams wrote:
Sixth, I am going to be maintaining this code. If anyone has a problem with
specific code during a merge or regression, they merely need ask me.
That is a big no. There will always be a moment when someone else must
or wants to work
are you claiming my code is not maintainable by other developers? if so,
then please prove it objectively; otherwise, let's stop talking about this,
and move on with the merge vote
On Tue, Oct 25, 2011 at 1:21 AM, Simon Pepping spepp...@leverkruid.euwrote:
On Mon, Oct 24, 2011 at 09:05:34PM
On Thu, Oct 20, 2011 at 10:31 PM, Peter Hancock peter.hanc...@gmail.comwrote:
From the surface I would have been very much in favor of supporting a
merge in the near future, however I have had the chance to review some
areas of the complex script branch and I have some concerns.
The
On Thu, Oct 20, 2011 at 02:53:54PM +0100, Vincent Hennebert wrote:
Here are the sizes of some new files:
1075 src/java/org/apache/fop/fonts/GlyphSequence.java
1089 src/java/org/apache/fop/fonts/GlyphProcessingState.java
1269
I am pleased to learn that you are also in need of this new
functionality.
I share some of Vincent and Peter's concerns about technical points of
the code. On the other hand, this is the only implementation of
complex scripts we have, created by Glenn, in the style of Glenn. It
is an initial
On 21/10/2011 09:36, Simon Pepping wrote:
Hi Simon,
I am pleased to learn that you are also in need of this new
functionality.
I share some of Vincent and Peter's concerns about technical points of
the code. On the other hand, this is the only implementation of
complex scripts we have,
Chris,
I would really like to see an acknowledgement from Glenn that there are
some imperfections that need addressing.
I wasn't aware I had given anyone the impression of presenting a perfect
submission. In fact, one of my favorite quotes is Voltaire's *le mieux est
l'ennemi du bien* the
Quick question about this.
Please forgive my naïveté but, does this code affect processing
if you're not using ComplexScript support?
Thanks,
Clay
On 21/10/11 09:36, Simon Pepping wrote:
I am pleased to learn that you are also in need of this new
functionality.
I share some of Vincent and Peter's concerns about technical points of
the code. On the other hand, this is the only implementation of
complex scripts we have, created by
On 21/10/2011 15:13, Glenn Adams wrote:
Chris,
Hi Glenn,
I would really like to see an acknowledgement from Glenn that there
are some imperfections that need addressing.
I wasn't aware I had given anyone the impression of presenting a
perfect submission. In fact, one of my favorite
inline
On Sat, Oct 22, 2011 at 12:04 AM, Chris Bowditch bowditch_ch...@hotmail.com
wrote:
Since Thunderhead also needs this feature we are willing to invest some
time into it too. Currently my team are telling me it would take 9 person
months to port this code into our branch of FOP, partly
Jonathan,
Obviously, FOP's strongest supporters over the past years do not
require this new functionality. FOP needs the additional support of
new stakeholders of this new functionality. Could your teams test it
on their documents and report their findings to the fop-user email
list?
Simon
On 19/10/2011 19:32, Simon Pepping wrote:
Hi Simon,
I think you misunderstood my mail. I don't want to stop the merge. I
simply thought it was an appropriate time to discuss some concerns that
Vincent and Peter had identified. You are preaching to the converted
about the need for supporting
The Complex Scripts feature is obviously a great enhancement and we
would all love to have it implemented in FOP. However, that should not
come at the expense of maintainability and the implementation of other
new features.
When I look at the code in the Temp_ComplexScripts branch, I have
serious
This is a tough one.
The need for complex script support in FOP is likely high on the wish
list of any global supporter of FOP and it is certainly in the
interest of the project to support. The amount of work that Glenn has
done is considerable: the volume of code, the test coverage and the
-Original Message-
From: Simon Pepping [mailto:spepp...@leverkruid.eu]
Sent: Thursday, October 20, 2011 3:19 AM
To: fop-dev@xmlgraphics.apache.org
Subject: Re: Merge Request - Temp_ComplexScripts into Trunk
Jonathan,
Obviously, FOP's strongest supporters over the past years do
On 18/10/2011 19:55, Simon Pepping wrote:
I merged the ComplexScripts branch into trunk. Result:
Hi Simon,
As well of the question of how to do the merge there is also the
question should we do the merge? Of course this is a valuable feature to
the community, and Glenn has invested a lot of
I provided a detailed comment on Vincent's brief review at:
https://issues.apache.org/bugzilla/show_bug.cgi?id=49687#c31
With the exception of the the following comment, the remaining comments are
editorial in nature or have no actionable response.
How feasible is it to run the BIDI algorithm
HI,
IMHO, Production ready should only cited before a FOP release, not for
a merge of branch to trunk.
At this stage, the only questions are about regression tests (and code
readability, since open source).
Merging the branch now should encourage more users to test these new
features and give
Group
InterSystems
+1 617-621-0600
jonathan.levin...@intersystems.com
-Original Message-
From: Simon Pepping [mailto:spepp...@leverkruid.eu]
Sent: Wednesday, October 19, 2011 2:32 PM
To: fop-dev@xmlgraphics.apache.org
Subject: Re: Merge Request - Temp_ComplexScripts into Trunk
Over
I merged the ComplexScripts branch into trunk. Result:
--- Merging r981451 through r1185769 into '.':
Summary of conflicts:
Text conflicts: 58
Tree conflicts: 126
Most tree conflicts are probably an artifact of subversion. See
svn info lib/xmlgraphics-commons-1.5svn.jar|tail -n 4
Tree
41 matches
Mail list logo
