| | <<<Back 1 day (to 2015/10/25) | 20151026 |
| Robin_Watts | TTOTD: When you have a bad back, do not a) manhandle a washing machine around, and then b) go out for food and a film without remembering to take a painkiller with you. | 12:23.14 |
| tor8 | Robin_Watts: I've uploaded the release candidate source and windows binary and updated the news page. | 12:55.18 |
| | I ran into some trouble building the 64-bit windows release; some of the targets don't compile :( | 12:55.42 |
| Robin_Watts | openssl ones? | 12:57.22 |
| tor8 | Oh, it's just skipping over the new projects I added. | 12:59.06 |
| Robin_Watts | has physio appointment at 3:30, so will be heading out at 3:15ish. | 13:03.29 |
| ismail | is there a high resolution mupdf icon somewhere? (to use in a linux package, desktop menu) | 13:14.52 |
| henrys | uh oh the dreaded time change... | 13:50.21 |
| | we change next week. | 13:50.42 |
| kens | We changed on Sunday | 13:50.49 |
| | Its now 13:48 | 13:50.59 |
| henrys | yup | 13:51.01 |
| | being an hour early for the meeting is better than an hour late ;-) | 13:52.43 |
| kens | Well, we'd generally be here anyway | 13:53.02 |
| tor8 | ismail: http://ghostscript.com/~tor/mupdf-simplified-logo.png | 14:09.08 |
| | ismail: in the source, in 'platform/ios/iTunesArtwork2.png' might also work for you | 14:09.57 |
| | but that has the typical iOS rounded corners | 14:10.06 |
| mvrhel_laptop | we need to change the time earlier here | 14:10.06 |
| | its pitch black when the kids walk to school | 14:10.15 |
| | since its raining and they have projects to carry in I am going to be a nice guy and drive them though | 14:10.45 |
| kens | :-) | 14:11.16 |
| mvrhel_laptop | henrys: so I am going to spend a little time working on http://bugs.ghostscript.com/show_bug.cgi?id=696290 this week. | 14:12.18 |
| henrys | mvrhel_laptop: we need to not change the time at all. | 14:41.07 |
| | http://www.petition2congress.com/6284/end-daylight-savings-time | 14:43.39 |
| | mvrhel_laptop: I think the candy industry lobbied to get it before halloween, unbelievable. | 14:46.27 |
| | s/before/after | 14:46.39 |
| mvrhel_laptop | I do like it in the summer around here though with the time change. otherwise it would be light at 3am | 15:05.18 |
| henrys | an interesting proposal is to have pacific and central be on dst and mountain and eastern on standard resulting in 2 time zones in the US separated by 2 hours. Your monday morning brain stimulation ... | 15:05.53 |
| Robin_Watts | goes to physio. back in a bit. | 15:07.08 |
| tor8 | henrys: if spain can share a time zone with poland despite lying to the west of britain ... | 15:09.16 |
| | henrys: what about alaska and hawaii in that proposal? | 15:09.27 |
| henrys | tor8: I'd really be fine with almost any reasonable proposal that didn't change the damn clocks. Presumably something that optimized energy savings would be best | 15:10.35 |
| tor8 | henrys: the biggest "problem" is the fixation on keeping 9-5 office hours. | 15:11.56 |
| henrys | tor8: to me having folks have a little dark in the morning or evening pales in comparison to the madness of changing the time. | 15:18.05 |
| kens | I seem to be going down with somethign gastric, so I'm heading off, may not make the meeting tomorrow..... | 15:59.44 |
| henrys | ray, chrisl (for the logs) we can talk about it tomorrow but I think we are really giving up a lot without the shared device in language. The biggest problem is not having 1 output. Really nice to have stream of different PDL jobs and use 1 "OutputFile" | 16:54.58 |
| | s/language/the language switch build/ | 16:55.37 |
| ismail | tor8: thanks! | 16:56.00 |
| chrisl | henrys: well, a) I can't see a way to make it work reliably with a shared device, and b) why should it matter since it isn't for "general" use anyway? | 16:56.50 |
| henrys | a) gc pcl or fix pdfwrite b) I don't want to constrain it's use if we don't have to. | 16:58.32 |
| chrisl | a) pdfwrite isn't the problem b) it was *you* that stated that it wasn't for general use | 16:59.28 |
| henrys | chrisl: we agreed sometime back that devices wouldn't use gc, and for a good amount of stuff they don't. | 17:00.46 |
| | the ls build does work for the most part with low level devices | 17:01.02 |
| | chrisl: as for (b) being in the thick of redesigning it I've thought about it some more and think it could be generally useful. | 17:01.59 |
| chrisl | henrys: no, we agreed that device shouldn't *rely* on gc, but because Postscript can hold a reference to the device (in a ref) having device completely outside gc is incompatible with the Postscript interpreter | 17:02.10 |
| henrys | chrisl: surely we could have a workaround for that, but I'm also thinking gc'ing pcl may not be that painful. | 17:03.26 |
| chrisl | So, after all the hostility to the garbage collector....... | 17:04.11 |
| henrys | chrisl: well Robin did have some ideas about possibly generating the descriptor that would take a lot of the hell out of it | 17:05.05 |
| chrisl | Then there's the problem of device selection in Postscript | 17:05.33 |
| henrys | I have the ls switch stuff working now with separate devices and memory now, and after fiddling with it I wonder why bother? just use separate processes. | 17:07.18 |
| chrisl | Shared code makes the total footprint smaller | 17:07.52 |
| henrys | I know that is the advantage, that's it though. | 17:09.06 |
| chrisl | I think another problem is that Ghostscript's entire device selection is handled in Postscript, and its device management is totally based on information gained during that process. | 17:10.04 |
| | I strongly suspect foisting a device from outside the PS environment onto Ghostscript was another source of problems for the original ls implementation | 17:11.57 |
| | Especially, but not exclusively, when the device is pdfwrite | 17:12.49 |
| henrys | chrisl: I haven't seen many problems with raster devices. pdfwrite is all over the gc, and I think most of that comes from the "imager state" - if that could be somehow separated memory-wise from the graphics state I think that would catch a lot of the issues. | 17:14.24 |
| chrisl | henrys: pdfwrite only relies on garbage collected memory for certain objects that can only come from the Postscript world. For everything else, although allocated in gc memory, pdfwrite does actually manage the memory itself | 17:15.46 |
| | But even sorting out those remaining cases doesn't solve the problem of how the device interacts with the Postscript environment | 17:16.49 |
| | And, FWIW, I'd much rather get rid of the imager state altogether - it's a horrible source of confusion, IMHO | 17:19.27 |
| henrys | chrisl: what are some specific things you are thinking about that will not work if we have an api for gs_setdevice? | 17:19.54 |
| chrisl | mainly setpagedevice/currentpagedevice and currentdevice in Postscript | 17:21.32 |
| henrys | chrisl: yeah but we have a lot of flexibility with what we choose to do and not do with those. | 17:22.53 |
| chrisl | Really? I thought we'd want to stick to what the spec requires | 17:23.39 |
| henrys | maybe you're right about the imager state. I think peter feared folks writing devices would poke at the graphics state ... | 17:24.28 |
| chrisl | I can see the reasoning behind it, but I don't agree with it..... | 17:25.21 |
| | For a concrete of case of a problem: if we take device entirely out of garbage collected memory, and then some Postscript does: "<< new device dict>> setpagedevice /cdev currentdevice def" - we'll encounter problems at the end of job | 17:27.34 |
| Robin_Watts | I think there are places in the graphics lib where we make a new imager_state and pass that on. | 17:27.37 |
| chrisl | Robin_Watts: yes, and often doesn't check whether it started with a graphics state or another imager state | 17:28.08 |
| Robin_Watts | where we are unwilling (or unable) to make a real graphics_state. | 17:28.09 |
| chrisl | There isn't a massing difference in the size of the two structures | 17:28.29 |
| henrys | chrisl: I'm also thinking the other way... gc for pcl and xps... but tailoring our entire system to PostScript gc just seems backward. | 17:29.24 |
| | Robin_Watts: are you okay? | 17:29.54 |
| mvrhel_laptop | good grief. So I see the issue with the shading fills with devices like psdcmyk and tiffsep | 17:29.58 |
| | The test is_dc_nearly_linear is always returning false | 17:30.13 |
| Robin_Watts | henrys: I have, apparently, tweaked a disc in my back. | 17:30.23 |
| mvrhel_laptop | since the device colors are deviceN type | 17:30.24 |
| | Robin_Watts: sorry to hear that | 17:30.31 |
| henrys | Robin_Watts: ugh | 17:30.39 |
| mvrhel_laptop | I have been down that road before | 17:30.45 |
| chrisl | henrys: I think that ship sailed with the original implementation - the graphics library was implemented, from the ground up, for Postscript | 17:30.46 |
| Robin_Watts | Should get better - nothing earth shattering. | 17:30.56 |
| mvrhel_laptop | the upside is that it does get better | 17:31.04 |
| Robin_Watts | yeah. | 17:31.13 |
| chrisl | Robin_Watts: stay mobile, but gentle movement | 17:31.21 |
| rayjj | actually, the graphics state does have baggage for some stuff besides PostScript -- ROPS and antialiasing | 17:31.51 |
| chrisl | imager state, surely? | 17:32.30 |
| rayjj | but as to why those, and not the rest of the PDF ExtGState stuff ... | 17:32.30 |
| chrisl | Ugh, don't get me started...... | 17:32.43 |
| henrys | rayjj: the entire discussion above may be of interest... | 17:32.45 |
| chrisl | henrys: I just don't see how we can get around the the way Postscript interacts with the device, and especially, being able to hold a reference to the device in PS VM | 17:34.39 |
| rayjj | henrys: I just got back from picking up my car. I'll review the logs | 17:34.40 |
| chrisl | Now, if we could do a bit of re-architecture and API redesign....... | 17:35.44 |
| henrys | chrisl: I wonder why that didn't come up in the language switch build before, we did beat on quite a bit, at least for low level devices | 17:36.00 |
| chrisl | henrys: it certainly came up when I tested it, which is why I raised it as a problem when we discussed it two staff meetings ago | 17:36.38 |
| henrys | chrisl: but we were using .endjob each postscript file should be encapsulated. | 17:42.47 |
| chrisl | henrys: but you're leaving a reference to a non-garbage collected object in existence | 17:43.27 |
| henrys | chrisl: and that is not a bug that could be addressed? | 17:46.03 |
| chrisl | henrys: I'd be interested in a solution for garbage collecting without a garbage collector | 17:47.06 |
| Robin_Watts | chrisl: I'd be interested in seeing how far we could get by first reducing it so that we never used gc for objects that weren't directly reachable from postscript. | 17:48.37 |
| chrisl | Robin_Watts: well, we're sort of heading down that road anyway. But that comes with its own problems | 17:49.31 |
| Robin_Watts | We have to reach devices from PS, so we should keep devices as gc'able. But sub sections of the devices that aren't reachable from PS should not be handled by gc. | 17:49.51 |
| | Yeah, it means we have to track usage and free stuff ourselves. | 17:50.09 |
| | No 'free ride' like we get from the gc. | 17:50.20 |
| chrisl | Not only that. To keep memory use under control, we trigger gc sweeps based on how much memory is in use - with loads of memory allocated outside of the garbage collector, we aren't making that decision on full information | 17:51.13 |
| | There is (or should be) an open bug for exactly that problem | 17:52.29 |
| | henrys: the main thing is, for the primary target audience of language switching, having separate devices is totally irrelevant, so I think we continue on that route, and discuss future/further enhancements as and when resources permit | 17:57.18 |
| baegle | I'm getting "Error: /typecheck in /findfont" when running ghostscript. I have already removed all WOFFs I can find. I don't know how to further debug the issue. Can anyone help? | 17:57.46 |
| chrisl | baegle: what version of gs are you using? | 17:58.19 |
| rayjj | since PCL doesn't use the GC, the device related stuff is properly tracked (doesn't leak), thus doesn't depend on a GC to clean things up | 17:58.30 |
| baegle | chrisl: 9.06~dfsg-2+deb8u1 (debian stable/Jessie) | 17:59.02 |
| rayjj | baegle: that's really old | 17:59.22 |
| henrys | chrisl: well I strongly disagreed with that, just you and rayjj outvoted me. What kind of printer would have 2 devices? bah! | 17:59.24 |
| chrisl | henrys: I don't recall your argument..... | 17:59.51 |
| rayjj | having a single device was a mess on the previous l/s. | 18:00.16 |
| chrisl | baegle: we released 9.18 not long ago | 18:00.31 |
| | henrys: Bear in mind that not sharing the device does *not* imply not sharing raster buffer memory | 18:01.32 |
| rayjj | chrisl wanted to have the parser each have their own device, and my only objection was making sure that the buffers for the devices for an inactive parser weren't kept around. Chris assured me that wouldn't be the case | 18:01.43 |
| henrys | chrisl: well the device is an abstaction of the hardware how many printers does a printer have? Which PageCount shall we use, the sum of the 2 devices... | 18:02.00 |
| baegle | chrisl: sure... I have feeling my issue is something I could debug if I understood how to do so. I don't even know what kind of sanity checks I can run to determine if ghostscript can find the font it's looking for | 18:02.22 |
| rayjj | henrys: well, to a PS printer, it thinks it "owns" the printer, and any intervening PCL jobs are invisible to it | 18:02.50 |
| henrys | rayjj: that ain't the way my printer works. It's an HP, pretty popular ... | 18:03.20 |
| rayjj | baegle: typecheck in findfont is *not* a problem that you can probably diagnose | 18:03.25 |
| chrisl | henrys: again. not sharing the device does not imply not sharing information | 18:03.46 |
| rayjj | henrys: so if you send a PS job that prints the currentpagedevice /PageCount, run a PCL job, and send that same PS job, it includes the PCL pages ? | 18:04.25 |
| | henrys: if so, we can do that -- it certainly isn't hard | 18:04.46 |
| chrisl | baegle: you could use strace to possibly see what font file was being read when the error triggered | 18:06.05 |
| rayjj | The Samsung I have doesn't have PS (just PDF which doesn't let me print the device's PageCount) | 18:06.06 |
| henrys | rayjj: huh I thougt the status page said postscript | 18:06.53 |
| rayjj | hmm... I'm not at the printer just now. I'll have to double check (or dig up the scan I did of that page) | 18:07.32 |
| chrisl | henrys: I feel like I/we are just repeating ourselves - we discussed this at length at the staff meeting and, as far as I'm concerned, nothing (from a technical perspective) has changed | 18:12.59 |
| rayjj | chrisl: right. I thought we agreed to letting you do it with each parser having its own device as long as the buffers (at least the large ones) weren't kept allocated | 18:14.22 |
| | chrisl: and if you run into problems doing it that way, its also fine with me if you decide to go back to a single (shared) device | 18:15.03 |
| chrisl | rayjj: Well, I gave up when I looked at the PCL interpreter front end...... | 18:15.18 |
| rayjj | chrisl: basically, as far as I am concerned, do how you think best (as long as you don't create memory usage issues) | 18:15.52 |
| chrisl | I *thought* henrys was adding an API style front end for PCL, from which I could then move on with ghostpdl | 18:16.23 |
| | rayjj: given that for any printer integration, we're looking at custom device(s), I don't see the memory use as a problem | 18:17.31 |
| henrys | chrisl: I am doing that, I have it working almost, from working on it I see it sucks, that's why I'm bringing it up. You are right nothing has changed technically. | 18:17.33 |
| chrisl | henrys: we could start up Ghostcript, let it do the device selection, and then grab the device from there - that *might* work...... | 18:18.29 |
| | But that means keeping a Ghostscript instance in existence all the time, which sucks | 18:19.35 |
| mvrhel_laptop | 696227 is interesting. psdcmykog has the issue but not psdcmyk | 18:23.46 |
| chrisl | henrys: Besides, I don't think getting it working with separate devices precludes us from exploring ways to make a single device work in the future. It just gets us another step forward, and something that a printer company could feasibly use | 18:25.14 |
| henrys | chrisl: I completely agree with that, I'm expecting to have something the same as gs's api for PCL this week. | 18:26.50 |
| chrisl | henrys: So, we can revisit this in person (which I think is more productive). The problem is, all my current ideas for solving the problem of the shared device(s) would involved API changes | 18:28.38 |
| henrys | chrisl: right language switching is all over the agenda so I don't think anything need be added | 18:31.06 |
| chrisl | henrys: TBH, if you want a proper argument: I think the *right* way to have this work would be to have a shared graphics library context, into which all the interpreters feed marking operations - but as the graphics lib context contains (opaque) references to interpreter context(s), that's never going to happen! | 18:40.21 |
| henrys | chrisl: that was our first design and we weren't able to get it to work. | 18:41.42 |
| chrisl | henrys: it would need *major* re-engineering of a few things to make it viable | 18:42.54 |
| | Just to be clear: I was not suggesting we take that route, but the usual: "if we'd been making these decisions twenty years ago......" | 18:44.28 |
| mvrhel_laptop | lunch time | 19:21.56 |
| rayjj | mvrhel_laptop: if you set the -dBandHeight=338 for the psdcmyk device (same as the psdcmykog device uses by default), you get a better comparison of the -ZL output. The interesting thing is that the psdcmyk device does the 'rendering bands' four times from (0,0) to (10,10). The psdcmykog device only does that once | 21:09.30 |
| mvrhel_laptop | rayjj: oh interesting. thanks | 21:24.25 |
| rayjj | mvrhel_laptop: the cmykog device doesn't use the get_bits_rectangle (or downscaler variant) to get single planes. It uses the "process_page" device proc | 21:26.05 |
| | in the cmykog_process function, it calls the get_bits_rectangle to get the pointers to the data. The other thing it does is that it uses the gdev_prn_color_usage to decide if it's going to output a plane. It could be that the color_usage is wrong | 21:28.43 |
| mvrhel_laptop | rayjj: oh I bet gdev_prn_color_usage is a likely problem | 21:53.30 |
| | looking at that now | 21:53.36 |
| | hmm no that was not the problem. | 21:58.08 |
| | I forced it to always process and still have the same thing | 21:58.50 |
| baegle | Can I send someone a postscript file for review? I just tried opening it in evince and it segfaulted | 23:19.36 |
| | This is the file that ghostscript crashed on, which seems to have been happening inside ps2pdf | 23:20.52 |
| | well, ok. It looks like it's just debian's super old version that's the problem because the latest 9.18 binary works just fine. | 23:49.22 |
| | Forward 1 day (to 2015/10/27)>>> | |
IRC Logs
