Well, in a certain aspect that is already the case today. I've recently
added to possibility to dynamically add renderer-specific XML handlers.
I need this for the Barcode4J extension for example (directly prividing
EPS and PDF versions of the barcode to the renderer). Furthermore, you
can always
On 31.08.2005 00:16:05 J.Pietschmann wrote:
Jeremias Maerki wrote:
I don't think you missed anything important except maybe your
personal opinion how you'd propose to go on. :-)
Ok.
Step 0: Baseline rules.
- No new Errors except possibly some sort of a FOPConfigurationError
(JAXP
(Just to be clear, you mean reference-orientation on simple-page-master,
right? Not region-body.)
Good question. I can't find any special reference to this case in the
spec. I guess we need to go with the end-user expectation which I
imagine would be that you compensate for the the rotation. But
Like others I'm hesitant to call it 1.0 just yet. 0.9 sends the right
signal IMO. We're not quite where we want to be but we are soon and
people can start looking at the new package.
We don't just have features that exceed FOP 0.20.5. We also have points
where FOP Trunk is still inferior to
On Wed, 31 Aug 2005 04:07 pm, Jeremias Maerki wrote:
Like others I'm hesitant to call it 1.0 just yet. 0.9 sends the right
signal IMO. We're not quite where we want to be but we are soon and
people can start looking at the new package.
Fine, not a problem for me.
We don't just have features
On 31.08.2005 10:29:07 Manuel Mall wrote:
On Wed, 31 Aug 2005 04:07 pm, Jeremias Maerki wrote:
Like others I'm hesitant to call it 1.0 just yet. 0.9 sends the right
signal IMO. We're not quite where we want to be but we are soon and
people can start looking at the new package.
Fine, not
Jeremias Maerki wrote:
The subject says it all:
http://wiki.apache.org/xmlgraphics-fop/ReleasePlanFirstPR
This is open for discussion. I'd really love to get the first release
out by the end of September.
Thats a good objective. I've reviewed the plan and it looks good. I
noticed that there
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36418.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Chris Bowditch wrote:
+ * Conditional space support, i.e. space-before.conditionality=retain
Chris, doesn't this work already?
As far as I can remember the correct space resolution is still missing, so
for example the space-after of a block is not added to the space-after
of the following
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36432.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
There seems to be a number of bugs concerning the positioning and
cropping of external SVG images in Fop. In particular, any large
SVG image gets cropped back to the 100x100 viewport defined in
getViewportSize() in SVGUserAgent.java. This seems to fit with
the problems reported against 0.20.5:
I'll have to take a closer look. I know there are still a few problems
left (I've been working in this area lately). The first step is to
create small test cases [1] to cover all the different possibilities.
Once we have that we can define the expectations and fix the problems.
That way we can
Luca Furini wrote:
Chris Bowditch wrote:
+ * Conditional space support, i.e. space-before.conditionality=retain
Chris, doesn't this work already?
Sorry that line wasn't clear enough. I just meant
space-before.conditionality should be fully implemented = discard
should work too.
As
Chris Bowditch wrote:
I just knocked up a small test case and although retain is honoured,
discard is ignored. I knew it wasn't quite yet working but didn't
realise retain was working :) I'll update the Wiki.
Could you please also attach your file?
I have tested a simple sequence of blocks
Luca Furini wrote:
Chris Bowditch wrote:
I just knocked up a small test case and although retain is honoured,
discard is ignored. I knew it wasn't quite yet working but didn't
realise retain was working :) I'll update the Wiki.
Could you please also attach your file?
Here is the sample:
Chris Bowditch wrote:
Here is the sample:
Thanks!
I have tested a simple sequence of blocks with conditional spaces and
the output seems ok; the output of the testcase space-block2.xml seems
correct too (I'm going to add checks).
Not true, space-block2.xml does not work. On the second
Luca Furini wrote:
Chris Bowditch wrote:
Here is the sample:
Thanks!
I have tested a simple sequence of blocks with conditional spaces and
the output seems ok; the output of the testcase space-block2.xml
seems correct too (I'm going to add checks).
Not true, space-block2.xml does not
I did a few things on PDFGraphics2D to improve the situation:
http://svn.apache.org/viewcvs?rev=240344view=rev
BTW Batik saw a significant performance increase when we went
to using a DecimalFormat object to write our strings.
Thanks for the hint. Sounds like rewriting PDFNumber.doubleOut using
DecimalFormat makes sense. May I ask what you used before switching to
DecimalFormat?
On 31.08.2005 14:32:01 Thomas DeWeese wrote:
I did a few things on PDFGraphics2D to improve the situation:
Jeremias Maerki writes:
I'll have to take a closer look. I know there are still a few problems
left (I've been working in this area lately). The first step is to
create small test cases [1] to cover all the different possibilities.
There is one related testcase - external-graphic-svg.xml.
Chris,
I'm afraid I don't agree with you here. You seem to mix up space conditionality
and space precedence. See § 4.3 of the spec, and especially § 4.3.1,
Space-resolution rules [1]
Conditionality only stands for spaces that begin a reference area; as per the
first rule, all of the
Weird. This test case works for me and it is not disabled (see
disabled-testcases.txt).
What does the Area Tree XML look like (found in
build/test-results/layoutengine)?
On 31.08.2005 14:58:04 richardw wrote:
Jeremias Maerki writes:
I'll have to take a closer look. I know there are still a
Jeremias Maerki wrote:
Like others I'm hesitant to call it 1.0 just yet. 0.9 sends the right
signal IMO. We're not quite where we want to be but we are soon and
people can start looking at the new package.
(..)
Jeremias Maerki
I agree, we have to be carefull to send the right message.
Vincent Hennebert wrote:
Chris,
I'm afraid I don't agree with you here. You seem to mix up space
conditionality and space precedence. See § 4.3 of the spec, and
especially § 4.3.1, Space-resolution rules [1]
Conditionality only stands for spaces that begin a reference area; as
per the first
Chris,
do you really think that FOray font integration is a prerequisite for
this release?
I would have thought its more of a nice to have but not a requirement
for this release.
Manuel
On Wed, 31 Aug 2005 09:00 pm, Apache Wiki wrote:
Dear Wiki user,
You have subscribed to a wiki page or
On Wed, 2005-08-31 at 10:07 +0200, Jeremias Maerki wrote:
Like others I'm hesitant to call it 1.0 just yet. 0.9 sends the right
signal IMO. We're not quite where we want to be but we are soon and
people can start looking at the new package.
I would recommend calling it 0.90, since obviously 9
Chris Bowditch a écrit :
The second fo:block does not begin a reference area, so space
conditionality isn't taken into consideration. For both spaces,
precedence is not specified so the default value of 0 is used (§
7.10.5 7.10.6). The third rule of § 4.3.1 states that between the
two
Just have a look at the number of messages for each month:
http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/
Or this: http://people.apache.org/~coar/fop-dev_xmlgraphics_apache_org.png
(taken from http://people.apache.org/~coar/mlists.html#xmlgraphics.apache.org,
the red line in the
Manuel Mall a écrit :
I would have thought its more of a nice to have but not a requirement
for this release.
Exactly. If FOrayFont is ready for this release, all the better.
It's difficult to say if it will be. The pdf library is now converted,
PDFRenderer almost.
I think the PSRenderer
Jeremias Maerki wrote:
Just have a look at the number of messages for each month:
http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/
yes I have noticed the increase in activity. It's been hard to keep up
with all the mails on this list over the last few days. It's a good sign
Thank you, Finn!
Regards,
Peter Herweg
-Ursprungliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Auftrag von Finn Bock
Gesendet: Mittwoch, 31. August 2005 01:10
An: fop-dev@xmlgraphics.apache.org
Betreff: Re: svn commit: r264856 - in
Jeremias Maerki wrote:
Thanks for the hint. Sounds like rewriting PDFNumber.doubleOut using
DecimalFormat makes sense. May I ask what you used before switching to
DecimalFormat?
Double.toString(double d),
I just took a look, whats with the PDFNumber.doubleOut function
It rounds
Sorry, that was my mistake - need to configure NetBeans to put the
Apache license into new files generated by the IDE.
Manuel
On Thu, 1 Sep 2005 04:42 am, Jeremias Maerki wrote:
Oops.
On 31.08.2005 22:30:49 bckfnn wrote:
Author: bckfnn
Date: Wed Aug 31 13:29:33 2005
New Revision:
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36379.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Just an update to let you know I should have something ready to show you
this week-end.
Patrick Paul
Jeremias Maerki wrote:
Ok, so let's try to come up with a list. I see:
The whole Using FOP section
- compiling.xml
- configuration.xml
- running.xml
- embedding.xml
- servlets.xml
-
35 matches
Mail list logo
