On Mon, Apr 29, 2019 at 10:52:59AM +0200, Bahr Rudolf wrote:

On Sun, Apr 28, 2019 at 11:12:43PM +0200, Hans Hagen wrote:

...

On 4/28/2019 8:10 PM, Rudolf Bahr wrote:

...

Dear list,

I'm getting unexplainable artefacts in the pdf-output.

My MWE is:

------------------ \starttext

\externalfigure [input.png] [width=100mm]

\stoptext ------------------

I append the output "MWE.pdf" and the input-figure "input.png" for comparison.

I'm experiencing the artefacts with some figures which are all several years old. Until now it never happened in conTeXt programs. Because I installed a new OS (LinuxMint) on my workstation at the same time I tried 3 pdfviewers (okular, evince, xpdf) all with the same result.

different inclusion code

...

I'm using LuaMetaTeX, Version 2.00.0, ConTeXt ver: 2019.04.13 17:25 MKIV beta fmt: 2019.4.15

Please, do you have any idea what could be the reason? no problems here .. can you update?

Hans

Sorry, but even after updating to ConTeXt ver: 2019.04.29 09:02 MKIV beta fmt: 2019.4.29 I'm experiencing the same artefacts as before.

Please, what means "different inclusion code"?

Interesting news! After having changed the png-Format of the external figure to ".tiff"-Format by gimp2.10 the artefacts have gone! Rudolf

On Mon, Apr 29, 2019 at 01:18:04PM +0200, Hans Hagen wrote:

On 4/29/2019 10:52 AM, Rudolf Bahr wrote:

...

Sorry, but even after updating to ConTeXt ver: 2019.04.29 09:02 MKIV beta fmt: 2019.4.29 I'm experiencing the same artefacts as before.

Please, what means "different inclusion code"? all in lua

anyway, as the png test suite passes ok the question is what makes your image different ... here it looks ok when included on windows64 bit and linux 64 bit

...

gm identify input.png input.png PNG 334x168+0+0 DirectClass 8-bit 29.6Ki 0.000u 0m:0.000000s gm identify: iCCP: CRC error (input.png).

maybe a bad image?

Perhaps. Or generated by older software. Though my GraphicsMagick (1.3.28): "gm identify input.png" doesn't tell me anything about a "CRC error": input.png PNG 334x168+0+0 DirectClass 8-bit 29.6Ki 0.000u 0m:0.000003s Anyway, at the beginning of a new book there are 10 of such images with artefacts. I can handle the problem by converting them to .tiff-pictures. As long as I shall have enough storage in my host :-), for me all will be ok. Thank you! Rudolf

On Mon, Apr 29, 2019 at 04:32:07PM -0600, Alan Braslau wrote:

On Mon, 29 Apr 2019 13:18:04 +0200 Hans Hagen wrote:

...

anyway, as the png test suite passes ok the question is what makes your image different ... here it looks ok when included on windows64 bit and linux 64 bit

Your very own .png image and MWE works fine here on OSX, freeBSD, and linux.

Alan

Thank you, Alan! I converted this image and its comrades which showed artefacts to .tiff-images and so they all work at their very best. My conTeXt-version is: This is LuaMetaTeX, Version 2.00.0 ConTeXt ver: 2019.04.29 09:02 MKIV beta fmt: 2019.4.29 But the .log-file contains following strange lines: [...] luatex warning > pdfe: ? luatex warning > pdfe: ? luatex warning > pdfe: ? luatex warning > pdfe: ? luatex warning > pdfe: ? luatex warning > pdfe: ? pages > flushing realpage 2, userpage 2, subpage 2 luatex warning > pdfe: ? luatex warning > pdfe: ? luatex warning > pdfe: ? pages > flushing realpage 3, userpage 3, subpage 3 [...] There are 6 such .tiff-images on page 2 (without any other images) and 3 on page 3. On page 3 there are 5 other .png-images without any problems. I don't know what "pdfe" means. The 9 .tiff-images are few years older than the .png-images on page 3. This means they have been generated in a slightly other way than the newer .png-files on page 3, for instance by an older context-mkiv and GIMP 2.8 on debian 8 (Jessie) or later debian 9 (Stretch), wheras now I'm using context-lmtx on LinuxMint and GIMP2.10. But, as I pointed out, this .tiff-workaround is ok for me, because the artefact effect seems to be limited to those images on page 2 and 3 in my new book. Strange is, that the artefacts (with the same images which haven't been changed in any way) didn't crop up with older context-mkiv. Rudolf

The problem with artefacts in .png images is still unsolved for me. I can circumvent it by using .jpg or .tiff images instead of .png images as long as no transparent areas in the images are needed. As far as I know .jpg and .tiff formats cannot handle transparancy, do they?

Now in .log files messages like "luatex warning > pdfe: invalid 11 0 R object at offset 223611" can be seen. Please, what do they mean? Does that come from an pdf generated by image magick>? If so, the

On 5/16/2019 12:21 PM, Rudolf Bahr wrote: problem is there ... the last years I've seen lots of converted files with bogus pdf objects. (Kind of harmless but still.) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------