RE: Relative font weights and font selection

[Victor Mote <vi...@outfitr.com>]

Victor Mote wrote (August 27, 2005):

> > > 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();

...

> > > 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.
> > 
> > Why not directly return an array of all indexes where there is a 
> > missing glyph?
> 
> OK. Probably in a separate method called unavailableChars.
> 
> > 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?
> 
> Yes. That definitely needs to be there.

The following methods have now been added to org.axsl.font.Font:
    public byte nextBolderWeight() ;
    public byte nextLighterWeight() ;
    public Font nextBolderFont() ;
    public Font nextLighterFont() ;

    public int unavailableChar(String string, int beginIndex) ;
    public int unavailableChar(char[] chars, int beginIndex) ;
    public int[] unavailableChars(String string, int beginIndex) ;
    public int[] unavailableChars(char[] chars, int beginIndex) ;

and a char has been added to the signature of the method
org.axsl.font.FontServer.selectFont.

Stub implementations have been created in FOray, but the added functionality
is, in general, not actually in place yet. I'll get to that as I am able,
but at least those working with the interface can move forward when they are
ready.

Victor Mote

Re: Relative font weights and font selection

[Vincent Hennebert <vi...@enseeiht.fr>]

Victor Mote a écrit :
> The following methods have now been added to org.axsl.font.Font:
>     public byte nextBolderWeight() ;
>     public byte nextLighterWeight() ;
>     public Font nextBolderFont() ;
>     public Font nextLighterFont() ;
> 
>     public int unavailableChar(String string, int beginIndex) ;
>     public int unavailableChar(char[] chars, int beginIndex) ;
>     public int[] unavailableChars(String string, int beginIndex) ;
>     public int[] unavailableChars(char[] chars, int beginIndex) ;
> 
> and a char has been added to the signature of the method
> org.axsl.font.FontServer.selectFont.
> 
> Stub implementations have been created in FOray, but the added functionality
> is, in general, not actually in place yet. I'll get to that as I am able,
> but at least those working with the interface can move forward when they are
> ready.

That seems pretty well to me. As it also isn't urgent for me to implement this 
I'll wait before looking at it into more details.
But that should let doing the trick.

Thanks,
Vincent

RE: Relative font weights and font selection

[Victor Mote <vi...@outfitr.com>]

Victor Mote wrote (on Monday):

> The following methods have now been added to org.axsl.font.Font:
>     public byte nextBolderWeight() ;
>     public byte nextLighterWeight() ;
>     public Font nextBolderFont() ;
>     public Font nextLighterFont() ;
> 
>     public int unavailableChar(String string, int beginIndex) ;
>     public int unavailableChar(char[] chars, int beginIndex) ;
>     public int[] unavailableChars(String string, int beginIndex) ;
>     public int[] unavailableChars(char[] chars, int beginIndex) ;
> 
> and a char has been added to the signature of the method 
> org.axsl.font.FontServer.selectFont.
> 
> Stub implementations have been created in FOray, but the 
> added functionality is, in general, not actually in place 
> yet. I'll get to that as I am able, but at least those 
> working with the interface can move forward when they are ready.

FOrayFont now has fully functional implementations of all of these methods,
and its font selection logic has been upgraded to use them. With the
*possible* exception of font-selection-strategy (I will start a separate
thread on this issue shortly), I think that FOray's font selection is now
fully conformant.

FOrayFOTree has also been upgraded to use the font-selection properly, and
to compute the relative font weights using the new aXSL font methods. If it
helps, Vincent and Manuel can use this as a template when implementing in
FOP. The only real trick in FOray was getting the first chunk of text that
should be considered. If that task is difficult in FOP, and you wish to
defer it, you can probably safely do so by sending the space character 0x20
to the FontServer.selectFontXSL method. Most, if not all, fonts will be able
to encode that character.

There are some user issues that result from the new conformity, WRT
simulating small-caps. The small-caps simulation logic that FOray inherited
from FOP had the following features:
1. Used a hard-coded 80% figure.
2. The decision to use small-caps at all, always simulated, was made
entirely outside of the font system.
3. Actual simulation of small-caps took place outside of the font system.

In order to build a conformant font selection, items 1 and 2 above have been
pulled into the font system. The aXSL font configuration DTD now includes
for the font-description element an attribute called "simulate-small-caps",
which takes a percentage. Existence of the simulate-small-caps attribute
also allows the font-description to be selected for either
font-variant="normal" or font-variant="small-caps" requests. User must now
provide a "simulate-small-caps" attribute for small-caps simulation to even
be considered in the font-selection process. The font-selection logic should
pick a true small-caps variant before picking one that merely simulates
small-caps. Also the following method has been added to the Font interface
to expose the new information provided in font configuration:
    public int smallCapsSize(int fontSize);

This method returns the fontSize that should be used for intrinsically
lowercase characters. Remember that the font system doesn't know when
small-caps simulation is actually being used (item 3 above). It only knows
whether it can be used or not, and, if so, the scaling factor that should be
applied.

BTW, the DTD now also includes the following font-description attributes:
  simulate-oblique CDATA #IMPLIED
  simulate-backslant CDATA #IMPLIED
  simulate-ultra-condensed CDATA #IMPLIED
  simulate-extra-condensed CDATA #IMPLIED
  simulate-condensed CDATA #IMPLIED
  simulate-semi-condensed CDATA #IMPLIED
  simulate-semi-expanded CDATA #IMPLIED
  simulate-expanded CDATA #IMPLIED
  simulate-extra-expanded CDATA #IMPLIED
  simulate-ultra-expanded CDATA #IMPLIED

These are intended for aXSL implementation that wish to simulate font-style
and font-stretch values. I have documented these pretty heavily in the DTD
itself for those who want more detail.

Victor Mote