On 27 January 2012 20:17, J.Pietschmann <j3322...@yahoo.de> wrote:
> Am 27.01.2012 16:35, schrieb mehdi houshmand:
>> There seem to be an awful lot of static main methods around the fonts
>> and hyphenation packages, I was wondering if anyone had any objections
>> to moving all these methods into classes under a single package i.e.
> AFAIR all of these are there to facilitate development and testing,
> the font metrics and the hyphenation class generator being the only
> exceptions. They are not meant for the average user. Most if not all
> could probably be deleted, or a least moved into the test tree.
Though I agree with you, and would like to do that, I'm a little
apprehensive about removing functionality, there's always a use case
you're not taking into account. Moving them to a place we can isolate
(*cough* ignore) is sufficient for now.
> Unfortunately, there are at least two different APIs involved, and
> there are still reasons users should be able to set different resolvers
> for different purposes. Using an underlying unified API makes sense,
> however I remember unifying DTDEntityResolver and the other Resolvers
> run into difficulties (maybe related to XML catalogs).
Ignoring the API differences, the only reason I can think that people
would need multiple resolvers is to create a disparity between the
fop.xconf and the input. This is only a problem with relative URIs -
where to resolve the relative base directory from. URIs in the
fop.xconf are resolved relative to the conf file, and those in the
input are relative to the input file (be it FO or IF). This behaviour
will have to be maintained. Other than that, there doesn't seem to be
any reason why multiple resolvers are necessary.
Any specialized handling of URIs can be controlled by embedding
details in the URI itself, for example, if you want fonts to be pulled
from some remotely, just use "font:" as the scheme, and set your URI
resolver to handle the "font" scheme appropriately. The only reason
this scheme method can't be used to create a disparity between the
input-base and conf-base is because we can't define a scheme for
relative URIs, it is prohibited by the URI spec. If I'm missing a
use-case or mistaken in some way, please feel free to correct my
assumptions, getting URI resolution wrong is a serious mistake.