Bug 708201 - Corrupted PDF with lualatex + gs 10.04.0
Summary: Corrupted PDF with lualatex + gs 10.04.0
Status: RESOLVED DUPLICATE of bug 708042
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Text (show other bugs)
Version: 10.04.0
Hardware: PC Linux
: P2 normal
Assignee: Default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-12-18 17:01 UTC by Denis Bitouzé
Modified: 2024-12-19 14:25 UTC (History)
0 users

See Also:
Customer:
Word Size: ---


Attachments
Test file (3.51 KB, application/pdf)
2024-12-18 17:01 UTC, Denis Bitouzé
Details
Original test file (uncompressed) before gs is used (3.45 KB, application/pdf)
2024-12-18 17:06 UTC, Denis Bitouzé
Details
Original test file (uncompressed) after gs is used (3.51 KB, application/pdf)
2024-12-18 17:07 UTC, Denis Bitouzé
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Denis Bitouzé 2024-12-18 17:01:04 UTC
Created attachment 26295 [details]
Test file

Consider the following simple `test.tex` source file:

\documentclass{article}
\begin{document}
Foo.
\end{document}

Compiled with both (up to date TeX Live 2024) `pdflatex`, `xelatex` or `lualatex`, the resulting `test.pdf` is okay. But, if it is compiled with `lualatex` (only) and if the resulting PDF is subject to:

gs -P- -dSAFER -q -P- -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sstdout=%stderr "-sOutputFile=test.pdf.pdf" -P- -dSAFER test.pdf

with `gs` (version 10.04.0), the “Foo.” text in `test.pdf.pdf` (joined), if copied and pasted, returns:

6QQX

I don't know the PDF internals but this bug has been discussed here:

https://tug.org/pipermail/tex-live/2024-December/050985.html

and, in this thread, from this post:

https://tug.org/pipermail/tex-live/2024-December/050990.html

and the following ones, it looks like the  mapping is missing in gs 10.04.0  while gs 10.03.1 includes it.
Comment 1 Denis Bitouzé 2024-12-18 17:06:17 UTC
Created attachment 26296 [details]
Original test file (uncompressed) before gs is used

Added the original test file (uncompressed) before gs is used.
Comment 2 Denis Bitouzé 2024-12-18 17:07:52 UTC
Created attachment 26297 [details]
Original test file (uncompressed) after gs is used

Replaced the test file by the one obtained from the original one after gs is used.
Comment 3 Ken Sharp 2024-12-18 17:36:26 UTC

*** This bug has been marked as a duplicate of bug 708042 ***
Comment 4 Denis Bitouzé 2024-12-18 20:05:11 UTC
(In reply to Ken Sharp from comment #3)
> 
> *** This bug has been marked as a duplicate of bug 708042 ***

Could you please explain in what the current bug is a duplicate of bug 708042, and what to do to get rid of this issue?

Thanks.
Comment 5 Ken Sharp 2024-12-19 08:24:02 UTC
(In reply to Denis Bitouzé from comment #4)
> (In reply to Ken Sharp from comment #3)
> > 
> > *** This bug has been marked as a duplicate of bug 708042 ***
> 
> Could you please explain in what the current bug is a duplicate of bug
> 708042, and what to do to get rid of this issue?
> 
> Thanks.

 You failed to give the back channel output:

------------------------------------------------------------------------------
GPL Ghostscript 10.04.0 (2024-09-18)
Copyright (C) 2024 Artifex Software, Inc.  All rights reserved.
This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY:
see the file COPYING for details.
Processing pages 1 through 1.
Page 1

The following errors were encountered at least once while processing this file:
        CMap unrecoverably broken

   **** This file had errors that were repaired or ignored.
   **** The file was produced by:
   **** >>>> LuaTeX-1.18.0 <<<<
   **** Please notify the author of the software that produced this
   **** file that it does not conform to Adobe's published PDF
   **** specification.
------------------------------------------------------------------------------

The input file has an 'unusual' CMap with an empty bfrange, just as described in 708042.

----------------------
0 beginbfrange
endbfrange
----------------------

Remove those two lines and the problem disappears. So clearly the same problem as described in comment #3 of bug #708042.

*** This bug has been marked as a duplicate of bug 708042 ***
Comment 6 Denis Bitouzé 2024-12-19 08:40:07 UTC
(In reply to Ken Sharp from comment #5)
> (In reply to Denis Bitouzé from comment #4)
> > (In reply to Ken Sharp from comment #3)
> > > 
> > > *** This bug has been marked as a duplicate of bug 708042 ***
> > 
> > Could you please explain in what the current bug is a duplicate of bug
> > 708042, and what to do to get rid of this issue?
> > 
> > Thanks.
> 
>  You failed to give the back channel output:
> [...]

Sorry, I have no idea what is the back channel output and how to get it.
Comment 7 Ken Sharp 2024-12-19 08:56:43 UTC
(In reply to Denis Bitouzé from comment #6)
> (In reply to Ken Sharp from comment #5)
> > (In reply to Denis Bitouzé from comment #4)
> > > (In reply to Ken Sharp from comment #3)
> > > > 
> > > > *** This bug has been marked as a duplicate of bug 708042 ***
> > > 
> > > Could you please explain in what the current bug is a duplicate of bug
> > > 708042, and what to do to get rid of this issue?
> > > 
> > > Thanks.
> > 
> >  You failed to give the back channel output:
> > [...]
> 
> Sorry, I have no idea what is the back channel output and how to get it.

When you run Ghostscript, provided you don't do something unhelpful like setting -q or -dQUIET, which suppresses the information, you get helpful information on stdout and stderr. Note your command line binds stdout to stderr so all the output goes to stderr.

In passing; your command line uses -q which is (as noted) less than ideal when investigating problems, and also sets -dSAFER twice and -P- three times.
Comment 8 Denis Bitouzé 2024-12-19 14:25:06 UTC
(In reply to Ken Sharp from comment #7)
> (In reply to Denis Bitouzé from comment #6)
> > (In reply to Ken Sharp from comment #5)
> > > (In reply to Denis Bitouzé from comment #4)
> > > > (In reply to Ken Sharp from comment #3)
>
> When you run Ghostscript, provided you don't do something unhelpful like
> setting -q or -dQUIET, which suppresses the information, you get helpful
> information on stdout and stderr. Note your command line binds stdout to
> stderr so all the output goes to stderr.

Thanks!
 
> In passing; your command line uses -q which is (as noted) less than ideal
> when investigating problems,

OK.

> and also sets -dSAFER twice and -P- three times.

In fact, I first encountered this issue with ps2pdf, which in turn runs ps2pdf14, which in turn runs ps2pdfwr, which in turn runs:

exec "$GS_EXECUTABLE" $OPTIONS -q -P- -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sstdout=%stderr "-sOutputFile=$outfile" $OPTIONS "$infile"

where:

OPTIONS="-P- -dSAFER", hence the options duplicated.