Re: Another page-related question: page-position=last
Ah, so we need to define first, what we really want to expect. :-) Does the spec say anything about the expected behaviour? On 02.10.2005 00:57:07 J.Pietschmann wrote: Jeremias Maerki wrote: On 27.09.2005 16:38:23 Luca Furini wrote: [the usual layout oscillation/convergence problem] What is the expected output? In this case it has to generate a blank page IMO. The expected output is that there is some content (area with bpd0) on the last page, even if this sounds suboptimal. J.Pietschmann Jeremias Maerki
Re: Another page-related question: page-position=last
On Oct 3, 2005, at 16:11, Jeremias Maerki wrote: On 02.10.2005 00:57:07 J.Pietschmann wrote: Jeremias Maerki wrote: On 27.09.2005 16:38:23 Luca Furini wrote: [the usual layout oscillation/convergence problem] What is the expected output? In this case it has to generate a blank page IMO. The expected output is that there is some content (area with bpd0) on the last page, even if this sounds suboptimal. Ah, so we need to define first, what we really want to expect. :-) Does the spec say anything about the expected behaviour? I believe this can be (more or less) inferred from the fact that there are actually three sub-conditions, namely: page-position, odd-or-even and blank-or-not-blank. Given that: a) all three sub-conditions have to be true for the condition on the fo:conditional-page-master to be true (= to make it eligible for selection) b) the initial value for 'blank-or-not-blank' is 'any' Then I'd conclude that both the described expected outputs --blank page or one filled with some content-- are allowed in case there is no explicit blank-or-not-blank sub-condition specified on the fo:c-p-m in question (or an explicit any, which comes down to the same thing). If and only if you have a fo:c-p-m with both page-position=last and blank-or-not-blank=blank, the output of one blank last page is the only correct output. Same thing for Joerg's expectation, which is the only correct output in case you have page-position=last and blank-or-not-blank=not-blank. Note: in both cases I'm assuming this to be the only fo:c-p-m with a condition page-position=last. I'm not absolutely sure, so correct me if I'm wrong... For instance: I'm wondering whether the conditions *have* to be met, so that the layout-engine would, if necessary, have to perform all sorts of magic tricks to force the content to meet the criteria, or whether OTOH, the layout-engine only *has* to choose a particular fo:c-p-m if the criteria actually are met (?) Anyone? Cheers, Andreas
Re: Another page-related question: page-position=last
On Oct 3, 2005, at 21:22, J.Pietschmann wrote: Umm, emm, blank means no area at all on the page body, not even one with bpd=0. E.g. fo:flow ... fo:block/ fo:block break-before=page/ /fo:flow would create two non-blank pages. Or so I think. I see and fully agree, but IIRC, one of the ideas was to create a sort of dummy-area (internally, not corresponding to a FO in the document), so that the last page-master would always be used, even if the next-to-last page can hold all of the remaining content at a given point. AFAICT, this would *only* be acceptable if the page-master in question doesn't have an explicit non-blank constraint. In any case, you're right about the above example generating two non-blank (yet empty) pages. So, a page-master with explicit blank constraint can never be used for either of them. But now, I'm still wondering about the last question in my earlier post... :-/ If we have: fo:conditional-page-master page-position=last blank-or-not-blank=not-blank a) Does this page-master have to be used, period? (= If there are no areas left to fill up the last page, layout needs to backtrack in order to satisfy both conditions.) b) Does it have to be used only in case both criteria are met at the same time? (= If there are no areas left to fill up an eventual last page, then this page-master is simply never eligible for selection.) I'm inclined to believe b), but again, not absolutely --or: absolutely not-- certain about this... Make it page-position=last and odd-or-even=odd: does that mean that we have to make sure that the page-sequence always contains an odd number of pages, or that that page-master is eligible for selection only if the last page turns out to have an odd number? Cheers, Andreas
Re: More style issues
Jeremias Maerki wrote: But I'll never define a variable called blockProgressionDimension! I was after weirder stuff. Some random picks: - availIPD (but availableBPD used elsewhere) - avgWidth (but averageLineLength used elsewhere) - bHyph (but hyphen/hyphenate/hyphenation used lesewhere) - bInWS - bSuppressLastPar - backProps (but backgroundNNN used elsewhere) - baseProp (but baseProperty used elsewhere) - bfentries - bpdim - bufin - cbout - cfvals - cmpnValue - contentPosIter (but contentListIterator used elsewhere) - curCharIter, but currParIterator - curTxf - currentGU - currentPageG - currentPageNum (but currentPageNumber used elsewhere) - currentloc - cycenum - dbuf - decoData - defG - descPList: description? descendant? descartes? - dur - effBorders (but effectiveAlignment used elsewhere) - elem (but element used elsewhere) - embFile (but embedFile used elsewhere) - equivChar - errMsg - etmXHeight - extGState - fnSeparatorLength (but footnoteNNN used elsewhere) - getAllocIPD (but getAllocationIPD used elsewhere) - getBBox - getCCL - getColSpanIndex (but getColumnRowSpanningAttrs used elsewhere) - getCurrentPV - getKE - getLM (but getLayoutManager used elsewhere) - getLsb - getP - getRefIPD (but getReferenceAreaIPD used elsewhere) - getSPM - getStemV - grn - guSpan - hasTextDeco - horzSpan - htPropNames - iTWSadjust - inl - intbl - ipdWidth (ultimate weirdness!) - kpx1 - lastLoca - leadingSS - ledd2 - longHorMetricSize - lvlInCntr - mtxPtr - myShad - numLen - offDocumentItems - paddingPt - pgNbField - pixSzMM - propEx - relbase (but relativebase used elsewhere) - resSpace: reserved? resolved? reset? randomly enhanced space? - rightPadStr - rslt - setDW - setDoOutput - sPM - spMaker - trIter - transFactory - uniMap - xRefFormats HTH J.Pietschmann
