vertical-align vs baseline alignment properties

[Manuel Mall <mm...@arcus.com.au>]

As a consequence of the recent discussion on the correct bpd for inline 
areas I was looking at actually implementing it. Part of that is 
correct vertical positioning, i.e. baseline alignments, of those areas.

Am I correct in saying that the vertical-align property which is a 
shorthand for a combination of baseline related properties is not 
currently implemented as shorthand, that is the property system doesn't 
do the mapping to the corresponding properties (alignment-baseline, 
alignment-adjust, baseline-shift and dominant-baseline)?

Also those 4 properties, while set on the various fo's, don't seem to 
have getters so are not available to the layout system.

So, the first step in moving away from vertical-align and to the four 
corresponding properties is to fix the property subsystem and the fo 
definitions.

Finn, the property system already has a notion of corresponding 
properties, etc.. I haven't looked into it in any detail but can that 
be used for the mapping of vertical-align or do we need some custom 
mechanism in this case?

Manuel

Re: vertical-align vs baseline alignment properties

[Manuel Mall <mm...@arcus.com.au>]

On Wed, 14 Sep 2005 08:40 pm, Finn Bock wrote:
> [Manuel]
>
<snip/>
> There is also explicit support shorthands. For the 4 properties the
> vertical-align must be specified as a shorthand:
>
> m.addShorthand(s_generics[PR_VERTICAL_ALIGN]);
>
> and a new custom ShorthandParser must be written and added to the
> vertical-align maker
>
> m.setDatatypeParser(new VerticalAlignShorthandParser());
>
> which consist of code to implement the rule in [7.29.22]:
>
<snip/>

Finn, thanks - consider it done!
> regards,
> finn

Manuel

Re: vertical-align vs baseline alignment properties

[Finn Bock <bc...@worldonline.dk>]

[Manuel]

> As a consequence of the recent discussion on the correct bpd for inline 
> areas I was looking at actually implementing it. Part of that is 
> correct vertical positioning, i.e. baseline alignments, of those areas.
> 
> Am I correct in saying that the vertical-align property which is a 
> shorthand for a combination of baseline related properties is not 
> currently implemented as shorthand, that is the property system doesn't 
> do the mapping to the corresponding properties (alignment-baseline, 
> alignment-adjust, baseline-shift and dominant-baseline)?

Correct.

> Also those 4 properties, while set on the various fo's, don't seem to 
> have getters so are not available to the layout system.
>
> So, the first step in moving away from vertical-align and to the four 
> corresponding properties is to fix the property subsystem and the fo 
> definitions.

Correct.

> Finn, the property system already has a notion of corresponding 
> properties, etc.. I haven't looked into it in any detail but can that 
> be used for the mapping of vertical-align or do we need some custom 
> mechanism in this case?

There is also explicit support shorthands. For the 4 properties the 
vertical-align must be specified as a shorthand:

m.addShorthand(s_generics[PR_VERTICAL_ALIGN]);

and a new custom ShorthandParser must be written and added to the 
vertical-align maker

m.setDatatypeParser(new VerticalAlignShorthandParser());

which consist of code to implement the rule in [7.29.22]:

if (property.getEnum() == EN_BASELINE)
     switch (propId) {
     case PR_ALIGNMENT_BASELINE:
	return new EnumProperty(EN_BASELINE)
     case PR_ALIGNMAENT_ADJUST:
	return new EnumProperty(EN_AUTO)
     case PR_BASELINE_SHIFT:
	return new EnumProperty(EN_BASELINE)
     case PR_DOMINENT_BASELINE:
	return new EnumProperty(EN_AUTO)
     }
} else property.getEnum() == EN_TOP) {
     switch (propId) {
     case PR_ALIGNMENT_BASELINE:
	return new EnumProperty(EN_BEFORE_EDGE)
     case PR_ALIGNMAENT_ADJUST:
	return new EnumProperty(EN_AUTO)
     case PR_BASELINE_SHIFT:
	return new EnumProperty(EN_BASELINE)
     case PR_DOMINENT_BASELINE:
	return new EnumProperty(EN_AUTO)
     }
....



As an aside, the FOP implementation deviates from the spec since 
shorthands should set values for other properties, but our system pulls 
the values out of the shorthand property with the help of a ShorthandParser.

regards,
finn