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 Complex scripts. It is an urgent
requirement for us too.
If we don't discuss our concerns over the code now, then when do we
discuss it?
Vincent and Peter will be replying to this thread shortly and will
outline their primary concerns then.
Thanks,
Chris
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 in
LibreOffice Writer. I am sure that, if I would open it in *the* *Word*
processor, it would just work. When I process the file with FOP, it
does not work. With the complex scripts functionality, it works,
dependent on the use of supported or otherwise suitable fonts. (That
is true for all above applications, but apparently those come
configured with my system.)
So what does a person do who believes in the XML stack to maintain his
documentation, and wants to send his documents in Hindi to his
customers? See that XSL-FO with FOP is not a suitable solution for him
because Hindi uses a complex script?
FOP needs the complex scripts functionality to remain a player in the
global playing field.
This is for me the single overarching consideration to want this
functionality in FOP's trunk code, and in, say, half a year in a
release. All other considerations are minor, unless one wants to claim
that this code will block FOP's further development and maintenance in
the coming years.
Of course, not everybody needs this functionality, and there is a fear
of increased maintenance overhead. But the question is: For whom do we
develop FOP? Also for the large part of the world that uses complex
scripts?
With the development of the complex scripts functionality, Glenn Adams
and his sponsor Basis Technologies have created a new reality, which
is not going to go away. If this functionality does not end up in FOP,
it will probably live on elsewhere. If the FOP team is fine with that,
say no to the merge request, and feel comfortable with a trusted niche
application.
Simon Pepping
On Wed, Oct 19, 2011 at 09:50:24AM +0100, Chris Bowditch wrote:
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 time in
its development but is it truely production ready? I asked Vincent
to take a look at the branch earlier in the year as it's a feature
we also need, but he had several concerns that have not be
adequately answered. Take a look at comment #30;
https://issues.apache.org/bugzilla/show_bug.cgi?id=49687#c30
I'm not sure why Vincent describes it as a "brief look" because he
spent several days on it. I also asked Peter to take a look and he
had similar concerns. 2 or 3 letter variable names are a barrier for
any committer wanting to maintain this code and I don't think it is
a sufficient argument to say that a pre-requisite to maintaining
this code is to be a domain expert. I would hope that any
experienced committer with a debugger should be able to solve some
bugs. Obviously certain problems will require domain expertise, but
the variables names are a key barrier to being able to maintain this
code.
I realise my comments might be a little controversial and I don't
mean any disrespect to Glenn or his work (which is largely
excellent), but we should at least discuss these topics before the
merge is completed.
