Re: Image Size Calculations

[Clay Leeds]

Greetings,
On Jun 8, 2004, at 1:55 PM, J.Pietschmann wrote:
Darn, the mail server failed yesterday. Resending.
And I thought it was just me...
Peter B. West wrote:
> I think the problem is that pixels are not well-defined.  In 
general, a pixel is an output-dependent unit.  On a printer, a pixel 
might be 1/2400 inch, on the screen, 1/96".  The Recommendation warns 
about this in 5.9.13.1 Pixels.  I suggest that anyone tempted to 
define lengths in "px" read that section of the Recommendation.  It's 
not so bad if the units are completely "internal", that is, that it 
only affects text, tables and the like.  But when you import an image 
constructed externally, and defined in pixels for God knows what 
output device, you are asking for trouble.

Well, perhaps we should use wording like this in graphics.xml:
"FOP always assumes a resolution of 72dpi on encountering pixel
measurements, regardless of the output device, and converts all length
measured in pixels in millipoints using 1/72 pixels per inch as
conversion factor. The layout stage doesn't use pixels, even if the
final rendering is on a bitmapped device like the monitor. A bitmapped
image without explicit measurements is assumed to have the actual pixel
counts as measurements. Any resolution declaration in the image 
metadata
is ignored."
I was about to make these changes, when I realized I wasn't certain 
where these edits would be made:

Overview of Graphics Support
http://xml.apache.org/fop/graphics.html#support-overview
Graphics Resolution
http://xml.apache.org/fop/graphics.html#resolution
I am leaning towards the latter. Which leads to the question: replace 
the first paragraph?

BTW, nice work, Jorg!
BTW does someone know how resolution is stored in GIFs, and whether
the Java image API can retrieve this?
I was under the impression GIF files were always 8-bit (256 color) at 
72dpi.

This search gave me some nice hits:
http://www.google.com/search?q=GIF+resolution&ie=UTF-8&oe=UTF-8
> Bottom line - don't define *anything* in px.
Yeah, double this. I have no idea why people are confused to no
end by this issue.
J.Pietschmann
If we put it on the site in a WARNING box, it'll resonate...
Web Maestro Clay
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Image Size Calculations

[Peter B. West]

J.Pietschmann wrote:
Well, perhaps we should use wording like this in graphics.xml:
"FOP always assumes a resolution of 72dpi on encountering pixel
measurements, regardless of the output device, and converts all length
measured in pixels in millipoints using 1/72 pixels per inch as
conversion factor. The layout stage doesn't use pixels, even if the
final rendering is on a bitmapped device like the monitor. A bitmapped
image without explicit measurements is assumed to have the actual pixel
counts as measurements. Any resolution declaration in the image metadata
is ignored."
Ideal.
Peter
--
Peter B. West 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Image Size Calculations

[J.Pietschmann]

Darn, the mail server failed yesterday. Resending.
Peter B. West wrote:
> I think the problem is that pixels are not well-defined.  In general, 
a pixel is an output-dependent unit.  On a printer, a pixel might be 
1/2400 inch, on the screen, 1/96".  The Recommendation warns about this 
in 5.9.13.1 Pixels.  I suggest that anyone tempted to define lengths in 
"px" read that section of the Recommendation.  It's not so bad if the 
units are completely "internal", that is, that it only affects text, 
tables and the like.  But when you import an image constructed 
externally, and defined in pixels for God knows what output device, you 
are asking for trouble.

Well, perhaps we should use wording like this in graphics.xml:
"FOP always assumes a resolution of 72dpi on encountering pixel
measurements, regardless of the output device, and converts all length
measured in pixels in millipoints using 1/72 pixels per inch as
conversion factor. The layout stage doesn't use pixels, even if the
final rendering is on a bitmapped device like the monitor. A bitmapped
image without explicit measurements is assumed to have the actual pixel
counts as measurements. Any resolution declaration in the image metadata
is ignored."
BTW does someone know how resolution is stored in GIFs, and whether
the Java image API can retrieve this?
> Bottom line - don't define *anything* in px.
Yeah, double this. I have no idea why people are confused to no
end by this issue.
J.Pietschmann
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Image Size Calculations

