FOrayFont?

[Vincent Hennebert <vi...@enseeiht.fr>]

Hi all...

Sorry to insist, but what is your final decision? A quick summary of the thread 
gives:
- Jeremias +1
- Simon +1
- Glen +0
The FOray+aXSL stuff would be used in the form of a jar file put in the lib 
directory; FOray's avalon loggers would be wrapped into a JCL adapter for now.

So?
Vincent

Re: FOrayFont?

[Glen Mazza <gm...@apache.org>]

+0 still as-is.

+1, if Jeremias will let me melt his PageViewportProvider directly into 
PSLM; it's only about 75 extra LOC and four methods so I think we can go 
without the extra moving part.

+1000, if Jeremias will let me remove his RendererFactory.  
IMContinuedHO, whatever its elegance, it is not mathematically/logically 
reduced and hence unattractive to the Don Knuth types we need to get on 
this team, and to the university types/research organizations I would 
like to get more interested into this project.

The Don Knuth types do not like to see this:

x + 3 = y + 2  (math)
or (comp. sci.):
i = i + 1;
i = i + 3; 

They wrinkle their noses and run away.  Math/algorithm-lovers very 
rarely derive pleasure from non-fully-reduced work.

They do like to see this, however:
x = y - 1 (math)
or
i = i + 4; (comp. sci.)

Here, now we're talking algorithmic attainment, their field, and they 
are more likely to help us out in our work, FOP being considerably more 
interesting than the types of stuff they normally get to work on.

I believe XSL is more than just implementable, it is actually 
*solvable*--i.e., multiple teams working independently would arrive at 
the same common, timeless algorithm if they all reduced their code while 
working on it (just as they, working independently, would all arrive at 
the same Pythagorean Theorem.)  I am unsure, but I believe it is the 
determination of this common algorithm that would be most likely to 
attract support from external organizations.  RendererFactory, like most 
Java design patters, appears to move us away from the common algorithm.

w/o RF: (fully reduced, every team will sooner or later arrive at):
fop-->fotreebuilder-->foeventhandler-->renderer

w/RF:  After (not reduced, each team could implement differently, per 
the tastes of individual developers or groups of developers):
fop-->fotreebuilder-->rendererfactory-->foeventhandler-->rendererfactory-->renderer

FOP's greatest allure is its unique math-based algorithms, so unlike 
most (boring) Java apps you do not need to pile on Java design patterns 
to make it appealing to would-be committers.  Furthermore, such moves 
actually tend to have a negative effect, as it just makes FOP look like 
any of thousands of other open-source Java applications (that we would 
now need to compete with for resources).  In terms of attracting 
developers/outside companies, it seems to me that it would be like 
putting a magazine cover girl model in an Eskimo outfit, or like taking 
a perfectly prepared steak and pouring that horrid A-1 steak sauce over it.

Regards,
Glen


Vincent Hennebert escribió:

> Hi all...
>
> Sorry to insist, but what is your final decision? A quick summary of 
> the thread gives:
> - Jeremias +1
> - Simon +1
> - Glen +0
> The FOray+aXSL stuff would be used in the form of a jar file put in 
> the lib directory; FOray's avalon loggers would be wrapped into a JCL 
> adapter for now.
>
> So?
> Vincent
>

Re: FOrayFont?

[Chris Bowditch <bo...@hotmail.com>]

Vincent Hennebert wrote:

> Hi all...
> 
> Sorry to insist, but what is your final decision? A quick summary of the 

Thank you for insisting. I think it would be a great advantage if FOP used the 
Font module developed in FORay. So heres my +1

> thread gives:
> - Jeremias +1
> - Simon +1
> - Glen +0
> The FOray+aXSL stuff would be used in the form of a jar file put in the 
> lib directory; FOray's avalon loggers would be wrapped into a JCL 
> adapter for now.

I'm happy with that.

Chris

Re: FOrayFont?

[Glen Mazza <gm...@apache.org>]

Victor Mote wrote:

