Re: Beta release next week?

[Jeremias Maerki]

Same with PDFTranscoder. Weird. So, on my system it seems to work fine.
I double-checked that I'm using the batik-all-1.6.jar in the lib
directory and nothing else.

On 20.12.2005 13:26:57 Jeremias Maerki wrote:
> You know what I just did? I downloaded the 0.91 branch I've just created
> and ran an FO file with a referenced SVG file through FOP that contains
> a mixture of "simple" and "non-simple" text. Guess what: "simple" text
> was painted as text, not shapes. Maybe it's only the PDFTranscoder that
> has a problem. I have yet to check that one.
> 
> On 20.12.2005 11:50:24 thomas.deweese wrote:
> > Hi Jeremias,
> > 
> > Jeremias Maerki <[EMAIL PROTECTED]> wrote on 12/20/2005 05:35:14 AM:
> > 
> > > I've just tried to implement that approach you outlined but the problem
> > > is that this init() method is not accepted by the compiler.
> > 
> >Your right in the past I had used static member functions, and you
> > can't access 'this' before the super-class constructor is called so this
> > won't work.  However
> > 
> > > On 14.12.2005 15:13:49 thomas.deweese wrote:
> > 
> > > >If you want to do this, then we should 'fix' the PDFTranscoder
> > > > for SVG text.  It appears that the main problem with Batik 1.6 is
> > > > that it calls 'registerBridges' in the base class constructor before
> > > > the subclass can 'record' it's updated bridges.
> > 
> >I just checked and the Batik 1.6 release does _not_ do this,
> > it calls 'registerSVGBridges' well after the constructor completes,
> > the 1.5.1 release did call registerSVGBridges in the constructor.
> > Which still leaves a bit of an open questions as to why text isn't
> > text with Batik 1.6.
> 
> 
> 
> Jeremias Maerki



Jeremias Maerki

Re: Beta release next week?

[Jeremias Maerki]

You know what I just did? I downloaded the 0.91 branch I've just created
and ran an FO file with a referenced SVG file through FOP that contains
a mixture of "simple" and "non-simple" text. Guess what: "simple" text
was painted as text, not shapes. Maybe it's only the PDFTranscoder that
has a problem. I have yet to check that one.

On 20.12.2005 11:50:24 thomas.deweese wrote:
> Hi Jeremias,
> 
> Jeremias Maerki <[EMAIL PROTECTED]> wrote on 12/20/2005 05:35:14 AM:
> 
> > I've just tried to implement that approach you outlined but the problem
> > is that this init() method is not accepted by the compiler.
> 
>Your right in the past I had used static member functions, and you
> can't access 'this' before the super-class constructor is called so this
> won't work.  However
> 
> > On 14.12.2005 15:13:49 thomas.deweese wrote:
> 
> > >If you want to do this, then we should 'fix' the PDFTranscoder
> > > for SVG text.  It appears that the main problem with Batik 1.6 is
> > > that it calls 'registerBridges' in the base class constructor before
> > > the subclass can 'record' it's updated bridges.
> 
>I just checked and the Batik 1.6 release does _not_ do this,
> it calls 'registerSVGBridges' well after the constructor completes,
> the 1.5.1 release did call registerSVGBridges in the constructor.
> Which still leaves a bit of an open questions as to why text isn't
> text with Batik 1.6.



Jeremias Maerki

Re: Beta release next week?

[thomas . deweese]

Hi Jeremias,

Jeremias Maerki <[EMAIL PROTECTED]> wrote on 12/20/2005 05:35:14 AM:

> I've just tried to implement that approach you outlined but the problem
> is that this init() method is not accepted by the compiler.

   Your right in the past I had used static member functions, and you
can't access 'this' before the super-class constructor is called so this
won't work.  However

> On 14.12.2005 15:13:49 thomas.deweese wrote:

> >If you want to do this, then we should 'fix' the PDFTranscoder
> > for SVG text.  It appears that the main problem with Batik 1.6 is
> > that it calls 'registerBridges' in the base class constructor before
> > the subclass can 'record' it's updated bridges.

   I just checked and the Batik 1.6 release does _not_ do this,
it calls 'registerSVGBridges' well after the constructor completes,
the 1.5.1 release did call registerSVGBridges in the constructor.
Which still leaves a bit of an open questions as to why text isn't
text with Batik 1.6.