[Christian Hattemer]

Clay Leeds wrote:

> If it's true that graphics measurements specified in INCHES yields 
> better results than PX, that certainly is news, and would (if 
> reproducible) warrant special mention on the FOP Graphics page. Can you 
> also do a test to see if the results are similar if you specify mm and 
> cm (millimeters & centimeters of course ;-)) as well?

I just found out that xpdf has fooled me. The default magnification level is
125%. It's clear that the images don't look good because they have been
scaled up for display. The images are fine when selecting 100%. Argh!

The images are too large in relation to the text, but that should be easy to
fix.

Another interesting thing is that another PDF of the same site, which was
built a few years ago using Windows tools (AFAIK MS Word and Adobe
Distiller), looks best at a magnification level of 150%. At 125% it still looks
better than the one I produced, but a close look with xmag reveals that it
is scaled. At 100% it's even more scaled. Dunno why this happens,
Windows is always strange.
 
> BTW, I don't know if this is related, but GIF images do not scale well, 
> as they are a form of a INDEXED BITMAP image. JPG images scale much 
> better. This could be part of the problem. If you're working with line 
> drawings, perhaps SVG might be a better format to use in your 
> documents.

Have a look at my previous mail if you want to see the images I'm working with.

Bye, Chris






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

Re: Image Size Calculations

[Peter B. West]

Clay Leeds wrote:
On Jun 7, 2004, at 2:13 AM, Chris Bowditch wrote:
Christian Hattemer wrote:
If it's true that graphics measurements specified in INCHES yields 
better results than PX, that certainly is news, and would (if 
reproducible) warrant special mention on the FOP Graphics page. Can you 
also do a test to see if the results are similar if you specify mm and 
cm (millimeters & centimeters of course ;-)) as well?
I think the problem is that pixels are not well-defined.  In general, a 
pixel is an output-dependent unit.  On a printer, a pixel might be 
1/2400 inch, on the screen, 1/96".  The Recommendation warns about this 
in 5.9.13.1 Pixels.  I suggest that anyone tempted to define lengths in 
"px" read that section of the Recommendation.  It's not so bad if the 
units are completely "internal", that is, that it only affects text, 
tables and the like.  But when you import an image constructed 
externally, and defined in pixels for God knows what output device, you 
are asking for trouble.

Consider the lengths that Gimp goes to on installation to make sure that 
images are reliably sized.  You must effectively tell Gimp exactly what 
the size of a screen pixel is on your monitor.  Incidentally, if you 
want to find out about the dimensions of images, install Gimp and load 
the image.  Because of Gimp's awareness of your monitor size, you should 
be able to get reliable translations of image sizes into stable units.

Bottom line - don't define *anything* in px.
BTW, I don't know if this is related, but GIF images do not scale well, 
as they are a form of a INDEXED BITMAP image. JPG images scale much 
better. This could be part of the problem. If you're working with line 
drawings, perhaps SVG might be a better format to use in your documents.

This leads to the question: How can I find out the actual resolution 
of my
images and calculate the dimensions in inches? Do I have to modify the
generated fo afterwards to include the calculated dimensions?

Dont you know the resolution of the images? It is difficult for me to 
answer this question as I dont know where you get the images from. In 
my environment, the system responsible for generating the images 
stores the measurements in cm/mm/inches along with the resolution and 
the image itself.

Chris

Can't you just load the image directly into a web browser:
images/NetworkModel/Basics/BachmanDiagram.GIF
--
Peter B. West 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Image Size Calculations

[Clay Leeds]

On Jun 7, 2004, at 2:13 AM, Chris Bowditch wrote:
Christian Hattemer wrote:

The images are a bunch of line drawings and other illustrations from a
website I converted into DocBook.
The DocBook stylesheets include the images like this:

