We -- at InterSystems -- deploy an application that runs in upwards of 40 countries, using many of the languages for which complex script support is required.
We definitely need complex script support. It is a requirement for us. Thanks, Jonathan Levinson Senior Software Developer Object 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 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.
