Re: block-containers with BPD set

2005-01-27 Thread 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?

snip/

  (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

2005-01-27 Thread 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

2005-01-27 Thread 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] - http://homepage.mac.com/webmaestro/
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet


RE: block-containers with BPD set

2005-01-27 Thread 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): pThe 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./p pThe 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./p

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 fo:block-container ... /fo:block-container, 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

2005-01-27 Thread 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