Re: Beta release next week?

[Jeremias Maerki]

Thomas,

I've just tried to implement that approach you outlined but the problem
is that this init() method is not accepted by the compiler. You can't
access member variables before Object's constructor is called. I guess
we'll have to wait until the next Batik release to fix this. Or did you
actually try it and managed to get it to work?

On 14.12.2005 15:13:49 thomas.deweese wrote:
> Hi Jeremias,
> 
> Jeremias Maerki <[EMAIL PROTECTED]> wrote on 12/14/2005 08:33:47 AM:
> 
> > Given the number of bugs fixed and the feedback we got, I think it 
> > should be safe to do another release tagged "beta". 
> 
>If you want to do this, then we should 'fix' the PDFTranscoder
> for SVG text.  It appears that the main problem with Batik 1.6 is
> that it calls 'registerBridges' in the base class constructor before
> the subclass can 'record' it's updated bridges.  I believe it is 
> possible to fix this by replacing:
> 
> super(userAgent);
> 
> with:
> super(init(userAgent, fontInfo, linkTransform))
> 
> Where init is more or less:
> 
> UserAgent init(UserAgent ua, FontInfo fi, AffineTransform lt) {
>   this.fontInfo  = fi;
> this.linkTransform = lt;
>   return ua;
> }
> 
> This will not fix all cases (if a new BridgeContext is constructed,
> for example to handle an internal SVG image, it will not inherit the
> 'updated' bridges, for that to work properly people will need the SVN
> Batik).
> 
> [Having to employ such ugly tactics to get subclass code run before
>  baseclass constructor code demonstrates how silly the 'super' must
>  be first - compiler restriction is].



Jeremias Maerki

Re: Beta release next week?

[Simon Pepping]

+1 from me.

0.91beta, in the end approaching 1.00, or 0.9beta1, in the end
approaching 0.9very-much-production = 1.00.

Simon

On Wed, Dec 14, 2005 at 02:33:47PM +0100, Jeremias Maerki wrote:
> Feedback so far has shown that we're in a better condition than I
> thought. FOP 0.90alpha1 seems to be quite usable. It even stands up to
> many non-trivial documents. I've been able to fix quite a number of bugs
> so far and I think I speak not only for myself when I say that it would
> be good to get rid of the "alpha" tag. FOP 0.90 is certainly not a
> replacement for 0.20.5 in every situation but already in many. We
> already have pretty good documentation although there are, of course,
> still some gaps that could be filled. Given the number of bugs fixed and
> the feedback we got, I think it should be safe to do another release
> tagged "beta". I don't care too much about the exact version number.
> I'll leave suggestions up to you. Release early, release often
> 
> WDYT?
> 
> Jeremias Maerki
> 

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

Re: Beta release next week?

[Manuel Mall]

> Feedback so far has shown that we're in a better condition than I
> thought. FOP 0.90alpha1 seems to be quite usable. It even stands up to
> many non-trivial documents. I've been able to fix quite a number of bugs
> so far and I think I speak not only for myself when I say that it would
> be good to get rid of the "alpha" tag. FOP 0.90 is certainly not a
> replacement for 0.20.5 in every situation but already in many. We
> already have pretty good documentation although there are, of course,
> still some gaps that could be filled. Given the number of bugs fixed and
> the feedback we got, I think it should be safe to do another release
> tagged "beta". I don't care too much about the exact version number.
> I'll leave suggestions up to you. Release early, release often
>
> WDYT?
>
> Jeremias Maerki
>
+1 (Informal of course)

Manuel

Re: Beta release next week?

[Jeremias Maerki]

On 14.12.2005 18:29:01 Adam Strzelecki wrote:
> > Again, ASF license policy. No more distribution of unreleased code from
> > ASF hardware anymore. But you can use a Batik snapshot internally in
> > your company.
> Frankly I'm not keen in ASF policy so sorry for my naive questions.

Absolutely no need to be sorry. I can't know that. I'm actually sorry it
has to be so complicated.


Jeremias Maerki

Re: Beta release next week?

[The Web Maestro]

On Dec 14, 2005, at 11:29 AM, Andreas L Delmelle wrote:

On Dec 14, 2005, at 14:33, Jeremias Maerki wrote:

Given the number of bugs fixed and the feedback we got, I think it
should be safe to do another release tagged "beta". I don't care
too much about the exact version number.
I'll leave suggestions up to you. Release early, release often

