RE: Building Fop 1.0dev with JDK 1.3 ??

[Bielik, Robert]

Phew... OK, I'll try. Though I have very limited insight into FOP to know what 
my
changes would incur, and unfortunately _very_ limited time so I don't want you 
to
count on me... ;)

Btw, when you develop FOP, what environment are you using ? I'm thinking of
cramming it into Eclipse which is sailing up to be my number 1 choice of IDE :)

Regards
/R

> -Original Message-
> From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 27, 2005 8:48 AM
> To: fop-dev@xmlgraphics.apache.org
> Subject: Re: Building Fop 1.0dev with JDK 1.3 ??
> 
> 
> Until we decide otherwise, FOP is still targeted at JDK 1.3 but you're
> right it currently doesn't compile. Nobody took the time, yet, to make
> it compile under 1.3. It's on my list of things but there are so many
> little things still to do. If you could try to fix it and send a patch
> that would be absolutely awesome! Do you want to try?
> 
> On 27.07.2005 08:14:14 Bielik, Robert wrote:
> > The question seemed to fit in this list rather than fop-users:
> > 
> > I've checked out the fop trunk and tried to build it with 
> JDK 1.3, however 
> > that doesn't seem to work (getting a number of compile 
> errors on among other
> > things, java.awt.Color)
> > 
> > Is the trunk known to require JDK1.4 or higher, if not, 
> what do I need to
> > think about ?
> > 
> > The reason I need JDK 1.3 is that I'm trying to fit fop 
> into an application
> > where JRE1.3 is used, AND I need it to be able to render 
> the (embedded) SVG in the
> > XSL-FO which is what doesn't work for me in fop 0.20.5.
> > 
> > TIA
> > /Rob
> 
> 
> 
> Jeremias Maerki
> 
> 

Re: Building Fop 1.0dev with JDK 1.3 ??

[Jeremias Maerki]

Until we decide otherwise, FOP is still targeted at JDK 1.3 but you're
right it currently doesn't compile. Nobody took the time, yet, to make
it compile under 1.3. It's on my list of things but there are so many
little things still to do. If you could try to fix it and send a patch
that would be absolutely awesome! Do you want to try?

On 27.07.2005 08:14:14 Bielik, Robert wrote:
> The question seemed to fit in this list rather than fop-users:
> 
> I've checked out the fop trunk and tried to build it with JDK 1.3, however 
> that doesn't seem to work (getting a number of compile errors on among other
> things, java.awt.Color)
> 
> Is the trunk known to require JDK1.4 or higher, if not, what do I need to
> think about ?
> 
> The reason I need JDK 1.3 is that I'm trying to fit fop into an application
> where JRE1.3 is used, AND I need it to be able to render the (embedded) SVG 
> in the
> XSL-FO which is what doesn't work for me in fop 0.20.5.
> 
> TIA
> /Rob



Jeremias Maerki

Re: getPageCount and FOP 1.0dev

[Jeremias Maerki]

Manuel,

thanks for grabbing this. I think the easiest thing will be to recreate
what was in 0.20.5. It doesn't offer very much and I have a better
overall mechanism in mind (as a long-term solution) but for the moment
it is easiest to do that. Here's what I would do:
- Copy over FormattingResults and PageSequenceResults over from 0.20.5
and replace the license header with the once you find all over FOP Trunk.
- Go to org.apache.fop.area.AreaTreeHandler.endPageSequence() and build
up the FormattingResults structure as it's done in 0.20.5 in
StreamRenderer. AreaTreeHandler is more or less the old StreamRenderer.
- When endPageSequence() is called you can probably derive the number of
pages generated for a page-sequence by subtracting currentPageNumber
from startPageNumber in layoutmgr.PageSequenceLayoutManager.
- Find a way to access the FormattingResults structure in Fop.java like
it was done in 0.20.5.

As an alternative to doing this in AreaTreeHandler you might want to
investigate fo.Root and fo.PageSequence but I'd prefer to have stuff
like that in AreaTreeHandler.

I hope that gives you some hints to do this. It shouldn't really be that
hard.

On 27.07.2005 08:13:58 Manuel Mall wrote:
> Jeremias,
> 
> happy to do so - I just setup Fop under NetBeans 4.1.
> 
> However, where do I start for something like this?
> 
> Manuel
> 
> PS: I moved this thread over to fop-dev as I assume its more appropriate
> here.
> 
> -Original Message-
> From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, 27 July 2005 14:08
> To: fop-users@xmlgraphics.apache.org
> Subject: Re: getPageCount and FOP 1.0dev
> 
> 
> No, but you're welcome to help improve the situation. :-)
> 
> On 27.07.2005 03:50:46 Manuel Mall wrote:
> > Jeremias post on fop-dev suggesting to push for a release made me curious
> to
> > check out if the new trunk code will work with our application.
> Downloading
> > it with subversion and building it with ant was not a big problem (These
> > things never seem to be 100% straightforward). Some of the interfaces have
> > changed and what was ...apps.Driver is now sort of ...apps.Fop. Not such a
> > big deal especially as examples exist, just a nuisance if you only want to
> > see if the new trunk code works with what we have got as it means code
> > changes to existing code. However I am stuck with how to replace the old
> > .getResults().getPageCount(). Is there something equivalent in
> > 1.0dev?
> 
> 
> Jeremias Maerki
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]



