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. Interestingly, CSS 2.1 (the only version of CSS 2 still available at W3C) removes font-stretch entirely!!??!! 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. 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. 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. 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