| | <<<Back 1 day (to 2022/06/01) | Fwd 1 day (to 2022/06/03) >>> | 20220602 |
| artifexirc-bot | <qwertynik> Had been using -dFILTER* options to generate PDF with desired content types. | 09:36.41 |
| | <qwertynik> -dFILTERTEXT -DFILTERIMAGES would give a PDF with all vectors. Is there a way to generate a PDF with only a specific set of vectors drawn? | 09:36.41 |
| | <qwertynik> @here | 09:36.45 |
| | <Robin_Watts> Define 'specific set' ? | 09:53.25 |
| | <Robin_Watts> Short answer is, I suspect, no. Long answer is, anything is possible with open source, but you'd need to hack the C. | 09:54.41 |
| | <qwertynik> Based on the seqno of the paths/vectors | 10:03.10 |
| | <Robin_Watts> seqno is not a PDF concept. | 10:03.37 |
| | <Robin_Watts> You mean you want to be able to say "include all the vectors between the 1000th you see, and the 2000th you see", say? | 10:04.15 |
| | <qwertynik> Thinking if this would be possible using js passed to mutool run. Haven't yet found anything yet though. | 10:04.27 |
| | <KenSharp> The answer is, simply, no. You could extend the code if you wished, but we won't make any attempt to do so. | 10:05.16 |
| | <KenSharp> No idea about MuPDF | 10:05.27 |
| | <qwertynik> Sure. For MuPDF, will ask in the relevant forum | 10:05.53 |
| | <qwertynik> Hmm, ok. Is there any JS/Python SDK/Wrapper available for Ghostscript? | 10:06.32 |
| | <qwertynik> Yes. The number could be anything. Draw all except 10-20 (based on seqno) | 10:07.13 |
| | <KenSharp> Ghostscript has it's own API you can call it from a number of different languages. There's a C# wrapper and a .NET wrapper (neither from us) and there's a set of bindings we do supply but I don't know what they support. | 10:07.29 |
| | <Robin_Watts> MuPDF has the concept of PDF processors. | 10:07.38 |
| | <Robin_Watts> One of those PDF processors is a filter. | 10:07.50 |
| | <KenSharp> In any event, none of them will help you achieve this with Ghostscript. The vector filtering is done by a subclassing device written in C and that's what you would need to modify. | 10:07.56 |
| | <chrisl> There are python bindings for Ghostscript, but only for the official, public API | 10:08.02 |
| | <Robin_Watts> It'd be easy to write a new PDF processor to filter in the way you describe. | 10:08.16 |
| | <Robin_Watts> but it would (I believe) require C coding. | 10:08.39 |
| | <qwertynik> Ok, so based on what is mentioned, bindings/wrappers will not help. And for the use case at hand new PDF processor in C needs to be written. | 10:10.07 |
| | <qwertynik> Would this then require building Ghostscript on own? | 10:10.25 |
| | <KenSharp> For MuPDF you need to write a processor, for Ghostscript you could extend the existing device | 10:10.35 |
| | <Robin_Watts> No. Not GS. MuPDF. | 10:10.36 |
| | <KenSharp> And yes, you would need to rebuild Ghostscript | 10:10.51 |
| | <qwertynik> Ok. Thanks for the confirmation. Any tutorial/documentation link to build a PDF processor? | 10:12.10 |
| | <KenSharp> You can't do that in Ghostscript, that's a MuPDF question | 10:12.31 |
| | <KenSharp> For Ghostscript you need to look at the relevant device, I can find that for you if need be. | 10:12.53 |
| | <qwertynik> Sure, that would help me understand the effort it would take to build it. | 10:14.41 |
| | <KenSharp> Building GS is easy, there's a makefile autotools and a solution for Windows. THe code implementing the object filtering (all three types) Is in /ghostpdl/base/gdevoflt.c | 10:16.07 |
| | <KenSharp> Essentially every drawing operation is classified as either vector, text or image. Then the relevant flag is consulted whenever an operation takes place. If we are filtering images, and the current operation is an image, we just return without drawing. And similarly for the other operations | 10:17.20 |
| | <qwertynik> Ok. Sounds straight forward. | 10:18.17 |
| | <qwertynik> Yes. Had built it locally on WSL2. However, when doing it on server, not sure how to move the executables alone. Because on the server, having the build related packages installed is not essential. | 10:19.13 |
| | <KenSharp> For both MuPDF and Ghostscript, you should read the licence before embarking on any project involving altering the code. | 10:20.22 |
| | <qwertynik> Yes, given that it is AGPLv3 this makes sense. Certainly there could be more. But at the outset, assuming that new processor's code will need to be shared. | 10:21.33 |
| | <KenSharp> As long as you understand the licence no problem, we like to flag this up early so nobody wastes their time on an unacceptable licence limitation | 10:22.13 |
| | <qwertynik> Yes, that helps. Thanks for bringing it up. Not that I will hold the response, in this case, writing a processor would require to share it with the Ghostscript team correct? | 10:23.54 |
| | <KenSharp> You wouldn't need to share anything with us perse, no matter what. You would need to publish the code so that other users could use it. Mainly so that anyone using the binary would be able to modify it later. | 10:24.58 |
| | <KenSharp> You wouldn't need to share anything with us per se, no matter what. You would need to publish the code so that other users could use it. Mainly so that anyone using the binary would be able to modify it later. | 10:25.09 |
| | <Robin_Watts> If you modify the code and then distribute the compiled version, you have to make the source available to anyone who receives it. (And for the AGPL 'Distribute' includes 'make available as a service'). | 10:25.32 |
| | <chrisl> If you're targetting a server, you'll probably want to build without the X11 devices. Ideally, you'll want to be building on the same distro version as the server, so all the library versions match up. Or, if supported, build it as a snap. | 10:26.20 |
| | <qwertynik> Although extension/modification of the code is not planned yet, can you link to how the code should be *published*? Should it be done on GitHub? | 10:27.50 |
| | <KenSharp> TBH it simply has to be available on request, but Github is reasonable I guess. | 10:28.27 |
| | <KenSharp> I believe that the documentation should at least say where the code can be obtained, whether that be by a letter to the autour or a URL to Github isn't specified | 10:29.11 |
| | <KenSharp> I believe that the documentation should at least say where the code can be obtained, whether that be by a letter to the author or a URL to Github isn't specified | 10:29.24 |
| | <qwertynik> Hmm, ok. Makes sense. Assuming putting it on Github would be essential. Otherwise it would be difficult to know which user made what changes. | 10:32.14 |
| | <qwertynik> ie: For instance, how would one know the list of users who have modified the library code. | 10:34.09 |
| | <qwertynik> So would building on distro same as server and then transferring the executables alone help? Not an expert in building packages, but had come across the concept of dynamic linking - which makes an executable not usable unless the linked packages are also deployed. | 10:35.51 |
| | <chrisl> @qwertynik As long as the dependencies are installed on the server (which they ought to be if gs is already there), then the binaries will work after being copied across | 10:39.35 |
| | <qwertynik> But wouldn't there be a version mismatch? Or, one will need to use GS version that's available on server and then rebuild it after modifying. And this may not be ideal. | 10:44.07 |
| | <Robin_Watts> If you build a version of gs on one machine and expect to be able to move the binary to a second machine, then yes, you need to ensure that any dynamic libs that you depend on match on both machines. That's just the way stuff works. | 11:00.36 |
| | <qwertynik> Yes. Probably at the cost of build generation time, is generating a purely static build possible? | 11:07.26 |
| | <Robin_Watts> @qwertynik By default, as supplied with our source, I believe we build purely(\*) static builds. (\* the exception being the C lib itself). | 11:30.00 |
| | <qwertynik> Ok that sounds good. So copying across servers of same version should work I assume. | 11:31.53 |
| | <Robin_Watts> Generally, yes, but this is sounding like Unixy questions rather than Ghostscripty ones. | 11:39.59 |
| | <qwertynik> Yes, it does. Asked to know from Ghostcript point of view. | 11:48.35 |
| | <qwertynik> With this message, itt is clear now. | 11:48.45 |
| | <<<Back 1 day (to 2022/06/01) | Forward 1 day (to 2022/06/03)>>> | |
Log of #ghostscript at irc.freenode.net.