You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Jeremias Maerki <de...@jeremias-maerki.ch> on 2008/04/29 18:15:59 UTC
Font auto-detection and font referencing
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 {@link FontTriplet}.
*/
public interface Matcher {
/**
* Indicates whether the given {@link 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
Re: Font auto-detection and font referencing
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Hi Adrian
On 30.04.2008 13:19:37 Adrian Cumiskey wrote:
> 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?
Sure. For all font triplets that match the criteria in the configuration
a transient field on the associated EmbedFontInfo is set to tell the
font loading code later that it shouldn't set the URL for the font file
on the loaded font which effectively causes the font to be referenced.
The field in EmbedFontInfo is transient as this information doesn't
belong to the part that is cached in the cache file. More beautiful
would obviously be a way to hold this field separately. But creating too
much new stuff just for a boolean seems impractical.
> And what classes would implement Matcher? (I'd
> probably call that interface FontMatcher).
See the attached patch (not ready to apply, one thing I have to look
into). I've called it Matcher as it's an inner interface for FontTriplet,
i.e. FontTriplet.Matcher. If it's not an inner interface it should
rather be called FontTripletMatcher as the "Font" class is something
else. The two implementations I have are inner classes to
PrintRendererConfigurator as they are only needed there at the moment.
I mentioned the Matcher as you assume you also have to match font
triplets. But you don't do it in the configurator, but in FontInfo.
Maybe later someone needs to add something else, for example, add some
matchers to treat some TrueType fonts not as CID fonts but in
single-byte mode. Who knows: at some point, the matcher might even be
used to implement a different ruleset for font fallbacks than are
already in FontInfo.
> 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.
Sure, the old idea of font sources (see Wiki
http://wiki.apache.org/xmlgraphics-fop/FOPFontSubsystemDesign and the
archives). I'm all for it. I'm annoyed about the font config duplication
myself. But it's not something that can be done on-the-fly. Starting the
bits of the generalization now would just add confusion if you ask me. I
was actually thinking about tackling that as I move the whole thing
to Commons. During the move I don't have to look after backwards
compatibility and anything. At any rate, this has to be designed
carefully so we don't create a mess right from the start.
<snip/>
Jeremias Maerki
Re: Font auto-detection and font referencing
Posted by Adrian Cumiskey <ad...@gmail.com>.
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 {@link FontTriplet}.
>>>>> */
>>>>> public interface Matcher {
>>>>>
>>>>> /**
>>>>> * Indicates whether the given {@link 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
>
>
Re: Font auto-detection and font referencing
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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 {@link FontTriplet}.
> >>> */
> >>> public interface Matcher {
> >>>
> >>> /**
> >>> * Indicates whether the given {@link 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
Re: Font auto-detection and font referencing
Posted by Adrian Cumiskey <ad...@gmail.com>.
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 {@link FontTriplet}.
>>> */
>>> public interface Matcher {
>>>
>>> /**
>>> * Indicates whether the given {@link 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
>
>
Re: Font auto-detection and font referencing
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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 {@link FontTriplet}.
> > */
> > public interface Matcher {
> >
> > /**
> > * Indicates whether the given {@link 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
Re: Font auto-detection and font referencing
Posted by Adrian Cumiskey <ad...@gmail.com>.
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 {@link FontTriplet}.
> */
> public interface Matcher {
>
> /**
> * Indicates whether the given {@link 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
>
>