ghostscript-10.0.0

[Bruce Dubbs]

New major version.

[pierre]

Recent Changes in Ghostscript Version 10.00.0 (2022-08-18)

Highlights in this release include:

The big change in this release is that the old PDF interpreter (written in PostScript) is now fully deprecated. We will not be making any further changes to it. For this release, the -dNEWPDF=false option remains for "emergency" use, but the option to fall back to the old intepreter will also be removed in the next full release (10.01.0) in spring 2023.

So we once again encourage all users to test the new interpreter in their use cases, and report any problems.

The new PDF interpreter written in C has had several performance improvements. It was already quicker for the majority of cases than the PostScript implementation, but we found further improvements for common cases, and also several speed improvements in edge cases.

Our efforts in code hygiene and maintainability continue.

The usual round of bug fixes, compatibility changes, and incremental improvements.

(9.53.0) We have added the capability to build with the Tesseract OCR engine. In such a build, new devices are available (pdfocr8/pdfocr24/pdfocr32) which render the output file to an image, OCR that image, and output the image "wrapped" up as a PDF file, with the OCR generated text information included as "invisible" text (in PDF terms, text rendering mode 3).

Mainly due to time constraints, we only support including Tesseract from source included in our release packages, and not linking to Tesseract/Leptonica shared libraries. Whether we add this capability will be largely dependent on community demand for the feature.

See ​Enabling OCR for more details.

[Xi Ruoyao]

The test command gs -q -dBATCH /usr/share/ghostscript/10.00.0/examples/tiger.eps does not work for me... Not sure if I've done something wrong.

[Xi Ruoyao]

With Ghostscript-9.56.1, I have:

gs -h | grep x11:

Default output device: x11alpha
   tiffscaled8 tiffsep tiffsep1 txtwrite uniprint urf x11 x11alpha x11cmyk
   x11cmyk2 x11cmyk4 x11cmyk8 x11gray2 x11gray4 x11mono xcf xes xpswrite

With 10.0.0:

gs -h | grep x11: nothing

[pierre]

Replying to Xi Ruoyao:

With Ghostscript-9.56.1, I have:

gs -h | grep x11:

Default output device: x11alpha
   tiffscaled8 tiffsep tiffsep1 txtwrite uniprint urf x11 x11alpha x11cmyk
   x11cmyk2 x11cmyk4 x11cmyk8 x11gray2 x11gray4 x11mono xcf xes xpswrite

With 10.0.0:

gs -h | grep x11: nothing

Maybe this ​bug is relevant, but not sure

[Xi Ruoyao]

Replying to pierre:

Replying to Xi Ruoyao:

With Ghostscript-9.56.1, I have:

gs -h | grep x11:

Default output device: x11alpha
   tiffscaled8 tiffsep tiffsep1 txtwrite uniprint urf x11 x11alpha x11cmyk
   x11cmyk2 x11cmyk4 x11cmyk8 x11gray2 x11gray4 x11mono xcf xes xpswrite

With 10.0.0:

gs -h | grep x11: nothing

Maybe this ​bug is relevant, but not sure

I don't think they are the same, and I created ​https://bugs.ghostscript.com/show_bug.cgi?id=705895.

--disable-hidden-visibility can workaround the issue.

[Xi Ruoyao]

The upstream suggests to remove --enable-dynamic.

[Xi Ruoyao]

Replying to Xi Ruoyao:

The upstream suggests to remove --enable-dynamic.

And it works for me.

[pierre]

After discussing whith Xi Ruoyao: upstream has changed to hidden visibility because they had conflicts with symbols defined in other libraries. Removing --enable-dynamic allows to include the X11 library into the gs executable, so symbol visibility is not a problem anymore.

[pierre]

Fixed at 680a059706.

[pierre]

dvisvgm FTBFS with:

libtool: link: g++ -Wall -Wnon-virtual-dtor -I../libs/clipper -I../libs/variant/include -I/opt/texlive/2022/include -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I../libs/xxHash -g -O2 -Wno-mismatched-tags -o dvisvgm dvisvgm.o  -L/opt/texlive/2022/lib ./.libs/libdvisvgm.a ../libs/clipper/libclipper.a -lfreetype ../libs/xxHash/libxxhash.a ../libs/ff-woff/libfontforge.a -lwoff2enc -lbrotlienc -lcrypto -lz -lpotrace -lgs -lkpathsea
/usr/bin/ld: ./.libs/libdvisvgm.a(Ghostscript.o): in function `Ghostscript::error_name(int)':
/sources/dvisvgm/dvisvgm-2.14/src/Ghostscript.cpp:382: undefined reference to `gs_error_names'
collect2: error: ld returned 1 exit status

[pierre]

Can be fixed with:

sed "s/gs_error_names\[/error_names[/" -i src/Ghostscript.cpp

This is what is done in Win32 builds anyways. And according to the changelog, using gs_error_names only prevents including the error strings in the binary (who cares?)

Reported upstream: ​https://github.com/mgieseki/dvisvgm/issues/195

[Xi Ruoyao]

Replying to pierre:

Can be fixed with:

sed "s/gs_error_names\[/error_names[/" -i src/Ghostscript.cpp

This is what is done in Win32 builds anyways. And according to the changelog, using gs_error_names only prevents including the error strings in the binary (who cares?)

Reported upstream: ​https://github.com/mgieseki/dvisvgm/issues/195

Another visibility-related issue. I'm not sure if it's an intentional change in Ghostscript or oversight. I've asked Chris in the Ghostscript ticket.

AFIAK Windows uses a default setting similar to -fvisibility=hidden for their DLL. They have __dllspec(export) which is similar to our __attribute__((visibility("default"))). So I guess this issue showed up on Windows much earlier and they've worked around (or fixed, depending on whether it's intentional or oversight on Ghostscript side) it.

[pierre]

I think gs_error_names has always be meant to be private: it is not in the gserrors.h file, and the header that reference it is ierrors.h, and it is said:

/*
 * DO NOT USE THIS FILE IN THE GRAPHICS LIBRARY.
 * THIS FILE IS PART OF THE POSTSCRIPT INTERPRETER.
 * USE gserrors.h IN THE LIBRARY.
 */