On 25.08.2005 18:10:51 Victor Mote wrote:
> Victor Mote wrote (August 8):
> > Manuel Mall wrote:
> > 
> > > Regarding the "bolder", "lighter" issue and the general 
> > font selection 
> > > I looked at the "pre-patch for FOrayFont adaptation to Fop"
> > > (http://issues.apache.org/bugzilla/show_bug.cgi?id=35948) and 
> > > concluded that meddling with the font selection system will 
> > interfere 
> > > with the FOray font integration and that the FOray font system has 
> > > addressed most of the font selection issues any way (not sure about 
> > > the "bolder", "lighter" bits though).
> > > I will therefore back-off from that line of work and wait for the 
> > > FOray font integration to complete, assuming that it is still going 
> > > ahead.
> > 
> > Sorry to be so slow responding. I think Vincent is taking 
> > August off, but is still working on the font integration work.
> > 
> > Manuel and I have had an off-line conversation about the 
> > bolder/lighter issue, and I think we will need to improve 
> > both the interface and the implementation to handle this and 
> > the similar issues for font-stretch. I'll work on that in the 
> > next week or two.
> First, sorry to be so slow. I can finally get to all my tools again.
> 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.

I believe that font-stretch has to included just like font-weight to
select the actual font.

If you look at Adobe's Kepler collections below you have all the
font-weight variants for each of the three font-stretch variants (Std,
SemiCondensed and Extended). It's simply an additional dimension in the
matrix to choose a font. Not that font-stretch is used so often. That's
probably the reason why it was removed. CSS probably doesn't need this
level of detail for font selection, but XSL-FO might just be a little
closer to the market where people are very picky about what font they
use. Anyway, nobody uses 32 font variants in one document and a little
font mapping configuration would do away with the need for font-stretch.
So supporting font-stretch and font-size-adjust are low-priority
especially since they are both in the "Extended" conformance level.

> Interestingly, CSS 2.1 (the only version of CSS 2 still available at W3C)
> removes font-stretch entirely!!??!!

font-size-adjust was removed, too.

CSS versions at W3C:

> 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.

> 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.

I got the impression that's what the spec tried to establish. Hmm.

> 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.
> 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.

I like that!

> 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.
> 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.
> > > BTW, while very briefly looking at parts of the FOray/aXSL font 
> > > selection code I noticed at least one instance where it relied on a 
> > > JDK
> > > 1.4 API call. Not quite what we want for FOP I believe but 
> > I am sure 
> > > easy to fix for Victor.
> > 
> > Yes, we should be able to get a 1.3 solution for this. BTW, 
> > FOray is theoretically dependent on 1.4. However, I don't 
> > know that there are any 1.4 dependencies in the font code.
> I have removed the 1.3 dependency noted in aXSL. There may be others that
> need to be addressed to retrofit for 1.3 use.
> Victor Mote

Jeremias Maerki

Reply via email to