Re: block-containers with BPD set
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
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
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
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
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