>  
>
>>Related to this is that I moved FOP from the controller-class (in use
>>1998-2004) to the pipeline approach[1] early last year, and 
>>still recommend that architecture.  However, I suspect the 
>>font code will be expecting a controller-class architecture 
>>to work.  Given that most committers have been comfortable 
>>    
>>
>
>Why do you say this? An org.foray.font.Font is pretty similar in concept to
>a java.awt.Font, except that it provides additional services. The FontServer
>is needed to keep the various clients separate. (This is important for TTF
>subsetting in multi-threaded environments). The whole system should work
>fine AFAICT anywhere where java.awt.Font might be used. It should work
>equally well with FOP's "pipeline" (pipes cemented with glue) or with
>FOray's pipeline (the Unix-ish definition of a pipe with components that are
>agnostic about the source of input or the use of output).
>
>  
>

Sounds nice!  Amazing how FOP always seems to manage to get the right 
talent at the right time.

Glen

RE: FOrayFont?

[Victor Mote <vi...@outfitr.com>]

Glen Mazza wrote:

> At any rate, though, I anticipate us bringing in and 
> modifying the code over time, rather than keeping it as an 
> external JAR.

That is fine, but I hope you and others will give the jar approach a fair
trial. The whole point of the collaboration is to avoid duplication of
effort. I know (better than most) that forks are sometimes unavoidable, but
I hope they will be considered a last resort.

> Related to this is that I moved FOP from the controller-class (in use
> 1998-2004) to the pipeline approach[1] early last year, and 
> still recommend that architecture.  However, I suspect the 
> font code will be expecting a controller-class architecture 
> to work.  Given that most committers have been comfortable 

Why do you say this? An org.foray.font.Font is pretty similar in concept to
a java.awt.Font, except that it provides additional services. The FontServer
is needed to keep the various clients separate. (This is important for TTF
subsetting in multi-threaded environments). The whole system should work
fine AFAICT anywhere where java.awt.Font might be used. It should work
equally well with FOP's "pipeline" (pipes cemented with glue) or with
FOray's pipeline (the Unix-ish definition of a pipe with components that are
agnostic about the source of input or the use of output).

> with the controller-class approach in the past, I would be OK 
> with it if we wanted to switch back--I can't spend as much 
> time anymore on FOP anyway.  I remain satisfied that the 
> proof-of-concept worked but we have users to satisfy here...  ;-)

I like to think that FOP will eventually switch, not back, but forward to a
componentized model, but think the only way to see that happen is to show it
working in FOray. But really, nothing that I can see in FOrayFont should
require any architectural changes one way or another. If FOP wants or needs
to change its architecture, I don't see it coming as a result of anything in
FOrayFont.

> I do have a caution to offer though:  If the goal is to be 
> rewarded for one's efforts on FOP, make sure the 
> architectural decisions are done so that 18 months, 24 months 
> down the road FOP will have a 90% market share, even if it 
> means there will be grumbling on the mailing lists for the 
> initial few months because FOP 0.20.5 is incompatible with FOP 1.0.  
> I personally am strong-kneed enough to handle the grumbling 
> with the knowledge that FOP will be ultimately very 
> successful.  Indeed, I take it for granted that if you want a 
> work-of-art system that puts the competition to shame two 
> years down the road, you have to make the unpleasant 
> architectural changes now to put FOP's past behind it. 

Sorry, I couldn't parse your meaning here at all, unless you are arguing
against changing the architecture back. Again, that shouldn't be necessary.

> For practical reasons though, we may end up needing to 
> restore some of the API back such as Driver.  But if the team 
> does not think long-term, and just reacts to every individual 
> ML complaint by adding to the API, FOP will become 
> unmaintainable and start to degrade.  I was around in late 
> 2003 when FOP 1.0 had all the API's of the past--it also went 
> down to three active committers at that time--Victor, Joerg, 
> and myself.  Too much to maintain, then people get turned off 
> from the project, and, long-term, users on the ML get 
> confused, given the multiple ways to do the same thing.

Well, the API issue is separate from the internal architecture issue, which
in turn, is separate from the font system issue. Some of the ugliness that
existed in the code at that time was due to my efforts to change the
internal architecture *without* changing the outer-layer API, which, at the
time, was forbidden. That has changed.

Nevertheless, there is one API issue which FOP will need to consider. A
FontServer instance needs to be created somewhere. FOray accepts one in the
FOraySession constructor, but instantiates one if it is passed null. IMO,
this maximizes flexibility, but if FOP wants to leave its API alone (and I
understand the desire to do so), it can simply instantiate one internally.

Victor Mote

Re: FOrayFont?

