Re: [xep-support] General identifier in XEP configuration file for font paths

From: Thomas Schraitle <>
Date: Sun Nov 26 2006 - 02:19:27 PST

Hi Michael,

On Sunday 26 November 2006 08:42, Michael Sulyaev wrote:
> Thomas Schraitle wrote:
> > I believe it works. Unfortunatly, I have to use different
> > configuration files that share a lot of duplicate font-group entries.
> > The only difference is a different xml:base attribute, for example
> > (omitted config root element):
> >
> > ---[ xep-a.xml ]---
> > xml:base="file:///usr/X11R6/lib/X11/fonts/truetype/"
> > ---[ xep-b.xml ]---
> > xml:base="file:///usr/share/fonts/truetype/"
> Hi Tom,
> The fonts location on a target system won't change once the system is
> installed, so you may choose between different options during install
> time of your software.
> I would handle this with sed on a template configuration file,
> replacing e.g. __SYSTEM_FONTS__ with '/usr/X11R6/lib/X11' or
> '/usr/share'. What could be wrong with this approach?

It works, yes. :) Unfortunatly there are two problems with this approach:

1. Usually I create RPM packages of our XML build environment. At the
moment the RPM packages are noarch and independend of any (openSUSE)
platform; in other words they can be installed on every (open)SUSE
distribution. If I introduce this placeholder, it will be not independed
anymore. It's not that bad of course, but I would like to have /one/ RPM
package that can be installed on all platforms.

2. My collegues and I work with SVN and the XEP configuration file is
available in our repository. At the moment it contains the /usr/X11R6/...
directory as everybody has <=10.1 installed. If I have to change
something (say introduce a new font, change an option, ...), everbody
from my team can run "svn update" and it works without any further
configuration. However, if I have to insert a placeholder this needs a
separate step after an update. This can be easily forgotten.

I know, these "problems" look small but makes the daily work unneccessary
awkward. Therefor I search for a method to avoid such problems.

Now I tried to use a (general) URL in xml:base and resolve it through a
XML catalog. You end up with the following font-group. For example:

 <font-group label="DejaVu"
         ligatures="&#xFB00; &#xFB01; &#xFB02;"
         embed="true" subset="true">
     <font-family name="DejaVuSerif">
            <font-data ttf="DejaVuSerif.ttf"/>
         <!-- ... More font entries ... -->

My catalog has the following entry (omitted the catalog root element):

<group xml:base="file:///usr/X11/lib/X11/fonts/truetype/">

I added the Apache XML resolver class and the
contains a "verbosity=4" line. Running XEP with the XML catalog resolver
I can see lots of debug messages and the important lines:

 xml:base: file:///usr/X11/lib/X11/fonts/truetype/
 BASE STR: file:///usr/X11/lib/X11/fonts/truetype/

 (reset) xml:base:

Obviously my catalog is read by the resolver class. However, I get the
following error in the end:

 [error] Cannot read font metric from
 [error] HTTP response status is 404
 error: formatting failed: com.renderx.fonts.BadFontDataException: Could
 not obtain font metric for font family 'DejaVuSerif'

Which is true of course, as there is no font at but unexpected anyway. ;) I would have
expected that XEP reads the TTF file from /usr/X11/... according to the
rewriteURI rule from my catalog. I tried it with a different rule
(rewriteSystem) without success.

With the above method I could solve my two problems as it is done at
runtime, not hard coded or replaced. Unforuntatly it doesn't work as

Did I misunderstand something or is it a bug in the resolver class,
limitations in XEP, or ...? Any ideas? Any solution is highly
appreciated. :-)


----- Versions
XEP 4.7 build 20060908
java version "1.5.0_07"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03)
Java HotSpot(TM) Client VM (build 1.5.0_07-b03, mixed mode, sharing)

Thomas Schraitle
(*) To unsubscribe, send a message with words 'unsubscribe xep-support'
in the body of the message to from the address
you are subscribed from.
(*) By using the Service, you expressly agree to these Terms of Service
Received on Sun Nov 26 02:24:06 2006

This archive was generated by hypermail 2.1.8 : Sun Nov 26 2006 - 02:24:07 PST