Jeremias Maerki

Building Fop 1.0dev with JDK 1.3 ??

[Bielik, Robert]

The question seemed to fit in this list rather than fop-users:

I've checked out the fop trunk and tried to build it with JDK 1.3, however 
that doesn't seem to work (getting a number of compile errors on among other
things, java.awt.Color)

Is the trunk known to require JDK1.4 or higher, if not, what do I need to
think about ?

The reason I need JDK 1.3 is that I'm trying to fit fop into an application
where JRE1.3 is used, AND I need it to be able to render the (embedded) SVG in 
the
XSL-FO which is what doesn't work for me in fop 0.20.5.

TIA
/Rob

getPageCount and FOP 1.0dev

[Manuel Mall]

Jeremias,

happy to do so - I just setup Fop under NetBeans 4.1.

However, where do I start for something like this?

Manuel

PS: I moved this thread over to fop-dev as I assume its more appropriate
here.

-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 27 July 2005 14:08
To: fop-users@xmlgraphics.apache.org
Subject: Re: getPageCount and FOP 1.0dev


No, but you're welcome to help improve the situation. :-)

On 27.07.2005 03:50:46 Manuel Mall wrote:
> Jeremias post on fop-dev suggesting to push for a release made me curious
to
> check out if the new trunk code will work with our application.
Downloading
> it with subversion and building it with ant was not a big problem (These
> things never seem to be 100% straightforward). Some of the interfaces have
> changed and what was ...apps.Driver is now sort of ...apps.Fop. Not such a
> big deal especially as examples exist, just a nuisance if you only want to
> see if the new trunk code works with what we have got as it means code
> changes to existing code. However I am stuck with how to replace the old
> .getResults().getPageCount(). Is there something equivalent in
> 1.0dev?


Jeremias Maerki


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 21265] - referencing a custom font (TTF or Adobe Type 1) for a pdf document fails witch fop-0.20.4

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=21265


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]
Summary|referencing a custom font   |referencing a custom font
   |(TTF or Adobe Type 1) for a |(TTF or Adobe Type 1) for a
   |pdf document fails witch|pdf document fails witch
   |fop-0.20.4  |fop-0.20.4




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: svn commit: r225143 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: apps/ fo/ render/ render/java2d/ render/pdf/ render/ps/ render/svg/ render/xml/ util/

[J.Pietschmann]

Jeremias Maerki wrote:

Just had. I must say that I don't get it from a 5 minute glance at it.


Me too. Commons math used to use discovery for getting an
implementation class for root solvers, but they abandoned
the approach because they thought the added dependency wont
outweight the benefits.
But they do have a Service class!

J.Pietschmann

Re: MathML and barcode support for FOP

[Jeremias Maerki]

I understand your concerns but we should make it as easy as possible for
beginners. There are a lot of them, many knowing almost nothing about
Java and classpaths. The beauty with these extensions is that they can
easily be deleted when not used. No rebuild necessary.

On 26.07.2005 21:45:33 Simon Pepping wrote:
> Having MathML and barcode support is a good thing. But I am not very
> enthousiastic about the goal of providing support for both
> out-of-the-box. Scratching pieces of functionality together and
> integrating them is a different role than developing an application. I
> am a Debian Linux user, and an advocate of the model of Debian (and
> other distributions): development is one role, integration is another
> role. I am horrified of the Apache packages, which make me have Xerces
> and other libs many times on my computer.
> 
> I am in favour of promoting the MathML extension to a more visible
> place. I have no opinion on JEuclid in XMLGraphics. Separating SVG
> support from FOP core is OK with me.


Jeremias Maerki

Re: Flame-fodder: Thinking about starting to release again....

[Jeremias Maerki]

On 26.07.2005 21:51:03 Simon Pepping wrote:
> I think that the first production release should be on parity with
> 0.20.5, unless we can advertise that the gains in new features
> outweigh the loss of features. The very first release does not have to
> satisfy that criterion, so we can do that soon. I would prefer a
> series like 0.90, 0.91, etc., with a b or beta or pr appended to make
> it clear that for now it is not yet the production ready successor to
> 0.20.

+1


Jeremias Maerki

Re: Flame-fodder: Thinking about starting to release again....

[J.Pietschmann]

Jeremias Maerki wrote:

I don't know of any such convention. I've seen various variants: rc,
beta, previews etc. I think we're free to choose.


I'd rather go for "alpha". "rc" means "release candidate", meaning
features and APIs are stable, and I don't think HEAD is there already.

Other than that, a release as a sign that the project isn't dead is
highly recommended, regardless of bugs and incomplete features.

J.Pietschmann

Re: Flame-fodder: Thinking about starting to release again....

[Jeremias Maerki]

On 26.07.2005 17:22:28 The Web Maestro wrote:
> Before we actually move to make this release, I'd like to understand 
> the discrepancies between 0.20.5 and the proposed 0.9rc1 release of 
> TRUNK a bit better.

Yes, that's an important point.

> I was under the impression that the first TRUNK 
> release would be on parity with 0.20.5. I'm not *certain* that is 
> necessary, although it is certainly preferred. Jeremias mentioned 
> parity between the PDF, Postscript & Java2D renderers, and that's a 
> good goal.

