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 bpd>0) 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 bpd>0) 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"
Andreas L Delmelle wrote: [blankety-blank-blanks stuff] Umm, emm, "blank" means no area at all on the page body, not even one with bpd=0. E.g. would create two non-blank pages. Or so I think. I probably have to revise the statement about the last page. I'm feeling somewhat blank now... J.Pietschmann
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. 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: 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
Negative half-leading trait?
In 6.5.2 it says: The .minimum, .optimum, and .maximum components of the half-leading trait are set to 1/2 the difference of the computed value of the line-height property and the computed value of the sum of the text-altitude and text-depth properties. The .precedence and .conditionality components are copied from the line-height property. If the line-height is smaller than the total text height we get a negative "half-leading" trait value. Is that a legal/sensible/plausible value or should it be forced to 0 in this case? For 2 of the 3 different line-stacking-strategies the half-leading trait becomes a space-before/after specifier on the line area and therefore becomes part of the space resolution algorithm. I assume negative values are OK in that case although I am not sure? Manuel
