cvs commit: xml-fop/src/java/org/apache/fop/fo BorderWidthPropertyMaker.java CompoundPropertyMaker.java CorrespondingPropertyMaker.java DimensionPropertyMaker.java IndentPropertyMaker.java LineHeightPropertyMaker.java BoxPropShorthandParser.java CondLengthProperty.java EnumProperty.java FOPropertyMapping.java GenericShorthandParser.java KeepProperty.java LengthPairProperty.java LengthProperty.java LengthRangeProperty.java Property.java PropertyList.java ShorthandParser.java SpaceProperty.java

2004-01-22 Thread bckfnn 
bckfnn  2004/01/22 01:06:05

  Modified:.build.xml
   src/java/org/apache/fop/fo BoxPropShorthandParser.java
CondLengthProperty.java EnumProperty.java
FOPropertyMapping.java GenericShorthandParser.java
KeepProperty.java LengthPairProperty.java
LengthProperty.java LengthRangeProperty.java
Property.java PropertyList.java
ShorthandParser.java SpaceProperty.java
  Added:   src/java/org/apache/fop/fo BorderWidthPropertyMaker.java
CompoundPropertyMaker.java
CorrespondingPropertyMaker.java
DimensionPropertyMaker.java
IndentPropertyMaker.java
LineHeightPropertyMaker.java
  Log:
  Abandon codegenerated property makers and use bean-like makers instead.
  
  - ShorthandParsers are made stateless.
  - Makers for compound properties inherts from new CompoundPropertyMaker
class and overrides makeNewProperty.
  - FOPropertyMapping is no longer generated but is handcoded.
  - get() and findProperty() methods are moved from PropertyList to the
property makers.
  
  PR: 25873
  
  Revision  ChangesPath
  1.100 +1 -19 xml-fop/build.xml
  
  http://cvs.apache.org/viewcvs/xml-fop/build.xml.diff?r1=1.99r2=1.100
  
  
  1.6   +8 -7  xml-fop/src/java/org/apache/fop/fo/BoxPropShorthandParser.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/BoxPropShorthandParser.java.diff?r1=1.5r2=1.6
  
  
  1.4   +22 -2 xml-fop/src/java/org/apache/fop/fo/CondLengthProperty.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/CondLengthProperty.java.diff?r1=1.3r2=1.4
  
  
  1.5   +2 -2  xml-fop/src/java/org/apache/fop/fo/EnumProperty.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/EnumProperty.java.diff?r1=1.4r2=1.5
  
  
  1.2   +2472 -634 xml-fop/src/java/org/apache/fop/fo/FOPropertyMapping.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/FOPropertyMapping.java.diff?r1=1.1r2=1.2
  
  
  1.5   +12 -22xml-fop/src/java/org/apache/fop/fo/GenericShorthandParser.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/GenericShorthandParser.java.diff?r1=1.4r2=1.5
  
  
  1.4   +21 -1 xml-fop/src/java/org/apache/fop/fo/KeepProperty.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/KeepProperty.java.diff?r1=1.3r2=1.4
  
  
  1.4   +21 -1 xml-fop/src/java/org/apache/fop/fo/LengthPairProperty.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/LengthPairProperty.java.diff?r1=1.3r2=1.4
  
  
  1.5   +14 -1 xml-fop/src/java/org/apache/fop/fo/LengthProperty.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/LengthProperty.java.diff?r1=1.4r2=1.5
  
  
  1.4   +21 -1 xml-fop/src/java/org/apache/fop/fo/LengthRangeProperty.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/LengthRangeProperty.java.diff?r1=1.3r2=1.4
  
  
  1.17  +331 -161  xml-fop/src/java/org/apache/fop/fo/Property.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/Property.java.diff?r1=1.16r2=1.17
  
  
  1.28  +16 -107   xml-fop/src/java/org/apache/fop/fo/PropertyList.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/PropertyList.java.diff?r1=1.27r2=1.28
  
  
  1.5   +1 -0  xml-fop/src/java/org/apache/fop/fo/ShorthandParser.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/ShorthandParser.java.diff?r1=1.4r2=1.5
  
  
  1.4   +22 -2 xml-fop/src/java/org/apache/fop/fo/SpaceProperty.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/SpaceProperty.java.diff?r1=1.3r2=1.4
  
  
  1.1  xml-fop/src/java/org/apache/fop/fo/BorderWidthPropertyMaker.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/BorderWidthPropertyMaker.java?rev=1.1
  
  
  1.1  xml-fop/src/java/org/apache/fop/fo/CompoundPropertyMaker.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/CompoundPropertyMaker.java?rev=1.1
  
  
  1.1  
