Re: alignment-adjust property
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
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/ smime.p7s Description: S/MIME Cryptographic Signature
Re: alignment-adjust property
On Wed, 28 Sep 2005 06:03 pm, Peter B. West wrote: 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, thanks for the encouragement. I am happy to write to the editors. And yes, as I am fairly new to this (in the sense of delving into the depth of spec) I am using this mailing list as a sounding board first because I am still apprehensive about generating noise / garbage or whatever you want to call it due to being a newbie and possibly not understanding something which to someone with more experience would be obvious. Peter Manuel
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
