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 Manuel Mall <mm...@arcus.com.au> on 2005/09/28 06:11:40 UTC
alignment-adjust property
This is another of those spec interpretation questions. Sorry to
populate this list with so many of these questions but this is a source
of real irritation for me in the moment. I just want to get
sub/superscripts working and do it properly and I am hitting all these
"murky" (as Peter put it) things in the spec.
Here we go again. In 7.13 the spec defines the various baselines. In
that section it says: "There are, in addition, two computed baselines
that are only defined for line areas." and then goes on about those two
baselines being "before-edge" and "after-edge".
We then come to 7.13.1 alignment-adjust and "before-edge" and
"after-edge" are valid values. However, the alignment-adjust property
applies only to inline fo's. And inline fo's don't generate line areas.
As the alignment-adjust property applies to the area generated by the
fo (not like the alignment-baseline property which applies to the
parent area) none of the areas generated by the fo's in question will
have those baselines defined. The text also implies that i-f-o and and
e-g have the "after-edge" as their dominant baseline. For the "auto"
setting we are allowed to use heuristics to determine where the
baseline is but that option is not open to the other values. So, what's
the point of having "before-edge", "after-edge" as allowed values if
those baselines are guaranteed not to be defined (and even use them as
default for e-g and i-f-o)?
Manuel
Re: alignment-adjust property
Posted by Manuel Mall <mm...@arcus.com.au>.
On Wed, 28 Sep 2005 03:17 pm, Jeremias Maerki wrote:
> I read it like this: The areas generated by inlines are always
> children of line areas. Since only line areas can define the
> before-edge and after edge baselines, areas generated by inlines have
> to retrieve these two baselines from their parent line area. I
> believe this is some kind of implied inheritance. Disclaimer: I
> haven't studied the whole topic!
>
Jeremias, this doesn't quite gel with me as I don't think inheritance
can be involved. alignment-adjust is about answering the question:
Where is my alignment-point within the area(s) I am generating.
This question cannot (IMO) be answered relative to inherited baseline
tables (some of those inherited baselines may even be well outside of
the area the fo in question is generating).
> On 28.09.2005 06:11:40 Manuel Mall wrote:
> > This is another of those spec interpretation questions. Sorry to
> > populate this list with so many of these questions but this is a
> > source of real irritation for me in the moment. I just want to get
> > sub/superscripts working and do it properly and I am hitting all
> > these "murky" (as Peter put it) things in the spec.
> >
> > Here we go again. In 7.13 the spec defines the various baselines.
> > In that section it says: "There are, in addition, two computed
> > baselines that are only defined for line areas." and then goes on
> > about those two baselines being "before-edge" and "after-edge".
> >
> > We then come to 7.13.1 alignment-adjust and "before-edge" and
> > "after-edge" are valid values. However, the alignment-adjust
> > property applies only to inline fo's. And inline fo's don't
> > generate line areas. As the alignment-adjust property applies to
> > the area generated by the fo (not like the alignment-baseline
> > property which applies to the parent area) none of the areas
> > generated by the fo's in question will have those baselines
> > defined. The text also implies that i-f-o and and e-g have the
> > "after-edge" as their dominant baseline. For the "auto" setting we
> > are allowed to use heuristics to determine where the baseline is
> > but that option is not open to the other values. So, what's the
> > point of having "before-edge", "after-edge" as allowed values if
> > those baselines are guaranteed not to be defined (and even use them
> > as default for e-g and i-f-o)?
> >
> > Manuel
>
> Jeremias Maerki
Manuel
Re: alignment-adjust property
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
I read it like this: The areas generated by inlines are always children
of line areas. Since only line areas can define the before-edge and
after edge baselines, areas generated by inlines have to retrieve these
two baselines from their parent line area. I believe this is some kind
of implied inheritance. Disclaimer: I haven't studied the whole topic!
On 28.09.2005 06:11:40 Manuel Mall wrote:
> This is another of those spec interpretation questions. Sorry to
> populate this list with so many of these questions but this is a source
> of real irritation for me in the moment. I just want to get
> sub/superscripts working and do it properly and I am hitting all these
> "murky" (as Peter put it) things in the spec.
>
> Here we go again. In 7.13 the spec defines the various baselines. In
> that section it says: "There are, in addition, two computed baselines
> that are only defined for line areas." and then goes on about those two
> baselines being "before-edge" and "after-edge".
>
> We then come to 7.13.1 alignment-adjust and "before-edge" and
> "after-edge" are valid values. However, the alignment-adjust property
> applies only to inline fo's. And inline fo's don't generate line areas.
> As the alignment-adjust property applies to the area generated by the
> fo (not like the alignment-baseline property which applies to the
> parent area) none of the areas generated by the fo's in question will
> have those baselines defined. The text also implies that i-f-o and and
> e-g have the "after-edge" as their dominant baseline. For the "auto"
> setting we are allowed to use heuristics to determine where the
> baseline is but that option is not open to the other values. So, what's
> the point of having "before-edge", "after-edge" as allowed values if
> those baselines are guaranteed not to be defined (and even use them as
> default for e-g and i-f-o)?
>
> Manuel
Jeremias Maerki
Re: alignment-adjust property
Posted by "Peter B. West" <pb...@pbw.id.au>.
Manuel Mall wrote:
> This is another of those spec interpretation questions. Sorry to
> populate this list with so many of these questions but this is a source
> of real irritation for me in the moment. I just want to get
> sub/superscripts working and do it properly and I am hitting all these
> "murky" (as Peter put it) things in the spec.
>
Don't apologise for actually reading the Recommendation, and thinking
about it. The fact is that there is not enough of that done by those
who are "implementing" the Recommendation, as evidenced by the existence
of these bugs in the document. No matter what the interpretation,
7.13.1 and 7.13.2 have editorial bugs which need to be clarified. Think
about it. How many commercial implementations are out there? The same
bugs are still present in the 1.1 draft. (See Section 7.14).
You found it, so you get to write to the editors. If you are
apprehensive about that, talk to me further off-list, or to Glen (who
has communicated quite a lot with the editors, and who has popped up
again) or Victor.
Peter
--
Peter B. West <http://cv.pbw.id.au/>
Folio <http://defoe.sourceforge.net/folio/>