Re: grops and BeginBinary

[Werner LEMBERG]

> - resource_manager::do_begin_binary() has an "ungetc(c, fp)"
>   call, which should be "ungetc(cc, fp)".

Fixed, thanks.

> - The Quark Express data has a terminating carriage return before
>   the %%EndBinary line.  grops is expecting the %%EndBinary to be
>   right up against the end of the binary data, and doesn't tolerate
>   the carriage return.  I don't know if grops or quark is violating
>   the standard, from the look of grops's *output*, I think it's
>   grops that's at fault.

I've just checked Adobe's 5001.DSC_Spec.pdf document -- this is not
really documented.  According to the examples I also think that grops
should be more tolerant.  I've sent a mail to Adobe for clarification.

> I've also had problems with (one of) microsoft's postscript drivers
> which seems to think 256-character lines are fine, but grops won't
> tolerate more than 255.  The patch below makes grops much more
> tolerant by upping the limit to (an arbitrary) 1000.

Well, the spec clearly says (5002.EPSF_Spec.pdf):

  2.9 Miscellaneous Constraints

    EPS files must not have lines of ASCII text that exceed 255
    characters, excluding line-termination characters.

    ...

Please report this incorrect behaviour to Microsoft.  I doubt that it
is a good idea to make grops more tolorant here since such PS files
will fail almost everywhere.


    Werner