WDYT?


+1. 0.90beta sounds fine to me.

Cheers,

Andreas


+1 for 0.90beta

IMO, we don't need to worry about 0.90beta1 or anything, because we can 
always bump to 0.91beta, etc. I assume 0.90 will be relatively 
unchanged from it's current state (e.g., won't include the FOray font 
stuff--which presumably would still come in pre-1.0?)


Regards,

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

Re: Beta release next week?

[Andreas L Delmelle]

On Dec 14, 2005, at 14:33, Jeremias Maerki wrote:


Given the number of bugs fixed and the feedback we got, I think it
should be safe to do another release tagged "beta". I don't care
too much about the exact version number.
I'll leave suggestions up to you. Release early, release often

WDYT?


+1. 0.90beta sounds fine to me.

Cheers,

Andreas

P.S.: Apologies for not being able to invest a lot of time lately.  
Currently very busy at the job --in fact working two jobs at the same  
time (for only one salary, no less :-S), so in the evenings my  
brain's a bit too full to go delving through source code looking for  
bugs/possible improvements-- but that's soon about to change. In the  
meantime, I'll help where I can...

Re: Beta release next week?

[Adam Strzelecki]

> Again, ASF license policy. No more distribution of unreleased code from
> ASF hardware anymore. But you can use a Batik snapshot internally in
> your company.
Frankly I'm not keen in ASF policy so sorry for my naive questions.

> Yes I didn't think Batik was ready for a release just yet. So I guess,
> it boils down to the question: how long do you think it will be until
> Batik can do another release? If it's likely to be a long time, then
> perhaps we should make the change you suggest. 
I must confess I already tried this hack few days ago when having this
stroking problem. Compiled it with Java 1.6 (mustang beta) and new Java
version cannot be fooled like that:

[javac]
D:\Development\apps\fop-trunk\src\java\org\apache\fop\svg\PDFBridgeContext.java:66:
cannot reference this before supertype constructor has been called
[javac] super(init(userAgent, fontInfo, linkTransform));

So may be not compilable with future Java 1.6 (mustang) versions,
IMHO better wait for new Batik release then :(

Regards,
-- 
Adam Strzelecki |: nanoant.com :|

Re: Beta release next week?

[Chris Bowditch]

[EMAIL PROTECTED] wrote:

I thought this bug was fixed in Batik's SVN Head. If so, it will be 
fixed when we next do a release in Batik, and if people need a fix 
sooner then they can download Batik source and build it themselves.



   In general I agree, however it is extremely unlikely that Batik will
have a release before FOP which means that this feature will remain
broken in a second release.


Yes I didn't think Batik was ready for a release just yet. So I guess, 
it boils down to the question: how long do you think it will be until 
Batik can do another release? If it's likely to be a long time, then 
perhaps we should make the change you suggest.





It seems silly to put in a hack, when its already fixed in Batik's SVN 


Head.

   If it were a more invasive hack I would agree however in this case the
hack is small and isolated and it will enable people to use 'stable' 
releases

for FOP and Batik which is (right or wrong) important to many people.


I guess you are right. It makes interoperability between FOP and Batik 
versions easier.




   I don't have really strong feelings on this but I think that adding
the hack is the better solution.


I don't feel strongly either way. I just wanted clarification on why you 
were proposing the hack really.


Chris

Re: Beta release next week?

[Jeremias Maerki]

On 14.12.2005 15:56:33 Adam Strzelecki wrote:
> >If it were a more invasive hack I would agree however in this case the
> > hack is small and isolated and it will enable people to use 'stable' 
> > releases
> > for FOP and Batik which is (right or wrong) important to many people.
> Anyway FOP 0.90beta binaries are going to be distributed with binaries
> of Batik so in this case if there will be no Batik stable release lets
> distribute it with SVN version, it shouldn't be a problem ?

Again, ASF license policy. No more distribution of unreleased code from
ASF hardware anymore. But you can use a Batik snapshot internally in
your company.

> > 
> >I don't have really strong feelings on this but I think that adding
> > the hack is the better solution.
> Me neither.
> 
> Regards,
> -- 
> Adam Strzelecki |: nanoant.com :|



Jeremias Maerki

Re: Beta release next week?

[Jeremias Maerki]

On 14.12.2005 16:10:29 Adam Strzelecki wrote:
> >> fop-0.90-trunk-toUnicodeCMap.patch (attached, also one that is in
> >> bugzilla) - embedding ToUnicode maps (previously did one for 0.20.5, but
> >> this one works nice with SVN head)
> > 
> > I'd love to but I've had to seek legal advice on this topic, because you
> > took a file from another project. It's clearly not exclusively your own
> > IP and therefore I have to find out how to deal with that, even though
> > the license of the original file is the same as FOP. So far, I haven't
> > received any answer, so I'm afraid your patch has to wait. Sorry.
> Well I took the PDFToUnicodeCMap.java from FOray project which is Apache
> V2.0 License and it is fork of FOP 0.20, rest was just almost prepared
> in FOP.. like PDFCMap.java was there but unused.

I know. But this is Apache license policy. And being an officer of the
ASF I have to lead with good example. I'm trying everything to resolve
this as quickly as possible but since the FOrayFont work is not far away
it may not be worth the trouble. After all, I assume you have to stick
to FOP Trunk instead of 0.90alpha1 anyway so this should not be a big
problem in the meantime.

> > Thanks. And thanks for letting yourself be converted to 0.90. :-) Your
> > feedback is highly appreciated.
> Great. I'm really suffering of MS Office domination... DocBook XML & FOP
> are great detoxinators for me ;)
> We are now pushing all projects to use DocBook documentation so we
> generate: CHM Html Helps, printed docs (FOP -> PDF) and websites on fly
> from just one XML source.
> 
> Also storing XML DocBook and SVG images in CVS is easy comparing to
> tracking changes in Word documents (used by some of our clients) which
> is nightmare.
> 
> Regards,
> -- 
> Adam Strzelecki |: nanoant.com :|



Jeremias Maerki

Re: Beta release next week?

[Adam Strzelecki]

>> fop-0.90-trunk-toUnicodeCMap.patch (attached, also one that is in
>> bugzilla) - embedding ToUnicode maps (previously did one for 0.20.5, but
>> this one works nice with SVN head)
> 
> I'd love to but I've had to seek legal advice on this topic, because you
> took a file from another project. It's clearly not exclusively your own
> IP and therefore I have to find out how to deal with that, even though
> the license of the original file is the same as FOP. So far, I haven't
> received any answer, so I'm afraid your patch has to wait. Sorry.
Well I took the PDFToUnicodeCMap.java from FOray project which is Apache
V2.0 License and it is fork of FOP 0.20, rest was just almost prepared
in FOP.. like PDFCMap.java was there but unused.

> Thanks. And thanks for letting yourself be converted to 0.90. :-) Your
> feedback is highly appreciated.
Great. I'm really suffering of MS Office domination... DocBook XML & FOP
are great detoxinators for me ;)
We are now pushing all projects to use DocBook documentation so we
generate: CHM Html Helps, printed docs (FOP -> PDF) and websites on fly
from just one XML source.

Also storing XML DocBook and SVG images in CVS is easy comparing to
tracking changes in Word documents (used by some of our clients) which
is nightmare.

Regards,
-- 
Adam Strzelecki |: nanoant.com :|

Re: Beta release next week?

[Adam Strzelecki]

>If it were a more invasive hack I would agree however in this case the
> hack is small and isolated and it will enable people to use 'stable' 
> releases
> for FOP and Batik which is (right or wrong) important to many people.
Anyway FOP 0.90beta binaries are going to be distributed with binaries
of Batik so in this case if there will be no Batik stable release lets
distribute it with SVN version, it shouldn't be a problem ?

> 
>I don't have really strong feelings on this but I think that adding
> the hack is the better solution.
Me neither.

Regards,
-- 
Adam Strzelecki |: nanoant.com :|

Re: Beta release next week?

[Jeremias Maerki]

On 14.12.2005 15:40:46 Adam Strzelecki wrote:
> Hello,
> 
> > WDYT?
> That's cool!
> 
> I was stick to 0.20.5 but now I once have adapted 0.90svn it's working
> great.

Good to hear.

> Just wanted to ask if the upcoming release will have anything to do with
>  FOray fonts or not yet ?

No. That's not a small task. I will want to play with this stuff a
little before releasing.

