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

Reply via email to