I agree that it is preferred to have a 0.20.5 equivalent, but not so
much that it obstructs us from doing a perfectly usable release. I think
0.20.5 will still be around for a while. There's no easy way around that.

> The FOPProjectTasks Wiki[1] is a good place to start, but a comparison 
> chart similar to the FOP Compliance Page might be better. That way our 
> users can quickly identify how usable the TRUNK release is for them. In 
> fact, it might make sense to just update the FOP Compliance page with 
> this information, changing "support" to "0.20.5 support", and creating 
> an additional "0.9xx1 support" group of columns[3].

As I mentioned myself a couple of times the compliance page is extremely
important for us as an instrument to inform users of the status of the
development. That's also a point where non-developers can easily
contribute. :-)


Jeremias Maerki

Re: MathML and barcode support for FOP

[Simon Pepping]

Having MathML and barcode support is a good thing. But I am not very
enthousiastic about the goal of providing support for both
out-of-the-box. Scratching pieces of functionality together and
integrating them is a different role than developing an application. I
am a Debian Linux user, and an advocate of the model of Debian (and
other distributions): development is one role, integration is another
role. I am horrified of the Apache packages, which make me have Xerces
and other libs many times on my computer.

I am in favour of promoting the MathML extension to a more visible
place. I have no opinion on JEuclid in XMLGraphics. Separating SVG
support from FOP core is OK with me.

Regards, Simon

On Tue, Jul 26, 2005 at 04:05:31PM +0100, Chris Bowditch wrote:
> Jeremias Maerki wrote:
> 
> >Devs,
> >
> >I'd like to have your thoughts about the following proposal. MathML and
> >barcodes are frequently asked for and I would consider it a service to
> >our users if we provided support for both out-of-the-box without people
> >having to scratch together the little pieces to make this stuff work.
> >JEuclid is AL1.1 and Barcode4J is AL2.0 licensed. So no worries about
> >redistribution. I'd like to promote the MathML extension out of the
> >examples directory where it seems to be a little hidden. We still have
> >the "plan" extension as a good example for FOP extensions. But I
> >wouldn't really want to integrate the MathML extension sources into the
> >main source tree where it adds to the existing blob of code. I'd rather
> >make SVG support separate and therefore optional and put both (SVG and
> >MathML) alongside each other in a separate place next to the main
> >sources. FOP without Batik-dependency has also been asked for a few
> >times which we could get almost for free if we did this. Barcode4J 1.0
> >as my proposed barcode package (what a surprise!) has its own FOP
> >extension and would simply be added as a JAR file in the lib directory.
> >I could do the necessary changes while doing the whole XML Graphics
> >Commons stuff which I really really really want to do really really soon
> >now. :-)
> 
> I am in favour of seeing MathML and barcode support out of the box in 
> FOP. Most people using XSL-FO for printed documents have a requirement 
> to add Barcodes and there are a small number of people asking for 
> Mathematic Formula representions. As you already mentioned it might be a 
> good idea to move the JEuclid code into a sub project of Xml Graphics. 
> Possibly the code that Siarhei Baidun is proposing to commit to Apache 
> in another thread.
> 
> Chris
> 

-- 
Simon Pepping
home page: http://www.leverkruid.nl

Re: Flame-fodder: Thinking about starting to release again....

[Simon Pepping]

On Tue, Jul 26, 2005 at 08:22:28AM -0700, The Web Maestro wrote:
> The thought of having a release from the TRUNK branch is very exciting. 
> I agree that releasing as 0.9rc1 (or 0.9b1, since we may not yet be at 
> release candidate stage or 0.9xx1) makes sense, and tells the world 
> we've moved past the 0.20.5 stage, which our project and community 
> desperately needs almost 2 years after the maintenance branch was 
> frozen.
> 
> Before we actually move to make this release, I'd like to understand 
> the discrepancies between 0.20.5 and the proposed 0.9rc1 release of 
> TRUNK a bit better. I was under the impression that the first TRUNK 
> release would be on parity with 0.20.5. I'm not *certain* that is 
> necessary, although it is certainly preferred. Jeremias mentioned 
> parity between the PDF, Postscript & Java2D renderers, and that's a 
> good goal.

I think that the first production release should be on parity with
0.20.5, unless we can advertise that the gains in new features
outweigh the loss of features. The very first release does not have to
satisfy that criterion, so we can do that soon. I would prefer a
series like 0.90, 0.91, etc., with a b or beta or pr appended to make
it clear that for now it is not yet the production ready successor to
0.20.
 
> The FOPProjectTasks Wiki[1] is a good place to start, but a comparison 
> chart similar to the FOP Compliance Page might be better. That way our 
> users can quickly identify how usable the TRUNK release is for them. In 
> fact, it might make sense to just update the FOP Compliance page with 
> this information, changing "support" to "0.20.5 support", and creating 
> an additional "0.9xx1 support" group of columns[3].

Sounds good.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl

Re: Flame-fodder: Thinking about starting to release again....

[The Web Maestro]

