On Fri, 26 Aug 2005 10:35 pm, Vincent Hennebert wrote:
> Victor Mote a écrit :
> > I am ignoring font-stretch for now. I am unclear whether it works
> > similarly to font-weight, or whether it is totally resolvable in
> > the FO Tree. Interestingly, CSS 2.1 (the only version of CSS 2
> > still available at W3C) removes font-stretch entirely!!??!!
>
> As I understand the spec, this works differently from font-weight and
> can be resolved in the FO Tree: just select the next expanded value
> for "wider" or next condensed for "narrower". The font selection
> would be performed only after, when it is time to decide e.g. which
> font the keyword "semi-expanded" matches. That's true that it is an
> extra-feature that IMO can be simulated with a good font
> configuration file.
>
I am with Vincent on this one. Here is the text for "wider" from the 
spec ("smaller" is defined the same way): 
The relative keyword "wider" sets the value to the next expanded value 
above the inherited value (while not increasing it above 
"ultra-expanded").

Note how it refers to setting the value of the property. No reference to 
the font selection process.

Now contrast that to the definition of "bolder" in the spec: 
Specifies the next weight that is assigned to a font that is darker than 
the inherited one. If there is no such weight, it simply results in the 
next darker numerical value (and the font remains unchanged), unless 
the inherited value was "900", in which case the resulting weight is 
also "900".

Here it talks about weights assigned to fonts, etc.. 

The two mechanisms sound quite different to me.

> > 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'd go with 1. Get the inherited font; find a darker one in the fonts
> database; get its weight value. That's it.
>
> > In order to move forward, I suggest the addition of the following
> > methods in org.axsl.font.Font:
> >
> >     public byte nextBolderWeight();
> >     public byte nextLighterWeight();
> >     public org.axsl.font.Font nextBolderFont();
> >     public org.axsl.font.Font nextLighterFont();
> >
> > 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.
>
> That seems OK.
> The only interest I see for a font to belong to several families is
> when there is a specific family (Times, Helvetica) and a generic one
> (serif, sans-serif...). In this case a generic family would be mapped
> to a specific one, and I don't think your proposed methods prevents
> that. Otherwise I don't see much interest to mix several families to
> build a complete set. The result would be visually bad IMO.
> I may have missed something: I haven't studied that point yet.
>
> > There is another area complexity in font selection that has not yet
> > been addressed, so I pose it here to Vincent and Manuel especially,
> > and to any others who wish to comment. The whole issue of whether
> > the Font has a glyph for the character(s) has not yet been
> > addressed. The best idea I have for this is as follows:
> >
> > 1. Add a char to the signature of
> > org.axsl.font.FontServer.selectFont. This char represents the first
> > char of the text for which the font is being selected. This allows
> > the selection process to pass by a font-family if it cannot paint
> > the character.
>
> So let's assume that I have a line of text to render. IIUC I would
> use it like this: * first call with the first char of the text to get
> the font that will be generally used
> * an additional call for each character for which there is no glyph
> in the general font
> Is that what you mean?
>
> > 2. Add the following method to org.axsl.font.Font:
> >     /**
> >      * Examines each character in string to ensure that a glyph
> > exists in the font for that
> >      * character. If a character has no glyph in the font, the
> > character's index in string
> >      * is returned.
> >      * @return The index in string of its first character for which
> > no glyph exists in this
> >      * font. If all characters in the string have glyphs in this
> > font, -1 is returned.
> >      */
> >     public int unavailableChar(String string);
> >
> >     Add also an overridden version of this method with char[] as
> > the parameter.
>
> Why not directly return an array of all indexes where there is a
> missing glyph? Or add a beginIndex parameter so that one doesn't have
> to artificially recreate a String made of the initial String minus
> all characters up to the first missing glyph?
>
> > Between these two, I think an application should be able to
> > efficiently subdivide a chunk of text based on the various fonts
> > that may need to be used to process it.
>
> In the long-term the font-selection-strategy will have to be
> implemented. The preceding stuff may need to be completed.
>
> > Comments on any of this are very welcome. I had hoped to defer some
> > of these font selection issues for a while yet, and you guys are
> > frankly ahead of me in needing to resolve them, so I will be glad
> > to react to those who may have thought it through more than I have.
>
> I wish I could be more helpful, but I haven't considered all aspects
> of the problem yet and I don't catch the whole point. I'd like to
> first finish the font integration work.
> IMHO this feature is for now not that important. What do other
> committers think?
>
I am not a committer but I do agree with your sentiments. Probably the 
most important "side-effect" of the FOray font integration with respect 
to the font selection process would be support for font family lists in 
font specifications. This is currently not supported and is in my 
opinion a compliance "must" case before release (not for the 1.0 pre 
beta but after that).

> Vincent
Manuel

Reply via email to