Re: Static main methods
Hi, Le 27/01/2012 21:17, J.Pietschmann a écrit : I'm not sure what to do with the metrics generator, as the metrics file is deprecated anyway. IIUC, metric file is deprecated *only* for embedded fonts. It is still required for referenced fonts. deprecating metrics generator makes the latter font usage deprecated too. -- Pascal
Re: Static main methods
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.
Static main methods
Hi, Another proposal for public consideration: 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. org.apache.fop.cli.utils. This would involve more than merely copy/pasting the main method itself, but also some of the ancillary methods that are only used by static main methods. Obviously, this would include updating the documentation to reflect the migration. The reason I'm making this proposition is that I'm trying to unify the URI resolution and file access within FOP, we currently use 5 URI resolvers, without including what XMLGraphics and Batik do, (FOURIResolver, FontResolver, HyphenationTreeResolver, DataURIResolver, DTDEntityResolver) which I think we can all agree is a little excessive. In so doing, I keep bumping up against these static main methods or functions that are only called by them, and it seems to me that while I'm at it, I might as well do some clean up. Anyways your collective thoughts would be appreciated on the matter, Mehdi
Re: Static main methods
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. I'm not sure what to do with the metrics generator, as the metrics file is deprecated anyway. The hyphenation class generator is already a class for itself (which ist overly complicated and could probably share more code with the ant task). Another possibility would be to get rid of explicitely building serialized hyphenation classes and use a caching mechanism for processed hyphenation patterns, somewhat similar to fonts. (FOURIResolver, FontResolver, HyphenationTreeResolver, DataURIResolver, DTDEntityResolver) which I think we can all agree is a little excessive. 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
