[Octave-bug-tracker] [bug #44186] print command gives incorrect postscript file

[Dan Sebald]

Follow-up Comment #30, bug #44186 (project octave):

Good little bit of investigation with the extra 16 bytes...

I've attempted a download of the source code for ghostscript at the website
downloads.ghostscript.com.  Just to not overlook something, my experience is
that the tar expansion reported an error on the file ghostscript-9.15.tar.gz:


[@ ghostscript]$ tar -xzf ghostscript-9.15.tar.gz 

gzip: stdin: unexpected end of file
tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now


while it appears that most of the files expanded in the directory.  Using
bunzip2 on the file ghostscript-9.15.tar.bz2 produced no errors about the
archive.

OK, so I'm looking at the code in the bunzip directory version, and I will
toss out some observations that might lead to ideas.

I see five occurrences of "EndResource" in what looks like it could be file
generation code (I've snipped results from the many postscript examples in the
tree):


address@hidden ghostscript-9.15]$ grep EndResource */*/*
devices/vector/gdevpdfu.c:            stream_puts(pdev->strm,
"%%EndResourcen");
devices/vector/gdevpsfm.c:        stream_puts(s, "%%EndResourcen");
devices/vector/gdevpsu.c:    "%%EndResource",           /* ProcSet */
lcms2/src/cmsps2.c:        _cmsIOPrintf(mem, "%%%%EndResourcen");
lcms/src/cmsps2.c:    Writef(mem, "%%%%EndResourcen");
Binary file Resource/CIDFont/ArtifexBullet matches


1) In gdevpsu.c the following is intended to be printed at that point where
the 16 "garbage" bytes are appearing:


static const char *const psw_end_prolog[] = {
    "end def",
    "%%EndResource",            /* ProcSet */
    "/pagesave null def",       /* establish binding */
    "%%EndProlog",
    0
};


In the sample postscript file, I've replaced the garbage bytes with "/pagesave
null def" and the PostScript file is readable by "gv".  Could it be that under
MXE compilation (remember, I'm clueless about MXE), that the "/p" portion of
that string is treated as some kind of escape character causing the printf
statement to put out some bogus characters?  (The string is 18 characters
long, minus "/p" makes it 16 characters.)  Could MXE require two slashes,
"//pagesave null def"?

2) In gdevpsfm.c is the following:


    if (!pcmap->ToUnicode) {
        stream_puts(s, "%%EndResourcen");
        stream_puts(s, "%%EOFn");
    }


which doesn't look pertinent.  There's no EOF right after EndResource in the
sample file.

3) In gdevpdfu.c is


int
pdf_end_obj(gx_device_pdf * pdev, pdf_resource_type_t type)
{
    stream_puts(pdev->strm, "endobjn");
    if (pdev->ForOPDFRead && pdev->ProduceDSC) {
        switch(type) {
            case resourcePage:
                break;
            default:
            stream_puts(pdev->strm, "%%EndResourcen");
            break;
        }
    }
    return 0;
}


There is an "endobjn" just previous to the %%EndResource in the sample file. 
Just previous to the "endobj" is ">>", that appears in a function called
pdf_store_page_resources:


        if (s) {
            stream_puts(s, ">>n");
            pdf_end_separate(pdev, i);
        }
        /* If an object isn't used, we still need to emit it :-( This is
because
         * we reserved an object number for it, and the xref will have an
entry
         * for it. If we don't actually emit it then the xref will be
invalid.
         * An alternative would be to modify the xref to mark the object as
unused.
         */
        if (i != resourceFont && i != resourceProperties)
            pdf_write_resource_objects(pdev, i);


This (gdvpdfu.c) is starting to look like the path the ghostscript program is
taking when creating the sample EPS file.  So where does
"pdf_write_resource_objects()" go, because that is where the garbage bytes
would be?  Basically, it calls:


                    code = cos_write_object(pres->object, pdev, rtype);


and cos_write_object (in gdevpdfo.c) utilizes 


    code = cos_write(pco, pdev, pco->id);


which is


/* Write a cos object on the output. */
cos_proc_write(cos_write);      /* check prototype */
int
cos_write(const cos_object_t *pco, gx_device_pdf *pdev, gs_id object_id)
{
    return pco->cos_procs->write(pco, pdev, object_id);
}


Whew, getting deep.  And pco is a structure.  And cos_procs is a structure of
functions(??), for which write() is called.


#define cos_object_struct(otype_s, etype)
struct otype_s {
    const cos_object_procs_t *cos_procs;        /* must be first */


I can't follow beyond that point.  I could compile the program and print out
some of what is being produced here, but if the problem only happens under
MXE, then there's no point.  I would say though that this structure function
call and object pointer stuff is pretty complex, so it wouldn't surprise me a
compiler has problems, if that in fact ends up being the issue.

4) In cmsps2.c is the following code hunk:


    if (!(dwFlags & cmsFLAGS_NODEFAULTRESOURCEDEF)) {

    Writef(mem, "%%%%EndResourcen");
    Writef(mem, "n%% CRD Endn");
    }


That doesn't look pertinent.  There's no "CR End" in the sample EPS file.

5) In dscparse.c there looks to be a check against EndResource:


    else if (IS_DSC(line, "%%EndResource")) {
        dsc->id = CDSC_ENDRESOURCE;
        dsc->begin_resource_count--;
    }


I think this is the parsing file for reading postscript input, not generating
output.

So, sorry if that was lengthy, and didn't really resolve anything, but I think
the warmest trail is #3 above.  If there is someone who can compile under MXE
and put some fprintf(stderr,) calls in precise locations involving that
pco->cos_procs->write(pco, pdev, object_id);, it might go somewhere.

...

OK, wait.  Just a little more.  Where might this "cos_write" come from?  I see
a header file ijs/unistd.h that has the following:


/* unistd_.h */
#if defined(_WIN32)
#  include <process.h>
#  include <io.h>
#  include <fcntl.h>
#if !defined(__WATCOMC__)
   /* everything except watcom have _read()/_write(),
      watcom has read()/write() but not _read()/_write() */
#  define read(handle, buffer, count) _read(handle, buffer, count)
#  define write(handle, buffer, count) _write(handle, buffer, count)
#endif /* !__WATCOMC__ */
#ifdef _MSC_VER
   /* MSVC alone require this? */
#  define close(fd) _close(fd)
#endif /* _MSC_VER */
#else
#  include <unistd.h>
#endif


which has a WIN3D precompile conditional.  So, basically, could it be that
after all the structure deciphering, the plain old "write()" command for the
compiler is called?  Note that all the other ASCII in that test file, the
"endobj", the "%%EndResource", etc. is done using stream_puts() whereas that
little bit of garbage data between %%EndResource and %%EndProlog looks like it
may be originating from write() instead via what I described in #3.

So, MXE's write() routine... any thoughts?

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?44186>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/