| | <<<Back 1 day (to 2015/03/26) | 20150327 |
| kens | Apparently Michael has been with Artifex 7 years today (LinkedIn tells me), so congratulations :-) | 08:18.06 |
| chrisl | Hmm, the opvp/oprp device is a complete mess - I'd go so far as to say it's totally broken from a Postscript perspective...... | 09:44.01 |
| kens | THat's unfortuneate, isn't that one of the ones Till said they 'needed' ? | 09:44.20 |
| chrisl | Yes, and TBH, for most *Ghostscript* uses, it's probably fine. But *huge* amounts of it's internal state is stored in global variables | 09:45.04 |
| kens | Oh, that's not good. | 09:45.25 |
| chrisl | So doing a setpagedevice from Postscript could potentially have unexpected and horrid side effects..... | 09:46.02 |
| kens | Well the PDF interpreter, at least, does setpagedevice | 09:46.30 |
| chrisl | Yes, but the PDF interpreter should only tweak the configuration of the existing device, not install a new one | 09:47.03 |
| kens | Yes, that's true | 09:47.10 |
| | OK I think I have a fix for Zoltan's problem, for some reason best known to whoever write it, resolvestream doesn't reposition the underlying PDFfile pointer after it reads the stream, and the type 6 halftone code wasn't taking steps to save and restore it. (which, in fairness resolvestream comments say it must) | 09:49.06 |
| chrisl | The biggest and most obvious issue is that the global state includes whether the code is being called as the opvp (vector) device, or the oprp (raster) device - so if you set one at the command line, gsave then set the other from the Postscript job, then grestore, the state will be wrong after the gresore | 09:49.33 |
| kens | Oh yeah, that would be *really* bad | 09:49.49 |
| | If unlikely I guess | 09:49.55 |
| chrisl | Nevertheless, it should *never* have been included in our distro in that state | 09:50.31 |
| kens | Well we've obviously been less than careful about contributed devices in the past | 09:50.55 |
| chrisl | And, of course, it makes it a *huge* 'mare to try to make it thread safe which, as it happens, would also fix it from a PS perspective, too | 09:52.21 |
| henrys | more pcl bugs ... things are getting exciting around here ;-) | 16:02.06 |
| kens | Gives you something to do :-D | 16:02.25 |
| henrys | gullaume is always good for a room size plot to my get my computer thrashing... | 16:05.38 |
| Robin_Watts | aargh. | 16:17.27 |
| | I think MuPDF's transparency handling is horribly broken, for knockout groups at least. | 16:17.48 |
| | In general, all our rendering routines (for paths etc) do standard 'dumb' blending; we take a background and we antialias blend our new rendered object onto it. | 16:18.43 |
| | For that, we use the standard linear blending operation. | 16:18.59 |
| | When we come to a transparency group, we copy a section of the render bitmap to use as a 'background'. | 16:19.57 |
| | We then render onto that. | 16:20.16 |
| | When we close the group, we examine every pixel on the thing we rendered. | 16:21.24 |
| | We 'unpick' the standard blend, and then redo the fancy blend. | 16:21.47 |
| | But for knockout groups, there are 2 levels of stored backdrop. | 16:24.22 |
| tor8 | Robin_Watts: don't blame me :) | 16:28.27 |
| | though I think that is the same approach I've seen in gs | 16:28.35 |
| Robin_Watts | gs is even more confusing than mupdf. | 16:28.49 |
| | A new event for Henry: http://www.redbull.com/uk/en/adventure/events/1331668145513/red-bull-neptune-steps | 18:27.28 |
| henrys | Robin_Watts: that does sound like fun. | 18:28.27 |
| Robin_Watts | To make it more interesting the locks should start to slowly empty as soon as half the field has made it across each one. | 18:30.50 |
| henrys | like being a human salmon ! | 18:34.26 |
| mvrhel_laptop | ok. I finally have most of ken's comments fixed. now, I can finally see if I can replicate his issues with printing and the crash that he was seeing | 21:19.12 |
| GUIpsp | hey, I found a small typo in the source, but it's in debug code so I don't think it's worth it to make a patch just for this small typo | 22:16.19 |
| | http://git.ghostscript.com/?p=ghostpdl.git;a=blob;f=gs/toolbin/headers.tcl;h=64a428cb4fbc23136ad1166220f467b7891e9ca6;hb=HEAD#l91 | 22:16.23 |
| | Forward 1 day (to 2015/03/28)>>> | |
IRC Logs