On 12.02.2008 09:08:44 Justus wrote: > Jeremias Maerki <[EMAIL PROTECTED]> wrote on Mon, 11 Feb 2008 > 09:21:10 +0100: > > > On 09.02.2008 21:43:12 Justus-bulk wrote: > > > >> one might prefer the non-condensed "DejaVu Serif" triple since the > >> font full name and the family name are in agreement, whereas they > >> aren't for the condensed font. > > > > ...the logic should probably be: > > - Generate the "family" triplet for any font of that family if it does > > not exist already. > > - If the triplet exists already and the family name equals the full name > > then replace the triplet. > > OK, we agree on this one, but with the following one I apparently was > not clear: > > >> What is the semantics of multiple family names? Is there an order of > >> preference? In this case, one could change Fop to drop the condensed > >> "DejaVu Serif" triple since "DejaVu Serif" is its second family name, > >> whereas it is the first family name of the non-condensed font. > > > > The problem here is that you don't know in which order the discovered > > fonts arrive for the registration > > I was not talking about the order in which the fonts are processed, > but about the order of the individual family names of a given font. Is > this order significant? Are there any formal specifications about > this? If so, one could prioritize the triplets based on the rank of > the family name.
I don't know of any formal specifications about family names. Each font designer is free to choose the value for the font family. I've seen differing approaches in the past. The order of the registration in FOP is significant if there are duplicate registrations. One font will win and if we don't be careful it's the wrong one (see below). This really relates to the above rule we both agree on. It's the same topic for me. > If there are no specified semantics about family name ranking, we > should probably not worry about them until it solves a concrete > problem. My particular case will be solved by the simpler "equality" > heuristic. Ok, part of the problematic code is in FontInfoFinder.generateTripletsFromFont(). The problem is really that this method doesn't have any access to the other triplets that have already been generated. Maybe this can also be resolved at the point where the font is selected. But the "mixing" currently occurs in FontInfo.addFontProperties() where a (Triplet-)Map is populated. Values are overwritten there without checking if there's already a "better" value in there already. If you want to give it a try, feel free... > > Justus Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
