> I'm looking at the support for alternate sizes of images, and wondering
> if something should change.
As you know from a previous message, there's a definate mathematical
scaling factor issue with the current image parsers in the Python code. I
haven't been able to locate where this happens (or if it's just ImageMagic,
in which case, we may be able to work around the flaw with Python). A quick
example is the following pseudocode:
plucker-build [...] --alt-maxwidth=320
(a double-normal image, the original was a 160x160 gif)
The parser reports:
ppmquant: 16 colors found in colormap
ppmquant: mapping image to new colors...
pnmtopalm: input is grayscale 160x160, maxval 255 -- using 4 bits-per-pixel
plucker-build [...] --alt-maxheight=320
(the same image, original 160x160 gif)
ppmquant: 16 colors found in colormap
ppmquant: mapping image to new colors...
pnmtopalm: input is grayscale 150x150, maxval 255 -- using 4 bits-per-pixel
Somehow I just lost 10 pixels on the height and the width. Why?
In both cases, you'll notice that I did not get an image that was
double the size (when viewed on the Palm, though I can't find a way to find
out exactly what the size of the converted image actually was. The parser
only reports the input size, but not the output size, currently).
If I take that 160x160.gif image and make it 160x320 (height being
the larger value), and run the following:
plucker-build [...] --alt-maxwidth=1000
I get:
ppmquant: 16 colors found in colormap
ppmquant: mapping image to new colors...
pnmtopalm: input is grayscale 125x250, maxval 255 -- using 4 bits-per-pixel
If I change it so that I ask for an image with exactly double the
height (640), it then tells me the input file is much different than actual:
ppmquant: 16 colors found in colormap
ppmquant: mapping image to new colors...
pnmtopalm: input is grayscale 150x300, maxval 255 -- using 4 bits-per-pixel
The reason I want exactly double the image size, is because fonts
that are not aliased in the original 160x160 image (a graph) look sharp and
crisp at 320x320. Anything less or more than an multiple of those (2x 3x,
etc.) results in blurry, completely unreadable fonts.
I have yet to find a way to get exactly double the image size in any
image that I pull into the parser. The fact that I get a different size of
"input" images (using the same unmodified source image) depending on whether
I use --alt-maxwidth vs. the same multiplier with --alt-maxheight, baffles
me. This should not change the output.
> To refresh everyone's memory: There are two kinds of image pages
> included in a Plucked document, inline and separate.
There's a slight issue here as well, in that if you use --alt-maxfoo
on any plucked document, *EVERY SINGLE IMAGE* then applies to those values.
What this means is that even a document where an image leads to a separate
page (<a href="foo.html"><img src="foo.gif"></a>), will then take even the
smallest "bullet" image and make it a nice huge image when tapped. Even
simple images on a page that are linked to nothing are applied this state.
Not quite sure that's the desired action.
I do, however, recommend an option we should support inside the href
element:
<a href="foo.html" MAXWIDTH="160" MAXHEIGHT="160" ALTMAXWIDTH="320">
> I'm proposing to change this so that if 'alt_max*' is specified, and a
> separate image page is produced as the result of a link, it will be
> scaled to the 'alt_max*' sizes instead of the regular 'max*' sizes, and
> no additional separate page will be created. If 'alt_max*' is not
> specified, the regular 'max*' restrictions will be honored.
This sounds like a good idea, but can we fix the scaling first =) It
may complicate things to inherit that scaling "fracture" in the new design
for the parser.
/d
