| Summary: | gs9.52 pdf2ps + ps2pdf round trip fails with Resource R713 is a shading, which can't be handled at level 2. | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | William Bader <williambader> |
| Component: | PDF Writer | Assignee: | Ken Sharp <ken.sharp> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | williambader |
| Priority: | P4 | ||
| Version: | 9.52 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Customer: | Word Size: | --- | |
| Attachments: |
PDF to show the problem
result of poppler 0.89.0 pdftops -level3 4244201-1.pdf viewing gs pdfwrite output in gv |
||
Thank you for the complete bug report (file and command line). Created attachment 19390 [details] result of poppler 0.89.0 pdftops -level3 4244201-1.pdf In all of the tests in my first comment, it happens without any command line options. For another data point, pdftops -level3 4244201-1.pdf x.ps produces an x.ps that views OK in gv, and ps2pdf x.ps x1.pdf completes without errors, but the generated pdf is almost all black. I tested poppler pdftops 0.73.0 and 0.89.0 and gs ps2pdf 9.27 and 9.52. It works if I remove the -level3 from pdftops, but I think that it is a gs issue because with -level3, the generated ps views correctly in both versions of gs. I attached the result of poppler 0.89.0 pdftops -level3 4244201-1.pdf x.ps gs ps2pdf creates a pdf that views incorrectly with gs and that crashes atril (the pdf viewer on the mate desktop). ps2ascii doesn't like the pdftops output either. This whole thing started because I need to convert the PDF to an EPS, place the EPS on a postscript page, and then convert the postscript to a PDF, and something along the way is messing with the fonts in a way that breaks copy&paste of text from the PDF. gs can view the x.ps file without problems under the x11 device. ps2ascii works with other files like alphabet.ps. If necessary, I can rebuild gs with debugging to get a more useful traceback. $ ps2ascii x.ps GPL Ghostscript 9.52: It is not possible to preserve transfer functions in PDF 2.0 transfer functions will be applied instead malloc(): invalid size (unsorted) /usr/bin/ps2ascii: line 21: 36509 Aborted (core dumped) $GS_EXECUTABLE $OPTIONS -o - "$1" $ gdb /u/gnu/gs/gs GNU gdb (GDB) Fedora 8.3.50.20190824-30.fc31 Copyright (C) 2019 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /u/gnu/gs/gs... (No debugging symbols found in /u/gnu/gs/gs) (gdb) set args -q -dSAFER -sDEVICE=txtwrite -o - x.ps (gdb) r Starting program: /u/gnu/gs9.52/gs -q -dSAFER -sDEVICE=txtwrite -o - x.ps Missing separate debuginfos, use: dnf debuginfo-install glibc-2.30-11.fc31.x86_64 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". GPL Ghostscript 9.52: It is not possible to preserve transfer functions in PDF 2.0 transfer functions will be applied instead double free or corruption (out) Program received signal SIGABRT, Aborted. 0x00007ffff76e9625 in raise () from /lib64/libc.so.6 Missing separate debuginfos, use: dnf debuginfo-install avahi-libs-0.7-20.fc31.x86_64 bzip2-libs-1.0.8-1.fc31.x86_64 cups-libs-2.2.12-9.fc31.x86_64 dbus-libs-1.12.18-1.fc31.x86_64 expat-2.2.8-1.fc31.x86_64 fontconfig-2.13.92-3.fc31.x86_64 freetype-2.10.0-3.fc31.x86_64 gmp-6.1.2-10.fc31.x86_64 gnutls-3.6.14-1.fc31.x86_64 keyutils-libs-1.6-3.fc31.x86_64 krb5-libs-1.17-46.fc31.x86_64 libICE-1.0.10-2.fc31.x86_64 libSM-1.2.3-4.fc31.x86_64 libX11-1.6.9-2.fc31.x86_64 libXau-1.0.9-2.fc31.x86_64 libXext-1.3.4-2.fc31.x86_64 libXt-1.1.5-12.20190424gitba4ec9376.fc31.x86_64 libcom_err-1.45.5-1.fc31.x86_64 libffi-3.1-23.fc31.x86_64 libgcc-9.3.1-2.fc31.x86_64 libgcrypt-1.8.5-1.fc31.x86_64 libidn-1.35-6.fc31.x86_64 libidn2-2.3.0-1.fc31.x86_64 libpaper-1.1.24-25.fc31.x86_64 libpng-1.6.37-2.fc31.x86_64 libselinux-2.9-5.fc31.x86_64 libtasn1-4.14-2.fc31.x86_64 libuuid-2.34-4.fc31.x86_64 libxcb-1.13.1-3.fc31.x86_64 libxcrypt-4.4.16-3.fc31.x86_64 lz4-libs-1.9.1-1.fc31.x86_64 nettle-3.5.1-3.fc31.x86_64 openssl-libs-1.1.1g-1.fc31.x86_64 p11-kit-0.23.20-1.fc31.x86_64 pcre2-10.35-1.fc31.x86_64 systemd-libs-243.8-1.fc31.x86_64 zlib-1.2.11-20.fc31.x86_64 (gdb) bt #0 0x00007ffff76e9625 in raise () from /lib64/libc.so.6 #1 0x00007ffff76d28d9 in abort () from /lib64/libc.so.6 #2 0x00007ffff772d4af in __libc_message () from /lib64/libc.so.6 #3 0x00007ffff7734a9c in malloc_printerr () from /lib64/libc.so.6 #4 0x00007ffff7736920 in _int_free () from /lib64/libc.so.6 #5 0x00000000006e442c in ?? () #6 0x00000000007a86ae in rc_free_text_enum () #7 0x00000000008d56e4 in ?? () #8 0x00000000008d5b50 in op_show_continue_dispatch () #9 0x000000000089478f in ?? () #10 0x00000000008ba943 in ?? () #11 0x00000000008bb2b8 in gs_interpret () #12 0x00000000008ae8a1 in gs_main_run_string_with_length () #13 0x00000000008b055f in ?? () #14 0x00000000008b080c in ?? () #15 0x00000000008b0922 in ?? () #16 0x00000000008b1fb4 in gs_main_init_with_args01 () #17 0x00000000008b2229 in gs_main_init_with_args () #18 0x000000000046929b in main () (gdb) Traceback with symbols:
(gdb) bt
#0 0x00007ffff76e9625 in raise () from /lib64/libc.so.6
#1 0x00007ffff76d28d9 in abort () from /lib64/libc.so.6
#2 0x00007ffff772d4af in __libc_message () from /lib64/libc.so.6
#3 0x00007ffff7734a9c in malloc_printerr () from /lib64/libc.so.6
#4 0x00007ffff7736920 in _int_free () from /lib64/libc.so.6
#5 0x00000000006e43ac in textw_text_release (pte=0x2274108, cname=0x165c372 "op_show_restore") at ./devices/vector/gdevtxtw.c:2302
#6 0x00000000007a85fe in rc_free_text_enum (mem=0x1dadd68, obj=0x2274108, cname=0x165c372 "op_show_restore") at ./base/gstext.c:759
#7 0x00000000008d5614 in op_show_restore (for_error=for_error@entry=0, i_ctx_p=<optimized out>, i_ctx_p=<optimized out>) at ./psi/zchar.c:1018
#8 0x00000000008d5a80 in op_show_free (code=0, i_ctx_p=0x1de03d8) at ./psi/zchar.c:1034
#9 op_show_continue_dispatch (i_ctx_p=i_ctx_p@entry=0x1de03d8, npop=npop@entry=0, code=0) at ./psi/zchar.c:716
#10 0x00000000008d5f0d in op_show_continue (i_ctx_p=0x1de03d8) at ./psi/zchar.c:690
#11 op_show_continue (i_ctx_p=i_ctx_p@entry=0x7) at ./psi/zchar.c:685
#12 0x00000000008946bf in moveshow (i_ctx_p=0x7, have_x=<optimized out>, have_y=<optimized out>) at ./psi/zcharx.c:143
#13 0x00000000008ba873 in interp (perror_object=<optimized out>, pref=<optimized out>, pi_ctx_p=<optimized out>) at ./psi/interp.c:1410
#14 gs_call_interp (pi_ctx_p=pi_ctx_p@entry=0x1dace30, pref=pref@entry=0x7fffffffa240, user_errors=user_errors@entry=1, pexit_code=pexit_code@entry=0x7fffffffa29c,
perror_object=<optimized out>) at ./psi/interp.c:520
#15 0x00000000008bb1e8 in gs_interpret (pi_ctx_p=pi_ctx_p@entry=0x1dace30, pref=pref@entry=0x7fffffffa240, user_errors=user_errors@entry=1,
pexit_code=pexit_code@entry=0x7fffffffa29c, perror_object=<optimized out>, perror_object@entry=0x7fffffffa2a0) at ./psi/interp.c:477
#16 0x00000000008ae7d1 in gs_main_interpret (perror_object=0x7fffffffa2a0, pexit_code=0x7fffffffa29c, user_errors=1, pref=0x7fffffffa240, minst=0x1dacd90) at ./psi/imain.c:253
#17 gs_main_run_string_end (perror_object=0x7fffffffa2a0, pexit_code=0x7fffffffa29c, user_errors=1, minst=0x1dacd90) at ./psi/imain.c:791
#18 gs_main_run_string_with_length (str=<optimized out>, length=<optimized out>, perror_object=0x7fffffffa2a0, pexit_code=0x7fffffffa29c, user_errors=1, minst=0x1dacd90)
at ./psi/imain.c:735
#19 gs_main_run_string_with_length (minst=0x1dacd90, str=<optimized out>, length=<optimized out>, user_errors=1, pexit_code=0x7fffffffa29c, perror_object=0x7fffffffa2a0)
at ./psi/imain.c:721
#20 0x00000000008b048f in run_string (minst=minst@entry=0x1dacd90, str=str@entry=0x212a3f0 "<782e7073>.runfile", options=options@entry=3, user_errors=user_errors@entry=1,
pexit_code=0x7fffffffa29c, pexit_code@entry=0x0, perror_object=0x7fffffffa2a0, perror_object@entry=0x0) at ./psi/imainarg.c:1119
#21 0x00000000008b073c in runarg (minst=minst@entry=0x1dacd90, arg=arg@entry=0x7fffffffa3b8 "x.ps", post=post@entry=0x165533d ".runfile", options=options@entry=3,
user_errors=1, pexit_code=pexit_code@entry=0x0, perror_object=0x0, pre=0x1474b5d "") at ./psi/imainarg.c:1088
#22 0x00000000008b0852 in argproc (arg=0x7fffffffa3b8 "x.ps", minst=0x1dacd90) at ./psi/imainarg.c:1010
#23 argproc (minst=0x1dacd90, arg=0x7fffffffa3b8 "x.ps") at ./psi/imainarg.c:995
#24 0x00000000008b1ee4 in gs_main_init_with_args01 (minst=minst@entry=0x1dacd90, argc=argc@entry=7, argv=argv@entry=0x7fffffffaed8) at ./psi/imainarg.c:241
#25 0x00000000008b2159 in gs_main_init_with_args (minst=0x1dacd90, argc=argc@entry=7, argv=argv@entry=0x7fffffffaed8) at ./psi/imainarg.c:288
#26 0x00000000008b352d in psapi_init_with_args (ctx=<optimized out>, argc=argc@entry=7, argv=argv@entry=0x7fffffffaed8) at ./psi/psapi.c:272
#27 0x000000000090e475 in gsapi_init_with_args (instance=<optimized out>, argc=argc@entry=7, argv=argv@entry=0x7fffffffaed8) at ./psi/iapi.c:148
#28 0x000000000046929b in main (argc=7, argv=0x7fffffffaed8) at ./psi/gs.c:95
(gdb) frame 5
#5 0x00000000006e43ac in textw_text_release (pte=0x2274108, cname=0x165c372 "op_show_restore") at ./devices/vector/gdevtxtw.c:2302
2302 gs_free(tdev->memory, penum->Widths, sizeof(float), pte->text.size, "txtwrite free temporary widths array");
(gdb) print tdev->memory
$1 = (gs_memory_t *) 0x1daf148
(gdb) print penum->Widths
$2 = (float *) 0x2187bf0
(gdb) print pte->text.size
$3 = 8
(gdb) print *pte
$4 = {text = {operation = 132353, data = {bytes = 0x22764d8 "", chars = 0x22764d8, glyphs = 0x22764d8, d_char = 36136152, d_glyph = 36136152}, size = 8, delta_all = {
x = 1.7372976548146921e-316, y = 4.9406564584124654e-324}, delta_space = {x = 1.7372976548146921e-316, y = 1.7372976548146921e-316}, space = {s_char = 140737488289792,
s_glyph = 140737488289792}, x_widths = 0x22740d0, y_widths = 0x22740d0, widths_size = 8}, dev = 0x1e421b8, imaging_dev = 0x0, pgs = 0x1de06c8, orig_font = 0x2273688,
path = 0x1dfe4f0, pdcolor = 0x2262780, pcpath = 0x226c400, memory = 0x1dadd68, procs = 0x1463ce0 <textw_text_procs>, rc = {ref_count = 0, memory = 0x1dadd68,
free = 0x7a85e0 <rc_free_text_enum>}, enum_client_data = 0x0, current_font = 0x2273688, outer_CID = 2147483647, is_pure_color = 1, log2_scale = {x = 0, y = 0}, pair = 0x0,
index = 8, xy_index = 0, fstack = {depth = 0, items = {{font = 0x2273688, index = 0}, {font = 0x0, index = 0}, {font = 0x0, index = 0}, {font = 0x0, index = 0}, {font = 0x1,
index = 0}, {font = 0x0, index = 0}}}, cmap_code = 0, single_byte_space = 0, bytes_decoded = 0, FontBBox_as_Metrics2 = {x = 0, y = 0}, text_enum_id = 0,
device_disabled_grid_fitting = 0, fapi_log2_scale = {x = 0, y = 0}, fapi_glyph_shift = {x = 0, y = 0}, returned = {current_char = 0, current_glyph = 0, total_width = {
x = 0.029953839460792844, y = 0}}, auto_release = 0, pgs2 = 0x0, level = 0, charpath_flag = cpm_show, show_gstate = 0x0, can_cache = 0, ibox = {p = {x = 0, y = 64}, q = {
x = 1, y = 8842464}}, obox = {p = {x = 0, y = 8842480}, q = {x = 0, y = 8842496}}, ftx = 0, fty = 8577536, encode_char = 0x872310 <gx_forward_get_initial_matrix>,
dev_cache = 0x86bf40 <gx_default_sync_output>, dev_cache2 = 0x86c290 <gx_default_output_page>, dev_null = 0x86d5b0 <gx_default_close_device>, wxy = {x = 8856512, y = 0},
wxy_float = {x = 4.3757457514827509e-317, y = 4.2337394272924764e-317}, use_wxy_float = 8796896, origin = {x = 122900, y = 88573}, cc = 0x0, width_status = 8829696,
continue_proc = 0x86fb10 <gx_default_get_bits>}
(gdb)
(In reply to William Bader from comment #0) > I have a pdf that when I run it through pdf2ps and then run the resulting ps > through ps2pdf, ps2pdf fails with > $ ps2pdf g1.ps g11.pdf > GPL Ghostscript 9.52: > It is not possible to preserve transfer functions in PDF 2.0 > transfer functions will be applied instead > Resource R713 is a shading, which can't be handled at level 2. > %%[ Error handled by opdfread.ps : undefined; OffendingCommand: > ....Undefined ]%% > %%[STACK: > 2 > --nostringval-- > /R713 > --nostringval-- > /R713 > -mark- > -mark- > -mark- > %%]% The PostScript produced by ps2write should never contain a Shading, because shadings are a level 3 feature and ps2write only emits level 2 PostScript. These should have been rendered to an image instead. > I am running gs on Fedora 31 Linux on x86_64. > Fedora 31 has 9.27. > The problem seems triggered by gs 9.52 pdf2ps which causes the same error in > both gs 9.27 and 9.52 ps2pdf. > The ps produced by gs 9.27 pdf2ps works with both gs 9.27 and 9.52 ps2pdf. > > Trying ps2pdf with various compatibility levels like > ps2pdf -dCompatibilityLevel=2.0 > does not help. The ps2pdf and pdf2ps scripts set the CompatibilityLevel internally apparently, so I suspect that simply can't be set from the command line, or at least not like that. I'm unable to reproduce this problem. I've tried Linux (Ubuntu 18.10) 64-bit binary built from the 9.52 source tag, release build; current master, 64-bit release build; Windows 32-bit and 64-bit debug builds built from current master as well as the Windows 32 and 64-bit release binaries. None of these give me any problems, and the PDF file produced looks reasonably similar to the original, although considerably smaller at 2.5MB. I do see some colour shifts but it would take some time to figure out why and that doesn't (yet at least) seem to be your problem. So the first question then is where did you get the 9.52 binary you are using, did you build it yourself from source, or is it a packaged version ? If you did build it yourself, did you specify any additional build controls ? Rather than use the scripts, can you please try instead: gs -sDEVICE=ps2write -o out.ps 4244201-1.pdf and then gs -sDEVICE=pdfwrite -o out.pdf out.ps So we can remove a possible source of confusion and errors (the scripts). (In reply to William Bader from comment #3) > ps2ascii doesn't like the pdftops output either. Well that would be a different problem. Please help to reduce my confusion; if you've got a different problem open a new bug. I find it difficult to track multiple problems in a single bug report. > This whole thing started because I need to convert the PDF to an EPS, place > the EPS on a postscript page, and then convert the postscript to a PDF, and > something along the way is messing with the fonts in a way that breaks > copy&paste of text from the PDF. That's not at all surprising. Search/copy/paste is, essentially, a retrofit to PDF. There was no real scope for this in the original PDF specification which was merely intended to display the file the same across platforms, originally nobody expected to be able to search the file. However Acrobat did make some simple attempts at this in its early versions of Acrobat. If the Encoding being used was ASCII (or one of a number of 'standard' encodings), then this did in fact work which led people to use it and complain when it didn't work. The usual problem is subset fonts; this is because subset fonts usually start their encoding by putting the first character used at encoding 1, the second at encoding point 2, etc. This means that 'Hello' is encoded as 0x01, 0x02, 0x03, 0x03, 0x04 instead of the ASCII values of 0x48, 0x65, 0x6c, 0x6c, 0x6f. To try and improve this situation Adobe later added the ToUnicode CMap. A font can (optionally) include a ToUnicode CMap which maps the encoding point to a Unicode code point, so that search etc can work. All well and good. However *PostScript* doesn't have any notion of a ToUnicode CMap (not even in level 3). So when you convert a PDF file to PostScript that 'meta' information is necessarily discarded. Convert that PostScript back to PDF and 'poof' the Unicode information is gone and the search which used to work no longer does. 40 of the fonts in your original PDF file contain ToUnicode CMaps. Those cannot be preserved into the PostScript, and so if you convert that PostScript back into PDF, all that information will be lost for those fonts. It would not surprise me at all to find that after that treatment text cannot be searched for. This is the sort of thing that I have in mind when I tell people not to do round-tripping unless they absolutely have to, and if they do then they have to expect possible problems. PDF and PostScript are not the same. > gs can view the x.ps file without problems under the x11 device. > ps2ascii works with other files like alphabet.ps. > If necessary, I can rebuild gs with debugging to get a more useful traceback. You might like to try the current HEAD of master if you're going to rebuild Ghostscript. There has already been at least one recent memory bug fixed: https://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=8c7bd787defa071c96289b7da9397f673fddb874 Otherwise please open a new report. Created attachment 19398 [details] viewing gs pdfwrite output in gv Thanks for the suggestions. 1/ I rebuilt from the gs 9.52 source distribution (without my build script), and the file created by ps2write worked with pdfwrite. I will have to check what my build script does. It messes with CFLAGS to add a higher optimization among other things, but I thought that if I lost something important, it wouldn't compile or link. I've been using this script for years, and this is the first time that something didn't work. /tmp/gs9.52/gs -sDEVICE=ps2write -o out.ps 4244201-1.pdf ; /tmp/gs9.52/gs -sDEVICE=pdfwrite -o out.pdf out.ps # works ok with standard build Comparing my build against a standard build with configure and make, the build from my script seems to have added a color space. I am going to look at it some more to be sure that it is something that I did wrong rather than different compile options exposing a bug. $ diff xgsw.ps xgsnew.ps | head -30 # xgsw = made with my build, xgsnew = made with default build 7c7 < %%CreationDate: D:20200702055535+01'00' --- > %%CreationDate: D:20200702060815+01'00' 25492c25492 < %%BeginResource: file (PDF Color Space obj_708) --- > %%BeginResource: file (PDF CharProc obj_708) 25494,25498d25493 < [/Pattern] < endobj < %%EndResource < %%BeginResource: file (PDF CharProc obj_714) < 714 0 obj 25521,25522c25516,25517 < %%BeginResource: file (PDF CharProc obj_715) < 715 0 obj --- > %%BeginResource: file (PDF CharProc obj_709) > 709 0 obj 25546,25547c25541,25542 < %%BeginResource: file (PDF CharProc obj_716) < 716 0 obj --- > %%BeginResource: file (PDF CharProc obj_710) > 710 0 obj 2/ I rebuilt from git, and that fixed the memory corruption crash with txtwrite. It makes a large file with a lot of whitespace, but I was running it only for testing. /tmp/ghostpdl/bin/gs -q -dSAFER -sDEVICE=txtwrite -o - 4244201-1.pdf > txt.txt -rw-rw-rw- 1 william william 5539 Jul 2 06:35 4244201-1.txt # pdftotext -rw-rw-rw- 1 william william 10694896 Jul 2 06:33 txt.txt # gs 3/ The git build continues to generate a pdf that is almost all black when I run it on the ps generated by pdftops -level3. I tested both Fedora's pdftops 0.73.0 and pdftops 0.89.0 that I built from source. pdftops -level3 4244201-1.pdf x3.ps ; /tmp/ghostpdl/bin/gs -sDEVICE=pdfwrite -o x3.pdf x3.ps I attached what happens when I view x3.pdf in gv. It also happens when I view it with gs built from git with the default x11 device. It shows the first screen, thinks for a bit, and then draws a lot of black. I think that x3.pdf (the output of gs pdfwrite) is bad (rather than just being displayed incorrectly) because it crashes atril. It also happens with Fedora's gs 9.27. x3.ps (the output of pdftops) views correctly in gv, so I think that it is ok. I forgot to say that I am doing 64 bit builds. $ file /tmp/ghostpdl/bin/gs /tmp/ghostpdl/bin/gs: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=aca7986ccfeaaf3a0b219d980b9f749f6ca480d9, for GNU/Linux 3.2.0, not stripped $ uname -a Linux laptop 5.6.19-200.fc31.x86_64 #1 SMP Wed Jun 17 16:54:35 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux $ gcc -v 2>&1 | grep Red gcc version 9.3.1 20200408 (Red Hat 9.3.1-2) (GCC) I see what you mean about the fonts. Thanks for explaining it. poppler pdffonts says that they are all "CID Type 0C" with "Identity-H". When I disassemble the original PDF, I can see sections like the one below. I think that CMapType 2 means a ToUnicode CMap. I am going to ask the people who made the PDF to try to save it with different options. I think that they used Quark. /CIDInit /ProcSet findresource begin 12 dict begin begincmap /CIDSystemInfo <</Registry (Berkeley-Black-OV-BHQHLP) /Ordering (CIDUCS) /Supplement 0 >> def /CMapName /Berkeley-Black-OV-BHQHLP def /CMapType 2 def 1 begincodespacerange <0000> <FFFF> endcodespacerange 2 beginbfchar <0001> <0066> <0002> <006F> endbfchar endcmap CMapName currentdict /CMap defineresource pop end end (In reply to William Bader from comment #6) > Created attachment 19398 [details] > viewing gs pdfwrite output in gv > 1/ I rebuilt from the gs 9.52 source distribution (without my build script), > and the file created by ps2write worked with pdfwrite. OK that's interesting, if you can isolate what the difference is I'll try and fix it. To be honest a different optimisation sounds unlikely to be a problem here, though anything is conceivable. > Comparing my build against a standard build with configure and make, the > build from my script seems to have added a color space. I am going to look > at it some more to be sure that it is something that I did wrong rather than > different compile options exposing a bug. The different numbering doesn't mean that a colour space was added, it may mean that the CharProc was lost. Object are numbered sequentially as they are encountered so either is possible (there can be 'holes' if we create an object then decide we don't need it, but this is rare). Of course once the numbering differs the remainder of the file is likely to differ. > 2/ I rebuilt from git, and that fixed the memory corruption crash with > txtwrite. OK so that most likely means it was the existing fix for a memory problem, thanks for trying that. > It makes a large file with a lot of whitespace, but I was running it only > for testing. The default format tries to match the layout of the original, by using space characters and newlines to reproduce it. You need to use a fixed pitch font to see the layout properly. The XML-ish output (TextFormat=0 or 1) does away with trying to fake the layout and just gives the characters and position. > 3/ The git build continues to generate a pdf that is almost all black when I > run it on the ps generated by pdftops -level3. I tested both Fedora's > pdftops 0.73.0 and pdftops 0.89.0 that I built from source. Could you open a different bug for this please ? Multiple different issues in the same bug are terribly difficult to track and tend to spiral on forever. I prefer to have each issue in its own report so I can close them when they are dealt with. I've been compiling with different options all day. The "Resource R713 is a shading, which can't be handled at level 2." error comes from -ffast-math. I can reproduce the error from the ghostscript 9.52 source tar with CFLAGS='-ffast-math' ./configure ; make /tmp/gs9.52/bin/gs -sDEVICE=ps2write -o out.ps 4244201-1.pdf ; /tmp/gs9.52/bin/gs -sDEVICE=pdfwrite -o out.pdf out.ps So ghostscript is fine, and the lesson is to avoid -ffast-math. I would have expected that if fast-math would fail, it would cause more subtle problems. Maybe it generated an impossible value for one of the shading parameters. I am going to create a new bug for the other issue if I can still reproduce it. -ffast-math sets -fno-math-errno -funsafe-math-optimizations -ffinite-math-only -fno-rounding-math -fno-signaling-nans -fcx-limited-range -fexcess-precision=fast The guilty party is the -funsafe-math-optimizations component. The problem happens with CFLAGS='-funsafe-math-optimizations' ./configure ; make According the the gcc 9 man page, -ffast-match is not turned on by any -O option besides -Ofast since it can result in incorrect output. I confirmed that the problem also happens with CFLAGS='-Ofast' ./configure ; make According to the gcc man page, -funsafe-math-optimizations "Allow optimizations for floating-point arithmetic that (a) assume that arguments and results are valid and (b) may violate IEEE or ANSI standards. When used at link time, it may include libraries or startup files that change the default FPU control word or other similar optimizations." I did runs of good and bad versions with -sDEBUG. They had only a few differences, probably due to different memory layouts. I need to update my build scripts not to use -Ofast or -ffast-math. (In reply to William Bader from comment #10) > The guilty party is the -funsafe-math-optimizations component. The problem > happens with Well I guess the clue is in the name :-) Thanks for the investigation, I'm going to close this bug report now as 'worksforme' (mostly because there doesn't seem to be a more appropriate resolution). Like you I am somewhat surprised that this doesn't cause more widespread problems in Ghostscript. For what its worth Chris (our build maintainer) says the he knows that significant additional optimisations cause us trouble; -O3 doesn't work for example. |
Created attachment 19389 [details] PDF to show the problem I have a pdf that when I run it through pdf2ps and then run the resulting ps through ps2pdf, ps2pdf fails with $ ps2pdf g1.ps g11.pdf GPL Ghostscript 9.52: It is not possible to preserve transfer functions in PDF 2.0 transfer functions will be applied instead Resource R713 is a shading, which can't be handled at level 2. %%[ Error handled by opdfread.ps : undefined; OffendingCommand: ....Undefined ]%% %%[STACK: 2 --nostringval-- /R713 --nostringval-- /R713 -mark- -mark- -mark- %%]% I am running gs on Fedora 31 Linux on x86_64. Fedora 31 has 9.27. The problem seems triggered by gs 9.52 pdf2ps which causes the same error in both gs 9.27 and 9.52 ps2pdf. The ps produced by gs 9.27 pdf2ps works with both gs 9.27 and 9.52 ps2pdf. Trying ps2pdf with various compatibility levels like ps2pdf -dCompatibilityLevel=2.0 does not help.