Re: Foray's font subsystem for Fop

[The Web Maestro]

On Jun 24, 2005, at 7:33 AM, 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

- Chris +1 (attached below)

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

It would've been better to forward the original VOTE message (attached at the bottom for completeness), otherwise it's a little bit stickier, since these 'votes' are scattered amongst two threads... (which is why I replied to the original thread...)

Anyway... +1 from me!

Regards, Web Maestro Clay

Begin forwarded message:

From: Chris Bowditch <[EMAIL PROTECTED]>
Date: June 24, 2005 7:58:35 AM PDT
To: fop-dev@xmlgraphics.apache.org
Subject: Re: FOrayFont?
Reply-To: fop-dev@xmlgraphics.apache.org
Reply-To: [EMAIL PROTECTED]

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


On Jun 17, 2005, at 12:53 PM, Simon Pepping wrote:
On Tue, Jun 14, 2005 at 10:33:10AM +0200, Jeremias Maerki wrote:
I welcome any additional thoughts/comments. Now starting to work...

I wish you had asked before diving into this. Before FOray-Font can be
integrated with FOP we need to have a vote on this among the committers
and frankly, I'm sure such a thing will cost a lot of energy. I'm not
going to push in that direction without any hint of support from at
least two other committers around here. I hope we will get more opinions.

I am catching up on my email, and reading this thread several days
after the fact. I did not see a reaction to Jeremias' above request.

In general I am all for sharing an implementation of a piece of
functionality that can be accessed via an agreed interface. Font
services are really a good candidate. I have not studied FOray-Font,
but I follow Jeremias' judgement on this that it is better than what
we have now. Therefore I am in favour of using FOray-Font for
satisfying FOP's font requirements.

As long as FOray-Font is released under the Apache license, I believe
that FOP should not have a problem with it, even if FOP would not have
any control over it, as long as the implementation satisfies us. As
soon as it does not, the license allows us to take a snapshot of the
sources and go our own way. That is how I understand open source and
the Apache license. I do not quite understand why we would need a
grant. But even if so, Victor is willing to give one.

That is my stand point. If this were a vote, my vote would be +1.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



Regards,

Web Maestro Clay
-- 
<[EMAIL PROTECTED]> - 
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Foray's font subsystem for Fop

[Simon Pepping]

On Tue, Jun 14, 2005 at 10:33:10AM +0200, Jeremias Maerki wrote:
> > I welcome any additional thoughts/comments. Now starting to work...
> 
> I wish you had asked before diving into this. Before FOray-Font can be
> integrated with FOP we need to have a vote on this among the committers
> and frankly, I'm sure such a thing will cost a lot of energy. I'm not
> going to push in that direction without any hint of support from at
> least two other committers around here. I hope we will get more opinions.

I am catching up on my email, and reading this thread several days
after the fact. I did not see a reaction to Jeremias' above request.

In general I am all for sharing an implementation of a piece of
functionality that can be accessed via an agreed interface. Font
services are really a good candidate. I have not studied FOray-Font,
but I follow Jeremias' judgement on this that it is better than what
we have now. Therefore I am in favour of using FOray-Font for
satisfying FOP's font requirements.

As long as FOray-Font is released under the Apache license, I believe
that FOP should not have a problem with it, even if FOP would not have
any control over it, as long as the implementation satisfies us. As
soon as it does not, the license allows us to take a snapshot of the
sources and go our own way. That is how I understand open source and
the Apache license. I do not quite understand why we would need a
grant. But even if so, Victor is willing to give one.

That is my stand point. If this were a vote, my vote would be +1.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl

Re: OT: Moving to UK? (RE: Foray's font subsystem for Fop)

[Jeremias Maerki]

On 16.06.2005 01:53:39 Peter B. West wrote:
> Jeremias Maerki wrote:
> > Do you, by chance, intend to visit ApacheCon in Stuttgart in July?
> > 
> 
> It's relatively expensive, isn't it?

Yes, that's the catch. Being a speaker it almost costs me nothing. I
disagree with the way this is currently done. They pay me the travel and
two hotel nights which isn't really necessary and only makes the
conference more expensive for everyone else. When I went to Seybold
conference in Amsterdam as a speaker last year, I only got free
admission and lunch which should be enough.

>  I don't know what I will be doing 
> at any particular time.  It depends on what work is available to me.
> 
> > If you come to Switzerland, tell me!
> 
> I certainly will.  There are a few of you in the area whom I will 
> contact when we pass through.

I bet.

Jeremias Maerki

Re: OT: Moving to UK? (RE: Foray's font subsystem for Fop)

[Jeremias Maerki]

On 15.06.2005 21:32:21 Andreas L. Delmelle wrote:
> > -Original Message-
> > From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
> >
> 
> Hi Jeremias,
> 
> > Do you, by chance, intend to visit ApacheCon in Stuttgart in July?
> 
> (I take this 'you' to be plural)

Sure, this is addressed to every FOP committer.

> Me personally, I did intend to visit when I first received word, but
> unfortunately I wasn't able to get the necessary time off... A shame though,
> so close. :-(
> 
> > If you come to Switzerland, tell me!
> 
> Will certainly do so. I do want to travel to Switzerland very much --in my
> dreams, I even have a house there :-) Ah well, who knows, one day...

Looking forward to it.

Jeremias Maerki

Re: OT: Moving to UK? (RE: Foray's font subsystem for Fop)

[Glen Mazza]

Andreas L. Delmelle wrote:

 


Do you, by chance, intend to visit ApacheCon in Stuttgart in July?
   



(I take this 'you' to be plural)
Me personally, I did intend to visit when I first received word, but
unfortunately I wasn't able to get the necessary time off... A shame though,
so close. :-(

 



I came close to going...But ultimately it would have been quite 
expensive and time-consuming for me to plan such a trip.  There's an 
"Extreme XML" Conference in Canada this August that looked pretty good 
and would cost me much less--so I signed up for that instead as my 
learning-vacation for the year.



If you come to Switzerland, tell me!
   



Will certainly do so. I do want to travel to Switzerland very much --in my
dreams, I even have a house there :-) 



with a *very, very* luxurious attic I would suspect...  ;-)

Glen

Re: OT: Moving to UK? (RE: Foray's font subsystem for Fop)

[Peter B. West]

Jeremias Maerki wrote:

Do you, by chance, intend to visit ApacheCon in Stuttgart in July?



It's relatively expensive, isn't it?  I don't know what I will be doing 
at any particular time.  It depends on what work is available to me.



If you come to Switzerland, tell me!


I certainly will.  There are a few of you in the area whom I will 
contact when we pass through.


Peter
--
Peter B. West 
Folio 
 <- the atTridged version

Re: Foray's font subsystem for Fop

[Peter B. West]

Thomas DeWeese wrote:

Hi All,

  Just to throw in my 2 cents.   Batik "Handles" this through the
@font-face CSS property.  This allows you to provide a mapping
from a CSS font-family (with weight etc) to a font file on disk/network
etc:

@font-face { font-family: "CSS Batik SVGFont";
 src: url(batikFont.svg#Batik); }


CSS2 is, of course, the basis for XSL-FO font selection.  The (partially 
realized) Java font selection methodology is similar in approach.




Peter B. West wrote:


J.Pietschmann wrote:


Jeremias Maerki wrote:

Ok, but this assumes that you work in concert with AWT's font 
subsystem.



Well, AWT doesn't provide a way to get the file for a font, but
we can at least get an AWT Font from a TTF file.



And a Type1 file (Java 5).  Java just keeps getting better.



   This is _very_ interesting.  Do you have a reference on this?
Illustrator has a bad habit of embedding CEF (CFF?) fonts in
SVG - these are Type1 font outlines in a TrueType/OpenType wrapper
If the JDK supports Type1 fonts it might support these now as well
(hoping ;).


The 1.5 API for java.awt.Font.

Peter
--
Peter B. West 
Folio 
 <- the atTridged version

RE: OT: Moving to UK? (RE: Foray's font subsystem for Fop)

[Andreas L. Delmelle]

> -Original Message-
> From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
>

Hi Jeremias,

> Do you, by chance, intend to visit ApacheCon in Stuttgart in July?

(I take this 'you' to be plural)
Me personally, I did intend to visit when I first received word, but
unfortunately I wasn't able to get the necessary time off... A shame though,
so close. :-(

> If you come to Switzerland, tell me!

Will certainly do so. I do want to travel to Switzerland very much --in my
dreams, I even have a house there :-) Ah well, who knows, one day...


Cheers,

Andreas

Re: OT: Moving to UK? (RE: Foray's font subsystem for Fop)

[Jeremias Maerki]

Do you, by chance, intend to visit ApacheCon in Stuttgart in July?

If you come to Switzerland, tell me!

On 15.06.2005 18:52:22 Peter B. West wrote:
> Andreas L. Delmelle wrote:
> >>-Original Message-
> >>From: Peter B. West [mailto:[EMAIL PROTECTED]
> >>
> > 
> > 
> > Hi Peter,
> > 
> > 
> >>..., and Jenni and I are moving to the UK for 12
> >>months at the end of June, ...
> > 
> > 
> > Well, if you have plans to cross the channel and visit Belgium during those
> > 12 months, be sure to drop me a line. Maybe we can get together for a beer
> > :-)
> > 
> 
> We plan to cross the channel many, many times.  Can't wait to have that 
> beer.
> 
> > 
> > Cheers,
> > 
> > Andreas
> > 
> 
> Peter
> -- 
> Peter B. West 
> Folio 
>  <- the atTridged version



Jeremias Maerki

Re: OT: Moving to UK? (RE: Foray's font subsystem for Fop)

[Peter B. West]

Andreas L. Delmelle wrote:

-Original Message-
From: Peter B. West [mailto:[EMAIL PROTECTED]




Hi Peter,



..., and Jenni and I are moving to the UK for 12
months at the end of June, ...



Well, if you have plans to cross the channel and visit Belgium during those
12 months, be sure to drop me a line. Maybe we can get together for a beer
:-)



We plan to cross the channel many, many times.  Can't wait to have that 
beer.




Cheers,

Andreas



Peter
--
Peter B. West 
Folio 
 <- the atTridged version

OT: Moving to UK? (RE: Foray's font subsystem for Fop)

[Andreas L. Delmelle]

> -Original Message-
> From: Peter B. West [mailto:[EMAIL PROTECTED]
>

Hi Peter,

> ..., and Jenni and I are moving to the UK for 12
> months at the end of June, ...

Well, if you have plans to cross the channel and visit Belgium during those
12 months, be sure to drop me a line. Maybe we can get together for a beer
:-)


Cheers,

Andreas

Re: Foray's font subsystem for Fop

[Jeremias Maerki]

http://java.sun.com/j2se/1.5.0/docs/api/java/awt/Font.html#createFont(int,%20java.io.InputStream)
http://java.sun.com/j2se/1.5.0/docs/api/java/awt/Font.html#TYPE1_FONT
http://java.sun.com/j2se/1.5.0/docs/guide/2d/new_features.html#createFont

Reading what's there I don't have high hopes that you can load CEF fonts.

See also:
http://support.adobe.com/devsup/devsup.nsf/docs/50568.htm

If we were able to figure out in what specification CEF is documented
and the embedded font data were a full Type 1 font, it shouldn't be hard
to extract it from a stream. I currently don't see through there: CEF,
CFF, Type 2, TrueType, OpenType, blah, blah, blah. A real mess.

On 15.06.2005 15:35:37 Thomas DeWeese wrote:
> Hi All,
> 
>Just to throw in my 2 cents.   Batik "Handles" this through the
> @font-face CSS property.  This allows you to provide a mapping
> from a CSS font-family (with weight etc) to a font file on disk/network
> etc:
> 
>  @font-face { font-family: "CSS Batik SVGFont";
>   src: url(batikFont.svg#Batik); }
> 
> Peter B. West wrote:
> > J.Pietschmann wrote:
> > 
> >> Jeremias Maerki wrote:
> >>
> >>> Ok, but this assumes that you work in concert with AWT's font subsystem.
> >>
> >> Well, AWT doesn't provide a way to get the file for a font, but
> >> we can at least get an AWT Font from a TTF file.
> > 
> > And a Type1 file (Java 5).  Java just keeps getting better.
> 
> This is _very_ interesting.  Do you have a reference on this?
> Illustrator has a bad habit of embedding CEF (CFF?) fonts in
> SVG - these are Type1 font outlines in a TrueType/OpenType wrapper
> If the JDK supports Type1 fonts it might support these now as well
> (hoping ;).



Jeremias Maerki

Re: Foray's font subsystem for Fop

[Thomas DeWeese]

Hi All,

  Just to throw in my 2 cents.   Batik "Handles" this through the
@font-face CSS property.  This allows you to provide a mapping
from a CSS font-family (with weight etc) to a font file on disk/network
etc:

@font-face { font-family: "CSS Batik SVGFont";
 src: url(batikFont.svg#Batik); }

Peter B. West wrote:

J.Pietschmann wrote:


Jeremias Maerki wrote:


Ok, but this assumes that you work in concert with AWT's font subsystem.


Well, AWT doesn't provide a way to get the file for a font, but
we can at least get an AWT Font from a TTF file.


And a Type1 file (Java 5).  Java just keeps getting better.


   This is _very_ interesting.  Do you have a reference on this?
Illustrator has a bad habit of embedding CEF (CFF?) fonts in
SVG - these are Type1 font outlines in a TrueType/OpenType wrapper
If the JDK supports Type1 fonts it might support these now as well
(hoping ;).

RE: Foray's font subsystem for Fop

[Rick Bullotta]

Let's not even start discussing the intellectual property implications that are 
starting to surface...



From: Peter B. West [mailto:[EMAIL PROTECTED]
Sent: Tue 6/14/2005 9:22 PM
To: fop-dev@xmlgraphics.apache.org
Subject: Re: Foray's font subsystem for Fop



J.Pietschmann wrote:
> Vincent Hennebert wrote:
>
>> I was starting to wonder what I could have done wrong so that things
>> turn out that way.
>
>
> Just ignore the bickering for now. There seems to be a law that every
> Open Source project (or any other reasonably open project for that
> matter) sooner or later will get people with incompatible personalities,
> resulting in some mud slinging on mailing lists or worse. Notice the
> dismissal of one of the core BSD core developers last year, regular
> flame wars on the Linux Ethernet driver lists including heavy name
> calling and mutual allegations of incompetence, the fork of
> Geronimo off JBoss with associated ugliness and so on.
>
> No need for you to worry.

Let's not forget Linus v. President Tridgell, a dispute with somewhat
wider impact.

It's almost as bad as proprietary projects, but everything is on public
view, everyone gets to express an opinion, and the individuals have real
alternatives on how to proceed after disagreements.

Peter
--
Peter B. West <http://cv.pbw.id.au/>
Folio <http://defoe.sourceforge.net/folio/>
<http://folio.bkbits.net/> <- the atTridged version


<>

Re: Foray's font subsystem for Fop

[Peter B. West]

J.Pietschmann wrote:

Vincent Hennebert wrote:

I was starting to wonder what I could have done wrong so that things 
turn out that way.



Just ignore the bickering for now. There seems to be a law that every
Open Source project (or any other reasonably open project for that
matter) sooner or later will get people with incompatible personalities,
resulting in some mud slinging on mailing lists or worse. Notice the
dismissal of one of the core BSD core developers last year, regular
flame wars on the Linux Ethernet driver lists including heavy name
calling and mutual allegations of incompetence, the fork of
Geronimo off JBoss with associated ugliness and so on.

No need for you to worry.


Let's not forget Linus v. President Tridgell, a dispute with somewhat 
wider impact.


It's almost as bad as proprietary projects, but everything is on public 
view, everyone gets to express an opinion, and the individuals have real 
alternatives on how to proceed after disagreements.


Peter
--
Peter B. West 
Folio 
 <- the atTridged version

Re: Foray's font subsystem for Fop

[Peter B. West]

J.Pietschmann wrote:

Jeremias Maerki wrote:


Ok, but this assumes that you work in concert with AWT's font subsystem.



Well, AWT doesn't provide a way to get the file for a font, but
we can at least get an AWT Font from a TTF file.


And a Type1 file (Java 5).  Java just keeps getting better.

Peter
--
Peter B. West 
Folio 
 <- the atTridged version

Re: Foray's font subsystem for Fop

[Peter B. West]

Jeremias Maerki wrote:

On 14.06.2005 17:59:03 Victor Mote wrote:



That whole idea deserves more thought and experimentation,
and I haven't had time to work on the font system since October.




Victor, I have been experiencing similar frustrations, and Jenni and I 
are moving to the UK for 12 months at the end of June, so I don't expect 
to have any concentrated development time for a while.




Absolutely. It would be great if it could be made to work but I
seriously doubt it. At any rate I wish Peter the best of luck with his
approach. I hope he'll be a happy customer of our Graphics2D
implementations when they are separated in the XML Graphics Commons area.
:-)


I certainly hope so.

Peter
--
Peter B. West 
Folio 
 <- The atTridged version

Re: Foray's font subsystem for Fop

[Peter B. West]

Victor Mote wrote:

Jeremias Maerki wrote:



Just to be clear, these are the possibilities:
1. FOP uses FOray-Font (JAR file in lib directory), no 
license grant necessary, no FOray sources in an ASF repository.



This is my preference.


2. FOP forks FOray-Font, license grants are necessary due to 
ASF policy.



I will be happy to provide such a grant.


3. You donate FOray-Font (back) to the ASF, development 
within FOray stops, FOray uses a JAR from XML Graphics 
Commons, development continues within the XML Graphics 
Commons area, license grants are necessary due to ASF policy.



This is essentially what I tried to do from within FOP. It failed miserably.
I cannot afford to make that mistake again. More to come later by way of
answer to your other emails.


I have an interest in the future of FOray-Font, so my preference is 
shared with Victor.


Peter
--
Peter B. West 
Folio 
 <- The atTridged version

Re: Foray's font subsystem for Fop

[Jeremias Maerki]

On 14.06.2005 23:27:44 J.Pietschmann wrote:
> Jeremias Maerki wrote:
> > Relying on static
> > variables in the case of logging is not necessarily bad.
> 
> *cough* This depends on whether a single logger for all threads
> is not necessarily bad. I personally would probably prefer the
> possibility to direct logging for different threads into different
> destinations.

Me too, if you read everything I wrote. And you can strike the "probably"
for me. That statement was pretty general. That's why I talked about an
application-specific interface for special logging and notification
purposes. You could place the instance in a thread-local. Probably not
all logging needs to be per processing run. But some applications will
want specific and ideally parseable info back.


Jeremias Maerki

Re: Foray's font subsystem for Fop

[Jeremias Maerki]

On 14.06.2005 23:21:51 J.Pietschmann wrote:
> Vincent Hennebert wrote:
> > I was starting to 
> > wonder what I could have done wrong so that things turn out that way.
> 
> Just ignore the bickering for now. There seems to be a law that every
> Open Source project (or any other reasonably open project for that
> matter) sooner or later will get people with incompatible personalities,
> resulting in some mud slinging on mailing lists or worse. Notice the
> dismissal of one of the core BSD core developers last year, regular
> flame wars on the Linux Ethernet driver lists including heavy name
> calling and mutual allegations of incompetence, the fork of
> Geronimo off JBoss with associated ugliness and so on.

Not to mention the expulsion of an ASF committer from the Avalon project.
And later the violent shutdown of that project.

> No need for you to worry.
> 
> J.Pietschmann



Jeremias Maerki

Re: Foray's font subsystem for Fop

[J.Pietschmann]

Jeremias Maerki wrote:

Relying on static
variables in the case of logging is not necessarily bad.


*cough* This depends on whether a single logger for all threads
is not necessarily bad. I personally would probably prefer the
possibility to direct logging for different threads into different
destinations.

Some times ago Sun asked for ideas for language features for
the next major Java version, and closures were brought up on
jakarta general. I couldn't think of a use case in a language
with compile time variable binding, but now I think I should
reconsider...

J.Pietschmann

Re: Foray's font subsystem for Fop

[J.Pietschmann]

Vincent Hennebert wrote:
I was starting to 
wonder what I could have done wrong so that things turn out that way.


Just ignore the bickering for now. There seems to be a law that every
Open Source project (or any other reasonably open project for that
matter) sooner or later will get people with incompatible personalities,
resulting in some mud slinging on mailing lists or worse. Notice the
dismissal of one of the core BSD core developers last year, regular
flame wars on the Linux Ethernet driver lists including heavy name
calling and mutual allegations of incompetence, the fork of
Geronimo off JBoss with associated ugliness and so on.

No need for you to worry.

J.Pietschmann

Re: Foray's font subsystem for Fop

[J.Pietschmann]

Jeremias Maerki wrote:

Ok, but this assumes that you work in concert with AWT's font subsystem.


Well, AWT doesn't provide a way to get the file for a font, but
we can at least get an AWT Font from a TTF file.

J.Pietschmann

RE: Foray's font subsystem for Fop

[Victor Mote]

Jeremias Maerki wrote:

> > Most people will want to point the auto-registration to 
> C:\WINDOWS\FONTS.
> > Mine has 581 files in it, each of which would have to be opened and 
> > partially parsed. I actually use no more than 10-15 for FO work. I 
> > think this might actually open up a bunch of potentially 
> ugly support 
> > issues, and I would think twice about it. Nevertheless, it 
> can be done.
> 
> Not necessarily. I thought about that. We would have to 
> create some sort of font cache file which holds the most 
> important info to avoid parsing every font before it's really 
> used. I've seen that even the old Acrobat Reader 4.05 on 
> Linux did something like that.

It is an interesting idea. I would probably tend to implement it, at least
in the beginning, as a batch job that simply reads a directory of font files
and spits out a font-configuration file for the contents of that directory.
That saves the user some trouble, but still gives him control (and
responsibility) over the output. If your application tries to take
responsibility for this, then you will end up needing to reconcile the cache
with reality every time anyway, which defeats the purpose of the cache.
There is a good reason that fonts tend to evolve into an o/s service.

Victor Mote

RE: Foray's font subsystem for Fop

[Victor Mote]

Jeremias Maerki wrote:

> > Most people will want to point the auto-registration to 
> C:\WINDOWS\FONTS.
> > Mine has 581 files in it, each of which would have to be opened and 
> > partially parsed. I actually use no more than 10-15 for FO work. I 
> > think this might actually open up a bunch of potentially 
> ugly support 
> > issues, and I would think twice about it. Nevertheless, it 
> can be done.
> 
> Not necessarily. I thought about that. We would have to 
> create some sort of font cache file which holds the most 
> important info to avoid parsing every font before it's really 
> used. I've seen that even the old Acrobat Reader 4.05 on 
> Linux did something like that.

It is an interesting idea. I would probably tend to implement it, at least
in the beginning, as a batch job that simply reads a directory of font files
and spits out a font-configuration file for the contents of that directory.
That saves the user some trouble, but still gives him control (and
responsibility) over the output. If your application tries to take
responsibility for this, then you will end up needing to reconcile the cache
with reality every time anyway, which defeats the purpose of the cache.
There is a good reason that fonts tend to evolve into an o/s service.

Victor Mote

Re: Foray's font subsystem for Fop

[Jeremias Maerki]

On 14.06.2005 17:59:03 Victor Mote wrote:
> Jeremias Maerki wrote:
> 
> > Ok, but this assumes that you work in concert with AWT's font 
> > subsystem.
> > If we talk about the font subsystem for PDF and PS we have 
> > all liberties we want. If we can give the FO processor a 
> > directory and it makes all the fonts in this directory 
> > available for FO processing then I am where I would like to 
> > be. Of course, there will be some additional topic such as 
> 
> This is very doable (although I would not have thought to call it
> auto-registration). Foray does not rely on anything in the font
> configuration to tell it what kind of font file it is working on -- in other
> words, it parses enough of each file already to create instances of the
> correct font subclass. It would not be hard to write a method that opens a
> directory and creates font instances for each file in that directory. Except
> ...
> 
> > font substitution and embedding control, but if we can make 
> 
> ... and even font naming. One of the things that the configuration file does
> is provide (at least potentially) an unambiguous and cross-platform way of
> declaring the relationships between fonts in various families and the
> mapping between what they are called in an FO document and how they are
> found in the system.

That's actually what I meant by font substitution. It's good we talked
about it. ;-) 

> > the font registration a no-brainer for at least 60% of the 
> > people we've accomplished a lot. The Java2D/AWT renderer is a 
> > different story. There we have to work with what we are 
> > given. I really wonder if Peter will really stay with the 
> > 100% AWT approach till the end.
> 
> Most people will want to point the auto-registration to C:\WINDOWS\FONTS.
> Mine has 581 files in it, each of which would have to be opened and
> partially parsed. I actually use no more than 10-15 for FO work. I think
> this might actually open up a bunch of potentially ugly support issues, and
> I would think twice about it. Nevertheless, it can be done.

Not necessarily. I thought about that. We would have to create some sort
of font cache file which holds the most important info to avoid parsing
every font before it's really used. I've seen that even the old Acrobat
Reader 4.05 on Linux did something like that.

> As far as Peter's ideas in this area, I want to spend more time on them.
> There is a great divide in FOrayFont between what we call FreeStandingFont
> (those read from disk) and SystemFont (the AWT fonts). Ideally it would be
> nice for those to be merged. Since an AWT font can be created from a font on
> disk, if those metrics are suitable for layout, then the disk font can be
> used for embedding (this can't be done with AWT fonts returned by the java
> runtime, because it doesn't tell you where the physical file is or what are
> its contents).

And the reported metrics seem to be different!

> That whole idea deserves more thought and experimentation,
> and I haven't had time to work on the font system since October.

Absolutely. It would be great if it could be made to work but I
seriously doubt it. At any rate I wish Peter the best of luck with his
approach. I hope he'll be a happy customer of our Graphics2D
implementations when they are separated in the XML Graphics Commons area.
:-)


Jeremias Maerki

Re: Foray's font subsystem for Fop

[Jeremias Maerki]

On 14.06.2005 17:29:01 Victor Mote wrote:
> Jeremias Maerki wrote:
> 
> > The logging problem is a minor one. There's a wrapper for JCL 
> > that easily wraps an Avalon Logger [1]. But that's obviously 
> > the exact opposite of what you need. On the other side, 
> > creating an implementation of Avalon's Logger interface that 
> > wraps a JCL logger should be just as easy. Unfortunately, 
> > such a class doesn't exist, yet, but that's written within 10 minutes.
> > 
> > Let me explain why we switched from Avalon Logging to JCL. 
> > Avalon Loggers are always passed from container to child 
> > object (Inversion of Control). A class using a JCL logger 
> > always fetches a logger from a factory. So the difference is 
> > in acquiring a logger but there's also another aspect: With 
> > Avalon Logger you can use different loggers on different 
> > instances of the same class which you can't if you use the 
> > normal JCL pattern of using a static variable for holding the logger.
> > The static variable has certain advantages, too: You don't 
> > need a variable on every object instance and you don't have 
> > to pass Loggers all around in the system, which is 
> > particularly problematic or at least cumbersome in FOP. JCL 
> > makes many thing easier.
> > 
> > But as I hinted above there's no problem connecting the two 
> > approaches.
> > Both are light-weight and therefore easy to handle.
> > 
> > [1] 
> > http://jakarta.apache.org/commons/logging/api/org/apache/commo
> > ns/logging/impl/AvalonLogger.html
> 
> Thanks for the explanation. I went to a lot of trouble in FOray, mostly
> based on past conversations with you, to remove all such static-ish things,
> and I probably won't do anything that would require a client application to
> use anything like that. But maybe there are some other things that can be
> done.

I've seen that work and I'm sure it was worth it. Relying on static
variables in the case of logging is not necessarily bad. I know I
advocated the use of Avalon Logger at that time. I still think it is
good. The big advantage is really to be able to provide a new logger
instance for each processing run so you can log each document separately
which you can't if you use JCL's static logging pattern. But I've
learned from several people as well as from my own experience that
especially in the case of FOP the Avalon Logging approach can be
annoying and that per-processing-run loggin should be done through a
different mechanism, such as specialized, application-specific
interfaces. I haven't been able to get to the latter, yet. It's one of
my long term goals to provide better feedback to the caller about layout
problems or progress, as well as cleaner exception throwing.

> Foray addresses the logging problem through its tree organization
> (everything is a tree), and storing the Logger instance at the top of the
> tree, each child node being able to get the Logger instance from its parent.

The question here, of course, is if it is performant. It's probably ver
little but still, in a deep tree a logging call causes a number of
method calls to determine the logger instance.

> The only times it needs to get passed as a parameter is when moving from one
> module to another. So, for example if PDFDocument is at the top of the tree
> in the FOrayPDF module, it probably requires a Logger in its constructor,

The pure Avalon spirit would be to have that class implement LogEnabled.

> but then makes it available to all of its children. In some cases (like
> FOrayFont) it must be provided through an interface to keep the module as
> independent as it needs.
> 
> During our previous Inversion of Control discussion, I briefly toyed with
> the idea of having the FontConsumer provide a method *to do its own
> logging*. So, rather than FontConsumer providing a Logger to FontServer
> (which you did not like), it would instead provide something like:

The whole discussion there was problematic because I didn't really have
time to explain everything to you. But again, I think it was worth it
from what I can see.

>   public void logMessage(String message, int messageLevel) ;
>
> where messageLevel would indicate whether the message was debug, error,
> warning, etc. The things I dislike about this are 1) it is YALP (yet another
> logging protocol), which is what I understood Avalon to be trying to unify,
> and 2) it requires the client side to write code that seems pretty
> redundant. However, it is a pretty generic solution.
> 
> One alternative would be for FontServer and FontConsumer to both allow
> Commons loggers as well as Avalon loggers, and for it to deal with the
> wrapping, etc. If it will help and if there are no better ideas, I am
> willing to do this.

I'd leave it as-is for the moment. As I said earlier, I believe it's
very easy to wrap a JCL logger into an Avalon Logger and pass that into
FontServer and FontConsumer. I'd even say you're on the safer side than
FOP because with the static logg

RE: Foray's font subsystem for Fop

[Victor Mote]

Jeremias Maerki wrote:

> Ok, but this assumes that you work in concert with AWT's font 
> subsystem.
> If we talk about the font subsystem for PDF and PS we have 
> all liberties we want. If we can give the FO processor a 
> directory and it makes all the fonts in this directory 
> available for FO processing then I am where I would like to 
> be. Of course, there will be some additional topic such as 

This is very doable (although I would not have thought to call it
auto-registration). Foray does not rely on anything in the font
configuration to tell it what kind of font file it is working on -- in other
words, it parses enough of each file already to create instances of the
correct font subclass. It would not be hard to write a method that opens a
directory and creates font instances for each file in that directory. Except
...

> font substitution and embedding control, but if we can make 

... and even font naming. One of the things that the configuration file does
is provide (at least potentially) an unambiguous and cross-platform way of
declaring the relationships between fonts in various families and the
mapping between what they are called in an FO document and how they are
found in the system.

> the font registration a no-brainer for at least 60% of the 
> people we've accomplished a lot. The Java2D/AWT renderer is a 
> different story. There we have to work with what we are 
> given. I really wonder if Peter will really stay with the 
> 100% AWT approach till the end.

Most people will want to point the auto-registration to C:\WINDOWS\FONTS.
Mine has 581 files in it, each of which would have to be opened and
partially parsed. I actually use no more than 10-15 for FO work. I think
this might actually open up a bunch of potentially ugly support issues, and
I would think twice about it. Nevertheless, it can be done.

As far as Peter's ideas in this area, I want to spend more time on them.
There is a great divide in FOrayFont between what we call FreeStandingFont
(those read from disk) and SystemFont (the AWT fonts). Ideally it would be
nice for those to be merged. Since an AWT font can be created from a font on
disk, if those metrics are suitable for layout, then the disk font can be
used for embedding (this can't be done with AWT fonts returned by the java
runtime, because it doesn't tell you where the physical file is or what are
its contents). That whole idea deserves more thought and experimentation,
and I haven't had time to work on the font system since October.

Victor Mote

RE: Foray's font subsystem for Fop

[Victor Mote]

Jeremias Maerki wrote:

> Ok, but this assumes that you work in concert with AWT's font 
> subsystem.
> If we talk about the font subsystem for PDF and PS we have 
> all liberties we want. If we can give the FO processor a 
> directory and it makes all the fonts in this directory 
> available for FO processing then I am where I would like to 
> be. Of course, there will be some additional topic such as 

This is very doable (although I would not have thought to call it
auto-registration). Foray does not rely on anything in the font
configuration to tell it what kind of font file it is working on -- in other
words, it parses enough of each file already to create instances of the
correct font subclass. It would not be hard to write a method that opens a
directory and creates font instances for each file in that directory. Except
...

> font substitution and embedding control, but if we can make 

... and even font naming. One of the things that the configuration file does
is provide (at least potentially) an unambiguous and cross-platform way of
declaring the relationships between fonts in various families and the
mapping between what they are called in an FO document and how they are
found in the system.

> the font registration a no-brainer for at least 60% of the 
> people we've accomplished a lot. The Java2D/AWT renderer is a 
> different story. There we have to work with what we are 
> given. I really wonder if Peter will really stay with the 
> 100% AWT approach till the end.

Most people will want to point the auto-registration to C:\WINDOWS\FONTS.
Mine has 581 files in it, each of which would have to be opened and
partially parsed. I actually use no more than 10-15 for FO work. I think
this might actually open up a bunch of potentially ugly support issues, and
I would think twice about it. Nevertheless, it can be done.

As far as Peter's ideas in this area, I want to spend more time on them.
There is a great divide in FOrayFont between what we call FreeStandingFont
(those read from disk) and SystemFont (the AWT fonts). Ideally it would be
nice for those to be merged. Since an AWT font can be created from a font on
disk, if those metrics are suitable for layout, then the disk font can be
used for embedding (this can't be done with AWT fonts returned by the java
runtime, because it doesn't tell you where the physical file is or what are
its contents). That whole idea deserves more thought and experimentation,
and I haven't had time to work on the font system since October.

Victor Mote

RE: Foray's font subsystem for Fop

[Victor Mote]

Jeremias Maerki wrote:

> The logging problem is a minor one. There's a wrapper for JCL 
> that easily wraps an Avalon Logger [1]. But that's obviously 
> the exact opposite of what you need. On the other side, 
> creating an implementation of Avalon's Logger interface that 
> wraps a JCL logger should be just as easy. Unfortunately, 
> such a class doesn't exist, yet, but that's written within 10 minutes.
> 
> Let me explain why we switched from Avalon Logging to JCL. 
> Avalon Loggers are always passed from container to child 
> object (Inversion of Control). A class using a JCL logger 
> always fetches a logger from a factory. So the difference is 
> in acquiring a logger but there's also another aspect: With 
> Avalon Logger you can use different loggers on different 
> instances of the same class which you can't if you use the 
> normal JCL pattern of using a static variable for holding the logger.
> The static variable has certain advantages, too: You don't 
> need a variable on every object instance and you don't have 
> to pass Loggers all around in the system, which is 
> particularly problematic or at least cumbersome in FOP. JCL 
> makes many thing easier.
> 
> But as I hinted above there's no problem connecting the two 
> approaches.
> Both are light-weight and therefore easy to handle.
> 
> [1] 
> http://jakarta.apache.org/commons/logging/api/org/apache/commo
> ns/logging/impl/AvalonLogger.html

Thanks for the explanation. I went to a lot of trouble in FOray, mostly
based on past conversations with you, to remove all such static-ish things,
and I probably won't do anything that would require a client application to
use anything like that. But maybe there are some other things that can be
done.

Foray addresses the logging problem through its tree organization
(everything is a tree), and storing the Logger instance at the top of the
tree, each child node being able to get the Logger instance from its parent.
The only times it needs to get passed as a parameter is when moving from one
module to another. So, for example if PDFDocument is at the top of the tree
in the FOrayPDF module, it probably requires a Logger in its constructor,
but then makes it available to all of its children. In some cases (like
FOrayFont) it must be provided through an interface to keep the module as
independent as it needs.

During our previous Inversion of Control discussion, I briefly toyed with
the idea of having the FontConsumer provide a method *to do its own
logging*. So, rather than FontConsumer providing a Logger to FontServer
(which you did not like), it would instead provide something like:

public void logMessage(String message, int messageLevel) ;

where messageLevel would indicate whether the message was debug, error,
warning, etc. The things I dislike about this are 1) it is YALP (yet another
logging protocol), which is what I understood Avalon to be trying to unify,
and 2) it requires the client side to write code that seems pretty
redundant. However, it is a pretty generic solution.

One alternative would be for FontServer and FontConsumer to both allow
Commons loggers as well as Avalon loggers, and for it to deal with the
wrapping, etc. If it will help and if there are no better ideas, I am
willing to do this.

Victor Mote

RE: Foray's font subsystem for Fop

[Victor Mote]

Jeremias Maerki wrote:

> The logging problem is a minor one. There's a wrapper for JCL 
> that easily wraps an Avalon Logger [1]. But that's obviously 
> the exact opposite of what you need. On the other side, 
> creating an implementation of Avalon's Logger interface that 
> wraps a JCL logger should be just as easy. Unfortunately, 
> such a class doesn't exist, yet, but that's written within 10 minutes.
> 
> Let me explain why we switched from Avalon Logging to JCL. 
> Avalon Loggers are always passed from container to child 
> object (Inversion of Control). A class using a JCL logger 
> always fetches a logger from a factory. So the difference is 
> in acquiring a logger but there's also another aspect: With 
> Avalon Logger you can use different loggers on different 
> instances of the same class which you can't if you use the 
> normal JCL pattern of using a static variable for holding the logger.
> The static variable has certain advantages, too: You don't 
> need a variable on every object instance and you don't have 
> to pass Loggers all around in the system, which is 
> particularly problematic or at least cumbersome in FOP. JCL 
> makes many thing easier.
> 
> But as I hinted above there's no problem connecting the two 
> approaches.
> Both are light-weight and therefore easy to handle.
> 
> [1] 
> http://jakarta.apache.org/commons/logging/api/org/apache/commo
> ns/logging/impl/AvalonLogger.html

Thanks for the explanation. I went to a lot of trouble in FOray, mostly
based on past conversations with you, to remove all such static-ish things,
and I probably won't do anything that would require a client application to
use anything like that. But maybe there are some other things that can be
done.

Foray addresses the logging problem through its tree organization
(everything is a tree), and storing the Logger instance at the top of the
tree, each child node being able to get the Logger instance from its parent.
The only times it needs to get passed as a parameter is when moving from one
module to another. So, for example if PDFDocument is at the top of the tree
in the FOrayPDF module, it probably requires a Logger in its constructor,
but then makes it available to all of its children. In some cases (like
FOrayFont) it must be provided through an interface to keep the module as
independent as it needs.

During our previous Inversion of Control discussion, I briefly toyed with
the idea of having the FontConsumer provide a method *to do its own
logging*. So, rather than FontConsumer providing a Logger to FontServer
(which you did not like), it would instead provide something like:

public void logMessage(String message, int messageLevel) ;

where messageLevel would indicate whether the message was debug, error,
warning, etc. The things I dislike about this are 1) it is YALP (yet another
logging protocol), which is what I understood Avalon to be trying to unify,
and 2) it requires the client side to write code that seems pretty
redundant. However, it is a pretty generic solution.

One alternative would be for FontServer and FontConsumer to both allow
Commons loggers as well as Avalon loggers, and for it to deal with the
wrapping, etc. If it will help and if there are no better ideas, I am
willing to do this.

Victor Mote

Re: Foray's font subsystem for Fop

[Jeremias Maerki]

Ok, but this assumes that you work in concert with AWT's font subsystem.
If we talk about the font subsystem for PDF and PS we have all liberties
we want. If we can give the FO processor a directory and it makes all
the fonts in this directory available for FO processing then I am where
I would like to be. Of course, there will be some additional topic such
as font substitution and embedding control, but if we can make the font
registration a no-brainer for at least 60% of the people we've
accomplished a lot. The Java2D/AWT renderer is a different story. There
we have to work with what we are given. I really wonder if Peter will
really stay with the 100% AWT approach till the end.

On 14.06.2005 16:16:09 Victor Mote wrote:
> Based on current constraints, I don't think automatic font registration is
> possible. In order to embed a font, you have to have access to the
> underlying file or at least its contents. Until Java gives us this in its
> own AWT system, you're going to have to get this information somewhere else.
> Peter West and I have discussed an interesting idea that I want to explore
> further, which is taking the external registration information and using it
> to create System (AWT) fonts -- but that still requires an external
> registration step.



Jeremias Maerki

Re: Foray's font subsystem for Fop

[Jeremias Maerki]

Thanks, Glen, for your statement earlier. And I apologize for jumping to
early conclusions about your expected behaviour. I've been burnt a few
times so I get jumpy.

Victor, your offer for write access on FOray for qualified developers is
greatly appreciated and does away with some of my fears about making
FOray-Font a FOP dependency. And thanks for taking the time for your
explanations.

So I think this is a matter of polling the remaining committers on what
they think about using FOray-Font (and aXSL for that matter) a
dependency of FOP (binary JAR file in the lib dir), so we can profit
from a better font support. I'd appreciate any statements even if it's a
"don't care". We'd have a volunteer who would do it for us, and I'd
certainly keep an eye on it and serve as reviewer. But I don't have time
to do the actual foot work here.


Jeremias Maerki

RE: Foray's font subsystem for Fop

[Victor Mote]

Glen Mazza wrote:

> I think Victor said he didn't want to collaborate anymore:
> 
> http://marc.theaimsgroup.com/?l=fop-dev&m=111263144615399&w=2
> http://marc.theaimsgroup.com/?l=fop-dev&m=111265443425492&w=2

Even those on this list who are not native English speakers will be able to
easily understand the difference between "my efforts at collaboration
between our two projects have utterly failed at every level" and "I don't
want to collaborate anymore".

> Again, I will stay out of it if another worked with his code. 
>  I don't have time for the font work, but certainly recognize 
> it needs improvement.  I'm in layout now--if I don't like the 
> front end it doesn't matter (as much!) anymore, I am now past it.
> 
> But we've had Victor's front-end architecture for the first 
> of my two years here and my mathematical reduction of it for 
> the second. 

This actually confirms what I have suspected all along. You never ever EVER
saw my front-end architecture. It never made it into FOP. If I had a list of
1000 changes that needed to be made, you took a snapshot after #9 had just
been completed and decided that because that did not meet your standards, it
should be killed. It didn't meet anyone's standards, certainly not mine.

> Improvements on layout have been much more rapid in the second year.

This is pure speculation with no shred of reasonable nexus. I have a
favorite "alternate history" theory as well that has FOP modularization work
done in March, 2004, FOP 0.21 released in April, 2004. At this point ALL
modules can be improved without giving up benefits of working code, and
developers start doing so. Font refactoring is completed by July, 2004. That
and other improvements were released in August, 2004, and Victor was then
free to work on the new layout system. Mine is just as much speculation as
yours (although I can point to how it worked in FOray).

Victor Mote

RE: Foray's font subsystem for Fop

[Victor Mote]

Glen Mazza wrote:

> I think Victor said he didn't want to collaborate anymore:
> 
> http://marc.theaimsgroup.com/?l=fop-dev&m=111263144615399&w=2
> http://marc.theaimsgroup.com/?l=fop-dev&m=111265443425492&w=2

Even those on this list who are not native English speakers will be able to
easily understand the difference between "my efforts at collaboration
between our two projects have utterly failed at every level" and "I don't
want to collaborate anymore".

> Again, I will stay out of it if another worked with his code. 
>  I don't have time for the font work, but certainly recognize 
> it needs improvement.  I'm in layout now--if I don't like the 
> front end it doesn't matter (as much!) anymore, I am now past it.
> 
> But we've had Victor's front-end architecture for the first 
> of my two years here and my mathematical reduction of it for 
> the second. 

This actually confirms what I have suspected all along. You never ever EVER
saw my front-end architecture. It never made it into FOP. If I had a list of
1000 changes that needed to be made, you took a snapshot after #9 had just
been completed and decided that because that did not meet your standards, it
should be killed. It didn't meet anyone's standards, certainly not mine.

> Improvements on layout have been much more rapid in the second year.

This is pure speculation with no shred of reasonable nexus. I have a
favorite "alternate history" theory as well that has FOP modularization work
done in March, 2004, FOP 0.21 released in April, 2004. At this point ALL
modules can be improved without giving up benefits of working code, and
developers start doing so. Font refactoring is completed by July, 2004. That
and other improvements were released in August, 2004, and Victor was then
free to work on the new layout system. Mine is just as much speculation as
yours (although I can point to how it worked in FOray).

Victor Mote

Re: Foray's font subsystem for Fop

[Vincent Hennebert]

Hello Jeremias,

I must convey that your answer was a relief for me ;-) I was starting to wonder 
what I could have done wrong so that things turn out that way.


I keep your technical comments in mind for later, if I eventually may work on 
this. Don't worry about the time I've already spent on: it was necessary for me 
to feel capable of working on it. And while doing that I have discovered things 
that can be useful for other tasks.


I'm just discovering the political side of open-source development. I guess it 
can't be avoided but I just hope that it will not prevent Fop from becoming the 
world's best FO processor. I think this goal is not that far away from some 
others' [1]. Can't we try to calm down personal conflicts and put the stress on 
technical quality?


I'm providing fresh blood. I'm not aware of past conflicts. Perhaps I can act as 
a bridge between two different points of vue...


I'm still proposing to work on FOrayFont. In a technical point of vue it would 
IMO be best to share a common code repository between the two projects. If it 
appears not to be possible Victor will surely accept making a donation, and then 
Fop can always develop its own improvements and adaptations on this basis. 
However, I wouldn't like this eventuality, towards Victor.


Now perhaps that making a 1.0 release is a priority, at which case I can wait 
before doing the work. In the meanwhile I can find other things to work on. 
Perhaps it would be an additional benefit for a 1.0 release to have an improved 
font subsystem, though.


Team, I'm now letting you make your decision. I'm keeping being connected.

Regards,
Vincent

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

RE: Foray's font subsystem for Fop

[Victor Mote]

Jeremias Maerki wrote:

> To state my opinion on this matter:
> I would like to see Vincent integrating FOray-Font into FOP. 
> There has been some work on fonts compared to the FOP 
> maintenance branch but Victor has invested more time in 
> FOray-Font. Victor's font subsystem is now technically more 
> advanced than what we have. The most interesting feature is 
> the fact that you don't have to create that bloody font 
> metrics file anymore. When that is eventually coupled with 
> automatic font registration then it'll be a killer feature. I 

Based on current constraints, I don't think automatic font registration is
possible. In order to embed a font, you have to have access to the
underlying file or at least its contents. Until Java gives us this in its
own AWT system, you're going to have to get this information somewhere else.
Peter West and I have discussed an interesting idea that I want to explore
further, which is taking the external registration information and using it
to create System (AWT) fonts -- but that still requires an external
registration step.

> consider this one of the more important tasks to improve 
> user-friendliness. Of course, the same functionality could 
> also be done within FOP but why duplicate the effort? I'm 
> sure there are still a few things that would need to be 
> polished inside FOray-Font but if it helps us taking a step 
> forward then I'm all for it. But that's obviously my 
> technical side speaking.

There are a lot of improvements that need to be made to FOrayFont, but it is
in every respect IMO a "step forward" on every axis.

> Ideally, a font engine that is shared between two projects 
> should be in a more or less neutral place write-accessible by 
> both parties but as we've seen now there are personal 
> dissonances. The problem comes up if Glen starts to veto 

I have no problem with giving qualified FOP developers write access to
FOray. I have close to 3000 hours invested in FOray now, and I have no
intention of having that undone, so they'll need to provide some assurances
that they understand the "FOray way".

> against using Victor's work, of if Victor can't or won't 
> support our wishes anymore. The latter could be a real 
> problem if we switch to FOray-Font as it is a crucial part in 
> the puzzle. But Victor already provided a potential way to 
> improve that situation: aXSL.
> If we converted our current font engine to implement the aXSL 
> interface, we can easily switch. The downsides are the need 
> to maintain compatibility with aXSL as it advances and aXSL 
> has first to show that it is capable of handling multiple 
> implementations.

Also, see my previous email about grants. If you want, you can pull the
FOray code into your repository and hack away. I hope this will always be
considered a last resort, but I understand (all too well) the desire not to
invest in something that will come back and bite you badly.

> Looking at this from a distance:
> 1. From a technical perspective, we should work together, if 
> only to avoid being silly by duplicating work.
> 2. From a psychological perspective, I don't think the two 
> projects will ever get along.
> 
> That said, I think Victor and I get along together pretty 
> well. He doesn't even mind discussing stuff with me which is 
> a good sign. Too bad I got so little time discussing some 
> really interesting stuff with him, but I have to concentrate 
> on the layout engine ATM. But there are so many broken 
> glasses on both sides that I doubt we find a way of working together.

IMO, the reason you and I get along pretty well is that we are both trying
to get work done. If we start out disagreeing about something, we usually
eventually come to an agreement, because are guided by reason and common
goals. Most importantly, when we disagree, we say why, we try to either
teach or learn. I am quite capable of getting along with reasonable people,
changing my opinions, and learning from mistakes.

You say "I don't think the two projects will ever get along". I don't think
the two projects will ever by reunified, but I see no reason for them not to
get along. There is only one FOP developer that is likely to cause a
significant problem, and he has already promised to avoid the matter. And if
they can't, everyone's investment is protected.

> > If the FOP developers change their minds and decide to work 
> with you, good.
> > If not, please consider posting a message to the FOray mailing list 
> > telling me more about what you are trying to accomplish, 
> and I'll be 
> > glad to offer some suggestions if I can. FOray's design not 
> only makes 
> > it easier to use FOray code in FOP, but it makes it easier 
> to use FOP code in FOray.
> 
> That sounds like a suggestion for collaboration to me. Give 
> and take. I hope I'm right, Victor. You know I would really 
> like to work together with you again. It's simply that I'm 
> afraid of the old feelings come back (from whatever side) and 
> t

RE: Foray's font subsystem for Fop

[Victor Mote]

Jeremias Maerki wrote:

> To state my opinion on this matter:
> I would like to see Vincent integrating FOray-Font into FOP. 
> There has been some work on fonts compared to the FOP 
> maintenance branch but Victor has invested more time in 
> FOray-Font. Victor's font subsystem is now technically more 
> advanced than what we have. The most interesting feature is 
> the fact that you don't have to create that bloody font 
> metrics file anymore. When that is eventually coupled with 
> automatic font registration then it'll be a killer feature. I 

Based on current constraints, I don't think automatic font registration is
possible. In order to embed a font, you have to have access to the
underlying file or at least its contents. Until Java gives us this in its
own AWT system, you're going to have to get this information somewhere else.
Peter West and I have discussed an interesting idea that I want to explore
further, which is taking the external registration information and using it
to create System (AWT) fonts -- but that still requires an external
registration step.

> consider this one of the more important tasks to improve 
> user-friendliness. Of course, the same functionality could 
> also be done within FOP but why duplicate the effort? I'm 
> sure there are still a few things that would need to be 
> polished inside FOray-Font but if it helps us taking a step 
> forward then I'm all for it. But that's obviously my 
> technical side speaking.

There are a lot of improvements that need to be made to FOrayFont, but it is
in every respect IMO a "step forward" on every axis.

> Ideally, a font engine that is shared between two projects 
> should be in a more or less neutral place write-accessible by 
> both parties but as we've seen now there are personal 
> dissonances. The problem comes up if Glen starts to veto 

I have no problem with giving qualified FOP developers write access to
FOray. I have close to 3000 hours invested in FOray now, and I have no
intention of having that undone, so they'll need to provide some assurances
that they understand the "FOray way".

> against using Victor's work, of if Victor can't or won't 
> support our wishes anymore. The latter could be a real 
> problem if we switch to FOray-Font as it is a crucial part in 
> the puzzle. But Victor already provided a potential way to 
> improve that situation: aXSL.
> If we converted our current font engine to implement the aXSL 
> interface, we can easily switch. The downsides are the need 
> to maintain compatibility with aXSL as it advances and aXSL 
> has first to show that it is capable of handling multiple 
> implementations.

Also, see my previous email about grants. If you want, you can pull the
FOray code into your repository and hack away. I hope this will always be
considered a last resort, but I understand (all too well) the desire not to
invest in something that will come back and bite you badly.

> Looking at this from a distance:
> 1. From a technical perspective, we should work together, if 
> only to avoid being silly by duplicating work.
> 2. From a psychological perspective, I don't think the two 
> projects will ever get along.
> 
> That said, I think Victor and I get along together pretty 
> well. He doesn't even mind discussing stuff with me which is 
> a good sign. Too bad I got so little time discussing some 
> really interesting stuff with him, but I have to concentrate 
> on the layout engine ATM. But there are so many broken 
> glasses on both sides that I doubt we find a way of working together.

IMO, the reason you and I get along pretty well is that we are both trying
to get work done. If we start out disagreeing about something, we usually
eventually come to an agreement, because are guided by reason and common
goals. Most importantly, when we disagree, we say why, we try to either
teach or learn. I am quite capable of getting along with reasonable people,
changing my opinions, and learning from mistakes.

You say "I don't think the two projects will ever get along". I don't think
the two projects will ever by reunified, but I see no reason for them not to
get along. There is only one FOP developer that is likely to cause a
significant problem, and he has already promised to avoid the matter. And if
they can't, everyone's investment is protected.

> > If the FOP developers change their minds and decide to work 
> with you, good.
> > If not, please consider posting a message to the FOray mailing list 
> > telling me more about what you are trying to accomplish, 
> and I'll be 
> > glad to offer some suggestions if I can. FOray's design not 
> only makes 
> > it easier to use FOray code in FOP, but it makes it easier 
> to use FOP code in FOray.
> 
> That sounds like a suggestion for collaboration to me. Give 
> and take. I hope I'm right, Victor. You know I would really 
> like to work together with you again. It's simply that I'm 
> afraid of the old feelings come back (from whatever side) and 
> t

Re: Foray's font subsystem for Fop

[Glen Mazza]

Jeremias Maerki wrote:

>

Ideally, a font engine that is shared between two projects should be in
a more or less neutral place write-accessible by both parties but as
we've seen now there are personal dissonances. 


I think Victor said he didn't want to collaborate anymore:

http://marc.theaimsgroup.com/?l=fop-dev&m=111263144615399&w=2
http://marc.theaimsgroup.com/?l=fop-dev&m=111265443425492&w=2


The problem comes up if
Glen starts to veto against using Victor's work, of if Victor can't or
won't support our wishes anymore. 


Again, I will stay out of it if another worked with his code.  I don't 
have time for the font work, but certainly recognize it needs 
improvement.  I'm in layout now--if I don't like the front end it 
doesn't matter (as much!) anymore, I am now past it.


But we've had Victor's front-end architecture for the first of my two 
years here and my mathematical reduction of it for the second. 
Improvements on layout have been much more rapid in the second year.


I do appreciate your work here, Jeremias, and don't wish to add to your 
stress level on this.  I won't interfere with the font work.


Regards,
Glen

RE: Foray's font subsystem for Fop

[Victor Mote]

Jeremias Maerki wrote:

> Just to be clear, these are the possibilities:
> 1. FOP uses FOray-Font (JAR file in lib directory), no 
> license grant necessary, no FOray sources in an ASF repository.

This is my preference.

> 2. FOP forks FOray-Font, license grants are necessary due to 
> ASF policy.

I will be happy to provide such a grant.

> 3. You donate FOray-Font (back) to the ASF, development 
> within FOray stops, FOray uses a JAR from XML Graphics 
> Commons, development continues within the XML Graphics 
> Commons area, license grants are necessary due to ASF policy.

This is essentially what I tried to do from within FOP. It failed miserably.
I cannot afford to make that mistake again. More to come later by way of
answer to your other emails.

Victor Mote

RE: Foray's font subsystem for Fop

[Victor Mote]

Jeremias Maerki wrote:

> Just to be clear, these are the possibilities:
> 1. FOP uses FOray-Font (JAR file in lib directory), no 
> license grant necessary, no FOray sources in an ASF repository.

This is my preference.

> 2. FOP forks FOray-Font, license grants are necessary due to 
> ASF policy.

I will be happy to provide such a grant.

> 3. You donate FOray-Font (back) to the ASF, development 
> within FOray stops, FOray uses a JAR from XML Graphics 
> Commons, development continues within the XML Graphics 
> Commons area, license grants are necessary due to ASF policy.

This is essentially what I tried to do from within FOP. It failed miserably.
I cannot afford to make that mistake again. More to come later by way of
answer to your other emails.

Victor Mote

Re: Foray's font subsystem for Fop

[Jeremias Maerki]

Victor,

I know you intended that. But "use" and "further develop" are two
different things. What I was getting at with the license grant thing is
the possibility to take your font code and put it FOP code repository
(or better XML Graphics Commons when it finally pops into existence,
still in the queue with infrastructure). Since it was developed outside
the FOP project it wasn't really developed under your Apache CLA. Only
you can commit any FOray source code to an ASF code repository, and only
if you are are sure that noone else contributed any changes to that code
during the development under the FOray project. The other possibility is
to get a license grant from you and any other contributor to FOray-Font
so we can commit the code ourselves (given we decide to do it).

Just to be clear, these are the possibilities:
1. FOP uses FOray-Font (JAR file in lib directory), no license grant
necessary, no FOray sources in an ASF repository.
2. FOP forks FOray-Font, license grants are necessary due to ASF policy.
3. You donate FOray-Font (back) to the ASF, development within FOray
stops, FOray uses a JAR from XML Graphics Commons, development continues
within the XML Graphics Commons area, license grants are necessary due
to ASF policy.

You can guess from my earlier comments that my preference would be (3),
but that's not up to me. (1) is the easiest way but leaves us with an
important dependency on a project that I marked as a one-man-show
(which is an assumption). I don't really like (2). You see that we need
to define what we're really talking about.

On 14.06.2005 14:44:15 Victor Mote wrote:
> Jeremias Maerki wrote:
> 
> > No. Licensing is absolutely no problem in this case. FOray is 
> > distributed under the same license as FOP. What we can't 
> > simply do is take Victor's (source) code and put it in our 
> > code repository without Victor doing a grant to the ASF. 
> > That's a matter of ASF policy. We can add a JAR, however.
> 
> Well, the intent of FOray has always been that its code should be accessible
> at every level to Apache and to anyone else who wants to use it. If I need
> to make a special grant to make that clear, show me where to sign.
> 
> Victor Mote



Jeremias Maerki

RE: Foray's font subsystem for Fop

[Victor Mote]

Jeremias Maerki wrote:

> No. Licensing is absolutely no problem in this case. FOray is 
> distributed under the same license as FOP. What we can't 
> simply do is take Victor's (source) code and put it in our 
> code repository without Victor doing a grant to the ASF. 
> That's a matter of ASF policy. We can add a JAR, however.

Well, the intent of FOray has always been that its code should be accessible
at every level to Apache and to anyone else who wants to use it. If I need
to make a special grant to make that clear, show me where to sign.

Victor Mote

RE: Foray's font subsystem for Fop

[Victor Mote]

Jeremias Maerki wrote:

> No. Licensing is absolutely no problem in this case. FOray is 
> distributed under the same license as FOP. What we can't 
> simply do is take Victor's (source) code and put it in our 
> code repository without Victor doing a grant to the ASF. 
> That's a matter of ASF policy. We can add a JAR, however.

Well, the intent of FOray has always been that its code should be accessible
at every level to Apache and to anyone else who wants to use it. If I need
to make a special grant to make that clear, show me where to sign.

Victor Mote

Re: Foray's font subsystem for Fop

[Jeremias Maerki]

Vincent,

thank you very much for wanting to help. You've seen that you
inadvertently touched a sensitive subject. I'm really sad that these
things must happen. Let me just comment on your initial mail from a
purely technical perspective.

On 12.06.2005 17:20:07 Vincent Hennebert wrote:
> Hi Fop Team and Victor,
> 
> I'm considering to adapt Foray's font subsystem to Fop. I have already 
> experimented a bit and the thing seems to be rather feasible. So far I have 
> encountered two problems:
> 
> - logging mechanism: Foray uses the avalon framework while Fop uses commons 
> logging. The 2 APIs are similar but I suppose I'll have to convert the avalon 
> stuff into commons. Or are there any plans to change the logging mechanism 
> (I'm 
> thinking about the FOPAvalonization Wiki page)? Another minor problem will be 
> to 
> plug the right logger to the font subsystem. I guess only one logger is 
> created 
> and passed through all classes?

The logging problem is a minor one. There's a wrapper for JCL that
easily wraps an Avalon Logger [1]. But that's obviously the exact
opposite of what you need. On the other side, creating an implementation
of Avalon's Logger interface that wraps a JCL logger should be just as
easy. Unfortunately, such a class doesn't exist, yet, but that's written
within 10 minutes.

Let me explain why we switched from Avalon Logging to JCL. Avalon
Loggers are always passed from container to child object (Inversion of
Control). A class using a JCL logger always fetches a logger from a
factory. So the difference is in acquiring a logger but there's also
another aspect: With Avalon Logger you can use different loggers on
different instances of the same class which you can't if you use the
normal JCL pattern of using a static variable for holding the logger.
The static variable has certain advantages, too: You don't need a
variable on every object instance and you don't have to pass Loggers all
around in the system, which is particularly problematic or at least
cumbersome in FOP. JCL makes many thing easier.

But as I hinted above there's no problem connecting the two approaches.
Both are light-weight and therefore easy to handle.

[1] 
http://jakarta.apache.org/commons/logging/api/org/apache/commons/logging/impl/AvalonLogger.html

> - the font subsystem is based on a client/server architecture; the question 
> is: 
> which Fop class should be made a FontConsumer? And where should the 
> FontServer 
> be created and held? So far I've used FOEventHandler as a FontConsumer and a 
> holder of a FontServer. It's quite convenient but I'm not sure at all that it 
> is 
> good design; I'm not yet used to Fop's overall architecture.

I think it would have to be a separate class and held by either
FOEventHandler or FOUserAgent. But we've already stretched the
FOUserAgent a bit already. Anyway, I don't think this is such an
important decision. This can always be improved.

> I welcome any additional thoughts/comments. Now starting to work...

I wish you had asked before diving into this. Before FOray-Font can be
integrated with FOP we need to have a vote on this among the committers
and frankly, I'm sure such a thing will cost a lot of energy. I'm not
going to push in that direction without any hint of support from at
least two other committers around here. I hope we will get more opinions.


Jeremias Maerki

Re: Foray's font subsystem for Fop

[Jeremias Maerki]

I'm sorry, that I'm so late. I'm currently drowning in dozens of little
things I need to attend to.

On 13.06.2005 18:47:09 Victor Mote wrote:
> Vincent Hennebert wrote:
> > If you decide not to do it, well, no matter, I'll find 
> > another thing to do ;-)
> 
> Since I am in a later time zone than almost anyone, I suppose that everyone
> has had a chance to respond to this by now. Hopefully I am wrong.

Yes, you are. I've seen the thread but felt I'd have to approach this
carefully.

To state my opinion on this matter:
I would like to see Vincent integrating FOray-Font into FOP. There has
been some work on fonts compared to the FOP maintenance branch but
Victor has invested more time in FOray-Font. Victor's font subsystem is
now technically more advanced than what we have. The most interesting
feature is the fact that you don't have to create that bloody font
metrics file anymore. When that is eventually coupled with automatic
font registration then it'll be a killer feature. I consider this one of
the more important tasks to improve user-friendliness. Of course, the
same functionality could also be done within FOP but why duplicate the
effort? I'm sure there are still a few things that would need to be
polished inside FOray-Font but if it helps us taking a step forward then
I'm all for it. But that's obviously my technical side speaking.

Ideally, a font engine that is shared between two projects should be in
a more or less neutral place write-accessible by both parties but as
we've seen now there are personal dissonances. The problem comes up if
Glen starts to veto against using Victor's work, of if Victor can't or
won't support our wishes anymore. The latter could be a real problem if
we switch to FOray-Font as it is a crucial part in the puzzle. But
Victor already provided a potential way to improve that situation: aXSL.
If we converted our current font engine to implement the aXSL interface,
we can easily switch. The downsides are the need to maintain
compatibility with aXSL as it advances and aXSL has first to show that
it is capable of handling multiple implementations.

Looking at this from a distance:
1. From a technical perspective, we should work together, if only to
avoid being silly by duplicating work.
2. From a psychological perspective, I don't think the two projects will
ever get along.

That said, I think Victor and I get along together pretty well. He
doesn't even mind discussing stuff with me which is a good sign. Too bad
I got so little time discussing some really interesting stuff with him,
but I have to concentrate on the layout engine ATM. But there are so
many broken glasses on both sides that I doubt we find a way of working
together.

> If the FOP developers change their minds and decide to work with you, good.
> If not, please consider posting a message to the FOray mailing list telling
> me more about what you are trying to accomplish, and I'll be glad to offer
> some suggestions if I can. FOray's design not only makes it easier to use
> FOray code in FOP, but it makes it easier to use FOP code in FOray.

That sounds like a suggestion for collaboration to me. Give and take. I
hope I'm right, Victor. You know I would really like to work together
with you again. It's simply that I'm afraid of the old feelings come
back (from whatever side) and the two project teams break off with each
other again leaving a mess behind.

The two reasons that make me hesitant to really put energy into
reestablishing a mode of collaboration is the high risk of failure,
especially given the immediate bad energies that bubbled up following
Vincent's proposal, and the fact that I have the impression that FOray
is a one-man-show and there's a risk for FOP depending on such a thing.

> And
> FOray has no internal political issues that prevent it from using
> compatibly-licensed code developed elsewhere.

Yes, but see my second reason just above.


Jeremias Maerki

Re: Foray's font subsystem for Fop

[Jeremias Maerki]

No. Licensing is absolutely no problem in this case. FOray is
distributed under the same license as FOP. What we can't simply do is
take Victor's (source) code and put it in our code repository without
Victor doing a grant to the ASF. That's a matter of ASF policy. We can
add a JAR, however.

On 13.06.2005 05:29:08 Glen Mazza wrote:
> Licensing is another headache, Victor would probably need to donate the 
> code first to Apache before we could use it.


Jeremias Maerki

Re: Foray's font subsystem for Fop

[The Web Maestro]

On Jun 13, 2005, at 5:10 AM, Vincent Hennebert wrote:
My goal is not to create any problem within the Team, or between it 
and other people. Adapting FOrayFont to Fop is an issue that has 
already been raised by a couple of persons here. I'm willing to do 
this work because I feel capable of and because I think it would be a 
bonus for Fop.
Now I'm just proposing it. It is not up to me to make any decision 
about doing it or not. I'm now waiting for a common Team decision.


If you decide not to do it, well, no matter, I'll find another thing 
to do ;-)


And please don't feel offensed by any of my words: I'm not a native 
english speaker and words that seem neutral to me may actually be 
offensive ;-/


Regards,
Vincent


IMO, the goal of the active FOP committers (not to mention the rest of 
our active contributors--which includes Victor) is to get something 
useful out the door before the end of the summer (i.e., FOP 1.0!). To 
that end, almost anything you can do to help with this feat will be 
welcomed.


In any case, suffice it to say that we welcome new blood in here. Just 
be certain you try to follow the Contributors Tech Guide[1].


If you intend to make some lasting contributions (which we hope will be 
the case :-D), please consider filling out the CLA[2] now, so that we 
can accept and apply your PATCHes upon receipt. Otherwise, we may have 
to wait for you to fill it out before we can accept your 1st 
significant PATCH... Oh, and... welcome to the club!


Contributors Tech Guide:
http://www.apache.org/dev/contributors.html

ASF Licenses:
http://www.apache.org/licenses/

Regards,

Web Maestro Clay
--
<[EMAIL PROTECTED]> - 
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

RE: Foray's font subsystem for Fop

[Victor Mote]

Vincent Hennebert wrote:

> When politics interferes in open-source development ;-) Hey, 
> I don't think we are here to flame each other. I respect both 
> Victor's and your opinions. I think you both contribute in a 
> useful way. I agree with your willing to clean up the 
> development code because IMO it makes Fop's code discovering 
> easier for newcomers (I know what I'm speaking about ;-). I 
> fully understand Victor's willing to first provide a clean 
> modularization because I'm also fond of well design.

Just to be clear, there is no reason for the work that Glen is doing and the
work that I am doing to be mutually exclusive. I also have some respect for
the cleanup and documentation work that Glen is trying to accomplish. It is
on the bigger issues that we disagree.

> If you decide not to do it, well, no matter, I'll find 
> another thing to do ;-)

Since I am in a later time zone than almost anyone, I suppose that everyone
has had a chance to respond to this by now. Hopefully I am wrong.

If the FOP developers change their minds and decide to work with you, good.
If not, please consider posting a message to the FOray mailing list telling
me more about what you are trying to accomplish, and I'll be glad to offer
some suggestions if I can. FOray's design not only makes it easier to use
FOray code in FOP, but it makes it easier to use FOP code in FOray. And
FOray has no internal political issues that prevent it from using
compatibly-licensed code developed elsewhere.

Victor Mote

RE: Foray's font subsystem for Fop

[Victor Mote]

Vincent Hennebert wrote:

> When politics interferes in open-source development ;-) Hey, 
> I don't think we are here to flame each other. I respect both 
> Victor's and your opinions. I think you both contribute in a 
> useful way. I agree with your willing to clean up the 
> development code because IMO it makes Fop's code discovering 
> easier for newcomers (I know what I'm speaking about ;-). I 
> fully understand Victor's willing to first provide a clean 
> modularization because I'm also fond of well design.

Just to be clear, there is no reason for the work that Glen is doing and the
work that I am doing to be mutually exclusive. I also have some respect for
the cleanup and documentation work that Glen is trying to accomplish. It is
on the bigger issues that we disagree.

> If you decide not to do it, well, no matter, I'll find 
> another thing to do ;-)