The thought of having a release from the TRUNK branch is very exciting. 
I agree that releasing as 0.9rc1 (or 0.9b1, since we may not yet be at 
release candidate stage or 0.9xx1) makes sense, and tells the world 
we've moved past the 0.20.5 stage, which our project and community 
desperately needs almost 2 years after the maintenance branch was 
frozen.


Before we actually move to make this release, I'd like to understand 
the discrepancies between 0.20.5 and the proposed 0.9rc1 release of 
TRUNK a bit better. I was under the impression that the first TRUNK 
release would be on parity with 0.20.5. I'm not *certain* that is 
necessary, although it is certainly preferred. Jeremias mentioned 
parity between the PDF, Postscript & Java2D renderers, and that's a 
good goal.


The FOPProjectTasks Wiki[1] is a good place to start, but a comparison 
chart similar to the FOP Compliance Page might be better. That way our 
users can quickly identify how usable the TRUNK release is for them. In 
fact, it might make sense to just update the FOP Compliance page with 
this information, changing "support" to "0.20.5 support", and creating 
an additional "0.9xx1 support" group of columns[3].


[1] FOPProjectTasks Wiki
http://wiki.apache.org/xmlgraphics-fop/FOPProjectTasks

[2] FOP Compliance Page
http://xml.apache.org/fop/compliance.html

[3] XSL-FO Object Support Table (§6)
http://xml.apache.org/fop/compliance.html#fo-object

Regards,

Web Maestro Clay
--
<[EMAIL PROTECTED]> - 
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Flame-fodder: Thinking about starting to release again....

[Jeremias Maerki]

I don't know of any such convention. I've seen various variants: rc,
beta, previews etc. I think we're free to choose.

Starting with a couple of preview releases would IMO be good to inform
people that the release is not supposed to be used in production, yet. A
release candidate is more like a probable end version where the last RC
is converted to the final release. At least that's my view.

On 26.07.2005 16:57:52 Chris Bowditch wrote:
> I wouldnt go as far as calling the code totally unstable! I have used it 
> for some documents and the output looks okay. However, we should call it 
> rc or pr as you suggest. I thought the Apache convention was 'rc', but I 
> have no real preference. Just so long as its clear that we expect to 
> find a few bugs and fix them before a production ready release is done.




Jeremias Maerki

Re: MathML and barcode support for FOP

[Chris Bowditch]

Jeremias Maerki wrote:


Devs,

I'd like to have your thoughts about the following proposal. MathML and
barcodes are frequently asked for and I would consider it a service to
our users if we provided support for both out-of-the-box without people
having to scratch together the little pieces to make this stuff work.
JEuclid is AL1.1 and Barcode4J is AL2.0 licensed. So no worries about
redistribution. I'd like to promote the MathML extension out of the
examples directory where it seems to be a little hidden. We still have
the "plan" extension as a good example for FOP extensions. But I
wouldn't really want to integrate the MathML extension sources into the
main source tree where it adds to the existing blob of code. I'd rather
make SVG support separate and therefore optional and put both (SVG and
MathML) alongside each other in a separate place next to the main
sources. FOP without Batik-dependency has also been asked for a few
times which we could get almost for free if we did this. Barcode4J 1.0
as my proposed barcode package (what a surprise!) has its own FOP
extension and would simply be added as a JAR file in the lib directory.
I could do the necessary changes while doing the whole XML Graphics
Commons stuff which I really really really want to do really really soon
now. :-)


I am in favour of seeing MathML and barcode support out of the box in 
FOP. Most people using XSL-FO for printed documents have a requirement 
to add Barcodes and there are a small number of people asking for 
Mathematic Formula representions. As you already mentioned it might be a 
good idea to move the JEuclid code into a sub project of Xml Graphics. 
Possibly the code that Siarhei Baidun is proposing to commit to Apache 
in another thread.


Chris

Re: fop contribution

[Jeremias Maerki]

On 26.07.2005 16:51:35 Siarhei Baidun wrote:
> >> 1. the insertion of exeternal PDF documents into the rendered PDF 
> >> document.
> >> The mechanism is similar on the images insertion, we use
> >> fo:external-graphics element and put content-type property equals to 
> >> "pdf"
> >>
> >> For example,
> >>
> >> 
> >> An external PDF file is inserted into rendered PDF document AS-IS, also
> >> there is a possibility to insert page range, not the whole external PDF.
> >
> > This sounds quite interesting and has been asked for a few times. A
> > simpler use case would be simply to be able to add PDF pages to a
> > FOP-generated document, possibly through a custom extension.
> 
> I may have expressed the idea not very clearly.
> We do add PDF pages to a FOP-generated document, except we do not use 
> extension pight now.
> We modified PDFRenderer  A BIT and particulary have added there the method
> renderExternalPage(...)

Ah, I see. But in that case external-graphic is probably not the right
element to use as it is an inline-level element.

