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.
Re: svn commit: r1234877 - in /xmlgraphics/fop/trunk: examples/embedding/java/embedding/ examples/embedding/java/embedding/atxml/ src/java/org/apache/fop/cli/ src/java/org/apache/fop/render/ src/java/
Yes, I believe you're correct, but this I think can be considered to be a quite advanced use-case and as such not relevant to the public API. Since there are still unknowns, I'll leave it for now, no doubt this will be discussed again in the future. On 28 January 2012 11:19, J.Pietschmann j3322...@yahoo.de wrote: Am 25.01.2012 15:59, schrieb mehdi houshmand: This would mean deprecating o.a.f.apps.FOUserAgent.setRendererOverride(...) since (if I'm not mistaken) this is legacy code to bind a MIME type to IF output. AFAIR it was meant as a hook for users providing their own renderer, overriding built-in renderers for the same MIME type. E.g. some hacked-up AFP-renderer or something. I wish Jeremias would come forward and provide some more background. J.Pietschmann
DO NOT REPLY [Bug 52513] [PATCH] Moving FOUserAgent to the constructor of Renderers
https://issues.apache.org/bugzilla/show_bug.cgi?id=52513 Mehdi Houshmand med1...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Mehdi Houshmand med1...@gmail.com 2012-01-30 09:50:54 UTC --- patch applied in r1237582 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: checkstyle errors, deprecation
This has been amended in r1237610. However just to note, this strictly speaking shouldn't be a checkstyle error, FOP is Java5 compliant not Java6, and as such that method isn't deprecated. On 27 January 2012 17:44, Glenn Adams gl...@skynav.com wrote: I notice 4 checkstyle errors have creeped into recent trunk commits. Also, there is a deprecated usage in one of the junit tests (run junit-compile target) that has been around for a while that should be fixed: % ant junit-compile ... [javac] /users/glenn/Work/fop/test/java/org/apache/fop/fonts/truetype/TTFFontLoaderTestCase.java:42: warning: [deprecation] toURL() in java.io.File has been deprecated [javac] String absoluteFilePath = file.toURL().toExternalForm(); Maybe a committer could fix these.
DO NOT REPLY [Bug 52536] [PATCH] Updating documentation about FOPs API
https://issues.apache.org/bugzilla/show_bug.cgi?id=52536 Mehdi Houshmand med1...@gmail.com changed: What|Removed |Added Attachment #28212|0 |1 is obsolete|| --- Comment #1 from Mehdi Houshmand med1...@gmail.com 2012-01-30 15:01:55 UTC --- Created attachment 28231 -- https://issues.apache.org/bugzilla/attachment.cgi?id=28231 API documentation -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
