| | <<<Back 1 day (to 2017/11/20) | 20171121 |
| janzo | so i tried to flatten my pdf using pdf2ps > ps2pdf, but it created a bunch of type 3 fonts. can i avoid that? | 03:52.46 |
| | my goal is to flatten a pdf to just images | 04:25.35 |
| pipitas | janzo: In your pipeline: ps2pdf has output before input. Try "pdf2ps in.pdf - | ps2pdf - out.pdf". | 06:10.08 |
| kens | janzo you can't do what you are trying to achieve the way you are going about it. Both PDF and PostScript output will attempt to preserve as much of the original content as possible. SO you won't get any images. | 08:11.19 |
| | If you want a PDF which solely consists of an image then right now you need to first render the input to an image, then read the bitmap format back into Ghostscritp and produce a PDF file using pdfwrite. | 08:11.56 |
| | The viewpbm.ps file in ghostpdl/lib can be used to read .pbm format bitmaps, so if you first render to PBM and then read teh individual .pbm files back into Ghostscript then you can produce an 'image only' PDF file. | 08:13.28 |
| | Or you could probably achieve the same thing using ImageMagick. | 08:13.38 |
| deekej | chrisl, kens: Hello guys, I'm trying to create the ghostscript RPM package from scratch for Fedora now, so it's as close to vanilla build as possible. But there are few things I don't understand. | 09:40.50 |
| kens | OK..... | 09:41.02 |
| deekej | Previous maintainers were for some unknown reason using libxml2 library when building Ghostscript | 09:41.22 |
| kens | Ummmm, for what ? | 09:41.39 |
| deekej | but I don't see it being required/needed anywhere in ./configure output | 09:41.41 |
| | well, that's my question - I guess it ended up there just by a mistake | 09:41.57 |
| kens | We've never (as far as I know) had a dependency on it | 09:42.00 |
| deekej | ok, that asnwers my question :) thanks | 09:42.13 |
| kens | YW :) | 09:42.25 |
| deekej | however, fontconfig and DBus are useful for ghostscript, am I right? | 09:42.42 |
| kens | fontconfig can be (maybe) What is DBus ? | 09:43.03 |
| chrisl | dbus is needed for cups | 09:43.28 |
| kens | Oh right | 09:43.32 |
| deekej | ah, ok | 09:43.34 |
| | kens: dbus is message bus system, where each software can "register" and listen on that bus for messages | 09:44.03 |
| chrisl | I suspect libxml2 might be required by fontconfig | 09:44.08 |
| kens | Yeah I had found the wiki | 09:44.11 |
| deekej | *system wide messages | 09:44.12 |
| | chrisl: thanks for suggestion, I'll check that | 09:44.29 |
| chrisl | The fact they are explicitly checked for suggests a (probably long resolved) problem with the dependencies of cups/fontconfig etc | 09:45.29 |
| deekej | ok, so looking at configure.ac, the test for XML is currently being run only when "with_xps" is true. AFAIK, XPS is (no longer?) part of ghostscript | 09:50.48 |
| kens | well, its part of the family | 09:51.05 |
| | but its a different executable | 09:51.11 |
| | I still don't think we have it as a dependency though | 09:51.32 |
| deekej | What I meant is that the ghostscript-only source code does not contain xps/ folder, so XPS wouldn't build for me anyway. :) In this case there's no need for the XML to be used for build process. :) | 09:53.11 |
| chrisl | For xps we use expat | 09:53.19 |
| kens | For Ghostscript (as opposed to GhpstPCL and GhostXPS) there's certainly no requirement, and as Chris says we use expat anyway.... | 09:53.46 |
| deekej | chrisl: yes. I see that XML is being checked if the expat is not found :) | 09:53.47 |
| kens | Hmm, I doubt that anything except expat would work, but I could be wrong | 09:54.10 |
| chrisl | I don't see anywhere in configure.ac we check for any XML library other than expat | 09:54.47 |
| deekej | chrisl: configure.ac:1300 [at latest master in git] | 09:55.47 |
| | chrisl: or I could be interpreting it wrong | 09:56.06 |
| chrisl | That's expat | 09:56.07 |
| deekej | ah, ok | 09:56.29 |
| chrisl | We're checking for the XML_ParserCreateNS() function in the expat library | 09:56.34 |
| | After which we check for the expat.h header - which seems the wrong way 'round, but hey-ho | 09:57.44 |
| | I'm just going to grab a coffee - back in a few minutes...... | 09:58.27 |
| deekej | I'm trying to figure out if the X driver should be shipped with ghostscript binaries by default or not. I've read in docs that it is useful for native X11 fonts, but is it also useful when doing "just" some conversions where nothing is displayed via GUI (e.g. ps2pdf)? | 11:47.30 |
| kens | You don't need the X device(s) when using the pdfwrite or ps2write devices (or any devices except the X devices, obviously) | 11:48.13 |
| chrisl | We don't use the "native" font integration any more - it was removed a few years ago | 11:50.27 |
| deekej | ah, okay. In that case it make sense to ship the X driver as a separate (and optional) package for users | 11:51.40 |
| chrisl | Generally, IIRC, most distros do two packages, "gs" and "gsx" - gsx includes the X11 device(s), and will replace the "gs" package when installed | 11:52.51 |
| deekej | I'm trying to figure out the thought processes of previous maintainer here... :-/ He created many packages, where one of them was just ghostscript, one of them was x11 driver, and one of them was gtk-based (gsx) | 11:54.54 |
| | the X11 and GTK were not shipped as one package, though | 11:55.09 |
| chrisl | Well, they are different..... | 11:55.26 |
| | The GTK one uses GTK to display output from the display device, whilst the X11 one interacts directly with X | 11:56.26 |
| | Oh, the ghostscript-x11 package relies on dynamic loading of the X11 devices | 11:58.19 |
| deekej | that makes sense. So for GKT-based the user has to use the 'gsx' binary, while for X11-based ghostscript the 'gs' should be enough, right? | 11:58.51 |
| chrisl | Yes. For the dynamic loading of the X11 devices, there's a build flag that needs setting | 12:00.21 |
| | --enable-dynamic | 12:00.55 |
| deekej | What would happen if I would replace the gs binary with gsx? Would the conversion scripts like ps2pdf still work? | 12:02.46 |
| | other distros probably use some symlink magic for this I guess | 12:03.21 |
| chrisl | Yes, all that would happen is the default device would change - but that probably isn't desireable | 12:03.24 |
| deekej | IMHO it isn't | 12:03.47 |
| chrisl | No, other distros include gs and gsx executables, not links | 12:04.09 |
| deekej | I would like to have the ghostscript as close to vanilla build | 12:04.21 |
| | ok | 12:04.27 |
| chrisl | The exes are tiny because they link to the .so | 12:04.56 |
| deekej | chrisl: does this package layout make sense? https://pastebin.com/tnDyHegf | 12:19.14 |
| | it's just a proposal | 12:19.26 |
| | I'm especially wondering about the ghostscript-utils - should it be part of the ghostscript, or does it make sense to you for these utilities to be a subpackage? (could it break anything?) | 12:20.08 |
| chrisl | We generally try to discourage use of the utils in lib/ *but* AIUI, most of the time they are packged with ghostscript so, again, it might confuse users if that changes | 12:22.18 |
| | Also, you might want to be selective about what you include from lib/ | 12:22.50 |
| | Personally, I might consider doing a libgs package, but that may be unnecessary complication | 12:24.22 |
| | deekej: Oh, and I think most folks package ijs separately | 12:30.59 |
| | back in a couple of hours | 12:48.58 |
| deekej | guys, who is currently responsible for development/maintaining of IJS source code? is it Artifex? | 14:56.39 |
| | I saw this: http://www.openprinting.org/download/ijs/ | 14:56.46 |
| chrisl | deekej: we are (unfortunately) the canonical "source" for the ijs code - but it is not really actively maintained (on the basis that it hasn't needed anything!) | 15:21.29 |
| deekej | chrisl: I have found out that we have HPLIP (HPIJS) in Fedora as well. Is it better to build Ghostscript against HPIJS or just IJS? | 16:00.08 |
| chrisl | Um, I thought HPIJS was just the server (or client, I can't remember which way round the IJS logic works) | 16:02.11 |
| deekej | I was just following what was written on the webpage - that the HPIJS should be compatible with IJS clients | 16:04.35 |
| | I really don't know much more about it :-/ | 16:04.43 |
| chrisl | Right, so when you build gs against IJS, gs includes a device which is an IJS client. | 16:05.13 |
| | You can then have the gs IJS client connect to the HP IJS server to print to an HP printer | 16:05.59 |
| | Forward 1 day (to 2017/11/22)>>> | |
Log of #ghostscript at irc.freenode.net.