J.Pietschmann wrote:
Peter B. West wrote:
...the intention of the spec would be realised by laying out 0 of the
repeatable-p-m-refs "thin", out of the available range of 0-100, then
laying out 1 of the "thick" r-p-m-refs.
Interesting and useful interpretation. The problem is, how to
implement
Peter B. West wrote:
...the intention of the spec would
be realised by laying out 0 of the repeatable-p-m-refs "thin", out of
the available range of 0-100, then laying out 1 of the "thick" r-p-m-refs.
Interesting and useful interpretation. The problem is, how to
implement this?
J.Pietschmann
J.Pietschmann wrote:
Victor Mote wrote:
Just to be clear, I should point out that there is not a layout that is
impossible to perform.
There are layouts for which it is very hard to decide what
to do. Consider the following:
http://www.w3.org/1999/XSL/Format";>
On Tue, 2002-12-03 at 21:56, J.Pietschmann wrote:
> Oleg Tkachenko wrote:
> > btw, how does such a case addressed by the spec? Apparently FOP, antenna
> > and xep do squeeze content. Isn't it an example of overconstrained
> > geometry (5.3.4)?
>
> It can be interpreted as such in the presented c
Oleg Tkachenko wrote:
btw, how does such a case addressed by the spec? Apparently FOP, antenna
and xep do squeeze content. Isn't it an example of overconstrained
geometry (5.3.4)?
It can be interpreted as such in the presented case. Use height instead
of width and a table whose rows are kept to
J.Pietschmann wrote:
There are layouts for which it is very hard to decide what
to do. Consider the following:
http://www.w3.org/1999/XSL/Format";>
blabla..
Should this create 100 empty pages and r
Victor Mote wrote:
Just to be clear, I should point out that there is not a layout that is
impossible to perform.
There are layouts for which it is very hard to decide what
to do. Consider the following:
http://www.w3.org/1999/XSL/Format";>
On Thu, 2002-11-21 at 16:03, Rhett Aultman wrote:
> When you say "in the design," do you mean that this is expected behavior as it is
>now or as it should be at some point in the future?
That's the point of the original message, currently it doesn't do it
quite right. I am looking to adjust it to
Responses below.
-Original Message-
From: Keiron Liddle [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 21, 2002 9:11 AM
To: FOP
Subject: RE: Getting breaks: revisited
On Thu, 2002-11-21 at 14:20, Rhett Aultman wrote:
>No, in the design the best break cannot be before the bl
On Thu, 2002-11-21 at 14:20, Rhett Aultman wrote:
> IIRC, in my "8778 experiment", the break being offered was never null. The best
>break is always being offered, but the best break is at the beginning of the
>offending block. Either way, this resolves only the most trivial of the examples
>w
Responses below.
-Original Message-
From: Keiron Liddle [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 21, 2002 3:08 AM
To: FOP
Subject: RE: Getting breaks: revisited
Hi Rhett,
>>
On Wed, 2002-11-20 at 16:44, Rhett Aultman wrote:
> I may be green, but I did spot some
Hi Rhett,
On Wed, 2002-11-20 at 16:44, Rhett Aultman wrote:
> I may be green, but I did spot some of this a couple weeks ago, and it went mostly
>unnoticed. While writing this email, I downloaded another CVS snapshot and the
>super-simple test document from bug #8778, which is probably the sim
Responses Below.
-Original Message-
From: Keiron Liddle [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 20, 2002 3:38 AM
To: FOP
Subject: RE: Getting breaks: revisited
>>
I can't really see what you could find out on a first pass that does not
do some sort of layout. I su
On Tue, 2002-11-19 at 16:57, Rhett Aultman wrote:
>
> I'm not sure how writing the thing to make two passes is more loop prone than making
>one pass, especially if each pass performs a different function. For example, what
>if the first pass was designed only to gather information about the pro
Response below.
-Original Message-
From: Peter B. West [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November 19, 2002 9:55 AM
To: [EMAIL PROTECTED]
Subject: Re: Getting breaks: revisited
Keiron Liddle wrote:
>> I could just do it, special cases can use special techniques provi
Respone below.
-Original Message-
From: Keiron Liddle [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November 19, 2002 5:06 AM
To: FOP
Subject: RE: Getting breaks: revisited
On Sat, 2002-11-16 at 09:21, Rhett Aultman wrote:
>> What if, instead, two passes were taken? The first pass
Keiron Liddle wrote:
On Tue, 2002-11-19 at 15:07, Peter B. West wrote:
If possible I think we should try to avoid making multiple passes since
it can lead to loops etc. The table layout auto will need at least two
passes but this should be possible using the layout managers.
Is that a "should
On Tue, 2002-11-19 at 15:07, Peter B. West wrote:
> > If possible I think we should try to avoid making multiple passes since
> > it can lead to loops etc. The table layout auto will need at least two
> > passes but this should be possible using the layout managers.
>
>
> Is that a "should be" or
Keiron Liddle wrote:
On Sat, 2002-11-16 at 09:21, Rhett Aultman wrote:
It seems to me that there are (at least) two approaches: 1. A leaf on the
tree says "I am here, put me somewhere on a page", or 2. A higher-level node
(page-sequence) says "I have some space here, send me something to fill it
On Sat, 2002-11-16 at 09:21, Rhett Aultman wrote:
> > It seems to me that there are (at least) two approaches: 1. A leaf on the
> > tree says "I am here, put me somewhere on a page", or 2. A higher-level node
> > (page-sequence) says "I have some space here, send me something to fill it."
>
> 3. 1
On Fri, 2002-11-15 at 19:48, Victor Mote wrote:
> Just to be clear, I should point out that there is not a layout that is
> impossible to perform. The standard allows (and would have to)
> implementation-specific handling of what they call "over-constrained"
> requirements. In other words, requirem
Response Below.
-Original Message-
From: Peter B. West [mailto:[EMAIL PROTECTED]]
Sent: Friday, November 15, 2002 7:25 PM
To: [EMAIL PROTECTED]
Subject: Re: Getting breaks: revisited
>>Victor Mote wrote:
> It seems to me that there are (at least) two approaches: 1. A leaf on t
Victor Mote wrote:
Rhett Aultman wrote:
Hm...and what about a fusion of the two.
Yes.
>>If the LMs submitted
potential breaks and some sort of information about the
constraint that has to be removed to use them, and this
information was held on to, then at some point down the line in
pr
Victor Mote wrote:
Just to be clear, I should point out that there is not a layout that is
impossible to perform. The standard allows (and would have to)
implementation-specific handling of what they call "over-constrained"
requirements. In other words, requirements can be prioritized and allowed
Rhett Aultman wrote:
> Hm...and what about a fusion of the two. If the LMs submitted
> potential breaks and some sort of information about the
> constraint that has to be removed to use them, and this
> information was held on to, then at some point down the line in
> processing, FOP could rewind
Response below.
-Original Message-
From: Victor Mote [mailto:vic@;outfitr.com]
Sent: Friday, November 15, 2002 1:48 PM
To: [EMAIL PROTECTED]
Subject: RE: Getting breaks: revisited
>>Just to be clear, I should point out that there is not a layout that is
impossible to perfor
Rhett Aultman wrote:
> There is one more problem you need to put in there- under the
> current system, there is no mechanism for determining if the
> layout instructions in an FO document will produce a document
> that cannot exist. At least, there's none I've seen. Most of
> the bugs posted reg
Keiron Liddle wrote:
Hi Developers,
The current way that breaks are found with the layout managers has a
couple of problems.
Currently the information is contained in both the layout managers and
the break positions. This means that it must follow the order: get
breaks: add areas: get breaks et
Comments below.
-Original Message-
From: Keiron Liddle [mailto:keiron@;aftexsw.com]
Sent: Friday, November 15, 2002 3:30 AM
To: FOP
Subject: Getting breaks: revisited
<>
There is one more problem you need to put in there- under the current system, there is
no mechanism for determining
On Fri, 2002-11-15 at 09:42, Bertrand Delacretaz wrote:
> On Friday 15 November 2002 09:30, Keiron Liddle wrote:
> >. . .(does anyone even know what I am talking
> > about)
>
> Not much on my side as the whole layout thing is still a mystery to me
> (because I have no experience in computing layo
On 15 Nov 2002 09:30:17 +0100 Keiron Liddle wrote:
> So does that sound right. (does anyone even know what I am talking
> about)
:-) It sounds reasonable from a very high point of view. I hope I will
soon be able to join this kind of discussion. From next week on I'll be
a free man for a few mont
On Friday 15 November 2002 09:30, Keiron Liddle wrote:
>. . .(does anyone even know what I am talking
> about)
Not much on my side as the whole layout thing is still a mystery to me
(because I have no experience in computing layouts and never took
the time to study this part the code in detail).
32 matches
Mail list logo