> If NO I would like to ask maybe those 2 patches will be then useful for
> upcoming beta:
> 
> fop-0.90-trunk-toUnicodeCMap.patch (attached, also one that is in
> bugzilla) - embedding ToUnicode maps (previously did one for 0.20.5, but
> this one works nice with SVN head)

I'd love to but I've had to seek legal advice on this topic, because you
took a file from another project. It's clearly not exclusively your own
IP and therefore I have to find out how to deal with that, even though
the license of the original file is the same as FOP. So far, I haven't
received any answer, so I'm afraid your patch has to wait. Sorry.

> fop-0.90-trunk-tspan-pdf-text.patch (attached to some previous mail) -
> this one also renders PDF text for tspan without stroking, I adapted
> code from 0.20.5. Does work nicely, only have problems when text has
> some style="stroke..." those are ignored (not implemented).

I yet have to look closer at all the SVG stuff that we're talking about
here. If it's fine, I'll apply it, of course.

> Also wish to point to
> http://issues.apache.org/bugzilla/show_bug.cgi?id=37877 discussion.. if
> it will be possible to count dimensions for viewBox less SVGs like Batik
> Squiggle does for upcoming beta ??

Yes, I'm trying hard to get that in as well. One thing after the other.

> Ahh ... one last thing... this message:
> "Some content could not fit into a line/page after 50 attempts."
> 
> Would it be hard to write what is this "some content actually". Because
> it might be hard to guess if you have plenty of embedded images in FO
> file :)

I'll try.

> Anyway great work guys,

Thanks. And thanks for letting yourself be converted to 0.90. :-) Your
feedback is highly appreciated.


Jeremias Maerki

Re: Beta release next week?

[thomas . deweese]

Hi Chris,

> > Jeremias Maerki <[EMAIL PROTECTED]> wrote on 12/14/2005 08:33:47 
AM:

> >>Given the number of bugs fixed and the feedback we got, I think it 
> >>should be safe to do another release tagged "beta". 

> [EMAIL PROTECTED] wrote:

> >If you want to do this, then we should 'fix' the PDFTranscoder
> > for SVG text.

Chris Bowditch <[EMAIL PROTECTED]> wrote on 12/14/2005 09:24:14 
AM:

> I thought this bug was fixed in Batik's SVN Head. If so, it will be 
> fixed when we next do a release in Batik, and if people need a fix 
> sooner then they can download Batik source and build it themselves.

   In general I agree, however it is extremely unlikely that Batik will
have a release before FOP which means that this feature will remain
broken in a second release.

> It seems silly to put in a hack, when its already fixed in Batik's SVN 
Head.

   If it were a more invasive hack I would agree however in this case the
hack is small and isolated and it will enable people to use 'stable' 
releases
for FOP and Batik which is (right or wrong) important to many people.

   I don't have really strong feelings on this but I think that adding
the hack is the better solution.

Re: Beta release next week?

[Adam Strzelecki]

Hello,

> WDYT?
That's cool!

I was stick to 0.20.5 but now I once have adapted 0.90svn it's working
great.

Just wanted to ask if the upcoming release will have anything to do with
 FOray fonts or not yet ?

If NO I would like to ask maybe those 2 patches will be then useful for
upcoming beta:

fop-0.90-trunk-toUnicodeCMap.patch (attached, also one that is in
bugzilla) - embedding ToUnicode maps (previously did one for 0.20.5, but
this one works nice with SVN head)

fop-0.90-trunk-tspan-pdf-text.patch (attached to some previous mail) -
this one also renders PDF text for tspan without stroking, I adapted
code from 0.20.5. Does work nicely, only have problems when text has
some style="stroke..." those are ignored (not implemented).

Also wish to point to
http://issues.apache.org/bugzilla/show_bug.cgi?id=37877 discussion.. if
it will be possible to count dimensions for viewBox less SVGs like Batik
Squiggle does for upcoming beta ??

Ahh ... one last thing... this message:
"Some content could not fit into a line/page after 50 attempts."

Would it be hard to write what is this "some content actually". Because
it might be hard to guess if you have plenty of embedded images in FO
file :)

Anyway great work guys,

