(Unknown)

[mehdi houshmand <me...@gmail.com>]

Hi All,



I think we've got to the stage in the URI unification branch where it's
ready to be merged into trunk (not into 1.1RC1). I know there have been
proponents against the inclusion of this feature and/or those who are
concerned the wider implications as it means FOP has fewer contingency
methods when attempting file access. I'll try and explain how we've
addressed those concerns as well as some of the code improvements we've
made.



- Syntactic URI fall-back mechanisms - if a URI is syntactically erroneous
i.e. contains white-space, "\" instead of "/", we do some validation on to
mitigate some of the common mistakes. However, we don't allow for falling
back to 'new File(".")' or "new URL(...).openStream()" since these can
obviously cause clashes in a highly parallelised multi-tenant environment.



- Single FOP conf parse - Previously the renderer specific regions of the
FOP conf was being parsed on every run. This is costly to performance for
the obvious reason, but as well as this, it meant that font auto-detection
was having to be executed on every run. The font-caching was created to
mitigate some of those performance costs, however, caching the FOP conf
makes much more sense. It means we can get rid of the font-caching and
don't have to to worry about performance but it also allowed to do a lot of
clean up in the configuration packages. The renderer specific config is
also lazy loaded such that it is only parsed when the respective renderer
is invoked, mitigating the one-off cost of parsing that config.



- The environment profile - We've created an environment profile that
abstracts the system in which FOP is invoked. This allows us to
programmatically enforce restrictions to, for example, font-caching and
auto-detection since users may want to control this behaviour for any
number of reasons.



- Improved URI handling - because the URI resolution has been unified to a
couple of classes, the behaviour is much easier for users to understand.



- Consistent base directories - We've tried to ensure that base directories
are consistent with FOP previously, the <base> and <font-base> still work
as previously.



There are however some outstanding TODOs that need to be addressed,
however, though they are important, they don't need to be all merged in at
the same time. I will be working on these and keep the community updated:



TODOs//



- XGC and libraries - This is most likely the next project, we need to do
the same in the XGC project and look at some of FOPs dependencies (Batik
too!). The plan will be to move all the resource resolver classes to XGC
since that is the parent library so that they can be used though out the
XMLGraphics libraries.



- Improved MIME type resolution - currently FOP's file-type
(file-MIME-type) is performed in-situ using file-name endings. This is,
while working perfectly fine on a desktop environment, would be less than
desirable if file-names were just hashes or the like from a virtual
file-system. We need to give the user the flexibility to define a file MIME
type without forcing them to put the file-ending in the URI.

- Default handling in some of the Configurators - We have improved the
mechanism that handles default values in the configuration as well as
config injected via RendererOptions (on the FOUserAgent) and the FOP conf
for PDF. However, time constraints haven't allowed us to do the same for PS
and AFP, which would be nice to do. This isn't of utmost priority, but it
would be nice to not have the "if (x != null)" peppered around the source

Sorry for the long email, I just thought it'd be a good time to expose some
of the work we've been doing,

Mehdi


P.S. More information can be found wiki under the developers section, it's
currently down so I can't post a link.

Re:

[Glenn Adams <gl...@skynav.com>]

thanks for clarifying

On Tue, Jun 26, 2012 at 9:01 AM, mehdi houshmand <me...@gmail.com> wrote:

> I meant that font-caching wasn't necessary so if you disable it, it
> wouldn't have a performance impact in a batch processing system like a
> "cloud environment". I should make it clear that we haven't removed either
> font-caching or font auto detection, we have just given users the means to
> disable and/or restrict those services.
>
> Mehdi
>
>
> On 26 June 2012 15:57, Glenn Adams <gl...@skynav.com> wrote:
>
>> On Tue, Jun 26, 2012 at 8:38 AM, mehdi houshmand <me...@gmail.com>wrote:
>>
>>> It means we can get rid of the font-caching and don't have to to worry
>>> about performance but it also allowed to do a lot of clean up in the
>>> configuration packages.
>>>
>>
>> I'm not sure I understand what you mean by "we can get rid of
>> font-caching". Does this work eliminate font caching or are you suggesting
>> that it makes such a change more feasible. Or by "get ride of" do you mean
>> "disable"?
>>
>
>

Re:

[mehdi houshmand <me...@gmail.com>]

I meant that font-caching wasn't necessary so if you disable it, it
wouldn't have a performance impact in a batch processing system like a
"cloud environment". I should make it clear that we haven't removed either
font-caching or font auto detection, we have just given users the means to
disable and/or restrict those services.

Mehdi

On 26 June 2012 15:57, Glenn Adams <gl...@skynav.com> wrote:

> On Tue, Jun 26, 2012 at 8:38 AM, mehdi houshmand <me...@gmail.com>wrote:
>
>> It means we can get rid of the font-caching and don't have to to worry
>> about performance but it also allowed to do a lot of clean up in the
>> configuration packages.
>>
>
> I'm not sure I understand what you mean by "we can get rid of
> font-caching". Does this work eliminate font caching or are you suggesting
> that it makes such a change more feasible. Or by "get ride of" do you mean
> "disable"?
>

Re:

[Glenn Adams <gl...@skynav.com>]

On Tue, Jun 26, 2012 at 8:38 AM, mehdi houshmand <me...@gmail.com> wrote:

> It means we can get rid of the font-caching and don't have to to worry
> about performance but it also allowed to do a lot of clean up in the
> configuration packages.
>

I'm not sure I understand what you mean by "we can get rid of
font-caching". Does this work eliminate font caching or are you suggesting
that it makes such a change more feasible. Or by "get ride of" do you mean
"disable"?