Bug 691971

i.e. pdfdraw -s (size) 144x144 -r 72 would result in a 144x144 pixel bitmap but would 216x216 if the -r (resolution) was 108 -- the reason for points is that the page has a real size so the size of a reduction should have a real unit size not a sampling rate dependent unit like pixels but real points -- the page is scaled to fit the given area if that means there are black bars on the top or sides (due to mismatch in aspect) the bitmap is made smaller as not to include them in the image i.e. they are trimmed

the new option -s (size) would take wxh in points while a related one -e (exact) wxh would take it in pixels

the default value for wxh for -s would be the size of the page to be drawn if this options is not specified while -e default would be -s's times -r

the reason for this is that without this it's unneededly harder to have mupdf's pdfdraw replace evince-thumbnailer as it takes a -s option like the one i give (but as it only gives one dimension) which specifies the maximum size of the result thumbnail as the only current way to do this with mupdf's pdfdraw is to use mupdf's pdfinfo to get the page dimensions compute the scaling factor by a rather simple formula for example:

612/x=128 => 1/612/x=1/128 => x/612=1/128 => x=1/128*612 => x=612/128

[ 0 0 612 792 ] / 128 would be [ 0 0 4.78125 6.1875 ] and then take the maximum 6.1875 and do 72/6.1875 yielding 11.636363636363637 so to get that page to fit in a 128x128 pixel box one would need to render it at 11.6363 dpi resolution

but doing this would mean two program launches rather than just one and two parsings of the pdf file so that's the reason this behavior should be inside of pdfdraw