Problem with mis-identified .png graphics files when generating DVI

Problem with mis-identified .png graphics files when generating DVI

[Bruce Horrocks]

[-- Attachment #1: Type: text/plain, Size: 338 bytes --]

Hi all,

I posted the attached a while ago but have received no responses. I'm 
still stuck though. :-(

If there was anyone who had half an idea but didn't post a reply because 
they thought that someone else might know better then please feel free 
to come forward now.

Thanks in advance.

   ------- Forwarded message follows -------

[-- Attachment #2: Type: message/rfc822, Size: 4018 bytes --]

From: Bruce Horrocks <bh@granby.demon.co.uk>
To: ntg-context@ntg.nl
Subject: Problem with mis-identified .png graphics files when generating DVI
Date: Sun, 30 Dec 2001 17:08:08 +0000
Message-ID: <95L6D5B4n0L8Ew0a@granby.demon.co.uk>

I have a simple test file that includes a PNG graphic. Generating a PDF
file works fine. However, when I try to produce a DVI file, ConTeXt mis-
identifies the PNG file as EPS. I'd like to know why and what can be
done, if anything?

Here is the test file:

\traceexternalfigurestrue
\starttext
\startfiguretext[right][fig:example]
{none}
{\externalfigure
  [zzz.png]
  [width=2in,height=1in]
}
This is a test.
\stopfiguretext
\stoptext

In the log file, I get the following when generating the PDF file:

systems        : begin file 00_master at line 3
 <./zzz.png>
figures        : dimensions of ./zzz.png loaded from figurefile itself

[locating ./zzz.png as png] [analyzing ./zzz.png on . as png] [found] [./zzz.pn
g: t={png} m={png} l=dummy w=9472573 h=4736286 sx=73.2 sy=75.0 ox=\scratchdimen
  oy=\scratchdimen ] (./00_master.tuo)
floatblocks    : 1 placed

and, as I said, this works fine - ConTeXt has correctly identified the
files as PNG and found the correct dimensions and scale factors.

When producing a DVI file, the equivalent extract from the logfile is:

systems        : begin file 00_master at line 3
figures        : figure ./zzz.png has zero dimensions
figures        : dimensions of ./zzz.png loaded from figurefile itself

[locating ./zzz.png as eps] [analyzing ./zzz.png on . as eps] [zero] [found] [.
/zzz.png: t={eps} m={eps} l=dummy w=9472573 h=4736286 sx=0.09999 sy=0.09999 ox=
\scratchdimen  oy=\scratchdimen ] (./00_master.tuo)
floatblocks    : 1 placed

This doesn't work, presumably because ConTeXt is mis-interpreting the
file as EPS and messing up the scale factors. What I would like to know
is where/why this is happening?

As far as I can tell, the file core-fig.tex contains the relevant code.
However, my knowledge of (Con)TeX is obviously not good enough because I
don't understand how this code is driver specific? If anyone can shed
any light on this then I would be most grateful.

Version info:
This is pdfeTeX, Version 3.14159-14f-released-20000525-2.1 (MiKTeX 2.1) (preloaded format=cont-en 2001.12.30)  30 DEC 2001 16:53
ConTeXt  ver: 2001.12.20  fmt: 2001.12.30  int: english  mes: english

Thanks in advance.
-- 
Bruce Horrocks
Hampshire
England
bh@granby.demon.co.uk

[-- Attachment #3: Type: text/plain, Size: 59 bytes --]

-- 
Bruce Horrocks
Hampshire
England
bh@granby.demon.co.uk

Re: Problem with mis-identified .png graphics files when generating DVI

[Hans Hagen]

At 12:33 PM 1/7/2002 +0000, Bruce Horrocks wrote:
Hi

>I have a simple test file that includes a PNG graphic. Generating a PDF
>file works fine. However, when I try to produce a DVI file, ConTeXt mis-
>identifies the PNG file as EPS. I'd like to know why and what can be
>done, if anything?
>
>Here is the test file:
>
>\traceexternalfigurestrue
>\starttext
>\startfiguretext[right][fig:example]
>{none}
>{\externalfigure
>   [zzz.png]
>   [width=2in,height=1in]
>}
>This is a test.
>\stopfiguretext
>\stoptext
>
>In the log file, I get the following when generating the PDF file:
>
>systems        : begin file 00_master at line 3
>  <./zzz.png>
>figures        : dimensions of ./zzz.png loaded from figurefile itself
>
>[locating ./zzz.png as png] [analyzing ./zzz.png on . as png] [found] 
>[./zzz.pn
>g: t={png} m={png} l=dummy w=9472573 h=4736286 sx=73.2 sy=75.0 
>ox=\scratchdimen
>   oy=\scratchdimen ] (./00_master.tuo)
>floatblocks    : 1 placed
>
>and, as I said, this works fine - ConTeXt has correctly identified the
>files as PNG and found the correct dimensions and scale factors.
>
>When producing a DVI file, the equivalent extract from the logfile is:
>
>systems        : begin file 00_master at line 3
>figures        : figure ./zzz.png has zero dimensions
>figures        : dimensions of ./zzz.png loaded from figurefile itself
>
>[locating ./zzz.png as eps] [analyzing ./zzz.png on . as eps] [zero] 
>[found] [.

I'm not sure if you do have an eps.

Context figure inclusion works as follows:

\externalfigure[abc][...]

in this case, context will try to locate a file and determine its 
dimensions based on a built in list of suffixes, strating with the best 
quality available, so vector before bitmap, lossless before lossy.

In your case, you specify a suffix explitly, so context will analyze the 
graphic according to its known suffixes (also depends on the driver) but 
uses the file itself as subject. So, in dvi mode it will (since dvips 
supports eps) analyze the png as if it was an eps. This gives zero 
dimensions, so ...

Now, if you have an eps as well as a png version, you can say

\externalfigure[zzz][width=2in,height=1in]

and in the case of pdftex, the png will be used, and in case of dvi, the 
eps. Depending on the settings, when no dimensions can be determined, 
texutil will be used. If you say texutil --fig, you will notice that a 
*.tuf file is generated. This file will be consulted when present. (texutil 
can analyze the supported formats.) This also means that you can process 
files without the graphics being present (given that there is a tuf file).

So, the advice is: don't specify a suffix in case of multiple output.

[when you use pdftex, an alternative is to define a figure base]

Hans
-------------------------------------------------------------------------
                                   Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                       Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
  tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------
                                   fall-back web server: 
www.pragma-pod.nl
-------------------------------------------------------------------------

Re: Problem with mis-identified .png graphics files when generating DVI

[Bruce Horrocks]

In message <5.1.0.14.1.20020107152506.05150f60@server-1>,
on Mon, 7 Jan 2002 at 15:34:04, Hans Hagen wrote:

>>When producing a DVI file, the equivalent extract from the logfile is:
>>
>>systems        : begin file 00_master at line 3
>>figures        : figure ./zzz.png has zero dimensions
>>figures        : dimensions of ./zzz.png loaded from figurefile itself
>>
>>[locating ./zzz.png as eps] [analyzing ./zzz.png on . as eps] [zero] 
>>[found] [.
>
>I'm not sure if you do have an eps.

That's exactly the point: I don't have an eps file and I want to know 
why the system thinks that I do.

>Context figure inclusion works as follows:

[snip]

>In your case, you specify a suffix explitly, so context will analyze 
>the graphic according to its known suffixes (also depends on the 
>driver) but uses the file itself as subject. So, in dvi mode it will 
>(since dvips supports eps) analyze the png as if it was an eps. This 
>gives zero dimensions, so ...

I don't really understand this. If I deliberately specify a .png 
extension, I why doesn't the system simply say: "Error - you have 
specified a file extension that I don't know how to deal with"?

[suggestion to use .eps versions as well snipped]

I appreciate the suggestion but I will have lots of illustrations. 
Keeping two sets in synch introduces a configuration management issue. 
It *might* be easier to amend the DVI driver to support .png files 
(since my viewer already does).

Okay, so next question. Where do I start looking to make the appropriate 
change? As I pointed out in my first post, PDF output identifies the 
.png extension properly but DVI doesn't. However, looking through the 
ConTeXt source, I can only find *one* reference to determining the type 
and size of graphics files. This is in core-fig.tex. I must have missed 
something because I don't see how this differs depending upon driver. 
Any suggestions would be greatly appreciated.

Regards,
-- 
Bruce Horrocks
Hampshire
England
bh@granby.demon.co.uk

Re: Problem with mis-identified .png graphics files when generating DVI

[Hans Hagen]

At 04:30 PM 1/7/2002 +0000, Bruce Horrocks wrote:
>In message <5.1.0.14.1.20020107152506.05150f60@server-1>,
>on Mon, 7 Jan 2002 at 15:34:04, Hans Hagen wrote:
>
>>>When producing a DVI file, the equivalent extract from the logfile is:
>>>
>>>systems        : begin file 00_master at line 3
>>>figures        : figure ./zzz.png has zero dimensions
>>>figures        : dimensions of ./zzz.png loaded from figurefile itself
>>>
>>>[locating ./zzz.png as eps] [analyzing ./zzz.png on . as eps] [zero] 
>>>[found] [.
>>
>>I'm not sure if you do have an eps.
>
>That's exactly the point: I don't have an eps file and I want to know why 
>the system thinks that I do.

because your driver settings (dvips) tell context that eps is supported, 
context tries to interpret your file as such (because you specified the 
suffix png, it honnors the suffix, otherwise it would have appended .eps to 
the filename. This may look strange but imagine that one can have files 
called abc.def which are eps files given that they conform to the specs. 
The suffix is only an indication of the type. So, the solution is *not* to 
specify the suffix.

so what the trace says is:

i found a zzz.png and will look at it as if it was eps [enter eps parsing 
mode]
i'm analyzing this file using the eps parser
there are zero dimensions encountered

normally it would go on then looking for files with non zero dimensions but 
here you run into the escape. I probably can best remove that escape 
triggered by the suffix. i will look into that bit later

>I don't really understand this. If I deliberately specify a .png 
>extension, I why doesn't the system simply say: "Error - you have 
>specified a file extension that I don't know how to deal with"?

this is no problem if png is supported by your dvi converter indeed, if it 
is, let me know and i'll add the code needed to the driver

if png is not supported, you needs to convert it to eps (uysing imagemagick 
for instance)

>I appreciate the suggestion but I will have lots of illustrations. Keeping 
>two sets in synch introduces a configuration management issue. It *might* 
>be easier to amend the DVI driver to support .png files (since my viewer 
>already does).

this is no problem, as said, but as far as i know dvips does not support 
png inclusion

>Okay, so next question. Where do I start looking to make the appropriate 
>change? As I pointed out in my first post, PDF output identifies the .png 
>extension properly but DVI doesn't. However, looking through the ConTeXt 
>source, I can only find *one* reference to determining the type and size 
>of graphics files. This is in core-fig.tex. I must have missed something 
>because I don't see how this differs depending upon driver. Any 
>suggestions would be greatly appreciated.

ah, the real thing is done in the spec-*.tex files, the core-fig module 
asks the special drivers if a format is supported and/or if it can handle 
objects and finally inserts the driver code needed to actually include the 
graphic. spec-tr.tex is the file that defined support for dvips.

Hans
-------------------------------------------------------------------------
                                   Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                       Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
  tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------
                                   fall-back web server: 
www.pragma-pod.nl
-------------------------------------------------------------------------

Re: Problem with mis-identified .png graphics files when generating DVI

[Taco Hoekwater]

On Mon, 7 Jan 2002 16:30:11 +0000
"Bruce Horrocks" <bh@granby.demon.co.uk> wrote:

> Okay, so next question. Where do I start looking to make the appropriate 
> change? As I pointed out in my first post, PDF output identifies the 
> .png extension properly but DVI doesn't. However, looking through the 
> ConTeXt source, I can only find *one* reference to determining the type 
> and size of graphics files. This is in core-fig.tex. I must have missed 
> something because I don't see how this differs depending upon driver. 
> Any suggestions would be greatly appreciated.

Have a look at the spec-XXX.tex files, these define the driver macros.
Look for things like \definefileinsertion.

Adding PNG may not work straight away. Two main problems to solve:

- The size of the image has to be available to the macros. I am not sure
  whether pdftex accepts png images in DVI mode. Anyway, finding out the
  size is doable (using an external program if need be).

- The other problem is the precise syntax that the DVI driver needs.
  Just saying 'it supports' doesn't help. TeX \specials are basically
  strings, and you need to know what precisely the viewer expects to find
  in this string.

If both of these have been done, the macro for inclusion itself is fairly 
trivial.

-- 
groeten,

Taco

Re: Problem with mis-identified .png graphics files when generatingDVI

[George N. White III]

TeX and related tools have become a massive system that is becoming a
signficant problem to maintain. It is easy to say "let's just add support
for the new XYZ graphics format" to dvips or pdftex or xdvi or ... These
suggestions are rarely accompanied by the necessary patches. In practice,
adding support for new graphics formats involves linking to 3rd party
libraries, changes to macro packages like LaTeX and ConTeXt, etc. There
are other urgent needs (e.g., UTF-8/Unicode support).

Support non-native graphics formats in pdftex and dvips should be viewed
with caution. It is important to note than the support in pdftex for PNG
and other image formats is incomplete, and that the most reliable
method to insert images into PDF files is to make the images into PDF
independently of pdftex. With dvips, the most reliable approach is to
convert images to EPS. Adding support for images to pdftex has resulted in
a more complex program that is less portable and less immune to side
effects (e.g., changing a .dll or .so version) from other differences
between similar systems.

In my work (which involves processing remote sensing data commonly
visualized using "false color" images), it is important that similar
images always have consistent color scales. I view the image support in
pdftex as a convenience (e.g., if it works well enough for a particular
project, I will use it, but I would never rely on it for critical work).
There are many attributes of PDF images that you can't easily control
using the support provided in pdftex, so images "placed" using PNG rarely
match the colors of images converted to PDF using other tools.

The problem reported by Bruce Horrocks would not arise when using EPS with
dvips and PDF with pdftex.

-- 
George N. White III <gnw3@acm.org> Bedford Institute of Oceanography

Re: Problem with mis-identified .png graphics files when generating DVI

[Hans Hagen]

At 08:59 AM 1/8/2002 -0400, George N. White III wrote:

>Support non-native graphics formats in pdftex and dvips should be viewed
>with caution. It is important to note than the support in pdftex for PNG
>and other image formats is incomplete, and that the most reliable
>method to insert images into PDF files is to make the images into PDF
>independently of pdftex. With dvips, the most reliable approach is to
>convert images to EPS. Adding support for images to pdftex has resulted in
>a more complex program that is less portable and less immune to side
>effects (e.g., changing a .dll or .so version) from other differences
>between similar systems.

ah, i never knew that png support was incomplete; i knew that tiff was 
crappy so i don't support that

The problem reported by Bruce Horrocks would not arise when using EPS with
>dvips and PDF with pdftex.

indeed, here we follow the same approach (today we put most graphics into 
figure base files which are easy to handle for pdftex)

hans
-------------------------------------------------------------------------
                                   Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                       Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
  tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------
                                   fall-back web server: 
www.pragma-pod.nl
-------------------------------------------------------------------------

Problem with mis-identified .png graphics files when generating DVI

[Bruce Horrocks]

I have a simple test file that includes a PNG graphic. Generating a PDF
file works fine. However, when I try to produce a DVI file, ConTeXt mis-
identifies the PNG file as EPS. I'd like to know why and what can be
done, if anything?

Here is the test file:

\traceexternalfigurestrue
\starttext
\startfiguretext[right][fig:example]
{none}
{\externalfigure
  [zzz.png]
  [width=2in,height=1in]
}
This is a test.
\stopfiguretext
\stoptext

In the log file, I get the following when generating the PDF file:

systems        : begin file 00_master at line 3
 <./zzz.png>
figures        : dimensions of ./zzz.png loaded from figurefile itself

[locating ./zzz.png as png] [analyzing ./zzz.png on . as png] [found] [./zzz.pn
g: t={png} m={png} l=dummy w=9472573 h=4736286 sx=73.2 sy=75.0 ox=\scratchdimen
  oy=\scratchdimen ] (./00_master.tuo)
floatblocks    : 1 placed

and, as I said, this works fine - ConTeXt has correctly identified the
files as PNG and found the correct dimensions and scale factors.

When producing a DVI file, the equivalent extract from the logfile is:

systems        : begin file 00_master at line 3
figures        : figure ./zzz.png has zero dimensions
figures        : dimensions of ./zzz.png loaded from figurefile itself

[locating ./zzz.png as eps] [analyzing ./zzz.png on . as eps] [zero] [found] [.
/zzz.png: t={eps} m={eps} l=dummy w=9472573 h=4736286 sx=0.09999 sy=0.09999 ox=
\scratchdimen  oy=\scratchdimen ] (./00_master.tuo)
floatblocks    : 1 placed

This doesn't work, presumably because ConTeXt is mis-interpreting the
file as EPS and messing up the scale factors. What I would like to know
is where/why this is happening?

As far as I can tell, the file core-fig.tex contains the relevant code.
However, my knowledge of (Con)TeX is obviously not good enough because I
don't understand how this code is driver specific? If anyone can shed
any light on this then I would be most grateful.

Version info:
This is pdfeTeX, Version 3.14159-14f-released-20000525-2.1 (MiKTeX 2.1) (preloaded format=cont-en 2001.12.30)  30 DEC 2001 16:53
ConTeXt  ver: 2001.12.20  fmt: 2001.12.30  int: english  mes: english

Thanks in advance.
-- 
Bruce Horrocks
Hampshire
England
bh@granby.demon.co.uk