DO NOT REPLY [Bug 31675] New: - Batik image readers fails
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31675. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31675 Batik image readers fails Summary: Batik image readers fails Product: Fop Version: 1.0dev Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: images AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The recent change to image loading (using batik, i believe) now throws an exception for an image that previously loaded fine. Error loading an image java.lang.ArrayIndexOutOfBoundsException: 651 at java.awt.image.SinglePixelPackedSampleModel.setPixels(SinglePixelPackedSampleModel.java:670) at java.awt.image.WritableRaster.setPixels(WritableRaster.java:547) at sun.awt.image.SunWritableRaster.setPixels(SunWritableRaster.java:132) at org.apache.batik.ext.awt.image.GraphicsUtil.copyData_FALLBACK(Unknown Source) at org.apache.batik.ext.awt.image.GraphicsUtil.copyData(Unknown Source) at org.apache.batik.ext.awt.image.rendered.Any2sRGBRed.copyData(Unknown Source) at org.apache.batik.ext.awt.image.rendered.AbstractRed.getData(Unknown Source) at org.apache.batik.ext.awt.image.rendered.AbstractRed.getData(Unknown Source) at org.apache.fop.image.BatikImage.loadImage(BatikImage.java:159) at org.apache.fop.image.BatikImage.loadBitmap(BatikImage.java:69) at org.apache.fop.image.AbstractFopImage.load(AbstractFopImage.java:149) at org.apache.fop.render.pdf.PDFRenderer.putImage(PDFRenderer.java:1141) at org.apache.fop.render.pdf.PDFRenderer.renderImage(PDFRenderer.java:1077) at org.apache.fop.render.AbstractRenderer.renderViewport(AbstractRenderer.java:626) at org.apache.fop.render.pdf.PDFRenderer.renderViewport(PDFRenderer.java:1243) at org.apache.fop.render.AbstractRenderer.renderInlineArea(AbstractRenderer.java:578) at org.apache.fop.render.AbstractRenderer.renderLineArea(AbstractRenderer.java:564) at org.apache.fop.render.pdf.PDFRenderer.renderLineArea(PDFRenderer.java:766) at org.apache.fop.render.AbstractRenderer.renderBlocks(AbstractRenderer.java:500) at org.apache.fop.render.AbstractRenderer.renderBlock(AbstractRenderer.java:542) at org.apache.fop.render.AbstractRenderer.renderBlocks(AbstractRenderer.java:492) at org.apache.fop.render.AbstractRenderer.renderFlow(AbstractRenderer.java:403) at org.apache.fop.render.AbstractRenderer.renderMainReference(AbstractRenderer.java:386) at org.apache.fop.render.AbstractRenderer.renderBodyRegion(AbstractRenderer.java:322) at org.apache.fop.render.AbstractRenderer.renderRegionViewport(AbstractRenderer.java:270) at org.apache.fop.render.AbstractRenderer.renderPageAreas(AbstractRenderer.java:243) at org.apache.fop.render.pdf.PDFRenderer.renderPage(PDFRenderer.java:435) at org.apache.fop.area.RenderPagesModel.checkPreparedPages(RenderPagesModel.java:147) at org.apache.fop.area.RenderPagesModel.addPage(RenderPagesModel.java:126) at org.apache.fop.layoutmgr.PageSequenceLayoutManager.finishPage(PageSequenceLayoutManager.java:537) at org.apache.fop.layoutmgr.PageSequenceLayoutManager.doLayout(PageSequenceLayoutManager.java:236) at org.apache.fop.layoutmgr.PageSequenceLayoutManager.run(PageSequenceLayoutManager.java:178) at org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.java:322) at org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java:239) at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:275)
Re: FOP updated to new Batik API
Glen Mazza wrote:
Patch applied! But please be careful to keep all
if-statements within braces--for the second patch, the
change at line 500 made the code look somewhat vague
as to your intentions (see below--I fixed it though).
Ahh yah, sorry for the confusion.
You say you 'fixed it', you should not
have moved the result stuff into the if.
(...previous { somewhere...)
if (alpha != 255)
hasMask = true;
result[count++] = (byte)((val 16) 0xFF);
result[count++] = (byte)((val 8) 0xFF);
result[count++] = (byte)((val) 0xFF);
}
--- Thomas DeWeese [EMAIL PROTECTED] wrote:
I've attached a
tiny
patch that fixes this for the PDFTextPainter.
I also have attached a patch for PDFGraphics2D.
The patch has two parts - the first is the more
important
of the two.
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Re: FOP updated to new Batik API
--- Thomas DeWeese [EMAIL PROTECTED] wrote: You say you 'fixed it', you should not have moved the result stuff into the if. No, I did not--it was *reformatted* correctly I meant! Glen __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Re: FOP updated to new Batik API
Patch applied! But please be careful to keep all
if-statements within braces--for the second patch, the
change at line 500 made the code look somewhat vague
as to your intentions (see below--I fixed it though).
(...previous { somewhere...)
if (alpha != 255)
hasMask = true;
result[count++] = (byte)((val 16) 0xFF);
result[count++] = (byte)((val 8) 0xFF);
result[count++] = (byte)((val) 0xFF);
}
Thanks,
Glen
--- Thomas DeWeese [EMAIL PROTECTED] wrote:
I've attached a
tiny
patch that fixes this for the PDFTextPainter.
I also have attached a patch for PDFGraphics2D.
The patch has two parts - the first is the more
important
of the two.
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Re: FOP updated to new Batik API
I'll get to these this weekend.
Thanks,
Glen
--- Thomas DeWeese [EMAIL PROTECTED] wrote:
Hi Glen,
Thanks for doing this.
I just updated my FOP and ran some FO/SVG
through it.
You seem to have gotten most of it, but I noticed
that
you didn't use TextPainterInfo.fillPaint - instead
you
continued to use the value of the FOREGROUND
attribute.
You may not have noticed this becuase I was unable
to
'remove' the FOREGROUND ACI attribute as I was for
the
others (it comes from the JDK). I've attached a
tiny
patch that fixes this for the PDFTextPainter.
I also have attached a patch for PDFGraphics2D.
The patch has two parts - the first is the more
important
of the two.
The first block is for drawing images and
does two things - first it installs the composite
from
the PDFGraphics when drawing the image to it's
offscreen
buffer - this ensures that 'group opacity' is
properly
propagated. Second it removes the 'composite with
white'
this was important before FOP handled masks but
since it
does that now I would remove it, it makes a quite
visible
difference in a lot of places.
The second part of the patch is probably not
that
important (but was part of my tracking down the
FOREGROUND
bug). It seems that in general PDFGraphics2D is a
little
shaky in how it treats color vs paint. This patch
just
tries to make sure that everywhere it sets color it
also
sets paint. This part probably needs more work but
might
warrent an entry in Bugzilla or something.
Glen Mazza wrote:
--- Thomas DeWeese [EMAIL PROTECTED]
wrote:
1.) We do not have plans anytime soon for making
a
new
release of maintenance--so, if I made the change,
the
new pdftranscoder.jar could be based only on a
nightly
build--is that OK with you?
I think that would be fine.
Changes have been made on maintenance (0.20.5) and
development (1.0) version. I also updated the
Batik
library to that of a nightly build.
I stand corrected--pdf transcoder.jar is actually
using our development (1.0) version--which is very
good news--you can checkout xml-fop and just run
Ant
(default target) to get the pdftranscoder.jar.
We've had some moving around in the files
recently--if
there's a problem with the pdftranscoder.jar, let
us
know--we may need to update the build process in
case
certain files have been left out.
How do I obtain a single batik.jar for me to
compile
According to an email from Keiron in the fop-dev
archives, FOP relies on the all-jar target in
your
build.xml. I just sent you a patch (in Bugzilla)
to
update the build.xml helptext to include a
description
of that target. (Saves confusion down the
road...)
Great that is a good idea.
Index:
src/java/org/apache/fop/svg/PDFTextPainter.java
===
RCS file:
/home/cvs/xml-fop/src/java/org/apache/fop/svg/PDFTextPainter.java,v
retrieving revision 1.7
diff -w -u -r1.7 PDFTextPainter.java
--- src/java/org/apache/fop/svg/PDFTextPainter.java
9 Sep 2003 19:44:22 - 1.7
+++ src/java/org/apache/fop/svg/PDFTextPainter.java
10 Sep 2003 09:54:26 -
@@ -138,7 +138,6 @@
gvtFonts = (List) aci.getAttribute(
GVTAttributedCharacterIterator.TextAttribute.GVT_FONT_FAMILIES);
-Paint forg = (Paint)
aci.getAttribute(TextAttribute.FOREGROUND);
TextPaintInfo tpi = (TextPaintInfo)
aci.getAttribute(
GVTAttributedCharacterIterator.TextAttribute.PAINT_INFO);
@@ -146,6 +145,7 @@
return;
}
+Paint forg = tpi.fillPaint;
Paint strokePaint = tpi.strokePaint;
Float size = (Float)
aci.getAttribute(TextAttribute.SIZE);
if (size == null) {
Index:
src/java/org/apache/fop/svg/PDFGraphics2D.java
===
RCS file:
/home/cvs/xml-fop/src/java/org/apache/fop/svg/PDFGraphics2D.java,v
retrieving revision 1.10
diff -w -u -r1.10 PDFGraphics2D.java
--- src/java/org/apache/fop/svg/PDFGraphics2D.java
20 Aug 2003 18:09:46 -1.10
+++ src/java/org/apache/fop/svg/PDFGraphics2D.java
10 Sep 2003 09:56:47 -
@@ -471,6 +471,7 @@
g.setPaint(new Color(1, 1, 1, 0));
g.fillRect(0, 0, width * scaleFactor,
height * scaleFactor);
g.clip(new Rectangle(0, 0,
buf.getWidth(), buf.getHeight()));
+g.setComposite(gc.getComposite());
if (!g.drawImage(img, 0, 0,
buf.getWidth(), buf.getHeight(), observer)) {
return false;
@@ -498,33 +499,13 @@
val = iarray[j];
alpha = val 24;
mask[maskpos++] =
(byte)(alpha 0xFF);
-if (alpha != 255) {
+if (alpha != 255)
Re: FOP updated to new Batik API
Hi Glen,
Thanks for doing this.
I just updated my FOP and ran some FO/SVG through it.
You seem to have gotten most of it, but I noticed that
you didn't use TextPainterInfo.fillPaint - instead you
continued to use the value of the FOREGROUND attribute.
You may not have noticed this becuase I was unable to
'remove' the FOREGROUND ACI attribute as I was for the
others (it comes from the JDK). I've attached a tiny
patch that fixes this for the PDFTextPainter.
I also have attached a patch for PDFGraphics2D.
The patch has two parts - the first is the more important
of the two.
The first block is for drawing images and
does two things - first it installs the composite from
the PDFGraphics when drawing the image to it's offscreen
buffer - this ensures that 'group opacity' is properly
propagated. Second it removes the 'composite with white'
this was important before FOP handled masks but since it
does that now I would remove it, it makes a quite visible
difference in a lot of places.
The second part of the patch is probably not that
important (but was part of my tracking down the FOREGROUND
bug). It seems that in general PDFGraphics2D is a little
shaky in how it treats color vs paint. This patch just
tries to make sure that everywhere it sets color it also
sets paint. This part probably needs more work but might
warrent an entry in Bugzilla or something.
Glen Mazza wrote:
--- Thomas DeWeese [EMAIL PROTECTED] wrote:
1.) We do not have plans anytime soon for making a
new
release of maintenance--so, if I made the change,
the
new pdftranscoder.jar could be based only on a
nightly
build--is that OK with you?
I think that would be fine.
Changes have been made on maintenance (0.20.5) and
development (1.0) version. I also updated the Batik
library to that of a nightly build.
I stand corrected--pdf transcoder.jar is actually
using our development (1.0) version--which is very
good news--you can checkout xml-fop and just run Ant
(default target) to get the pdftranscoder.jar.
We've had some moving around in the files recently--if
there's a problem with the pdftranscoder.jar, let us
know--we may need to update the build process in case
certain files have been left out.
How do I obtain a single batik.jar for me to compile
According to an email from Keiron in the fop-dev
archives, FOP relies on the all-jar target in your
build.xml. I just sent you a patch (in Bugzilla) to
update the build.xml helptext to include a description
of that target. (Saves confusion down the road...)
Great that is a good idea.
Index: src/java/org/apache/fop/svg/PDFTextPainter.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/svg/PDFTextPainter.java,v
retrieving revision 1.7
diff -w -u -r1.7 PDFTextPainter.java
--- src/java/org/apache/fop/svg/PDFTextPainter.java 9 Sep 2003 19:44:22 -
1.7
+++ src/java/org/apache/fop/svg/PDFTextPainter.java 10 Sep 2003 09:54:26 -
@@ -138,7 +138,6 @@
gvtFonts = (List) aci.getAttribute(
GVTAttributedCharacterIterator.TextAttribute.GVT_FONT_FAMILIES);
-Paint forg = (Paint) aci.getAttribute(TextAttribute.FOREGROUND);
TextPaintInfo tpi = (TextPaintInfo) aci.getAttribute(
GVTAttributedCharacterIterator.TextAttribute.PAINT_INFO);
@@ -146,6 +145,7 @@
return;
}
+Paint forg = tpi.fillPaint;
Paint strokePaint = tpi.strokePaint;
Float size = (Float) aci.getAttribute(TextAttribute.SIZE);
if (size == null) {
Index: src/java/org/apache/fop/svg/PDFGraphics2D.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/svg/PDFGraphics2D.java,v
retrieving revision 1.10
diff -w -u -r1.10 PDFGraphics2D.java
--- src/java/org/apache/fop/svg/PDFGraphics2D.java 20 Aug 2003 18:09:46 -
1.10
+++ src/java/org/apache/fop/svg/PDFGraphics2D.java 10 Sep 2003 09:56:47 -
@@ -471,6 +471,7 @@
g.setPaint(new Color(1, 1, 1, 0));
g.fillRect(0, 0, width * scaleFactor, height * scaleFactor);
g.clip(new Rectangle(0, 0, buf.getWidth(), buf.getHeight()));
+g.setComposite(gc.getComposite());
if (!g.drawImage(img, 0, 0, buf.getWidth(), buf.getHeight(), observer)) {
return false;
@@ -498,33 +499,13 @@
val = iarray[j];
alpha = val 24;
mask[maskpos++] = (byte)(alpha 0xFF);
-if (alpha != 255) {
+if (alpha != 255)
hasMask = true;
-/*
-if (alpha != 0) {
-binaryMask = false;
-}*/
-
-// System.out.println(Alpha: + alpha);
-
FOP updated to new Batik API
--- Thomas DeWeese [EMAIL PROTECTED] wrote: 1.) We do not have plans anytime soon for making a new release of maintenance--so, if I made the change, the new pdftranscoder.jar could be based only on a nightly build--is that OK with you? I think that would be fine. Changes have been made on maintenance (0.20.5) and development (1.0) version. I also updated the Batik library to that of a nightly build. I stand corrected--pdf transcoder.jar is actually using our development (1.0) version--which is very good news--you can checkout xml-fop and just run Ant (default target) to get the pdftranscoder.jar. We've had some moving around in the files recently--if there's a problem with the pdftranscoder.jar, let us know--we may need to update the build process in case certain files have been left out. How do I obtain a single batik.jar for me to compile the changed application against? What does an official batik.jar include? I don't know for certain but I suspect that this is all the classes from the source tree and files from the resource tree in batik (you could trim a little - get rid of interactive stuff but it would be small). According to an email from Keiron in the fop-dev archives, FOP relies on the all-jar target in your build.xml. I just sent you a patch (in Bugzilla) to update the build.xml helptext to include a description of that target. (Saves confusion down the road...) Thanks, Glen __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
DO NOT REPLY [Bug 17380] New: - Batik Component will not recognize feXXXX SVG elements
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17380. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17380 Batik Component will not recognize fe SVG elements Summary: Batik Component will not recognize fe SVG elements Product: Fop Version: 0.15 Platform: PC OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: svg AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I am having trouble rendering SVG elements prefixed with fe in FOP. The following is an excerpt from the fo document: fo:instream-foreign-object sg:svg xmlns:sg=http://www.w3.org/2000/svg; width=100 height=100 sg:filter id=Bevel filterUnits=objectBoundingBox x=-10% y=-10% width=150% height=150% sg:feGaussianBlur in=SourceAlpha stdDeviation=2 result=blur/ sg:feSpecularLighting in=blur surfaceScale=5 specularConstant=0.5 specularExponent=10 result=specOut style=lighting- color:rgb(255,255,255) sg:fePointLight x=-5000 y=-1 z=2/ /sg:feSpecularLighting sg:feComposite in=specOut in2=SourceAlpha operator=in result=specOut2/ sg:feComposite in=SourceGraphic in2=specOut2 operator=arithmetic k1=0 k2=1 k3=1 k4=0 result=litPaint/ /sg:filter sg:rect x=11 y=13 width=80 height=72 style=fill:rgb (0,0,255);stroke:rgb(0,0,0);stroke-width:1/ /sg:svg /fo:instream-foreign-object The following message appears when running fop: [DEBUG] Input mode: [DEBUG] xslt transformation [DEBUG] xml input file: dbStructure.xml [DEBUG] xslt stylesheet: tables-fo.xsl [DEBUG] Output mode: [DEBUG] pdf [DEBUG] output file: dbStructure.pdf [DEBUG] OPTIONS [DEBUG] no user configuration file is used [default] [DEBUG] debug mode on [DEBUG] dump configuration [DEBUG] quiet mode on [DEBUG] Using org.apache.xerces.parsers.SAXParser as SAX2 Parser [DEBUG] base directory: file:/C:/DATA/DOWNLOAD/XML/FOP/SRC/ [INFO] FOP 0.20.4 [DEBUG] Using org.apache.xerces.parsers.SAXParser as SAX2 Parser [INFO] building formatting object tree [DEBUG] setting up fonts [ERROR] Unknown formatting object http://www.w3.org/2000/svg^feSpecularLighting [ERROR] Unknown formatting object http://www.w3.org/2000/svg^fePointLight [ERROR] Unknown formatting object http://www.w3.org/2000/svg^feComposite The fo document renders, and the rectangle appears, however the blur and lighting aspects are not applied to the rectangle. The latest release of Batik supports all three elements rejected by FOP (confirmed on the Batik website). Also, the namespace checks out as correct on the W3C website. What do I have to do to get the version of Batik bundled with FOP to recognize these SVG elements? Regards, Justin. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: new batik
On Thu, 2002-05-16 at 17:53, Christian Geisert wrote: Is it possible to make Fop work without batik.jar ? (of course if no svg is used) This is addressed in the new code. Until then no, not without disabling it entirely. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: new batik
Keiron Liddle schrieb: Hi, Since a new beta of batik has been released I think we can go with this for the next release. I will put the new batik into cvs and update the code to work with it. Is it possible to make Fop work without batik.jar ? (of course if no svg is used) Keiron. Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
AW: new batik
Hello Christian, yes, it is possible to run FOP without batik, but you have to change the source. You have to remove all the imports to packages svg... and kick out all the references to classes having to do with svg. In fact we did this and we have a working version based on FOP 0.20.3 running without batik and producing nice PDF/PostScript/AWT (without svg). We had to do this since we are running FOP with VisualAge+WebSphere on jdk 1.2.2. Hope this helps. Greetings, Patrick Dipl. Inform. Patrick Chaumette T-Systems ITS GmbH Service Prozesse Retail Hausanschrift: Fasanenweg 9, 70771 Leinfelden-Echterdingen Postanschrift: Postfach 100258, 70746 Leinfelden-Echterdingen Telefon: (0711)972-2437 Telefax: (0711)972-1949 E-Mail: [EMAIL PROTECTED] Internet: http://www.t-systems.de -Ursprüngliche Nachricht- Von: Christian Geisert [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 16. Mai 2002 17:53 An: [EMAIL PROTECTED] Betreff: Re: new batik Keiron Liddle schrieb: Hi, Since a new beta of batik has been released I think we can go with this for the next release. I will put the new batik into cvs and update the code to work with it. Is it possible to make Fop work without batik.jar ? (of course if no svg is used) Keiron. Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
new batik
Hi, Since a new beta of batik has been released I think we can go with this for the next release. I will put the new batik into cvs and update the code to work with it. Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: new batik
At 09:40 13/05/2002, Keiron Liddle wrote: Hi, Since a new beta of batik has been released I think we can go with this for the next release. You mean we'll go with the next *release* of Batik with the next release of FOP... We aren't shipping beta software with our release are we? Any chance of upping the version number of FOP to something like 0.91 because some people don't seem to like using software as low as 0.24 Alex Openweb Analysts Ltd, London: Software For Complex Websites http://www.OWAL.co.uk/ Free Consultancy for London Companies thinking of Open Source Software. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: new batik
On Mon, 2002-05-13 at 12:59, Alex McLintock wrote: At 09:40 13/05/2002, Keiron Liddle wrote: Hi, Since a new beta of batik has been released I think we can go with this for the next release. You mean we'll go with the next *release* of Batik with the next release of FOP... We aren't shipping beta software with our release are we? Considering how FOP uses batik and what has been recently developed in batik, the animations and scripting. I think this should be very stable for its use within FOP. The main issue is about the api and this is an improvement from the previous situation anyway. Alternatively we could wait an indefinite amount of time where the situation may still be the same. I am simply removing a barrier to a release. Any chance of upping the version number of FOP to something like 0.91 because some people don't seem to like using software as low as 0.24 I didn't know making software was as easy as setting a number. Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: new batik
Alex wrote: Any chance of upping the version number of FOP to something like 0.91 because some people don't seem to like using software as low as 0.24 At 12:45 13/05/2002, Keiron Liddle wrote: I didn't know making software was as easy as setting a number. I should have put a smiley in there but it is a serious point. Some people are not using Fop because of its low version number. You and I know that the version 1.0 will be the one which complies with the XSL:FO spec and we are a long way from that. FOP does not cope with the whole spec but it is quite satisfactory for many jobs. However there is a purely psychological problem with using software with such a low version number - it discourages some potential users. That is why I suggested skipping some version numbers but still keeping it below version 1.0 Ale Openweb Analysts Ltd, London: Software For Complex Websites http://www.OWAL.co.uk/ Free Consultancy for London Companies thinking of Open Source Software. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Version numbers (WAS:RE: new batik)
Believe me when I say that I am well aware of how important promotion is in a project, but I still don't think that we should inflate a version number just to attract new users. FOP has now had articles published about it more than once in XML Journal, which is a far greater sign to users of FOP's capabilities than a version number. If we really wanted to be more appealing from a marketing perspective, I'd suggest that we instead use a milestone release system for production releases and leave the version numbers under the covers so to speak. Although, in all honesty, I don't think we really need to do that. FOP's got enough good PR without us slinging version numbers about to get a little bit more. This does touch on a more important issue, though. Do we have a standard for our version numbers? I was thinking that, until 1.0, it'd be a good idea for each release to denote what percentage of the FO spec we feel we've covered. For example, 0.20 would be a release supporting a fifth of the FO spec features. Just a thought. -Original Message- From: Alex McLintock [mailto:[EMAIL PROTECTED]] Sent: Monday, May 13, 2002 8:18 AM To: [EMAIL PROTECTED] Subject: Re: new batik Alex wrote: Any chance of upping the version number of FOP to something like 0.91 because some people don't seem to like using software as low as 0.24 At 12:45 13/05/2002, Keiron Liddle wrote: I didn't know making software was as easy as setting a number. I should have put a smiley in there but it is a serious point. Some people are not using Fop because of its low version number. You and I know that the version 1.0 will be the one which complies with the XSL:FO spec and we are a long way from that. FOP does not cope with the whole spec but it is quite satisfactory for many jobs. However there is a purely psychological problem with using software with such a low version number - it discourages some potential users. That is why I suggested skipping some version numbers but still keeping it below version 1.0 Ale Openweb Analysts Ltd, London: Software For Complex Websites http://www.OWAL.co.uk/ Free Consultancy for London Companies thinking of Open Source Software. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
