Package: python-odtwriter
Version: 1.3a-1
Severity: normal
Tags: patch
--- Please enter the report below this line. ---
Odt writer is making mistakes about images in documents. The big one is that
it's not calculating the correct size of the image.
Steps to reproduce the bug:
###########################
1. Create a rst document with a image directive. The image itself is going
to be 300dpi and 1500 by 1125 pixels in jpeg format. This creates a
high-detailed image suitable for printing. Printers are much higher
resolution devices then computer displays and thus require much higher
resolution images in order to keep the image from being crappy looking.
Higher resolution meaning higher density of pixels.
2. use rst2odt to create a odt version of the file.
What should happen:
###################
The odt document created should create a document were the image is 5 by 3.75
inches.
What does happen:
#################
If you do not specify a scale or height and width option to the image directive
then it creates very tiny images. Something like .22 inches square or something
like that. Not sure how this happens.
If you give a height and width data for the image directive then you end up
with a massive image that spans the entire width of the page.
One temporary fix:
##################
Only use images with very low resolutions.. like 96dpi. This is perfectly
suitable to digital formats and displays, but is poor for anything that needs
to be printed.
My dirty hack:
##############
It seems that rst2latex gets this right and gets the image sizing correct.
Maybe you want to look to them and see how it's done.
But this is my 'fix'::
/usr/share/pyshared/docutils/writers/odtwriter$ diff __init__.py init.old
1788,1796c1788,1790
< if ('width' not in node.attributes or 'height' not in
< node.attributes):
<
< # Ok, I've modified this to give me width and height based on
the
< # DPI. not sure what the magic number 0.035278 is suppose to
be
< # for, so I got rid of it. DPI is based on inches so that
needs to
< # be converted to centimeters to conform to the rest of the
coding
< # style
<
---
> if ('scale' in node.attributes and
> ('width' not in node.attributes or
> 'height' not in node.attributes)):
1802,1808c1796,1799
< widthDpi, heightDpi = imageobj.info['dpi']
< # convert to float to preserve precision
< widthCM = (width / float(widthDpi)) * 2.54
< heightCM = (height / float(heightDpi)) * 2.54
< if 'scale' in node.attributes:
< widthCM *= scale
< heightCM *= scale
---
> width = width * (35.278 / 1000.0)
> width *= scale
> height = height * (35.278 / 1000.0)
> height *= scale
1811c1802
< return scale, widthCM, heightCM
---
> return scale, width, height
Hope that makes sense. I am pulling the DPI from the image using the PIL
library then calculating the size and converting it to centimeters.
So far this works for me, but I wouldn't be suprised if it causes problems for
others.
Other related issues and suggestions:
#####################################
There is some niggling issues with how the images are set in the page.
Sometimes if 2 large images are next to each other they end up fighting over
the available page space and one ends up get shoved over the edge of the
margins into 'unprintable' page space. What should happen is if 2 images are
too large to fit together then you just end up with a page with a single image
on it, then another page with the second image, followed by the text that is
suppose to follow it.
What may be a better fix to do is fix the restructured text stuff to allow
users to specify DPI or 'density' of their images. The width and height stuff
being measured in pixels is misleading since the actual physical size isn't
ever going to be measured by pixels.
This is one of those things that can be difficult to get right.
The 'standard' for internet images and computer images is going to default to
'96 dpi' since that is what the vast majority of the world's displays default
to since they are using Microsoft Windows. This is fine. However modern OSes
have the ability to scale their UI elements to match the display resolution. So
if you have a circle that is one inch wide on a 7 inch display with 800x480
resolution (that's a small, high resolution display) it will still be a one
inch circle on a 17 inch monitor with 1024x768 resolution (that's a large, low
resolution display).
So I don't know if it would be better to add a density option and default to
96dpi if user specifies width and height in pixels without a scale or density
option, or what to do. But something should be done since this sort of thing is
important if you want to deal with multiple formats and keep everything
more-or-less readable and more-or-less consistent across multiple formats and
display technologies (ie: printed book vs website)
--- System information. ---
Architecture: i386
Kernel: Linux 2.6.25-2-686
Debian Release: lenny/sid
991 unstable 10.1.5.7
500 unstable 10.1.5.7
500 testing 10.1.5.7
400 testing 10.1.5.7
300 experimental 10.1.5.7
--- Package information. ---
Depends (Version) | Installed
=================================-+-===========
python | 2.5.2-1
python-central (>= 0.6.7) | 0.6.8
python-docutils | 0.5-2
python-lxml |
OR python (>= 2.5) | 2.5.2-1
OR python-elementtree | 1.2.6-12
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