xml-fop/src/java/org/apache/fop/fo/CorrespondingPropertyMaker.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/CorrespondingPropertyMaker.java?rev=1.1
  
  
  1.1  xml-fop/src/java/org/apache/fop/fo/DimensionPropertyMaker.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/DimensionPropertyMaker.java?rev=1.1
  
  
  1.1  xml-fop/src/java/org/apache/fop/fo/IndentPropertyMaker.java
  
  
http://cvs.apache.org/viewcvs/xml-fop/src/java/org/apache/fop/fo/IndentPropertyMaker.java?rev=1.1
  
  
  1.1

DO NOT REPLY [Bug 25873] - [PATCH] abandoning code-generated Property.Maker

2004-01-22 Thread bugzilla 
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=25873.
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=25873

[PATCH] abandoning code-generated Property.Maker

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-01-22 09:10 ---
Applied.

Futher comments from xml-dev:
   http://marc.theaimsgroup.com/?l=fop-devm=107308498806385w=2
   http://marc.theaimsgroup.com/?l=fop-devm=107445625709662w=2
   http://marc.theaimsgroup.com/?l=fop-devm=107434372324847w=2

Re: missing Japanese character

2004-01-22 Thread Siarhei Baidun 

 Do you use the same metrics file ion bothe cases?

Yes I do

If so, it's probably one of the mapping problems.

Exactly. I saw PDF's inside that have got from FOP 0.20.5 and 0.20.4rc
versions.
Missing Japanese character has code 0004 in PDF's stream rendered by FOP
0.20.5.
But in PDF from 0.20.4rc symbol with code 0004 is empty space.

 The code should be either in one of the files in the font subdirectory or
in LineArea.java.

Suppose some problem with class that implements mapping.
If you have more exact suggestion, share please.

 You can try a CVS diff for a start.
 Is there a specific reason why you can't simply upgrade? especially
 the 0.20.4rc had a few nasty deficiencies.

Yes, there is. In fact a couple of reasons. One of them is we are planning
to make porting on new FOP (from main branch)

Unnesting properties and makers.

2004-01-22 Thread Finn Bock 
Hi,

After updating from CVS, it is most likely necessary to do an ant 
clean to get rid of the old generated maker classes, before building.

I have not yet removed the properties.xsl file from CVS. I guess it 
should be removed since it isn't used anymore.

I've found an argument for unnesting the maker classes from their 
property classes: If we want to put the makers in its own package and I 
think it would be a little cleaner to do that. Using the fo.properties 
package seems natural.

Does anyone know why we wrap the datatypes instances in a property 
instance? I think we could avoid the property instance by having the 
datatypes extends an AbstractProperty class which implement a Property 
interface:

public interface Property {
public Length getLength();
public Space getSpace();
...
}
public class AbstractProperty {
public Length getLength() {
return null;
}
public Space getSpace() {
return null;
}
...
}
public class Length extends AbstractProperty {
// Rest of datatypes.Length class.
...
public Length getLength() {
return this;
}
}
With such a change, one of the remaining differences between HEAD and 
Alt-Design would be in the naming of the classes:
  Property = PropertyValue
  Property.Maker = Property

Comments?

regards,
finn

cvs commit: xml-fop status.xml

