Hi Jeremias,
I'm not sure I fully understand, maybe it might clarify this a little for me if you could explain
how the font reference mapped to an actual font? And what classes would implement Matcher? (I'd
probably call that interface FontMatcher).
Also would your <fonts/> matching configuration definition reside under each <renderer/> or would it
reside more globally and apply to all the renderers as a sibling of </renderers>? I would propose
that in the *future* it would be better if font configuration is managed in the configuration at a
global level above <renderers/> in a <fonts/> declaration.
In this way, fonts would be managed globally in a FontManager and then each Renderer exposes what
their font support capabilities are (see http://xmlgraphics.apache.org/fop/trunk/fonts.html#intro).
This would work in a similar way to how image support is communicated. Then at some point in the
future when FopFactory, UserAgent etc dependencies have been removed from high level components,
there would be an opportunity to migrate more to xmlgraphics-commons.
Adrian.
Jeremias Maerki wrote:
Adrian, you're under time pressure, I'm not. So why don't you just
finish your stuff in peace and I'll integrate mine later. But of course,
I can post my changes once I've finished testing. Should be later today.
Still looking for feedback for my proposal.... ;-)
On 30.04.2008 11:10:42 Adrian Cumiskey wrote:
I'm not angry, well maybe a little bit annoyed initially... ;-) - I know your intention was not to
create a problem for me, and of course your contributions are valued :). Its just I'm under a bit
of time pressure to deliver this feature and this is not something I accounted for.
I have done quite a bit of cleanup and restructuring when working on this, removing dependencies on
the static FontSetup and creating a FontManager which resides in FopFactory which then delegates to
FontInfo. So I'm guessing this might cause your code quite a few conflicts. It seems svn commits
are still not possible so I'll continue to work on finishing off what I have. My implementation
doesn't use regex's like yours but it supports comma separated font attributes and weight ranges.
Maybe we can combine the best of each other's implementation into a final solution. Maybe you could
send me a patch file for the work you have done in this area so I can take a look at your approach? :)
Adrian.
Jeremias Maerki wrote:
Adrian,
I'm not sure: Are you angry at me now? I hope not, and if you are: my
apologies. I sure don't intend to get in your way and I'm fully aware
that you're doing something in the vicinity. I certainly don't mind
sorting out any conflicts on my side. Since SVN write access doesn't
work anyway at the moment I won't commit anything immediately. I also
have to do a bit more testing tomorrow. I'm simply going down my task
list and this topic happened to come out on top. I just thought I'd
share what I came up with. After all this is nothing big and it's very
easy for me to go a different route if necessary. My main work was in
areas where you won't have to change anything.
But WDYT about my proposal? Useful? Stupid?
On 29.04.2008 19:02:13 Adrian Cumiskey wrote:
Jeremias,
I think we may have some crossed wires here as I communicated that I'd be working in this area and
have been working on a matching mechanism following your suggested font-substitution-catalog
configuration.
I very much hope I don't feel the need to throw anything away as my implementation includes weight
and style, and also takes account of priority. If you have something working I guess you should go
ahead and commit when svn has returned, and I'll spend some time sorting out the conflicts :).
Adrian.
Jeremias Maerki wrote:
I'm working on making referenced fonts work with font auto-detection,
i.e. that one can define which fonts should not be embedded, only
referenced. I already have the basics working locally. In the case of
TrueType fonts I can make use of the same mechanism I introduced for
Type 1 fonts to address more than just the WinAnsi glyphs (using
multiple single byte encodings). I'm writing because I want to see if
anyone is opposed to my approach for specifying which fonts should be
referenced. Here's what the config file now looks like:
<fonts>
[..]
<referenced-fonts>
<match font-family="Helvetica"/>
<match font-family="DejaVu.*"/>
<match font-family=".*Grotesk.*"/>
</referenced-fonts>
</fonts>
Basically I've defined an interface for which I can add whatever
implementation I want:
public class FontTriplet implements Comparable, Serializable {
[..]
/**
* Matcher interface for [EMAIL PROTECTED] FontTriplet}.
*/
public interface Matcher {
/**
* Indicates whether the given [EMAIL PROTECTED] FontTriplet} matches a
particular criterium.
* @param triplet the font triplet
* @return true if the font triplet is a match
*/
boolean matches(FontTriplet triplet);
}
}
I'm currently using regular expressions to match the font-family names.
If the font matches it is set to referencing mode. Works pretty nicely
IMO.
BTW, Adrian, you could use the same interface for the matching part I've
proposed earlier for the font substitution.
Jeremias Maerki
Jeremias Maerki
Jeremias Maerki
