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. <snip/> > 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). > > J.Pietschmann > 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.
