baseline-shift and KnuthInlineBoxes

2005-09-16 Thread Manuel Mall
This is probably a question for Luca.

if we have a baseline-shift, eg.

some X2 ...

how is that intended to be modelled with respect to the lead,height, and 
middle values to be stored in the created KnuthInlineBoxes for the 
fo:inline?

Thanks

Manuel


Re: baseline-shift and KnuthInlineBoxes

2005-09-16 Thread Luca Furini

Manuel Mall wrote:


if we have a baseline-shift, eg.

some Xbaseline-shift="super">2 ...


how is that intended to be modelled with respect to the lead,height, and 
middle values to be stored in the created KnuthInlineBoxes for the 
fo:inline?


I think that more (or different) information needs to be stored in the 
KnuthInlineBoxes in order to fully implement the properties concerning the 
vertical positioning of objects.


Lead, total and middle are only enough to handle vertical-align = top, 
bottom or middle; anyway, maybe three attributes could be enough: one 
identifying the alignment baseline (alphabetic, ideographic, 
text-before-edge, ...) and two specifying the box heigth above and below 
this baseline.


The LineLM should look at these values when creating the lines: each box 
height will be interpreted differently according to its baseline: I think 
this will be the tricky part of this work!


HTH, even if it' not much :-)

Regards
Luca




Re: baseline-shift and KnuthInlineBoxes

2005-09-16 Thread Manuel Mall
On Fri, 16 Sep 2005 07:10 pm, Luca Furini wrote:
> Manuel Mall wrote:
> > if we have a baseline-shift, eg.
> >
> > some X > baseline-shift="super">2 ...
> >
> > how is that intended to be modelled with respect to the
> > lead,height, and middle values to be stored in the created
> > KnuthInlineBoxes for the fo:inline?
>
> I think that more (or different) information needs to be stored in
> the KnuthInlineBoxes in order to fully implement the properties
> concerning the vertical positioning of objects.

I was afraid that would be the case.

>
> Lead, total and middle are only enough to handle vertical-align =
> top, bottom or middle; anyway, maybe three attributes could be
> enough: one identifying the alignment baseline (alphabetic,
> ideographic, text-before-edge, ...) and two specifying the box heigth
> above and below this baseline.

Not sure that would be enough. Its the baseline-shift that worries me. 
The system also has to cater for multiple levels of nested 
fo:inline/fo:character with changing baseline tables while exposing all 
this (in some form) up to the Line LM so it can calculate the proper 
line dimensions.

From my POV this needs quite a bit more thought and spec reading (this 
seems to become my pasttime now - don't read a good book - no, read the 
spec - again). Looks like we won't get sub/superscripts in a hurry as I 
want to tidy up other things first (still waiting for my apache 
account, so I can commit the changes accumulating here) before 
attacking this and trying to implement all the alignment stuff.

Would be really nice to get some wider variety of fonts to play with. 
May be including some unusual scripts with strange baselines. Do we 
need something like OFFO for fonts, i.e. a repository of open licensed 
but incompatible with Apache license fonts already converted for use 
with fop?

>
> The LineLM should look at these values when creating the lines: each
> box height will be interpreted differently according to its baseline:
> I think this will be the tricky part of this work!
>
> HTH, even if it' not much :-)

yeah, good one :-) I am still wondering what I let myself in for by 
joining this party.

>
> Regards
>  Luca
Regards

Manuel


Re: baseline-shift and KnuthInlineBoxes

2005-09-16 Thread Simon Pepping
On Fri, Sep 16, 2005 at 09:42:01PM +0800, Manuel Mall wrote:
> On Fri, 16 Sep 2005 07:10 pm, Luca Furini wrote:
> > Manuel Mall wrote:
> Would be really nice to get some wider variety of fonts to play with. 
> May be including some unusual scripts with strange baselines. Do we 
> need something like OFFO for fonts, i.e. a repository of open licensed 
> but incompatible with Apache license fonts already converted for use 
> with fop?

OFFO could easily host FOP-specific tables for such fonts. It could
also maintain a list of such fonts. I am not sure it should host such
fonts itself, but it could if there is a good reason.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl