| | <<<Back 1 day (to 2018/07/11) | 20180712 |
| yepi | HI everyone. | 09:18.15 |
| | I want to use ghostscript api with gsapi_set_display_callback. I am interested in rastering a postscript file in small pieces, in order to process one part at time (with few memory ^^). I am looking to the callback "display_update", but i d'ont know how it is call or even if it is what i need ? Any information or advice are welcome :D | 09:18.26 |
| kens | IIRC display_update is called intermittently by Ghostscript itself | 09:19.03 |
| | Hmm, maybe not | 09:21.27 |
| | I cna't see it being called anywhere | 09:21.37 |
| chrisl | "small pieces" is not a very clear description | 09:21.54 |
| kens | Oh and interpreting the PostScript in smal chunks doesn't decrease the amount of memory that will be used. | 09:22.30 |
| chrisl | First stop would be: https://www.ghostscript.com/doc/9.23/API.htm#display | 09:22.55 |
| kens | If you want to minimise the memory usage then you need to use a display list, which renders horizontal bands of the page | 09:22.59 |
| | NB a display list (clist in GS terms) is nothing to do with the display device, desptie the name.... | 09:23.46 |
| chrisl | Rather the opposite: the display device *cannot* use the clist | 09:24.10 |
| yepi | "small pieces" i want line or stripe of my file | 10:02.38 |
| kens | You cannot do that with the display device. | 10:02.50 |
| | In order to produce the rendered page in horizontal stripes (or bands) you must use the Ghostscript clist, which you cannot do with the display device. | 10:03.21 |
| | What is you final target output ? | 10:03.31 |
| yepi | d'ont use display device is not a problem if i can access to this raster stripe. | 10:04.18 |
| kens | Again, what do you plan to do with the output ? | 10:04.41 |
| yepi | i want rgba | 10:05.07 |
| kens | Then use the PNG device | 10:05.21 |
| | pngalpha actually I think | 10:05.50 |
| yepi | How access to the stripes, during the process ? | 10:06.32 |
| kens | Why do you want to ? | 10:06.39 |
| yepi | actualy i use ghostscript to create my raster file and i process change some pixels... I want to do it during the raster process | 10:07.52 |
| kens | Then you need to write your own device. I would suggest that you start with the pngalphs device since that is (I htink) close to what you want. | 10:08.21 |
| | Is this for an open source project ? Is there a website for it I can look at for more details ? | 10:09.04 |
| yepi | not an opensource projet, i am applying simple changes on realy big picture (over 30k dpi) | 10:10.21 |
| kens | Well the answer is the same. You will need to write your own Ghostscript device | 10:10.51 |
| yepi | i will look at it ^^^ | 10:11.12 |
| | thanks for your help | 10:11.37 |
| kens | NP | 10:11.41 |
| yepi | bye, have a nice day :D | 10:12.36 |
| Robin_Watts | yepi: One thing, before you launch into it... | 10:17.33 |
| | If you *aren't* open source, then we have to ask whether this is just a personal project, or whether you're hoping to either distribute the end result, or put it on a server so people can use it. | 10:18.44 |
| | Either way, that would count as "distribution" under the terms of the GNU AGPL. | 10:19.21 |
| | If you're not prepared to give away your source to anyone who uses your software then you can't use the GNU AGPL. | 10:19.44 |
| | So you'd need a commercial license. | 10:19.53 |
| | I'd really advise you to find out about the cost of a commercial license before you invest too much time into writing stuff. | 10:20.28 |
| yepi | Robin_Watts: for now it's juste an experimentation. If it works, it's not a problem to share it. It might be not realy interesting for others :D | 14:59.58 |
| ray_laptop | I saw the discussion on the logs. I wanted to mention that all devices (including the display device) can use a clist IFF the page uses transparency and the ESTIMATED pdf14 transparency buffer stack exceeds the MaxBitmap parameter | 15:08.03 |
| | now that we have (thanks to kens) subclass devices, we may want to move that hack into a subclass device so it applies even for non-transparent pages | 15:09.09 |
| kens | I think that the proper memory device would be a better way to go for general purpose use | 15:09.32 |
| ray_laptop | See the log for commit 4e44c995 | 15:09.34 |
| kens | Rather than trying to bend the display device | 15:09.50 |
| ray_laptop | kens: The IJS device _is_ a printer class device, so it can also be used | 15:10.20 |
| | I agree that trying to use the display device is not a good way to go for yepi | 15:11.00 |
| kens | I'm simply saying that this is more weight to Chris's argument that we need a printer device which can return the bitmap in memory, for people who want to do tht. But without bending the disply device in ways it wasn't originally intended | 15:11.17 |
| | Its not the only time we've been asksed about it, either on Bugzilla or here | 15:11.44 |
| | If anything ther requests are getting more frequent | 15:11.58 |
| | And writing your own Ghostscript device is a lot of work, and fairly daunting | 15:12.16 |
| ray_laptop | and making/extending the IJS device to support a function call/callback interface rather than pipes would be a simple way to get a "memory" device (it has the desired simplified parameter methods) | 15:12.26 |
| | kens: for folks that don't want to do a device, steer them toward the IJS interface. | 15:13.09 |
| kens | I know nothing about the device, so I cannot really comment, but in general I would prefer not to repurpose an existing device. | 15:13.22 |
| ray_laptop | it's a LOT simpler than doing a gs device | 15:13.35 |
| | kens: it is intended to let processes get raster data and then process it. As I see it, it is NOT re-purposing, since that IS its purpose | 15:14.35 |
| kens | Well then why is it called 'IJS' and nont 'memory' o something | 15:14.56 |
| chrisl | It has massive security issues, though..... | 15:15.07 |
| ray_laptop | I mentioned it to chrisl a few weeks back | 15:15.09 |
| | maybe NancyDurgin can suggest security fixes for it :-) (the IJS spec has been around a long time, so it might be time for an update | 15:18.03 |
| | chrisl: yes, the security issues are mentioned in https://www.ghostscript.com/doc/current/Devices.htm#IJS but a function call interface (staying within a process, not connecting to a "server") would not have those issues | 15:19.04 |
| kens | But then it wouldn't be an IJS client any more | 15:20.03 |
| chrisl | ray_laptop: yeh, but at the moment, pointing people at IJS gets them out of the complexity of writing a gs device, into Unix IPC and the security concerns..... | 15:20.32 |
| | I agree that something based on the IJS standard is probably a good direction, though | 15:21.12 |
| ray_laptop | kens: the spec is really ancient: https://www.ghostscript.com/doc/ijs/ijs_spec.pdf I don't think anyone has ever updated it (google doesn't find one) | 15:24.12 |
| Robin_Watts | cp gdevijs.c gdevnewthing.c, hack on gdevnewthing.c | 15:24.26 |
| ray_laptop | The openprinting org would be the ones to see | 15:24.38 |
| kens | Yes, certainly, but its not IJS then, that's my only point | 15:24.47 |
| ray_laptop | kens: extending IJS to IJS 0.40 doesn't mean we have to re-invent round things to make dragging carts easier | 15:25.40 |
| kens | I htink it would be better to have a new device, people are not really going to understand why we point them at an 'IJS' device when they want an 'in memory' device | 15:26.31 |
| Robin_Watts | So "Using the IJS device as a basis for a new device", might be a proposal that would be more palatable to everyone than "modifying ijs". | 15:26.38 |
| kens | Even if they can find the IJS specification and a Google for IJS is not helpful) then they're simply going to be horrified by a client/server model | 15:26.53 |
| | Robin_Watts : yes, I think that's what both Chris and I have said before | 15:27.20 |
| Robin_Watts | ray_laptop: How do you feel about that? It would have the advantage of us not having to worry about ripping out the security risk stuff from the existing device and breaking backwards compatibility. | 15:28.35 |
| chrisl | One other concern I have about IJS is that it only allows setting/retrieving one parameter value at a time - given our get/put_params that could be expensive | 15:31.32 |
| ray_laptop | chrisl: I agree that something that would let someone set a bunch of parameters from a list makes sense | 15:41.19 |
| | Robin_Watts: A new device is reasonable -- I just think we should take advantage of the ideas (and maybe some of the code) in the IJS device, since that is a reasonably simplified model for a device | 15:42.31 |
| | chrisl: as far as a list of parameters, we'd want a way for a device to identify which parameter(s) in the list failed (or at least the first one that fails) for returning that info in configuration error | 15:44.16 |
| | and presumably the device would follow the model that it does not apply ANY of the parameters in a list unless they all succeed (a concept required by setpagedevice, but hard for implementors to grok) | 15:45.51 |
| | the set one parameter at a time lets the internal part of the device (the ijs_client code) hide that from the server implementor | 15:47.04 |
| | chrisl: note that calling with one parameter at a time doesn't mean that our internal part can't handle the full param list and just make multiple calls and it might simplify it for a customer doing their part | 15:49.07 |
| | Forward 1 day (to 2018/07/13)>>> | |
Log of #ghostscript at irc.freenode.net.