Hi,
I get 11 errors and cannot build this rev.
Latest working rev was 524578 (for me).
I attached the build log.
Pascal
-Message d'origine-
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Envoyé : dimanche 1 avril 2007 16:51
À : fop-commits@xmlgraphics.apache.org
Author:
Hi,
Reading both CSS2 XSLFO 1.1 specs,..
1/ CSS2 17.5.1 gives the order of tables layers.
background-color default to transparent.
2/ XSLFO 6.7.9 says that fo:table-row does not generate any areas.
My question is: how to display row background if there is no area for it?
I see 2 answers:
1/
Hi,
I get 3 errors when I buid this latest TRUNK revision.
FYI, latest rev that works is rev 554240.
Rev 554251 fails too.
Pascal
[javac] D:\fop_trunk\src\java\org\apache\fop\fo\flow\TableFObj.java:330:
NumberProperty(int) has protected access in
Pascal Sancho wrote:
Hi,
I get 3 errors when I buid this latest TRUNK revision.
FYI, latest rev that works is rev 554240.
Rev 554251 fails too.
Pascal
[javac]
D:\fop_trunk\src\java\org\apache\fop\fo\flow\TableFObj.java:33
0: NumberProperty(int) has protected access
Hi,
For questions related to FOP usage, please ask in fop-user list.
FOP cannot concatenate PDFs, but you can do that in a post-process.
see [1] for existing post-processors.
Pascal
[1] http://xmlgraphics.apache.org/fop/resources.html#products-pdf
Message
Hi Andreas,
I think you are right, the current FO is not in its ancestors list.
Reading back REC 1.1/5.10.4, the default value for this function is the same
property.
In this case, the nearest ancestor-or-self specified property does a circular
ref,
but the nearest ancestor specified
Hi Vincent,
some weeks ago, I've checked some old bugs.
Attached the list of these bugs and what are fixed in latest trunk.
Since I'm neither reporter, nor fop dev, I didn't close those bugs.
Don't know the best way to help...
Pascal
-Message d'origine-
De : [EMAIL PROTECTED]
-Message d'origine-
De : Chris Bowditch [mailto:[EMAIL PROTECTED]
Envoyé : mardi 23 octobre 2007 14:45
Pascal Sancho wrote:
Hi Vincent,
some weeks ago, I've checked some old bugs.
Attached the list of these bugs and what are fixed in latest trunk.
Since I'm neither
Hi,
Sorry for the noise, I end with the bug #20950.
I hope this will save some time to FOP team.
Pascal
-Message d'origine-
De : J.Pietschmann [mailto:[EMAIL PROTECTED]
Envoyé : mardi 23 octobre 2007 21:40
Vincent Hennebert wrote:
Pascal Sancho wrote:
Sorry for the noise, I end with the bug #20950.
I hope this will save some time to FOP team.
Great and important work
-Message d'origine-
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Envoyé : jeudi 8 novembre 2007 16:13
Author: jeremias
Date: Thu Nov 8 07:13:24 2007
New Revision: 593189
URL: http://svn.apache.org/viewvc?rev=593189view=rev
Log:
Improved font auto-detection and handling
-Message d'origine-
De : mckacl [mailto:[EMAIL PROTECTED]
Envoyé : jeudi 15 novembre 2007 19:48
Hello,
I have taken responsibility for the FOP implementation at my company.
Unfortunately, in the past the framework was directly
customized for our
product requirements.
We
Hi there,
I've closed some bugs related to 0.20.x season, since they have been
fixed in recent releases (or trunk).
Hope that will help FOP team.
Some of them are in WORKSFORME state.
Please, have a particular look on these ones.
Soon, the 0.90-0.92 season?
Pascal
Hi Jeremiah,
There is an ommited copy/paste, isn't?
Pascal
-Message d'origine-
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Envoyé : lundi 25 août 2008 10:24
(...)
+dc:descriptionDocument subject/dc:subject
yazzy a écrit :
Hi
I have been asked to use FOP to convert RFT documents to PDF.
FOP has to be embeded within ASP page (JScript).
I have never used FOP and search found no examples to convert RFT to PDF
format. The only example I found was ExampleObj2PDF.java but I don't think
this the
Jonathan Levinson a écrit :
We are an international company, and need to support non-Western
documents including Greek, Thai and Chinese, amongst many others. We
have technical people at work in every area of the globe.
Best Regards,
Jonathan S. Levinson
-Original Message-
From: Simon
Hi Jeca,
Please, ask such question on FOP USER list, DEV list is for FOP
development questions.
What FOP version do you use?
What font do you use?
Can you provide short XSL-FO (not XSLT) that reproduce your problem?
At this stage, I can only suppose that either text-decoration is never
used
Hi Vincent,
I missed this this bug , thanks for the link.
For now, I'm fighting with Forrest...
When I understood it, I'll make the change.
Pascal
Vincent Hennebert a écrit :
Hi Pascal,
Author: psancho
Date: Mon Feb 15 15:43:32 2010
New Revision: 910239
URL:
It works like a charm now.
Thank you Jeremias.
--
Pascal
Jeremias Maerki a écrit :
Pascal, try to update/revert to revision 656962 on trunk. That's the
version I'm working with. Forrest is not always very forward and
backward compatible.
On 16.02.2010 16:28:15 Pascal Sancho wrote:
Hi
Hi Lars,
You should post using-Fop related questions on the Fop-user list, please.
The XSL-FO REC 1.1 says that fo:marker content is
(#PCDATA|%inline;|%block;)* (see [1]).
Therefore, as said in log, your fo:marker contains at least 1
fo:table-row, while it should not. Can you check that?
If this
(https://svn.apache.org)
Pascal
Vincent Hennebert a écrit :
Hi Pascal,
Pascal Sancho wrote:
Hi Vincent,
I missed this this bug , thanks for the link.
For now, I'm fighting with Forrest...
When I understood it, I'll make the change.
Great. The next step is to upload the updated
You are right, Simon.
I've tried to commit deployment by hands, and it's OK.
I have to investigate why ForrestBot did not.
Pascal
Simon Pepping a écrit :
On Wed, Feb 17, 2010 at 01:29:19PM +0100, Pascal Sancho wrote:
Hi Vincent,
I cannot deploy using ForrestBot; I think I have not write
A possible cause:
missing [deploy.svn.commit-message] when invoking ForrestBot with [ant
-f publish.xml] (see [1]).
I will check that on a future deployment.
[1]
http://svn.apache.org/repos/asf/forrest/trunk/etc/publishing_our_site.txt
Pascal
Pascal Sancho a écrit :
You are right, Simon.
I've
Hi,
I partially agree, but...:
- both releases (0.94: 2007, 0.95: 2008) are posterior to REC 1.1 (2006);
- both releases implement some REC 1.1 new features (Cf. bookmarks).
I can revert the change, but that will not reflect the above things, IMHO.
WDYT?
--
Pascal
Simon Pepping a écrit :
Hi Euan,
this bug is still reproduced with FOP TRUNK.
as a workaround, you should use fo:table instead of fo:list.
for your 2nd question, you can directly download FOP 0.95 binaries (see
[1]), but if you want to build from source, you should read first the
build page [2]).
If you still get
Hi Yannick,
IIUC, this patch doesn't apply to FOP.
Can you revert your change, please?
Thx
Pascal
bugzi...@apache.org a écrit :
https://issues.apache.org/bugzilla/show_bug.cgi?id=36378
Yannick Majoros yannick.majo...@gmail.com changed:
What|Removed
Hi,
For FOP usage related questions, please ask to FOP-users list, witch is
more appropriate.
That said, you are facing to 2 separate topics:
1/ XML to XST-FO transformation stage: produced XML contains XML
entities rather than characters, witch gives a hard to read file for a
human being.
This
Hi Giuseppe,
that is a good new! and you are welcome.
You can contribute initially by writing patches (see [1]), that is the
most common way for an initial contribution.
IIUC, you are ready to help on index implementation ([2]: REC 1.1 § 6.10).
I don't know if somebody in the dev team have some
Hi Tom,
Please, ask FOP usage related questions on FOP-User list.
That said, your question is not directly related to FOP. To be given a
more precise answer, you should indicate/provide:
- indicate what XML DTD and/or what XSLT you are using (and ask on the
relevant list, either concerning your
Hi Eric,
This site is not maintained by FOP team and appears to be out of date.
Currently, the only way to get an up-to-date javadocs is to make it
yourself: see [1].
[1] http://xmlgraphics.apache.org/fop/trunk/compiling.html#build-script
or
Hi Simon,
Le 07/07/2010 17:13, Simon Pepping a écrit :
This completes the documentation for the release. Note the following
points:
Rewrote xdocs/status.xml. Removed all references to the 0.20
versions. Removed all links to 0.94 and earlier.
xdocs/upgrading.xml is completely outdated. Do
Filled a bug entry to keep track of this:
https://issues.apache.org/bugzilla/show_bug.cgi?id=49583
Pascal
Le 10/07/2010 16:18, Simon Pepping a écrit :
On Thu, Jul 08, 2010 at 09:10:48AM +0200, Pascal Sancho wrote:
Hi Simon,
Le 07/07/2010 17:13, Simon Pepping a écrit :
xdocs
Hi Simon,
The FOP 1.0 tab homepage is the same as the FOP trunk one (title and
content).
Great ( and expected ;-) ) job otherwise, congratulations.
--
Pascal
Le 22/07/2010 09:26, Simon Pepping a écrit :
On Thu, Jul 22, 2010 at 08:19:13AM +0200, Michael Seeberger wrote:
Hi there,
when
that it is indeed working correctly
for ArialUni, peforming both bidi and Arabic shaping, i.e.,
substitution of positional variants and ligatures. Would you agree? Or
do you think something is amiss?
G.
On Tue, Aug 3, 2010 at 10:21 PM, Pascal Sancho
pascal.san...@takoma.fr mailto:pascal.san
Hi Eric,
this list is about FOP development, not XSLT or XSL-FO questions.
That said:
- all pages features are nested in the fo:root/fo:layout-master-set
element,
- while content is nested in fo:root/fo:page-sequence.
Therefore you should process your XML in a 2 passes XSLT:
- 1 template for
I've noticed that this has changed: Wiki changes are notified to fop-dev
list.
--
Pascal
Le 06/08/2010 12:09, Vincent Hennebert a écrit :
Moreover, notification is sent to the fop-commits mailing list whenever
a change is made to the wiki, which allows us to easily follow people’s
progress.
Hi,
Junit tests are for pre-commit purpose.
You can easily avoid them by running the right ant option:
ant package.
see [1] for further info on running ant with fop.
[1] http://xmlgraphics.apache.org/fop/1.0/compiling.html#env-ant
Le 09/12/2010 14:08, Eric Douglas a écrit :
Is there a way to
Hi Simon,
no problem for me, I have currently less free time to help FOP project.
However, I continue to monitor FOP lists, and help when I can.
Le 09/03/2011 20:14, Simon Pepping a écrit :
Dear former FOP committer,
On the FOP web pages you are listed as an active committer to FOP.
Since
Hi Eric,
FOP team is described here: http://xmlgraphics.apache.org/fop/team.html
Every FOP commiter (active or not) can commit to either FOP code or FOP
Web site.
Theree is no limit of people.
Giving someone commiter right access follows these steps:
- canditature proposed by a team member,
Hi,
FOP is an open source project, and everybody can contribute in his own
way, so you can reopen closed issues as you want if needed, and submit
patches as you want.
That said, IMHO, apart in a company quality context, testing closed
issues will not help very much (typically, an issue is closed
, not the exception.
G.
On Tue, May 3, 2011 at 1:24 AM, Pascal Sancho pascal.san...@takoma.fr
mailto:pascal.san...@takoma.fr wrote:
Hi,
FOP is an open source project, and everybody can contribute in his own
way, so you can reopen closed issues as you want if needed, and submit
Oh, my bad!
I've read Vincent's comment too quickly. You are right, and sorry about
what I said in this threat regarding this issue.
Apologies again.
Le 11/05/2011 13:45, Chris Bowditch a écrit :
On 11/05/2011 08:11, Pascal Sancho wrote:
Hi Darshan,
Hi Pascal,
Le 09/05/2011 23:28
Hi Daisuke
As you suspected it, this list is not for FOP usage, but FOP internals.
In the future, you should ask such kind of questions on FOP-Users list
(see [1] for details).
That said, FOP displays a '#' when a character is not available in
configured fonts.
To handle Japanese characters you
Hi Clay,
svn site r1140033 deployed.
Le 26/06/2011 09:20, Clay Leeds a écrit :
FWIW, I should've mentioned that there was some minor code cleanup in
here as well, to bring it closer to Forrest's skinconf.xml file.
Also, my primary purpose in making changes, was to help the Apache XML
Hi Glenn,
IMHO, the default setting should depend on how much it affects the
performances.
Can you give an approximative impact?
Le 19/07/2011 03:40, Glenn Adams a écrit :
I'm adding a feature to allow enable/disable of complex script features
(bidi, complex char to glyph mapping) at runtime,
if users will even notice this, so this would argue for enabling
by default.
On Tue, Jul 19, 2011 at 2:08 AM, Pascal Sancho pascal.san...@takoma.fr
mailto:pascal.san...@takoma.fr wrote:
Hi Glenn,
IMHO, the default setting should depend on how much it affects the
performances
Hi Vincent,
I'm not sure that this fixes the problem...
a simple quote should.
Le 12/09/2011 16:19, vhenneb...@apache.org a écrit :
- * Ascender Height is the character�s most positive y-axis value.
+ * Ascender Height is the characterâs most positive y-axis value.
--
Pascal
Hi,
+1 for me
Le 17/10/2011 15:06, Clay Leeds a écrit :
I'll belly up to the bar and have a Mockito as well... ;-)
+1
Sent from my iPhone
On Oct 13, 2011, at 8:38 AM, Peter Hancock peter.hanc...@gmail.com wrote:
I would like to launch a vote to include the Mockito framework and her
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
Hi,
I'm not sure that short variables names affect readability when long
mathematical formulas are used.
sometimes, code concision can help in understanding what code does:
depending on what you can read and understand at a glance.
Readability should be in a place between concision and verbose,
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
Hi,
There was a discussion about enabling it by default, with some
performances tests.
see http://marc.info/?l=fop-devm=131108266423848w=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
Hi Chris,
found just one duplication:
Match
Class name=org.apache.fop.afp.AFPPaintingState/
Field name=colorConverter/
Bug pattern=SE_BAD_FIELD_STORE/
/Match
using following template:
xsl:template match=Match
xsl:if test=preceding-sibling::Match[
Class/@name = current()/Class/@name
or (not(Method) and not(current()/Method) and not(Field) and
not(current()/Field)))]
xsl:copy-of select=./
/xsl:if
/xsl:template
This gives a more complete list (see atteched output)
Le 19/01/2012 13:33, Pascal Sancho a écrit :
Hi Chris,
found just one duplication:
Match
Class name
Hi,
I agree.
Found in FOP only 1 method witch javadoc explicitely says that is not
part of external API
(see o.a.fop.apps.FopFactory.java#getColorSpaceCache())
Perhaps this should be extended to the whole public material that should
only be invoked as internal.
Le 24/01/2012 12:16, Chris
Hi,
Le 27/01/2012 21:17, J.Pietschmann a écrit :
I'm
not sure what to do with the metrics generator, as the metrics file
is deprecated anyway.
IIUC, metric file is deprecated *only* for embedded fonts.
It is still required for referenced fonts.
deprecating metrics generator makes the latter
Hi,
+1
good job, Peter.
Does this will be a start point for a new FOP release?
Le 06/02/2012 13:35, Peter Hancock a écrit :
Thanks for bring these issues to my attention Chris.
Revision 1240963 addresses all findbug and checkstyle warnings.
Thanks,
Peter
On Thu, Feb 2, 2012 at 11:56
Hi,
for FOP usage related question, please ask on FOP-USER list.
that said, FOP 0.20.x is no longuer supported.
In this situation, the issue will be hard to reproduce.
AFAICS, I don't remember such limitation/intercation between file size
and missing characters.
Too many unknown factors can act
Hi,
+1
great job, Glenn.
Le 17/04/2012 10:15, Chris Bowditch a écrit :
Hi All,
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. JIRA has a more modern look
Hi,
great job, Clay!
I've looked at the compliance page closer, and it seems that rendering
doesn't support markdown extras (like table or headerid), when it is
said here [1] that such features are enabled for the CMS.
As a workaround, we can insert html markup inside the markdown, I tried
Hi Glenn,
1.1rc1 sounds good for me.
If further RC is required, the only final digit needs to be incremented.
In addition, this version name indicates by itself that this version
should not be used in prod.
Le 30/05/2012 16:40, Glenn Adams a écrit :
sounds reasonable, but I have a couple of
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 feature will not be part of the 1.1 release.
If merging have to be done quickly, then we should create a 1.1
maintenance branch to ensure that merging will not affect
Ok,
then...
+1 for me
2012/6/15 Glenn Adams gl...@skynav.com:
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 psancho@gmail.com
wrote:
Hi,
Since Glenn is in the process to release
Hi,
+1 for merging it to trunk.
That said, I'm a little puzzled with the release process.
In my mind, a RC should come before a production release, freezing all features.
Only bugfix should be permitted on RC.
Adding new feature to RC2 is a precedent that allows to add a new
feature after each
are planed to be ma
2012/7/2 mehdi houshmand med1...@gmail.com:
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 12:32, Pascal Sancho psancho@gmail.com wrote:
Hi,
+1 for merging it to trunk
Sorry, an unwanted key stroke...
2012/7/2 Pascal Sancho psancho@gmail.com:
Mehdi,
I speak about post 1.1RC1.
Your merge will be against the trunk.
What about the 1.1RC2 or 1.1 final?
In the current usage, *all* FOP releases are tagged directly from
trunk (via a branch that is only
changes to trunk affect 1.1RC*? The
1.1 branch has already been defined and voted upon, I don't see how any
changes to trunk would affect it? I'm not very familiar with the FOPs
releasing process so do excuse me.
Mehdi
On 2 July 2012 13:42, Pascal Sancho psancho@gmail.com wrote:
Mehdi
Hi Glenn,
good job!
I noticed 2 things remaining TODO in release checklist [1]:
announcement and bugzilla entry.
I can help you for the announcement (contact list at [2] plus previous
announces below).
[1] http://xmlgraphics.apache.org/fop/dev/release.html#checklist
[2]
Hi,
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
bugtracker facilities.
That could be done when we'll migrate to
I'm ok with that, but all fop team should be convinced...
So debate (if that need to discuss) is open ;-)
2012/7/13 Glenn Adams gl...@skynav.com:
On Fri, Jul 13, 2012 at 2:05 AM, Pascal Sancho psancho@gmail.com
wrote:
IMHO, using a bugtracker system to list bugfix or changes is a good
Hi
I tried yesterday to deploy minor changes on website (r1383917), but
when I entered svn up on people.apache.org (Cf. [1]),
I got an attempt to write a readonly database message.
Can someone try it and let me know if it's only for my account or not, please?
[1]
Ok,
thanks, Glenn. I'll contact infrastructure.
2012/9/14 Glenn Adams gl...@skynav.com:
On Fri, Sep 14, 2012 at 3:28 PM, Pascal Sancho psancho@gmail.com
wrote:
Hi
I tried yesterday to deploy minor changes on website (r1383917), but
when I entered svn up on people.apache.org (Cf. [1
Hi,
1st, this discussion should move to fop-dev list now.
2nd, there is definitively some issues that are due to length handled
as integer (char width you pointed here, i-p-d changes from page to
page because length is rounded when it result in float value (metric
to imperial conversion,
would anyone create a document that's 1/2 a mile long?
As for the rounding thing, I don't really have much useful input on that, my
understanding of the layout engine just isn't mature enough for me to form
an informed opinion.
On 25 September 2012 08:44, Pascal Sancho psancho@gmail.com wrote
Hi,
Very good job!
+1
2012/10/12 Peter Hancock peter.hanc...@gmail.com:
Hi,
Luis Benardo and Myself have just done some clean up to the branch
Temp_RoundedCorners. This branch implements support for 'fox'
extension properties for specifying borders with rounded corners.
Please refer to
Yes, CSS3 naming is easier to understand.
And like other border-* properties, top, right, bottom, left should be
mapped to equivalent FO directions in lr-tb mode (respectively before,
end, after, start).
2012/10/12 Clay Leeds the.webmaes...@gmail.com:
I would prefer CSS3 naming conventions as
Hi,
great job, Peter.
I have just a comment: when using invalid *-radius property (IE
fox:border-end-after-radius, inverting b-p-d and i-p-d radices), FOP
should warn or throw an exception, but I guess this is a more general
fox behaviour.
still +1 for me.
2012/10/22 Peter Hancock
Hi,
This merge seems introduce 3 deprecated warning.
I'm not sure, but it is possible that UnitConv has migrated to
xmlgraphics.commons
compile-java:
[mkdir] Created dir: D:\bin\java\fop\trunk\build\classes
[javac] Compiling 1441 source files to D:\bin\java\fop\trunk\build\classes
, and the branch should be
checked, regarding all changes introduced during the branch creation,
I suspect other potential regressions.
2012/10/24 Pascal Sancho psancho@gmail.com:
Hi,
This merge seems introduce 3 deprecated warning.
I'm not sure, but it is possible that UnitConv has migrated
Hi,
for fop usage related thing, please ask on Fop-users list. Fop-dev
list is for FOP internal development.
That said, your trace says:
java.lang.NoClassDefFoundError:
org/apache/fop/fo/flow/table/TableFObj$ColumnNumberPropertyMaker
(...)
Caused by: java.io.EOFException: Detect premature EOF at
On Thu, Oct 25, 2012 at 9:21 AM, Pascal Sancho psancho@gmail.com wrote:
Hi,
it appears that the change from r687369 is lost (replacing
org.apache.fop.util.UnitConv with
org.apache.xmlgraphics.util.UnitConv).
This regression starts with the branch (r1003017), so I guess it was
branched
Hi Glenn,
I have no access to such actions (Jira login: psancho).
2012/12/14 Glenn Adams gl...@skynav.com:
I've added all committers and contributors to their respective Jira roles,
except for Andreas who doesn't yet have a Jira account. I believe you should
be able to make the necessary
On Fri, Dec 14, 2012 at 2:17 AM, Pascal Sancho psancho@gmail.com
wrote:
Hi Glenn,
I have no access to such actions (Jira login: psancho).
2012/12/14 Glenn Adams gl...@skynav.com:
I've added all committers and contributors to their respective Jira
roles,
except for Andreas who doesn't
Hi,
before closing a bug, I think one should indicate what version its
resolution does affect.
The goal is to easily manage changes pages in FOP website.
2012/12/14 Alexis Giotis (JIRA) j...@apache.org:
[
Alexis
On 14 Dec 2012, at 17:07, Pascal Sancho psancho@gmail.com wrote:
Hi,
before closing a bug, I think one should indicate what version its
resolution does affect.
The goal is to easily manage changes pages in FOP website.
2012/12/14 Alexis Giotis (JIRA) j...@apache.org
/2012 09:08, Pascal Sancho wrote:
Hi list,
Hi Pascal,
In order to keep trace about works on versions, we should use the Jira
feature to indicate what version is fixed.
I agree.
in almost cases, fixes are against the trunk. Since in Jira one can
rename the version name (see [1
with this suggestion as i understand it
On Mon, Dec 17, 2012 at 2:08 AM, Pascal Sancho psancho@gmail.com
wrote:
Hi list,
In order to keep trace about works on versions, we should use the Jira
feature to indicate what version is fixed.
in almost cases, fixes are against the trunk. Since in Jira one can
Hi,
Jira comes with
- a new field [Type] that didn't exist in Bugzilla, with following entries:
Bug, New feature, Improvement, Wish, Task, and Test.
- the opportunity to create sub-tasks.
I propose the following usage:
Bug: a bug report, and only that
New feature and Improvement:
-
://issues.apache.org/jira/browse/FOP-1226
[3] https://issues.apache.org/jira/browse/FOP-1674
2012/12/19 Glenn Adams gl...@skynav.com:
On Wed, Dec 19, 2012 at 9:14 AM, Pascal Sancho psancho@gmail.com
wrote:
Jira comes with
- a new field [Type] that didn't exist in Bugzilla, with following
entries
Hi,
unless I'm missing something, fontbox dev activity is quite slow
(latest commit was on 2007-10-01, 6 years ago, see [1]).
IMHO, introducing a dependency on such project witch will need some
improvement is not a good thing, unless we can ensure that submitting
patches to it will be applied on
://svn.apache.org/viewvc/pdfbox/
I think it makes sense to reuse code wherever possible, especially when we
are talking about fellow Apache projects. So I'm +1 to this proposal.
Thanks,
Chris
On 10/01/2013 09:12, Pascal Sancho wrote:
Hi,
unless I'm missing something, fontbox dev activity
+1
2013/1/10 Robert Meyer rme...@hotmail.co.uk:
Hi all,
I posted a message yesterday about getting opinions on either adding a
dependency to fontbox to use their implementation or write our own for OTF
CFF support. I personally think that using fontbox would be the better
option due to:
Hi list,
I've updated the release page, taking into account that doc is now in CMS.
All changes that were made before on xdoc subdir have been removed,
including update for doap.rdf or news-data.xml.
You can check the changes, comparing [1] production site and [2] staging site.
If there is no
Hi Glenn,
2013/1/22 Glenn Adams gl...@skynav.com:
While debugging FOP-2197 [1], I learned that:
junit-transcoder tests all end up performing auto font detection, which
seems questionable [is this needed?]
auto font detection performs recursion on the font base directory even
though the code
Hi,
Since XCG website repository includes now all XCG sub-projects, there
should be a Jira entry for that.
In the same way, the doc management page should be moved to XCG general
website; WDYT?
2013/2/5 Clay Leeds the.webmaes...@gmail.com
I'll investigate the ANT stuff.
As for including the
Hi,
to unsubscribe from this list, you should mail directly to
fop-dev-unsubscr...@xmlgraphics.apache.org
--
pascal
Hi,
fop doc reflects now what is recommended in userlist...
good point!
2013/2/13 Luis Bernardo lmpmberna...@gmail.com:
In case someone misses the commit message...
I removed the section about font metrics from the trunk/fonts.html page (the
information is still present in 1.1/fonts.html
Hi,
You should file in a new entry in Jira, attaching the material provided here.
Note that RTF maintenance is quite poor (see [1]), and help is always welcome.
[1] http://xmlgraphics.apache.org/fop/trunk/output.html#rtf
2013/3/26 markus.sticker.e...@zf.com:
Hi,
I’ve got a strange
Hi,
I think it's a good idea.
2013/5/23 Luis Bernardo lmpmberna...@gmail.com
INFRA finally got around to do this, after a bit of nagging.
I assume that existing users will not be affected by this ACL. Changes to
the ACL admin group can be done by the users listed here:
Hi,
from [1], I understand that the BATIK patch is not yet applied on BATIK
trunk, so introducing a such dependency is not a good idea for the moment.
I will vote +1 when the patch will be applied.
For now, we depend on Batik team
[1]
1 - 100 of 228 matches
Mail list logo
