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
