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
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 concept
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 crea
I was under the impression that the breaker automatically favors break
decisions that take up less space. It even goes so far that if you have
a minimum="0pt" and an optimum="2opt" on a space-before, that it
currently chooses "0pt" which is not so good, actually.
Well, we have several documented e
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,
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 recre
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 s
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 argue
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 m
Jeremias,
we consider the signing of the CCLA (corporate) , not ICLA (individual).
Could you please advise if ICLAs have to be signed along with CCLA for those
employees who would commit to Apache?
--
Thanks,
Siarhei Baidun
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
address
I've just had a closer look into the JEuclid project. There seems
absolutely no activity lately. 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
address the additional re
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 free
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 .
You're welcome :) However, I did a "svn up" and several .java files had conflict
resolve markers in them (< = >).
I'm not used to svn, is there something more I need to do?
/Robert
> -Original Message-
> From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July
On 27.07.2005 12:35:16 Siarhei Baidun wrote:
> > Ah, I see. But in that case external-graphic is probably not the right
> > element to use as it is an inline-level element.
>
> Any other ideas?
> The problem is XSL-FO specification does not describes the case of embedding
> external PDF files, s
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 l
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
Ah, I see. But in that case external-graphic is probably not the right
element to use as it is an inline-level element.
Any other ideas?
The problem is XSL-FO specification does not describes the case of embedding
external PDF files, so there is no special element there.
iText is able to han
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 it
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 expr
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=225486&view=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 scr
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 wrot
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 expressi
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
> Subje
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 PageS
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
Yes, please! :-) Thanks Luca.
On 27.07.2005 10:21:14 Luca Furini wrote:
> 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/.o
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 thin
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 results.
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.
getInstance(ColorSpace.CS_L
On 27.07.2005 08:54:27 Bielik, Robert wrote:
> 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... ;)
If you have very limited time then it's probably too soon
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
33 matches
Mail list logo
