Re: Patches for FOP PDF and JPEG

2004-08-17 Thread Peter B. West
Thomas,
Could you clarify something for me please.  As I understood it, the 
Java2D stuff assumes a normalized unit of measurement of 1pt = 1/72 
inch.  It provides float and double versions of the graphical objects, 
like Rectangle2D.Double and Rectangle2D.Float.  The GraphicsDevice 
objects within the GraphicsEnvironment then transform measurements in 
the normalized form into device units.  It is this normalization that 
allows for the predictable representation of of graphics objects on 
different output media.

So far, so good?
Was it your intention that the SVGGraphics2d environment provide such 
functionality?  Is this still the case?

Peter
--
Peter B. West http://cv.pbw.id.au/


Re: Patches for FOP PDF and JPEG

2004-08-17 Thread Thomas DeWeese
Hi Peter,
   I suspect I'm kind of missing your point, perhaps you can be
clearer in what you are looking for from SVGGraphics2D?
Peter B. West wrote:
Could you clarify something for me please.  As I understood it, the 
Java2D stuff assumes a normalized unit of measurement of 1pt = 1/72 
inch.  It provides float and double versions of the graphical objects, 
like Rectangle2D.Double and Rectangle2D.Float.  The GraphicsDevice 
objects within the GraphicsEnvironment then transform measurements in 
the normalized form into device units.  It is this normalization that 
allows for the predictable representation of of graphics objects on 
different output media.

So far, so good?
  Actually I don't think this is entirely accurate.  The Graphics2D
when you get it is set such that 1 unit ~= 1/72 inch (for displays
it is set to 1 pixel which may be 1/96th inch).  If you ask the
Graphics2D for it's transform, you get the transform from the current
'user space' to device space.  For screen devices this is usually 1:1,
for print devices this is usually ~1:4.  Applications that know what
they are doing take care to rasterize content at the device resolution
not at userspace resolution.
Was it your intention that the SVGGraphics2d environment provide such 
functionality?  Is this still the case?
  I think that SVGGraphics2D conforms to this basic idea[*].  It has
the deficiency that you can't specify an initial 72dpi-device
transform, which is useful for when content gets rasterized.  This is
essentially the same issue as the PDF graphics has for raster content.
[*] One unit in the SVG Graphics2D maps to one unit in the root SVG
element's user space, which unless someone adds a viewBox should
map roughly to either 1 screen pixel or 1/72nd of an inch on a
print.



Re: Patches for FOP PDF and JPEG

2004-08-16 Thread Thomas DeWeese
Jeremias Maerki wrote:
As you can see from the CVS messages I had to fix a few classes in the
images package. I wonder how you could test the whole thing with these
classes messed up. I got NPEs and such. Anyway, it's fixed now.
   Well, I was testing JPEG functionality and the log changes were
only for exception handling which is what I was avoiding ;).
   Also this change is also a bit old in my copy so most of the
development/testing was done a while ago.

On 15.08.2004 22:53:50 Thomas DeWeese wrote:
Hi guys,
   Sorry, there was a mistake in the patch (resolved a conflict
wrong), use the attached one instead (you think you checked
everything...)
Thomas DeWeese wrote:

Hi guys,
   These patches have nothing to do with your recent request for
more information about the PDFTranscoder.  The most important
one is the fix for getPixelUnitToMillimeter which currently
causes PDF output to be the wrong size.
   The other patches enable the JPEG code to work correctly
for JPEG files that have lots of long APP markers in them.
I think Photoshop and a few other apps can do this.  It also
defers the creation of the original node until it absolutely
has to thus avoiding decoding the JPEG file and creating
the raster unless needed.
   Let me know if you have any questions on either of these
and I will be looking to Jeremias's questions shortly.


Jeremias Maerki



Patches for FOP PDF and JPEG

2004-08-15 Thread Thomas DeWeese
Hi guys,
   These patches have nothing to do with your recent request for
more information about the PDFTranscoder.  The most important
one is the fix for getPixelUnitToMillimeter which currently
causes PDF output to be the wrong size.
   The other patches enable the JPEG code to work correctly
for JPEG files that have lots of long APP markers in them.
I think Photoshop and a few other apps can do this.  It also
defers the creation of the original node until it absolutely
has to thus avoiding decoding the JPEG file and creating
the raster unless needed.
   Let me know if you have any questions on either of these
