You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Simon Pepping <sp...@leverkruid.eu> on 2011/10/25 10:31:43 UTC
[VOTE] Merge branch Temp_ComplexScripts into trunk
With his latest patch, Glenn Adams wrote:
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.
... snip ...
Note that there remains work to be done on CS support, including adding
support for:
- additional scripts
- additional output formats
At present, support is provided for:
- Arabic, Hebrew, and Devanagari Scripts
- PDF output format
I expect that additional support for other scripts and formats will be added
over time, either by myself, or other members of the community. However, the
absence of support for all complex scripts and all output formats should not
be a deterrent to active use of the support already present. It is now a
good time to broaden the user community of the CS features, and the best way
to do that is to bring it into the trunk at this time.
End of quote
Following this request, I herewith propose to merge the branch
Temp_ComplexScripts into trunk, and launch a formal vote.
I vote positive: +1
For the rules of voting about code commits, see the project charter,
article 11, http://wiki.apache.org/xmlgraphics/ProjectCharter.
Simon Pepping
Re: [VOTE] Merge branch Temp_ComplexScripts into trunk
Posted by Clay Leeds <th...@gmail.com>.
Thanks Pascal! And thank you Glenn! Great work!
+1 from me!
"My religion is simple. My religion is kindness."
- HH The Dalai Lama of Tibet
On Oct 25, 2011, at 6:29 AM, Pascal Sancho <pa...@takoma.fr> wrote:
> Hi,
>
> There was a discussion about enabling it by default, with some
> performances tests.
>
> see http://marc.info/?l=fop-dev&m=131108266423848&w=2
>
> Le 25/10/2011 14:54, The Web Maestro a écrit :
>>> Following this request, I herewith propose to merge the branch
>>> Temp_ComplexScripts into trunk, and launch a formal vote.
>>>
>>> I vote positive: +1
>>>
>>> For the rules of voting about code commits, see the project charter,
>>> article 11, http://wiki.apache.org/xmlgraphics/ProjectCharter.
>>>
>>> Simon Pepping
>>
>> This sounds good to me, but I want to ask:
>>
>> Does this new feature have any impact on people not using Complex
>> Scripts in their FOP process?
>>
>> Regards,
>>
>> The Web Maestro
>> --
>> <th...@gmail.com> - <http://ourlil.com/>
>> My religion is simple. My religion is kindness.
>> - HH The 14th Dalai Lama of Tibet
>>
>
> --
> Pascal
Re: [VOTE] Merge branch Temp_ComplexScripts into trunk
Posted by Pascal Sancho <pa...@takoma.fr>.
Hi,
There was a discussion about enabling it by default, with some
performances tests.
see http://marc.info/?l=fop-dev&m=131108266423848&w=2
Le 25/10/2011 14:54, The Web Maestro a écrit :
>> Following this request, I herewith propose to merge the branch
>> Temp_ComplexScripts into trunk, and launch a formal vote.
>>
>> I vote positive: +1
>>
>> For the rules of voting about code commits, see the project charter,
>> article 11, http://wiki.apache.org/xmlgraphics/ProjectCharter.
>>
>> Simon Pepping
>
> This sounds good to me, but I want to ask:
>
> Does this new feature have any impact on people not using Complex
> Scripts in their FOP process?
>
> Regards,
>
> The Web Maestro
> --
> <th...@gmail.com> - <http://ourlil.com/>
> My religion is simple. My religion is kindness.
> - HH The 14th Dalai Lama of Tibet
>
--
Pascal
Re: Ligatures
Posted by Glenn Adams <gl...@skynav.com>.
Thanks Tony! I'll look into that. And nice to hear from you after many
years.
Best,
Glenn
On Wed, Oct 26, 2011 at 10:46 PM, Tony Graham <tg...@mentea.net> wrote:
> On Tue, October 25, 2011 11:29 pm, Glenn Adams wrote:
> > They (latin ligatures) are already enabled, so no extra work is needed.
> > Though this could benefit by adding support for some of the more recent
> > CSS3
> > font properties related to the use of AATs, e.g., see [1] for:
> >
> > font-variant-alternates
> > font-variant-ligatures
> > font-feature-settings
> >
> > [1] http://www.w3.org/TR/css3-fonts/
>
> FWIW, the XSL 2.0 Requirements includes several requirements for better
> font support [1], including font choice based on script or language and
> font-specific features (i.e., OpenType features).
>
> The work to date on improved font support hasn't made it into the current
> Working Draft [3][4], but I, personally, don't see anything wrong with
> anyone who can articulate specific needs for improved font support in
> XSL-FO 2.0 submitting a pre-emptive comment about it on the W3C Bugzilla
> [2].
>
> Regards,
>
>
> Tony Graham tgraham@mentea.net
> Consultant http://www.mentea.net
> Mentea 13 Kelly's Bay Beach, Skerries, Co. Dublin, Ireland
> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> XML, XSL-FO and XSLT consulting, training and programming
>
> [1] http://www.w3.org/TR/xslfo20-req/#N66770
> [2] http://www.w3.org/XML/2008/01/xsl-fo-bugzilla.html
> [3] http://www.w3.org/TR/2011/WD-xslfo20-20110927/
> [4] http://www.w3.org/TR/xslfo20/
>
Re: Ligatures
Posted by Tony Graham <tg...@mentea.net>.
On Tue, October 25, 2011 11:29 pm, Glenn Adams wrote:
> They (latin ligatures) are already enabled, so no extra work is needed.
> Though this could benefit by adding support for some of the more recent
> CSS3
> font properties related to the use of AATs, e.g., see [1] for:
>
> font-variant-alternates
> font-variant-ligatures
> font-feature-settings
>
> [1] http://www.w3.org/TR/css3-fonts/
FWIW, the XSL 2.0 Requirements includes several requirements for better
font support [1], including font choice based on script or language and
font-specific features (i.e., OpenType features).
The work to date on improved font support hasn't made it into the current
Working Draft [3][4], but I, personally, don't see anything wrong with
anyone who can articulate specific needs for improved font support in
XSL-FO 2.0 submitting a pre-emptive comment about it on the W3C Bugzilla
[2].
Regards,
Tony Graham tgraham@mentea.net
Consultant http://www.mentea.net
Mentea 13 Kelly's Bay Beach, Skerries, Co. Dublin, Ireland
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
XML, XSL-FO and XSLT consulting, training and programming
[1] http://www.w3.org/TR/xslfo20-req/#N66770
[2] http://www.w3.org/XML/2008/01/xsl-fo-bugzilla.html
[3] http://www.w3.org/TR/2011/WD-xslfo20-20110927/
[4] http://www.w3.org/TR/xslfo20/
Re: Ligatures (was: [VOTE] Merge branch Temp_ComplexScripts into trunk)
Posted by Glenn Adams <gl...@skynav.com>.
They (latin ligatures) are already enabled, so no extra work is needed.
Though this could benefit by adding support for some of the more recent CSS3
font properties related to the use of AATs, e.g., see [1] for:
font-variant-alternates
font-variant-ligatures
font-feature-settings
[1] http://www.w3.org/TR/css3-fonts/
On Wed, Oct 26, 2011 at 2:40 AM, Christopher R. Maden <cr...@maden.org>wrote:
> On 10/25/2011 10:16 AM, Glenn Adams wrote:
> > Keep in mind that Latin (Roman), Cyrillic, and Greek scripts also
> > benefit from support when complex scripts are enabled, since in these
> > cases the advanced typographic tables (ATT) present in OpenType fonts
> > used with these scripts are enabled. For example, such tables enable
> > the correct placement of combining marks (e.g., diacritics and
> > accents) with base characters.
>
> Ooh, I hadn’t really thought of this before... how much work would it
> take to use this code to enable Latin ligatures (fi, fl, etc.) when the
> typeface supports them? I currently handle this in XSLT and it’s a
> PITA, and also lacks information about actual typeface support for
> advanced ligatures (ffi, ct, etc.).
>
> ~Chris
> --
> Chris Maden, text nerd <URL: http://crism.maden.org/ >
> “Be wary of great leaders. Hope that there are many, many small
> leaders.” — Pete Seeger
>
Ligatures (was: [VOTE] Merge branch Temp_ComplexScripts into trunk)
Posted by "Christopher R. Maden" <cr...@maden.org>.
On 10/25/2011 10:16 AM, Glenn Adams wrote:
> Keep in mind that Latin (Roman), Cyrillic, and Greek scripts also
> benefit from support when complex scripts are enabled, since in these
> cases the advanced typographic tables (ATT) present in OpenType fonts
> used with these scripts are enabled. For example, such tables enable
> the correct placement of combining marks (e.g., diacritics and
> accents) with base characters.
Ooh, I hadn’t really thought of this before... how much work would it
take to use this code to enable Latin ligatures (fi, fl, etc.) when the
typeface supports them? I currently handle this in XSLT and it’s a
PITA, and also lacks information about actual typeface support for
advanced ligatures (ffi, ct, etc.).
~Chris
--
Chris Maden, text nerd <URL: http://crism.maden.org/ >
“Be wary of great leaders. Hope that there are many, many small
leaders.” — Pete Seeger
Re: [VOTE] Merge branch Temp_ComplexScripts into trunk
Posted by Glenn Adams <gl...@skynav.com>.
The short answer is that if you do not wish to be affected by complex script
support, you can use the new "-nocs" command line option or you can specify
<complex-scripts disabled='true'/> in your FOP configuration file.
Keep in mind that Latin (Roman), Cyrillic, and Greek scripts also benefit
from support when complex scripts are enabled, since in these cases the
advanced typographic tables (ATT) present in OpenType fonts used with these
scripts are enabled. For example, such tables enable the correct placement
of combining marks (e.g., diacritics and accents) with base characters.
G.
On Tue, Oct 25, 2011 at 8:54 PM, The Web Maestro
<th...@gmail.com>wrote:
> > Following this request, I herewith propose to merge the branch
> > Temp_ComplexScripts into trunk, and launch a formal vote.
> >
> > I vote positive: +1
> >
> > For the rules of voting about code commits, see the project charter,
> > article 11, http://wiki.apache.org/xmlgraphics/ProjectCharter.
> >
> > Simon Pepping
>
> This sounds good to me, but I want to ask:
>
> Does this new feature have any impact on people not using Complex
> Scripts in their FOP process?
>
> Regards,
>
> The Web Maestro
> --
> <th...@gmail.com> - <http://ourlil.com/>
> My religion is simple. My religion is kindness.
> - HH The 14th Dalai Lama of Tibet
>
Re: [VOTE] Merge branch Temp_ComplexScripts into trunk
Posted by The Web Maestro <th...@gmail.com>.
> Following this request, I herewith propose to merge the branch
> Temp_ComplexScripts into trunk, and launch a formal vote.
>
> I vote positive: +1
>
> For the rules of voting about code commits, see the project charter,
> article 11, http://wiki.apache.org/xmlgraphics/ProjectCharter.
>
> Simon Pepping
This sounds good to me, but I want to ask:
Does this new feature have any impact on people not using Complex
Scripts in their FOP process?
Regards,
The Web Maestro
--
<th...@gmail.com> - <http://ourlil.com/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet
Re: [VOTE] Merge branch Temp_ComplexScripts into trunk
Posted by Peter Hancock <pe...@gmail.com>.
I will vote -0 with reasons I have already expressed in the 'Merge
Request - Temp_ComplexScripts into Trunk' thread.
I hope we can go forward refining this work, along with the rest FOP,
through constructive collaboration, respecting the varied degrees of
experiences, expertises and passion that we can all bring to the
project.
Peter
[1] http://markmail.org/message/ti5233ftlxacau4a
On Fri, Oct 28, 2011 at 3:40 PM, Vincent Hennebert <vh...@gmail.com> wrote:
> This vote was launched while discussion was still going on on the
> mailing list. It would have been good to wait that a consensus is
> reached, which I don’t think has happened yet. What was the urgency to
> launch the vote now?
>
> I haven’t received any answer to my concerns about the following
> metrics:
> • 74 files in the o.a.f.fonts package
> In o.a.f.fonts.truetype.TTFFile:
> • 5502 lines
> • 150+ method declarations
> In the test o.a.f.complexscripts.util.TTXFile:
> • 3449 lines
> • 50+ field declarations
> • 1800 lines in the Handler.startElement method
>
> As it currently is, I believe that the font package will cause serious
> issues when merging other branches, fixing bugs or implementing other
> features.
>
> I don’t see what advantage does merging the Complex Scripts branch to
> trunk bring. Users who are skilled enough to check out a copy of the
> trunk, build it and test it can equally do it on a branch. For the rest
> of them, I don’t think that downloading a nightly build of trunk or
> a build of the branch would make any difference.
>
> ATM Simon is regularly uploading a build of the branch on his personal
> space at people.apache.org. I believe that this is exactly what non
> power users need, and I would be happy to take over this task if he is
> no longer willing to do it.
>
> If trunk is regularly merged to the branch (which I would also happily
> do), then it makes virtually no difference whether one is working on the
> trunk or on the branch.
>
> The new code deliberately ignores established code conventions by
> disabling Checkstyle rules. This makes it inconsistent with the rest of
> the code base and will unnecessarily distract people who try to
> understand it.
>
> I saw some slightly encouraging notes from Glenn that he is prepared to
> do some refactoring work on his code. I urge him to break down the fonts
> package and classes into smaller, more manageable components, and to do
> it as soon as possible.
>
> ATM I don’t believe that this code is maintainable by anyone else but
> Glenn. Therefore I think that merging it to Trunk is a bad idea. I’m not
> willing to provide any support for it at the moment, and the tone of his
> latest messages does certainly not encourage me to get involved in it in
> the future.
>
> Therefore, I’m voting -0.9.
>
> Vincent
>
>
> On 25/10/11 09:31, Simon Pepping wrote:
>> With his latest patch, Glenn Adams wrote:
>>
>> 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.
>>
>> ... snip ...
>>
>> Note that there remains work to be done on CS support, including adding
>> support for:
>>
>> - additional scripts
>> - additional output formats
>>
>> At present, support is provided for:
>>
>> - Arabic, Hebrew, and Devanagari Scripts
>> - PDF output format
>>
>> I expect that additional support for other scripts and formats will be added
>> over time, either by myself, or other members of the community. However, the
>> absence of support for all complex scripts and all output formats should not
>> be a deterrent to active use of the support already present. It is now a
>> good time to broaden the user community of the CS features, and the best way
>> to do that is to bring it into the trunk at this time.
>>
>> End of quote
>>
>> Following this request, I herewith propose to merge the branch
>> Temp_ComplexScripts into trunk, and launch a formal vote.
>>
>> I vote positive: +1
>>
>> For the rules of voting about code commits, see the project charter,
>> article 11, http://wiki.apache.org/xmlgraphics/ProjectCharter.
>>
>> Simon Pepping
>
Re: [VOTE] Merge branch Temp_ComplexScripts into trunk
Posted by Vincent Hennebert <vh...@gmail.com>.
This vote was launched while discussion was still going on on the
mailing list. It would have been good to wait that a consensus is
reached, which I don’t think has happened yet. What was the urgency to
launch the vote now?
I haven’t received any answer to my concerns about the following
metrics:
• 74 files in the o.a.f.fonts package
In o.a.f.fonts.truetype.TTFFile:
• 5502 lines
• 150+ method declarations
In the test o.a.f.complexscripts.util.TTXFile:
• 3449 lines
• 50+ field declarations
• 1800 lines in the Handler.startElement method
As it currently is, I believe that the font package will cause serious
issues when merging other branches, fixing bugs or implementing other
features.
I don’t see what advantage does merging the Complex Scripts branch to
trunk bring. Users who are skilled enough to check out a copy of the
trunk, build it and test it can equally do it on a branch. For the rest
of them, I don’t think that downloading a nightly build of trunk or
a build of the branch would make any difference.
ATM Simon is regularly uploading a build of the branch on his personal
space at people.apache.org. I believe that this is exactly what non
power users need, and I would be happy to take over this task if he is
no longer willing to do it.
If trunk is regularly merged to the branch (which I would also happily
do), then it makes virtually no difference whether one is working on the
trunk or on the branch.
The new code deliberately ignores established code conventions by
disabling Checkstyle rules. This makes it inconsistent with the rest of
the code base and will unnecessarily distract people who try to
understand it.
I saw some slightly encouraging notes from Glenn that he is prepared to
do some refactoring work on his code. I urge him to break down the fonts
package and classes into smaller, more manageable components, and to do
it as soon as possible.
ATM I don’t believe that this code is maintainable by anyone else but
Glenn. Therefore I think that merging it to Trunk is a bad idea. I’m not
willing to provide any support for it at the moment, and the tone of his
latest messages does certainly not encourage me to get involved in it in
the future.
Therefore, I’m voting -0.9.
Vincent
On 25/10/11 09:31, Simon Pepping wrote:
> With his latest patch, Glenn Adams wrote:
>
> 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.
>
> ... snip ...
>
> Note that there remains work to be done on CS support, including adding
> support for:
>
> - additional scripts
> - additional output formats
>
> At present, support is provided for:
>
> - Arabic, Hebrew, and Devanagari Scripts
> - PDF output format
>
> I expect that additional support for other scripts and formats will be added
> over time, either by myself, or other members of the community. However, the
> absence of support for all complex scripts and all output formats should not
> be a deterrent to active use of the support already present. It is now a
> good time to broaden the user community of the CS features, and the best way
> to do that is to bring it into the trunk at this time.
>
> End of quote
>
> Following this request, I herewith propose to merge the branch
> Temp_ComplexScripts into trunk, and launch a formal vote.
>
> I vote positive: +1
>
> For the rules of voting about code commits, see the project charter,
> article 11, http://wiki.apache.org/xmlgraphics/ProjectCharter.
>
> Simon Pepping
Re: Merge branch Temp_ComplexScripts into trunk
Posted by Glenn Adams <gl...@skynav.com>.
Simon,
Thanks for your response. I appreciate your prior assistance on this work.
I will continue to maintain and develop support for internationalization
features in FOP in my public repository [1].
[1] http://github.com/skynavga/fop
See also [2] for up to date documentation on these features as well as
bug/issue tracking.
[2] http://skynav.trac.cvsdude.com/fop
Regards,
Glenn
On Wed, Nov 9, 2011 at 11:33 AM, Simon Pepping <sp...@leverkruid.eu>wrote:
> I will not apply this patch. I will no longer be available to shepherd
> this project in FOP. Somebody else must take over this role.
>
> Simon
>
> On Sun, Nov 06, 2011 at 09:14:20PM -0700, Glenn Adams wrote:
> > Simon,
> >
> > I have created a patch [1] that, if applied to trunk as described in [2],
> > effectively merges the Temp_ComplexScript branch (updated with changes
> from
> > recent trunk commits) plus one bug fix for bidi content inside
> > fo:static-content.
> >
> > [1] http://issues.apache.org/bugzilla/attachment.cgi?id=27906
> > [2] http://issues.apache.org/bugzilla/show_bug.cgi?id=49687#c46
> >
> > Attached to this message is the captured session of the steps I took in
> > creating this patch.
> >
> > I've verified that all junits pass, and no new checkstyle warnings are
> > introduced. There remain two new findbug warnings, however, introduced in
> > recent changes to the trunk, which I did not attempt to fix. Otherwise, a
> > build and test run are clean.
>
Re: Merge branch Temp_ComplexScripts into trunk
Posted by Glenn Adams <gl...@skynav.com>.
Simon,
Thanks for your response. I appreciate your prior assistance on this work.
I will continue to maintain and develop support for internationalization
features in FOP in my public repository [1].
[1] http://github.com/skynavga/fop
See also [2] for up to date documentation on these features as well as
bug/issue tracking.
[2] http://skynav.trac.cvsdude.com/fop
Regards,
Glenn
On Wed, Nov 9, 2011 at 11:33 AM, Simon Pepping <sp...@leverkruid.eu>wrote:
> I will not apply this patch. I will no longer be available to shepherd
> this project in FOP. Somebody else must take over this role.
>
> Simon
>
> On Sun, Nov 06, 2011 at 09:14:20PM -0700, Glenn Adams wrote:
> > Simon,
> >
> > I have created a patch [1] that, if applied to trunk as described in [2],
> > effectively merges the Temp_ComplexScript branch (updated with changes
> from
> > recent trunk commits) plus one bug fix for bidi content inside
> > fo:static-content.
> >
> > [1] http://issues.apache.org/bugzilla/attachment.cgi?id=27906
> > [2] http://issues.apache.org/bugzilla/show_bug.cgi?id=49687#c46
> >
> > Attached to this message is the captured session of the steps I took in
> > creating this patch.
> >
> > I've verified that all junits pass, and no new checkstyle warnings are
> > introduced. There remain two new findbug warnings, however, introduced in
> > recent changes to the trunk, which I did not attempt to fix. Otherwise, a
> > build and test run are clean.
>
Re: Merge branch Temp_ComplexScripts into trunk
Posted by Simon Pepping <sp...@leverkruid.eu>.
I will not apply this patch. I will no longer be available to shepherd
this project in FOP. Somebody else must take over this role.
Simon
On Sun, Nov 06, 2011 at 09:14:20PM -0700, Glenn Adams wrote:
> Simon,
>
> I have created a patch [1] that, if applied to trunk as described in [2],
> effectively merges the Temp_ComplexScript branch (updated with changes from
> recent trunk commits) plus one bug fix for bidi content inside
> fo:static-content.
>
> [1] http://issues.apache.org/bugzilla/attachment.cgi?id=27906
> [2] http://issues.apache.org/bugzilla/show_bug.cgi?id=49687#c46
>
> Attached to this message is the captured session of the steps I took in
> creating this patch.
>
> I've verified that all junits pass, and no new checkstyle warnings are
> introduced. There remain two new findbug warnings, however, introduced in
> recent changes to the trunk, which I did not attempt to fix. Otherwise, a
> build and test run are clean.
Re: Merge branch Temp_ComplexScripts into trunk
Posted by Glenn Adams <gl...@skynav.com>.
Simon,
I have created a patch [1] that, if applied to trunk as described in [2],
effectively merges the Temp_ComplexScript branch (updated with changes from
recent trunk commits) plus one bug fix for bidi content inside
fo:static-content.
[1] http://issues.apache.org/bugzilla/attachment.cgi?id=27906
[2] http://issues.apache.org/bugzilla/show_bug.cgi?id=49687#c46
Attached to this message is the captured session of the steps I took in
creating this patch.
I've verified that all junits pass, and no new checkstyle warnings are
introduced. There remain two new findbug warnings, however, introduced in
recent changes to the trunk, which I did not attempt to fix. Otherwise, a
build and test run are clean.
Regards,
Glenn
On Sat, Oct 29, 2011 at 4:56 AM, Simon Pepping <sp...@leverkruid.eu>wrote:
> Ideally, the merge is performed in subversion. Earlier I noted that
> that gives a large number of document and tree conflicts. I do not
> have time to resolve them.
>
> If no team member picks this task up, a patch from Glenn is a good
> alternative solution. Glenn, can you attach it to the Bugzilla report?
> Can you indicate how you proceeded, and how you guarantee that the
> patch has the same result as a merge in Subversion?
>
> Simon Pepping
>
> On Sat, Oct 29, 2011 at 09:02:42AM +0800, Glenn Adams wrote:
> > Let me know how I may most expeditiously accomplish this work. In the
> mean
> > time, I will prepare a patch against trunk from the Temp_CS branch,
> which I
> > imagine Simon will be the one to apply.
> >
> > G.
> >
>
Re: Merge branch Temp_ComplexScripts into trunk
Posted by Simon Pepping <sp...@leverkruid.eu>.
Ideally, the merge is performed in subversion. Earlier I noted that
that gives a large number of document and tree conflicts. I do not
have time to resolve them.
If no team member picks this task up, a patch from Glenn is a good
alternative solution. Glenn, can you attach it to the Bugzilla report?
Can you indicate how you proceeded, and how you guarantee that the
patch has the same result as a merge in Subversion?
Simon Pepping
On Sat, Oct 29, 2011 at 09:02:42AM +0800, Glenn Adams wrote:
> Let me know how I may most expeditiously accomplish this work. In the mean
> time, I will prepare a patch against trunk from the Temp_CS branch, which I
> imagine Simon will be the one to apply.
>
> G.
>
Re: [VOTE] Merge branch Temp_ComplexScripts into trunk
Posted by Glenn Adams <gl...@skynav.com>.
Thank you FOP team. As I have stated previously, I am prepared to improve
and maintain this code moving forward, including adding comments for local
variables not already described, and refactoring certain classes to reduce
class size.
I've also given some thought to moving the new CS classes in o.a.f.fonts
into a new subpackage:
org.apache.fop.fonts.complexscripts
It may also be possible to refactor the new ATT parsing support I added to
o.a.f.fonts.truetype.TTFFile into separate files as well. Frankly, though, I
wonder if the entire font subsystem isn't in need of a redesign. It seems to
be overly complex and unwieldy even without the new CS features.
I may also refactor BidiUtil and move into a new subpackage:
org.apache.fop.layoutengine.bidi
Regarding o.a.f.complexscripts.util.TTXFile, this is a utility class used
only with certain junit related test files. At present, checkstyle is not
even run on *any* of the junit related java source files. Length of this
file or its methods or number of field declarations should not an issue. If
someone wants to refactor that file as an exercise for the reader, I have no
objection.
Let me know how I may most expeditiously accomplish this work. In the mean
time, I will prepare a patch against trunk from the Temp_CS branch, which I
imagine Simon will be the one to apply.
G.
On Sat, Oct 29, 2011 at 2:05 AM, Simon Pepping <sp...@leverkruid.eu>wrote:
> Seven committers voted. There were five +1 votes and no -1 votes. There
> was one -0.9 vote and one -0 vote.
>
> According to the Project Charter three +1 ('yes' votes) with no -1
> ('no' votes or vetoes) are needed to approve a significant code
> change. Therefore the proposal to merge the Temp_ComplexScripts branch
> into trunk has been accepted.
>
> Thank you for voting. I acknowledge that Vincent and Peter are not
> convinced of the wisdom of this decision. I hope we can all move
> forward with this new situation.
>
> Simon
>
> On Tue, Oct 25, 2011 at 10:31:43AM +0200, Simon Pepping wrote:
> > With his latest patch, Glenn Adams wrote:
> >
> > 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.
> >
> > ... snip ...
> >
> > Note that there remains work to be done on CS support, including adding
> > support for:
> >
> > - additional scripts
> > - additional output formats
> >
> > At present, support is provided for:
> >
> > - Arabic, Hebrew, and Devanagari Scripts
> > - PDF output format
> >
> > I expect that additional support for other scripts and formats will be
> added
> > over time, either by myself, or other members of the community. However,
> the
> > absence of support for all complex scripts and all output formats should
> not
> > be a deterrent to active use of the support already present. It is now a
> > good time to broaden the user community of the CS features, and the best
> way
> > to do that is to bring it into the trunk at this time.
> >
> > End of quote
> >
> > Following this request, I herewith propose to merge the branch
> > Temp_ComplexScripts into trunk, and launch a formal vote.
> >
> > I vote positive: +1
> >
> > For the rules of voting about code commits, see the project charter,
> > article 11, http://wiki.apache.org/xmlgraphics/ProjectCharter.
> >
> > Simon Pepping
>
Re: [VOTE] Merge branch Temp_ComplexScripts into trunk
Posted by Simon Pepping <sp...@leverkruid.eu>.
Seven committers voted. There were five +1 votes and no -1 votes. There
was one -0.9 vote and one -0 vote.
According to the Project Charter three +1 ('yes' votes) with no -1
('no' votes or vetoes) are needed to approve a significant code
change. Therefore the proposal to merge the Temp_ComplexScripts branch
into trunk has been accepted.
Thank you for voting. I acknowledge that Vincent and Peter are not
convinced of the wisdom of this decision. I hope we can all move
forward with this new situation.
Simon
On Tue, Oct 25, 2011 at 10:31:43AM +0200, Simon Pepping wrote:
> With his latest patch, Glenn Adams wrote:
>
> 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.
>
> ... snip ...
>
> Note that there remains work to be done on CS support, including adding
> support for:
>
> - additional scripts
> - additional output formats
>
> At present, support is provided for:
>
> - Arabic, Hebrew, and Devanagari Scripts
> - PDF output format
>
> I expect that additional support for other scripts and formats will be added
> over time, either by myself, or other members of the community. However, the
> absence of support for all complex scripts and all output formats should not
> be a deterrent to active use of the support already present. It is now a
> good time to broaden the user community of the CS features, and the best way
> to do that is to bring it into the trunk at this time.
>
> End of quote
>
> Following this request, I herewith propose to merge the branch
> Temp_ComplexScripts into trunk, and launch a formal vote.
>
> I vote positive: +1
>
> For the rules of voting about code commits, see the project charter,
> article 11, http://wiki.apache.org/xmlgraphics/ProjectCharter.
>
> Simon Pepping
Re: [VOTE] Merge branch Temp_ComplexScripts into trunk
Posted by Adrian Cumiskey <ad...@gmail.com>.
+1 from me. A lot of work, a great achievement.
On 25 October 2011 12:10, Simon Pepping <sp...@leverkruid.eu> wrote:
> The vote runs for three days, and will end on Friday 28 October 2011
> at 18:00h UTC.
>
> Simon Pepping
>
> On Tue, Oct 25, 2011 at 10:31:43AM +0200, Simon Pepping wrote:
> >
> > Following this request, I herewith propose to merge the branch
> > Temp_ComplexScripts into trunk, and launch a formal vote.
> >
> > For the rules of voting about code commits, see the project charter,
> > article 11, http://wiki.apache.org/xmlgraphics/ProjectCharter.
>
Re: [VOTE] Merge branch Temp_ComplexScripts into trunk
Posted by Simon Pepping <sp...@leverkruid.eu>.
The vote runs for three days, and will end on Friday 28 October 2011
at 18:00h UTC.
Simon Pepping
On Tue, Oct 25, 2011 at 10:31:43AM +0200, Simon Pepping wrote:
>
> Following this request, I herewith propose to merge the branch
> Temp_ComplexScripts into trunk, and launch a formal vote.
>
> For the rules of voting about code commits, see the project charter,
> article 11, http://wiki.apache.org/xmlgraphics/ProjectCharter.
Re: [VOTE] Merge branch Temp_ComplexScripts into trunk
Posted by Chris Bowditch <bo...@hotmail.com>.
On 25/10/2011 09:31, Simon Pepping wrote:
> With his latest patch, Glenn Adams wrote:
Hi All,
>
> 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.
Although there are some concerns over certain technical aspects in the Complex Scripts branch Glenn has spent some time answering our concerns and has made some steps towards a compromise. Given the need for this feature in the community and the level of testing Glenn has conducted I am happy for the merge to proceed. Thanks for your hard work Glenn!
<snip/>
> Following this request, I herewith propose to merge the branch
> Temp_ComplexScripts into trunk, and launch a formal vote.
>
> I vote positive: +1
+1
>
> For the rules of voting about code commits, see the project charter,
> article 11, http://wiki.apache.org/xmlgraphics/ProjectCharter.
>
> Simon Pepping
>
>
Chris
Re: [VOTE] Merge branch Temp_ComplexScripts into trunk
Posted by Pascal Sancho <pa...@takoma.fr>.
I vote positive too: +1
Le 25/10/2011 10:31, Simon Pepping a écrit :
> With his latest patch, Glenn Adams wrote:
>
> 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.
>
> ... snip ...
>
> Note that there remains work to be done on CS support, including adding
> support for:
>
> - additional scripts
> - additional output formats
>
> At present, support is provided for:
>
> - Arabic, Hebrew, and Devanagari Scripts
> - PDF output format
>
> I expect that additional support for other scripts and formats will be added
> over time, either by myself, or other members of the community. However, the
> absence of support for all complex scripts and all output formats should not
> be a deterrent to active use of the support already present. It is now a
> good time to broaden the user community of the CS features, and the best way
> to do that is to bring it into the trunk at this time.
>
> End of quote
>
> Following this request, I herewith propose to merge the branch
> Temp_ComplexScripts into trunk, and launch a formal vote.
>
> I vote positive: +1
>
> For the rules of voting about code commits, see the project charter,
> article 11, http://wiki.apache.org/xmlgraphics/ProjectCharter.
>
> Simon Pepping
>
--
Pascal