Jeremias Maerki wrote: > I believe that font-stretch has to included just like > font-weight to select the actual font.
Sorry to be unclear. I understand that font-stretch must be included. The issue is whether the "wider" and "narrower" constraints can be processed in the FOTree by simply bumping the description up / down, or whether (as seems to be the case for font-weight) they must be resolved in the font system by looking at the actual fonts available. I originally read the spec to mean the latter, but I think Manuel reads the spec as the former. I am not sure which is right. If the latter is correct, then we will need to do something similar to what I have described for font-weight to handle the font-stretch relative values. > > For font-weight, there seems to be some ambiguity in the > standard(s). > > There are two possibilities, and neither CSS 2.1 nor XSL-FO seem to > > resolve the > > matter: > > > > 1. Apply "bolder" and "lighter" to the inherited font to compute a > > weight that is applied to the selected font. > > 2. Select the font, inheriting the weight from the inherited font, > > then applying "bolder" and "lighter" to that weight. > > I think this is really up to the user agent to define the > exact strategy as long as the "visual order" is preserved. OK. That is a third theory. > > This will allow the client application (FOP) to use whichever > > algorithm it thinks is appropriate. The bad news is that this ties > > each registered font to exactly one font-family, something > I was hoping to avoid. > > I got the impression that's what the spec tried to establish. Hmm. I have never seen such a thing explicitly. I have been working under the assumption that font A could be part of two font-families if a user wished to do so. (I am not sure why a user would want to do so -- this was just known to be possible with the data structured as it is). Thanks for your comments. Victor Mote