So the image dimensions are specified. But it seems the unit "px" 
isn't
enough to make the images look nice. Looking at the "Graphics 
Resolution"
section it seems that the dimensions should be specified in inches to
stop using the default 72 dpi.
Thats right pixel measurements are not enough information for FOP to 
scale the image to a fixed size. FOP would need to know a resolution 
as well, but that isnt implemented right now. The only way FOP will 
scale the image to a particular size is if you tell FOP the 
measurement.
If it's true that graphics measurements specified in INCHES yields 
better results than PX, that certainly is news, and would (if 
reproducible) warrant special mention on the FOP Graphics page. Can you 
also do a test to see if the results are similar if you specify mm and 
cm (millimeters & centimeters of course ;-)) as well?

BTW, I don't know if this is related, but GIF images do not scale well, 
as they are a form of a INDEXED BITMAP image. JPG images scale much 
better. This could be part of the problem. If you're working with line 
drawings, perhaps SVG might be a better format to use in your 
documents.

This leads to the question: How can I find out the actual resolution 
of my
images and calculate the dimensions in inches? Do I have to modify the
generated fo afterwards to include the calculated dimensions?
Dont you know the resolution of the images? It is difficult for me to 
answer this question as I dont know where you get the images from. In 
my environment, the system responsible for generating the images 
stores the measurements in cm/mm/inches along with the resolution and 
the image itself.

Chris
Can't you just load the image directly into a web browser:
images/NetworkModel/Basics/BachmanDiagram.GIF
Web Maestro Clay
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Image Size Calculations

[Christian Hattemer]

Chris Bowditch wrote:

> > I was able to work around the object-too-large bug by using a larger page
> > size. In the PDF the images have the wrong resolutions and look
> > ugly. (Read on, it's a slightly different question than usual)
> 
> Hidding objects that are too large is not necessarily a bug. The XSL-FO spec

It does not hide them, it goes into an endless loop trying to fit the object on
the next page. It only stops when the memory is full. This is described in the
FAQ. (This is with fop 0.20.5, since I wasn't able to compile the current
version.)

> Dont you know the resolution of the images? It is difficult for me to answer
> this question as I dont know where you get the images from. In my
> environment, 
> the system responsible for generating the images stores the measurements in
> cm/mm/inches along with the resolution and the image itself.

I didn't make the images myself. I have converted a website into DocBook and
want to create a PDF from that now. It basically works, but the images are ugly.

You can see the page with the image I mentioned in my previous mail here:
http://www.fbi.fh-darmstadt.de/~erbs/Databases/NetworkModel/Basics/index.html

The same applies to all other images on that site. All images are processed by 
fop
as they are online on that page.

Bye, Chris






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

Re: Image Size Calculations

[Chris Bowditch]

Christian Hattemer wrote:
Hi,
I was able to work around the object-too-large bug by using a larger page
size. In the PDF the images have the wrong resolutions and look
ugly. (Read on, it's a slightly different question than usual)
Hidding objects that are too large is not necessarily a bug. The XSL-FO spec 
has several options for dealing with objects that are too large in the 
overflow property. FOP defaults to "hidden" and doesnt implement the other 
overflow options.

The images are a bunch of line drawings and other illustrations from a
website I converted into DocBook.
The DocBook stylesheets include the images like this:

So the image dimensions are specified. But it seems the unit "px" isn't
enough to make the images look nice. Looking at the "Graphics Resolution"
section it seems that the dimensions should be specified in inches to
stop using the default 72 dpi.
Thats right pixel measurements are not enough information for FOP to scale the 
image to a fixed size. FOP would need to know a resolution as well, but that 
isnt implemented right now. The only way FOP will scale the image to a 
particular size is if you tell FOP the measurement.

This leads to the question: How can I find out the actual resolution of my
images and calculate the dimensions in inches? Do I have to modify the
generated fo afterwards to include the calculated dimensions?
Dont you know the resolution of the images? It is difficult for me to answer 
this question as I dont know where you get the images from. In my environment, 
the system responsible for generating the images stores the measurements in 
cm/mm/inches along with the resolution and the image itself.

Chris

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