Re: block-containers with BPD set

[Jeremias Maerki]

Thanks to Victor and Andreas for helping me here, although I'm still
confused.

On 27.01.2005 00:25:27 Victor Mote wrote:
> Andreas L. Delmelle wrote:
> 
> > Do you feel the contents of the block-container should not be 
> > broken up at all? (Hence the analogy to a fo:external-graphic?)
> 
> No, sorry, I didn't mean to imply that. I think the contents can (possibly,
> depending on the overflow constraints) be broken up, but that the viewport
> cannot be. So the analogy with external-graphic breaks down there. The
> similarity is in the fact that they (in this case) have a fixed size and
> must move in their entirety.

This seems to be contradicting. I don't see how the overflow property
would control such behaviour. Also, if you say that they "must move in
their entiretly", how can the contents be broken up? Or does "they"
refer to something else than the contents?



> > (more or less the effect the page-height property has on the 
> > page-viewport-areas generated during formatting) In that 
> > case, is it even conceivable to have more than one 
> > viewport-area for a block-container with constrained bpd?
> 
> Yes. This seems most useful to me in cases where the viewport would occupy
> most or all of the main-reference-area, as in the case of the
> report-turned-sideways example I gave earlier. Suppose you have some unknown
> quantity of 132-column output you want to show in landscape mode. You can
> create a fixed-size block-container, tell it to overflow into other ones,
> add a "break" constraint at the end of each page, and you now get n pages of
> output.

Well, this is a case where I'd rather use a separate page-sequence with the
reference orientation set on the simple-page-master.

> > Or would it mean that _all_ of them taken together should be 
> > _that_ big?
> 
> The previously-cited 1.1 item seems to indicate that the constraint applies
> to each of the viewport areas individually as opposed to all of them in
> total. However, I could misunderstand.
> 
> > Having no constraints on the keeps, and only the bpd 
> > specified, it seems perfectly legal to break and interpret 
> > the bpd constraint as a total that may be divided over 
> > multiple viewport areas, but it may seem a bit tricky.
> 
> You may be right, but I can't think of a case where that would be useful.
> 
> AFAICT, keeps and space constraints would be left intact for the contents of
> the block-container. So, if a decision has been made that an additional
> viewport is needed to fit the contents, the keeps, breaks, and spaces would
> be used to decide which content went to an anterior vp and which to a
> posterior vp, just like in any page-break decision.

Hmm, seems like there's some room for interpretation. Yet another
question for the FO WG. Sigh.

I guess we're not so bad off with the current handling, so I'll let it
be for the moment and go on to more important tasks. At any rate, this
thread is flagged in my mail client...

Thanks,
Jeremias Maerki

Fwd: FOP status

[Ilya Khandamirov]

Dear FOP Developers,

I'm re-posting this mail from the user list, because there was no clear
answer there.

The main questions are: 
- what are the plans concerning the future FOP releases? Is there a defined
timeline?
- what are the plans concerning the spec conformance?

Your answers are greately appreciated. It would help me to decide, if i
should go FOP.

Regards,
Ilya


--- Weitergeleitete Nachricht / Forwarded Message ---
Date: Tue, 25 Jan 2005 14:16:54 +0100 (MET)
From: "Ilya Khandamirov" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: FOP status

Hi,

I need a possibility to generate PDF from my XML. I've heard many good
things about FOP, and i would use it, but...

After having a quick look at the home page i got an impresion, that the
project is dead. Last release is already 1.5 years old, and it is a bug fix
only release. No information about upcoming features/releases. Dev and user
mailing lists do not seem to be very busy.

Hopefully my impression is wrong. Could someone please clarify, what are the
current plans regarding the future FOP development? What are the plans
concerning FOP 1.0? What are the plans concerning the spec conformance?

Regards,
Ilya

-- 
GMX im TV ... Die Gedanken sind frei ... Schon gesehen?
Jetzt Spot online ansehen: http://www.gmx.net/de/go/tv-spot

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-- 
10 GB Mailbox, 100 FreeSMS http://www.gmx.net/de/go/topmail
+++ GMX - die erste Adresse für Mail, Message, More +++

Re: FOP status

[The Web Maestro]

Ilya,
NOTE: This message does not reflect a decision of the FOP Development 
Team. Rather it is my own thoughts on the subject. If there are any 
mistakes or inaccuracies in my thinking or reasoning, I hope the FOP 
Team will let us know. My goal is to give Ilya and other an answer on 
this important subject.

The FOP Development Team is actively & diligently working to achieve a 
1.0 release of Apache FOP. As with many open source projects with 
limited resources (i.e., a small number of active volunteer 
developers[1]), release schedules suffer. It has been 18+ months since 
the most recent release of 'maintenance' branch of FOP (fop-0.20.5). As 
you are probably aware, there were problems with meeting the 
requirements of the XSL-FO 1.0 Spec via the 'maintenance' branch, so it 
was frozen. The hope was that a re-design could be released relatively 
quickly, which would enable the FOP Team to meet the needs of the 
XSL-FO Spec. This hasn't happened yet, but we haven't stopped working 
towards that goal.

Although there are Status[2], Change[3], ToDo[4], News[5] and other 
pages, a TIMELINE unfortunately is not presently on the site. Possible 
release dates and timelines for FOP 1.0 have been unofficially bandied 
about on the mailing lists. The most 'relevant' date I've seen is 
"summer of 2005". This is not any sort of a 'promise' of a release 
date. It's just what I've seen in the mailing lists. In the 
not-too-distant future, I suspect the FOP Development Team will discuss 
a timeline schedule for release. Perhaps we may even  add info on the 
FOP 'home' page or add a new page to the site, to communicate better 
with the FOP community.