> >> For external PDF uploading we use the third-party library Etymon Pj
> >> (http://www.etymon.com/epub.html) .
> >> It is under GNU GPL license .
> >
> > This is a problem. Apache software can't include or use GPL-licensed
> > software. A different approach would be to extend our own PDF library
> > to support parsing PDF or to use iText (which is MPL 1.1 licensed and
> > therefore usable for us). But the latter option would probably mean to
> > rewrite the whole PDFRenderer to use iText with all the implications
> > that arise with this. That's why I'd personally prefer extending our own
> > PDF library. But that is open for discussion.
> 
> To extend PDF library is the perfect solution.
> But it might take a long time and we need the working solution asap.
> So as a temporary solution we can consider the use of iText instead of Pj. 
> Right now I do not think such substitution is a bit problem.
> If iText is able to parse PDF document and if it provides the API to 
> retrieve PDF entities (e.g. Pages, resources, objects)  - no problem.
> Should say again, in case of the present implementation PDFRenderer is 
> affected in a little extent.

iText is able to handle that, yes.

> >> 2. MathML 2.0 support.
> > Are you aware of the MathML extension in the FOP repository?
> > http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/examples/mathml/
> 
> Have just had a look on it and was really surprised - it uses JEuclid!
> Just would like to say that we have been developing MathML support for 
> several month and made a deep tests for it.
> During development we were modifying JEuclid and have almost re-written it. 
> We can now consider the case of the implementation of mathML sub-project in 
> the scope of FOP (as PDF library)

Provided, we get the licensing issues right, yes. This would include
contacting the original authors of JEuclid if you based your code on it.
Furthermore, bringing in a whole subproject such as JEuclid would
involve going through the Apache Incubator. But let's first get some
opinions on that move (see my other thread).

> > If you plan to contribute anything larger than a bugfix on an existing
> > file we will need a CLA (contributor license agreement) for each person
> > that contributes to the project (to be sent to the ASF secretary). In
> > addition to that it may be necessary to submit a CCLA (corporate
> > contributor license agreement). Please see the following link for more
> > information:
> > http://www.apache.org/licenses/
> >
> > Code conventions are found here:
> > http://xml.apache.org/fop/dev/conventions.html
> >
> > Before you start to work on anthing bigger, please tell us what it is so
> > we can give some guidance and make sure there aren't any big
> > disappointments. Contributions should be sent to us using Bugzilla
> > entries which we will review and commit to the repository once
> > everything is fine. People contributing substantially to the project
> > (code, documentation, support etc.) over a longer period of time are
> > eligible to become a committer which includes write-access to the
> > code-repository, voting right and stuff like that. More infos on how
> > that works under:
> > http://xmlgraphics.apache.org/charter.html
> > http://www.apache.org/foundation/faq.html
> 
> Ok,
> we are ready to provide you our source code for features I outlined above 
> through Bugzilla.
> 
> As I understand, the license agreement (CLA) is requried when the issue of 
> becoming a contributor will arise (after several sucessfull contributions 
> through Bugzilla, as you wrote).

No, the ASF policy was recently changed (or rather clarified) so you
would need to submit a CLA for any contribution bigger than a trivial bugfix
on an existing file, i.e. for new files, even if you're not yet a
committer.


Jeremias Maerki

Re: Flame-fodder: Thinking about starting to release again....

[Chris Bowditch]

Jeremias Maerki wrote:


Another thing, that I'd like to bring up. We're approaching a state
where FOP Trunk code is usable for more serious use cases. The important
FOs are all implemented. In the past, we talked about making 1.0 meet
XSL 1.0 Basic Conformance. I believe to do that would be bad for the
project in its current state. We can't wait much longer and we
desperately need to attract active contributors. I don't mean that the
first release has to be a 1.0. But IMO we should get close to that.
Maybe call the first unstable preview release 0.9pr1. Once we have a
stable code base with a reasonable feature set and updated documentation
we should IMO call it 1.0 and go on from there.


I totally agree that a release is necessary to move the project on and 
since most of the functionality of 0.20.5 has been restored in Head plus 
keep-* property support I feel the code is ready for a release. Also I 
agree with your reasoning that it should be called 0.9 to make it clear 
that there are still some limitations to be addressed.




I believe that we could do an initial unstable preview release with big
disclaimers all over the place in about two months. My next tasks are to
update the PostScript renderer and to make sure that PDF, PS and Java2D
output is more or less on the same level. After that we should do a
testing/bugfixing round to make the overall package real-world-usable.


I wouldnt go as far as calling the code totally unstable! I have used it 
for some documents and the output looks okay. However, we should call it 
rc or pr as you suggest. I thought the Apache convention was 'rc', but I 
have no real preference. Just so long as its clear that we expect to 
find a few bugs and fix them before a production ready release is done.


Chris

Re: fop contribution

[Siarhei Baidun]

1. the insertion of exeternal PDF documents into the rendered PDF 
document.

The mechanism is similar on the images insertion, we use
fo:external-graphics element and put content-type property equals to 
"pdf"


For example,


An external PDF file is inserted into rendered PDF document AS-IS, also
there is a possibility to insert page range, not the whole external PDF.


This sounds quite interesting and has been asked for a few times. A
simpler use case would be simply to be able to add PDF pages to a
FOP-generated document, possibly through a custom extension.


I may have expressed the idea not very clearly.
We do add PDF pages to a FOP-generated document, except we do not use 
extension pight now.

We modified PDFRenderer  A BIT and particulary have added there the method
renderExternalPage(...)


For external PDF uploading we use the third-party library Etymon Pj
(http://www.etymon.com/epub.html) .
It is under GNU GPL license .


This is a problem. Apache software can't include or use GPL-licensed
software. A different approach would be to extend our own PDF library
to support parsing PDF or to use iText (which is MPL 1.1 licensed and
therefore usable for us). But the latter option would probably mean to
rewrite the whole PDFRenderer to use iText with all the implications
that arise with this. That's why I'd personally prefer extending our own
PDF library. But that is open for discussion.


To extend PDF library is the perfect solution.
But it might take a long time and we need the working solution asap.
So as a temporary solution we can consider the use of iText instead of Pj. 
Right now I do not think such substitution is a bit problem.
If iText is able to parse PDF document and if it provides the API to 
retrieve PDF entities (e.g. Pages, resources, objects)  - no problem.
Should say again, in case of the present implementation PDFRenderer is 
affected in a little extent.



2. MathML 2.0 support.

Are you aware of the MathML extension in the FOP repository?
http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/examples/mathml/


Have just had a look on it and was really surprised - it uses JEuclid!
Just would like to say that we have been developing MathML support for 
several month and made a deep tests for it.
During development we were modifying JEuclid and have almost re-written it. 
We can now consider the case of the implementation of mathML sub-project in 
the scope of FOP (as PDF library)




If you plan to contribute anything larger than a bugfix on an existing
file we will need a CLA (contributor license agreement) for each person
that contributes to the project (to be sent to the ASF secretary). In
addition to that it may be necessary to submit a CCLA (corporate
contributor license agreement). Please see the following link for more
information:
http://www.apache.org/licenses/

Code conventions are found here:
http://xml.apache.org/fop/dev/conventions.html

Before you start to work on anthing bigger, please tell us what it is so
we can give some guidance and make sure there aren't any big
disappointments. Contributions should be sent to us using Bugzilla
entries which we will review and commit to the repository once
everything is fine. People contributing substantially to the project
(code, documentation, support etc.) over a longer period of time are
eligible to become a committer which includes write-access to the
code-repository, voting right and stuff like that. More infos on how
that works under:
http://xmlgraphics.apache.org/charter.html
http://www.apache.org/foundation/faq.html


Ok,
we are ready to provide you our source code for features I outlined above 
through Bugzilla.


As I understand, the license agreement (CLA) is requried when the issue of 
becoming a contributor will arise (after several sucessfull contributions 
through Bugzilla, as you wrote).


--
Siarhei Baidun 

Re: MathML and barcode support for FOP

[Jeremias Maerki]

I was not so much thinking about additional XML Graphics projects.
Bringing Barcode4J here was on my mind, but not lately. I'm not sure if
it would be a good fit as it doesn't exclusively have to do the
converting XML to graphical output. That's only one use case. Generating
barcodes as bitmap images, for example, has absolutely nothing to do
with XML stuff.

Bringing JEuclid into the ASF and XML Graphics, however, could be quite
interesting and would be fully in line with the project charter.

On 26.07.2005 16:34:08 The Web Maestro wrote:
> It all sounds good to me. I was one of those asking for batik-less FOP, 
> since I needed to output PDF from a headless system (I think we ended 
> up using the Postscript renderer, and cat'ing it to the printer...).
> 
> I also welcome the thought of additional XML Graphics projects. Not so 
> much for the sake of quantity, but because I hope that additional 
> projects might bring additional users (folks interested in MathML or 
> Barcode4J, but not necessarily brought in because of XSL-FO/PDF or 
> SVG), and eventually additional committers (mmm... fresh blood ;-)).
> 
> Web Maestro Clay
> 
> On Jul 26, 2005, at 7:26 AM, Jeremias Maerki wrote:
> > Devs,
> >
> > I'd like to have your thoughts about the following proposal. MathML and
> > barcodes are frequently asked for and I would consider it a service to
> > our users if we provided support for both out-of-the-box without people
> > having to scratch together the little pieces to make this stuff work.
> > JEuclid is AL1.1 and Barcode4J is AL2.0 licensed. So no worries about
> > redistribution. I'd like to promote the MathML extension out of the
> > examples directory where it seems to be a little hidden. We still have
> > the "plan" extension as a good example for FOP extensions. But I
> > wouldn't really want to integrate the MathML extension sources into the
> > main source tree where it adds to the existing blob of code. I'd rather
> > make SVG support separate and therefore optional and put both (SVG and
> > MathML) alongside each other in a separate place next to the main
> > sources. FOP without Batik-dependency has also been asked for a few
> > times which we could get almost for free if we did this. Barcode4J 1.0
> > as my proposed barcode package (what a surprise!) has its own FOP
> > extension and would simply be added as a JAR file in the lib directory.
> > I could do the necessary changes while doing the whole XML Graphics
> > Commons stuff which I really really really want to do really really 
> > soon
> > now. :-)
> >
> > Jeremias Maerki
> >
> >
> 
> Regards,
> 
> Web Maestro Clay
> -- 
> <[EMAIL PROTECTED]> - 
> My religion is simple. My religion is kindness.
> - HH The 14th Dalai Lama of Tibet



Jeremias Maerki

Flame-fodder: Thinking about starting to release again....

[Jeremias Maerki]

Another thing, that I'd like to bring up. We're approaching a state
where FOP Trunk code is usable for more serious use cases. The important
FOs are all implemented. In the past, we talked about making 1.0 meet
XSL 1.0 Basic Conformance. I believe to do that would be bad for the
project in its current state. We can't wait much longer and we
desperately need to attract active contributors. I don't mean that the
first release has to be a 1.0. But IMO we should get close to that.
Maybe call the first unstable preview release 0.9pr1. Once we have a
stable code base with a reasonable feature set and updated documentation
we should IMO call it 1.0 and go on from there.

I believe that we could do an initial unstable preview release with big
disclaimers all over the place in about two months. My next tasks are to
update the PostScript renderer and to make sure that PDF, PS and Java2D
output is more or less on the same level. After that we should do a
testing/bugfixing round to make the overall package real-world-usable.

Your thoughts?

Jeremias Maerki

Re: MathML and barcode support for FOP

[The Web Maestro]

It all sounds good to me. I was one of those asking for batik-less FOP, 
since I needed to output PDF from a headless system (I think we ended 
up using the Postscript renderer, and cat'ing it to the printer...).


I also welcome the thought of additional XML Graphics projects. Not so 
much for the sake of quantity, but because I hope that additional 
projects might bring additional users (folks interested in MathML or 
Barcode4J, but not necessarily brought in because of XSL-FO/PDF or 
SVG), and eventually additional committers (mmm... fresh blood ;-)).


Web Maestro Clay

On Jul 26, 2005, at 7:26 AM, Jeremias Maerki wrote:

Devs,

I'd like to have your thoughts about the following proposal. MathML and
barcodes are frequently asked for and I would consider it a service to
our users if we provided support for both out-of-the-box without people
having to scratch together the little pieces to make this stuff work.
JEuclid is AL1.1 and Barcode4J is AL2.0 licensed. So no worries about
redistribution. I'd like to promote the MathML extension out of the
examples directory where it seems to be a little hidden. We still have
the "plan" extension as a good example for FOP extensions. But I
wouldn't really want to integrate the MathML extension sources into the
main source tree where it adds to the existing blob of code. I'd rather
make SVG support separate and therefore optional and put both (SVG and
MathML) alongside each other in a separate place next to the main
sources. FOP without Batik-dependency has also been asked for a few
times which we could get almost for free if we did this. Barcode4J 1.0
as my proposed barcode package (what a surprise!) has its own FOP
extension and would simply be added as a JAR file in the lib directory.
I could do the necessary changes while doing the whole XML Graphics
Commons stuff which I really really really want to do really really 
soon

now. :-)

