Jeremias,

fair enough. I have done the "larger", "smaller" bits as they are 
constrained to the fop property subsystem and will post a patch later. 
They were quite a handy starting point in trying to understand the fop 
property system.  

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.

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.

Now back to the WIKI to find something to do.

Manuel

On Mon, 8 Aug 2005 01:04 am, Jeremias Maerki wrote:
> 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