00:05.33 Opened logfile log/20130625. 00:05.33 Chans: (ghostbot) in:#ghostscript 00:16.24 hi 00:16.24 somebody said hello 00:16.24 hey 00:16.31 sebras is addressing ghostbot 00:16.31 ghostbot: welcome back! :) 00:16.31 Loaded Math 00:20.05 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 00:20.05 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 00:21.13 Chans: (ghostbot) in:#ghostscript 00:27.47 FORK(402) --- fork starting for 'RSSFeeds', PID == 402, bot_pid == 31304 --- 00:27.48 FORK(402) !ERROR! cannot load my module: RSSFeeds 00:27.48 FORK(402) fork: took 1s for RSSFeeds. 00:27.48 FORK(402) --- fork finished for 'RSSFeeds' --- 00:38.47 LOG: last message repeated 3 times 00:38.47 Seen: Flushed 1 entries. 00:47.49 --- Saved uptime records. 00:52.53 Chans: (ghostbot) in:#ghostscript 00:58.20 >>> vtorri has signed off IRC (Ping timeout: 256 seconds) [#ghostscript] 00:58.40 FORK(26610) --- fork starting for 'RSSFeeds', PID == 26610, bot_pid == 31304 --- 00:58.41 FORK(26610) !ERROR! cannot load my module: RSSFeeds 00:58.41 FORK(26610) fork: took 1s for RSSFeeds. 00:58.41 FORK(26610) --- fork finished for 'RSSFeeds' --- 01:02.36 >>> join/#ghostscript pipitas (~pipitas@p54A02098.dip0.t-ipconnect.de) 01:05.38 >>> pipitas1 has signed off IRC (Ping timeout: 255 seconds) [#ghostscript] 01:08.59 Chans: (ghostbot) in:#ghostscript 01:19.19 ircCheck: possible lost in space; checking.Tue Jun 25 01:19:19 2013 01:19.19 >ghostbot< TEST 01:19.19 IRCTEST: Yes, we're alive. 01:24.29 Chans: (ghostbot) in:#ghostscript 01:28.55 FORK(29620) --- fork starting for 'RSSFeeds', PID == 29620, bot_pid == 31304 --- 01:28.56 FORK(29620) !ERROR! cannot load my module: RSSFeeds 01:28.56 FORK(29620) fork: took 1s for RSSFeeds. 01:28.56 FORK(29620) --- fork finished for 'RSSFeeds' --- 01:47.57 --- Saved uptime records. 01:57.09 Chans: (ghostbot) in:#ghostscript 01:59.17 FORK(32413) --- fork starting for 'RSSFeeds', PID == 32413, bot_pid == 31304 --- 01:59.18 FORK(32413) !ERROR! cannot load my module: RSSFeeds 01:59.18 FORK(32413) fork: took 1s for RSSFeeds. 01:59.18 FORK(32413) --- fork finished for 'RSSFeeds' --- 02:00.42 >>> join/#ghostscript pipitas1 (~pipitas@p54A00138.dip0.t-ipconnect.de) 02:02.22 >>> pipitas has signed off IRC (Ping timeout: 256 seconds) [#ghostscript] 02:12.35 Chans: (ghostbot) in:#ghostscript 02:22.45 ircCheck: possible lost in space; checking.Tue Jun 25 02:22:45 2013 02:22.45 >ghostbot< TEST 02:22.45 IRCTEST: Yes, we're alive. 02:27.57 Chans: (ghostbot) in:#ghostscript 02:29.35 FORK(1699) --- fork starting for 'RSSFeeds', PID == 1699, bot_pid == 31304 --- 02:29.36 FORK(1699) !ERROR! cannot load my module: RSSFeeds 02:29.36 FORK(1699) fork: took 1s for RSSFeeds. 02:29.36 FORK(1699) --- fork finished for 'RSSFeeds' --- 02:48.19 --- Saved uptime records. 02:57.36 >>> join/#ghostscript tkamppeter_ (~till@p5480AEE4.dip0.t-ipconnect.de) 02:59.37 Chans: (ghostbot) in:#ghostscript 02:59.47 FORK(771) --- fork starting for 'RSSFeeds', PID == 771, bot_pid == 31304 --- 02:59.48 FORK(771) !ERROR! cannot load my module: RSSFeeds 02:59.48 FORK(771) fork: took 1s for RSSFeeds. 02:59.48 FORK(771) --- fork finished for 'RSSFeeds' --- 03:01.21 >>> tkamppeter has signed off IRC (Ping timeout: 248 seconds) [#ghostscript] 03:16.13 Chans: (ghostbot) in:#ghostscript 03:27.21 ircCheck: possible lost in space; checking.Tue Jun 25 03:27:21 2013 03:27.21 >ghostbot< TEST 03:27.21 IRCTEST: Yes, we're alive. 03:29.51 FORK(32580) --- fork starting for 'RSSFeeds', PID == 32580, bot_pid == 31304 --- 03:29.52 FORK(32580) !ERROR! cannot load my module: RSSFeeds 03:29.52 FORK(32580) fork: took 1s for RSSFeeds. 03:29.52 FORK(32580) --- fork finished for 'RSSFeeds' --- 03:32.29 Chans: (ghostbot) in:#ghostscript 03:48.35 LOG: last message repeated 3 times 03:48.35 --- Saved uptime records. 03:55.35 >>> join/#ghostscript vtorri (~vtorri@alf94-3-82-66-248-160.fbx.proxad.net) 04:00.13 FORK(1581) --- fork starting for 'RSSFeeds', PID == 1581, bot_pid == 31304 --- 04:00.14 FORK(1581) !ERROR! cannot load my module: RSSFeeds 04:00.14 FORK(1581) fork: took 1s for RSSFeeds. 04:00.14 FORK(1581) --- fork finished for 'RSSFeeds' --- 04:01.35 >>> vtorri has signed off IRC (Quit: Quitte) [#ghostscript] 04:04.09 Chans: (ghostbot) in:#ghostscript 04:20.05 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 04:20.05 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 04:30.35 FORK(6494) --- fork starting for 'RSSFeeds', PID == 6494, bot_pid == 31304 --- 04:30.36 FORK(6494) !ERROR! cannot load my module: RSSFeeds 04:30.36 FORK(6494) fork: took 1s for RSSFeeds. 04:30.36 FORK(6494) --- fork finished for 'RSSFeeds' --- 04:30.55 ircCheck: possible lost in space; checking.Tue Jun 25 04:30:55 2013 04:30.55 >ghostbot< TEST 04:30.55 IRCTEST: Yes, we're alive. 04:36.17 Chans: (ghostbot) in:#ghostscript 04:40.53 >>> Gigs- has signed off IRC (Ping timeout: 240 seconds) [#ghostscript] 04:49.15 --- Saved uptime records. 04:52.31 Chans: (ghostbot) in:#ghostscript 04:56.39 >>> join/#ghostscript Gigs- (~Gigs@206-248-204-121.unassigned.ntelos.net) 04:56.39 >>> Gigs- has signed off IRC (Changing host) [#ghostscript] 04:56.39 >>> join/#ghostscript Gigs- (~Gigs@pdpc/supporter/28for7/gigs) 05:00.35 FORK(6877) --- fork starting for 'RSSFeeds', PID == 6877, bot_pid == 31304 --- 05:00.36 FORK(6877) !ERROR! cannot load my module: RSSFeeds 05:00.36 FORK(6877) fork: took 1s for RSSFeeds. 05:00.36 FORK(6877) --- fork finished for 'RSSFeeds' --- 05:07.57 Chans: (ghostbot) in:#ghostscript 05:30.45 FORK(9080) --- fork starting for 'RSSFeeds', PID == 9080, bot_pid == 31304 --- 05:30.46 FORK(9080) !ERROR! cannot load my module: RSSFeeds 05:30.46 FORK(9080) fork: took 1s for RSSFeeds. 05:30.46 FORK(9080) --- fork finished for 'RSSFeeds' --- 05:35.41 ircCheck: possible lost in space; checking.Tue Jun 25 05:35:41 2013 05:35.41 >ghostbot< TEST 05:35.41 IRCTEST: Yes, we're alive. 05:40.51 Chans: (ghostbot) in:#ghostscript 05:49.33 --- Saved uptime records. 05:56.47 Chans: (ghostbot) in:#ghostscript 06:01.33 FORK(20705) --- fork starting for 'RSSFeeds', PID == 20705, bot_pid == 31304 --- 06:01.34 FORK(20705) !ERROR! cannot load my module: RSSFeeds 06:01.34 FORK(20705) fork: took 1s for RSSFeeds. 06:01.34 FORK(20705) --- fork finished for 'RSSFeeds' --- 06:17.47 LOG: last message repeated 3 times 06:17.47 >>> chrisl_away materializes into chrisl 06:24.25 >>> join/#ghostscript vtorri (~vtorri@alf94-3-82-66-248-160.fbx.proxad.net) 06:29.25 Chans: (ghostbot) in:#ghostscript 06:32.33 FORK(31626) --- fork starting for 'RSSFeeds', PID == 31626, bot_pid == 31304 --- 06:32.34 FORK(31626) !ERROR! cannot load my module: RSSFeeds 06:32.34 FORK(31626) fork: took 1s for RSSFeeds. 06:32.34 FORK(31626) --- fork finished for 'RSSFeeds' --- 06:39.47 ircCheck: possible lost in space; checking.Tue Jun 25 06:39:47 2013 06:39.47 >ghostbot< TEST 06:39.47 IRCTEST: Yes, we're alive. 06:43.21 >>> join/#ghostscript kens (~Miranda@40.249.125.91.dyn.plus.net) 06:44.32 >>> join/#ghostscript tor8 (~tor@c-bd7871d5.04-50-6c756e10.cust.bredbandsbolaget.se) 06:45.52 Chans: (ghostbot) in:#ghostscript 06:50.27 --- Saved uptime records. 07:02.45 FORK(2004) --- fork starting for 'RSSFeeds', PID == 2004, bot_pid == 31304 --- 07:02.46 FORK(2004) !ERROR! cannot load my module: RSSFeeds 07:02.46 FORK(2004) fork: took 1s for RSSFeeds. 07:02.46 FORK(2004) --- fork finished for 'RSSFeeds' --- 07:03.15 Chans: (ghostbot) in:#ghostscript 07:05.51 >>> jghali has signed off IRC (Read error: Connection reset by peer) [#ghostscript] 07:06.29 >>> join/#ghostscript jghali (~jghali@ADijon-157-1-26-253.w86-218.abo.wanadoo.fr) 07:09.43 >>> vtorri has signed off IRC (Changing host) [#ghostscript] 07:09.44 >>> join/#ghostscript vtorri (~vtorri@enlightenment/developer/vtorri) 07:18.39 Chans: (ghostbot) in:#ghostscript 07:24.01 >>> sivoais has signed off IRC (Ping timeout: 246 seconds) [#ghostscript] 07:32.57 FORK(8766) --- fork starting for 'RSSFeeds', PID == 8766, bot_pid == 31304 --- 07:32.58 FORK(8766) !ERROR! cannot load my module: RSSFeeds 07:32.58 FORK(8766) fork: took 1s for RSSFeeds. 07:32.58 FORK(8766) --- fork finished for 'RSSFeeds' --- 07:34.15 Chans: (ghostbot) in:#ghostscript 07:44.45 ircCheck: possible lost in space; checking.Tue Jun 25 07:44:45 2013 07:44.45 >ghostbot< TEST 07:44.45 IRCTEST: Yes, we're alive. 07:50.15 Chans: (ghostbot) in:#ghostscript 07:50.35 --- Saved uptime records. 07:56.27 >>> join/#ghostscript sojic (~sojic@46.217.42.146) 08:03.13 FORK(27517) --- fork starting for 'RSSFeeds', PID == 27517, bot_pid == 31304 --- 08:03.14 FORK(27517) !ERROR! cannot load my module: RSSFeeds 08:03.14 FORK(27517) fork: took 1s for RSSFeeds. 08:03.14 FORK(27517) --- fork finished for 'RSSFeeds' --- 08:03.53 God, close 2 bugs, get 4 new ones.... 08:04.16 Pretty sure at least a couple aren't really yours 08:05.35 I just passed one to Ray (15+ Gb temp files) 08:05.54 I think that's actually legit, but Ray probably can figure out why the files are so big faster than me 08:06.11 Its a monstrously complex PDF file 08:06.26 It may have been fixed - he did fix something similar not that long ago 08:06.26 Chans: (ghostbot) in:#ghostscript 08:07.19 and his other report is another 15Mb PDF file 08:07.31 Which, the JPG one? 08:08.04 No, the other Gigs one, with (at least) 8 spot colours 08:08.22 Oh, right, that'll be a color one, then? 08:08.50 'probably'. Looks like it has full page overprinting, Michael will be delighted 08:09.36 And its NChannel too. 08:11.18 By the way, whats 'gsc' ? 08:11.32 I wasn't aware we built GS with that name on Linux 08:13.14 Hmm, I get an undefinedfilename in showpage 08:13.41 OK fixed that. 08:14.17 Guess I'd better boot a VM and try this in Linux 08:14.37 No, fails on Windows too, and in a debug build :-) 08:20.07 Good grief, showpage is a procedure in gs_init.ps. Of course it is.... 08:20.07 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 08:20.07 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 08:20.27 Joy looks like its a VM bug 08:22.35 Chans: (ghostbot) in:#ghostscript 08:26.48 kens: gsc is one of the dynamic lib aps, IIRC - gsx and gsc 08:27.18 Oh, OK 08:33.15 FORK(7776) --- fork starting for 'RSSFeeds', PID == 7776, bot_pid == 31304 --- 08:33.16 FORK(7776) !ERROR! cannot load my module: RSSFeeds 08:33.16 FORK(7776) fork: took 1s for RSSFeeds. 08:33.16 FORK(7776) --- fork finished for 'RSSFeeds' --- 08:36.52 Right, that's the other Gigs one off to Ray as well. 08:38.12 Chans: (ghostbot) in:#ghostscript 08:38.16 tor8: ping ? 08:38.29 Robin_Watts: hi. 08:38.54 In pdf-repair.c 08:38.58 line 44ish 08:39.11 we call pdf_parse_dict and we pass NULL for the pdf_document 08:39.29 There is a comment there that says "Send NULL xref so that we don't try to resolve references" 08:39.37 >>> vtorri has signed off IRC (Ping timeout: 246 seconds) [#ghostscript] 08:39.48 I can't see anywhere in pdf_parse_dict that we WOULD try to resolve references. Am I being dim? 08:40.47 Seen: Flushed 4 entries. 08:42.48 >>> join/#ghostscript chrisl_r61 (~chrisl_r6@cpc9-ando5-2-0-cust95.15-1.cable.virginmedia.com) 08:46.59 >>> sojic has signed off IRC (Remote host closed the connection) [#ghostscript] 08:47.16 let me try to remember 08:47.25 >>> join/#ghostscript sojic (~sojic@46.217.42.146) 08:47.36 I don't think it was set to NULL for the parse_dict call, but for later use 08:50.49 --- Saved uptime records. 08:51.02 >>> sojic has signed off IRC (Read error: Operation timed out) [#ghostscript] 08:51.32 tor8: Sorry, I have radu talking to me in a skype window. 08:52.06 I don't follow. 08:52.18 The one place where I can see a NULL is in the pdf_parse_dict call. 08:53.05 we set it to null so that the we wouldn't try to resolve any indirect references contained in the dict *later* 08:53.25 not during the parse call, but from any pdf_load_object calls that pulled up the same cached obj 08:53.36 and further operations on it 08:53.46 but I don't remember exactly why 08:53.46 Chans: (ghostbot) in:#ghostscript 08:55.21 tor8: for that to be true, the NULL passed into the pdf_parse_dict call would need to be stored in the lexed objects somewhere, yes ? 08:55.47 we stored the pdf_xref type in the objects at one time 08:55.55 before fz_context was introduced 08:55.59 so this could all be old junk 08:56.18 right. My suspicion is that it is indeed old. 08:56.58 Ah. We have a call to pdf_new_indirect in there, and that stores the xref. 08:57.00 maybe because we created a new pdf_xref object at the end? 08:57.09 so didn't want old stale pointers in there 08:57.18 (just a guess) 08:57.27 but the pdf_document pointer won't change now. 08:57.33 which is what we store. 08:57.41 the xref contents might, but the pdf_document won't. 08:57.44 so I think we're safe. 08:58.15 yeah. I think it ought to be safe. 08:58.29 I just looked at the ohloh graph of mupdf 08:58.43 code size was stable from 2004-2011 08:58.50 then it blew up, and has doubled in two years 08:59.08 3 months since last commit? 08:59.15 too many new features! :) 08:59.28 said last commit was 3 days ago 09:00.26 we had a local minimum in 2010 of 37kloc 09:00.39 now we're at 99kloc 09:03.26 has a well established, mature codebase 09:03.28 maintained by a large development team 09:03.30 with increasing Y-O-Y commits 09:03.33 Apparently we're fat. :) 09:03.34 FORK(32535) --- fork starting for 'RSSFeeds', PID == 32535, bot_pid == 31304 --- 09:03.35 FORK(32535) !ERROR! cannot load my module: RSSFeeds 09:03.35 FORK(32535) fork: took 2s for RSSFeeds. 09:03.35 FORK(32535) --- fork finished for 'RSSFeeds' --- 09:04.48 * kens/#ghostscript wonders what a Y-O-Y commit is 09:04.55 Year on Yea 09:04.56 WHy oh Why ? 09:04.57 Year on Year 09:05.04 :) 09:05.23 Why Oh Why, did we do that! seems more appropriate :) 09:07.26 tor8: 2 commits on robin/master then. 09:10.14 Interestingly gs has ballooned since 2010 too. 09:10.14 Chans: (ghostbot) in:#ghostscript 09:10.27 s/xref_entry/xref/ in the commit message? 09:10.32 That must be us pulling in dependencies. 09:10.51 in gs that's probably the case 09:11.00 or you're just outproducing the lot of us ;) 09:11.02 FreeType would be a big part of that 09:11.11 do I not need xref ? 09:11.19 tor8: I am the infinite monkey :) 09:11.30 do I not *mean* xref_entry ? 09:11.53 xref_entry is the individual slots in the xref (section) struct 09:12.01 table 09:12.03 thingy 09:12.18 I mean 'pdf_xref' 09:12.21 ok, will reword. 09:13.28 the patches look fine apart from that message 09:13.35 so go ahead once you've fixed 09:13.49 radu is complaining that the build script is borked for ios. 09:14.09 i'm trying to build your latest code 09:14.09 Robin_Watts: I'm surprised the ios build has worked at all the last couple of months 09:14.11 [09:51:26] Radu Lazar: iOS version 09:14.13 [09:51:50] Radu Lazar: even after make generate it still fails 09:14.14 I guess I could try to fix 09:14.15 [09:55:23] Radu Lazar: no rule to make target libs 09:14.16 [09:59:03] Radu Lazar: this is from the build script 09:14.18 [09:59:03] Radu Lazar: make -C .. libs || exit 1 09:14.19 [09:59:11] Radu Lazar: i thinks it should be ../.. 09:14.23 even with that 09:14.25 [10:12:20] Radu Lazar: it still fails after 09:14.27 [10:12:34] Radu Lazar: some paths don't add up, i guess 09:14.45 which version of ios/xcode is he using? may as well use the same when fixing it. 09:15.08 I have the Xcode 5 preview thingy installed too 09:15.20 4.6.3 and ios6.1 09:15.30 ios61 09:15.40 thanks. 09:15.57 I'll go ahead and ruin my day then.. 09:16.46 :) 09:18.01 I got my new computer all assembled, now to set up linux and a development environment for opengl... but that can wait till after I've torn out my remaining hair over some new apple madness :) 09:25.56 tor8: once the top of your head is cleared, you might want to start tearing your eyelashes. ;) 09:26.12 Robin_Watts: make -C .. libs -> "make -C ../.. OUT=$OUT libs" and then fix the ..'s in ../../$OUT/*.o in the ar line later on fixes it 09:26.18 tear off my eyelids! 09:26.58 Chans: (ghostbot) in:#ghostscript 09:28.22 Robin_Watts: ios build fix on tor/master 09:28.33 doesn't promise it runs after, but at least it compiles 09:32.40 don't push yet though 09:33.41 FORK(29961) --- fork starting for 'RSSFeeds', PID == 29961, bot_pid == 31304 --- 09:33.42 FORK(29961) !ERROR! cannot load my module: RSSFeeds 09:33.42 FORK(29961) fork: took 1s for RSSFeeds. 09:33.42 FORK(29961) --- fork finished for 'RSSFeeds' --- 09:41.31 Seen: Flushed 4 entries. 09:43.09 Chans: (ghostbot) in:#ghostscript 09:47.51 right. hot water sorted, so there is a reasonable chance I can have a shower when I get back from my run. bbiab. 09:51.01 --- Saved uptime records. 09:59.15 Chans: (ghostbot) in:#ghostscript 10:00.43 >>> join/#ghostscript paulgardiner (~chatzilla@smtp.glidos.net) 10:03.59 FORK(29629) --- fork starting for 'RSSFeeds', PID == 29629, bot_pid == 31304 --- 10:04.00 FORK(29629) !ERROR! cannot load my module: RSSFeeds 10:04.00 FORK(29629) fork: took 1s for RSSFeeds. 10:04.00 FORK(29629) --- fork finished for 'RSSFeeds' --- 10:11.56 I. Hate. X. Code. 10:15.09 Chans: (ghostbot) in:#ghostscript 10:20.54 Robin_Watts, tor8: Ah good. Three of my reviews are in. Thanks. I'm guessing there are quesions about or problems with the forth. 10:21.09 paulgardiner: read the irc logs from yesterday :) 10:21.19 Right. Will do. 10:21.19 I and Robin had a long discussion about it 10:21.35 Eek! Sounds ominous. 10:31.05 Chans: (ghostbot) in:#ghostscript 10:34.11 FORK(1048) --- fork starting for 'RSSFeeds', PID == 1048, bot_pid == 31304 --- 10:34.12 FORK(1048) !ERROR! cannot load my module: RSSFeeds 10:34.12 FORK(1048) fork: took 1s for RSSFeeds. 10:34.12 FORK(1048) --- fork finished for 'RSSFeeds' --- 10:35.49 Hmmm. Finding that hard to follow. One thing that it took me ages to realise is that we don't have to worry about multiple occurances of non-indirect objects: although our data structures support that possiblility, the file format doesn't, so it can never occur. 10:38.31 Second thing. We don't need to copy the whole hierarchy above an object we wish to change, just the nodes on a path up from the object to the next indirect one. 10:41.45 Seen: Flushed 3 entries. 10:42.28 So, if I'm understanding correctly, the idea is to make it more systematic about which thing to clone rather than relying on the fact that we known the important nodes in the hierarchy for all the particular cases that arise with forms and annotations. 10:46.06 So, I guess we could, while reading the file, keep a parent pointer for each non-indirect object... but setting that pointer would be highly nonsystematic and so just as fragile as performing the cloning on a case-by-case basis 10:47.19 Chans: (ghostbot) in:#ghostscript 10:51.05 --- Saved uptime records. 11:03.11 paulgardiner: the parser (and dict_puts, etc) could make sure the parent pointers are up to date 11:03.31 Chans: (ghostbot) in:#ghostscript 11:03.44 but we're not sure the parent is guaranteed to have the same lifetime or we'll introduce reference counting cycles 11:04.15 when writing out a new pdf the incremental xref section will need the full indirect object, so it won't hurt us (much) to clone the whole thing anyway 11:04.15 FORK(32664) --- fork starting for 'RSSFeeds', PID == 32664, bot_pid == 31304 --- 11:04.16 FORK(32664) !ERROR! cannot load my module: RSSFeeds 11:04.16 FORK(32664) fork: took 1s for RSSFeeds. 11:04.16 FORK(32664) --- fork finished for 'RSSFeeds' --- 11:04.23 and it makes the book-keeping simpler 11:04.56 Lost me. Whole thing? 11:05.13 10 0 obj << ...big nested dictionary... >> endobj 11:05.36 that whole thing has to be written out from scratch even if it's only one of the nested leaves in a big tree of dicts that has changed 11:06.19 Still lost 11:06.38 10 0 obj << /Foo << /Bar 3 >> /Quux 42 >> endobj 11:06.53 if we change 10's /Foo/Bar entry 11:07.08 all of 10 will have to be written in the new xref section 11:08.17 anyway, if you read all of yesterday's discussion I think you'll find it doesn't matter 11:08.58 since we can just zero the "cache entry" in xref->entry[x]->obj for the old xref section and move the pointer to the incremental section 11:09.06 yeah, but I don't get how that impacts on the incremental xref section. 11:09.17 I read it. I don't get it. 11:09.45 okay. here's my proposal from scratch: 11:10.18 we keep some book keeping in each pdf_obj (the object number of the containing obj/endobj more specifically) 11:10.56 whenever we try to mutate a pdf_obj, we need to move the containing obj/endobj into the incremental xref section 11:11.34 so pdf_dict_puts etc would find the corresponding "old" xref section, zero out the obj pointer, and make a new xref slot in the incremental xref section and put the pointer there instead. 11:12.00 and then from the root object it'd go and zero out the book-keeping object number (so we don't waste cycles doing the same thing over and over) 11:12.08 make sense so far? 11:12.47 Not quite. 11:13.03 the idea is to automatically put *all* edits into the incremental xref section 11:13.06 zerp out the obj pointer? 11:13.14 anything before the incremental section is immutable 11:13.15 s/zerp/zero/ 11:13.18 copy-on-write essentially 11:13.38 But we may need to refer to the old version 11:13.43 pdf_xref->table[x].obj has a pointer to an object (which is cached) 11:13.55 So would not zeroing make it unobtainable 11:14.27 trying to read the old object by using the old (non-incremental) xref section would reload it from file using the xref file offset 11:15.07 anybody trying to read the object from the "top" of the xref section stack (i.e. the latest version of an object) would get the mutated copy that hasn't been saved to file yet 11:17.02 So you zero it out so that you can avoid cloning it? 11:17.15 yup. 11:17.29 We zero it out a) so we don't try to read the old version and find the new version there 11:17.39 and b) so we don't clone it again and again. 11:18.12 oh, sorry, the pdf_obj 'parent' int - that's just for b) aiui. 11:18.19 Once you clone it and it's in the incremental section, you wouldn't clone it again anyway 11:18.47 Right, but whenever we alter it, we'd have to check whether it was there or not. 11:18.57 Chans: (ghostbot) in:#ghostscript 11:19.21 it's a question; is nulling recursively on a move more or less expensive than repeatedly rechecking objects when we touch them ? 11:20.02 paulgardiner: There was a small problem with the 3rd commit. 11:20.14 Where you malloc a list, then populate it, then use it, then free it. 11:20.31 If you throw an exception during the building, you can be left with an unfreed partial list. 11:20.33 Robin_Watts: yeah I saw the comment. So all sorted now though? 11:20.42 no, I didn't fix that yet. 11:20.52 Oh okay. I'll sort that. 11:21.20 I have some work preparatory to the changes tor8 is talking about. 11:21.32 on robin/master 11:21.39 I have yet to understand how nulling is avoiding a check 11:22.18 paulgardiner: I think robin's referring to setting pdf_obj->number to 0 as opposed to checking the xref slot 11:22.28 (correct me if I'm wrong) 11:28.02 I don't get why this is confusing me so much. Now I can't imagine what I could do with a pdf_obj that had had its number set to 0. I can't even work out what it used to refer to. 11:31.39 paulgardiner: Currently pdf_objs' don't have any 'parent' information. 11:32.07 If I have a pdf_obj that is (say) a name or a string or an int, there is no way to know what it's parent is. 11:32.31 Likewise if I have a dictionary, I have no way of knowing, purely from the pdf_obj where that lives in the heirarchy. 11:32.32 yes? 11:33.58 So by "number", did you mean the number of the containg indirect? 11:33.58 We are proposing adding a new field to pdf_obj, called, say, parent. The purpose of this field is to tell us what the closest parent of the object that has an xref entry is. 11:34.06 Yes. 11:34.16 FORK(1324) --- fork starting for 'RSSFeeds', PID == 1324, bot_pid == 31304 --- 11:34.17 FORK(1324) !ERROR! cannot load my module: RSSFeeds 11:34.17 FORK(1324) fork: took 1s for RSSFeeds. 11:34.17 FORK(1324) --- fork finished for 'RSSFeeds' --- 11:34.30 And nulling meant zero that? 11:34.36 yes. 11:34.45 or setting it to -1 or something. 11:34.55 Chans: (ghostbot) in:#ghostscript 11:35.18 some indication that this object is guaranteed to be in an object that it's in the incremental section already. 11:35.29 And that happens somehow as part of the moving to the incremental section> 11:35.34 ? 11:35.51 there can't ever be an indirect object with number 0 (it's reserved for the first "free" slot in the xref) 11:36.39 number is set only for objects with parents in the incremental section? 11:36.44 Whenever we do a pdf_dict_write (or whatever the function is), we need to ensure that the whole heirarchy that that dictionary lives in (up to the closest enclosing indirect reference) lives in the incremental section. 11:36.57 No. number is set for all objects. 11:37.09 But we null it for some? 11:38.23 When we realise that we change an object (and hence need to move it's containing heirarchy) to the incremental section we can set the 'parent' value for each object in the bit that we move to 0. 11:38.57 Meaning don't move again 11:39.02 indeed. 11:40.03 so the question is whether it's faster to zero the hierarchy, or do the test at each modification 11:42.17 Seen: Flushed 3 entries. 11:50.21 Chans: (ghostbot) in:#ghostscript 11:50.50 I suspect doing the test at each modification will be cheap enough. 11:51.11 --- Saved uptime records. 11:51.31 read the number. read the xref pointer, read xref[number].type 11:51.41 Talking on the phone helps. Yeah, get it now. So the number = 0 is just an optimisation to avoid checking its in the incremental sect 11:51.48 yeah. 11:52.04 Suppose we do *two* incremental things? 11:52.10 sign it once, then sign it again. 11:52.22 The number = 0 thing becomes problematic then. 11:52.37 because things that were updated and were in the incremental section no longer are. 11:52.48 so I'd vote for not doing the number = 0 thing. 11:53.32 But overall the idea is move instead of clone, which invloves setting old obj pointer to zero so it gets reloaded if needed, and make spotting of parent indirect object systematic rather than use case-by-case knowledge 11:54.41 Robin_Watts: ah yes, on saving the incremental section is no longer incremental 11:55.16 It was mainly the move instead of clone that was confusing me, but get it now. 11:55.24 Yes. Nice. 11:55.52 paulgardiner, tor8, sebras: http://www.kickstarter.com/projects/1949537745/armikrog 11:55.54 So who's doing what. I could take this over if you like, or you could continue 11:56.20 paulgardiner: I'm happy for you to take it over. 11:56.32 Okay great 11:56.41 I ought to just test pdfclean with my existing change. 11:56.50 the cluster passes it, and tor8 was happy. 11:57.12 paulgardiner: yes, I agree. checking the xref section rather than 0 sounds more robust. 11:57.50 If we ever do merging of documents, then having pdf_doc pointers in the pdf_obj's will mean we need to change ownership, but I don't think that affects us at the moment. 11:58.44 >>> join/#ghostscript sojic (~sojic@92.55.124.149) 11:59.45 Hmmm, the only thing I wonder is whether this is worth growing the obj structure for: the cases we need to handle are very few. Another possibility would be to change my existing patch to use move rather than clone 12:00.41 It's not like this will need revisiting for each new annotation type. 12:00.42 paulgardiner: The pdf_obj structure shrank by 8 bytes yesterday. 12:00.55 we're about to grow it by 4 :) 12:01.01 Oh well, would be rude not to take advantage of that. 12:01.03 so it's a net win. 12:01.34 paulgardiner: Do you want to fix that list malloc failure thing? 12:01.43 while I test pdfclean ? 12:01.45 Yeah. Will do that in a min 12:04.08 tor8, paulgardiner: If you "mutool clean -d pdf_reference17.pdf out.pdf" do you get warnings about trying to load object 333280 ? 12:04.18 FORK(2968) --- fork starting for 'RSSFeeds', PID == 2968, bot_pid == 31304 --- 12:04.19 FORK(2968) !ERROR! cannot load my module: RSSFeeds 12:04.19 FORK(2968) fork: took 1s for RSSFeeds. 12:04.19 FORK(2968) --- fork finished for 'RSSFeeds' --- 12:06.45 Chans: (ghostbot) in:#ghostscript 12:12.26 tor8: See Skype. 12:14.19 ok, old code is giving me the same errors with the xrefs. 12:15.13 paulgardiner: pushed. 12:20.13 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 12:20.13 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 12:23.09 Chans: (ghostbot) in:#ghostscript 12:24.45 paulgardiner: So, there is a problem with your reworked xref code. 12:25.05 let's do this on the phone, it'll be easier. 12:31.38 Robin_Watts: ios fix on tor/master 12:32.42 tor8: Let me look now. 12:34.19 FORK(15842) --- fork starting for 'RSSFeeds', PID == 15842, bot_pid == 31304 --- 12:34.20 FORK(15842) !ERROR! cannot load my module: RSSFeeds 12:34.20 FORK(15842) fork: took 1s for RSSFeeds. 12:34.20 FORK(15842) --- fork finished for 'RSSFeeds' --- 12:34.55 pushed 12:35.24 thanks. 12:35.37 >>> join/#ghostscript setmeaway (~setmeaway@119.201.52.138) 12:36.42 >>> chrisl materializes into chrisl_away 12:39.53 Chans: (ghostbot) in:#ghostscript 12:41.27 >>> tkamppeter_ materializes into tkamppeter 12:43.11 Seen: Flushed 3 entries. 12:52.03 --- Saved uptime records. 12:56.09 Chans: (ghostbot) in:#ghostscript 12:57.58 Hmmm, three cases: 1 - we call pdf_dict_set while loading from a file for a dict that has yet to be linked into the hierarchy of any indirect object; 2 - we call pdf_dict_set while loading from a file for a dict that is linked into an indirect object; 3 - we call pdf_dict_set to edit a document. 12:59.11 Not sure how to distinguish and handle these cases, especially as we load objects lazily, so we may edit page 1 before loading the objects for page 2. 12:59.48 There's a fix for the potential memory leak pushed to paul/master, BTW. 12:59.56 paulgardiner: when inserting an object into a dict or array, inherit the dict/array's parent number 13:00.22 and when loading an indirect object from file, set its number at or after creation 13:00.34 setting it after would have to be recursive thugh 13:01.32 tor8: yeah, I think we are forced to do the recursion because we probably create the non-indirect tree and then indirect it 13:02.00 Actually no, that's not quite right. 13:04.04 But still, whether a dict will already have a partent number to inherit will depend very much on the particular code used to load from the file 13:04.44 FORK(12506) --- fork starting for 'RSSFeeds', PID == 12506, bot_pid == 31304 --- 13:04.45 FORK(12506) !ERROR! cannot load my module: RSSFeeds 13:04.45 FORK(12506) fork: took 1s for RSSFeeds. 13:04.45 FORK(12506) --- fork finished for 'RSSFeeds' --- 13:05.44 hm, the xref->trailer may need some special magic number here? 13:06.43 Sorry, not getting that. 13:07.19 when mutating the trailer object... wouldn't we need to do the same "move to incremental" stuff? 13:08.29 Each xref-section structure has its own trailer obj 13:09.02 do you create a new trailer object clone when creating the incremental section? 13:09.28 just figured we shouldn't forget about mutating the xref... 13:09.29 I think so. Just looking now. 13:09.49 Hmmm, I seem to just pdf_keep_obj it. That can't be right. 13:10.04 whether that should also automatically create a new incremental section or something else 13:10.29 the trailers for new format xrefs has the Prev and Next and file offsets in the dictionaries 13:11.10 so if you're just pointing to the same as the old trailer, it sounds like you've got some more work to do :) 13:12.09 Yeah, I was not worrying about that too much because it should have no ill affects until we want to compare versions of the file. 13:12.30 Chans: (ghostbot) in:#ghostscript 13:12.46 I'm much more concerned about how to recognise the different cases of pdf_dict_put 13:13.47 >>> join/#ghostscript mvrhel_laptop (~chatzilla@24-247-151-14.dhcp.klmz.mi.charter.com) 13:14.05 paulgardiner: there's only one pdf_dict_put at the bottom that does the work 13:14.51 there is array_put/push/insert 13:15.01 Yeah sure, but knowing whether it is being called for a object load from the file or for the sake of editing is the problem 13:15.33 paulgardiner: I'd suggest a call pdf_set_object_number(obj, num) that recursively sets the object parent number 13:15.44 and add calls to that to pdf_load_ind_obj and pdf_load_stm_obj 13:15.55 and pdf_update_object 13:16.19 maybe this xref and object loading stuff could be refactored a bit to be clearer 13:16.49 init a new object with parent number set to 0 13:17.19 and then (recursively) inherit any time an object is linked into a dict or array 13:18.07 when parsing that shouldn't be too expensive (since parsing always adds to the end) 13:18.30 or if you have a better idea, use that :) 13:20.08 Trouble is, although I like this idea a lot, looking into the detail, I'm struggling to see a way to handle all the cases that is going to be less error prone than the case-by-case handling I did before. 13:20.30 >>> Fandekasp has signed off IRC (Ping timeout: 264 seconds) [#ghostscript] 13:21.24 I guess it should be the case that there are only a few well defined places in the code where we parse objects and just calling the recursive setting of the parent there should work. 13:21.50 >>> join/#ghostscript Fandekasp (~Fandekasp@27-32-19-26.static.tpgi.com.au) 13:22.24 >>> sojic has signed off IRC (Remote host closed the connection) [#ghostscript] 13:22.28 And maybe we can distinguish between pdf_dict_put for the sake of editing or loading on the basis of whether the parent is set. 13:24.25 Yeah, would that work: when calling pdf_dict_put, dict's parent == 0 means this dict is being altered for the sake of being parsed from the file? 13:24.40 And once we've loaded a 13:24.54 n object, we recursively set parent. 13:25.26 We discussed on the phone the idea of having a doc->incremental_mode flag. 13:25.53 If doc->incremental_mode =0, then we just change the dict, no messing with parents etc. 13:26.11 If doc->incremental_mode = 1 then we check the parent and move if required. 13:26.23 so we do normal loading with doc->incremental_mode set to 0. 13:26.50 Oh, but doing parsing later maybe a problem, is that what you're saying ? 13:28.20 Chans: (ghostbot) in:#ghostscript 13:28.42 Yeah. I realised that after we talked 13:30.08 paulgardiner: there are only two places objects are loaded from file -- pdf_parse_ind_obj and pdf_parse_stm_obj ... ad maybe the repair code has something as well 13:30.17 so, we could stash the incremental mode flag somewhere, do the parse, then reinstate the flag ? 13:31.42 Above I suggested that the dict's parent number being 0 could be used to determine whether we are loading for editing. 13:31.48 parent==0 when creating objects, if parent==0 when mutating, do nothing. then set parent after the object is loaded. that should cover both the incremental and non-incremental cases. 13:32.21 tor8: so you thing that would work. 13:32.25 when insert an object into a dict or array, if the dict or array has a parent != 0, recursively set the object's parent 13:32.30 tor8: That solves the parsing problem, yes. 13:33.09 but I still think we need an incremental_mode or not to say whether we are working in a way where all updates should be incremental, or whether we want to completely rewrite the file (like when we're cleaning) 13:33.23 tor8: that last case occuring only when editing? 13:33.54 Robin_Watts: yeah having a mode flag is still good. 13:34.06 Robin_Watts: yes. incremental mode should govern whether a mutation on a non-zero parent moves the object to the incremental section or not. 13:34.34 This sounds like a nice sane solution. No odd corner cases that I can immediately see. 13:34.36 but the incremental flag shouldn't affect maintaining the parent numbers 13:35.02 so all objects that live in an xref have a parent number, objects that don't (yet) have a zero parent number 13:35.12 FORK(18516) --- fork starting for 'RSSFeeds', PID == 18516, bot_pid == 31304 --- 13:35.13 FORK(18516) !ERROR! cannot load my module: RSSFeeds 13:35.13 FORK(18516) fork: took 1s for RSSFeeds. 13:35.13 FORK(18516) --- fork finished for 'RSSFeeds' --- 13:35.17 yeah, sounds good 13:35.30 any updates automatically move into the incremental xref section if the incremental mode is set, no possible way to forget 13:36.11 pdf_update_object which is used to insert a newly created object into the xref also needs to assert parent ownership 13:36.20 It's only arrays and dicts that need to be recursed through, right? 13:36.29 and of course the normal indirect and object stream parser cases 13:36.34 Yes. 13:36.35 paulgardiner: correct. 13:37.20 the repair and cleanup code does magic trickery, but I think at the end of this incremental xref updating they should be mostly using the 'regular' apis for building and rebuilding xrefs 13:37.32 s/updating/project/ 13:43.25 Seen: Flushed 3 entries. 13:43.43 Chans: (ghostbot) in:#ghostscript 13:50.20 Robin_Watts: git workflow question for you (or for tor8) 13:51.59 >>> pipitas1 has signed off IRC (Ping timeout: 255 seconds) [#ghostscript] 13:52.28 I was going to get going on the lcms mupdf stuff and I know that tor8 has a branch tor/lcms2. Can I just checkout that branch and go on from there? 13:52.38 --- Saved uptime records. 13:52.56 I am a little worried about what the origin is in this case 13:53.12 mvrhel_laptop: You can. 13:53.28 kens: thanks for looking at the bugs 13:53.35 NP 13:53.42 And then when I push Robin_Watts does it go to my repos? 13:53.55 git fetch from tor8's repo, then you'll see a tor/lcms2 branch. 13:53.58 kens: we get those complex files sometimes... I think what they come from is a forced language level postscript converted to PDF 13:54.08 Robin_Watts: yes I see the branch now 13:54.08 kens: gradients and transparency decomposed to raster 13:54.12 hm, I think I should update the lcms2 branch to the latest reshuffle 13:54.13 Create yourself a branch at that same place (lcms2). 13:54.15 Gigs, possibly, its really hard to tell 13:54.32 Then you can rebase it. 13:54.41 You may be best to let tor8 rebase that first for sanity. 13:54.45 tor8: oh I will wait if you are going to do that 13:54.52 they do eventually render but I drive gs from the web and people hit stop and reload which just runs another copy of gs 13:54.56 I'll do it right now, shouldn't take long 13:55.09 Robin_Watts: tested and they are private things 13:55.20 thanks not things 13:55.26 >>> join/#ghostscript pipitas (~pipitas@p54A00138.dip0.t-ipconnect.de) 13:55.53 Gigs, one of those is definitely a bug, the crash, the ohter, well I'm not sure, so I asked Ray to look at it, 15Gb seems a lot, but.... 13:56.06 Gigs: Eh? Me? What? 13:56.34 Oh, the attachments. Gotcha. 13:57.17 kens: well maybe there's a way to handle them a little more efficiently or something, we'll see 13:57.46 kens: I guess with planar all those color spaces are getting rendered into planar layers? 13:58.02 Thats a question for Robin_Watts :-) 13:58.13 I'm not too hung up on the complex file though, the segfault is more pressing IMO 13:58.18 In planar mode, we render in planar mode, yes :) 13:58.39 Robin_Watts: if you weren't keeping score this file is said to have 750 color spaces :P 13:59.10 kens: you are lucky though, back in the days of DCS2 files I had to get artifex attachments that were sometimes 150 megs 13:59.10 Chans: (ghostbot) in:#ghostscript 13:59.10 Many are duplicates of course 13:59.24 750 separations? 13:59.29 no not separations 13:59.41 I think it's probably a gradient that is decomposed 13:59.42 Well, what matters to planar is the number of separations. 13:59.57 line-by-line gradient fun 14:00.20 one raster image for each line :P 14:00.36 That might explain it 14:00.46 just guessing but it's usually something like that 14:00.49 Robin_Watts: potential memory leak fix is up 14:01.06 paulgardiner: Yeah, will look in a just a mo. mid debugging now. 14:01.18 np 14:04.39 mvrhel_laptop: okay, tor/lcms2 has been updated 14:06.03 FORK(28949) --- fork starting for 'RSSFeeds', PID == 28949, bot_pid == 31304 --- 14:06.04 FORK(28949) !ERROR! cannot load my module: RSSFeeds 14:06.04 FORK(28949) fork: took 1s for RSSFeeds. 14:06.04 FORK(28949) --- fork finished for 'RSSFeeds' --- 14:06.34 tor8: ok. let me see if I can do this 14:08.18 mvrhel_laptop: git checkout -b lcms2 tor/lcms2 14:08.25 or at least that's what I think the command should be 14:11.46 >>> henrys has signed off IRC (*.net *.split) [#ghostscript] 14:12.46 tor8: that matched the command that tortoise git used 14:14.31 mvrhel_laptop: then you want to set it to push to your user repo on casper: 14:14.41 Chans: (ghostbot) in:#ghostscript 14:14.48 git push -u mvrhel lcms2 14:15.12 the -u sets the 'upstream' flag for pull and push 14:16.22 ok so for some reason I had to do a hard reset of my lcms2 branch to yours. It had set it to an earlier checkout. 14:16.34 >>> join/#ghostscript henrys (~henrys@c-50-134-235-109.hsd1.co.comcast.net) 14:16.57 tor8: so now the git push -u mvrhel lcms2 will ensure that it pushes to my repos on casper? 14:17.47 mvrhel_laptop: yes. after the first command with -u you then only need to "git push" and if you're on your local lcms2 branch it will push to mvrhel 14:17.56 "git push -n" if you're unsure of what it will do 14:19.13 >>> join/#ghostscript vtorri (~vtorri@alf94-3-82-66-248-160.fbx.proxad.net) 14:20.24 >>> join/#ghostscript sojic (~sojic@92.55.124.149) 14:23.11 tor8: How can I see what the upstream branch for a given local branch is? 14:23.43 hmm I must have to specify something other than mvrhel in the above command 14:23.59 mvrhel_laptop: "origin" 14:24.05 ok that makes more sense 14:24.14 You have "origin" and "golden", right? 14:24.19 exactly 14:24.32 Robin_Watts: ok that was it 14:24.35 thanks 14:25.13 now lcms2 = origin/lcms2 = tor/lcms2 14:26.47 I have to run a rental car back to airport. Had another flight cancelled yesterday. Had to rent a car and drive from chicago to my parents 14:26.57 geez. 14:27.02 I have decided United is the worst airline 14:27.24 waited 1 hour for them to pull my bags 14:27.35 they had rebooked me on a flight on wed. 14:27.50 anyway. I will probably miss part of mupdf meeting but back shortly 14:30.29 Chans: (ghostbot) in:#ghostscript 14:30.58 >>> henrys has signed off IRC (*.net *.split) [#ghostscript] 14:31.26 paulgardiner: Fix looks fine. 14:32.06 >>> join/#ghostscript henrys (~henrys@c-50-134-235-109.hsd1.co.comcast.net) 14:32.08 I'm slightly bemused by you using the itr=&head; trick in the second part, but using tail in the top half. 14:32.22 but it'll work. 14:33.54 my IRC client showed everyone dropping off IRC and I was the only remaining one in the ghostscript group. I could get a complex from stuff like that. 14:34.40 Robin_Watts: need ** in the second loop because the error case must remove an item from the list. 14:35.14 >>> sojic has signed off IRC (Remote host closed the connection) [#ghostscript] 14:35.37 Right, but the same trick in the first half of the loop (head = NULL; itr = &head; ...... loop { (*itr) = annot; itr = &annot->next }; ) avoids the need for the hairy if in the loop. 14:35.44 Oh, I see what you are saying. I could have used similar to avoid casees int he top 14:35.55 personal preference only. I'll push it as is. 14:36.15 FORK(30803) --- fork starting for 'RSSFeeds', PID == 30803, bot_pid == 31304 --- 14:36.16 FORK(30803) !ERROR! cannot load my module: RSSFeeds 14:36.16 FORK(30803) fork: took 1s for RSSFeeds. 14:36.16 FORK(30803) --- fork finished for 'RSSFeeds' --- 14:36.45 I might change that later - just for consistency 14:39.48 tor8, Robin_Watts: more on this incremental stuff - pdf_dociment_s has page_objs and page_refs. An update might cause them to lose sync 14:40.02 >>> chrisl_away materializes into chrisl 14:40.06 >>> join/#ghostscript Robin_Watts_ (~chatzilla@109.176.197.175) 14:41.02 In fact, any structure that holds an non-indirect obj has potential problems. 14:42.03 paulgardiner: actually, to reduce document load times we could move to using the page tree structs as is instead of pre-flattening into a page list 14:43.06 I believe the page_obj is the only place where we actually hold on to objects (that I've written) ... can't remember about the store though, maybe we use some form of pdf_obj as keys there 14:43.08 >>> join/#ghostscript mrdocs (~mrdocs@c-76-102-153-54.hsd1.ca.comcast.net) 14:43.08 >>> mrdocs has signed off IRC (Changing host) [#ghostscript] 14:43.08 >>> join/#ghostscript mrdocs (~mrdocs@opensuse/member/mrdocs) 14:43.37 Seen: Flushed 7 entries. 14:43.56 navigating the page tree (and name trees, etc) directly without preloading is probably worthwhile doing 14:44.13 the main reason I moved to flattening them was to reduce the need for error checking back before we had exceptions 14:44.13 tor8: I think with the store its the other way round. We use the ref as key in the store where we need to use the actual object 14:45.11 >>> join/#ghostscript sivoais (~zaki@unaffiliated/sivoais) 14:45.25 >>> join/#ghostscript archdori1 (~Fandekasp@27-32-19-26.static.tpgi.com.au) 14:45.27 tor8: why do we have both the objs and refs? (assuming there's a simple explanation that avoids me having to suss it from the code) 14:46.07 Chans: (ghostbot) in:#ghostscript 14:49.18 >>> Fandekasp has signed off IRC (*.net *.split) [#ghostscript] 14:49.18 >>> plinnell has signed off IRC (*.net *.split) [#ghostscript] 14:49.18 >>> Robin_Watts has signed off IRC (*.net *.split) [#ghostscript] 14:49.21 the page_objs have inherited resources and mediaboxes copied into the dictionary 14:50.16 oh, that's bad then. 14:50.21 >>> join/#ghostscript mvrhel_laptop_ (~chatzilla@24-247-151-14.dhcp.klmz.mi.charter.com) 14:50.36 In incremental mode, we'll always immediately update those into a new section. 14:50.38 yeah. I've been meaning to fix it for a couple of years... 14:50.55 >>> sivoais has signed off IRC (Ping timeout: 264 seconds) [#ghostscript] 14:51.08 Similarly, I have code that 'marks/unmarks' dicts by adding bools I think. 14:51.17 I should change those to use the mark/unmark flags. 14:51.18 10 of the mupdf meeting 14:51.31 >>> mvrhel_laptop has signed off IRC (Ping timeout: 264 seconds) [#ghostscript] 14:51.39 Robin_Watts_: the mark/unmark stuff could use the same 'mark' as the garbage collector does 14:51.46 * Robin_Watts_/#ghostscript has tea and is standing by :) 14:51.46 >>> mvrhel_laptop_ materializes into mvrhel_laptop 14:51.58 tor8: indeed. 14:52.07 >>> kens has signed off IRC (Ping timeout: 264 seconds) [#ghostscript] 14:52.18 or maybe just another flag (if there's space) called 'seen' 14:52.22 since that's the most common use 14:52.31 The work involved in this seems to be expanding 14:52.39 I'll make a not of fixing the page tree loading stuff 14:52.42 note* 14:52.59 >>> join/#ghostscript kens (~Miranda@40.249.125.91.dyn.plus.net) 14:53.03 paulgardiner: I think this is highlighting some minor areas that need fixing. 14:53.13 --- Saved uptime records. 14:53.27 paulgardiner: that's not necessarily a bad thing, though. 14:53.30 i.e. they probably ought to be fixed irrespective of this work. this work is just giving us an excuse to do it now. 14:54.52 >>> join/#ghostscript sivoais (~zaki@unaffiliated/sivoais) 14:55.21 tor8: Ah. The code I was half remembering that stashes bools is the "pdf_resources_use_blending" stuff. 14:55.54 and it's not just 'marked or not'. It's "have I been here before, and if I did I decide true or false". 14:56.28 yeah. there may be some places where it's used to prevent infinite recursion on cyclic chains of references 14:58.13 I think the infinite chains of references can be coped with by the marked/unmarked flags in pdf_obj. 14:58.49 I *could* cope with the pdf_resources_use_blending by using 2 more bits out of the flags byte. 14:58.59 2 are used out of 8 so far. 14:59.45 * kens/#ghostscript wonders who the idiot complaining about pdfopt is, and why he won't just go away.... 15:00.27 kens: Give him a link in the bug to the final version in git. 15:00.31 Robin_Watts_: .useBM is the flag we set there. adding a two bits (SEEN, and TRUE/FALSE) flag words there should be generic enough 15:00.38 kens: tell him to report it to the author of the script 15:00.47 And tell him that he can use it by special dispensation. 15:01.09 tor8: right, that's what I was thinking. It's a bit bletcherous though. 15:01.19 well, so is .useBM :) 15:01.22 but if you're OK with it... 15:01.29 tor8: true :) 15:01.39 we need to learn the starbucks customer service acronym "LATTE" 15:02.19 Chans: (ghostbot) in:#ghostscript 15:02.21 having a generic flag things in the pdf_obj structs that's used for cyclic checking etc seems like a better choice than adding voodoo entries in dicts 15:03.19 okay meeting - one of the most exciting aspects of my job is I get to report everyone's most important current project to Miles. Now I've incorporated this into the workflowy, please look at the bottom of the agenda and see if you like your high priority job, please. 15:03.29 pdf_obj_mark could take an integer argument (and use 8 bits or so) perhaps? 15:04.10 chrisl, Robin_Watts_ I did just point out (again) that he can use the previous version of the program.... And since he is using a script to make fiels smaller, using pdfopt.ps is insane, since it only ever makes files bigger.... 15:04.52 henrys: can you post a link? 15:04.54 henrys can I have the URL for the agenda please ? I lost it :-( 15:05.00 * kens/#ghostscript ROFL 15:05.10 dog ate it? 15:05.18 No I just forgot where I put it 15:05.25 * Robin_Watts_/#ghostscript sends link to paul and kens 15:05.26 kens: I assumed he was starting with a linearised file, use ps2pdf to make it smaller, and then pdfopt to make it linearised again...... 15:05.31 THanks Robin_Watts_ 15:05.32 don't post it here! 15:05.58 henrys: What do you mean by "Incremental Update"? 15:06.02 chrisl, I think not, I suspect he doesn't understand teh script a all, and has no idea what it does. Monkey see, monkey do.... 15:06.03 >>> join/#ghostscript sojic (~sojic@92.55.124.149) 15:06.04 Do you mean "progressive loading"? 15:06.05 if you post it here, we'll have to take ghostbot out back and put a bullet in its head... 15:06.31 tor8: Nah, we just use surgery to remove a few neurons. I've had to do that a few times :) 15:06.52 kens: well, he's clearly not using pdfopt to make the file smaller, because it will *never* do that! 15:07.02 chrisl, exactly 15:07.02 FORK(17184) --- fork starting for 'RSSFeeds', PID == 17184, bot_pid == 31304 --- 15:07.03 FORK(17184) !ERROR! cannot load my module: RSSFeeds 15:07.03 FORK(17184) fork: took 1s for RSSFeeds. 15:07.03 FORK(17184) --- fork finished for 'RSSFeeds' --- 15:07.12 one second... 15:09.24 "incremental update" = something that paul needs for digital signatures, and something that he's pretty much on top of (also it's the subject of the conversations we've been having over the past couple of days on here). 15:09.35 I sent it to staff on 6/6/2013 10:12 am should I resend? 15:10.09 Robin_Watts_: I'm sorry yes I was mistakenly under the impression you were doing that. 15:10.15 I'll fix it. 15:11.13 I'm happy to help with it (in fact I spent the past couple of days bashing on pdf_objs to make them more amenable to it), but I think Paul is most of the way there without me, and I suspect we'd be treading on each others toes if I was to continue. 15:12.22 okay changed. 15:12.26 >>> mrdocs materializes into plinnell 15:12.45 My main projects should be progressive display or making pdfwrite work better for text (to enable the customers request for text annotations) 15:12.51 all I don't think the url will change in the near future so a bookmark should work. 15:13.20 let me add a cunning link to the dashboard ? 15:14.18 I guess we could do that but it has to be password protected yes? 15:14.29 yeah, hence cunning. 15:15.09 so how are digital signatures? Having it by September is the goal. 15:17.36 paulgardiner: ^^^ 15:18.37 Chans: (ghostbot) in:#ghostscript 15:18.47 I think Sept should be okay. 15:19.13 This incremental stuff has expanded a bit. 15:19.36 I had a solution but it relied on picking out just the cases we need for annotations and forms. 15:19.37 Can people check the dashboard now? The "Work items" link should be password protected by the same password as for bmpcmp. 15:20.01 If you've opened a bmpcmp window, you may not need to enter a password :) 15:20.02 It is so protected for me 15:20.11 kens: Thanks. 15:20.17 But opens an empty page.... 15:20.33 kens: yeah, I haven't put the secret sauce in there yet :) 15:20.38 Ah OK then 15:21.14 anything to talk about mupdf wise? 15:21.27 We've been discussing today a more systematic technieque. Definitely better in the long run but more work 15:21.28 tor8? 15:22.34 henrys: nothing to add. we've been talking about the incremental update stuff the past few days, but I think we've got a solution figured out now paul just needs to implement it 15:22.39 paulgardiner: I've been following the discussion a bit, but without detailed understanding. 15:23.15 kens: Try again now? 15:23.27 tor8, right I do look forward to your looking at OpenGL, it's something I think we need to start looking at - generally both mupdf and possibly GS 15:23.31 Robin_Watts_ : yes that works for me 15:23.37 thanks. 15:23.46 It depends on the priorities. The quickest was to get signatures might possibly be to stick with what I had for incremental update. 15:23.46 I've got two items on my urgent quick fix list left, and then I'm back to OpenGL. I have got a new linux box set up for running and debugging opengl stuff. 15:24.15 paulgardiner: Do you believe that doing it "the nice way" is going to take more than a day or so ? 15:24.46 No. I think a day or so, but there is the risk that we then see all sorts of thing it breaks. 15:24.48 tor8:oh great. Are you running linux on apple hardware? 15:25.16 henrys: no, bought a new i5 machine with the haswell chipset and an nvidia card 15:25.19 paulgardiner: I think we pursue it for a day or so. If it runs into problems we back hastily away and pretend that those aren't our footprints. 15:25.25 We've realised a few problems like the pageobjs array. I worry there may be more 15:25.40 Robin_Watts_: that would be my preference. 15:25.40 hopefully that covers the bases of all three major gpu vendors (my windows box running amd) 15:26.07 in my experience with opengl development, you have to be really careful about not tripping over vendor driver bugs :( 15:26.09 apple runs nvidia, right ? 15:26.37 apple runs intel, nvidia and amd chips. but with their own (very slowly updated) drivers 15:26.46 paulgardiner: Feel free to get me to do donkey work if required. 15:26.51 I was mostly mentioning the alternative just to be sure henrys was aware of its being a possibility 15:26.57 apple pre-lion was only opengl 2.1 15:27.04 and now they're all the way up to opengl 3.3 15:27.13 (the latest version of opengl is 4.something or other) 15:27.26 don't tell me, 3.3 is a special apple only version, right? :) 15:27.46 Robin_Watts_: the see where we are after I've spent a day on it looks like a good option 15:27.52 Robin_Watts_: well ... the apple opengl 3.x versions *don't* have the backwards compatible profile 15:28.05 so you're either running 2.1 or "core" 3.3 with no backwards compatible stuff at all 15:28.29 tor8: So, are you going to reimplementing the nvidia path rendering from the ground up then? 15:28.55 Robin_Watts_: I'll most likely try several approaches 15:28.57 paulgardiner: we have plenty of time so the "nice way" seems right 15:29.06 henrys: okay good. 15:29.41 tor8: I guess start with the nvidia driver on linux and then we can reimplement it if required? And hope that the rest of the world clues up in the meantime. 15:30.10 Robin_Watts_: yeah. that was the immediate plan. get something up and running using the nvidia path extensions first. 15:30.32 tor8: ok, that still leaves the "fun" of implementing blending in shaders. 15:30.33 well, first of all get some sort of opengl context setup and a viewer that does page flipping and zooming using GLUT or GLFW or something like that 15:30.51 Robin_Watts_: the "fun" will be implementing clipping... 15:31.07 nvidia have code for clipping, I thought ? 15:31.18 kens:were you laughing about starbucks? 15:31.30 they have some crude incomplete examples of clipping using their path rendering 15:32.06 henrys, Robin_Watts_ : should I be doing anything towards text annotations at this stage? 15:32.36 I think that to do general clipping using the stencil mask I'll have to render the clip mask once to a stencil bit plane when pushing the clip, and then clear that bit plane when popping 15:32.37 paulgardiner: Well, we're waiting to hear back from christophe as to whether they are urgent or not, right? 15:32.50 henrys no, I don't think so, when was that ? 15:32.52 the main issue is the limit of 8 bits on the stencil buffers on mobile hardware 15:33.10 Yeah, I haven't seen a reply. 15:33.22 you said ROFL I didn't know what you laughing about. 15:33.36 Oh, maybe I typed in the wrong window.... 15:33.50 Listen to the customer 15:33.52 Ask what the issue was 15:33.54 Take the time to... listen? Haha 15:33.55 Thank the customer 15:33.57 Encourage them to come back 15:33.58 ? 15:34.32 yea I should add it to the agenda ;-) 15:34.33 ah henrys I was ROFL because paulgardiner also asked for the agenda URL 15:34.45 Loser At The Till Emergency? 15:34.55 Chans: (ghostbot) in:#ghostscript 15:36.10 well L could be "lunge" - A "attack" ... 15:36.37 Look At The Total Eejit. 15:37.28 FORK(23555) --- fork starting for 'RSSFeeds', PID == 23555, bot_pid == 31304 --- 15:37.29 FORK(23555) !ERROR! cannot load my module: RSSFeeds 15:37.29 FORK(23555) fork: took 2s for RSSFeeds. 15:37.29 FORK(23555) --- fork finished for 'RSSFeeds' --- 15:37.57 7 past the meeting - see you in 23 minutes. 15:38.25 paulgardiner: looks like you might have a gs customer problem, ugh 15:38.55 * paulgardiner/#ghostscript cries 15:40.15 What's that then? Is there a communication from Raed that hasn't gotten through to me yet? 15:40.36 henrys: maybe we should suggest to marcosw, at this stage, I might as well do a "pre-release" of the commercial code for Raed 15:40.57 I don't think so. I think the problem is probably that Raed is incapable of applying patches. 15:41.33 >>> join/#ghostscript Fandekasp (~Fandekasp@27-32-19-26.static.tpgi.com.au) 15:41.37 well let's see why paulgardiner isn't getting this he must not be on support 15:41.51 henrys: Has there been a mail since this morning? 15:42.13 I have one where Marcos is sending a patched gp_win32.c 15:42.19 last mail I saw was 07:19 our time. 15:42.30 "I used it but now I’m getting the following linking error" 15:42.33 Robin_Watts_: what's more annoying is that he's apparently not willing to *try* the GPL code to see if these changes satisfy his needs :-( 15:42.56 chrisl: Then tell him to wait til august. 15:43.23 the email was sent to Marcos, Paul and Support. 15:43.31 Robin_Watts_: that would be my preference, but marcosw will probably feel different..... 15:43.34 So it would be be odd for Paul not to see it at all. 15:43.34 well let's let marocsw sort though it first. 15:43.44 Seen: Flushed 6 entries. 15:43.53 let me double check he's on support anyway. 15:44.04 At the moment this isn't a customer problem for paulgardiner 15:44.39 The short answer to the email is "yes" 15:45.07 he should change the condition as he suggests, cos that's what we have in our repo. 15:45.09 So far today, I have an email from Joann timed 1:02 and a couple from Orikasa around 9:00 15:46.03 paulgardiner does seem to be on the support mailing list 15:46.26 >>> archdori1 has signed off IRC (*.net *.split) [#ghostscript] 15:47.16 I reckon paulgardiner has already blacklisted Raed....... ;-) 15:47.36 but my last email from Raed was 9 hours ago. 15:47.43 :-) 15:49.53 paulgardiner: you are explicitly in Raed recipient list along with support. 15:50.23 spam blacklist like Chris said :-) 15:50.43 Chans: (ghostbot) in:#ghostscript 15:51.27 ok I am back 15:51.34 henrys: sorry that I missed the mupdf meeting 15:51.53 paulgardiner: I assume you have seen some mail addressed to the artifex domain? 15:52.06 I am going to get started on the ICC stuff w.r.t. mupdf and the windows phone app 15:52.14 yeah, I have some later messages 15:52.33 mvrhel_laptop: hi np about the meeting, I'm barely here myself. 15:52.46 ;-) 15:53.06 paulgardiner: IIRC, did have some problems with Raed's mail being spam-binned a while back, it might be worth checking the gmail spam folder 15:53.36 --- Saved uptime records. 15:53.51 it's fine if it is just spam but if paul's artifex address is not getting used and he's getting some stuff because it is going to the old domain that's not so good. 15:54.23 I looked at my logs. Couldn't see anything suspicious around 7:19 15:54.35 old domain == laser-point 15:55.11 kens: the linux/unix file enumeration code *is* supposed to recurse into folders, but it looks like a couple of typos, and an outright mistake prevent it working 15:55.13 I just forwarded paul a copy of the email to his artifex address and it arrived. 15:55.24 so his artifex address *is* working. 15:55.32 chrisl, well at least I wasn't completely mad :-) 15:55.50 chrisl hopefully it won't be too much effort to fix it. 15:56.02 It's always possible that the mail daemon somewhere along the line had a problem, and it'll arrive in 24 hours time :) 15:56.14 Robin_Watts_:I was just doing the same … so I'll stop 15:56.24 kens: no, but whoever wrote this was bordering on madness - *so* close, but clearly not tested :-( 15:56.43 >>> join/#ghostscript ray_laptop (~chatzilla@rrcs-64-183-45-163.west.biz.rr.com) 15:56.44 henrys: The answers to Raeds questions are "no" and "yes". 15:56.52 He clearly doesn't have the latest version of iapi.c 15:56.54 chrisl yeah that's what really puzzled me, on first inspection it looked like it 'ought' to work. but a very simple test showed it didn't 15:57.09 whether that's because it's badly patched or whether the patch was bad, I can't say. 15:57.52 kens: the descend into directory section was gated on whether the path was too long, but it was comparing it to the length of the pattern string, not the scratch string 15:58.10 Oh, oops that was never going to work 15:58.15 Raed must be sorted and filtered by marcosw before being considered by the rest of engineering ;-) 15:58.44 paulgardiner: I think gmail spam filtering happens even if you have it forwarding to another address, so I'd check that, just in case 15:58.50 * kens/#ghostscript wonders if Henrys is trying to get marcos to resign.... 15:59.05 marcosw loves that stuff. 15:59.29 He must do, otherwise he'd have said "wait until August"! 16:00.10 chrisl: Oh yes. It might have gotten trapped in the gmail's spam filtering before forwarding 16:00.27 we do waste a lot of time if multiple folks get embroiled in this stuff before marcosw has a discussion with the user and separates signal and noise. 16:01.02 gs meeting 16:02.01 all please check the workflow and see that your current high priority project is correct. Read back in the logs for what motivates this. 16:02.19 Yeah. There it is: stuck in gmail's spam filter 16:02.35 s/workflow/workflowy/ the link was sent 6/6 - tech agenda stuff. 16:02.45 don't post the link here. 16:03.22 (or it's linked from the dashboard now) 16:04.02 henrys: you mean we have to look at the tech agenda between meetings ? I liked it the old way where we could ignore things until just before the next meeting ;-) 16:04.08 :) 16:04.42 ray_laptop: no, this is better - it reminds us *what* we're ignoring ;-) 16:05.00 right quarterly idiocy was too infrequent 16:05.24 Now we can have weekly idiocy instead :-) 16:06.01 I, for one, incorporate idiocy into my daily routine, so........ 16:06.16 If nobody else has anything, there's a couple of bugs I'd like to talk about 16:06.26 actually you can still ignore things. I'll update the priority project (Miles' thing) at the meeting. 16:06.29 Chans: (ghostbot) in:#ghostscript 16:06.38 henrys: I think we decided the phone viewer had higher priority to the windows desktop viewer, or it that item the same? 16:06.40 kens: you can go before me. 16:06.44 :-) 16:06.49 First is #430175 16:06.58 a golden oldie 16:06.58 but I do have something after. 16:07.19 yeah, I think we should close it as 'wontfix', but I'd like to hear other opinions, especially Ray 16:07.39 FORK(30776) --- fork starting for 'RSSFeeds', PID == 30776, bot_pid == 31304 --- 16:07.40 FORK(30776) !ERROR! cannot load my module: RSSFeeds 16:07.40 FORK(30776) fork: took 1s for RSSFeeds. 16:07.40 FORK(30776) --- fork finished for 'RSSFeeds' --- 16:07.47 Moslty because he commented on it 8 years ago... 16:07.48 I would also add icc to mupdf as a priority and of course the color bugs are important. I am making some progress on the overprint simulation 16:07.53 kens: if you type "bug 430175" my irc tool will let me link to it (it things things that start with # are channel addresses) 16:08.07 there are some strange issues going on in the ghent tests though 16:08.11 Hmnm, OK ray 16:08.17 will try that on the next one 16:08.28 or try 430175 16:08.36 bug 430175 16:08.41 mvrhel_laptop: will do. 16:09.00 ok. thanks. sorry to interlace in your discussion kens 16:09.06 NP mvrhel_laptop 16:09.09 kens: Chatzilla keys on the "bug ' or 'bug #' 16:09.22 Robin_Watts_ : neither works on Miranda 16:09.42 I could probably do something abou thtat... 16:09.45 copy paste the url will work with all clients 16:09.46 Robin_Watts_: chatzilla doesn't need the # character 16:09.49 I would think 16:09.59 ray_laptop: Right, but it tolerates it, I believe. 16:10.15 Anyway, the point is this has been idle for 8 years, so my feeling is its not important enough to adpot (or we would have done it) 16:10.46 kens: does it look OK to stick in the toolbin ? 16:10.46 kens: IF we do fix it, it should be at the device level, not at the input ps level. 16:10.47 Its also debatable whetheer the authour can still be contacted (I;'m having this problem with bug 226943 as well) 16:11.07 Robin_Watts_ : There's no way we're going to do imposition at the device level 16:11.07 I agree it should be at the device level 16:11.11 kens: true. We can't include it without a CLA 16:11.12 i.e. do stuff like "fineprint" does on windows. 16:11.15 really? 16:11.28 Robin_Watts_: what's fineprint ? 16:11.46 http://fineprint.com/ 16:12.44 Given there are commercial aolutions (quite imposing as well for instance) I'm reluctant to do anything with this PostScript solution. 16:12.44 Installs a windows printer. You print to it, and you get a series of pages that you can view in memory and then reprint as pamphlets, odd pages, even pages etc. 16:13.17 Once we get savepage working, then it becomes possible to think of doing it at the device level nicely. 16:13.20 does it use Ghostscript ? 16:13.26 ray_laptop: No. 16:13.33 savepage is what I want to talk about 16:14.00 Can we come back to that ? 16:14.09 kens: yes (you first) 16:14.11 (Well, we're limited in that the clist is resolution specific so we'd need to pick scales etc beforehand, but...) 16:14.39 It doesn't sound like anyone is massively in favour of a PostScript solution 16:14.52 SO I'd like to 'wontifx' it, any objections ? 16:14.56 I agree to close it as is. 16:14.58 I'd like it closed as wontfix 16:15.10 OK my other one is a bug today 16:15.16 bug 694374 16:15.22 >>> join/#ghostscript mvrhel_laptop_ (~chatzilla@24-247-151-14.dhcp.klmz.mi.charter.com) 16:15.22 Maybe open an enhancement for imposition support that we can all ignore together? 16:15.52 It seems to process slowly (does on Acrobat too) but I cannot see why. Profiling it shows no specific hot spots (10% in decompression, 10% memory stuff are the highest) 16:16.09 But MuPDF can process the file in 1 second (2 minutes for gs) 16:16.38 kens: Does this have lots of nested image tiles in it? 16:16.40 Obviously I can reccomend MuPDF to the reporter, but can someone else take a poke at it and see if they can figure out why its so slow please ? 16:16.51 Robin_Watts_ : Err, maybe 16:17.01 I had a file that was a google maps type thing. 16:17.02 Its got lots of shadings 16:17.10 I'll just put this out: let's just wont fix anything that is ridiculously old. thoughts? 16:17.26 henrys I'm mostly in favour. I would like to do the ramfs one though 16:17.41 If I can contact the patch authour 16:17.42 and they plotted the lowest level tile, then higher res tiles on top of it etc. 16:17.51 Robin_Watts_ : no I don't think its like that 16:17.58 ok. 16:18.09 its *is* a stupidly constructed file, forms nested up to 7 levels deep 16:18.23 WHich 'might' be the problem, but I can't see it on a profiler 16:18.24 I think we had a gs enhancement to port the (much faster) mupdf shading over to gs and replace the mess that gs has 16:18.28 Is there transparency in the file ? 16:18.49 Robin_Watts_ : there is a page group, but removing it made no difference, the other elements are all opaque as far as I can tell 16:18.50 ray_laptop: I am currently in charge of ignoring that enhancement I beloeve. 16:18.56 I'm thinking everyone should look at their bugs and anything over 5 years without comment and of questionable value should be closed maybe as "LATER" 16:19.29 henrys I'm kind of doign that already, though I am putting a request for comment in some threads just in case 16:19.31 >>> sojic has signed off IRC (Remote host closed the connection) [#ghostscript] 16:19.34 agreed? 16:19.51 kens: -Z: will tell you if the clist found any actual transparency in any bands 16:19.52 I'm in favour, these ancient bugs are terrible 16:19.54 >>> tkamppeter has signed off IRC (Ping timeout: 264 seconds) [#ghostscript] 16:19.54 >>> mvrhel_laptop has signed off IRC (Ping timeout: 264 seconds) [#ghostscript] 16:20.01 henrys: agreed 16:20.08 ray OK I'll give that a try, thanks 16:20.16 henrys: fine by me 16:20.16 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 16:20.16 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 16:20.27 >>> mvrhel_laptop_ materializes into mvrhel_laptop 16:20.32 >>> pipitas has signed off IRC (Read error: Connection reset by peer) [#ghostscript] 16:20.36 >>> join/#ghostscript pipitas1 (~pipitas@p54A00138.dip0.t-ipconnect.de) 16:20.51 I'm sure you can create a query 16:20.51 OK I'm done. Ray's turn 16:21.40 I only have a couple that are that old. I need to check this one though and see if this is for real Bug 689792 16:21.40 from 8.62 ..... 16:22.10 Chans: (ghostbot) in:#ghostscript 16:22.22 for cust 801's issue #16 they want to re-order pages. 16:22.41 and the save page is the cleanest approach IMHO 16:23.08 >>> join/#ghostscript tkamppeter (~till@p5480AEE4.dip0.t-ipconnect.de) 16:23.17 I was thinking about adding it to the gx_device_printer class so all page devices that use the clist can use it 16:23.17 This is saving the clist after its generated ? Not the page buffer 16:23.27 kens: right, the clist 16:23.46 that would be useful 16:23.58 that way for them the job starts faster since clist writing is faster than rendering 16:23.59 Making ti available to all devices sounds good. Note that the high level devices don't use the clist though.... 16:24.40 ray_laptop : using -Z: on that file the clist didn't mention transparency at all 16:25.24 what do you all think of having it invoked using printer device params: i.e., save_pages={memory file off flush} 16:25.58 I like that idea 16:26.00 kens: page16 doesn't have transparency (according to pdf_info.ps) 16:26.09 ray_laptop:what about resolution dependency? Will you know the final resolution always when the clist is created? 16:26.12 ray_laptop : yes I had alreadt tried that too 16:26.16 I don't know if it's really in scope for gs, but I can tell you from the prepress side of things, imposition software sucks and you probably could tap a market opportunity. 16:27.00 Gigs-:you should become an OEM, make millions, and give us a cut. 16:27.10 I've thought about it 16:27.16 then to print the saved pages use: -sSavedPagesPrint=string 16:28.02 there is a guy who sells PDF imposition s/w that was in a booth next to us at a show a few years back. 16:28.16 Probably Aandi Inston of Quite Software 16:28.37 Quite Imposing is supposed to be good (I have never used it) 16:29.06 I was thinking the string could be either a list of pages, page ranges, or some common keywords like 'normal' 'reverse' 'even' 'odd' 16:29.23 Hmm, complex parsing, but it sounds good 16:29.25 ray_laptop:the resolution dependency in the clist makes it ineffective as a viewer format I believe. 16:29.31 kens: that's who is was 16:29.48 henrys: this is for printing apps, not the viewer 16:30.01 ray_laptop : I used to meet him a lot, last I heard he was living in what used to be a Victorian hotel on the shores of a loch in Scotland.... 16:30.22 ray_latpop:so printer is low on memory and wants to fall back to a lower resolution - then what? 16:30.31 viewer devices aren't gx_device_printer types 16:31.00 henrys what other alternatives are tehre which are not reolution dependent ? 16:31.11 henrys: saved_pages are not for small memory machines (primarily intended for disk based) 16:31.37 but among other things we could print collated copies 16:32.09 The clist being a resolution dependent device is a killer for some things. 16:32.13 kens: if the input is PDF, we can print any order directly from the PDF and not need the clist 16:32.24 kens:I think most display list formats in use are resolution independent - tor8 or Robin_Watts_ correct me if I'm wrong 16:32.24 We *could* write a "serialiser" device. 16:32.41 ray_laptop : yes certainly, I was thinking more of PostScript and PCL. XPS and PDF the file format effectively is the disply list 16:32.42 Something that just serialises gs device calls to a file. 16:32.51 we _could_ silently convert the non-pdf input to pdf and then do it 16:33.02 Then we have a new input format for gs. 16:33.29 Or we could use pdf as that serialised format. 16:33.56 I've wanted to write a 'pdfmerge' using mupdf for ages. 16:33.58 Robin_Watts_ : gs device calls are not resolution independent I think 16:34.00 right - that's what I believe Apple has done with Quartz more or less. 16:34.01 Robin_Watts_: sort of a variation on the 'txtwrite' device ?? 16:34.53 Something that produces a pdf out by taking 1 or more pages from various pdfs in. Where each page out can optionally come from several pages in. 16:35.26 Robin_Watts_: device call serialisation falls apart a little bit with the text is done in gs - i.e. not as a device method. 16:35.28 most device calls are 'fixed' which have a 8-bit fraction 16:35.29 but I'm not sure if we are getting too ambitious here and beyond the customer schedule horizon. 16:35.41 chrisl: Ugh, ok. 16:35.53 Robin_Watts_: unless we fix that ;-) 16:35.57 Using pdf as the intermediate format would be a sensible step, I suspect. 16:36.06 don't foget images,they have an enumerator too 16:36.13 And then we can use a mupdf based tool to do the page merging. 16:36.22 which is a MUCH less insane route. 16:36.23 henrys: true. The -sSavePages=memory -sSavedPagesPrint= would be pretty fast 16:36.38 since much of it is already there. 16:37.24 but I think you would get a lot more participation, ray_laptop if you didn't use the dreaded clist. 16:37.53 the problem with pdf as the page format is the speed of pdfwrite I think, then needing to re-parse it, but let me do some comparison timings 16:38.03 FORK(9336) --- fork starting for 'RSSFeeds', PID == 9336, bot_pid == 31304 --- 16:38.04 FORK(9336) !ERROR! cannot load my module: RSSFeeds 16:38.04 FORK(9336) fork: took 1s for RSSFeeds. 16:38.04 FORK(9336) --- fork finished for 'RSSFeeds' --- 16:38.13 Chans: (ghostbot) in:#ghostscript 16:38.17 henrys: I agree, and I am drawn to the pdf intermediate approach. 16:38.23 pdfwrite will not be hugely fast, and will require a decent amount of memory and disk space 16:38.45 But its possible its not much worse than the clist. 16:38.53 kens: for this customer, memory and disk space aren't an issue, but SPEED it 16:38.59 Again, please don't forget that some elements may be rendered 16:39.07 I think it should be a new middle level device like pxlcolor level - images, vectors, but not fonts. 16:39.15 kens: I meant to say, I've tried sending a mail through sourceforge to the ramfs guy earlier today - didn't bounce (yet), but haven't heard back yet either. 16:39.31 chrisl I've heard nothing yet either I'm afraid 16:39.38 I may end up having to reimplement it 16:39.57 kens: the clist writing is pretty quick, but rendering from the clist is MUCH more efficient, particularly since the pages will have to be written to clist first, then rendered 16:40.02 chrisl:have you overcome the obstacle with the new directory structure. Is there something to discuss? 16:40.24 henrys: nothing to discuss, I know vaguely where I'm going now 16:40.42 henrys: the problem with any device is that it won't be resolution independent as PDF is 16:41.04 sort of out of it today. Had to put my dog down yesterday after 13 years, been pretty mopey... 16:41.17 * kens/#ghostscript is sorry to hear that :-( 16:41.36 amazing how attached you get. 16:41.45 henrys: sorry to hear that. My dog finished at 15 years last year. 16:41.57 henrys: Crumbs. Sorry. It's a horrible thing to have to do, but (if it's anything like mine was) you know it was the right time, and for the best. 16:42.13 henrys: sorry hear that - went through the same thing with my cat back in February 16:42.25 * ray_laptop/#ghostscript recalls the conference calls with henrys' dog yapping in the background :-) 16:42.27 yes it was the right time, thanks everybody. 16:43.10 yes he was vocal. 16:44.08 ray_laptop:so should we recruit help to your project or do you want to scope it out first? 16:44.09 Seen: Flushed 8 entries. 16:44.39 henrys: I was thinking I could finish my approach with the clist saved pages this week. 16:45.01 given the initial look I've had at what is already there 16:45.04 It shoudl be easy to test the conversion speed to PDF as a comparison from that 16:45.18 I really do hope we can think about a pdf intermediate format - I think that would have some value. 16:45.19 I'm willing to bet the pdfwrite then render approach will be slower 16:45.30 also -sSavePages=file will let us move to a separate process to render the pages 16:45.44 I have to go off and cook, goodnight all 16:45.50 kens:I think we have to think about something much simple than pdfwrite 16:45.51 Robin_Watts_: do you know if here is a way to contact a user through github? 16:46.07 and if the place we write the saved page files to is a pipe, we have a queue on disk 16:46.15 chrisl: Not offhand. 16:46.17 henrys a PDF output that's simpler than pdfwrite ? What were you thinking abou as the content ? 16:46.19 nite, kens 16:46.45 >>> kens has signed off IRC (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) [#ghostscript] 16:46.50 >>> join/#ghostscript sojic (~sojic@92.55.124.20) 16:48.30 henrys: for the customer, I will look at the speed of pdfwrite and compare to clist writing. If pdfwrite is close, then I'll discuss it with everybody. 16:49.17 henrys: but doing anything 'from the ground up' might take too long (if it is a 'high level' type device) 16:49.27 >>> sojic has signed off IRC (Remote host closed the connection) [#ghostscript] 16:50.31 henrys: and probably won't be much faster than the pdfwrite approach. 16:51.20 ray_laptop:I believe the memory and temporary file space might be quite significant different with lower level pdf. 16:51.30 I'm really just thinking you don't need fonts 16:51.38 although some of the pdfwrite stuff to decide on image compression method should be disabled if we are interested in it as an intermediate format 16:52.21 but I'm speculating without any hard data. 16:52.28 ray_laptop: It would be really nice if we could find some way of passing images through without unpacking/repacking them. 16:52.40 henrys: so something like the old pswrite that did fonts as bitmaps (obviously NOT ps, but some format easier to parse). 16:52.53 bbiaw 16:52.58 Robin_Watts_: sorry, but that's a new device interface 16:53.31 but for an intermediate format we could skip compression (the clist doesn't compress images) 16:53.51 Chans: (ghostbot) in:#ghostscript 16:54.01 --- Saved uptime records. 16:54.25 Of the top of my head, could we do it by having a new image enumerator type offered as the first option. It would check to see if the device underneath it (pdfwrite) could accept images without repacking. If it could, then it would claim the call. If not, it would pass on, and the existing enumerator things would handle it. 16:55.04 Robin_Watts_: the image enumerator gets decompressed data 16:55.12 At the moment we have things like the interpolator enumeratee (is that the right term) that can either say "I'll do it" or "pass". 16:55.27 >>> join/#ghostscript gandaro (~gandaro@wikipedia/Gorlingor) 16:56.01 ray_laptop: hmm, ok. 16:56.13 all of the decompression is done by the parser. The graphics library doesn't get to see the original data 16:56.52 Robin_Watts_: but from the performance standpoint, as long as we only decompress once, we're OK 16:56.57 yes like pswrite I always think of pxlcolor because that's my world but they are at a similar leve. 16:57.05 We could add a new device interface that the parser could try calling first ? 16:57.14 but moving less data into the intermediate format _would_ be nice 16:57.28 >>> gandaro has signed off IRC (Read error: Connection reset by peer) [#ghostscript] 16:57.31 and if the device function is there, it could avoid decompressing? otherwise it would fallback and go the normal route? 16:57.32 chrisl:the urw fonts have arrived where do you them? 16:57.49 sorry forgot to say that at the meeting. 16:57.53 It's pretty shocking that in all this time, gs can't pass through images without recompression. 16:58.10 henrys: you can either mail them, or put them up on casper - either is fine 16:58.52 Robin_Watts_: it passes images through uncompressed. It's device specific whether or not the image is recompressed, but obviously pdfwrite wants to compress 16:59.20 Robin_Watts_: but rectifying that in the graphics library is a different enhancement bug 16:59.28 ray_laptop: Right, but we *should* be able to allow images to go through compressed. 16:59.28 chrisl:there on casper. 16:59.35 I added that to mupdf recently. 16:59.53 henrys: thanks, I'll deal with them when I have time 17:00.15 Robin_Watts_: good. But in order to render the pages, mupdf is still "dumb" in that it decompresses the entire pixmap, right ? 17:00.18 so for pdfwrite or svgwrite etc, we can write out the source image data without needing to recompress (and hence with no loss of quality) 17:00.30 chrisl:yes the directory stuff is probably more important. 17:00.50 ray_laptop: Yes. That's not a trivial thing to lift. 17:01.03 We can cope with decoding at subsample levels. 17:01.04 Robin_Watts_: right, it's obviously better for lossy compression to avoid the round-trip 17:01.13 bbiab 17:01.13 but we don't do banded decompression. 17:01.15 henrys: it shouldn't take long to sort out the fonts, I still have all the stuff from when I collated the report 17:01.34 (partly because banded operation is something we don't really do in mupdf - I mean, we support it, but no one uses it like that) 17:01.44 chrisl:really the fonts should go in soon - not just before the release. 17:01.57 like now or after august would be my vote. 17:02.06 Robin_Watts_: if you are zoomed into an image so the area needed is a subset of the image, does mupdf still require the full pixmap ? 17:02.31 Also, the image decompressors we use don't generally have a mechanism for decoding a subsection. 17:02.43 ray_laptop: I wondered if there would be a way to add an interpreter callback to allow the graphics library to access the original data stream for the image, and access whatever point in the filter chain it needed. 17:02.43 * ray_laptop/#ghostscript votes for doing it now, it's far enough ahead of the release 17:03.12 In some cases we could decode the whole thing and throw away the data not in the area we need, but that's still a lot of wasted work. 17:03.24 Robin_Watts_: JPEG is pretty common and is block oriented, right ? 17:03.24 ray_laptop: Yes, mupdf still decodes the entire pixmap. 17:03.30 I'll do the fonts before the end of week - just not looking at it when I have to finish in <10 minutes 17:03.42 but I agree that Flate compressed streams aren't 17:03.43 But very few JPEGs use the restart interval thing. 17:04.01 i.e. you need to decompress the whole bloody thing at least up to the point at which you've got enough. 17:04.10 chrisl: sounds good 17:04.16 bbiab 17:05.23 With progressive decoding it's even worse - you need to decode the whole image anyway, you can't (without some crufty extensions to jpeglib that I wrote for my previous job and are hence not available to us now) decode multiple strips from a progressive jpeg without restarting each time. 17:05.44 openJPEG requires the whole image in memory anyway. 17:05.59 faxes *could* be done line by line. 17:06.45 but then you get one that's flipped the wrong way up, and all your hard work is out the window. You need to go back to decoding on a per band basis. 17:07.21 When we get a customer complaint about image decoding memory size, we'll worry about it then :) 17:08.28 Robin_Watts_: sounds like a good approach 17:08.49 FORK(25601) --- fork starting for 'RSSFeeds', PID == 25601, bot_pid == 31304 --- 17:08.50 FORK(25601) !ERROR! cannot load my module: RSSFeeds 17:08.50 FORK(25601) fork: took 2s for RSSFeeds. 17:08.50 FORK(25601) --- fork finished for 'RSSFeeds' --- 17:09.31 ray_laptop: But surely it must be possible to add a mechanism to gs for passing compressed images across? 17:09.51 Chans: (ghostbot) in:#ghostscript 17:10.50 If the parser hits a jpeg compressed image, call .jpegimage or something. That would try to pass the image data compressed - and if the device doesn't support it, we'd fall back to current code. 17:12.47 PDF could be made to work like that, right? 17:12.52 It's PS that would be harder. 17:13.45 In PS we'd need to magically spot that the stream being fed to an image operation was a DCTDecode one and use the jpegimage call then instead. 17:14.07 and maybe we can't cope in all cases, but we should be able to cope in the common ones? 17:15.06 Robin_Watts_: Adding a special treatment for JPEG (and maybe JPX) may be useful for h.l. devices 17:16.00 Robin_Watts_: a.n.other RIP that I know of used a "fork" filter, which was pushed *first* in any image filter chain, then any interested party could find the fork filter, and pull the un-molested data from there - needed careful handling for the buffering, though. 17:16.03 >>> join/#ghostscript vtorri_ (~vtorri@alf94-3-82-66-248-160.fbx.proxad.net) 17:16.19 Robin_Watts_: but even doing it for Flate compressed would make pdfwrite faster since we could just collect the data 17:16.25 ray_laptop: Right. 17:16.57 chrisl: First is not always right though. 17:17.18 Imagine I have: ASCII85Decode then DCTDecode 17:17.36 You'd want the fork filter to be pushed just before DCTDecode. 17:18.10 In the PDF agent for my previous job, I 'shortstopped' the filters just before the last one if they were an image format and took the compressed data from there. 17:18.13 Robin_Watts_: still handling that in C isn't too bad. I'd just pass the raw data through (even if it's multiple filters) 17:18.42 ray_laptop: Right. In MUPDF we offer both a pointer to the data, and details of the compression used. 17:19.28 Robin_Watts_: the fork filter meta-data included the entire requested filter chain, so decoding to the desired level was easy enough 17:19.28 Robin_Watts_: Oh. Well, we'd have to come up with a much less sensible approach for ghostscript then. ;-) 17:19.37 If a device can cope with the compressed format it takes it. (so pdf can take jpeg straight through), but if it's in a format it doesn't understand (like PNG say), pdf will reject it. 17:20.22 so svgwrite can take PNGs and TIFFs unchanged, but PDF has to decode and flate them. 17:20.31 none of our parsers take in PNG AFAIK 17:20.44 mupdf reads PNGs for XPS 17:20.52 And GhostXPS reads PNGS too therefore 17:21.16 (no, we don't use pnglib, tor wrote his own) 17:21.33 OK. so our xps parser could pass through PNG's to an xpswrite (if we ever get one) 17:21.48 >>> tkamppeter has signed off IRC (*.net *.split) [#ghostscript] 17:21.49 >>> vtorri has signed off IRC (*.net *.split) [#ghostscript] 17:21.51 ray_laptop: We have an xpswrite, right henrys? 17:22.20 Robin_Watts_: I think all it can do so far is 'tiger' 17:22.21 Robin_Watts_: the other problem is making sure that no where do we try to up/down sample, change color space etc of the image "samples" being passed around. 17:23.04 if pdfwrite is changing the colorspace, it will have to decompress, and it'll probably just 'punt' on the call in that case 17:23.16 chrisl: The point of passing the compressed data is so we'd avoid all that code. 17:24.06 I'm just saying it may not be totally obvious everywhere that the samples can be "touched" 17:24.45 and I guess if pdfwrite determines (from the image parameters) that it needs to resample, it would also just use the current methods 17:24.54 ray_laptop: Right. 17:25.25 chrisl: The compressed and uncompressed paths would have to be more or less completely separate (after the initial detection) 17:25.35 Chans: (ghostbot) in:#ghostscript 17:25.59 but many times we DON'T need to resample, particularly if the image is already pretty low res, and then avoiding a JPEG round trip is particularly important 17:26.11 yes. 17:26.46 sounds like a good project for kens since he now has BOTH the pdf interpreter and the pdf writer :-) 17:26.54 I think this would be a massive step forward for pdfwrite, but I accept that I could be horribly underestimating the complexity involved. 17:27.10 Robin_Watts_: yes, you probably are. 17:27.34 When I originally talked this over with Ken it was purely from a quality POV and not performance, and we'd discussed giving pdfwrite access to the original data, and leaving the current image code doing as it currently does 17:27.34 we usually leave massively underestimating the scope to management 17:27.35 Don't get me wrong, I think it'll be hard. But I do think it's possible :) 17:28.33 chrisl: How can you give pdfwrite access to the original data without doing what I suggest? 17:29.25 >>> join/#ghostscript tkamppeter (~till@p5480AEE4.dip0.t-ipconnect.de) 17:30.09 Robin_Watts_: using the generic "custom" device method you added to the device interface, we could pass buffers of data. 17:30.49 the info that came in from cust 801 is interesting! 17:31.02 chrisl: but the trick is in spotting what those buffers of data is, right? 17:31.09 s/is/are/ 17:32.04 Robin_Watts_: so we have an "image data pending" call with any relevant data, then the buffers of image data, then a "done" call. 17:32.27 So that would be a PDF only solution? 17:32.49 No, PS, too. Just a hook in the image operator 17:33.34 So the image operator would spot that it was being called with a DCTDecode stream and do something special? 17:33.35 Anyway, it's moot, as it doesn't address the problem you guys are looking at 17:34.34 Robin_Watts_: no, any image would cause the calls to happen, and the target device would handle the buffers (or ignore it) as required 17:35.48 Eek, I have to go - Robin_Watts_ like I say, this stuff wouldn't help performance, so it's not really relevant 17:36.21 >>> chrisl materializes into chrisl_away 17:36.44 chrisl: Ah, I see. 17:38.23 I think passing in the compression format would be sensible (as the zimage code can spot it from the stream), and (AIUI) only one thing can 'suck' the data out of a stream. So getting the data out from the stream in order to pass it across means you can't easily get it out again to pass to the regular image calls. 17:39.13 FORK(14918) --- fork starting for 'RSSFeeds', PID == 14918, bot_pid == 31304 --- 17:39.14 FORK(14918) !ERROR! cannot load my module: RSSFeeds 17:39.14 FORK(14918) fork: took 1s for RSSFeeds. 17:39.14 FORK(14918) --- fork finished for 'RSSFeeds' --- 17:42.39 Chans: (ghostbot) in:#ghostscript 17:44.19 Seen: Flushed 6 entries. 17:54.19 --- Saved uptime records. 17:58.35 Chans: (ghostbot) in:#ghostscript 17:58.48 tor8: 2 commits on robin/master for you. 18:09.55 FORK(24270) --- fork starting for 'RSSFeeds', PID == 24270, bot_pid == 31304 --- 18:09.56 FORK(24270) !ERROR! cannot load my module: RSSFeeds 18:09.56 FORK(24270) fork: took 1s for RSSFeeds. 18:09.56 FORK(24270) --- fork finished for 'RSSFeeds' --- 18:15.09 Chans: (ghostbot) in:#ghostscript 18:31.46 working from one of our multipage sample files, 0.pdf (80 pages), it takes 8.3 seconds to write the clist or to write a pdf (also at 600 dpi). 18:34.42 the kicker is that rendering from the clist only takes 4 seconds, but rendering from the saved pdf takes 8.1 seconds even with BGPrint=true (with BGPrint=false it takes 9.8 seconds) 18:35.48 The other "gotcha" is that the customer's files are likely to have complex Japanese fonts which will make the double pass processing even worse. 18:36.05 I'm looking for a multi-page Japanese file to check that 18:37.54 henrys: Robin_Watts: (and anybody else that chimed in): I think that the saved page in clist format is going to have to be the approach for the customer. It's the fastest to implement (other than pdfwrite) and is going to give the best throughput. 18:40.05 FORK(28941) --- fork starting for 'RSSFeeds', PID == 28941, bot_pid == 31304 --- 18:40.06 FORK(28941) !ERROR! cannot load my module: RSSFeeds 18:40.06 FORK(28941) fork: took 1s for RSSFeeds. 18:40.06 FORK(28941) --- fork finished for 'RSSFeeds' --- 18:41.43 >>> vtorri_ has signed off IRC (Ping timeout: 240 seconds) [#ghostscript] 18:44.21 Seen: Flushed 2 entries. 18:47.19 Chans: (ghostbot) in:#ghostscript 18:54.23 --- Saved uptime records. 18:54.58 did that file have images in? 18:59.03 Robin_Watts_: 0.pdf doesn't have much image data 19:01.51 and ibm.pdf is a file with Japanese that I tested. Takes 4.6 seconds to write the clist OR pdfwrite, but renders in 1.6 seconds (has 68 pages) 19:03.12 I'm surprised that pdfwrite can write as fast as the clist. 19:03.22 Chans: (ghostbot) in:#ghostscript 19:03.50 and for situations where 1:1 output is possible, the clist is probably a better bet. 19:04.14 but for resolution independence pdfwrite seems a reasonable idea. 19:04.16 Robin_Watts_: I'm not, and for some files, pdfwrite _may_ win (with shadings) 19:04.50 Robin_Watts_: agreed 19:05.32 and if size of output is critical, then clist will be bigger than PDF, particularly with images 19:10.37 FORK(4219) --- fork starting for 'RSSFeeds', PID == 4219, bot_pid == 31304 --- 19:10.38 FORK(4219) !ERROR! cannot load my module: RSSFeeds 19:10.38 FORK(4219) fork: took 1s for RSSFeeds. 19:10.38 FORK(4219) --- fork finished for 'RSSFeeds' --- 19:15.52 well, for ibm.pdf that isn't quite true. On some pages clist is smaller and on some it's bigger :-/ 19:16.18 but performance-wise, when the resolution is known, clist is a clear winner 19:16.46 Robin_Watts_: are you willing to help me come up with UI names? 19:17.13 UI names ? sure 19:17.59 Robin_Watts_: initially I was thinking: -sSavePages=___ where ___ is "memory" or "file" or "off" 19:18.56 and -sSavedPagePrint=____ where the string is either a bunch of page ranges or keyword: "normal" "reverse" "even" "odd" 19:19.26 Chans: (ghostbot) in:#ghostscript 19:19.30 and having a parameter an application could interrogate: SavePageCount 19:20.13 I might be tempted to go with -sSavedPages="1-10" etc 19:20.29 because that's the one param that people usefully have to use. 19:20.57 I like the verb in there, but PrintSavedPages=____ would be OK 19:21.18 Are you intending that this is something that will work for all devices? 19:21.35 it'll be off unless people turn it on ? 19:21.38 Robin_Watts_: all 'printer' class devices (clist capable) 19:21.46 Right. so I was wrong. 19:21.51 Robin_Watts_: yes, default is "off" 19:22.02 -sSavePages="memory/file/off" is the one that people HAVE to use. 19:22.16 Robin_Watts_: and if it's on, then it forces clist mode, even if it's a single band 19:23.04 You could have -sSavePagesTo="memory/file" 19:23.20 and then have -sSavePages="page selection" 19:23.31 and by sending a selection that implicitly turns it on. 19:23.32 -sSavePages=flush will be the one that will clean up the clist files that were accumulated 19:23.54 ray_laptop: Thats for clearing up after a crash? 19:24.01 shouldn't need it in normal use? 19:24.57 Robin_Watts_: so for multiple copies, the saved page print mode would implicitly collate the copies ? 19:25.38 but if someone wanted "even" then "odd" we'd only delete the ones that were printed ? 19:26.01 Sorry, I'm not following. 19:26.21 I was thinking an explicit "flush" so they could do multiple -sSavedPagePrint=____ actions before flushing 19:26.35 >>> chrisl_r61 has signed off IRC (Remote host closed the connection) [#ghostscript] 19:26.46 Why would we want to allow multiple SavedPagePrint actions? 19:26.59 and how would that even work? 19:27.13 In gs, -sSavedPagePrint sets a string in a dictionary, right? 19:27.14 Robin_Watts_: I used this at my previous company (with ghostscript saved pages) to do one copy of a job, as a "proof" then if it's OK, print N copies 19:27.19 how can you have multiple ones? 19:27.34 these would be printer device parameters 19:27.47 ray_laptop: Give me a command line ? 19:28.53 gs -sDEVICE=ljet4 -o lpr: -sSavedPagePrint="odds,pause,even" in.pdf 19:28.59 gs -sDEVICE=ppmraw -o x-%d.ppm -sSavePages=memory 0.pdf -sSavedPagesPrint=reverse -sSavePages=flush 19:29.24 Robin_Watts_: what would "pause" do ? 19:29.39 pause and wait for user input. akin to showpage. 19:30.00 Give people a chance to take the paper out, and reinsert it for the other side to be printed. 19:30.02 manual duplexing. 19:30.13 or to check for a proof. 19:30.27 I don't see how your command line would work. 19:30.44 Robin_Watts_: well, the printer device doesn't have access to gs_stdin, but we _could_ parse for pause in the command line processing and send the "even" then pause for input, then the "odd" 19:31.00 I see that 0.pdf would run and the pages would be saved. 19:31.22 but then when we process -sSavedPagesPrint=reverse, all that would do is set a dictionary param. 19:31.32 Robin_Watts_: right, then the next argument is processed (-sSavedPagesPrint=reverse) 19:31.32 how can that actually trigger an action? 19:31.45 Is there some special class of param that I'm not familiar with ? 19:31.55 Robin_Watts_: it gets sent to the printer device as a parameter (using putdeviceprops) 19:32.19 Right, that's what I don't understand. 19:32.53 so the parameter is detected in gdev_prn_get_params 19:33.07 My understanding (probably flawed) was that it would go into a dictionary. And that dictionary would only get sent to the device when we do the next round of get_params/put_params. and that only happens when we have a new file to process. 19:33.48 Robin_Watts_: we can do whatever we want with the parameters on the command line 19:34.06 We should not introduce special cases for this work. 19:35.04 Before we go any further, let's make sure I'm not talking rubbish. 19:35.30 well, the way that doesn't require a special case is sort of UGLY: -c "<< /SavedPagesPrint (even) >> setpagedevice" 19:35.53 Chans: (ghostbot) in:#ghostscript 19:36.20 OK, so what I was saying was right? As it stands at the moment, without adding special cases, just using trailing -sBLAH won't work ? 19:36.21 but an application (or a printer that uses the gsapi_run_string) would do that 19:36.32 * ray_laptop/#ghostscript looks at the code 19:36.54 I don't see why we need to reach for the special cases. 19:37.15 Surely we can achieve exactly what we want without changing anything. 19:37.46 gs -sDEVICE=ppmraw -o x-%d.ppm -sSavePages=memory -sSavedPagesPrint=reverse 0.pdf 19:38.33 And if you want to allow for proofing: 19:38.56 gs -sDEVICE=ppmraw -o x-%d.ppm -sSavePages=memory -sSavedPagesPrint=reverse,pause,reverse 0.pdf 19:39.21 Robin_Watts_: that works for the keyword modes, but if you don't know page ranges ? 19:39.44 ray_laptop: Well, you run the bbox device first. 19:39.52 I should have brought this up a the meeting but I'm wondering if we shouldn't start using Skype a bit. The new salesperson is going to come on board soon and IRC has deficiencies in 2 areas: sort of geeky and can't talk about customers. Any thoughts? 19:39.54 YUCK! 19:40.01 or you use things like: even,odd,1-10,12-13 19:40.16 I don't see how your solution helps. 19:40.24 henrys: not about Skype, about Robin's idea 19:40.30 henrys: I do use skype. 19:40.32 of the using the bbox device 19:40.48 The MuPDF customer talks to me on skype. 19:40.49 FORK(2021) --- fork starting for 'RSSFeeds', PID == 2021, bot_pid == 31304 --- 19:40.50 FORK(2021) !ERROR! cannot load my module: RSSFeeds 19:40.50 FORK(2021) fork: took 2s for RSSFeeds. 19:40.50 FORK(2021) --- fork finished for 'RSSFeeds' --- 19:40.54 I talk to Scott on skype. 19:40.55 henrys: we can talk about customers on private chats 19:41.22 Robin_Watts:yes I know but this would involve a commercial app I believe because the free stuff is just one on one right? 19:41.24 but I try not to use it to talk to (say) tor or paul, because discussions here are logged and public. 19:41.59 henrys: free skype can do voice calls between n people. 19:42.13 for video calls, at least one of you needs a premium subscription. 19:42.29 henrys: it was you who wanted mvrhel_laptop and I to discuss things here so others could listen (and learn?) -- or just chime in with irritating questions ;-) 19:42.40 ray_laptop: sorry :) 19:42.58 Robin_Watts_: I didn't mean you. I meant henrys ;-) 19:43.42 ray_laptop: Most of the time for page ranges, you want evens, or odds, or 1-10, or 25- or something. 19:44.20 I'd imagine it'd be unusual to want to print the saved pages, THEN decide on the page ranges. 19:45.00 Seen: Flushed 3 entries. 19:45.31 I am not saying get rid of IRC as the primary interchange, but if the new salesperson is going to get involved it would be convenient to say okay this is not okay for IRC let's switch to Skype for this discussion. 19:45.51 Robin_Watts_: so we'd always "flush" after printing ? 19:46.05 anyway just something to think about. 19:46.12 yes. 19:46.40 henrys: I don't think it's at all unreasonable to suggest we should all install skype. 19:46.57 and be logged into it. and share contact details with each other. 19:47.26 I have Skype (and a skype account) but I usually have it as "offline" so people don't bother me 19:48.12 you would be alerted on IRC that there is a Skype meeting, enable it, then turn it off. 19:48.14 I have ray in skype. I don't have henry. 19:48.31 somehow my skype ID has been picked up by advertisers and if I'm online I usually get 6 or more chat requests from people I don't know 19:48.48 Yes I haven't done anything with it yet, or I did a long time ago and forgot everything. 19:48.56 ray_laptop: Did you allow your id to go into the directory? 19:49.15 >>> join/#ghostscript marcosw_ (~marcosw@eduroam-226-47.ucsc.edu) 19:49.36 there's that guy who missed the meeting ;-) 19:50.02 >>> marcosw_ has signed off IRC (Client Quit) [#ghostscript] 19:50.04 Robin_Watts_: but the other thing is the customer wants to run in server mode (and we want him to) to avoid first page startup times 19:50.15 >>> join/#ghostscript marcosw_ (~marcosw@eduroam-226-47.ucsc.edu) 19:50.43 ray_laptop: And what that I am suggesting is a problem with that? 19:51.33 Chans: (ghostbot) in:#ghostscript 19:51.50 I think we'd need a strong reason to make it so that saved pages persist beyond the lifetime of the file. 19:51.52 so that's why I was thinking of doing it after the file was processed. Also what if there are multiple files on the command line: in1.ps in2.ps -- when do we "apply" the print action 19:52.14 Robin_Watts_: the printer device has NO idea what file the pages come from 19:52.42 sorry about missing this morning's meeting. I was working on my car; a 30 minute job ended up taking me over an hour. 19:53.03 a phd working on a car, impossible. 19:53.16 ray_laptop: Ah. Now you're making it sound like we want something like: 19:53.39 henrys: 1) yes, he was trying to put fuel in it. 19:53.53 so another variation is to have some pseudo operators that can be used: -c "(1-10, 25) SavePagesPrint" 19:53.59 henrys: 2) yes, that's why the job took so long. 19:54.05 henrys: 3) etc. 19:54.17 these would send the parameter to the device with the string 19:54.27 --- Saved uptime records. 19:54.29 marcosw_:look forward to the plotter results but I'm afraid they aren't going to help. This is a tough one. 19:55.18 gs -sSavePages="memory" in1.ps in2.ps -sSavedPagePrint="1,2,3....-c ".savedPagePrint" (or something) 19:56.52 Robin_Watts_: as long as we have to use the -c syntax, then I prefer -c "(1-10, 25) SavedPagesPrint" 19:57.19 the -sSavedPagePrint="1-10,25" is redundant and no less confusing 19:57.21 Is SavedPagesPrint a postscript command then? 19:57.22 IMHO 19:58.02 Robin_Watts_: yes, set up as a pseudo operator in gs_init.ps (or one of the init files) 19:58.26 Actually, I dislike relying on PS. Think about pcl etc. 19:58.49 Can we define a new command line thing, like: --savedPagesPrint=..... 19:59.06 that would work on pcl/ps etc much nicer. 19:59.45 And it can be implemented the same on all languages. (It could call a dso?) 19:59.55 it would perform the somewhat less handy: mark /SavedPagesPrint (1-10,25) currentdevice .putdeviceprops 20:00.18 by all means have it exposed within ps, but we should not *require* ps. 20:00.46 Robin_Watts_: -c is specific to PS 20:01.03 Right. hence me saying we shouldn't use -c. 20:01.09 We should use a new thing. 20:01.19 Like --savedPagesPrint 20:01.27 we already support things like --debug 20:01.52 but a defining a new command line thingy would be doable in plmain arg processor OR ps arg processor 20:02.02 and by adding a new thing, we aren't complicating and overloading existing functionality like -s. 20:02.23 right. where possible we should avoid ps. 20:03.08 Robin_Watts_: OK. That's acceptable to me. So would you thing --SavePages=___ and --SavedPagesPrint=___ ... 20:03.41 it requires implementing in plmain.c and imainarg.c, but not a big deal 20:04.20 I've only implemented --debug in imainarg.c 20:04.38 Robin_Watts_: so it doesn't work with PCL ? 20:04.44 does too. 20:05.12 PCL doesn't use imainarg 20:05.27 Then how is --debug working!? 20:06.35 "main/debugobj/pcl6.exe --debug" gives me a list of debug flags. 20:07.43 Chans: (ghostbot) in:#ghostscript 20:08.02 Robin_Watts_: well, somebody did it (henrys?). Look at pl/plmain.c line 943 20:08.08 oh, it's in plmain.c too! 20:08.17 Phew. grepping for "--debug" wasn't showing it up :) 20:08.35 sorry about that, so yes, needed in 2 places. 20:08.44 but the actual implementation can be common. 20:08.48 but in any case, adding some slightly special code in plmain as well as imainarg doesn't bother me 20:09.02 That seems a far nicer solution to me, personally. 20:09.11 Robin_Watts_: and I agree that the implementation can (probably) be shared 20:09.48 I'm still not convinced about flushing implicitly 20:10.14 no, flushing implicitly doesn't work this way. 20:10.25 Robin_Watts_: it could 20:10.34 could it? 20:10.49 Then maybe we should have a way to disable automatic flushing ? 20:10.57 i.e. have it automatically flush by default? 20:11.14 I'm gonna have to go in a minute, so if I disappear, that's why, sorry. 20:11.24 FORK(11495) --- fork starting for 'RSSFeeds', PID == 11495, bot_pid == 31304 --- 20:11.25 FORK(11495) !ERROR! cannot load my module: RSSFeeds 20:11.25 FORK(11495) fork: took 1s for RSSFeeds. 20:11.25 FORK(11495) --- fork finished for 'RSSFeeds' --- 20:11.33 gs -sDEVICE=ppmraw -o x-%d.ppm --SavePages=memory in.pdf --SavePagesPrint=even,odd 20:12.24 it could keep the clist files and the list in memory for a second --SavePagesPrint=reverse or we could require --SavedPagesFlush 20:12.59 or maybe just use --SavePages=flush 20:14.03 and the question is whether or not we keep saved pages around after gs exits. I would think for --SavePages=file then, yes 20:14.11 I like the idea of a single --savepages flag. 20:14.22 unless someone explicitly does SavedPagesFlush 20:14.50 --savepages={memory,flush} 20:14.52 Well, it's easier to remember 20:14.54 or a page range. 20:15.08 even/odd/1-10,12- 20:15.20 Could we offer: 1:10 ? 20:15.27 meaning 10 copies of page 1 ? 20:15.37 --SavePages="print even" 20:15.40 or evens:10 20:15.45 why print ? 20:16.03 just because I like it :-) 20:16.20 personally I dislike HavingToRememberToShiftCaps 20:16.49 gotta go, sorry. 20:17.11 I also prefer "copies=10 print normal" to "normal:10" 20:18.17 I'll work on the saving and printing given printer device params and we'll discuss the UI more later 20:20.17 >>> join/#ghostscript henrys_ (~henrys@c-50-134-235-109.hsd1.co.comcast.net) 20:20.17 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 20:20.17 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 20:21.09 >>> henrys has signed off IRC (Ping timeout: 256 seconds) [#ghostscript] 20:21.09 >>> henrys_ materializes into henrys 20:24.09 Chans: (ghostbot) in:#ghostscript 20:31.36 >>> ray_laptop has signed off IRC (Ping timeout: 256 seconds) [#ghostscript] 20:38.13 >>> join/#ghostscript sojic (~sojic@92.55.124.152) 20:39.43 Chans: (ghostbot) in:#ghostscript 20:42.01 FORK(6319) --- fork starting for 'RSSFeeds', PID == 6319, bot_pid == 31304 --- 20:42.02 FORK(6319) !ERROR! cannot load my module: RSSFeeds 20:42.02 FORK(6319) fork: took 1s for RSSFeeds. 20:42.02 FORK(6319) --- fork finished for 'RSSFeeds' --- 20:45.09 Seen: Flushed 4 entries. 20:47.43 >>> sojic has signed off IRC (Remote host closed the connection) [#ghostscript] 20:50.37 >>> join/#ghostscript vtorri_ (~vtorri@alf94-3-82-66-248-160.fbx.proxad.net) 20:55.09 --- Saved uptime records. 20:55.27 >>> join/#ghostscript gandaro (~gandaro@wikipedia/Gorlingor) 20:55.40 >>> join/#ghostscript henrys_ (~henrys@c-50-134-235-109.hsd1.co.comcast.net) 20:55.50 Chans: (ghostbot) in:#ghostscript 20:56.55 >>> henrys has signed off IRC (Ping timeout: 264 seconds) [#ghostscript] 20:56.55 >>> henrys_ materializes into henrys 21:12.03 Chans: (ghostbot) in:#ghostscript 21:12.13 FORK(15134) --- fork starting for 'RSSFeeds', PID == 15134, bot_pid == 31304 --- 21:12.14 FORK(15134) !ERROR! cannot load my module: RSSFeeds 21:12.14 FORK(15134) fork: took 1s for RSSFeeds. 21:12.14 FORK(15134) --- fork finished for 'RSSFeeds' --- 21:20.04 Robin_Watts_: two commits look fine 21:20.10 >>> marcosw_ has signed off IRC (Quit: marcosw_) [#ghostscript] 21:28.19 Chans: (ghostbot) in:#ghostscript 21:41.07 >>> tor8 has signed off IRC (Quit: tor8) [#ghostscript] 21:42.15 FORK(21152) --- fork starting for 'RSSFeeds', PID == 21152, bot_pid == 31304 --- 21:42.16 FORK(21152) !ERROR! cannot load my module: RSSFeeds 21:42.16 FORK(21152) fork: took 1s for RSSFeeds. 21:42.16 FORK(21152) --- fork finished for 'RSSFeeds' --- 21:42.20 >>> join/#ghostscript sojic (~sojic@92.55.124.152) 21:44.33 Chans: (ghostbot) in:#ghostscript 21:45.33 Seen: Flushed 1 entries. 21:55.23 --- Saved uptime records. 21:56.43 >>> paulgardiner has signed off IRC (Quit: ChatZilla 0.9.90 [Firefox 21.0/20130511120803]) [#ghostscript] 22:00.37 Chans: (ghostbot) in:#ghostscript 22:01.31 >>> sojic has signed off IRC (Remote host closed the connection) [#ghostscript] 22:07.15 >>> gandaro has signed off IRC (Quit: Leaving) [#ghostscript] 22:12.57 FORK(1743) --- fork starting for 'RSSFeeds', PID == 1743, bot_pid == 31304 --- 22:12.58 FORK(1743) !ERROR! cannot load my module: RSSFeeds 22:12.58 FORK(1743) fork: took 1s for RSSFeeds. 22:12.58 FORK(1743) --- fork finished for 'RSSFeeds' --- 22:14.16 >>> join/#ghostscript sojic (~sojic@92.55.124.152) 22:16.03 Chans: (ghostbot) in:#ghostscript 22:19.55 >>> mvrhel_laptop has signed off IRC (Read error: Connection reset by peer) [#ghostscript] 22:20.23 >>> join/#ghostscript mvrhel_laptop (~chatzilla@24-247-151-14.dhcp.klmz.mi.charter.com) 22:21.13 ircCheck: possible lost in space; checking.Tue Jun 25 22:21:13 2013 22:21.13 >ghostbot< TEST 22:21.13 IRCTEST: Yes, we're alive. 22:32.05 Chans: (ghostbot) in:#ghostscript 22:43.15 FORK(10567) --- fork starting for 'RSSFeeds', PID == 10567, bot_pid == 31304 --- 22:43.16 FORK(10567) !ERROR! cannot load my module: RSSFeeds 22:43.16 FORK(10567) fork: took 1s for RSSFeeds. 22:43.16 FORK(10567) --- fork finished for 'RSSFeeds' --- 22:51.22 >>> sojic has signed off IRC (Remote host closed the connection) [#ghostscript] 22:55.25 --- Saved uptime records. 23:04.15 Chans: (ghostbot) in:#ghostscript 23:13.27 FORK(10170) --- fork starting for 'RSSFeeds', PID == 10170, bot_pid == 31304 --- 23:13.28 FORK(10170) !ERROR! cannot load my module: RSSFeeds 23:13.28 FORK(10170) fork: took 1s for RSSFeeds. 23:13.28 FORK(10170) --- fork finished for 'RSSFeeds' --- 23:24.47 LOG: last message repeated 3 times 23:24.47 ircCheck: possible lost in space; checking.Tue Jun 25 23:24:47 2013 23:24.47 >ghostbot< TEST 23:24.47 IRCTEST: Yes, we're alive. 23:24.48 tor8: (FOr the logs) Thanks. 23:36.03 Chans: (ghostbot) in:#ghostscript 23:43.37 FORK(29719) --- fork starting for 'RSSFeeds', PID == 29719, bot_pid == 31304 --- 23:43.38 FORK(29719) !ERROR! cannot load my module: RSSFeeds 23:43.38 FORK(29719) fork: took 1s for RSSFeeds. 23:43.38 FORK(29719) --- fork finished for 'RSSFeeds' --- 23:45.55 Seen: Flushed 1 entries. 23:47.13 >>> join/#ghostscript sojic (~sojic@92.55.124.152) 23:51.29 Chans: (ghostbot) in:#ghostscript 23:55.55 --- Saved uptime records.