Jeremias Maerki




Regards,

Web Maestro Clay
--
<[EMAIL PROTECTED]> - 
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: fop contribution

[The Web Maestro]

Jeremias,

I'm impressed with your fluency in English... :-p

On Jul 26, 2005, at 7:10 AM, Jeremias Maerki wrote:


I hope that helps. If you have any further questions, don't hesitate to
ask.

Jeremias Maerki


Regards,

Web Maestro Clay
--
<[EMAIL PROTECTED]> - 
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

MathML and barcode support for FOP

[Jeremias Maerki]

Devs,

I'd like to have your thoughts about the following proposal. MathML and
barcodes are frequently asked for and I would consider it a service to
our users if we provided support for both out-of-the-box without people
having to scratch together the little pieces to make this stuff work.
JEuclid is AL1.1 and Barcode4J is AL2.0 licensed. So no worries about
redistribution. I'd like to promote the MathML extension out of the
examples directory where it seems to be a little hidden. We still have
the "plan" extension as a good example for FOP extensions. But I
wouldn't really want to integrate the MathML extension sources into the
main source tree where it adds to the existing blob of code. I'd rather
make SVG support separate and therefore optional and put both (SVG and
MathML) alongside each other in a separate place next to the main
sources. FOP without Batik-dependency has also been asked for a few
times which we could get almost for free if we did this. Barcode4J 1.0
as my proposed barcode package (what a surprise!) has its own FOP
extension and would simply be added as a JAR file in the lib directory.
I could do the necessary changes while doing the whole XML Graphics
Commons stuff which I really really really want to do really really soon
now. :-)

