margin-left always stays on the left side. The FO spec makes a clear
distinction between absolute (left, top, right, bottom) and relative
(start, end, before, after) properties.
lr: left=start, right=end
rl: left=end, right=start
So you obviously hit a bug. We haven't paid so much attention to
I think the problem in this area is much less of a problem that within
the renderers. The LMs operate on millipoints which provide a very good
resolution for our purposes. I doubt we have a big problem here. But in
case you find a mixture of approaches, i.e. rounding and truncating,
then something
On 30.08.2005 01:24:07 Stephen Denne wrote:
Jeremias Maerki wrote:
So please help us with the development or at least share with us your
concrete requirements! Maybe yours are different than mine.
I was intending to help with the development, but unfortunately a change to
the business
[Jeremias Maerki]
Perfect, Finn! I've just hacked together a little test extension that
lets me evaluate properties and write failure messages to a singleton
which a JUnit test case could process. It's very rough right now, but
with a little more work this could really be cool for checking the
[Manuel]
Agree, and I have a solution for that ready to go.
I think this deserves some further comment / discussion. One, IMO
important, reason I want to do the evaluation during the FO parsing
stage is that once we are in the LMs we lost the property inheritance
information. That is
On Tue, 30 Aug 2005 04:05 pm, Finn Bock wrote:
[Manuel]
Agree, and I have a solution for that ready to go.
I think this deserves some further comment / discussion. One, IMO
important, reason I want to do the evaluation during the FO parsing
stage is that once we are in the LMs we lost
J.Pietschmann wrote:
Maybe I'm wrong in trying to do so, but I'd like to handle both
formatting objects in the same way.
If page numbers can be resolved to strings early, it should be
done. All the hassle for space readjusting, and perhaps reflowing
content, should be reserved for forward
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=36408.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
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.
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.
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.
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.
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.
Manuel Mall wrote:
PS: I can imagine Victor smiling now :-) : I told you so that not
leaving all property resolution to the LM stage is going to cause
trouble.
Not just Victor, Manuel. But please press on re-discovering the wheel.
Peter
smime.p7s
Description: S/MIME
Manuel Mall wrote:
PS: I can imagine Victor smiling now :-) : I told you so
that not leaving all property resolution to the LM stage is
going to cause trouble.
Trust me, I'm not smiling. As one of our U.S. Presidents was known for
saying, I feel your pain. In fact, it might be fairly said
On Tue, 30 Aug 2005 08:43 pm, Victor Mote wrote:
Manuel Mall wrote:
PS: I can imagine Victor smiling now :-) : I told you so
that not leaving all property resolution to the LM stage is
going to cause trouble.
Trust me, I'm not smiling. As one of our U.S. Presidents was known
for saying,
Manuel Mall wrote:
Fair enough, btw its not painful for me at all. I have joined the
project with the goal to help to get FOP 1.0 out of the door in a
relatively short timeframe (meaning months not years). To achieve that
I am more than prepared to be pragmatic in the sense of getting things
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:
This is an excellent goal. Sometimes it is all too easy to
aim for 100% perfection and then FOP gets stuck - just like
it has been for 2 years prior to 2005. Compromise is the key
to getting 1.0 out of the door.
This is grossly foul. I don't remember anyone striving
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.
Victor Mote wrote:
Chris Bowditch wrote:
This is an excellent goal. Sometimes it is all too easy to
aim for 100% perfection and then FOP gets stuck - just like
it has been for 2 years prior to 2005. Compromise is the key
to getting 1.0 out of the door.
This is grossly foul. I don't
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=36408.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Chris Bowditch wrote:
Manuel Mall wrote:
Fair enough, btw its not painful for me at all. I have joined the
project with the goal to help to get FOP 1.0 out of the door in a
relatively short timeframe (meaning months not years). To achieve that
I am more than prepared to be pragmatic in the
Peter B. West wrote:
snip/
Couldn't let that one go by, Chris. These issues, which were critical
to the creation of both Folio and FOray, were being thrashed out around
the beginning of 2003. You've been around long enough to know that,
haven't you? So for more than two years, the pragmatic
On 30.08.2005 16:06:08 Finn Bock wrote:
[Jeremias on fox:ps- extensions]
Anybody opposed to my adding this? ...
Not at all, but I assume that you ask because it can't be added as an
extension that is completely seperated from FOP. That you have to make
changes to FOP sources in order
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=36408.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Chris Bowditch wrote:
Peter B. West wrote:
snip/
Couldn't let that one go by, Chris. These issues, which were critical
to the creation of both Folio and FOray, were being thrashed out around
the beginning of 2003. You've been around long enough to know that,
haven't you? So for more than
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.
Jeremias Maerki
Luca Furini wrote:
The Knuth-style page breaking algorithm gets a representation of a whole
page-sequence
Ah, I wasn't aware of this. Well, operating on a whole page
sequence makes implementing widows/orphans and other keep
conditions possible without backtracking, interesting.
Very
Regarding a fop-users email mentioning:
com/sun/media/jai/codec/FileCacheSeekableStream
Reminded me of something I encountered recently:
In my brief experience (of a modified version of FOP 0.20.5 that I
inherited), if the href is to a file, then its input stream is being given
to JAI, JAI is
[EMAIL PROTECTED] wrote:
Modified: xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOText.java
URL:
http://svn.apache.org/viewcvs/xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOText.java?rev=264863r1=264862r2=264863view=diff
[EMAIL PROTECTED] wrote:
+
+ private static void attrBaseLineShift(EnumLength baselineShift, RtfAttributes rtfAttr) {
+
+ String s = baselineShift.getString();
Use baselineShift.getEnum() to get the enum values that is assigned to a
length. Never ever use the getString()
Stephen,
thanks for pointing this out (again). I'll post a patch to fix this.
Manuel
On Wed, 31 Aug 2005 07:02 am, Stephen Denne wrote:
Regarding a fop-users email mentioning:
com/sun/media/jai/codec/FileCacheSeekableStream
Reminded me of something I encountered recently:
In my brief
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.
Just to flag that I have a patch for this. However, it depends on the
big revised percentage handling patch. So I'll hang on to it for the
time being.
Manuel
On Tue, 30 Aug 2005 02:31 pm, Jeremias Maerki wrote:
margin-left always stays on the left side. The FO spec makes a clear
distinction
On Mon, 29 Aug 2005 11:31 pm, Manuel Mall wrote:
On Mon, 29 Aug 2005 11:28 pm, Jeremias Maerki wrote:
On 29.08.2005 17:18:18 Manuel Mall wrote:
On Mon, 29 Aug 2005 08:20 pm, Jeremias Maerki wrote:
You probably missed the following:
7.10.1 margin-top says for percentages:
The
Excellent - I like the sound of it :-).
Personally, after having now used the trunk a bit and seeing the test
cases, etc., I would be a bit bolder and go for a name like 1.0
alpha or 1.0EA (I think that's the terminology Sun is using for
unstable early releases). The big disclaimers still
37 matches
Mail list logo
