With this latest patch, I am satisfied that there is sufficient testing and
stability in the CS branch to support its merger into trunk. Therefore, I
request that such a merge be accomplished after applying patch 5 to the CS
branch as described below.
This newest patch primarily fills out the a th
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 confl
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 f
Over the past ten years computing has pervaded life in all its facets,
and spread over the world. As a consequence computing is now used in
all languages and all scripts.
When I open my devanagari test file in emacs, it just works. When I
open it in firefox, it just works. The same when I open it
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_ComplexScr
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 Peppin
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 C
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
obviou
-0600
jonathan.levin...@intersystems.com
> -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
>
> Jonat
On Thu, Oct 20, 2011 at 10:31 PM, Peter Hancock wrote:
>
> 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 treatment of Unicode Bidi s
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
> src/codegen/unicode/java/org/apache/fop/text/bidi/GenerateBidiT
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 imple
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, created
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 be
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 quot
inline
On Sat, Oct 22, 2011 at 12:04 AM, Chris Bowditch 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 because of some
> merge
On 22/10/11 01:22, Glenn Adams wrote:
> inline
>
> On Sat, Oct 22, 2011 at 12:04 AM, Chris Bowditch > 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 int
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
pr
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; I have
> offered to add comments to my uses, and that is the most I'm willing
>
On Mon, Oct 24, 2011 at 8:26 PM, Georg Datterl wrote:
> 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; I have
> > offer
t,
comment.
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
wrote:
Hello Glenn,
---
> *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 <mailto:g
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 wrote:
> On Mon, Oct 24, 2011 at 09:05:34PM +0800, Glenn Adams wrote:
On 21/10/11 08:29, Glenn Adams wrote:
> On Thu, Oct 20, 2011 at 10:31 PM, Peter Hancock
> wrote:
>
>>
>> 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
On 24/10/11 14:05, Glenn Adams wrote:
> On Mon, Oct 24, 2011 at 8:26 PM, Georg Datterl wrote:
>
>> 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 beca
inline
On Wed, Oct 26, 2011 at 6:49 PM, Vincent Hennebert wrote:
> On 21/10/11 08:29, Glenn Adams wrote:
> > On Thu, Oct 20, 2011 at 10:31 PM, Peter Hancock >wrote:
> >
> >>
> >> From the surface I would have been very much in favor of supporting a
> >> merge in the near future, however I have h
>> 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
On Wed, Oct 26, 2011 at 8:36 PM, Peter Hancock wrote:
> >> 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 wit
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 someti
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 c
On Wed, Oct 26, 2011 at 2:13 PM, Glenn Adams 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, and
> I may yet
On Wed, Oct 26, 2011 at 9:34 PM, Peter Hancock wrote:
> > 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
s if standard naming 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
> > > 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
On Thu, Oct 27, 2011 at 3:41 PM, Simon Pepping wrote:
> > > > 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
> > > na
raphics.apache.org
Subject: Re: Merge Request - Temp_ComplexScripts into Trunk
On Thu, Oct 27, 2011 at 3:41 PM, Simon Pepping
wrote:
> > > Ninth, spending time changing variable names is a waste of
time when I
> > could
> > > be working on addi
> 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 na
44 matches
Mail list logo