Best wishes,
-- 
Adam Strzelecki |: nanoant.com :|
Index: java/org/apache/fop/fonts/CIDFont.java
===
--- java/org/apache/fop/fonts/CIDFont.java  (revision 356250)
+++ java/org/apache/fop/fonts/CIDFont.java  (working copy)
@@ -1,12 +1,12 @@
 /*
  * Copyright 1999-2004 The Apache Software Foundation.
- * 
+ *
  * Licensed under the Apache License, Version 2.0 (the "License");
  * you may not use this file except in compliance with the License.
  * You may obtain a copy of the License at
- * 
+ *
  *  http://www.apache.org/licenses/LICENSE-2.0
- * 
+ *
  * Unless required by applicable law or agreed to in writing, software
  * distributed under the License is distributed on an "AS IS" BASIS,
  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
@@ -37,6 +37,11 @@
 public Map usedGlyphsIndex = new java.util.HashMap();
 public int usedGlyphsCount = 0;
 
+/**
+ * usedCharsIndex contains new glyph, original char
+ */
+public Map usedCharsIndex = new java.util.HashMap();
+
 //private PDFWArray warray = new PDFWArray();
 public int width[] = null;
 
@@ -90,4 +95,8 @@
 return true;
 }
 
+/**
+ * Returns char[] array .
+ */
+public abstract char[] getCharsUsed();
 }
