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