On Thu, Feb 14 2019, Wolfgang Schuster wrote:

Take a look at section 3.2 of the workflows [1] document.

[1] http://www.pragma-ade.nl/general/manuals/workflows-mkiv.pdf

Sorry, I don't understand. How will the "convert" command "convert -geometry %nx%x%ny% -compress JPEG ..." ever know, that the target height is 10cm? -- Peter

Thank you all for your help. First i tried the grph-downsample.lua script. Unfortunately i get an error message grph-downsample.lua:31: bad argument #2 to 'format' (number has no integer representation) See attached log file. Greetings Lutz Am 14. Februar 2019 21:44:31 MEZ schrieb Hans Hagen :

On 2/14/2019 9:32 PM, Peter Münster wrote:

...

On Thu, Feb 14 2019, Lutz Haseloff wrote:

...

I wanted to use the degrade module with recent ConTeXt and LuaTeX.

Hi Lutz,

Could you please check, if the module grph-downsample.lua could fit your needs?

...

The minimal example from the degrade manual gives an error. See the attached log. Is there any chance to get the module working again?

There is always a chance. The question is just: who will afford the efforts... Please check first the downsample module, and then let's see, if you still need this very old and hackish degrade module. you can plug in code

\startluacode

figures.converters["png"]["lowres.png"] = function(oldname,newname,resolution) os.execute(string.format('gm convert "%s" "%s"',oldname,newname)) end

figures.converters["jpg"]["lowres.jpg"] = function(oldname,newname,resolution) os.execute(string.format('gm convert "%s" "%s"',oldname,newname)) end

-- figures.suffixes["lowres.png"] = figures.suffixes.png -- suffix is automatically done

\stopluacode \enabletrackers[graphics*]

\starttext \externalfigure[t:/sources/mill.png][conversion=lowres.png] \externalfigure[t:/sources/hacker.jpg][conversion=lowres.jpg] \stoptext

----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl ----------------------------------------------------------------- ___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___________________________________________________________________________________

On Fri, 15 Feb 2019 07:56:31 +0100 Lutz Haseloff wrote:

First i tried the grph-downsample.lua script. Unfortunately i get an error message grph-downsample.lua:31: bad argument #2 to 'format' (number has no integer representation) See attached log file.

I remember that error. The script worked up to a particular context version. I believe a Lua upgrade broke it. The version attached should work. Marco

On Fri, 15 Feb 2019 10:22:48 +0100 Lutz Haseloff wrote:

but both scripts trow the same error on windows and linux-armhf:

grph-downsample.lua:32: bad argument #2 to 'format' (number has no integer representation)

It works here on linux-armhf. No Lua error. Maybe the file got mangled during transmission. I've uploaded a modified version to github, maybe try that one: https://github.com/mpfusion/context-downsample It includes a wrapper so you can call it like any other module (\usemodule[downsample]). It's still Peter's code, but with small modifications, so it degrades jpg as well as png images at the same time. It's a quick hack, but works here, also on armhf. Marco

On Fri, 15 Feb 2019 11:48:51 +0100 Lutz Haseloff wrote:

Your Module with wrapper finally works for me as expected.

Great to hear it's finally working.

Will it find its way into the distribution as an enhanced degrade module?

Probably not, for the following reasons: - It's 99% Peter's code, he's the maintainer of the module and probably he should just fix his code. - My modification contains an ugly hack that just renames all files to pdf, regardless of the actual file type because I have no clue how to do that properly. That code shouldn't make it into the distribution. - I'm not fluent in Lua and am therefore not the right person to maintain a Lua module. Marco

On Sun, 17 Feb 2019 12:14:14 +0100 Peter Münster wrote:

On Fri, Feb 15 2019, Marco Patzer wrote:

...

- It's 99% Peter's code, he's the maintainer of the module and probably he should just fix his code.

Done.

...

- My modification contains an ugly hack that just renames all files to pdf, regardless of the actual file type because I have no clue how to do that properly.

I've included your hack, because I don't have any better idea...

ok

...

That code shouldn't make it into the distribution.

Why not? Just because of the hack?

Yes. I didn't put much thought into it and assumed there is a better solution. Marco

On Mon, 18 Feb 2019 10:13:20 +0100 Marco Patzer wrote:

Yes. I didn't put much thought into it and assumed there is a better solution.

My working solution is to put figures in subdirectories by resolution, that is externally, once and for all, using whatever is your favorite tool to "degrade" pixel resolution to whatever value one desires, then setting global macro (\FigRes) to this subdirectory name. So, for example, \def\FigRes{300/} ... \externalfigure [\FigRes MyFigureName] I do this as I have *very* high resolution images as my source (also high resolution "depth", i.e. 16 bit) and it makes no sense to include these as is in my documents. It's very robust. Alan

On Mon, 18 Feb 2019 22:09:32 +0100 Peter Münster wrote:

On Mon, Feb 18 2019, Alan Braslau wrote:

...

My working solution is to put figures in subdirectories by resolution,

The purpose of the downsample module is something else: a well defined resolution of the image in the PDF-file. A bitmap image does not have a resolution, only a width and a height in pixels. The resolution gets defined, when you specify the real dimensions.

Incorrect, an image file contains width and height (in pixels) as well as a resolution, and the combination gives real dimensions (for a natural size). A proper scan of a real object specifies all of this. Alan

On Mon, 18 Feb 2019 23:50:24 +0100 Peter Münster wrote:

On Mon, Feb 18 2019, Alan Braslau wrote:

...

Incorrect, an image file contains width and height (in pixels) as well as a resolution,

Optionally a resolution in the metadata. Then, of course, you have a "natural size". But that doesn't matter, if you want other dimensions.

For example, in Context \externalfigure [myfigure] should give this natural size. Of course, you can always specify other dimensions, in which case it gets scaled. Since what counts for our use in Context is usually fixing a particular size, i.e. [width=\textwidth], the "resolution", i.e. density in pixels is something that we want to control. So if we want to print to 300 dpi, for example, and we have a text width of 17cm, say, then we would like to have an image that is some 2000 pixels in width. One can normalize one's collection of images however one wishes, but manipulating them on the fly as one changes layout or image placement hardly seems efficient, even if one were to be clever in storing copies and looking at time stamps. A little bit of forethought might be better, and more predictable. Alan