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. http://store.adobe.com/type/browser/P/P_1432.html http://store.adobe.com/type/browser/P/P_1435.html http://store.adobe.com/type/browser/P/P_1437.html > 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: http://www.w3.org/TR/REC-CSS1 http://www.w3.org/TR/REC-CSS2/ http://www.w3.org/TR/CSS21/ > 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