Jeremias Maerki

Re: fop contribution

[Jeremias Maerki]

On 26.07.2005 15:47:03 Siarhei Baidun wrote:
> Hello
> Do not know exactly the person that is responsible for such issue as mine. 

Not a single person, but the whole FOP developer community and
eventually the XML Graphics project management committee (PMC). But you
found exactly the right spot to write to.

> So I decided to write to fop-dev.
> Our company has been sucessfully using FOP for several years.
> As our customers required extended functionality and FOP had several bugs 
> and restrictions, 3 years ago we created our own FOP branch.
> Those days we were in a hurry and did not consider the issue of commitment 
> of our modifications to Apache.
> 
> Now we have troubles with our FOP branch support because we have to 
> constantly merge it with Apache's FOP. Having now necessary resources we'd 
> like very much to commit our changes to Apache.

That's very good news.

> There are two main features we have implemented in the FOP:
> 1. the insertion of exeternal PDF documents into the rendered PDF document.
> The mechanism is similar on the images insertion, we use 
> fo:external-graphics element and put content-type property equals to "pdf"
> 
> For example,
> 
> 
> An external PDF file is inserted into rendered PDF document AS-IS, also 
> there is a possibility to insert page range, not the whole external PDF.

This sounds quite interesting and has been asked for a few times. A
simpler use case would be simply to be able to add PDF pages to a
FOP-generated document, possibly through a custom extension.

