Hi,
Per GraphicsMagick's documentation, GraphicsMagick will—by default—'render' a PDFs at 72dpi.
This is far too low for my use case, especially in the age of high DPI digital displays.
GraphicsMagick provides a -density flag to allow changing this (e.g. -density 300 for 300dpi). However, I am unfortunately finding it difficult to pass this into the relevant GraphicsMagick calls executed by sorl-thumbnail's convert_engine. It seems to be structured such that achieving this with a subclass still requires duplicating large amounts of sorl-thumbnail code.
The big things that I've found stand in my way so far, are:
Argument order
GraphicsMagick requires that -density be passed in before the source file is referenced. Passing in -density after the source file causes -density to silently not apply (...at least in the same way, or the way that we want it to). For example, gm convert -density 300 in.pdf ... out.jpg works, whereas gm convert in.pdf -density 300 ... out.jpg does not.
This makes the most apparent customisation point in get_image() unsuitable, as it applies options after the source file:
https://github.com/jazzband/sorl-thumbnail/blob/master/sorl/thumbnail/engines/convert_engine.py#L37-L41
Impact on image size
Engine.get_image_size also needs to know about the desired density, and—unlike Engine.get_image()—there is essentially zero opportunity for shoving extra options into the gm identify call here.
https://github.com/jazzband/sorl-thumbnail/blob/master/sorl/thumbnail/engines/convert_engine.py#L37-L41
FWIW, I'm almost certain that I can just make do with forcing this into THUMBNAIL_CONVERT / THUMBNAIL_IDENTIFY, e.g. THUMBNAIL_CONVERT = "gm convert -density 300", but this isn't ideal, and doesn't allow other use cases, like setting the density on a per-call basis.
Hi,
Per GraphicsMagick's documentation, GraphicsMagick will—by default—'render' a PDFs at 72dpi.
This is far too low for my use case, especially in the age of high DPI digital displays.
GraphicsMagick provides a
-densityflag to allow changing this (e.g.-density 300for 300dpi). However, I am unfortunately finding it difficult to pass this into the relevant GraphicsMagick calls executed by sorl-thumbnail'sconvert_engine. It seems to be structured such that achieving this with a subclass still requires duplicating large amounts of sorl-thumbnail code.The big things that I've found stand in my way so far, are:
Argument order
GraphicsMagick requires that
-densitybe passed in before the source file is referenced. Passing in-densityafter the source file causes-densityto silently not apply (...at least in the same way, or the way that we want it to). For example,gm convert -density 300 in.pdf ... out.jpgworks, whereasgm convert in.pdf -density 300 ... out.jpgdoes not.This makes the most apparent customisation point in
get_image()unsuitable, as it applies options after the source file:https://github.com/jazzband/sorl-thumbnail/blob/master/sorl/thumbnail/engines/convert_engine.py#L37-L41
Impact on image size
Engine.get_image_sizealso needs to know about the desired density, and—unlikeEngine.get_image()—there is essentially zero opportunity for shoving extra options into thegm identifycall here.https://github.com/jazzband/sorl-thumbnail/blob/master/sorl/thumbnail/engines/convert_engine.py#L37-L41
FWIW, I'm almost certain that I can just make do with forcing this into
THUMBNAIL_CONVERT/THUMBNAIL_IDENTIFY, e.g.THUMBNAIL_CONVERT = "gm convert -density 300", but this isn't ideal, and doesn't allow other use cases, like setting the density on a per-call basis.