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,
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,
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
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
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
Jeremias,
Excellent, thanks for the pointers. I'll have a go at it over the coming
weekend as I am going away for a few days now.
Manuel
On Wed, 27 Jul 2005 02:43 pm, Jeremias Maerki wrote:
Manuel,
thanks for grabbing this. I think the easiest thing will be to recreate
what was in 0.20.5.
Ok, I've now managed to get everything to compile alright. It wasn't really any
large problems. However, there is one in Java2DRenderer.java regarding
ColorModel:
Original code (1001):
ColorModel cm = new ComponentColorModel(ColorSpace.
Jeremias Maerki wrote:
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
Thanks for taking the time. Are you sure that these are all the changes
that were necessary? When I change what you indicated here, I still get
a few other errors. If you made more than just these modifications would
you please send us a patch so I can put the changes into the repository?
The
No, there were a couple of other changes. They were as follows:
1) In PageSequenceLayoutManager.java inner class PageBreaker, all 'log.' were
changed to 'pslm.log.' so that the log instance in PageSeq...Manager.java is
called.
2) In org.apache.fop.render.bitmap.TIFFRenderer the getLogger() call
I see. So, do you know how to create a patch? Just run svn diff
mydiff.txt and send us the file. That way I don't have to recreate all
your changes. Thanks in advance!
On 27.07.2005 10:44:54 Bielik, Robert wrote:
No, there were a couple of other changes. They were as follows:
1) In
Ok, diff file is attached. build.properties and build.xml is included in it but
I guess you can scrap that part...
Regards,
/Robert
-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 27, 2005 10:50 AM
To: fop-dev@xmlgraphics.apache.org
Subject:
Sorry to interrupt you all. But I have so concerns using JEuclid for MathML.
I'm not sure if I have the permission to post here, but maybe you will
excuse my post if so.
I am not sure if using JEuclid is the right way to deal with MathML. As far
as I understand JEuclid transforms a MathML
The MathML extension uses JEuclid to convert the MathML to SVG
internally so we get quite good quality. I don't think it is possible to
create XSL-FO code from MathML because you can't properly place all the
elements. Doing that with SVG is a lot better.
On 27.07.2005 10:54:45 Norman Markgraf
Thanks a lot, Robert. This saved me a lot of time. I've committed your
patch to the repository.
http://svn.apache.org/viewcvs?rev=225486view=rev
On 27.07.2005 10:56:19 Bielik, Robert wrote:
Ok, diff file is attached. build.properties and build.xml is included in it
but
I guess you can scrap
Sorry to interrupt you all. But I have so concerns using JEuclid for
MathML.
I'm not sure if I have the permission to post here, but maybe you will
excuse my post if so.
I am not sure if using JEuclid is the right way to deal with MathML. As
far
as I understand JEuclid transforms a MathML
While we are speaking of that, If I may give my opinion: I agree with Norman
that using images to render maths isn't a good solution in the long-term. The
fact that it is SVG improves the situation a bit because fonts will be rendered
fine, but there are other problems to address: for example
Thank you, Siarhei, for the explanation of the interrelationship between
JEuclid and FOP. In fact that was roughly what I mean by image. As I
explained, I am not in the details.
The words by Jeremias, that you can not place all element properly, might be
the point that sounds the most important
Please don't work on private channels. You can use the fop-dev mailing
list to discuss stuff around MathML as long as there is some relation to
FOP.
I wasn't aware of the advanced requirements like baseline alignment and
such. At any rate, the new FOP has the ideal infrastructure to handle
cases
That was to be expected. Run a svn revert -R .. This will revert all
the files to the state in the repository. Note that you will lose any
changes that you made since you sent the patch. HTH.
On 27.07.2005 14:17:17 Bielik, Robert wrote:
You're welcome :) However, I did a svn up and several .java
Right. For example we could provide an additional extension element
under fo:root which would involve extending its contents from:
(layout-master-set,declarations?,page-sequence+)
to:
(layout-master-set,declarations?,(page-sequence|fox:external-document)+)
This way it would be possible to
I've just had a closer look into the JEuclid project. There seems
absolutely no activity lately.
That's true
I'd recommend the following approach:
Contact the original authors and tell them that there is interest to do
some work on JEuclid, mainly to make it fit for use in FOP and to
On 27.07.2005 15:49:02 Siarhei Baidun wrote:
Jeremias,
we consider the signing of the CCLA (corporate) , not ICLA (individual).
The ICLA is mandatory for each person that intends to submit a
contribution to an ASF project. The CCLA is only necessary if you work
for a company and you want to
I got a test case for tables which raises not a technical but rather a
interesting conceptual question. Please have a look at the attached test
case. It defines a table with two columns and two rows. In the given
setup the second row creates an break decision with the current code that
can be
One thing that IMHO is still lacking in the table breaking code is
penalty values. ATM all penalties are 0. I believe the penalty value
should depend on the extra vertical size that the break contributes,
that is, on the penalty's width. I have no idea about the
multiplication constant, nor if it
Don't AreaTreeModel.getPageSequenceCount() and
AreaTreeModel.getPageCount(int seq) do this? AreaTreeHandler.model is
the AreaTreeModel object.
Simon
On Wed, Jul 27, 2005 at 08:43:50AM +0200, Jeremias Maerki wrote:
Manuel,
thanks for grabbing this. I think the easiest thing will be to
Right. I forgot that the AreaTreeModel keeps track of the page sequences.
On 27.07.2005 21:41:27 Simon Pepping wrote:
Don't AreaTreeModel.getPageSequenceCount() and
AreaTreeModel.getPageCount(int seq) do this? AreaTreeHandler.model is
the AreaTreeModel object.
Simon
On Wed, Jul 27, 2005
On Jul 27, 2005, at 20:45, Jeremias Maerki wrote:
Hi,
I got a test case for tables which raises not a technical but rather a
interesting conceptual question. Please have a look at the attached
test
case. It defines a table with two columns and two rows. In the given
setup the second row
Sorry, forgot the attachment...
table-body4b.xml.head.pdf
Description: Adobe PDF document
On Jul 27, 2005, at 23:26, Andreas L Delmelle wrote:
On Jul 27, 2005, at 20:45, Jeremias Maerki wrote:
Hi,
I got a test case for tables which raises not a technical but rather a
interesting
J.Pietschmann schrieb:
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
Yes 0.90-alpha sounds like version number
Christian
30 matches
Mail list logo
