Created attachment 6905 [details]
xl job selecting 'Letter 8.5x11'

job causes crash on ghostpdl-9.00 (not on ghostpdl-8.71).

Created attachment 6906 [details]
xl-job selecting 'Letter 8.5x11'

xl-job selecting 'Letter 8.5x11' causes crash on 9.00, not on 8.71

Please attach the original XL file or a file disassembled with tools/pxldis.py, I steer away from using HP's tools.  Thanks

Hi Norbert I sent you email that I need the original XL file to fix this please reopen this bug when you attach it.  Thanks

Created attachment 6938 [details]
xl testfile selecting 'letter 8.5x11'

same file, now without PJL header.

added testfile

Created attachment 6941 [details]
gzipped xl-job selecting 'letter 8.5x11'

Fixed in 11907, the file does raise another issue - possibly a different bug.  HP searches for paper size letter 8.5x11 we don't find that because we only search for the 'letter' per the spec.  The file works because the default for not finding the specified page size is to return letter.  I haven't looked into this.

(In reply to comment #8)
> Fixed in 11907, the file does raise another issue - possibly a different bug. 
> HP searches for paper size letter 8.5x11 we don't find that because we only
> search for the 'letter' per the spec.  The file works because the default for
> not finding the specified page size is to return letter.  I haven't looked into
> this.

The 'Letter 8.5x11' a paperformat supported by our printers, and the job was generated with our printerdriver.

(In reply to comment #9)
> (In reply to comment #8)
> > Fixed in 11907, the file does raise another issue - possibly a different bug. 
> > HP searches for paper size letter 8.5x11 we don't find that because we only
> > search for the 'letter' per the spec.  The file works because the default for
> > not finding the specified page size is to return letter.  I haven't looked into
> > this.
> 
> The 'Letter 8.5x11' a paperformat supported by our printers, and the job was
> generated with our printerdriver.

I printed same job with the fix. The xl-error at the end (UndefinedFontNotRemoved) comes from the fact that the testjob was created from a much larger job (> 300 pages). I.e. the job is not entirely cosher. But it should not cause a crash because of the 'letter 8.5x11' .

(In reply to comment #9)
> (In reply to comment #8)
> > Fixed in 11907, the file does raise another issue - possibly a different bug. 
> > HP searches for paper size letter 8.5x11 we don't find that because we only
> > search for the 'letter' per the spec.  The file works because the default for
> > not finding the specified page size is to return letter.  I haven't looked into
> > this.
> 
> The 'Letter 8.5x11' a paperformat supported by our printers, and the job was
> generated with our printerdriver.

I recommend
ubyte_array eLetterPaper MediaSize

Your example generates an error on the HP 4600 Color Laserjet - Illegal Media Size, but I assume it works on some other HP printer as I've seen this kind of lenient string matching before, so I didn't throw a media size error.

Regarding comment #10 it certainly shouldn't crash - I just get the font error as expected.  Send me a command line and I'll look at it.

Created attachment 6945 [details]
corrected testfile

I removed the unnecessary 'Remove Fonts', and then the Font-error does not occur anymore.


So concluding: the crash should not occur, and behaviour should be:
either fallback to a default paper (PJL default: Letter for USA, A4 for Europe?)
or generate a media size error.

Both are ok for me as
the 'letter 8.5x11' does work on our printers, which have a lot more supported media. So I extended the known_media with our extra formats and also added some support to match for aliases (names found in other printerdrivers), so letter and 'letter 8.5x11' and 'letter standard' are all mapped onto eLetterPaper. Same for Tabloid and Ledger.

> 
> So concluding: the crash should not occur, and behaviour should be:
> either fallback to a default paper (PJL default: Letter for USA, A4 for
> Europe?)
> or generate a media size error.

I am still a bit confused here, at no time during studying this problem did I see a crash.  If there is a scenario that does create a crash please let me know.  Thanks.

(In reply to comment #13)
> > 
> > So concluding: the crash should not occur, and behaviour should be:
> > either fallback to a default paper (PJL default: Letter for USA, A4 for
> > Europe?)
> > or generate a media size error.
> 
> I am still a bit confused here, at no time during studying this problem did I
> see a crash.  If there is a scenario that does create a crash please let me
> know.  Thanks.

I compiled with MSVC, (and reverted the fix, so I then have the known_media defined as:
static px_media_t known_media[] = {
  px_enumerate_media(m_data)
{eLetterPaper}
};

debugobj/pcl6 -sDEVICE=jpeg -sOutputFile=page%d.jpg -r600 letter2.xl

will then crash with the following stacktrace

...
 px_process()
  pxBeginPage() (line 365 in pxsessio.c)
   px_paper_string_to_media() (line 79 in pxsessio.c)
    pjl_compare(paper_str, known_media[i].mname) (line 1221 in pjparse.c)
      for (; toupper(*s1) == toupper(*s2); ++s1, ++s2) 

paper_str = "Letter 8.5x11"
and i = 25 ; i.e. index of {eLetterPaper}
and known_media[i].mname == NULL. so toupper(NULL) crashes

known_media[24] = {21, "jisexec",2551,3898,50,50,50,50}
known_media[25] = {0, 0, 0, 0, 0, 0, 0, 0 }