and I will be looking to Jeremias's questions shortly.
? diffs
? foUnits.pdf
? pdfDPI.patch
? pdfImage.patch
? pdfJpeg.patch
? pdfTranscoder.patch
Index: src/java/org/apache/fop/image/analyser/JPEGReader.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/image/analyser/JPEGReader.java,v
retrieving revision 1.3
diff -w -u -r1.3 JPEGReader.java
--- src/java/org/apache/fop/image/analyser/JPEGReader.java  27 Feb 2004 17:47:30 
-  1.3
+++ src/java/org/apache/fop/image/analyser/JPEGReader.java  15 Aug 2004 17:54:47 
-
@@ -98,17 +98,35 @@
 private FopImage.ImageInfo getDimension(InputStream imageStream) throws 
IOException {
 FopImage.ImageInfo info = new FopImage.ImageInfo();
 try {
-imageStream.mark(imageStream.available());
+int pos=0, avail = imageStream.available();
+imageStream.mark(avail);
 int marker = NULL;
 long length, skipped;
 outer:
-while (imageStream.available()  0) {
-while ((marker = imageStream.read()) != MARK) {
-//nop, simply skip
+while (true) {
+do {
+if (avail == 0) {
+imageStream.reset();
+avail = 2*pos;
+imageStream.mark(avail);
+pos = (int)this.skip(imageStream, pos);
+avail -= pos;
 }
 
+marker = imageStream.read();
+pos++; avail--;
+} while (marker != MARK);
+
 do {
+if (avail == 0) {
+imageStream.reset();
+avail = 2*pos;
+imageStream.mark(avail);
+pos = (int)this.skip(imageStream, pos);
+avail -= pos;
+}
 marker = imageStream.read();
+pos++; avail--;
 } while (marker == MARK);
 
 switch (marker) {
@@ -120,13 +138,42 @@
 case SOF2:
 case SOF3: // SOF3 and SOFA are only supported by PDF 1.3
 case SOFA:
+while (avail  7) {
+imageStream.reset();
+avail = 2*pos;
+imageStream.mark(avail);
+pos = (int)this.skip(imageStream, pos);
+avail -= pos;
+}
 this.skip(imageStream, 3);
+pos+=3; avail-=3;
 info.height = this.read2bytes(imageStream);
+pos+=2; avail-=2;
 info.width = this.read2bytes(imageStream);
+pos+=2; avail-=2;
 break outer;
 default:
+while (avail  2) {
+imageStream.reset();
+avail = 2*pos;
+imageStream.mark(avail);
+pos = (int)this.skip(imageStream, pos);
+avail -= pos;
+}
 length = this.read2bytes(imageStream);
+pos+=2; avail-=2;
+if (avail  length) {
+imageStream.reset();
+avail = 2*pos;
+if (avail  pos+length+10) {
+avail = (int)(pos+length+10);
+}
+imageStream.mark(avail);
+pos = (int)this.skip(imageStream, pos);
+avail -= pos;
+}
 skipped = this.skip(imageStream, length - 2);
+pos += skipped; avail -= skipped;
 if (skipped != length - 2) {
 throw new IOException(Skipping Error);
 }
Index: src/java/org/apache/fop/svg/PDFImageElementBridge.java
===
RCS file: 

Re: Patches for FOP PDF and JPEG

2004-08-15 Thread Jeremias Maerki
Funny coincidence. I've just applied the patch locally and can't compile
PDFImageElementBridge anymore. The problem is this line:

   PDFJpegNode node = new PDFJpegNode(jpeg, origGN);

origGN isn't defined anymore but this line isn't affected by your patch.
Any idea? I'll have another look at it when I have time again tomorrow
evening (21h from now).

Something else: Wouldn't it be easier and more readable to write 25.4 /
72 instead of 0.352778f?

On 15.08.2004 21:10:54 Thomas DeWeese wrote:
 Hi guys,
 
  These patches have nothing to do with your recent request for
 more information about the PDFTranscoder.  The most important
 one is the fix for getPixelUnitToMillimeter which currently
 causes PDF output to be the wrong size.
 
  The other patches enable the JPEG code to work correctly
 for JPEG files that have lots of long APP markers in them.
 I think Photoshop and a few other apps can do this.  It also
 defers the creation of the original node until it absolutely
 has to thus avoiding decoding the JPEG file and creating
 the raster unless needed.
 
  Let me know if you have any questions on either of these
 and I will be looking to Jeremias's questions shortly.


Jeremias Maerki



Re: Patches for FOP PDF and JPEG

2004-08-15 Thread Thomas DeWeese
Hi guys,
   Sorry, there was a mistake in the patch (resolved a conflict
wrong), use the attached one instead (you think you checked
everything...)
Thomas DeWeese wrote:
Hi guys,
These patches have nothing to do with your recent request for
more information about the PDFTranscoder.  The most important
one is the fix for getPixelUnitToMillimeter which currently
causes PDF output to be the wrong size.
The other patches enable the JPEG code to work correctly
for JPEG files that have lots of long APP markers in them.
I think Photoshop and a few other apps can do this.  It also
defers the creation of the original node until it absolutely
has to thus avoiding decoding the JPEG file and creating
the raster unless needed.
Let me know if you have any questions on either of these
and I will be looking to Jeremias's questions shortly.

? PDFSz.patch
? diffs
? foUnits.pdf
? pdfDPI.patch
? pdfImage.patch
? pdfJpeg.patch
? pdfTranscoder.patch
Index: src/java/org/apache/fop/image/analyser/JPEGReader.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/image/analyser/JPEGReader.java,v
retrieving revision 1.3
diff -w -u -r1.3 JPEGReader.java
--- src/java/org/apache/fop/image/analyser/JPEGReader.java  27 Feb 2004 17:47:30 
-  1.3
+++ src/java/org/apache/fop/image/analyser/JPEGReader.java  15 Aug 2004 20:24:29 
-
@@ -98,17 +98,35 @@
 private FopImage.ImageInfo getDimension(InputStream imageStream) throws 
IOException {
 FopImage.ImageInfo info = new FopImage.ImageInfo();
 try {
-imageStream.mark(imageStream.available());
+int pos=0, avail = imageStream.available();
+imageStream.mark(avail);
 int marker = NULL;
 long length, skipped;
 outer:
-while (imageStream.available()  0) {
-while ((marker = imageStream.read()) != MARK) {
-//nop, simply skip
+while (true) {
+do {
+if (avail == 0) {
+imageStream.reset();
+avail = 2*pos;
+imageStream.mark(avail);
+pos = (int)this.skip(imageStream, pos);
+avail -= pos;
 }
 
+marker = imageStream.read();
+pos++; avail--;
+} while (marker != MARK);
+
 do {
+if (avail == 0) {
+imageStream.reset();
+avail = 2*pos;
+imageStream.mark(avail);
+pos = (int)this.skip(imageStream, pos);
+avail -= pos;
+}
 marker = imageStream.read();
+pos++; avail--;
 } while (marker == MARK);
 
 switch (marker) {
@@ -120,13 +138,42 @@
 case SOF2:
 case SOF3: // SOF3 and SOFA are only supported by PDF 1.3
 case SOFA:
+while (avail  7) {
+imageStream.reset();
+avail = 2*pos;
+imageStream.mark(avail);
+pos = (int)this.skip(imageStream, pos);
+avail -= pos;
+}
 this.skip(imageStream, 3);
+pos+=3; avail-=3;
 info.height = this.read2bytes(imageStream);
+pos+=2; avail-=2;
 info.width = this.read2bytes(imageStream);
+pos+=2; avail-=2;
 break outer;
 default:
+while (avail  2) {
+imageStream.reset();
+avail = 2*pos;
+imageStream.mark(avail);
+pos = (int)this.skip(imageStream, pos);
+avail -= pos;
+}
 length = this.read2bytes(imageStream);
+pos+=2; avail-=2;
+if (avail  length) {
+imageStream.reset();
+avail = 2*pos;
+if (avail  pos+length+10) {
+avail = (int)(pos+length+10);
+}
+imageStream.mark(avail);
+pos = (int)this.skip(imageStream, pos);
+avail -= pos;
+}
 skipped = this.skip(imageStream, length - 2);
+pos += skipped; avail -= skipped;
 if (skipped != length - 2) {
 throw new