You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Jeremias Maerki <de...@jeremias-maerki.ch> on 2005/12/14 14:33:47 UTC
Beta release next week?
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?
Posted by The Web Maestro <th...@gmail.com>.
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
--
<th...@gmail.com> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet
Re: Beta release next week?
Posted by Andreas L Delmelle <a_...@pandora.be>.
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?
Posted by Chris Bowditch <bo...@hotmail.com>.
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?
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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?
Posted by Adam Strzelecki <on...@java.pl>.
>> 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?
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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?
Posted by Adam Strzelecki <on...@java.pl>.
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 :|
Re: Beta release next week?
Posted by Simon Pepping <sp...@leverkruid.nl>.
+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?
Posted by Manuel Mall <ma...@apache.org>.
> 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?
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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 <de...@jeremias-maerki.ch> 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?
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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 <de...@jeremias-maerki.ch> 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?
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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 <de...@jeremias-maerki.ch> 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?
Posted by th...@kodak.com.
Hi Jeremias,
Jeremias Maerki <de...@jeremias-maerki.ch> 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?
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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 <de...@jeremias-maerki.ch> 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?
Posted by Chris Bowditch <bo...@hotmail.com>.
thomas.deweese@kodak.com wrote:
> Hi Jeremias,
>
> Jeremias Maerki <de...@jeremias-maerki.ch> 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.
<snip/>
> [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?
Posted by th...@kodak.com.
Hi Jeremias,
Jeremias Maerki <de...@jeremias-maerki.ch> 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].