I have created a new branch Temp_CFF [1], in order to add support for Adobe
CFF (Compact Font Format) encoded OpenType/TrueType fonts. CFF encoded
fonts use a different format, more compact representation for glyph outline
data [2][3]; specifically, they use Adobe Type 2 charstring format [4].
[1]
I support committing this patch, however I don't see an ICLA listed at [1]
for Alexios. Alexios, if you have not submitted an ICLA [2], please do so.
I would be happy to apply the patch (if Mehdi doesn't have the time).
[1] http://people.apache.org/committer-index.html#unlistedclas
[2] http://www
mitter.
>
>
> On Feb 28, 2012, at 11:53 AM, Glenn Adams wrote:
>
> I support committing this patch, however I don't see an ICLA listed at [1]
> for Alexios. Alexios, if you have not submitted an ICLA [2], please do so.
>
> I would be happy to apply the patch (if Mehdi d
On Wed, Feb 29, 2012 at 2:34 PM, Glenn Adams wrote:
>
>
> On Wed, Feb 29, 2012 at 2:18 PM, Vincent Hennebert
> wrote:
>
>> Glenn,
>>
>> This commit introduces Java 1.6 constructs, however we are still
>> supporting Java 1.5 as the minimum version. Sw
On Wed, Feb 29, 2012 at 2:18 PM, Vincent Hennebert wrote:
> Glenn,
>
> This commit introduces Java 1.6 constructs, however we are still
> supporting Java 1.5 as the minimum version. Switching to Java 1.6 is
> a significant decision that must be made by the project following
> a vote. Please, eithe
in the prior CS patch commit [1], two minor improvements were made to
build.xml [2], which I'd like to communicate to the group:
*junit output formatting*
(1) added definition of properties to control junit output formatting:
- junit.printsummary (defaults to off)
- junit.formatter.brief (
On Thu, Mar 1, 2012 at 1:17 AM, Pascal Sancho wrote:
> Hi,
>
> about @author tag, I agree with Vincent, reasons are clearly detailed here
> [1] (note that it is not a strict rule, just an "incitation").
>
> IIRC, this "incitation" had been discussed a long time after the FOP
> project began, and i
could you provide a link to the "Google Summer of Code Project"? how does
it relate to ASF and FOP activities?
On Thu, Mar 1, 2012 at 3:50 AM, mehdi houshmand wrote:
> Hi,
>
> We're thinking of submitting a proposal or two to the Google Summer of
> Code project and wanted to get some input from
I think we should keep in line with the Board recommendation.
>
> Thanks,
> Vincent
>
>
> On 01/03/12 09:00, Glenn Adams wrote:
> > On Thu, Mar 1, 2012 at 1:17 AM, Pascal Sancho >wrote:
> >
> >> Hi,
> >>
> >> about @author tag, I
In order to proceed on Vincent's proposed new checkstyle rules [1], I've
committed support for checkstyle-5.5 and the new rules [2].
[1]
http://mail-archives.apache.org/mod_mbox/xmlgraphics-general/201202.mbox/%3c4f2c1d25.8010...@gmail.com%3e
[2] http://svn.apache.org/viewvc?view=revision&revision
ng.
>
> In particular, I think we want to all use the same version of Checkstyle
> in order to ensure consistency. ATM Checkstyle 5.1 is used but when the
> new set of rules is in place I think we will all want to switch to
> Checkstyle 5.5.
>
> The checkstyle.location howeve
Thanks Alex for pointing this out. I'll fix right away. I had not
previously compiled (or used) any of the examples, so did not notice this
breakage.
G.
On Fri, Mar 2, 2012 at 7:22 AM, Alexios Giotis wrote:
> Hi Glenn,
>
> The complex scripts patch seems to have broken
> examples/embedding/java/
On Fri, Mar 2, 2012 at 11:18 AM, Vincent Hennebert wrote:
> I’d be happy to fix RegexpSingleLine and NewLineAtEndOfFile if that
> helps.
>
Sure, that will help divide the effort. One way you might do this (which I
will use), is:
(1) changing the new checkstyle.* params in your local properties f
Fixed [1].
[1] http://svn.apache.org/viewvc?view=revision&revision=1296385
On Fri, Mar 2, 2012 at 7:22 AM, Alexios Giotis wrote:
> Hi Glenn,
>
> The complex scripts patch seems to have broken
> examples/embedding/java/embedding/ExampleJava2D2PDF.java
>
> It would be good if by default the exampl
On Fri, Mar 2, 2012 at 11:18 AM, Vincent Hennebert wrote:
> Will you also fix the
> tests? Eventually we want to check them as well.
>
I agree that we will want to do so, but I'd prefer to handle the currently
checkstyle tested code first, and then subsequently do a separate fix round
to bring te
On Thu, Mar 1, 2012 at 5:30 PM, Glenn Adams wrote:
> ParenPad1
> MethodParamPad 4316
> WhitespaceAfter 2203
> ExplicitInitialization 795
>
Not implemented. I oppose enabling ParenPad or MethodParamPad for two
r
a community can impart upon them.
> >
> > I've included a link to the GSoC below, but if you do some research,
> > there's plenty of information out there.
> >
> > http://code.google.com/soc/
> >
> > Mehdi
> >
> > On 1 March 2012 16:13
On Mon, Mar 5, 2012 at 9:32 AM, Chris Bowditch
wrote:
> On 05/03/2012 16:18, mehdi houshmand wrote:
>
>> I agree that there may be some good project ideas in the bug list, but I
>> don't think the one Alex highlighted is a good one. Changing the layout
>> algorithm is a major undertaking, probably
On Mon, Mar 5, 2012 at 12:38 PM, Vincent Hennebert wrote:
> On 03/03/12 00:57, Glenn Adams wrote:
>
> > 2. for NoWhitespaceAfter, specified that line breaks are allowed after
> > DOT;
> > if this isn't done, then one cannot break a long line before *or* after
>
On Mon, Mar 5, 2012 at 1:14 PM, Glenn Adams wrote:
> On Mon, Mar 5, 2012 at 12:38 PM, Vincent Hennebert
> wrote:
>
>> On 03/03/12 00:57, Glenn Adams wrote:
>>
>> > 2. for NoWhitespaceAfter, specified that line breaks are allowed after
>> > DOT;
>>
enSSL
> souce code, where it is common to see the original authors. But then,
> there is no Javadoc there...
>
> On Tue, Mar 6, 2012 at 9:37 AM, Vincent Hennebert
> wrote:
> >> + *
> >> + * This work was originally authored by Glenn Adams (
> gad...@apache.org).
&g
fyi
-- Forwarded message --
From: Tony Graham
Date: Tue, Mar 6, 2012 at 5:25 AM
Subject: Proposed W3C "Print & Page Layout Community Group"
To: www-xsl...@w3.org
See http://www.w3.org/community/groups/proposed/#ppl
As the proposal text (below) states, the recent XSL-FO meetup sh
On Tue, Mar 6, 2012 at 10:55 AM, Glenn Adams wrote:
> The ASF board policy [1] which I cited in the update conventions page
> (that doesn't seem to have been rsynced yet) does not call out javadoc
i just svn updated /www/xmlgraphics.apache.org/fop on people.apache.org, so
it should
On Mon, Mar 19, 2012 at 9:14 PM, The Web Maestro
wrote:
> > Does that mean that we would be eventually phasing out Forrest
> > altogether and store the documentation directly in the CMS?
>
> Yes. We hope to phase out Forrest... All content changes will occur in the
> CMS.
>
At present, my underst
Testsuite: org.apache.fop.fo.properties.CommonAccessibilityHolderTestCase
Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.011 sec
Testcase: bindMustSetRoleAndSourceDoc took 0.01 sec
Caused an ERROR
Cannot mock/spy class
org.apache.fop.fo.properties.CommonBorderPaddingBackground
Mock
st unsatisfying solution to my eyes.
>
> Thanks for your vigilance,
> Vincent
>
>
> On 22/03/12 18:32, Glenn Adams wrote:
> > Testsuite: org.apache.fop.fo.properties.CommonAccessibilityHolderTestCase
> > Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.011 sec
> >
I just noticed that there are 83 bugs [1] that, since the FOP 1.0 release
(2010-07-20), have been marked as *resolved* and *fixed*, but have not been
changed to *closed* status.
[1]
https://issues.apache.org/bugzilla/buglist.cgi?list_id=81930;resolution=FIXED;chfieldto=Now;query_format=advanced;ch
On Wed, Mar 28, 2012 at 3:20 AM, Vincent Hennebert wrote:
> On 28/03/12 09:58, mehdi houshmand wrote:
> >>
> >> I wouldn’t bother. Lacking of a proper QA process, we don’t use the
> >> ‘verified’ and ‘closed’ status and consider that a bug has been handled
> >> once its status has been changed to
On Wed, Mar 28, 2012 at 12:23 AM, Glenn Adams wrote:
> I just noticed that there are 83 bugs [1] that, since the FOP 1.0 release
> (2010-07-20), have been marked as *resolved* and *fixed*, but have not
> been changed to *closed* status.
>
> [1]
> https://issues.apache.org/bu
If there are no objections, say, within 24 hours, I will go ahead and
transition to CLOSED+FIXED all bugs currently in the RESOLVED+FIXED state.
On Wed, Mar 28, 2012 at 10:45 AM, Glenn Adams wrote:
>
> On Wed, Mar 28, 2012 at 12:23 AM, Glenn Adams wrote:
>
>> I just noticed th
If I understand correctly, it is proposed that the FOP doc sources be
changed from the current forrest based format (and XML format) to markdown
format. If this is correct, then I would like to voice my objection to
making this change.
I am all for improving FOP documentation and management proces
On Thu, Mar 29, 2012 at 10:22 PM, Glenn Adams wrote:
> I also feel it is very important to continue using FOP documentation to
> create *some* output format. I am not prepared to give up our dog food,
> as that provides one more set of tests on FOP, that would otherwise be
> missin
On Fri, Mar 30, 2012 at 2:46 AM, Vincent Hennebert wrote:
> On 28/03/12 17:39, Glenn Adams wrote:
>
> > If we did have a full QA process, we would assign resolved bugs to
> someone
> > to check and transition to verified state. Then one of the following
> would
> &g
ve), then I have no objection to that.
Web Maestro Clay
>
> "My religion is simple. My religion is kindness."
> - HH The Dalai Lama of Tibet
>
> On Mar 29, 2012, at 9:22 PM, Glenn Adams wrote:
>
> If I understand correctly, it is proposed that the FOP doc sources be
&g
i've finished the batch transition to closed state for prior resolved bugs;
apologies for filling your inbox with the large number of bugzilla messages
On Wed, Mar 28, 2012 at 12:08 PM, Jeremias Maerki
wrote:
> There must be a really, really good reason to change the frontmost
> public API of FOP in a backwards-incompatible way. Changing the API will
> cause considerable work for all users when they upgrade. We must not do
> that on a whim.
>
W
On Mon, Apr 2, 2012 at 9:15 AM, Glenn Adams wrote:
> On Wed, Mar 28, 2012 at 12:08 PM, Jeremias Maerki
> wrote:
>
>> There must be a really, really good reason to change the frontmost
>> public API of FOP in a backwards-incompatible way. Changing the API will
>> caus
: maybe we should introduce a
> "version" attribute on the root element to indicate the version of IF
> XML format so people can deal more easily with that.
>
good idea; i will add
>
> Maybe there should be a registry of FOP's APIs and the stability policy
> for
On Tue, Apr 3, 2012 at 5:26 PM, Martin Edge
wrote:
> Yes, if you changed IF on me I'd need to know. I embed postscript commands
> in headers and page sequences.
>
> That said - if you are talking the java side of it versus the file format
> itself that doesn't affect me (but of course it may other
I need your input to identify bugs that should be designated as critical or
blocking for the purpose of performing an FOP1.1 release. If you believe an
existing open bug or a not yet filed bug is critical or blocking for the
purpose of creating a new release, then please respond. I will hold this
R
Following is a convenience link for listing those bugs which I am tracking
as my FOP1.1 short list. This list contains all open FOP bugs filed since
FOP1.0 release date (2012-07-21) that are not in the NEEDINFO state.
https://issues.apache.org/bugzilla/buglist.cgi?chfieldto=Now;chfield=%5BBug%20cr
s/all open/all normal or greater severity open/
On Sun, Apr 8, 2012 at 3:33 AM, Glenn Adams wrote:
> Following is a convenience link for listing those bugs which I am tracking
> as my FOP1.1 short list. This list contains all open FOP bugs filed since
> FOP1.0 release date (2012-07-21)
ok, good suggestion; i had thought of that also and was waiting to see
other feedback; i'll make this mod: default to true and log a message;
On Sun, Apr 8, 2012 at 8:38 AM, wrote:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=50435
>
> --- Comment #5 from Alex Giotis 2012-04-08
> 14:38:
On Sun, Apr 8, 2012 at 7:45 PM, The Web Maestro wrote:
>
>> So if you can find a way to transition to CMS as the doc management
>> system while still reusing the existing source formats and output formats
>> (modulo the above), then I have no objection to that.
>>
>
> Yes, we'd lose the XML-based
On Mon, Apr 9, 2012 at 6:50 AM, Clay Leeds wrote:
> On Apr 8, 2012, at 7:21 PM, Glenn Adams wrote:
>
> Yes, we'd lose the XML-based nature of the documentation. That's a fairly
>> large loss, but I don't know if that's a showstopper, considering the
>> b
at present, and for some time now, checkstyle-5.1 has been the default
version/configuration we have used on fop; however, now that vincent and i
have completed the work to use checkstyle-5.5, i'd like to change the
default in build.xml to use the new version
are there any objections to doing this
On Wed, Apr 11, 2012 at 3:29 AM, Chris Bowditch
wrote:
> My preference would be to find a way that allows us to move to CMS whilst
> keeping the xdoc source format. If it's not possible to keep the xdoc then
> I'm happy to accept moving to markdown or whatever works best.
>
+1
On Thu, Apr 12, 2012 at 6:59 AM, Chris Bowditch
wrote:
>
> Thanks for explaining. Based on the above I agree keeping xdocs seems
> overkill. I'm happy to move to markdown if that is the best alternative.
> Are there any options?
>
Agreed that removing forrest dependency is desirable. However, pre
there were no objections, so i have completed this change at
https://issues.apache.org/bugzilla/show_bug.cgi?id=53083
On Tue, Apr 10, 2012 at 4:43 PM, Glenn Adams wrote:
> at present, and for some time now, checkstyle-5.1 has been the default
> version/configuration we have used
On Sun, Apr 15, 2012 at 12:52 PM, The Web Maestro
wrote:
> I just added most of the nav for FOP Development (0.95, 1.0, trunk/ and
> 'dev'):
>
> http://xmlgraphics.staging.apache.org/
>
initial comments:
- the navigation panel on the left needs to start in a collapsed mode,
and remember it
I've been looking into a number of bugs related to fo:wrapper. After
reviewing the current implementation, I have concluded that a redesign of
WrapperLayoutManager is needed. I've started to document this at
http://wiki.apache.org/xmlgraphics-fop/Design/XslFo/Wrapper.
Comments are welcome.
G.
On Tue, Apr 17, 2012 at 2:15 AM, Chris Bowditch
wrote:
> We need to have a formal vote to decide if the XML Graphics project and
> all sub projects should switch the bug tracking system from Bugzilla to
> JIRA. The main benefits of which are:
>
+1
I like to give a little time to remove such code in case someone wishes to
dispute/revert my commented removal. If I don't remove in a reasonable
time, then feel free to remind me.
Thanks, G.
On Tue, Apr 24, 2012 at 9:15 AM, Vincent Hennebert wrote:
> On 21/04/12 05:11, gad...@apache.org wrote:
On Tue, Apr 24, 2012 at 9:12 AM, Vincent Hennebert wrote:
> On 22/04/12 21:09, gad...@apache.org wrote:
> > Author: gadams
> > Date: Sun Apr 22 20:09:42 2012
> > New Revision: 1328963
> >
> > URL: http://svn.apache.org/viewvc?rev=1328963&view=rev
> > Log:
> > Snapshot commit - does not build!
>
>
> I have no problem creating a chinese PDF when the font is embedded.
>>
>> The issue I am raising is when trying to reference (not embed) the font.
>>
>> Thanks for your help,
>>
>> Best regards,
>> JP
>>
>> On 23 Apr 2012, at 15:26, Glenn Ada
btw, this code has been present since 2008-05-08 [1]
[1] http://svn.apache.org/viewvc?view=revision&revision=654461
On Tue, Apr 24, 2012 at 1:16 PM, Glenn Adams wrote:
> ok, on digging into this further i have found:
>
> (1) luis is correct that embedding is performed by defaul
bug filed at https://issues.apache.org/bugzilla/show_bug.cgi?id=53142
jean-philippe, you may want to create a bugzilla account and add yourself
to the CC list for this bug
On Tue, Apr 24, 2012 at 1:16 PM, Glenn Adams wrote:
> ok, on digging into this further i have found:
>
> (1
ok, thanks for pointing that out; i have been marking their name in the
status.xml "due-to" attribute
On Wed, Apr 25, 2012 at 8:27 AM, Vincent Hennebert wrote:
> Hi Glenn,
>
> When committing patches submitted by contributors, you must put their
> names in the commit message. See also
> http://ww
n Bugzilla/JIRA and
> download it at build time. I suppose we can talk again about it once we
> have feedback from Sylvestre.
>
> On 08/04/12 10:33, Glenn Adams wrote:
> > Following is a convenience link for listing those bugs which I am
> tracking
> > as my FOP1.1 short l
was there a bug filed against which this fix was made? it's useful to
always file a bug for a significant change
On Fri, May 11, 2012 at 3:14 PM, wrote:
> Author: mehdi
> Date: Fri May 11 13:14:17 2012
> New Revision: 1337142
>
> URL: http://svn.apache.org/viewvc?rev=1337142&view=rev
> Log:
> Ch
Could you file a bug and reference it against this commit? Most commits
that change code, except perhaps one that is a trivial fix to a immediately
prior checkin or a cleanup fix, should have a bug filed that corresponds to
the commit. That allows us to have a better document trail for the commit,
thanks!
On Tue, May 15, 2012 at 8:53 AM, mehdi houshmand wrote:
> Yeah fair play on this one, in all honesty I was being lazy this time.
In accordance with a positive vote [1] to transition the XMLGraphics
products from Bugzilla to JIRA, I have filed an infrastructure task
requesting this transition at [2]. If I can help accomplish this task in
any way, please let me know.
Regards,
Glenn Adams (gadams at apache dot org)
[1]
http
ok; i'll update at first opportunity
On Thu, May 17, 2012 at 5:10 PM, Luis Bernardo wrote:
>
> I was going to submit a fix myself. Anyway, the epsilon only needs to be
> 1/256 because the fractional line width is stored in one byte. So it should
> be Math.abs(x - y) >= 1/256f.
>
> On 5/17/12 5:53
fixed, which, btw, can be done with:
svn propedit -r *revision* --revprop svn:log "new log message"
On Thu, May 17, 2012 at 3:02 AM, Vincent Hennebert wrote:
> Glenn,
>
> May I remind you to put contributor names in commit messages when you
> apply their patches [1].
>
> [1] http://markmail.org/
I've created an fop-1_1 branch to prepare the way for an FOP 1.1 release
according to the process outlined in [1]. At the recommended point in this
process, I will initiate a vote to accept the release.
If there are additional bug fixes or enhancements made in trunk during the
interim (before star
It would seem that to cut a FOP 1.1 release, we will need to do a
simultaneous XGC dot release as well, since the former depends on
unreleased changes in the latter. Is this correct?
docs, code, or should 1.1 be used?
- anything else?
On Wed, May 30, 2012 at 8:31 AM, Chris Bowditch
wrote:
> On 30/05/2012 08:36, Glenn Adams wrote:
>
> Hi Glenn,
>
>
> It would seem that to cut a FOP 1.1 release, we will need to do a
>> simultaneous XGC dot rele
I believe I've fixed this. We'll see on the next buildbot cycle.
On Sun, Jun 3, 2012 at 7:50 PM, Jeremias Maerki wrote:
> To whom it may engage...
>
> BUILD FAILED
> /srv/gump/public/workspace/xml-fop/build.xml:316: Compile failed; see the
> compiler error output for details.
>
Hi Mareki,
Thanks for your contribution. However, in order to process it, you will
need to accomplish the following prior to it being more fully considered
for possible integration:
- create and add tests for new renderer under test/**
- add necessary options to org.apache.fop.cli.CommandLi
It looks like my update to XGC didn't get completely propagated. I'm
heading to airport now, so won't be able to look at this until later today.
FWIW, my local build is working, so I've got to look deeper.
On Fri, Jun 15, 2012 at 2:45 AM, Jeremias Maerki wrote:
> To whom it may engage...
>
> This
If Vincent would like this in the 1.1 release, then I'm in favor of a merge
to trunk. So I'd say +1.
On Fri, Jun 15, 2012 at 5:29 AM, Pascal Sancho wrote:
> Hi,
>
> Since Glenn is in the process to release the FOP v1.1, I'm not sure
> it's time to merge such branch to trunk.
> I guess this new fe
Great job Vincent! You might also want to update the docs under [1] to
reflect the new TrueType/OpenType support, see, e.g., the Limitations
section.
[1] src/documentation/contentxdocs/trunk/output.html#ps
On Fri, Jun 22, 2012 at 12:35 PM, Vincent Hennebert wrote:
> While I was merging the FOP b
On Tue, Jun 26, 2012 at 8:38 AM, mehdi houshmand wrote:
> It means we can get rid of the font-caching and don't have to to worry
> about performance but it also allowed to do a lot of clean up in the
> configuration packages.
>
I'm not sure I understand what you mean by "we can get rid of
font-c
clear that we haven't removed either
> font-caching or font auto detection, we have just given users the means to
> disable and/or restrict those services.
>
> Mehdi
>
>
> On 26 June 2012 15:57, Glenn Adams wrote:
>
>> On Tue, Jun 26, 2012 at 8:38 AM, mehdi houshma
+1 but I'd prefer the merge wait a few days until I have completed the RC1
release
On Mon, Jul 2, 2012 at 6:28 AM, mehdi houshmand wrote:
> Hi Pascal,
>
> I won't be merging this into anything other than trunk. Sorry, maybe I
> should have made that more explicit.
>
> Mehdi
>
>
> On 2 July 2012
On Mon, Jul 2, 2012 at 7:25 AM, mehdi houshmand wrote:
> Ahh I see, ok, thanks Pascal. I think we got our wires crossed a little
> there ;)
>
> Glenn, my plan was to merge the URI-resolution stuff in tomorrow. If this
> burdens you in some way, could you let me know how and maybe we can come to
>
I have published XGC 1.5rc1 [1] and FOP 1.1rc1 [2], respectively, at:
- http://www.us.apache.org/dist/xmlgraphics/commons/
- http://www.us.apache.org/dist/xmlgraphics/fop/
With the exception of last modified time, these are exact copies of what
was posted on 24-Jun-12 for review and vote un
Please note that I have published the XGC/FOP site docs from the respective
{1.5,1.1}RC1 tags of these repos. Until this is merged into trunk, please
avoid publishing directly from trunk, lest the new RC1 docs be overwritten.
What would people prefer?
- merging these RC1 tagged revs back to trunk now (i.e., real soon now)
- not merging now, but waiting until their respective branches
(commons-1_5 & fop-1_1) are final before merging
If the former is followed, then we don't have to worry about overwriting
site
I've applied a fix at
http://svn.apache.org/viewvc?view=revision&revision=1356893. If this
doesn't address it, please let me know.
Thanks,
Glenn
On Tue, Jul 3, 2012 at 8:59 AM, sebb AT ASF wrote:
> The current version of the FOP DOAP is causing problems for
> projects.apache.org and so has been
just downloads it).
>
> When that works, it may be worth re-enabling the entry.
>
> On 3 July 2012 20:57, Glenn Adams wrote:
> > I've applied a fix at
> > http://svn.apache.org/viewvc?view=revision&revision=1356893. If this
> doesn't
> > address it,
l
[7] http://www.apache.org/dyn/closer.cgi/xmlgraphics/fop
[8] http://xmlgraphics.apache.org/fop/download.html
On behalf of the XML Graphics team,
Glenn Adams
On Tue, Jul 3, 2012 at 6:52 PM, sebb AT ASF wrote:
> Firefox now complains:
>
> Error loading stylesheet: A network error occurred loading an XSLT
> stylesheet:http://xmlgraphics.apache.org/xsl/p2.xsl
>
> This probably won't affect the project build, but it does affect users
> wishing to examine t
On Wed, Jul 4, 2012 at 9:25 AM, mehdi houshmand wrote:
> On 4 July 2012 12:32, Vincent Hennebert wrote:
>
>>
>> There does seem to be a regression. Before, the FopFactoryConfigurator
>> object was getting the strict-validation element from the config file
>> and calling FopFactory.setStrictValid
Thanks Vincent for pointing out the problem with performing merges on git
side then using git-svn dcommit back to SVN repo. I've investigated this
further, and indeed, git-svn does not update svn:mergeinfo or any other SVN
properties, so doing merges on the git side will be problematic. I will use
Mehdi, Please fix the following new deprecation warnings in trunk:
junit-compile-java:
[mkdir] Created dir:
/Users/glenn/Work/xmlgraphics/fop/trunk/build/test-classes
[mkdir] Created dir:
/Users/glenn/Work/xmlgraphics/fop/trunk/build/test-gensrc
[mkdir] Created dir:
/Users/glenn/Work/x
I'm now getting 98 new warnings when running "ant javadocs" on trunk:
[javadoc] Building tree for all the packages and classes...
[javadoc]
/Users/glenn/Work/xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/AFPResourceLevel.java:89:
warning - @param argument "level" is not a parameter name.
On Wed, Jul 4, 2012 at 3:54 PM, Alexios Giotis wrote:
> Well actually git-svn has an option to update the svn:mergeinfo. It might
> be worth giving it a try. There are some restrictions and I suggest to test
> it first. The following is part of $ man git-svn
>
>
> --mergeinfo=
>
On Thu, Jul 5, 2012 at 12:41 AM, mehdi houshmand wrote:
> Hi Chris/Glenn/Anyone else,
>
> You say command-line options should override the fop.xconf values, which
> makes sense. But should not-given command-line options override fop.xconf
> values too? Bare with me here, there is sense in the fol
No, this is NOT going to be fixed in the upcoming version. I have made NO
statements about when this will be addressed in FOP.
In particular, it will NOT be patched in 1.0 and will NOT be addressed in
1.1. This is a POSSIBLE 1.2 (or later) fix.
On Thu, Jul 5, 2012 at 1:23 AM, wrote:
> https://i
Is this addressing a specific bug? If not, then please enter a bug and
update the status to ensure this association for documentation and release
notes tracking purposes.
Also, I notice you left a printf in place below. Is that intentional? If
so, then I would suggest using something other than p
On Thu, Jul 12, 2012 at 7:45 AM, Vincent Hennebert wrote:
> On 12/07/12 14:37, Glenn Adams wrote:
> > Is this addressing a specific bug? If not, then please enter a bug and
> > update the status to ensure this association for documentation and
> release
> > notes tracking
On Thu, Jul 12, 2012 at 9:00 AM, Vincent Hennebert wrote:
> On 12/07/12 14:47, Glenn Adams wrote:
> > On Thu, Jul 12, 2012 at 7:45 AM, Vincent Hennebert >wrote:
> >
> >> On 12/07/12 14:37, Glenn Adams wrote:
> >>> Is this addressing a specific b
On Thu, Jul 12, 2012 at 10:47 AM, Vincent Hennebert wrote:
> On 12/07/12 16:17, Glenn Adams wrote:
> > If there is no bug entry in bugzilla, then there is/was no bug. Since
> this
> > is clearly a bug fix, there should be a documentation trail through the
> bug
> > da
On Fri, Jul 13, 2012 at 2:05 AM, Pascal Sancho wrote:
> IMHO, using a bugtracker system to list bugfix or changes is a good idea.
> But today, the practice in FOP project is to fill this list directly
> in the cited page.
> We can adopt a new policy here and have a change/bugfix list using
> bugtr
On Fri, Jul 13, 2012 at 9:08 AM, Vincent Hennebert wrote:
> We can decide to change that and use a bug tracking system instead, but
> in the same time we do that we will have to have in place a new
> mechanism to generate the changes [1] page. Also, we will most likely
> have to find a way to feed
On Mon, Jul 16, 2012 at 5:19 AM, Chris Bowditch
wrote:
> I'm in favour of changing the policy to always open a Bugzilla/Jira entry
> for every bug fixed in FOP. However, it won't always be possible to upload
> resources to replicate the issue. Whilst we can clean any FO Files of
> senstive data we
On Tue, Jul 17, 2012 at 6:05 PM, Alexios Giotis wrote:
> The end result is to provide a documentation trail. I initially replied to
> this thread because Jira is not (yet) used in FOP and it happens to provide
> this feature.
FYI, Alex, if you aren't aware of it, the project has already voted to
On Wed, Jul 18, 2012 at 7:44 AM, Vincent Hennebert wrote:
> On 18/07/12 13:46, Alexios Giotis wrote:
> >
> > On Jul 18, 2012, at 3:19 PM, Vincent Hennebert wrote:
> >
> >> On 18/07/12 01:14, Glenn Adams wrote:
> >>> On Tue, Jul 17, 2012 at 6:05 PM, Al
201 - 300 of 948 matches
Mail list logo