I apologize I/we cannot provide more specific information.
Web Maestro Clay
[1] Who we are
http://xml.apache.org/fop/team.html
[2] Status
http://xml.apache.org/fop/status.html
[3] Changes
http://xml.apache.org/fop/changes.html
[4] Todo
http://xml.apache.org/fop/todo.html
[5] News
http://xml.apache.org/fop/news.html
On Jan 27, 2005, at 6:35 AM, Ilya Khandamirov wrote:
Dear FOP Developers,
I'm re-posting this mail from the user list, because there was no clear
answer there.
The main questions are:
- what are the plans concerning the future FOP releases? Is there a 
defined
timeline?
- what are the plans concerning the spec conformance?

Your answers are greately appreciated. It would help me to decide, if i
should go FOP.
Regards,
Ilya
Web Maestro Clay
--
<[EMAIL PROTECTED]> - 
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

RE: block-containers with BPD set

[Victor Mote]

Jeremias Maerki wrote:

> Thanks to Victor and Andreas for helping me here, although 
> I'm still confused.
> 
> On 27.01.2005 00:25:27 Victor Mote wrote:
> > Andreas L. Delmelle wrote:
> > 
> > > Do you feel the contents of the block-container should 
> not be broken 
> > > up at all? (Hence the analogy to a fo:external-graphic?)
> > 
> > No, sorry, I didn't mean to imply that. I think the contents can 
> > (possibly, depending on the overflow constraints) be broken up, but 
> > that the viewport cannot be. So the analogy with external-graphic 
> > breaks down there. The similarity is in the fact that they (in this 
> > case) have a fixed size and must move in their entirety.
> 
> This seems to be contradicting. I don't see how the overflow 
> property would control such behaviour. Also, if you say that 
> they "must move in their entiretly", how can the contents be 
> broken up? Or does "they"
> refer to something else than the contents?
 
I'll try to clarify what I mean. A distinction must be made between the
viewport area(s)that are created by the block-container, which I will call
the container areas, and the areas that are generated by the children of the
block-container (block-level FOs), which I will call the child areas. Each
viewport area is a fixed size in the scenario described. It cannot be split
between columns or pages. If there is not room for it in its entirety on
page n, it must be moved in its entirety to page n + 1. However the child
areas are free to flow between the container areas, just like they would
flow between the main-reference-areas on two pages. So a block inside the
block-container might have part of its contents in one container area and
part in a subsequent one.

The overflow property enters in because of the "Issue" that you mentioned
(1.1 Standard, Section 6.5.3): "The overflow property applies to this
formatting object. There is a question of interpretation on whether the
fo:block-container generates more than one area when the
block-progression-dimension is fixed. The change proposed here
requires the user to specify the "repeat" value for the overflow property
when they want multiple instances of the block-container rather than the
initial value for overflow."

The default value for overflow is auto, which probably results in contents
being clipped for printed media (there being no opportunity for a
scroll-bar). But if the user sets the value to "repeat", additional content
areas can be created to contain the overflowed content. If the overflow
settings are such that overflowed content has no place to go, then
conceptually it all stays in the one container area, and is clipped. So the
setting of the overflow value on the block-container directly affects
whether those contents might be split between two container areas or simply
clipped.

You are correct that "they" in my original post did not refer to the child
areas, but rather to the container areas. My apologies for the ambiguity.

> > Yes. This seems most useful to me in cases where the viewport would 
> > occupy most or all of the main-reference-area, as in the 
> case of the 
> > report-turned-sideways example I gave earlier. Suppose you 
> have some 
> > unknown quantity of 132-column output you want to show in landscape 
> > mode. You can create a fixed-size block-container, tell it 
> to overflow 
> > into other ones, add a "break" constraint at the end of 
> each page, and 
> > you now get n pages of output.
> 
> Well, this is a case where I'd rather use a separate 
> page-sequence with the reference orientation set on the 
> simple-page-master.

Fair enough. Here are some things to consider:
1. I think using a block-container gives you the *potential* option of
letting the viewports be out-of-line areas. So your content might read: "See
Listing 1 , where the effects
of this ..." The content continues, but perhaps the next 3 pages are filled
with the block-container contents. I am not yet convinced that I fully grasp
all of the implications of the ordering issues, so it may be that this isn't
supported by the Standard.
2. What if the requirement is that 2 portrait "pages" be turned 90 degrees,
side-by-side, on the now landscape page? Depending on the amount of room on
the first page, and the parity of the number of such pages, you might end up
with an empty half-page. If your content needs to continue (as opposed to
looking like a new chapter), the repeating block-container looks like a good
option.

Victor Mote

Re: block-containers with BPD set

[Jeremias Maerki]

Thank you, Victor, now I think I finally understand what you mean.
However, I see is that this could lead to very funny results. Imagine a
BC with BPD set, overflow=repeat and reference-orientation=180. When the
contents overflow the first VPA, a new one is created under the first
(in BC parent's BP direction), if there's enough room for a second VPA
on the same reference area. If you looked at the paper upside down after
printing, it would look like this (the number indicate the order of the
blocks inside the BC):

5
6
7
8
1
2
3
4

Just for the fun of it. :-) I know it's a bit exotic.

I don't quite see the use-cases for this whole thing yet. But for XSL
1.0 it essentially means that there's only one VPA if the BPD is set,
right? So the current implementation in FOP would be ok for now.


Jeremias Maerki