Hi David,
JFYI, I have updated the texlive packages and have asked the release
managers to include the new binaries into the next release.
Upstream TeX Live has the patch already included in subversion.
Thanks a lot for your research and communication
Norbert
--
PREINING Norbert
On Wed, Mar 29, 2017 at 01:57:00PM +0900, Norbert Preining wrote:
> Do you think that an update for testing (in pre-release freeze) is
> required? Or possible?
I don't know anything about the release process so I can't comment on
that. I didn't test the change I suggested. This could be a
Hi David,
> The function write_png_rgb_alpha allocates twice as much memory as is
> necessary for the smask buffer. The second half of the buffer is left
> uninitialized and the whole buffer is copied to the output PDF file. It
> only arises with PNG images that have an alpha channel. (I suppose
On Tue, Sep 01, 2015 at 08:23:07AM +0900, Norbert Preining wrote:
> > I can still reproduce it inside a sid schroot (uptodate) and than run
> > testscript.sh
>
> Yes, this is a different item. The first - fixed by updating - was
> about differences in the fine dict.
>
> The problem with images
Hi Sandro,
> I can still reproduce it inside a sid schroot (uptodate) and than run
> testscript.sh
Yes, this is a different item. The first - fixed by updating - was
about differences in the fine dict.
The problem with images is not solved by now. I have no
idea where this comes from.
I
Hey,
I have checked by running pdflatex a few times, then compare two
successive runs, that the only changes are:
* /CreationDate
* /ModDate
* /ID in the /XRef table
nothing else has changed.
That is really strange, we have seen the diff inthe image blob mutiple times
and also could
Hey,
I can actually reproduce with the following:
\documentclass{article}
\begin{document}
\tableofcontents
\end{document}
.. which somewhat contradicts my previous paragraph. We might have three
issues here instead of just two.
Have you run pdflatex multiple times? Beause with
On Sun, 23 Aug 2015, Sandro Knauß wrote:
That is really strange, we have seen the diff inthe image blob mutiple times
and also could reproduce this on a openSuse. I'll give it another try in some
days. And keep you informed.
Please run pdflatex 3 or 4 times, and then compare two runs.
Hi Sandro
On Sun, 23 Aug 2015, Sandro Knauß wrote:
I can still reproduce the bug with the changing stream (images) with pdflatex
2014.20141024-2 on my system.
Not surprising. Nothing will change on jessie.
Can you please try it on sid with the packages that I uploaded
yesterday. There I see
pdflatex creates every time a different pdf (it differs in the
emeded images).
To clarify, the CreationDate and ModDate headers vary, but that is an
separate issue. For example, in:
http://i.imgur.com/GU5lqxF.png
.. I am ignoring the top part of the diff.
less pictures and no
Hi all,
On Sat, 22 Aug 2015, Sandro Knauß wrote:
While testing why the owncloudClient pdf is not reproducible, we found a bug
in pdflatex. The minimal document to triggerthis bug is a document with 4
I kind of disagree that this is a bug. It is a decision by the
pdftex developers to embed
The issue with timestamps Chris was mentioning is already
tracked in another bug: #792202 and also sent upstream [1].
And upstream was already discussing about making the Timestamps and
the ID turned off by default (and only embedded on request) [2].
This bug is actually only about the behavior
On Sat, 22 Aug 2015, Reiner Herrmann wrote:
tracked in another bug: #792202 and also sent upstream [1].
And upstream was already discussing about making the Timestamps and
the ID turned off by default (and only embedded on request) [2].
Great to hear.
Ignoring the Timestamps and the ID
Hi all,
(thanks Sandro for the files)
On Sat, 22 Aug 2015, Reiner Herrmann wrote:
Ignoring the Timestamps and the ID field, there is some additional
unreproducibility with those specific PNG files (perhaps related
to converting them or so), which should be fixed.
I have checked by running
14 matches
Mail list logo
