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="ff fi fl"
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.htmlReceived 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