Re: [Tex] very subtle endobj bug in latest pdftex

Hi Ross,

I have committed a workaround for this problem to supelec.

The situation is still not flawless, for example there are still cases
like this:

>>/ExtGState <<

Note there is no end-of-line after ">>". This looks a bit ugly but
otherwise harmless.

Regards,
Thanh


On 24 June 2014 01:10, Ross Moore <[email protected]> wrote:
> Hi Reinhard, Akira, and everyone else.
>
>
> Thanks for looking at this.
>
> On 24/06/2014, at 7:58 AM, Reinhard Kotucha wrote:
>
>> On 2014-06-23 at 12:44:37 +0900, Akira Kakuto wrote:
>>
>>> Dear Ross Moore,
>>>
>>>>>  <<
>>>>>  /I false
>>>>>  /K false
>>>>>  /CS /DeviceRGB
>>>>>  /S /Transparency
>>>>>>> endobj
>>>
>>> It seems that pdftex in TeX Live 2014 is copying
>>>
>>>>> \rendobj
>>>
>>> as
>>>
>>>>> endobj
>>>
>>> ignoring \r.
>>
>> Shouldn't it be \n instead of \r anyway?
>>
>> The PDF/A standard explicitly forbids \r as a line break.  The problem
>> is that if both, \r and \r\n are allowed and the content stream
>> contains binary data, it's impossible to determine whether \n is part
>> of the line break or part of the content stream.
>
> Yes, but if pdfTeX has already determined that the context makes it
> safe to remove the  \r  (as it seems to have done) then it should be
> possible to check the next character or upcoming key-word,
> to determine that  \n  is indeed required.
>
> One might well ask why the \r  was in the image file in the first
> place. The production of that image has a bit of history, but the
> final producer was Adobe Illustrator CS2 - quite an old version
> - on a Mac, where \r  is the usual line-end character.
>
> There are dozens of instances of these:  (using  vi )
>
>    ^Mendobj^M636 0 obj<<
> and
>    >>^Mendobj^M637 0 obj<<
>
> with different object numbers, but only one seems to have
> been handled incorrectly. The thing that seems to characterise
> this instance is that the object is a Transparency Group setting
> a ColorSpace, occurring immediately before the /Info  dictionary,
> which was originally created using pdfTeX itself (the PDF page
> being later edited in AI).
>
> The same thing happens with 2 other PDF images that I need
> for my final full document.
>
>
> Best of luck tracking this down, Thanh.
>
>
>
> But Reinhard makes an interesting point.
> Maybe if I use Acrobat Pro to Save As...  PDF/A then the
> line-ends will be changed from \r  to \n  and this
> problem can be avoided?
>
> Unfortunately it compresses, but I still see plenty of ^M in
> uncompressed portions of the resulting file.
> Also, it seems to have changed the colors somewhat.
>
>>
>> Regards,
>>  Reinhard
>
>
>
> Cheers,
>
>         Ross
>
> ------------------------------------------------------------------------
> Ross Moore                                       [email protected]
> Mathematics Department                           office: E7A-206
> Macquarie University                             tel: +61 (0)2 9850 8955
> Sydney, Australia  2109                          fax: +61 (0)2 9850 8114
> ------------------------------------------------------------------------
>
>
>
>
> _______________________________________________
> Tex mailing list
> [email protected]
> http://lists.river-valley.com/cgi-bin/mailman/listinfo/tex
>