RE: Relative font weights and font selection
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
RE: Relative font weights and font selection
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 wrote: Victor Mote a écrit : 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!!??!! As I understand the spec, this works differently from font-weight and can be resolved in the FO Tree: just select the next expanded value for wider or next condensed for narrower. The font selection would be performed only after, when it is time to decide e.g. which font the keyword semi-expanded matches. That's true that it is an extra-feature that IMO can be simulated with a good font configuration file. Just to be clear, I understand your last sentence to be addressing a different topic than the first part of this statement. That is, font configuration won't be at all involved with the *resolution* of font-stretch in what you have proposed. However, it may be involved from the standpoint of implementing a resolved font-stretch value in that font-stretch could be simulated using PostScript or PDF text parameters. Did I understand this correctly? 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'd go with 1. Get the inherited font; find a darker one in the fonts database; get its weight value. That's it. 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. That seems OK. The only interest I see for a font to belong to several families is when there is a specific family (Times, Helvetica) and a generic one (serif, sans-serif...). In this case a generic family would be mapped to a specific one, and I don't think your proposed methods prevents that. Otherwise I don't see much interest to mix several families to build a complete set. The result would be visually bad IMO. I may have missed something: I haven't studied that point yet. I think you understand it perfectly. You are correct on all points: 1) putting a font in multiple font families is not very important, 2) we can still alias a font-family to another one. 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. So let's assume that I have a line of text to render. IIUC I would use it like this: * first call with the first char of the text to get the font that will be generally used * an additional call for each character for which there is no glyph in the general font Is that what you mean? I guess so. It doesn't sound elegant or efficient, but I haven't thought of a better algorithm. Presumably the common case is that the first font selected works for all of the text. 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. Between
Re: Relative font weights and font selection
Victor Mote a écrit : As I understand the spec, this works differently from font-weight and can be resolved in the FO Tree: just select the next expanded value for wider or next condensed for narrower. The font selection would be performed only after, when it is time to decide e.g. which font the keyword semi-expanded matches. That's true that it is an extra-feature that IMO can be simulated with a good font configuration file. Just to be clear, I understand your last sentence to be addressing a different topic than the first part of this statement. That is, font configuration won't be at all involved with the *resolution* of font-stretch in what you have proposed. However, it may be involved from the standpoint of implementing a resolved font-stretch value in that font-stretch could be simulated using PostScript or PDF text parameters. Did I understand this correctly? Yes, except the end: we agree that it would not be the purpose of the font config file to solve font-stretch. What I meant is that we could use a workaround by specifying different font families for expanded fonts; e.g. one family Times-Normal and one Times-Expanded, instead of one family Times with to font-stretch variants, Normal and Expanded. The user, instead of changing the font-stretch property, would change the font-family. For all of this, probably the best approach is for someone to do exactly what you have done above: suggest changes to the interface that will provide the information needed. I'll put the problems of font-stretchability and glyph substitution on my personal todo list. I may consider those problems later, when I'm (at last!) finished with the font integration work. Vincent
Re: Relative font weights and font selection
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
RE: Relative font weights and font selection
Jeremias Maerki wrote: I believe that font-stretch has to included just like font-weight to select the actual font. Sorry to be unclear. I understand that font-stretch must be included. The issue is whether the wider and narrower constraints can be processed in the FOTree by simply bumping the description up / down, or whether (as seems to be the case for font-weight) they must be resolved in the font system by looking at the actual fonts available. I originally read the spec to mean the latter, but I think Manuel reads the spec as the former. I am not sure which is right. If the latter is correct, then we will need to do something similar to what I have described for font-weight to handle the font-stretch relative values. 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. OK. That is a third theory. 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. I have never seen such a thing explicitly. I have been working under the assumption that font A could be part of two font-families if a user wished to do so. (I am not sure why a user would want to do so -- this was just known to be possible with the data structured as it is). Thanks for your comments. Victor Mote
Re: Relative font weights and font selection
Victor Mote a écrit : 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!!??!! As I understand the spec, this works differently from font-weight and can be resolved in the FO Tree: just select the next expanded value for wider or next condensed for narrower. The font selection would be performed only after, when it is time to decide e.g. which font the keyword semi-expanded matches. That's true that it is an extra-feature that IMO can be simulated with a good font configuration file. 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'd go with 1. Get the inherited font; find a darker one in the fonts database; get its weight value. That's it. 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. That seems OK. The only interest I see for a font to belong to several families is when there is a specific family (Times, Helvetica) and a generic one (serif, sans-serif...). In this case a generic family would be mapped to a specific one, and I don't think your proposed methods prevents that. Otherwise I don't see much interest to mix several families to build a complete set. The result would be visually bad IMO. I may have missed something: I haven't studied that point yet. 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. So let's assume that I have a line of text to render. IIUC I would use it like this: * first call with the first char of the text to get the font that will be generally used * an additional call for each character for which there is no glyph in the general font Is that what you mean? 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? 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? 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. In the long-term the font-selection-strategy will have to be implemented. The preceding stuff may need to be completed. 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. I wish I could be more helpful, but I haven't considered all aspects of the problem yet and I don't catch the whole point. I'd like to first finish the font integration work. IMHO this feature is for now not that important. What do other committers think? Vincent
RE: Relative font weights and font selection
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
Re: Relative font weights and font selection
Victor Mote a écrit : 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. I confirm. Still one week offline (I'm connected only tonight) and I get back on my work on font integration. 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. There was a TODO in the code where bolder and lighter should be handled. I've left it as is for now as it is not very important yet. I had the feeling that the new font mechanism would ease things but as you say there seems to be some work to do. We will have to discuss about that one day... Cheers, Vincent
Re: Relative font weights and font selection
Sounds like a few changes are necessary. Frankly, larger, smaller, bolder and lighter are really not that important right now. I can't remember anyone ever asking for them (although I could have simply not paid attention). Yes, I think this could interfere with the FOray font integration work but so could the creation of the XML Graphics Commons subproject when that code is moved. Though this IS useful, if I could place a wish I'd rather you find an area of more practical value (just a personal opinion!). A full implementation of the font-family attribute would certainly be more useful. But if you wish to work on that nobody's going to say no. There are so many other little things that need to be improved, too (see the task list in the Wiki). Another important area would be URI resolution and proper and consistent resolution of relative paths. I think that is something that bugs especially our users through Cocoon. There are a few (older) notes about that in the Wiki. In this context it might be worthwhile to have a closer look at Batik's ParsedURL which I'd wish to see in XML Graphics Commons and used in FOP if that makes sense. This area could be something very very useful for the project and its users and be isolated enough for you not to get lost in FOP's complexity. Still, it's not a minor bit to chew. Anyway, it's up to you. On 06.08.2005 17:44:02 Manuel Mall wrote: I was looking at how to implement support for relative font weights (bolder and lighter). The spec says that a relative font weight refers to the next lighter or bolder font. This means we cannot simply subtract/add 100 to the weight but we have to find the next font relative to the current font which is actually lighter or bolder. For example if the current font weight is 400 for most of the default fonts the next bolder font weight is 700. This means this feature actually interacts with or is part of the font selection process. This raises the question if the font selection algorithm needs to be adjusted for this should it be fixed up to support for example list of font family names, font variant and font stretch or even the font selection strategy property including context characters, etc.. The last bit (selection strategy, context characters, glyph availability) may be a bit much for me to attempt at the moment but the other bits look doable. My question for the experienced developers and those fop-devs who look at the overall project: Is this something useful and sensible to attempt at this point in time, i.e. leading up to a 0.9 release? Would this cut across or interfere with the attempt to integrate FOray's font system into FOP? Manuel Jeremias Maerki
