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
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
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
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
On Jun 7, 2004, at 2:13 AM, Chris Bowditch wrote:
Christian Hattemer wrote:
SNIP'd what='overflow stuff'
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:
fo:external-graphic
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)
The images are a bunch of line drawings and other illustrations from a
website I converted
