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

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"
         xml:base="http://www.suse.de/fonts/truetype/"
         ligatures="&#xFB00; &#xFB01; &#xFB02;"
         embed="true" subset="true">
     <font-family name="DejaVuSerif">
         <font>
            <font-data ttf="DejaVuSerif.ttf"/>
         </font>
         <!-- ... More font entries ... -->
     </font-family>
 </font-group>
------------------------

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

------------------------
<group xml:base="file:///usr/X11/lib/X11/fonts/truetype/">
    <rewriteURI
       uriStartString="http://www.suse.de/fonts/truetype/"
       rewritePrefix=""/>
 </group>
------------------------

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

 [...]
 BASE STR:
 file:/home/tom/books/https-xslfobook/trunk/common/config/catalog.xml
 xml:base: file:///usr/X11/lib/X11/fonts/truetype/
 BASE STR: file:///usr/X11/lib/X11/fonts/truetype/
 rewriteURI: http://www.suse.de/fonts/truetype/

 REWRITE_URI: http://www.suse.de/fonts/truetype/
         file:/usr/X11/lib/X11/fonts/truetype/
 (reset) xml:base:
 file:/home/tom/books/https-xslfobook/trunk/common/config/catalog.xml
 [...]

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

 [error] Cannot read font metric from
 http://www.suse.de/fonts/truetype/DejaVuSerif.ttf
 [error] java.io.IOException: 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
www.suse.de/fonts/truetype/ 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
expected.

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

Thanks,
Tom

----- Versions
XEP 4.7 build 20060908
xml-commons-resolver-1.1-7
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 majordomo@renderx.com from the address
you are subscribed from.
(*) By using the Service, you expressly agree to these Terms of Service http://www.renderx.com/terms-of-service.html