You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Glen Mazza <gm...@apache.org> on 2005/05/05 06:00:56 UTC

iStartOn = break-before?

Team,

The AbstractBreaker.BlockSequence has an "iStartOn" property, that from 
looking at PSLM, quite possibly just means the "break-before" trait.  
Are they synonyms?  I would like us to use the official Rec term if at 
all possible.

Thanks,
Glen



    public class BlockSequence extends KnuthSequence {

        private int startOn;

        public BlockSequence(int iStartOn) {
            super();
            startOn = iStartOn;
        }
   .....

Re: iStartOn = break-before?

Posted by Glen Mazza <gm...@apache.org>.
OK, I'll update the variable with a comment explaining its meaning.

Thanks,
Glen

Jeremias Maerki wrote:

>Using the official terms is usually a good idea but in this instance I'd
>leave it like it is. It's not just the break-before value. The value for
>startOn can also come from a break-after property. It simply indicates
>for a BlockSequence on what kind of page it should start after
>normalizing where the value originally came from (break-after or
>break-before). IMO using "break-before" here would actually be confusing
>and startOn is more descriptive.
>
>On 05.05.2005 06:00:56 Glen Mazza wrote:
>  
>
>>Team,
>>
>>The AbstractBreaker.BlockSequence has an "iStartOn" property, that from 
>>looking at PSLM, quite possibly just means the "break-before" trait.  
>>Are they synonyms?  I would like us to use the official Rec term if at 
>>all possible.
>>
>>Thanks,
>>Glen
>>
>>
>>
>>    public class BlockSequence extends KnuthSequence {
>>
>>        private int startOn;
>>
>>        public BlockSequence(int iStartOn) {
>>            super();
>>            startOn = iStartOn;
>>        }
>>   .....
>>    
>>
>
>
>
>Jeremias Maerki
>
>
>  
>


Re: iStartOn = break-before?

Posted by Jeremias Maerki <de...@greenmail.ch>.
Using the official terms is usually a good idea but in this instance I'd
leave it like it is. It's not just the break-before value. The value for
startOn can also come from a break-after property. It simply indicates
for a BlockSequence on what kind of page it should start after
normalizing where the value originally came from (break-after or
break-before). IMO using "break-before" here would actually be confusing
and startOn is more descriptive.

On 05.05.2005 06:00:56 Glen Mazza wrote:
> Team,
> 
> The AbstractBreaker.BlockSequence has an "iStartOn" property, that from 
> looking at PSLM, quite possibly just means the "break-before" trait.  
> Are they synonyms?  I would like us to use the official Rec term if at 
> all possible.
> 
> Thanks,
> Glen
> 
> 
> 
>     public class BlockSequence extends KnuthSequence {
> 
>         private int startOn;
> 
>         public BlockSequence(int iStartOn) {
>             super();
>             startOn = iStartOn;
>         }
>    .....



Jeremias Maerki


RE: iStartOn = break-before?

Posted by "Andreas L. Delmelle" <a_...@pandora.be>.
> -----Original Message-----
> From: Glen Mazza [mailto:gmazza@apache.org]
>

Hi,

> The AbstractBreaker.BlockSequence has an "iStartOn" property, that from
> looking at PSLM, quite possibly just means the "break-before" trait.
> Are they synonyms?

Not really. I seem to agree with Jeremias here, in that iStartOn's _value_
is indeed the same type as that of the trait --Constants.EN_PAGE,
.EN_COLUMN...-- but, in the context of the BlockSequence this value is used
to represent what kind of (sub)page the first element should be layed out
on.
(IIUC: the break itself is already _there_ at that point, and iStartOn is
passed to handleBreak() to check if additional pageVP's need to be created
or the flow's column index needs to be incremented...)

So IMO naming it breakBefore would be misleading here.

> I would like us to use the official Rec term if at
> all possible.

I'm also very much in favor of this idea, however, that's all very easy when
it comes to the FOTree and the AreaTree, but it seems that whatever's in
between is left up to the implementation...

Cheers,

Andreas