[Glen Mazza <gm...@apache.org>]

I haven't researched fonts in general so I can't comment on its value or 
quality.  However, Victor's coding has shown itself to be pretty solid 
and robust in the past.   *What* Victor codes is often not my 
preference, but the *way* he codes what he does is quite good.  In 
general, if I had a mission-critical system to build I would be 
comfortable relying on him to build it.

At any rate, though, I anticipate us bringing in and modifying the code 
over time, rather than keeping it as an external JAR.

Related to this is that I moved FOP from the controller-class (in use 
1998-2004) to the pipeline approach[1] early last year, and still 
recommend that architecture.  However, I suspect the font code will be 
expecting a controller-class architecture to work.  Given that most 
committers have been comfortable with the controller-class approach in 
the past, I would be OK with it if we wanted to switch back--I can't 
spend as much time anymore on FOP anyway.  I remain satisfied that the 
proof-of-concept worked but we have users to satisfy here...  ;-)

I do have a caution to offer though:  If the goal is to be rewarded for 
one's efforts on FOP, make sure the architectural decisions are done so 
that 18 months, 24 months down the road FOP will have a 90% market 
share, even if it means there will be grumbling on the mailing lists for 
the initial few months because FOP 0.20.5 is incompatible with FOP 1.0.  
I personally am strong-kneed enough to handle the grumbling with the 
knowledge that FOP will be ultimately very successful.  Indeed, I take 
it for granted that if you want a work-of-art system that puts the 
competition to shame two years down the road, you have to make the 
unpleasant architectural changes now to put FOP's past behind it. 

For practical reasons though, we may end up needing to restore some of 
the API back such as Driver.  But if the team does not think long-term, 
and just reacts to every individual ML complaint by adding to the API, 
FOP will become unmaintainable and start to degrade.  I was around in 
late 2003 when FOP 1.0 had all the API's of the past--it also went down 
to three active committers at that time--Victor, Joerg, and myself.  Too 
much to maintain, then people get turned off from the project, and, 
long-term, users on the ML get confused, given the multiple ways to do 
the same thing.

Glen

[1] http://marc.theaimsgroup.com/?l=fop-dev&m=106246324305040&w=2


J.Pietschmann wrote:

> Vincent Hennebert wrote:
>
>> Sorry to insist, but what is your final decision? A quick summary of 
>> the thread gives:
>> - Jeremias +1
>> - Simon +1
>> - Glen +0
>> The FOray+aXSL stuff would be used in the form of a jar file put in 
>> the lib directory; FOray's avalon loggers would be wrapped into a JCL 
>> adapter for now.
>
>
> I'm somewhat uneasy with having an important if not essential
> subsystem developed outside (unless already widely used elsewhere),
> but I certainly wont veto anything which advances the project.
>
> +0
>
> J.Pietschmann
>

Re: FOrayFont?

["J.Pietschmann" <j3...@yahoo.de>]

Vincent Hennebert wrote:
> Sorry to insist, but what is your final decision? A quick summary of the 
> thread gives:
> - Jeremias +1
> - Simon +1
> - Glen +0
> The FOray+aXSL stuff would be used in the form of a jar file put in the 
> lib directory; FOray's avalon loggers would be wrapped into a JCL 
> adapter for now.

I'm somewhat uneasy with having an important if not essential
subsystem developed outside (unless already widely used elsewhere),
but I certainly wont veto anything which advances the project.

+0

J.Pietschmann

Re: FOrayFont?

[Jeremias Maerki <de...@greenmail.ch>]

Hi Vincent

Yeah, sorry. Given the feedback, you can go forward with this. I'll try
to help where I can. The goal should simply be that we have a real
benefit from using FOray-Font at the end. For example, the ability to
get rid of the manual step of creating font metric files is a good
benefit, as would be automatic font provisioning.

Thanks for insisting and helping us!

On 24.06.2005 16:33:19 Vincent Hennebert wrote:
> Hi all...
> 
> Sorry to insist, but what is your final decision? A quick summary of the thread 
> gives:
> - Jeremias +1
> - Simon +1
> - Glen +0
> The FOray+aXSL stuff would be used in the form of a jar file put in the lib 
> directory; FOray's avalon loggers would be wrapped into a JCL adapter for now.
> 
> So?
> Vincent



Jeremias Maerki