\ No newline at end of file
Index: java/org/apache/fop/fonts/MultiByteFont.java
===
--- java/org/apache/fop/fonts/MultiByteFont.java(revision 356250)
+++ java/org/apache/fop/fonts/MultiByteFont.java(working copy)
@@ -1,12 +1,12 @@
 /*
  * Copyright 1999-2004 The Apache Software Foundation.
- * 
+ *
  * Licensed under the Apache License, Version 2.0 (the "License");
  * you may not use this file except in compliance with the License.
  * You may obtain a copy of the License at
- * 
+ *
  *  http://www.apache.org/licenses/LICENSE-2.0
- * 
+ *
  * Unless required by applicable law or agreed to in writing, software
  * distributed under the License is distributed on an "AS IS" BASIS,
  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
@@ -125,7 +125,7 @@
  * @see org.apache.fop.fonts.FontDescriptor#isEmbeddable()
  */
 public boolean isEmbeddable() {
-return !(getEmbedFileName() == null && embedResourceName == null); 
+return !(getEmbedFileName() == null && embedResourceName == null);
 }
 
 /**
@@ -198,8 +198,8 @@
 for (int i = 0; (i < bfentries.length) && retIdx == 0; i++) {
 if (bfentries[i].getUnicodeStart() <= idx
 && bfentries[i].getUnicodeEnd() >= idx) {
-
-retIdx = bfentries[i].getGlyphStartIndex() 
+
+retIdx = bfentries[i].getGlyphStartIndex()
 + idx
 - bfentries[i].getUnicodeStart();
 }
@@ -222,6 +222,8 @@
new Integer(usedGlyphsCount));
 usedGlyphsIndex.put(new Integer(usedGlyphsCount),
 new Integer(retIdx));
+usedCharsIndex.put(new Integer(usedGlyphsCount),
+new Integer((int) c));
 retIdx = usedGlyphsCount;
 usedGlyphsCount++;
 } else {
@@ -299,5 +301,26 @@
 return usedGlyphs;
 }
 
+/** The invalid Unicode character, suitable as a return value in methods
+ * that need to return an invalid character. */
+public static final char INVALID_UNICODE_CHAR = 0x;
+
+public char[] getCharsUsed() {
+if (! isEmbeddable()) {
+return null;
+}
+char[] charArray = new char[us

Beta release next week?

[Jeremias Maerki]

Feedback so far has shown that we're in a better condition than I
thought. FOP 0.90alpha1 seems to be quite usable. It even stands up to
many non-trivial documents. I've been able to fix quite a number of bugs
so far and I think I speak not only for myself when I say that it would
be good to get rid of the "alpha" tag. FOP 0.90 is certainly not a
replacement for 0.20.5 in every situation but already in many. We
already have pretty good documentation although there are, of course,
still some gaps that could be filled. Given the number of bugs fixed and
the feedback we got, I think it should be safe to do another release
tagged "beta". I don't care too much about the exact version number.
I'll leave suggestions up to you. Release early, release often

WDYT?

Jeremias Maerki

Re: Beta release next week?

[Chris Bowditch]

[EMAIL PROTECTED] wrote:


Hi Jeremias,

Jeremias Maerki <[EMAIL PROTECTED]> wrote on 12/14/2005 08:33:47 AM:


Given the number of bugs fixed and the feedback we got, I think it 
should be safe to do another release tagged "beta". 



   If you want to do this, then we should 'fix' the PDFTranscoder
for SVG text.  It appears that the main problem with Batik 1.6 is
that it calls 'registerBridges' in the base class constructor before
the subclass can 'record' it's updated bridges.  I believe it is 
possible to fix this by replacing:


I thought this bug was fixed in Batik's SVN Head. If so, it will be 
fixed when we next do a release in Batik, and if people need a fix 
sooner then they can download Batik source and build it themselves.




super(userAgent);

with:
super(init(userAgent, fontInfo, linkTransform))


It seems silly to put in a hack, when its already fixed in Batik's SVN Head.




[Having to employ such ugly tactics to get subclass code run before
 baseclass constructor code demonstrates how silly the 'super' must
 be first - compiler restriction is].


Couldn't agree more

Chris

Re: Beta release next week?

[Jeremias Maerki]

Definitely high on my list prior to the release. Thanks for the hints.
I'll look into it ASAP.

On 14.12.2005 15:13:49 thomas.deweese wrote:
> Hi Jeremias,
> 
> Jeremias Maerki <[EMAIL PROTECTED]> wrote on 12/14/2005 08:33:47 AM:
> 
> > Given the number of bugs fixed and the feedback we got, I think it 
> > should be safe to do another release tagged "beta". 
> 
>If you want to do this, then we should 'fix' the PDFTranscoder
> for SVG text.  It appears that the main problem with Batik 1.6 is
> that it calls 'registerBridges' in the base class constructor before
> the subclass can 'record' it's updated bridges.  I believe it is 
> possible to fix this by replacing:
> 
> super(userAgent);
> 
> with:
> super(init(userAgent, fontInfo, linkTransform))
> 
> Where init is more or less:
> 
> UserAgent init(UserAgent ua, FontInfo fi, AffineTransform lt) {
>   this.fontInfo  = fi;
> this.linkTransform = lt;
>   return ua;
> }
> 
> This will not fix all cases (if a new BridgeContext is constructed,
> for example to handle an internal SVG image, it will not inherit the
> 'updated' bridges, for that to work properly people will need the SVN
> Batik).
> 
> [Having to employ such ugly tactics to get subclass code run before
>  baseclass constructor code demonstrates how silly the 'super' must
>  be first - compiler restriction is].



Jeremias Maerki

Re: Beta release next week?

[Chris Bowditch]

Jeremias Maerki wrote:


Feedback so far has shown that we're in a better condition than I
thought. FOP 0.90alpha1 seems to be quite usable. It even stands up to
many non-trivial documents. I've been able to fix quite a number of bugs
so far and I think I speak not only for myself when I say that it would
be good to get rid of the "alpha" tag. FOP 0.90 is certainly not a
replacement for 0.20.5 in every situation but already in many. We
already have pretty good documentation although there are, of course,
still some gaps that could be filled. Given the number of bugs fixed and
the feedback we got, I think it should be safe to do another release
tagged "beta". I don't care too much about the exact version number.
I'll leave suggestions up to you. Release early, release often

WDYT?


+1

Keep up the good work.

Chris

Re: Beta release next week?

[thomas . deweese]

Hi Jeremias,

Jeremias Maerki <[EMAIL PROTECTED]> wrote on 12/14/2005 08:33:47 AM:

> Given the number of bugs fixed and the feedback we got, I think it 
> should be safe to do another release tagged "beta". 

   If you want to do this, then we should 'fix' the PDFTranscoder
for SVG text.  It appears that the main problem with Batik 1.6 is
that it calls 'registerBridges' in the base class constructor before
the subclass can 'record' it's updated bridges.  I believe it is 
possible to fix this by replacing:

super(userAgent);

with:
super(init(userAgent, fontInfo, linkTransform))

Where init is more or less:

UserAgent init(UserAgent ua, FontInfo fi, AffineTransform lt) {
  this.fontInfo  = fi;
this.linkTransform = lt;
  return ua;
}

This will not fix all cases (if a new BridgeContext is constructed,
for example to handle an internal SVG image, it will not inherit the
'updated' bridges, for that to work properly people will need the SVN
Batik).

[Having to employ such ugly tactics to get subclass code run before
 baseclass constructor code demonstrates how silly the 'super' must
 be first - compiler restriction is].