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 Vincent Hennebert <vi...@anyware-tech.com> on 2007/03/13 09:50:01 UTC
Re: How could I change vertical alignment of list item bullet? [was
in fop-user]
[Moving to fop-dev as we're going to speak about implementation details]
Andrejus Chaliapinas a écrit :
> Hi Jeremias,
>
>> I've just checked since I was curious. It's already in 0.90. Seems to
>> have to do with font metrics. Take a look at the Area Tree XML. The
>> label has a BPD of 18936 while the body has 14400. Symbol has an
>> ascender of 1010 while Helvetica has 718.
>>
>> Smells like a need for implementing relative-align="baseline" to me.
>>
>> Jeremias Maerki
>
> Would it be hard to fix? Should I try that myself (hmm, not so easy) or
> someone else could take a look on that?
In theory no; in practice...
I'm not familiar with the inline part of the layout code, but as I've
been having this idea in the head for some time, I thought I might use
this opportunity to explain it. Inline specialists, please correct me if
I'm wrong.
AFAIK there is no information about the distance of the baseline from
the before-edge of an area. A quick small picture:
------------------------ <-- before-edge of the area
| |
| First line of text. | <-- "base-line" of the area
| Second line of text. | (= baseline of the first line)
| |
| |
| |
------------------------
If we had that information for each area, then this would be easy to
implement relative-align I think.
That would imply to change almost every LayoutManager to
compute/transfer this information. Quite a bit of work.
Andrejus, if you want to give it a try, you're welcome ;-) We would be
glad to help you find your way in the code. But, granted, that's perhaps
not the easiest way to get involved into FOP's development.
What do others think?
Vincent
RE: How could I change vertical alignment of list item bullet? [was in fop-user]
Posted by Andrejus Chaliapinas <a....@infosana.com>.
>
> Silly me, overcomplicated the situation. You are spot on Vincent and it
> actually works. Writing
> <fo:list-item-label end-indent="label-end()">
> <fo:block line-stacking-strategy="font-height"><fo:inline
> font-family="Symbol">•</fo:inline></fo:block>
> </fo:list-item-label>
> actually positions the bullet just fine.
>
> Thanks for that
>
> Manuel
Yes, this looks better in output comparing to previous case. Thank you for
providing that snippet.
Andrejus
Re: How could I change vertical alignment of list item bullet? [was in fop-user]
Posted by Manuel Mall <mm...@arcus.com.au>.
On Tuesday 13 March 2007 23:11, Vincent Hennebert wrote:
> Hi Manuel,
>
> Manuel Mall a écrit :
> > On Tuesday 13 March 2007 17:50, Vincent Hennebert wrote:
<snip/>
> > What concerns me more ATM is the question if we actually deal with
> > the font metrics, baselines, alignment correctly. The metrics of
> > the Base14 Symbol font have the Ascender/Descender actually
> > exceeding the fonts EM box (Ascender + Descender > 1000). This
> > causes the growth in line height for lines containing Symbol font
> > inlines. Is this the right thing to do? Or should we cap the line
> > height at the EM box height and larger characters just protrude.
> > Not sure if the spec actually deals with that. Would need to dig
> > into this again. Growl....
>
> ... IIUC that's the purpose of the line-stacking-strategy. I've never
> had enough energy to try and grasp every detail of this part of the
> spec, but I'd say that in the case of "font-height" the line height
> would depend on the font's em box and thus larger characters would
> protrude, and in the case of "max-height" they would not.
>
Silly me, overcomplicated the situation. You are spot on Vincent and it
actually works. Writing
<fo:list-item-label end-indent="label-end()">
<fo:block line-stacking-strategy="font-height"><fo:inline
font-family="Symbol">•</fo:inline></fo:block>
</fo:list-item-label>
actually positions the bullet just fine.
> WDYT?
> Vincent
Thanks for that
Manuel
Re: How could I change vertical alignment of list item bullet? [was in fop-user]
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Mar 13, 2007, at 14:51, Manuel Mall wrote:
> On Tuesday 13 March 2007 17:50, Vincent Hennebert wrote:
> <snip />
>> That would imply to change almost every LayoutManager to
>> compute/transfer this information. Quite a bit of work.
>>
> Yes, but I think for slightly different reason. The logic (in the case
> of lists) to support relative-align would have to be in the
> ListItemLM.
> After doing the line breaking (getNextKnuth...) for both the item
> label
> and the item body the ListItemLM would need to get to the first
> line of
> both subordinates (via the first Knuth element of each of the lists
> returned?), compare their heights and baselines, signal adjustments
> down to the relevant InlineLevel LMs and adjust the already generated
> Knuth element for page breaking to the new line height. I guess a
> similar logic would need to apply to support relative-align for table
> cells, i.e. it would reside at row level.
FWIW: this would be much more straightforward to handle with
Vincent's idea of merging page- and line-breaking, and my idea to use
endBlock() as a start/resume trigger for this combined algorithm
(supposing they're both feasible ideas, of course...)
As such, the end of the block in the list-item-label would then give
the higher level ListItemLM the chance to determine the label's
baseline/line-height/BPD *before* the block(s) in the list-item-body
pass through the breaking-algorithm.
As a consequence, I'm not so sure whether it would make much sense to
hack it in as a modification to every LM. The LMs and the interaction
between FO tree and layoutengine need to be revisited anyway to
address other issues (large page-sequences, alternating IPD, optimal
start-/end-float placement, etc.)
Just my 2 cents...
Cheers,
Andreas
Re: How could I change vertical alignment of list item bullet? [was
in fop-user]
Posted by Vincent Hennebert <vi...@anyware-tech.com>.
Hi Manuel,
Manuel Mall a écrit :
> On Tuesday 13 March 2007 17:50, Vincent Hennebert wrote:
>> [Moving to fop-dev as we're going to speak about implementation
>> details]
>>
>> Andrejus Chaliapinas a écrit :
>>> Hi Jeremias,
>>>
>>>> I've just checked since I was curious. It's already in 0.90. Seems
>>>> to have to do with font metrics. Take a look at the Area Tree XML.
>>>> The label has a BPD of 18936 while the body has 14400. Symbol has
>>>> an ascender of 1010 while Helvetica has 718.
>>>>
>>>> Smells like a need for implementing relative-align="baseline" to
>>>> me.
>>>>
>>>> Jeremias Maerki
>>> Would it be hard to fix? Should I try that myself (hmm, not so
>>> easy) or someone else could take a look on that?
>> In theory no; in practice...
>> I'm not familiar with the inline part of the layout code, but as I've
>> been having this idea in the head for some time, I thought I might
>> use this opportunity to explain it. Inline specialists, please
>> correct me if I'm wrong.
>>
>> AFAIK there is no information about the distance of the baseline from
>> the before-edge of an area. A quick small picture:
>>
>> ------------------------ <-- before-edge of the area
>>
>> | First line of text. | <-- "base-line" of the area
>> | Second line of text. | (= baseline of the first line)
>>
>> ------------------------
>>
>> If we had that information for each area, then this would be easy to
>> implement relative-align I think.
>>
>
> I believe that information is available. If you look at the area tree
> generated every text element has a baseline value which is the offset
> from the before edge.
>
>> That would imply to change almost every LayoutManager to
>> compute/transfer this information. Quite a bit of work.
>>
> Yes, but I think for slightly different reason. The logic (in the case
> of lists) to support relative-align would have to be in the ListItemLM.
> After doing the line breaking (getNextKnuth...) for both the item label
> and the item body the ListItemLM would need to get to the first line of
> both subordinates (via the first Knuth element of each of the lists
> returned?), compare their heights and baselines, signal adjustments
> down to the relevant InlineLevel LMs and adjust the already generated
> Knuth element for page breaking to the new line height. I guess a
> similar logic would need to apply to support relative-align for table
> cells, i.e. it would reside at row level.
Interesting. I'll try to comment on this later. Just a quick note for
the moment...
>> Andrejus, if you want to give it a try, you're welcome ;-) We would
>> be glad to help you find your way in the code. But, granted, that's
>> perhaps not the easiest way to get involved into FOP's development.
>>
>> What do others think?
>
> What concerns me more ATM is the question if we actually deal with the
> font metrics, baselines, alignment correctly. The metrics of the Base14
> Symbol font have the Ascender/Descender actually exceeding the fonts EM
> box (Ascender + Descender > 1000). This causes the growth in line
> height for lines containing Symbol font inlines. Is this the right
> thing to do? Or should we cap the line height at the EM box height and
> larger characters just protrude. Not sure if the spec actually deals
> with that. Would need to dig into this again. Growl....
... IIUC that's the purpose of the line-stacking-strategy. I've never
had enough energy to try and grasp every detail of this part of the
spec, but I'd say that in the case of "font-height" the line height
would depend on the font's em box and thus larger characters would
protrude, and in the case of "max-height" they would not.
WDYT?
Vincent
Re: How could I change vertical alignment of list item bullet? [was in fop-user]
Posted by Manuel Mall <mm...@arcus.com.au>.
On Tuesday 13 March 2007 17:50, Vincent Hennebert wrote:
> [Moving to fop-dev as we're going to speak about implementation
> details]
>
> Andrejus Chaliapinas a écrit :
> > Hi Jeremias,
> >
> >> I've just checked since I was curious. It's already in 0.90. Seems
> >> to have to do with font metrics. Take a look at the Area Tree XML.
> >> The label has a BPD of 18936 while the body has 14400. Symbol has
> >> an ascender of 1010 while Helvetica has 718.
> >>
> >> Smells like a need for implementing relative-align="baseline" to
> >> me.
> >>
> >> Jeremias Maerki
> >
> > Would it be hard to fix? Should I try that myself (hmm, not so
> > easy) or someone else could take a look on that?
>
> In theory no; in practice...
> I'm not familiar with the inline part of the layout code, but as I've
> been having this idea in the head for some time, I thought I might
> use this opportunity to explain it. Inline specialists, please
> correct me if I'm wrong.
>
> AFAIK there is no information about the distance of the baseline from
> the before-edge of an area. A quick small picture:
>
> ------------------------ <-- before-edge of the area
>
> | First line of text. | <-- "base-line" of the area
> | Second line of text. | (= baseline of the first line)
>
> ------------------------
>
> If we had that information for each area, then this would be easy to
> implement relative-align I think.
>
I believe that information is available. If you look at the area tree
generated every text element has a baseline value which is the offset
from the before edge.
> That would imply to change almost every LayoutManager to
> compute/transfer this information. Quite a bit of work.
>
Yes, but I think for slightly different reason. The logic (in the case
of lists) to support relative-align would have to be in the ListItemLM.
After doing the line breaking (getNextKnuth...) for both the item label
and the item body the ListItemLM would need to get to the first line of
both subordinates (via the first Knuth element of each of the lists
returned?), compare their heights and baselines, signal adjustments
down to the relevant InlineLevel LMs and adjust the already generated
Knuth element for page breaking to the new line height. I guess a
similar logic would need to apply to support relative-align for table
cells, i.e. it would reside at row level.
> Andrejus, if you want to give it a try, you're welcome ;-) We would
> be glad to help you find your way in the code. But, granted, that's
> perhaps not the easiest way to get involved into FOP's development.
>
> What do others think?
What concerns me more ATM is the question if we actually deal with the
font metrics, baselines, alignment correctly. The metrics of the Base14
Symbol font have the Ascender/Descender actually exceeding the fonts EM
box (Ascender + Descender > 1000). This causes the growth in line
height for lines containing Symbol font inlines. Is this the right
thing to do? Or should we cap the line height at the EM box height and
larger characters just protrude. Not sure if the spec actually deals
with that. Would need to dig into this again. Growl....
> Vincent
Manuel