Since I am in a later time zone than almost anyone, I suppose that everyone
has had a chance to respond to this by now. Hopefully I am wrong.

If the FOP developers change their minds and decide to work with you, good.
If not, please consider posting a message to the FOray mailing list telling
me more about what you are trying to accomplish, and I'll be glad to offer
some suggestions if I can. FOray's design not only makes it easier to use
FOray code in FOP, but it makes it easier to use FOP code in FOray. And
FOray has no internal political issues that prevent it from using
compatibly-licensed code developed elsewhere.

Victor Mote

Re: Foray's font subsystem for Fop

[Vincent Hennebert]

Glen Mazza a écrit :


Speaking for myself, I really don't want Victor's code in 1.0.  I don't 
like his personality, and have not been a fan of his architectural ideas 
much either--especially his emphasis on placing the 0.20.5 layout code 
into 1.0 via "multiple layout strategies".


I would not relish a return to these past arguments--1.0 is clean and 
clear of the 0.20.5 layout sludge, nobody has to wade through that stuff 
to help out on 1.0, and I am quite happy with the progress being made on 
1.0 because of it.



When politics interferes in open-source development ;-)
Hey, I don't think we are here to flame each other. I respect both Victor's and 
your opinions. I think you both contribute in a useful way. I agree with your 
willing to clean up the development code because IMO it makes Fop's code 
discovering easier for newcomers (I know what I'm speaking about ;-). I fully 
understand Victor's willing to first provide a clean modularization because I'm 
also fond of well design.




Licensing is another headache, Victor would probably need to donate the 
code first to Apache before we could use it.


I'm not used with licensing issues but as FOray uses the same license as Fop I 
guess there won't be any problem here. Maybe I'm wrong?


>
> It seems, Vincent, that you have inadvertently chosen a very unfortunate
> way to re-introduce yourself to this project.  (Not your fault--you
> didn't know.)  However, if others on the project do not mind working
> with Victor, and if he donates the code to FOP, I guess I could refrain
> from futher comment on it.  I will not touch the code personally,
> however, lest I have to interact with its author.

My goal is not to create any problem within the Team, or between it and other 
people. Adapting FOrayFont to Fop is an issue that has already been raised by a 
couple of persons here. I'm willing to do this work because I feel capable of 
and because I think it would be a bonus for Fop.
Now I'm just proposing it. It is not up to me to make any decision about doing 
it or not. I'm now waiting for a common Team decision.


If you decide not to do it, well, no matter, I'll find another thing to do ;-)

And please don't feel offensed by any of my words: I'm not a native english 
speaker and words that seem neutral to me may actually be offensive ;-/


Regards,
Vincent

Re: Foray's font subsystem for Fop

[Glen Mazza]

Victor Mote wrote:


Vincent Hennebert wrote:


I'm considering to adapt Foray's font subsystem to Fop. I 
have already experimented a bit and the thing seems to be 
rather feasible. So far I have encountered two problems:



First, thanks for your interest, and welcome to FOP. Even though I am not an
active FOP developer anymore, I'm glad to see it making progress. And I
agree that integrating FOrayFont with FOP should be quite feasible.




Speaking for myself, I really don't want Victor's code in 1.0.  I don't 
like his personality, and have not been a fan of his architectural ideas 
much either--especially his emphasis on placing the 0.20.5 layout code 
into 1.0 via "multiple layout strategies".


I would not relish a return to these past arguments--1.0 is clean and 
clear of the 0.20.5 layout sludge, nobody has to wade through that stuff 
to help out on 1.0, and I am quite happy with the progress being made on 
1.0 because of it.




I will be very happy to assist you in any way possible, short of writing FOP
code.



Licensing is another headache, Victor would probably need to donate the 
code first to Apache before we could use it.


It seems, Vincent, that you have inadvertently chosen a very unfortunate 
way to re-introduce yourself to this project.  (Not your fault--you 
didn't know.)  However, if others on the project do not mind working 
with Victor, and if he donates the code to FOP, I guess I could refrain 
from futher comment on it.  I will not touch the code personally, 
however, lest I have to interact with its author.


Glen

RE: Foray's font subsystem for Fop

[Victor Mote]

Vincent Hennebert wrote:

> I'm considering to adapt Foray's font subsystem to Fop. I 
> have already experimented a bit and the thing seems to be 
> rather feasible. So far I have encountered two problems:

First, thanks for your interest, and welcome to FOP. Even though I am not an
active FOP developer anymore, I'm glad to see it making progress. And I
agree that integrating FOrayFont with FOP should be quite feasible.

> - logging mechanism: Foray uses the avalon framework while 
> Fop uses commons logging. The 2 APIs are similar but I 
> suppose I'll have to convert the avalon stuff into commons. 
> Or are there any plans to change the logging mechanism (I'm 
> thinking about the FOPAvalonization Wiki page)? Another minor 
> problem will be to plug the right logger to the font 
> subsystem. I guess only one logger is created and passed 
> through all classes?

To be honest, I don't know what the benefits of one over the other are. I
was just feeling pretty good about getting all of the System.out stuff
consolidated into a logger. If it makes sense to convert to commons logging,
I'll be glad to do that. I assume it probably does or FOP wouldn't have gone
down that path. I've just never spent any time on the topic. Can an Avalon
logger be encapsulated in a Commons logger? If so, then it would be a very
easy decision to go with Commons.

I'll answer the question about how many and where to create the loggers
below.

> - the font subsystem is based on a client/server 
> architecture; the question is: 
> which Fop class should be made a FontConsumer? And where 
> should the FontServer be created and held? So far I've used 
> FOEventHandler as a FontConsumer and a holder of a 
> FontServer. It's quite convenient but I'm not sure at all 
> that it is good design; I'm not yet used to Fop's overall 
> architecture.

I am not familiar enough with FOP's current state to advise which class
should the FontConsumer, but I can describe it for you and one of the other
FOP developers can probably give you a good specific answer based on the
description. When I first split the font code off a year ago, I used the
FontInfo class for the FontConsumer implementation, and eventually renamed
it FOrayDocument. That was based on the maintenance branch code, but I think
there was at one time a class with the same name and purpose in the trunk
also. At any rate, the class should be one which represents the input
document. The purpose of the FontConsumer interface is to give the
FontServer a way to keep different documents separate, so that fonts can be
properly subsetted and encoded. As long as you pick a class that has exactly
one instance for document A and exactly one instance for document B, and
those two instances are different, it really doesn't matter much.

WRT the loggers, one is required to create a FontServer. FontServer uses
this for messages that are not directly related to a FontConsumer, e.g. as
it is initializing, etc. Each FontConsumer is required to provide a logger
as well, and FontServer uses that logger for messages that are specific to
that FontConsumer. Of course, it doesn't care if they are the same one.

Jeremias has commented before that he doesn't like FontConsumer passing a
Logger to FontServer. I couldn't figure out how to implement the alternative
that he suggested (Avalon Inversion of Control), and I think I last asked
him to write a patch illustrating the change when he gets a chance. I would
be glad to discuss the matter again, but you need to know that on that point
at least, we may have some work to do.

In FOray we actually store the FontServer instance in the FOraySession
instance, which is at the very top of our tree. Since one FontServer can
serve multiple documents, there was no need for us to provide means for more
than one FontServer. This may enter in to your decision about which class to
use as FontConsumer as well. The FontConsumer implementation needs to be
able to provide the FontServer instance, so it should either store it
internally or be able to get it from where it is stored. This was done to
prevent FontServer from being static. Whenever a FOP class needs a font
service, it just needs to know how to find the appropriate FontConsumer
instance -- it can get to all font services there.

VERY IMPORTANT -- FOrayFont is actually an implementation of axslFont.
axslFont is an interface, and FOrayFont is one (probably the only)
implementation of that interface. There is nothing wrong with integrating
directly to Foray, but it seems much better to integrate to the interface
instead. That gives FOP maximum flexibility if someone develops a better
implementation at some point. The amount of conversion work will be the same
either way.

I will be very happy to assist you in any way possible, short of writing FOP
code.

Victor Mote

RE: Foray's font subsystem for Fop

[Victor Mote]

Vincent Hennebert wrote:

> I'm considering to adapt Foray's font subsystem to Fop. I 
> have already experimented a bit and the thing seems to be 
> rather feasible. So far I have encountered two problems:

First, thanks for your interest, and welcome to FOP. Even though I am not an
active FOP developer anymore, I'm glad to see it making progress. And I
agree that integrating FOrayFont with FOP should be quite feasible.

> - logging mechanism: Foray uses the avalon framework while 
> Fop uses commons logging. The 2 APIs are similar but I 
> suppose I'll have to convert the avalon stuff into commons. 
> Or are there any plans to change the logging mechanism (I'm 
> thinking about the FOPAvalonization Wiki page)? Another minor 
> problem will be to plug the right logger to the font 
> subsystem. I guess only one logger is created and passed 
> through all classes?

To be honest, I don't know what the benefits of one over the other are. I
was just feeling pretty good about getting all of the System.out stuff
consolidated into a logger. If it makes sense to convert to commons logging,
I'll be glad to do that. I assume it probably does or FOP wouldn't have gone
down that path. I've just never spent any time on the topic. Can an Avalon
logger be encapsulated in a Commons logger? If so, then it would be a very
easy decision to go with Commons.

I'll answer the question about how many and where to create the loggers
below.

> - the font subsystem is based on a client/server 
> architecture; the question is: 
> which Fop class should be made a FontConsumer? And where 
> should the FontServer be created and held? So far I've used 
> FOEventHandler as a FontConsumer and a holder of a 
> FontServer. It's quite convenient but I'm not sure at all 
> that it is good design; I'm not yet used to Fop's overall 
> architecture.

I am not familiar enough with FOP's current state to advise which class
should the FontConsumer, but I can describe it for you and one of the other
FOP developers can probably give you a good specific answer based on the
description. When I first split the font code off a year ago, I used the
FontInfo class for the FontConsumer implementation, and eventually renamed
it FOrayDocument. That was based on the maintenance branch code, but I think
there was at one time a class with the same name and purpose in the trunk
also. At any rate, the class should be one which represents the input
document. The purpose of the FontConsumer interface is to give the
FontServer a way to keep different documents separate, so that fonts can be
properly subsetted and encoded. As long as you pick a class that has exactly
one instance for document A and exactly one instance for document B, and
those two instances are different, it really doesn't matter much.

WRT the loggers, one is required to create a FontServer. FontServer uses
this for messages that are not directly related to a FontConsumer, e.g. as
it is initializing, etc. Each FontConsumer is required to provide a logger
as well, and FontServer uses that logger for messages that are specific to
that FontConsumer. Of course, it doesn't care if they are the same one.

Jeremias has commented before that he doesn't like FontConsumer passing a
Logger to FontServer. I couldn't figure out how to implement the alternative
that he suggested (Avalon Inversion of Control), and I think I last asked
him to write a patch illustrating the change when he gets a chance. I would
be glad to discuss the matter again, but you need to know that on that point
at least, we may have some work to do.

In FOray we actually store the FontServer instance in the FOraySession
instance, which is at the very top of our tree. Since one FontServer can
serve multiple documents, there was no need for us to provide means for more
than one FontServer. This may enter in to your decision about which class to
use as FontConsumer as well. The FontConsumer implementation needs to be
able to provide the FontServer instance, so it should either store it
internally or be able to get it from where it is stored. This was done to
prevent FontServer from being static. Whenever a FOP class needs a font
service, it just needs to know how to find the appropriate FontConsumer
instance -- it can get to all font services there.

VERY IMPORTANT -- FOrayFont is actually an implementation of axslFont.
axslFont is an interface, and FOrayFont is one (probably the only)
implementation of that interface. There is nothing wrong with integrating
directly to Foray, but it seems much better to integrate to the interface
instead. That gives FOP maximum flexibility if someone develops a better
implementation at some point. The amount of conversion work will be the same
either way.

I will be very happy to assist you in any way possible, short of writing FOP
code.

Victor Mote

Re: Foray's font subsystem for Fop

[Glen Mazza]

Welcome back Vincent!  No, we switched from Avalon Logging to Commons 
Logging some time ago.  The FOPAvalonization page is rather out-of-date.


Victor and I tend to have different architectural ideas.  I have not 
researched his font work but I believe other team members are more 
knowledgable about it.  Fonts are hardly my speciality--I suspect our 
font implementation in 1.0 can use some improvement though.


Thanks,
Glen


Vincent Hennebert wrote:


Hi Fop Team and Victor,

I'm considering to adapt Foray's font subsystem to Fop. I have already 
experimented a bit and the thing seems to be rather feasible. So far I 
have encountered two problems:


- logging mechanism: Foray uses the avalon framework while Fop uses 
commons logging. The 2 APIs are similar but I suppose I'll have to 
convert the avalon stuff into commons. Or are there any plans to 
change the logging mechanism (I'm thinking about the FOPAvalonization 
Wiki page)? Another minor problem will be to plug the right logger to 
the font subsystem. I guess only one logger is created and passed 
through all classes?


- the font subsystem is based on a client/server architecture; the 
question is: which Fop class should be made a FontConsumer? And where 
should the FontServer be created and held? So far I've used 
FOEventHandler as a FontConsumer and a holder of a FontServer. It's 
quite convenient but I'm not sure at all that it is good design; I'm 
not yet used to Fop's overall architecture.


I welcome any additional thoughts/comments. Now starting to work...

Regards,
Vincent