2004-01-22 Thread bckfnn 
bckfnn  2004/01/22 02:54:39

  Modified:.status.xml
  Log:
  Update changes on code-generated property makers.
  
  Revision  ChangesPath
  1.34  +5 -0  xml-fop/status.xml
  
  Index: status.xml
  ===
  RCS file: /home/cvs/xml-fop/status.xml,v
  retrieving revision 1.33
  retrieving revision 1.34
  diff -u -r1.33 -r1.34
  --- status.xml2 Jun 2003 20:24:02 -   1.33
  +++ status.xml22 Jan 2004 10:54:39 -  1.34
  @@ -103,6 +103,11 @@
 /todo
   
 changes
  +   release version=2004 date=2004
  +action context=code dev=FB type=update
  +  Abandoned code-generated property maker classes.
  +/action
  +   /release
  release version=2003 date=2003
   action context=code dev=JM type=fix due-to=CTB/McGraw-Hill
 Fix for bad font encodings in the PS renderer (Fonts get reencoded as
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: xml-fop/src/java/org/apache/fop/fo LineHeightPropertyMaker.java

2004-01-22 Thread bckfnn 
bckfnn  2004/01/22 02:56:11

  Modified:src/java/org/apache/fop/fo LineHeightPropertyMaker.java
  Log:
  Fix typo in comments.
  
  Revision  ChangesPath
  1.2   +3 -3  xml-fop/src/java/org/apache/fop/fo/LineHeightPropertyMaker.java
  
  Index: LineHeightPropertyMaker.java
  ===
  RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fo/LineHeightPropertyMaker.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- LineHeightPropertyMaker.java  22 Jan 2004 09:06:05 -  1.1
  +++ LineHeightPropertyMaker.java  22 Jan 2004 10:56:11 -  1.2
  @@ -55,7 +55,7 @@
   
   /**
* A maker which calculates the line-height property.
  - * This property maker is special because line-heighe inherot the specified
  + * This property maker is special because line-height inherit the specified
* value, instead of the computed value.
* So when a line-height is create based on a attribute, the specified value
* is stored in the property and in compute() the stored specified value of
  @@ -118,4 +118,4 @@
   }
   return super.convertPropertyDatatype(p, propertyList, fo);
   }
  -}
  \ No newline at end of file
  +}
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

PDF Transcoder patch

2004-01-22 Thread Thomas DeWeese 
Hi all,

   I've attached a patch for the PDF Transcoder that Batik
uses.  There are three basic parts to the patch.  The first
gives each image added to the PDFGraphics2D a unique key.
Without this the PDF ends up referencing the same image
for each Jpeg added (this is the changes to PDFGraphics2D).
   The second part of the patch adds some additional classes
to the pdf-transcoder jar that are needed for some JPEG images.
It also adds a call to 'load(FopImage.ORIGINAL_DATA, null)' so
that colorspace info is available.  I am not entirely happy with
the location of this call, and I really don't like passing 'null'
as the UA - however I couldn't track down where the UA is available.
This call could/should also be moved into PDFDocument.addImage
or perhaps made internal to FopPDFImage.
   The third part is the removal of 'pdfg.setTransform(...)' from
the primitivePaint method from PDFImageElementBridge.

? diffs
? foUnits.pdf
? pdfDPI.patch
? pdfImage.patch
? pdfJpeg.patch
? pdfTranscoder.patch
Index: build.xml
===
RCS file: /home/cvs/xml-fop/build.xml,v
retrieving revision 1.99
diff -w -u -r1.99 build.xml
--- build.xml   21 Jan 2004 19:36:39 -  1.99
+++ build.xml   22 Jan 2004 01:59:12 -
@@ -538,7 +538,10 @@
 !--include name=org/apache/fop/layout/Font*.class/--
 include name=org/apache/fop/image/FopImag*.class/
 include name=org/apache/fop/image/Jpeg*/
+include name=org/apache/fop/image/EPS*/
 include name=org/apache/fop/image/Abstract*/
+include name=org/apache/fop/image/analyser/*.class/
+include name=org/apache/fop/util/CMYKColorSpace*.class/
 include name=org/apache/fop/util/StreamUtilities.class/
 include name=org/apache/fop/util/*OutputStream.class/
 include name=org/apache/fop/util/Finalizable.class/
@@ -598,7 +601,7 @@
   fileset dir=${build.dest}
 patternset refid=transcoder-classes/
   /fileset
-  fileset dir=${build.dir}/transcoder-dependencies/
+  fileset dir=${transcoder-deps}/
   manifest
 attribute name=Implementation-Title value=${fop-transcoder.name}/
 attribute name=Implementation-Version value=${fop-transcoder.version}/
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.12
diff -w -u -r1.12 PDFGraphics2D.java
--- src/java/org/apache/fop/svg/PDFGraphics2D.java  12 Dec 2003 22:37:39 - 
 1.12
+++ src/java/org/apache/fop/svg/PDFGraphics2D.java  22 Jan 2004 01:59:16 -
@@ -152,6 +152,12 @@
 protected int baseLevel = 0;
 
 /**
+ * The count of JPEG images added to document so they recieve
+ * unique keys.
+ */
+protected int jpegCount = 0;
+
+/**
  * The current font information.
  */
 protected Document fontInfo;
@@ -340,9 +346,13 @@
  * @param width the width to draw the image
  * @param height the height to draw the image
  */
-public void addJpegImage(JpegImage jpeg, float x, float y, float width, float 
height) {
-FopPDFImage fopimage = new FopPDFImage(jpeg, );
-int xObjectNum = this.pdfDoc.addImage(resourceContext, fopimage).getXNumber();
+public void addJpegImage(JpegImage jpeg, float x, float y, 
+ float width, float height) {
+String key = __AddJPEG_+jpegCount;
+jpegCount++;
+FopPDFImage fopimage = new FopPDFImage(jpeg, key);
+int xObjectNum = this.pdfDoc.addImage(resourceContext, 
+  fopimage).getXNumber();
 
 AffineTransform at = getTransform();
 double[] matrix = new double[6];
Index: src/java/org/apache/fop/svg/PDFImageElementBridge.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/svg/PDFImageElementBridge.java,v
retrieving revision 1.4
diff -w -u -r1.4 PDFImageElementBridge.java
--- src/java/org/apache/fop/svg/PDFImageElementBridge.java  3 Jan 2004 03:25:02 
-   1.4
+++ src/java/org/apache/fop/svg/PDFImageElementBridge.java  22 Jan 2004 01:59:16 
-
@@ -97,6 +97,7 @@
 (purl.toString(), purl.openStream(), null);
 if (ii.mimeType.toLowerCase() == image/jpeg) {
 JpegImage jpeg = new JpegImage(ii);
+jpeg.load(FopImage.ORIGINAL_DATA, null);
 PDFJpegNode node = new PDFJpegNode(jpeg, origGN);
 
 Rectangle2D imgBounds = getImageBounds(ctx, e);
@@ -154,7 +155,6 @@
 public void primitivePaint(Graphics2D g2d) {
 if (g2d instanceof PDFGraphics2D) {
 PDFGraphics2D pdfg = (PDFGraphics2D) g2d;
-pdfg.setTransform(getTransform());
 float x = 0;
 float y = 0;

Re: missing Japanese character

2004-01-22 Thread J.Pietschmann 
Siarhei Baidun wrote:
If you have more exact suggestion, share please.
Probably .../org/apache/fop/renderer/pdf/fonts/MultiByteFont.java,

One of them is we are planning
to make porting on new FOP (from main branch)
Don't hold your breath here.

J.Pietschmann

Re: Unnesting properties and makers.

2004-01-22 Thread J.Pietschmann 
Finn Bock wrote:
I have not yet removed the properties.xsl file from CVS. I guess it 
should be removed since it isn't used anymore.
I think you could leave the file there for now. It should be
sufficient to  inactivate the related task in the buildfile
(for example putting it in an XML comment).
Does anyone know why we wrap the datatypes instances in a property 
instance?
No.

Actually we should strive to use a proper parse tree for
property expressions:
1. Create a few classes for the symbols in the property
  expression grammar (section 5.9 of the spec). I think we need
 as terminals
 - AbsoluteNumeric
 - RelativeNumeric
 - Color (the #N thingy)
 - String (aka Literal)
 - NCName (everything else, basically, including enum tokens and
  inherit)
 and for the nonterminals
 - PropertyFunction
 - Some classes for the operators
2. Write a proper parser (maybe using ANTLR, at least for bootstrap)
 which produces a proper parse tree.
3. Add methods to the objects for resolving relative numeric values
 (percentages, em) and for evaluation.
4. Perhaps add constant folding to the parser.
J.Pietschmann

Re: Unnesting properties and makers.

2004-01-22 Thread Finn Bock 

I have not yet removed the properties.xsl file from CVS. I guess it 
should be removed since it isn't used anymore.
[J.Pietschmann]

I think you could leave the file there for now. 
Ok.

It should be
sufficient to  inactivate the related task in the buildfile
(for example putting it in an XML comment).
Too late for that, but I'll reactive the lines as comments tomorrow.

Does anyone know why we wrap the datatypes instances in a property 
instance?
No.

Actually we should strive to use a proper parse tree for
property expressions:
1. Create a few classes for the symbols in the property
  expression grammar (section 5.9 of the spec). I think we need
 as terminals
 - AbsoluteNumeric
 - RelativeNumeric
 - Color (the #N thingy)
 - String (aka Literal)
 - NCName (everything else, basically, including enum tokens and
  inherit)
 and for the nonterminals
 - PropertyFunction
 - Some classes for the operators
2. Write a proper parser (maybe using ANTLR, at least for bootstrap)
 which produces a proper parse tree.
3. Add methods to the objects for resolving relative numeric values
 (percentages, em) and for evaluation.
4. Perhaps add constant folding to the parser.
Interesting. What issues do we have in property parsing that is solved 
by this? I'm only aware of arithmetic on relative numerics which doesn't 
work.

regards,
finn

Getting rid of JIMI

2004-01-22 Thread Dalibor Topic 
Hi,

I was looking into getting FOP to run with kaffe[1] recently[2][3], and 
decided to have another look at it today, after gettig maven to run with 
kaffe. I tried to generate DocBook docuemntation for another package, 
and the Maven sdocbook plugin insisted on fetching jimi.jar from Sun.

So I'm wondering whether there is any need for JIMI any more in current 
FOP CVS sources, i.e. if PNG image handling is now being done within FOP 
internally?

If that's not the case, would it be possible to use the LGPLd code from 
http://catcode.com/pngencoder/ and http://www.sixlegs.com/software/png/ 
for the job, and dropping the dependency on JIMI completely?

If this is a FAQ, I'm sorry for wasting your time, I couldn't find an 
answer in the FAQs ...

cheers,
dalibor topic
[1] A free software runtime for java programs, see http://www.kaffe.org
[2] http://www.mail-archive.com/[EMAIL PROTECTED]/msg04038.html
[3] http://www.mail-archive.com/[EMAIL PROTECTED]/msg04023.html

Re: Unnesting properties and makers.

2004-01-22 Thread Glen Mazza 
--- Finn Bock [EMAIL PROTECTED] wrote:
 Hi,
 
 After updating from CVS, it is most likely necessary
 to do an ant 
 clean to get rid of the old generated maker
 classes, before building.
 

Great job--the build is now only 604 classes--1/3
removed!  This simplification does make the properties
easier to understand (although I'm still quite far
from fully comprehending them.)

 I have not yet removed the properties.xsl file from
 CVS. I guess it 
 should be removed since it isn't used anymore.
 

Good idea.

 
 I've found an argument for unnesting the maker
 classes from their 
 property classes: If we want to put the makers in
 its own package and I 
 think it would be a little cleaner to do that. Using
 the fo.properties 
 package seems natural.
 

Makes sense.


 
 Does anyone know why we wrap the datatypes instances
 in a property 
 instance? I think we could avoid the property
 instance by having the 
 datatypes extends an AbstractProperty class which
 implement a Property 
 interface:
 

Could you explain why we have the datatypes instances
to begin with--what they're for?  I'm not sure what
their precise purpose is.

Offhand, it's doesn't seem natural to go without
Property objects--they are kept in the PropertyList
and indexed by the property ID in that list. 
Furthermore, those are the objects requested by
layout.  What would be your alternative storage
technique otherwise--I believe, we do (frequently?)
have more than one datatype per property, correct?

Thanks,
Glen


__
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

Re: Getting rid of JIMI

2004-01-22 Thread Glen Mazza 
--- Dalibor Topic [EMAIL PROTECTED] wrote:
 If that's not the case, would it be possible to use
 the LGPLd code from 
 http://catcode.com/pngencoder/ and
 http://www.sixlegs.com/software/png/ 
 for the job, and dropping the dependency on JIMI
 completely?
 

No, (L)GPL and the Apache licenses are not compatible.

Glen

__
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

cvs commit: xml-fop/src/java/org/apache/fop/svg PDFGraphics2D.java PDFImageElementBridge.java

2004-01-22 Thread gmazza 
gmazza  2004/01/22 14:40:51

  Modified:.build.xml
   src/java/org/apache/fop/svg PDFGraphics2D.java
PDFImageElementBridge.java
  Log:
  Applied Thomas DeWeese's latest patch for the PDF transcoder.
  
  Revision  ChangesPath
  1.101 +4 -1  xml-fop/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/xml-fop/build.xml,v
  retrieving revision 1.100
  retrieving revision 1.101
  diff -u -r1.100 -r1.101
  --- build.xml 22 Jan 2004 09:06:05 -  1.100
  +++ build.xml 22 Jan 2004 22:40:51 -  1.101
  @@ -520,7 +520,10 @@
   !--include name=org/apache/fop/layout/Font*.class/--
   include name=org/apache/fop/image/FopImag*.class/
   include name=org/apache/fop/image/Jpeg*/
  +include name=org/apache/fop/image/EPS*/
   include name=org/apache/fop/image/Abstract*/
  +include name=org/apache/fop/image/analyser/*.class/
  +include name=org/apache/fop/util/CMYKColorSpace*.class/
   include name=org/apache/fop/util/StreamUtilities.class/
   include name=org/apache/fop/util/*OutputStream.class/
   include name=org/apache/fop/util/Finalizable.class/
  @@ -580,7 +583,7 @@
 fileset dir=${build.dest}
   patternset refid=transcoder-classes/
 /fileset
  -  fileset dir=${build.dir}/transcoder-dependencies/
  +  fileset dir=${transcoder-deps}/
 manifest
   attribute name=Implementation-Title value=${fop-transcoder.name}/
   attribute name=Implementation-Version value=${fop-transcoder.version}/
  
  
  
  1.13  +13 -3 xml-fop/src/java/org/apache/fop/svg/PDFGraphics2D.java
  
  Index: PDFGraphics2D.java
  ===
  RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/svg/PDFGraphics2D.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- PDFGraphics2D.java12 Dec 2003 22:37:39 -  1.12
  +++ PDFGraphics2D.java22 Jan 2004 22:40:51 -  1.13
  @@ -152,6 +152,12 @@
   protected int baseLevel = 0;
   
   /**
  + * The count of JPEG images added to document so they recieve
  + * unique keys.
  + */
  +protected int jpegCount = 0;
  +
  +/**
* The current font information.
*/
   protected Document fontInfo;
  @@ -340,9 +346,13 @@
* @param width the width to draw the image
* @param height the height to draw the image
*/
  -public void addJpegImage(JpegImage jpeg, float x, float y, float width, float 
height) {
  -FopPDFImage fopimage = new FopPDFImage(jpeg, );
  -int xObjectNum = this.pdfDoc.addImage(resourceContext, 
fopimage).getXNumber();
  +public void addJpegImage(JpegImage jpeg, float x, float y, 
  + float width, float height) {
  +String key = __AddJPEG_+jpegCount;
  +jpegCount++;
  +FopPDFImage fopimage = new FopPDFImage(jpeg, key);
  +int xObjectNum = this.pdfDoc.addImage(resourceContext, 
  +  fopimage).getXNumber();
   
   AffineTransform at = getTransform();
   double[] matrix = new double[6];
  
  
  
  1.5   +1 -1  xml-fop/src/java/org/apache/fop/svg/PDFImageElementBridge.java
  
  Index: PDFImageElementBridge.java
  ===
  RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/svg/PDFImageElementBridge.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- PDFImageElementBridge.java3 Jan 2004 03:25:02 -   1.4
  +++ PDFImageElementBridge.java22 Jan 2004 22:40:51 -  1.5
  @@ -97,6 +97,7 @@
   (purl.toString(), purl.openStream(), null);
   if (ii.mimeType.toLowerCase() == image/jpeg) {
   JpegImage jpeg = new JpegImage(ii);
  +jpeg.load(FopImage.ORIGINAL_DATA, null);
   PDFJpegNode node = new PDFJpegNode(jpeg, origGN);
   
   Rectangle2D imgBounds = getImageBounds(ctx, e);
  @@ -154,7 +155,6 @@
   public void primitivePaint(Graphics2D g2d) {
   if (g2d instanceof PDFGraphics2D) {
   PDFGraphics2D pdfg = (PDFGraphics2D) g2d;
  -pdfg.setTransform(getTransform());
   float x = 0;
   float y = 0;
   try {
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: PDF Transcoder patch

2004-01-22 Thread Glen Mazza 
Applied, thanks!
Glen

--- Thomas DeWeese [EMAIL PROTECTED] wrote:
 Hi all,
 
 I've attached a patch for the PDF Transcoder
 that Batik
 uses.  



__
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

Re: Getting rid of JIMI

2004-01-22 Thread Dalibor Topic 
Hi Glen,

thanks for the quick reply.

Glen Mazza wrote:
--- Dalibor Topic [EMAIL PROTECTED] wrote:

If that's not the case, would it be possible to use
the LGPLd code from 
http://catcode.com/pngencoder/ and
http://www.sixlegs.com/software/png/ 
for the job, and dropping the dependency on JIMI
completely?



No, (L)GPL and the Apache licenses are not compatible.
While I understand that GPL2 and ASL 1.1 are not compatible, I don't see 
a problem with LGPL 2.1 and ASL 1.1. Could you elaborate?

cheers,
dalibor topic