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

[Dan Sebald]

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

I think this binary write() is a red herring.  One reason is that the data
between %%EndResource and %%EndProlog is different for the a1.ps and a2.ps
examples.

The second reason is that I've compiled ghostscript 9.15 and tried following
the flow of events in the code by writing some comments into the EPS file. 
Here is the a2.ps code where we see problems:


%%EndResource
'.bd)$W9)[9aoC`EYQaCH6EJfnGELnTogC'^OSOs#N(address@hidden<='#W,8o)ht(8F)Qf,
J;>FWQB6t-4X#g2M;MFNJ%%EndProlog


By use of comments, I've traced this down to the following code hunk inside
gdevpdf.c:


    /* Copy the resources into the main file. */

    s = pdev->strm;
    resource_pos = stell(s);
    sflush(pdev->asides.strm);
    {
        FILE *rfile = pdev->asides.file;
        int64_t res_end = gp_ftell_64(rfile);

        gp_fseek_64(rfile, 0L, SEEK_SET);
        pdf_copy_data(s, rfile, res_end, NULL);
    }

    if (pdev->ForOPDFRead && pdev->ProduceDSC) {
        int j;

        code = 0;
        pagecount = 1;

        /* All resources and procsets written, end the prolog */
        stream_puts(pdev->strm, "%%EndPrologn");


That %%EndProlog above is the one written write after the garbage data. 
Notice above the code where %%EndProlog is written is the output routine
pdf_copy_data().  Let's look at that one:


/* Copy data from a temporary file to a stream. */
void
pdf_copy_data(stream *s, FILE *file, gs_offset_t count, stream_arcfour_state
*ss)
{
    gs_offset_t r, left = count;
    byte buf[sbuf_size];

stream_puts(s, "%%BEFORE LOOPn");
    while (left > 0) {
        uint copy = min(left, sbuf_size);

        r = fread(buf, 1, copy, file);
        if (r < 1) {
            gs_note_error(gs_error_ioerror);
            return;
        }
        if (ss)
            s_arcfour_process_buffer(ss, buf, copy);
        stream_write(s, buf, copy);
stream_puts(s, "%%JUST WROTE TO STREAMn");
        left -= copy;
    }
}


OK, with those comments, what I'm seeing in the data is %%JUST WROTE TO STREAM
throughout the whole generated EPS file.  In other words, the pdf_copy_data()
is used both before and after the %%EndProlog.  So, I have to conclude the
routine is fundamentally sound, because if it weren't we wouldn't be able to
fix the broken EPS file by removing the garbage data between %%EndResource and
%%EndProlog.  There's be bad data throughout the file.

Right before that %%EndProlog it appears that some resource data is being put
in place.  Where does that come from?  Are there some resource files somewhere
that are to be put at the head of the PostScript file?  Font descriptions? 
Default formating?  I don't know.  I'm still trying to figure out how things
are pieced together with Octave/ghostscript.

So obviously this pdf_copy_data() is getting data from some bogus location and
copying it into the output file.  What could it be?  Maybe

1) Some bad data in one of the resource locations?  Is MXE missing some
resource file?  But the garbage data is different in both examples, so not
likely.

2) This hunk of code might be dodgy:


    resource_pos = stell(s);
    sflush(pdev->asides.strm);
    {
        FILE *rfile = pdev->asides.file;
        int64_t res_end = gp_ftell_64(rfile);

        gp_fseek_64(rfile, 0L, SEEK_SET);
        pdf_copy_data(s, rfile, res_end, NULL);


Notice how there really is no check on the validity of the file stream.  The
gp_ftell_64() is supposed to indicate the length of the file, I guess. 
gp_fseek_64() is setting the file pointer to the head of the file, presumably.
 But what if that rfile pointer is not valid?  In that case gp_fseek_64()
would return an error value, in theory.  There really should be a conditional
test, e.g.,


        if (!gp_fseek_64(rfile, 0L, SEEK_SET))
            pdf_copy_data(s, rfile, res_end, NULL);


Of course, if res_end is reported as zero, then no problems.  But I notice
that the gp_fseek_64 and gp_ftell_64 routines are very system dependent:


base/gp_macio.c:int64_t gp_ftell_64(FILE *strm)
base/gp_mswin.c:gs_offset_t gp_ftell_64(FILE *strm)
base/gp_os2.c:int64_t gp_ftell_64(FILE *strm)
base/gp_unifs.c:int64_t gp_ftell_64(FILE *strm)
base/gp_vms.c:int64_t gp_ftell_64(FILE *strm)

base/gp_macio.c:int gp_fseek_64(FILE *strm, int64_t offset, int origin)
base/gp_mswin.c:int gp_fseek_64(FILE *strm, gs_offset_t offset, int origin)
base/gp_os2.c:int gp_fseek_64(FILE *strm, int64_t offset, int origin)
base/gp_unifs.c:int gp_fseek_64(FILE *strm, int64_t offset, int origin)
base/gp_vms.c:int gp_fseek_64(FILE *strm, int64_t offset, int origin)


I'm wondering if something is not working exactly correctly with the above
file routines on MXE.

Let's assume that some bogus file makes it to the point of pdf_copy_data(). 
There is another chance to catch the issue, in that routine:


        r = fread(buf, 1, copy, file);
        if (r < 1) {
            gs_note_error(gs_error_ioerror);
            return;
        }


If the read doesn't produce any data (because maybe the "file" pointer is
bogus), an error is noted and then returned.  So for bogus data to get through
(assuming it isn't originating from the file's contents) the value of r
reported back needs to be 1 or greater.  Maybe on MXE that is a meaningless
value for a bogus file, while on linux a value of zero comes back for a bogus
file.

Just speculating, but I think I'm sniffing more in the general area now.  If
someone on MXE can make this change


        if (!gp_fseek_64(rfile, 0L, SEEK_SET))
            pdf_copy_data(s, rfile, res_end, NULL);


and recompile and see if that fixes the problem, maybe it will lead
somewhere.


    _______________________________________________________

Reply to this item at:

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

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