> For external PDF uploading we use the third-party library Etymon Pj 
> (http://www.etymon.com/epub.html) .
> It is under GNU GPL license .

This is a problem. Apache software can't include or use GPL-licensed
software. A different approach would be to extend our own PDF library
to support parsing PDF or to use iText (which is MPL 1.1 licensed and
therefore usable for us). But the latter option would probably mean to
rewrite the whole PDFRenderer to use iText with all the implications
that arise with this. That's why I'd personally prefer extending our own
PDF library. But that is open for discussion.

> 2. MathML 2.0 support.
> To implement MathML support, we also used the  third-party library named 
> JEuclid.
> But we can consider the case of MathML support implementation fully inside 
> of FOP project, without JEuclid usage.
> It would be not very expensive in human/time resources as our guys almost 
> fully re-implemented JEuclid.

Are you aware of the MathML extension in the FOP repository?
http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/examples/mathml/

> Some other features and bugs fixes were made.
> 
> 3 years ago we based our FOP branch on the Apacehe FOP version 0.20.4rc.
> As FOP maintenance branch is not being developed, we'd like to make 
> contributions on the main branch.

That would be extremely welcome and just at the right time!!!

> Coule you please advise on the steps on how to contribute. I guess there 
> should be some code compliance rules and some agreements with Apache.
> Also in case our customers will port their applications on new FOP we could 
> participate in FOP contribution more actively and push forward its success.

Most of the basic information for contributors is found here:
http://xml.apache.org/fop/dev/index.html

If you plan to contribute anything larger than a bugfix on an existing
file we will need a CLA (contributor license agreement) for each person
that contributes to the project (to be sent to the ASF secretary). In
addition to that it may be necessary to submit a CCLA (corporate
contributor license agreement). Please see the following link for more
information:
http://www.apache.org/licenses/

Code conventions are found here:
http://xml.apache.org/fop/dev/conventions.html

Before you start to work on anthing bigger, please tell us what it is so
we can give some guidance and make sure there aren't any big
disappointments. Contributions should be sent to us using Bugzilla
entries which we will review and commit to the repository once
everything is fine. People contributing substantially to the project
(code, documentation, support etc.) over a longer period of time are
eligible to become a committer which includes write-access to the
code-repository, voting right and stuff like that. More infos on how
that works under:
http://xmlgraphics.apache.org/charter.html
http://www.apache.org/foundation/faq.html

I hope that helps. If you have any further questions, don't hesitate to
ask.

Jeremias Maerki

fop contribution

[Siarhei Baidun]

Hello
Do not know exactly the person that is responsible for such issue as mine. 
So I decided to write to fop-dev.

Our company has been sucessfully using FOP for several years.
As our customers required extended functionality and FOP had several bugs 
and restrictions, 3 years ago we created our own FOP branch.
Those days we were in a hurry and did not consider the issue of commitment 
of our modifications to Apache.


Now we have troubles with our FOP branch support because we have to 
constantly merge it with Apache's FOP. Having now necessary resources we'd 
like very much to commit our changes to Apache.


There are two main features we have implemented in the FOP:
1. the insertion of exeternal PDF documents into the rendered PDF document.
The mechanism is similar on the images insertion, we use 
fo:external-graphics element and put content-type property equals to "pdf"


For example,


An external PDF file is inserted into rendered PDF document AS-IS, also 
there is a possibility to insert page range, not the whole external PDF.


For external PDF uploading we use the third-party library Etymon Pj 
(http://www.etymon.com/epub.html) .

It is under GNU GPL license .

2. MathML 2.0 support.
To implement MathML support, we also used the  third-party library named 
JEuclid.
But we can consider the case of MathML support implementation fully inside 
of FOP project, without JEuclid usage.
It would be not very expensive in human/time resources as our guys almost 
fully re-implemented JEuclid.


Some other features and bugs fixes were made.

3 years ago we based our FOP branch on the Apacehe FOP version 0.20.4rc.
As FOP maintenance branch is not being developed, we'd like to make 
contributions on the main branch.


Coule you please advise on the steps on how to contribute. I guess there 
should be some code compliance rules and some agreements with Apache.
Also in case our customers will port their applications on new FOP we could 
participate in FOP contribution more actively and push forward its success.


--
Thanks in advance,
Siarhei Baidun 

DO NOT REPLY [Bug 35534] - fo document output is placed in page margins

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35534





--- Additional Comments From [EMAIL PROTECTED]  2005-07-26 09:55 ---
The situation is now improved here. The missing glues are now produced but if
there are shrink and stretch possibilities the spaces are currently not
adjusted, i.e. differing .minimum/.optimum/.maximum values on space-before and
space-after may produce undesirable results.

Changes:
http://svn.apache.org/viewcvs?rev=225133&view=rev
http://svn.apache.org/viewcvs?rev=225135&view=rev
http://svn.apache.org/viewcvs?rev=225147&view=rev
http://svn.apache.org/viewcvs?rev=225249&view=rev
http://svn.apache.org/viewcvs?rev=225250&view=rev

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.