00:10.30 Opened logfile log/20131015. 00:10.29 LOG: last message repeated 3 times 00:10.30 Seen: Flushed 2 entries. 00:11.00 --- Saved uptime records. 00:15.59 Chans: (ghostbot) in:#ghostscript 00:25.40 FORK(18960) --- fork starting for 'RSSFeeds', PID == 18960, bot_pid == 27362 --- 00:25.41 FORK(18960) !ERROR! cannot load my module: RSSFeeds 00:25.41 FORK(18960) fork: took 2s for RSSFeeds. 00:25.41 FORK(18960) --- fork finished for 'RSSFeeds' --- 00:27.27 marosw: you there? 00:27.33 marcosw 00:28.12 bug 694707 is fixed now. but I did not know how you wanted to handle it. also it would be good to add that file to the regression testing 00:28.30 the fix resulted in no changes in the cluster push 00:28.54 it occurs only in an odd case with various isolated / non-isolated transparency groups 00:29.12 now back to mupdf again 00:29.23 henrys: so the meeting is at 7:30 PDT tomorrow? 00:29.28 until 8:15 00:29.51 mvrhel_laptop: yes 00:30.03 did you read the logs about lcms? 00:32.09 Chans: (ghostbot) in:#ghostscript 00:33.08 henrys: yes. I made a comment above about it 00:33.22 then I should read the logs ;-) 00:33.59 :) 00:34.18 done for the night I think. I need to get over this cold 00:48.39 Chans: (ghostbot) in:#ghostscript 00:56.19 FORK(25517) --- fork starting for 'RSSFeeds', PID == 25517, bot_pid == 27362 --- 00:56.20 FORK(25517) !ERROR! cannot load my module: RSSFeeds 00:56.20 FORK(25517) fork: took 1s for RSSFeeds. 00:56.20 FORK(25517) --- fork finished for 'RSSFeeds' --- 01:10.49 Seen: Flushed 2 entries. 01:11.11 --- Saved uptime records. 01:20.39 Chans: (ghostbot) in:#ghostscript 01:26.59 FORK(26024) --- fork starting for 'RSSFeeds', PID == 26024, bot_pid == 27362 --- 01:27.00 FORK(26024) !ERROR! cannot load my module: RSSFeeds 01:27.00 FORK(26024) fork: took 1s for RSSFeeds. 01:27.00 FORK(26024) --- fork finished for 'RSSFeeds' --- 01:33.49 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 01:33.49 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 01:36.29 Chans: (ghostbot) in:#ghostscript 01:36.29 ircCheck: possible lost in space; checking.Tue Oct 15 01:36:29 2013 01:36.29 >ghostbot< TEST 01:36.29 IRCTEST: Yes, we're alive. 01:52.57 Chans: (ghostbot) in:#ghostscript 01:57.37 FORK(26891) --- fork starting for 'RSSFeeds', PID == 26891, bot_pid == 27362 --- 01:57.38 FORK(26891) !ERROR! cannot load my module: RSSFeeds 01:57.38 FORK(26891) fork: took 1s for RSSFeeds. 01:57.38 FORK(26891) --- fork finished for 'RSSFeeds' --- 02:09.18 >>> sebras2 materializes into sebras-work 02:11.27 --- Saved uptime records. 02:25.07 Chans: (ghostbot) in:#ghostscript 02:28.07 FORK(27204) --- fork starting for 'RSSFeeds', PID == 27204, bot_pid == 27362 --- 02:28.08 FORK(27204) !ERROR! cannot load my module: RSSFeeds 02:28.08 FORK(27204) fork: took 1s for RSSFeeds. 02:28.08 FORK(27204) --- fork finished for 'RSSFeeds' --- 02:41.07 LOG: last message repeated 3 times 02:41.07 ircCheck: possible lost in space; checking.Tue Oct 15 02:41:07 2013 02:41.07 >ghostbot< TEST 02:41.07 IRCTEST: Yes, we're alive. 02:42.51 >>> join/#ghostscript tkamppeter_ (~till@p5DDBAC4D.dip0.t-ipconnect.de) 02:46.38 >>> tkamppeter has signed off IRC (Ping timeout: 256 seconds) [#ghostscript] 02:57.11 Chans: (ghostbot) in:#ghostscript 02:58.12 FORK(24659) --- fork starting for 'RSSFeeds', PID == 24659, bot_pid == 27362 --- 02:58.13 FORK(24659) !ERROR! cannot load my module: RSSFeeds 02:58.13 FORK(24659) fork: took 2s for RSSFeeds. 02:58.13 FORK(24659) --- fork finished for 'RSSFeeds' --- 03:11.51 --- Saved uptime records. 03:12.51 Chans: (ghostbot) in:#ghostscript 03:28.22 FORK(29284) --- fork starting for 'RSSFeeds', PID == 29284, bot_pid == 27362 --- 03:28.23 FORK(29284) !ERROR! cannot load my module: RSSFeeds 03:28.23 FORK(29284) fork: took 2s for RSSFeeds. 03:28.23 FORK(29284) --- fork finished for 'RSSFeeds' --- 03:35.17 >>> mvrhel_laptop has signed off IRC (Quit: ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]) [#ghostscript] 03:44.41 Chans: (ghostbot) in:#ghostscript 03:44.41 ircCheck: possible lost in space; checking.Tue Oct 15 03:44:41 2013 03:44.41 >ghostbot< TEST 03:44.41 IRCTEST: Yes, we're alive. 03:58.57 FORK(9320) --- fork starting for 'RSSFeeds', PID == 9320, bot_pid == 27362 --- 03:58.58 FORK(9320) !ERROR! cannot load my module: RSSFeeds 03:58.58 FORK(9320) fork: took 1s for RSSFeeds. 03:58.58 FORK(9320) --- fork finished for 'RSSFeeds' --- 04:01.07 Chans: (ghostbot) in:#ghostscript 04:11.57 --- Saved uptime records. 04:16.57 Chans: (ghostbot) in:#ghostscript 04:29.17 FORK(19810) --- fork starting for 'RSSFeeds', PID == 19810, bot_pid == 27362 --- 04:29.18 FORK(19810) !ERROR! cannot load my module: RSSFeeds 04:29.18 FORK(19810) fork: took 1s for RSSFeeds. 04:29.18 FORK(19810) --- fork finished for 'RSSFeeds' --- 04:49.47 LOG: last message repeated 3 times 04:49.47 ircCheck: possible lost in space; checking.Tue Oct 15 04:49:47 2013 04:49.47 >ghostbot< TEST 04:49.47 IRCTEST: Yes, we're alive. 05:00.00 FORK(5565) --- fork starting for 'RSSFeeds', PID == 5565, bot_pid == 27362 --- 05:00.01 FORK(5565) !ERROR! cannot load my module: RSSFeeds 05:00.01 FORK(5565) fork: took 2s for RSSFeeds. 05:00.01 FORK(5565) --- fork finished for 'RSSFeeds' --- 05:05.49 Chans: (ghostbot) in:#ghostscript 05:12.19 --- Saved uptime records. 05:21.59 Chans: (ghostbot) in:#ghostscript 05:30.20 FORK(25848) --- fork starting for 'RSSFeeds', PID == 25848, bot_pid == 27362 --- 05:30.21 FORK(25848) !ERROR! cannot load my module: RSSFeeds 05:30.21 FORK(25848) fork: took 2s for RSSFeeds. 05:30.21 FORK(25848) --- fork finished for 'RSSFeeds' --- 05:33.59 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 05:33.59 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 05:37.59 Chans: (ghostbot) in:#ghostscript 05:53.39 ircCheck: possible lost in space; checking.Tue Oct 15 05:53:39 2013 05:53.39 >ghostbot< TEST 05:53.39 IRCTEST: Yes, we're alive. 06:01.05 FORK(21458) --- fork starting for 'RSSFeeds', PID == 21458, bot_pid == 27362 --- 06:01.06 FORK(21458) !ERROR! cannot load my module: RSSFeeds 06:01.06 FORK(21458) fork: took 1s for RSSFeeds. 06:01.06 FORK(21458) --- fork finished for 'RSSFeeds' --- 06:10.25 Chans: (ghostbot) in:#ghostscript 06:12.35 --- Saved uptime records. 06:26.25 Chans: (ghostbot) in:#ghostscript 06:31.15 FORK(2736) --- fork starting for 'RSSFeeds', PID == 2736, bot_pid == 27362 --- 06:31.16 FORK(2736) !ERROR! cannot load my module: RSSFeeds 06:31.16 FORK(2736) fork: took 1s for RSSFeeds. 06:31.16 FORK(2736) --- fork finished for 'RSSFeeds' --- 06:45.17 >>> join/#ghostscript kens (~Miranda@31.185.216.66) 06:58.05 Chans: (ghostbot) in:#ghostscript 06:58.05 ircCheck: possible lost in space; checking.Tue Oct 15 06:58:05 2013 06:58.05 >ghostbot< TEST 06:58.05 IRCTEST: Yes, we're alive. 07:01.50 FORK(1700) --- fork starting for 'RSSFeeds', PID == 1700, bot_pid == 27362 --- 07:01.51 FORK(1700) !ERROR! cannot load my module: RSSFeeds 07:01.51 FORK(1700) fork: took 2s for RSSFeeds. 07:01.51 FORK(1700) --- fork finished for 'RSSFeeds' --- 07:04.03 >>> chrisl_away materializes into chrisl 07:12.17 Robin_Watts: , paulgardiner, tor(n), can one of you reply to this please ? 07:12.18 http://stackoverflow.com/questions/19372802/how-can-change-color-drawing-of-mupdf 07:12.40 * kens/#ghostscript remembers Paul is away 07:12.50 --- Saved uptime records. 07:13.16 kens: tor(n)..! you echo my thoughts. :) 07:13.46 Seen: Flushed 2 entries. 07:14.16 Chans: (ghostbot) in:#ghostscript 07:15.24 Hmmm. chrisl, what's our position re GPL when using a DLL ? Is that 'linking' ? 07:15.41 ie does it invoke the viral nature of the GPL ? 07:17.38 kens: I believe it does, yes. 07:17.59 chrisl, its OK I followed the SO thread and it looks like its not relevant, sorry. 07:18.31 NP 07:19.00 Sybase PowerBuilder not only uses GS to create PDF files, it only works with 8.71 apparently.... 07:19.43 Yeh, I think I knew that - IIRC, I found a topic on their forum to that effect a while back 07:20.03 I actually commented on it at the time, but I'd forgotten about it 07:20.36 But I thought they exec'ed the executable, rather than link to the DLL..... 07:21.14 Yes, exactly. There was a new post with the same problem, but wttering about the DLL which had me chasing my tail for a moment 07:22.21 It might be worth pinging Miles, although I'm sure he'll have made contact before 07:29.59 Chans: (ghostbot) in:#ghostscript 07:32.20 FORK(26939) --- fork starting for 'RSSFeeds', PID == 26939, bot_pid == 27362 --- 07:32.21 FORK(26939) !ERROR! cannot load my module: RSSFeeds 07:32.21 FORK(26939) fork: took 2s for RSSFeeds. 07:32.21 FORK(26939) --- fork finished for 'RSSFeeds' --- 08:02.30 FORK(13784) LOG: last message repeated 4 times 08:02.30 FORK(13784) --- fork starting for 'RSSFeeds', PID == 13784, bot_pid == 27362 --- 08:02.31 FORK(13784) !ERROR! cannot load my module: RSSFeeds 08:02.31 FORK(13784) fork: took 2s for RSSFeeds. 08:02.31 FORK(13784) --- fork finished for 'RSSFeeds' --- 08:13.19 LOG: last message repeated 4 times 08:13.19 --- Saved uptime records. 08:14.09 Seen: Flushed 2 entries. 08:14.37 >>> join/#ghostscript tor7 (~tor@h-2-60.a230.priv.bahnhof.se) 08:17.29 Chans: (ghostbot) in:#ghostscript 08:22.49 ircCheck: possible lost in space; checking.Tue Oct 15 08:22:49 2013 08:22.49 >ghostbot< TEST 08:22.49 IRCTEST: Yes, we're alive. 08:32.56 FORK(31308) --- fork starting for 'RSSFeeds', PID == 31308, bot_pid == 27362 --- 08:32.57 FORK(31308) !ERROR! cannot load my module: RSSFeeds 08:32.57 FORK(31308) fork: took 2s for RSSFeeds. 08:32.57 FORK(31308) --- fork finished for 'RSSFeeds' --- 08:33.55 Chans: (ghostbot) in:#ghostscript 08:51.48 tor7: Good morning! Say, is it you who introduced commit 3c559928 (Set /Parent entry when inserting a page into the page tree)? 08:57.01 Micha`: tor7 is indeed the committer. why are you asking..? 09:01.56 Because I can't make it to work :-) It seems that it always creates cycles in the page tree. In fact, in pdf-page.c:573, shouldn't "pdf_dict_puts(page->me, "Parent", page_ref)" read "..., parent)" ? 09:02.25 --- note it *does* work with this change, but it may not be the intended behavior. 09:03.16 FORK(10564) --- fork starting for 'RSSFeeds', PID == 10564, bot_pid == 27362 --- 09:03.17 FORK(10564) !ERROR! cannot load my module: RSSFeeds 09:03.17 FORK(10564) fork: took 2s for RSSFeeds. 09:03.17 FORK(10564) --- fork finished for 'RSSFeeds' --- 09:06.35 Chans: (ghostbot) in:#ghostscript 09:12.37 >>> kens has signed off IRC (Read error: Connection reset by peer) [#ghostscript] 09:13.27 --- Saved uptime records. 09:13.41 >>> marcosw has signed off IRC (Ping timeout: 272 seconds) [#ghostscript] 09:14.15 Seen: Flushed 2 entries. 09:15.58 >>> join/#ghostscript kens (~Miranda@31.185.216.66) 09:16.38 Micha`: I'm reviewing tor7's patch and it looks alright to me. I thik page_ref is correct. he means to set a /Parent entry in the page dict which is added as far as I understand. 09:17.06 Micha`: yes. let me take a look. 09:17.18 ah.. no. I take that back. 09:17.25 page->me is the current page of course. 09:17.35 yes, it probably should be parent. d'oh... :-P 09:18.22 Micha`: this code is fairly untested, the code to use it hasn't really been exercised (or implemented in some cases) 09:20.08 Micha`: does it work if you make the change in pdf_dict_puts to use parent instead of page_ref? it looks like it ought to. 09:20.26 tor7: It does indeed. 09:20.32 Micha`: the one thing this code doesn't do is create a nice well balanced page tree 09:20.47 and it requires an existing page tree to work with 09:20.49 or in fact, any page tree if there isn't one to start with :) 09:21.07 Yes, I'm looking forward to that :-) Creating a PDF from scratch would be great. 09:21.13 so it can't create a page tree from scratch, it's only really useful for minor page removals or insertions as it stands 09:21.41 it's on the todo list, but at a very low priority (since we don't have an immediate need for it ourselves) 09:22.08 tor7: Couple of things on robin/master when you get a mo. 09:22.08 Chans: (ghostbot) in:#ghostscript 09:22.10 basically, it should be possible if you (a) handle the fz_throw TODO case of an empty page tree 09:22.26 and then optimise it by doing a rebalancing function you can call at the end 09:23.23 For the moment, I only plan to edit PDFs, hence I do not start from scratch, so I'm fine :) 09:23.33 >>> join/#ghostscript paulgardiner (~chatzilla@smtp.glidos.net) 09:23.35 Micha`: pdfclean has a function to rebuild the page tree (but it makes one flat page tree, not good for performance) when you ask it to drop pages 09:23.46 Robin_Watts: Did you see my comment about the empty contents? 09:23.58 and I believe the pdfwrite device has some of its own page tree creation 09:24.02 Micha`: I did, but I haven't had a chance to investigate it. 09:24.15 there's a few other things you need to create a valid PDF file from scratch, like the Catalog 09:24.43 Robin_Watts: No problem. 09:24.59 tor7: Ah, yes, I see... 09:25.27 Micha`: the plan is to (eventually) migrate both of them to this new page tree editing API you've found 09:27.46 I see. What is the current status of the (#if 0)'d code in pdf-write? 09:28.08 Robin_Watts: what's the fix in draw-device.c with blendmode & FZ_BLEND_MODEMASK about? I don't remember having a bitmask for the blend mode... 09:28.36 tor7: For the gstate the blendmode has ISOLATED and KNOCKOUT bits. 09:28.48 oh! 09:28.50 right. 09:29.01 so that was a silly typo on my part. 09:29.38 Robin_Watts: the four commits on robin/master LGTM 09:29.44 ta. 09:30.29 Pushed. 09:30.41 Micha`: Yesterdays fix is now in the golden repo. 09:32.48 Robin_Watts: two small fixes on tor/master 09:33.18 both look fine. 09:33.48 FORK(23979) --- fork starting for 'RSSFeeds', PID == 23979, bot_pid == 27362 --- 09:33.49 FORK(23979) !ERROR! cannot load my module: RSSFeeds 09:33.49 FORK(23979) fork: took 1s for RSSFeeds. 09:33.49 FORK(23979) --- fork finished for 'RSSFeeds' --- 09:33.51 Robin_Watts: also: grrr. lazy ass delivery bastards. the package would have arrived yesterday if they hadn't been too lazy to get out of their delivery van to ring the doorbell. 09:34.11 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 09:34.11 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 09:34.18 what? They pulled up outside and honked? 09:34.38 or they rang the mobile? 09:34.57 in 90% of times they're supposed to deliver, they take a look and say, eh fuck it. mark it as "undeliverable, the person wasn't at home. couldn't reach." with no attempt at doing so. no phone call, no door bell, no nothing. 09:35.33 I've heard similar complaints from other people that live in cities. 09:35.35 I got the paper slip with the swedish side tracking number and then at 13:42 -- tried to reach, couldn't. 09:35.58 yeah. it's pretty much standard practice. load it up on the van for delivery, make the rounds to the easy to get to places, and then back home to the depot. 09:36.09 annoying as hell though, if you live in the city... 09:36.24 most people probably don't even know, since they go to work at an office.... 09:36.42 Living in a village I've never had a problem. Of course the fact that I'm home all day everyday means that they mostly know they can drop parcels here for anyone in the street who is out... 09:37.37 yeah. I was surprised how fast the package arrived to you. 09:38.17 Chans: (ghostbot) in:#ghostscript 09:38.20 me too. Google Play said "usually dispatched within 2 days", then the receipt said "will be dispatched in 5 days time", then it arrived 2 days later. 09:49.39 >>> join/#ghostscript marcosw (~marcos@c-98-207-109-212.hsd1.ca.comcast.net) 09:53.32 Robin_Watts: Thanks for the commit! But we may have missed something: "pdf_dict_puts(page->me, "Contents", obj);" should read "pdf...(..., page->contents);" right? 09:53.52 Chans: (ghostbot) in:#ghostscript 09:53.54 kens: Thanks for spotting the question on stackoverflow. I've answered it. (Not quite off on vacation yet). 09:54.06 Ah, thanks paulgardiner 09:54.17 paulgardiner: Have fun. 09:54.54 Micha`: Urm... why? 09:54.57 Off Thurs morning, so hopefully will be working most of today and some of tomorrow 09:56.11 Micha`: Damn. Yes. 09:56.20 Robin_Watts: Ah! :-) 09:57.30 tor7: 2 more small fixes on robin/master then. 09:57.34 Micha`: Thanks again. 09:58.46 You're welcome. 10:00.05 tor7: there are also some iOS commits on paulg/master 10:03.56 FORK(31902) --- fork starting for 'RSSFeeds', PID == 31902, bot_pid == 27362 --- 10:03.57 FORK(31902) !ERROR! cannot load my module: RSSFeeds 10:03.57 FORK(31902) fork: took 2s for RSSFeeds. 10:03.57 FORK(31902) --- fork finished for 'RSSFeeds' --- 10:10.15 Chans: (ghostbot) in:#ghostscript 10:13.13 >>> marcosw has signed off IRC (Ping timeout: 272 seconds) [#ghostscript] 10:13.33 --- Saved uptime records. 10:14.24 Seen: Flushed 6 entries. 10:22.42 >>> join/#ghostscript marcosw (~marcos@c-98-207-109-212.hsd1.ca.comcast.net) 10:26.25 Chans: (ghostbot) in:#ghostscript 10:34.06 FORK(3250) --- fork starting for 'RSSFeeds', PID == 3250, bot_pid == 27362 --- 10:34.07 FORK(3250) !ERROR! cannot load my module: RSSFeeds 10:34.07 FORK(3250) fork: took 2s for RSSFeeds. 10:34.07 FORK(3250) --- fork finished for 'RSSFeeds' --- 11:03.14 LOG: last message repeated 3 times 11:03.14 fts_17_1700.pdf has a JPX image in it that doesn't render properly in mupdf, but does in gs. 11:03.21 One for shelly? 11:03.53 gs whinges about it though. 11:04.25 FORK(6937) --- fork starting for 'RSSFeeds', PID == 6937, bot_pid == 27362 --- 11:04.27 FORK(6937) !ERROR! cannot load my module: RSSFeeds 11:04.27 FORK(6937) fork: took 2s for RSSFeeds. 11:04.27 FORK(6937) --- fork finished for 'RSSFeeds' --- 11:05.02 whinges how ? 11:05.12 and in what way renders improperly ? 11:05.36 need to go look atg wife's computer, brb 11:10.06 Robin_Watts: IIRC, mupdf doesn't support SMaskInData (or whatever it's called), so it could be that. There are also some colour space heuristics (ahem, hacks!) in the gs interface code, so it could be that 11:13.51 Robin_Watts: Indeed, at least one of the images in fts_17_1700.pdf has "/SMaskInData 1" 11:13.51 --- Saved uptime records. 11:14.01 Chans: (ghostbot) in:#ghostscript 11:14.41 Seen: Flushed 3 entries. 11:30.21 >>> Fandekasp has signed off IRC (Quit: leaving) [#ghostscript] 11:30.31 Chans: (ghostbot) in:#ghostscript 11:30.38 >>> join/#ghostscript Fandekasp (~Fandekasp@27-32-19-26.static.tpgi.com.au) 11:34.35 FORK(10689) --- fork starting for 'RSSFeeds', PID == 10689, bot_pid == 27362 --- 11:34.36 FORK(10689) !ERROR! cannot load my module: RSSFeeds 11:34.36 FORK(10689) fork: took 1s for RSSFeeds. 11:34.36 FORK(10689) --- fork finished for 'RSSFeeds' --- 11:43.43 >>> join/#ghostscript sebras-hotel (b4a82eea@gateway/web/freenode/ip.180.168.46.234) 11:46.05 Chans: (ghostbot) in:#ghostscript 11:49.34 >>> chrisl materializes into chrisl_away 11:56.10 >>> join/#ghostscript stars (~stars@27.34.252.234) 12:02.15 Chans: (ghostbot) in:#ghostscript 12:04.55 FORK(32206) --- fork starting for 'RSSFeeds', PID == 32206, bot_pid == 27362 --- 12:04.57 FORK(32206) !ERROR! cannot load my module: RSSFeeds 12:04.57 FORK(32206) fork: took 2s for RSSFeeds. 12:04.57 FORK(32206) --- fork finished for 'RSSFeeds' --- 12:07.30 >>> henrys has signed off IRC (Ping timeout: 245 seconds) [#ghostscript] 12:14.35 --- Saved uptime records. 12:17.55 Chans: (ghostbot) in:#ghostscript 12:17.55 ircCheck: possible lost in space; checking.Tue Oct 15 12:17:55 2013 12:17.55 >ghostbot< TEST 12:17.55 IRCTEST: Yes, we're alive. 12:19.03 >>> join/#ghostscript flojpg (56408f44@gateway/web/freenode/ip.86.64.143.68) 12:21.22 hello world; i've a simple question for you all -> i've an application which provide text to GS using stdin. Is it possible to add a balise in the original text permiting to "inform" GS that it have to change the font (clearly, i want the same font but bold) 12:22.52 Ghostscript doesn't consume text (at least not directly), it consumes PostScript or PDF> Whatever is driving GS must be supplying one of those (most likely PostScript). You can change the font in PostScript using the setfont or selectfont operators 12:23.48 ok thanks for your help 12:23.52 i'll try this 12:24.54 chrisl: ah, thanks. 12:33.59 Chans: (ghostbot) in:#ghostscript 12:34.27 >>> stars has signed off IRC (Ping timeout: 272 seconds) [#ghostscript] 12:35.18 FORK(28886) --- fork starting for 'RSSFeeds', PID == 28886, bot_pid == 27362 --- 12:35.19 FORK(28886) !ERROR! cannot load my module: RSSFeeds 12:35.19 FORK(28886) fork: took 2s for RSSFeeds. 12:35.19 FORK(28886) --- fork finished for 'RSSFeeds' --- 12:38.41 In fact, I don't see anything in the PDF spec directed to written annotations. Ink annotations seem to be used 12:38.45 oops. 12:38.50 Let me finish that. 12:41.24 >>> flojpg has signed off IRC (Quit: Page closed) [#ghostscript] 12:45.33 Ink annotations seem to be used for freehand circling or underlying, and then for typing a note. That's not the same as plainly hand writing a note, plus the Ink type is not really robust --- no color change can be made during a note, for instance. ezpdf has handwritten notes, on Android at least, and it relies on a Stamp annotation for which it defines an appearance. This I consider hacking the spec --- plus, cl 12:45.33 icking the annotation opens an empty (typed) note, and this seems useless. So as I'm still planning on making a PDF annotator (with handwritten notes), am I right in thinking that the cleanest way would be to have one form XObject spanning the whole page containing the scribbles, possibly depending on an OCG? 12:46.00 Boy, rcirc could do a better job at splitting messages... 12:49.39 Chans: (ghostbot) in:#ghostscript 12:50.44 paulgardiner is the expert on annotations. 12:51.11 I thought there were text annotations too? 12:51.17 oh, but you want handwritten? 12:53.02 Precisely. 12:54.11 I think for handwritten, when you want to leave the possibility for other people to edit it later, you need ink. 12:54.33 I have a tablet with a pen, and I feel that no software handles scribbling on the PDF smoothly enough (I currently use an excellent software called LectureNotes, but it requires the PDF to be rasterized, which is no good for PDF books). 12:54.35 For handwritten when you want a fixed appearance that will never change, stamp will do the job. 12:56.08 With ink annotations, every time the user changes transparency, color, or thickness, a new annotation should be created. Plus, I don't feel it is the intended purpose of Ink annotations. 12:57.36 Also, Stamps do not seem to be intended for this. Can a viewer discard the /AP and redo the rendering based on the annotation type? 12:58.44 Acrobat (almost) always does so 12:58.56 Which I think is a really, really bad idea 12:59.25 kens: Really?! That does souns a bad idea. 13:00.17 kens: is that for annotations in general, or just certain ones? 13:00.59 paulgardiner : Acrobat *defintely* does this, we have a number of cases where we ahve a 'bug' because our annotations do not match what Acrobat displays. Yet we render teh appearance stream faithfully. It cna be shown (by extracting the appearance stream) that GS is drawing the AP the same as Acrobat, so clearly Acrobat is ignoting the AP stream. 13:01.03 Well... As far as I can see in the specs, it is not prohibited to do so. 13:01.50 Micha` : Yes, but if I am a content creator, and I go to the effort of creating an AP stream so it looks the way I intend, I would probably be p*ssed off if the viewer decided it knew better and drew something 'like' what I intended. 13:02.15 tor7: Another fix (making 3) on robin/master 13:03.12 paulgardiner : Acrobat ignores AP streams 'most' of the time, there seems no rhyme or reason. CHris and I suspect that the annotation renmdering was done by different people, and sometimes they decided they knew best and just rendered the content, and sometimes they decided to honour the creator's decision 13:04.14 chrisl: Turns out that SMaskInData doesn't matter for that file. It was an openjpeg 1 vs 2 thing. 13:04.24 Possibly we should be adopting openjpeg 2 now? 13:05.01 kens: And you'd be right to be pissed. But if it is specs-compliant, the problem may lie more in the specs. 13:05.22 FORK(20891) --- fork starting for 'RSSFeeds', PID == 20891, bot_pid == 27362 --- 13:05.23 FORK(20891) !ERROR! cannot load my module: RSSFeeds 13:05.23 FORK(20891) fork: took 2s for RSSFeeds. 13:05.23 FORK(20891) --- fork finished for 'RSSFeeds' --- 13:05.31 Chans: (ghostbot) in:#ghostscript 13:05.36 I'm sure I've seen many places in the spec where it explicitly states that the AP takes precedence if present 13:05.42 Micha` : I don't say its not spec compliant (and the PDF spec is very poor), I'm just saying that in my opinion its a very bad idea 13:05.52 Agreed. 13:06.49 FWIW one of the reasons Marcos had trouble with a (huge) PDF file recently was that the bug was a missing AP stream, and whenever Marcos edited teh PDF file and saved it, Acrobat quietly added an AP stream for him. 13:07.46 paulgardiner : an 'easy' way to test is to create a PDF file with one of every annotation type, then nobble the AP streams so they all point to the sma stream, eg a black box, and see what the viewer makes of it. 13:08.14 Micha`: I haven't yet fully understood why an Ink annotation (or collection of several) is wrong for your application. 13:08.16 Table 164, on the AP line, specifies: "Individual annotation handlers may ignore this entry and provide their own appearances." 13:10.19 kens: I had noticed that Acrobat ignored the AP for a signature annotation when information from the signature was missing, but then displayed it when the rest of the information was in place. I guess that's one case that could be deemed sensible. 13:10.50 paulgardiner : yes, possibly, but I've seen it ignore perfectly valid annotations with AP streams too 13:14.39 --- Saved uptime records. 13:14.59 Seen: Flushed 5 entries. 13:17.16 Micha`: Oh yes. Clearly the spec allows it. Perhaps it does make sense for some types of annotations (e.g., text annotations), where you might want your app to use a consistant icon to show where one might open up a hidden note. 13:17.21 paulgardiner: It is not wrong per se, but there are three reasons why I'm not sure it is the optimal choice. First, an annotation, AFAIU, is foremost an access to a typed note. My use do not fit this intention as I do not want typed notes; obviously I could just disregard that, but I'd rather conform to the spirit of the specs. Second, when I take notes on a paper, I have half a dozen different pens, hence I will 13:17.21 have at least that many Ink annotations. Third, and a consequence of Second, when erasing, I will have to go through all the Ink annotations to find the points to erase. This may overload the process (though I'm not sure). If I go for an OCG'd form XObject, I will have to consider only one object at a time. 13:18.18 >>> Fandekasp has signed off IRC (Ping timeout: 240 seconds) [#ghostscript] 13:19.32 Yes. Might be best. And you more easily guarantee getting the same results in other viewers. 13:21.19 Chans: (ghostbot) in:#ghostscript 13:27.46 paulgardiner: Thanks a lot for the advice. Your hindsight is very much welcome as I did not have a clue what an OCG was a few hours ago :) 13:28.57 Micha`: No problem. Glad we could help. 13:34.39 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 13:34.39 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 13:35.30 FORK(17112) --- fork starting for 'RSSFeeds', PID == 17112, bot_pid == 27362 --- 13:35.31 FORK(17112) !ERROR! cannot load my module: RSSFeeds 13:35.31 FORK(17112) fork: took 2s for RSSFeeds. 13:35.31 FORK(17112) --- fork finished for 'RSSFeeds' --- 13:36.39 Chans: (ghostbot) in:#ghostscript 13:42.14 >>> tor7 has signed off IRC (Ping timeout: 264 seconds) [#ghostscript] 13:42.56 >>> join/#ghostscript tor7 (~tor@h-2-60.a230.priv.bahnhof.se) 13:52.49 Chans: (ghostbot) in:#ghostscript 14:05.23 >>> join/#ghostscript henrys (~henrys@c-50-134-235-109.hsd1.co.comcast.net) 14:05.53 FORK(23143) --- fork starting for 'RSSFeeds', PID == 23143, bot_pid == 27362 --- 14:05.54 FORK(23143) !ERROR! cannot load my module: RSSFeeds 14:05.54 FORK(23143) fork: took 1s for RSSFeeds. 14:05.54 FORK(23143) --- fork finished for 'RSSFeeds' --- 14:06.11 >>> join/#ghostscript mvrhel_laptop (~chatzilla@c-50-159-85-185.hsd1.wa.comcast.net) 14:08.07 So, when did we decide the meeting time was today? :( 14:08.07 Chans: (ghostbot) in:#ghostscript 14:08.12 oops. :) instead of :( 14:09.11 AIUI 4:30 pm uk time, one meeting 14:10.13 >>> chrisl_away materializes into chrisl 14:14.53 Running through the fts cases for the svg device has been interesting. I've found a few things that mupdf gets wrong. 14:15.03 --- Saved uptime records. 14:15.23 Seen: Flushed 4 entries. 14:15.39 tiling patterns being one of them. I hate it whenever I have to make changes in this stuff. 14:16.21 patterns are horrible 14:21.33 Wasn't it 7:30 to 8:15 EST 14:22.54 Err, is that 3:30 UK time then ? 14:23.13 Yeah. I may be misremembering though 14:23.59 Chans: (ghostbot) in:#ghostscript 14:24.25 yes 5 minutes 14:24.33 ah thanks henrys 14:26.26 PST paulgardiner 14:27.15 Ah. That would explain the trouble I was having making it come to 3:30 14:29.39 I just added research MS Office solutions to the agenda. 14:30.33 henrys on the 'GS->Languages' item, I have added teh ramfs code, and closed #693363 14:31.23 henrys: I've been mainly continuing work on the iOS app this week, but I have started looking at libreoffice this afternoon. 14:31.27 At Chicago Print there has been a booth next to us with guys doing PDF -> Word and other formats. I would think that would be more popular than it is. 14:31.42 kens:super 14:32.23 kens:but I must have missed the commit message somehow - I do try and keep up with everything. 14:32.23 henrys: and I'm done with 694519 14:32.38 henrys let me look for the commits 14:33.10 On the iOS front I have form filling working but without javascript of course 14:34.03 chrisl: that I did see, I've marked the 2 done on the agenda 14:34.07 ramfs b5472ea6bf6925023febdeab12be9dbd83e811f1 d97571b56d7c740e7d6aeee064313b96048a5667 14:34.08 29ed18f26f78d3e737b5e73452b1aa1a90088144 14:34.20 henrys: thanks 14:34.26 kens: did you see that I fixed the xps trans issue you found. that was an interesting one 14:34.29 And I've just realised that checkboxes probably now work, but I haven't tested them :-) 14:34.34 chrisl: my suggested solution to yesterday's bug was sent as a patch to the 9-1 customer did you see it? 14:34.39 mvrhel_laptop : yes I saw you had fixed it, thanks for that! 14:34.55 henrys: I saw the mail, I didn't look at the patch - I'll look now 14:35.03 Bug 693363 was commit 9c13e3b9e735ba119f58c751a51fc55efef15a0c 14:35.14 chrisl: I didn't test gs ;-) 14:35.28 chrisl: but what could possibly go wrong ? 14:35.37 henrys: it really shouldn't affect gs 14:36.18 FORK(6569) --- fork starting for 'RSSFeeds', PID == 6569, bot_pid == 27362 --- 14:36.19 FORK(6569) !ERROR! cannot load my module: RSSFeeds 14:36.19 FORK(6569) fork: took 1s for RSSFeeds. 14:36.19 FORK(6569) --- fork finished for 'RSSFeeds' --- 14:36.33 henrys probably want to remove the RAM I/O device from 'someday projects' too 14:37.00 marcosw: did you see my comment about 694707? 14:37.02 kens:yes 14:37.13 henrys: did you actually check if using 64 bit color indices carried a performance penalty? I'd be a little surprised if that was still the case 14:38.16 henrys: the patch looks okay - assuming it tests out with GS, of course :-) 14:38.29 marcosw:how do you feel about me taking Mac Pro off a bit - I'm thinking of using windows on it. 801 is going to have more questions and they report probably on both. 14:39.08 chrisl: last I check there was significant penalty yes. 10 to 15 % if I remember correctly. 14:39.24 on certain files only. 14:39.34 Chans: (ghostbot) in:#ghostscript 14:39.44 chrisl: I cannot think of a platform on which 64bit wouldn't be a cost. 14:40.48 Robin_Watts: I'd have thought platforms with native 64 bit support would be fine 14:41.20 chrisl: The cost will be lower there, sure, but there is still more overhead in loading/saving to memory. 14:41.23 Robin_Watts, chrisl as you guys can see from the include file we've tried quite a few experiments with color indices. 14:43.43 chrisl: I do wonder if there is some optimizations we could do that would make the overhead insignificant 14:44.03 paulgardiner: how is iOS? 14:44.28 henrys: it may be that we're copying structure contents around, when passing a pointer would be more efficient. 14:45.07 henrys: Have reflow and form filling working. Still have javascript integration, signature support and printing to add. 14:45.29 Sorry and annotations 14:46.01 paulgardiner: wow moving right along. It can't be as painful as we thought 14:46.16 although there's a fair crossover between annotations and form filling (because of partial updates) that's now done 14:47.12 Robin_Watts: I don't know if your read my message to 801 but you might be a good candidate for that project if they say yes. I guess ray could do it also. 14:47.38 I hadn't spotted anything. Let me check again now. 14:47.59 tor7:how's GL? 14:48.37 mvrhel_laptop: finally back to mupdf? 14:48.54 henrys: The device with different resolutions per plane. Scary. 14:49.30 henrys: I am hoping to. kens dropped an ICC question on me that I will look at real quick and then I will fix my threading issue in the windows app 14:49.38 2 ICC questions :-) 14:49.40 had a nice discussion with Robin_Watts last week about my issues 14:50.08 for some definition of nice. 14:50.09 kens: oh yes 2 questions ;) 14:50.16 I will look at those this morning 14:50.20 THanks :-) 14:50.38 mvrhel_laptop: well I'm glad you've discussed your issues with somebody ;-) 14:50.49 ha 14:51.18 henrys: yeah. I like the structure that Tor created, now I understand it better, and the new stuff is fitting in quite naturally. 14:51.55 paulgardiner: oh good where is the mighty tor7? 14:53.16 any other meeting business? 14:53.16 I don't know. He was here earlier... slightly worrying. 14:53.35 I don't have anything else today 14:54.02 I guess marcosw and ray forgot about the new meeting time and will show up at the hour. 14:54.18 Possibly tor7 as well 14:54.45 I have some worries about libreoffice, but I need to get a better understanding of it before I'll no if they are legitimate worries. 14:54.55 Chans: (ghostbot) in:#ghostscript 14:54.56 s/no/know/ 14:55.18 libreoffice is C++? 14:55.40 yes. 14:55.57 In case anyone has missed the lcms2 discussions, it seems we have a way forward that Marti is happy with. If anyone wants to chime in, feel free to read the discussion in the logs. 14:56.01 The oox part is fairly small, but the whole thing is huge 14:56.15 libreoffice is C++ and MPL, so that sounds pretty good - if we can extract just the bits we need. 14:56.19 hmm LGPL? 14:56.28 I have yet to work out how selfcontained the oox part is 14:56.34 It's dual MPL and GNU GPLv3. 14:56.41 Robin_Watts: ah right 14:56.58 Robin_Watts : I read the discussion, but there's nothing I cna usefully say 14:57.00 kens. so where is 247-05.ps? 14:57.01 Most of what I've looked at so far is MPL 14:57.09 >>> join/#ghostscript ray_laptop (~chatzilla@cpe-76-171-54-81.socal.res.rr.com) 14:57.16 but I haven't sussed whether it pulls in any LGPL stuff. 14:57.16 mvrhel_laptop : ther original file ? Its in tests_private soemwhere 14:57.25 Its one of the QL test files 14:57.28 I can't seem to find it 14:57.29 good guess, henrys 14:57.29 give me a second 14:57.55 Actually I htink that should be 247-05.ps 14:58.05 Indeed it shold be 14:58.15 The whole oox directory looks to be MPL 14:58.33 paulgardiner: I thought the whole thing was both MPL and GNU GPLv3. I didn't think that there were different components in different licenses, but maybe I misunderstood. 14:59.00 mvrhel_laptop : /home/marcos/cluster/test_private/comparefiles/247-05.ps 14:59.05 oh compare files 14:59.07 ok 14:59.12 sorry 14:59.15 NP 14:59.27 Yeah. I was just going to add the proviso "If I'm understanding how the licencing works" 14:59.40 And ineed there is a 245-07 in there 14:59.52 chrisl: do do you want me to take care of the patch? 15:00.32 henrys: if you don't mind, yeh. 15:00.44 chrisl: will do. 15:01.16 Thanks 15:01.32 Robin_Watts: many of the files mention only MPL. I don't know whether they are infected with LGPL by being collected with files that mention LGPL 15:01.51 I do wish we had windows testing. Compiling with different color index values would have revealed a crash in pcl immediately. 15:02.32 Clearly if you build something from a collection of MPL and LGPL files then it's LGPL, but I don't know what happens if you pull out just MPL files and use only those. 15:02.44 kens: ok so 245-07.ps 15:02.48 yep 15:02.54 got that one 15:03.07 OK I htink I sent you a cut down file for the other problem 15:03.15 henrys: would it have shown on Unix, too? Maybe we should have 32bit color indices in the weekly tests? 15:03.16 I cannot at this stage tell if the oox part will build without pulling in all the huge number of libraries that make up libreoffice/core 15:03.17 henrys: windows also uses 64-bit color_index 15:03.34 kens: yes. thank you 15:03.38 NP 15:04.40 ray_laptop: due to a bug in pcl part of the code would be 32 and part 64 if built with 64, that easily preventable stuff with good testing. 15:06.29 >>> tkamppeter_ materializes into tkamppeter 15:06.29 FORK(10706) --- fork starting for 'RSSFeeds', PID == 10706, bot_pid == 27362 --- 15:06.30 FORK(10706) !ERROR! cannot load my module: RSSFeeds 15:06.30 FORK(10706) fork: took 1s for RSSFeeds. 15:06.30 FORK(10706) --- fork finished for 'RSSFeeds' --- 15:06.59 mvrhel_laptop : I forgot a point, for the second ICC question, you need to use -sDEVICE=pdfwrite -dPDFUseOldCMS=false 15:07.05 ah ok 15:07.08 thanks 15:07.08 henrys: right, but we can build with 32-bit color index on unix no or windows, tight ? 15:07.40 I have to head out right now. I will be back in about 30 minutes 15:09.04 chrisl: we have eliminated recursive make of the library makefile in gcc, I wish we could do that in msvc, it is much simpler. 15:09.13 chrisl: but indeed it should be tested. 15:09.28 paulgardiner: wouldn't that MPL file still be MPL? I mean that was the original license. the fact that MPL happens to be compatible with LGPL doesn't change the license of the file per se..? 15:09.46 paulgardiner: otherwise BSD-people would complain even more about GPL... :) 15:09.59 sebras-hotel: I think the worry is that the MPL stuff might build upon GPL stuff. 15:10.14 so we'd need to reimplement the GPL layers in order to use it. 15:10.39 Chans: (ghostbot) in:#ghostscript 15:11.00 http://www.kickstarter.com/projects/117421627/the-peachy-printer-the-first-100-3d-printer-and-sc 15:11.14 Both issues were worries of mine, although your interpretation sebras-hotel was the one that seemed most likley to me 15:11.15 Interesting. A 3d printer for $100. 15:11.26 ray_laptop: we can build with 32 or 64 on windows and unix. 15:11.36 henrys: there are recursive make calls in ugcc_top.mak - but they are fairly sane ones, unlike the msvc ones 15:11.46 Robin_Watts: ah, to make a commercial license viable? (I seem to recall that MPL would allow this, just like BSD) 15:11.57 henrys: oh, meeting's earlier rather than later? 15:12.04 ray_laptop: have a look at what I just emailed 801 - it might effect you anyway, so worth the read. 15:12.16 I ran out to pick up the chromebook so I'd be ready for the meeting... oops. 15:12.28 tor7:new meeting time is 7:30 PST 15:12.35 sebras-hotel: Indeed. Without a commercial license we wouldn't be interested. 15:12.52 henrys: have you switched from DST yet? 15:13.02 henrys: GL has clipping, going to take a break from that and see if we can render in CMYK 15:13.10 Robin_Watts: no of course not, and GPLv3 written by someone else and not dual licensed under BSD or similar would make it a problem. 15:13.15 henrys: That device sounds interesting. I'd be happy to have a look if you wanted me to. but then if ray particularly wanted to do it, I wouldn't fight for it :) 15:13.46 henrys: OK. 15:14.24 Robin_Watts: what they have now is going to be very slow - I mean copying all that data… lord 15:15.29 --- Saved uptime records. 15:15.29 Seen: Flushed 9 entries. 15:15.32 Are the two resolutions guaranteed to be easy integer multiples? 15:15.49 we've had experiences where customers have released products we didn't want to be associated with I'd like to avoid that. 15:16.08 chrisl: I would assume a fixed 2:1 ratio. 15:16.11 chrisl: yes it looks to be strictly 300 and 600 15:16.24 henrys: Presumably this is a planar device ? 15:16.32 henrys: right, it's better to render things directly. 15:17.07 Do we have any history of having devices with different resolutions? Cos I bet that will break all sorts of assumptions in clist etc. 15:17.36 henrys: but I'm not sure about a render device that has different res per plane (all but black at half res) 15:17.59 Postscript has no provision for that, so I doubt there's history 15:18.25 Robin_Watts: the clist would need to be at 600 dpi, then the buffer device (special memory device) would convert the coordinates 15:18.37 Robin_Watts: I thought we could just do copy_color, fill_rectangle and the low level stuff and skip pixels why change the res? 15:18.57 henrys: That will play hell with halftoning etc. 15:19.01 the clist needs to maintain a single res. 15:19.09 Robin_Watts: they are contone 15:19.21 Robin_Watts: there is no halftoning 15:19.26 full color 15:19.29 OK, so patterns. 15:19.35 We just had a bug where a pattern had alternate lines empty. 15:19.43 IIRC, someone like Scitext (kens do you remember?) did something like that - 600dpi for line art, and 300 dpi for contone 15:19.52 Robin_Watts: patterns and all bitmaps in the clist would be at 600 15:20.03 and because at certain resolutions we picked the empty lines, the pattern would disappear at certain resolutions. 15:20.48 Robin_Watts: patterns are inherently resolution independent (at least in PDF), 15:20.58 chrisl it was Dwight I think, but the output format was Scitex, CT/LW 15:21.13 ray_laptop : not whenyou render them 15:21.19 in PS you can write stuff that uses tricks to make stuff resolution dependent 15:21.20 ray_laptop: Tell that to the bug we were just looking at! 15:21.38 kens: no, I meant the definition of the patten in the PDF is not aware of the device re. 15:21.45 ray_laptop : correct 15:21.50 Robin_Watts: well it would be no different than what they have now. 15:21.57 But when you redner the pattern, the resolutiopn becomes important 15:22.08 henrys: Well, at the moment they are downsampling, right? So taking an average? 15:22.13 which I assume they are satisfied with but that may be a badd assumption 15:22.18 Robin_Watts: there's lots of cases where images, using the "center of pixel" rule cause dropout 15:22.30 Are you proposing we do that too? 15:22.30 Robin_Watts: they are not they are skipping 15:22.36 oh, ok. 15:22.54 What happens when we do 'getbits' ? 15:23.02 We'd have to pixel double up again. 15:23.15 seems like a 'darkest of the source pixels' would be better 15:23.44 kens: was Dwight's the only RIP that supported the Scitex device, then? 15:23.55 chrisl the only Jaws one I remember 15:24.30 Robin_Watts: presumably they would request the planes, and the color planes would be at the lower res 15:24.48 ray_laptop: How would they request the planes? using getbits? 15:25.01 No mechanism in getbits to signal that planes are at different res. 15:25.40 Robin_Watts: correct they've added that to our code already so easy enough to use what they have. 15:25.44 henrys: I haven't looked at that bit of hackery, do they convert to chunky pixels or separate planes (or line interleave) 15:26.07 henrys: They've added what to our code already? 15:26.08 ray_laptop: all chunky 15:26.18 Chans: (ghostbot) in:#ghostscript 15:26.27 Robin_Watts: and indicator at the beginning of each buffer what resolution it is. 15:26.41 At the moment I would imagine that they 'getbits' chunky pixels, and then downscale certain planes. 15:27.02 or maybe 'getbits' planar planes, and downscale. 15:27.17 They won't be changing our internal represenations at all so far, right ? 15:29.53 Robin_Watts: actually what they do is a bit different from what I said - they know the black data is 600 and the rest is 300 - they pickle in the width of each line when the copy not sure why that is necessary. Probably easiest for you guys to read the code it is fairly straightforward, hell I understand it ;-) 15:30.16 henrys: Where can I get a copy of the code? 15:30.28 I suspect that everything they currently do is 'post-getbits'. 15:30.38 Which is an infinitely sensible place for it, IMHO. 15:30.39 henrys: since you were doing it, I just haven't bothered (working on cust 532 issues) 15:31.24 Robin_Watts: yes, except they are rendering at 600 and processing every pixel -- which isn't great for performance 15:31.25 The only way you'd get significant benefits to doing stuff *pre* getbits, is if you could arrange for the original copy_mono/copy_color etc calls to be at the lower res. 15:31.35 Robin_Watts: but I agree that it's *nicer* 15:31.43 Otherwise you're having to downscale on every device call. 15:32.03 marcosw posted the ftp location somewhere I'll look. 15:32.11 Robin_Watts: well, copy mono for black wouldn't have to do anything 15:32.14 ray_laptop: No, I disagree. I think that it's going to far faster to process everything at 600dpi then downscale just once at the end. 15:32.31 and black text is the common case 15:33.07 I'm sure that's why they have black at higher res -- for text (particularly small CJK fonts) 15:33.09 ray_laptop: So when their device gets called with a 600dpi bitmap to 'copy_mono' they need to downscale that at that point. 15:33.13 That is hardly doing nothing. 15:33.33 Robin_Watts: but for black they don't downscale 15:33.34 Consider a page with a signficant amount of overpainting. 15:33.45 the color is downscaled not black 15:33.49 ray_laptop: OK, so not for black, for one of the color planes. 15:35.05 If there is a lot of overpainting, then you'll downscale every color component value for every paint of that pixel. 15:35.24 Whereas if you just do the dumb thing and downscale at the end, you only touch each pixel once. 15:35.29 Wholesale is cheaper than retail. 15:35.29 Robin_Watts: right -- if the color planes need to be erased (because they aren't white) we'd need to get the downscaled mask 15:35.42 support email search for "ftp" July 17 2013 Robin_Watts and ray_laptop ... 15:36.02 This is why the downscaler for tiffscaled etc works post getbits. 15:36.17 they actually went through the trouble off sse'ing the copied data, so I assume performance is an issue. 15:36.57 FORK(25663) --- fork starting for 'RSSFeeds', PID == 25663, bot_pid == 27362 --- 15:36.58 FORK(25663) !ERROR! cannot load my module: RSSFeeds 15:36.58 FORK(25663) fork: took 1s for RSSFeeds. 15:36.58 FORK(25663) --- fork finished for 'RSSFeeds' --- 15:36.59 Robin_Watts: I agree that doing the buffers at the end is simpler, and easier to tackle with SSE code 15:39.16 however the memory savings would be quite significant if there are few bands or full frame if could allocate 300 dpi space for 4 planes and 600 for 1. There's is a 5 color device. 15:39.20 henrys: I see one that my email thinks is 7/18 with M.S. saying he uploaded their project to the FTP site 15:39.42 henrys: I don't think they are memory constrained 15:40.09 ray_laptop: probably not. 15:40.33 henrys: Yes, we would save memory by holding those bands at lower res. But I fear we would lose speed. 15:40.35 henrys: and didn't you say that they need shorts ? is their color model 16 bits per pixel or 8 ? 15:40.47 yeah, why 16bits per component ? 15:41.01 ray_laptop: component, not pixel, AIUI. 15:41.18 Robin_Watts: I was surprised about that as well and hence brought it out in the email for clarity 15:42.05 is there something about SSE that would make shorts preferable? 15:42.25 Chans: (ghostbot) in:#ghostscript 15:42.40 Robin_Watts: I admit that downsampling a copy mono every time we paint a glyph would be slow IF we need to which is for copy mono with a color that is not black or, when the color is black and the color planes are not white 15:43.20 henrys: is the black plane 16 bits as well ? 15:43.21 henrys: Which zipfile from the ftp site? 15:43.36 xxxx_project.zip or xxxx_project_0822.zip ? 15:43.42 chrisl: you said another customer was doing this. Was it planar rendering. 15:44.22 Robin_Watts: either one has a few bug fixes for running on linux which you won't use. 15:44.44 I'll take the latter one then - newer, and 1/3 of the size. 15:44.48 Robin_Watts: use the latest one. 15:44.57 thanks. 15:45.17 henrys: not our customer, an old Jaws OEM. 15:45.21 and if you use pcl you need the fix I just emailed him - gs should be okay 15:45.38 chrisl: do you know if they were doing planar rendering? 15:46.16 They would have been doing serial separations, I believe. Each separation produced by rerunning the display list 15:46.30 ray_laptop, Robin_Watts It does seem if we went to a planar rendering model we could do different CTM's just a matter of coding ;-) 15:47.00 chrisl: Is the jaws displaylist resolution dependent ? 15:47.32 henrys: the problem is with bitmaps (images or glyphs) 15:47.42 henrys: If we went to a planar rendering model, and wanted to hold different planes at different res, I think you'll give the clist a stroke :) 15:48.05 Robin_Watts: yeah you are right. 15:48.06 Robin_Watts: largely so, but not completely. For the few cases it wasn't it was good enough to create the display list at high res, and do "stuff" to get it to lower res 15:48.55 to have resolution independent display list, text has to be paths, and without glyph caching of the bitmap that would SUCK with performance 15:49.33 ray_laptop: the glyphs were resolution dependent, but were generally in black, and therefore at the higher resolution 15:49.55 ray_laptop: That's not true. 15:50.08 MuPDF has a resolution independent display list. 15:50.15 I suppose you *could* have text as paths, and then have the glyph cache in the playback, and render to both resolutions 15:50.23 ray_laptop: note this was slightly different, as the differentiation was contone vs line art, not based on separations 15:50.25 It's just a different set of choices that you carry through. 15:50.31 Robin_Watts: mupdf has text as high level, right ? 15:50.37 ray_laptop: Right. 15:51.03 The problems that clist has with this instance are a consequence of the design decisions that were made right at the start of designing clist. 15:51.09 so as I said, the glyph cache is performed in the reader when it knows the res 15:51.19 And they were probably made for good reason. 15:51.40 is marcosw around 15:51.53 storing glyphs as path in the clist would be resolution independent. We'd just have to add caching 15:52.10 ray_laptop: 'just'. 15:52.10 mvrhel_laptop: I've been looking for him too. 15:52.14 ok 15:52.24 maybe at 9 15:52.50 Robin_Watts: simpler than putting all of the font logic post clist. 15:53.58 ray_laptop: I don't have a clear enough view to have a strong opinion on how it works out with the wacky clist bitmap cache management. 15:53.59 kens: for the first questions do I need to run any special command options? 15:54.09 except for text, the clist is resolution independent (at least when we don't do "default" image processing to lots of rect fills) 15:54.16 for this particular problem why couldn't we just render fonts at 600 dpi and put them in the clist? 15:54.18 or just render even to a raster device 15:54.22 mvrhel_laptop : yes you will still need the -dPDFUseOldCMS 15:54.27 For mupdf, it's a lot cleaner to have the font logic post clist. 15:54.34 but the question really is 'am I doing something dumb' ? 15:54.37 Robin_Watts: I strongly agree that the clist tile cache is wacko 15:54.55 Robin_Watts: cleaning that up is on the enhancement list 15:55.01 mvrhel_laptop : you can see the colour space has no icc_equivalent without going near pdfwrite 15:55.23 where can I catch it like this? 15:55.31 kens ^^ 15:55.35 mvrhel_laptop : Hmmm..... 15:55.43 In zimage1 I think 15:55.52 Or possibly zimge1_setup 15:55.59 henrys: we could render fonts at 600 (and do). the problem is when painting the glyph that is not black, or when we need to erase bits that are painted black on color planes 15:56.01 Let me get a debugger up 15:56.17 Their device looks to be doing the funky color encoding chicken dance. 15:56.38 henrys: the common case of black text on white would be fine. 15:56.40 I bet planar operation would help immensely. 15:57.02 mvrhel_laptop : If you break in image1_setup you can see it 15:57.14 Robin_Watts: they are switching to 9.10, so hopefully will not be using the compressed color encoding 15:57.17 break on line 209 in zimage.c 15:57.35 just after: 15:57.35 gs_color_space *csp = gs_currentcolorspace(igs); 15:57.48 Robin_Watts: yes, and avoid the whole compressed encoding problem 15:57.53 you will see that csp->icc_equivalent is NULL 15:58.43 Chans: (ghostbot) in:#ghostscript 15:58.44 Robin_Watts: the action starts in clist_render_thread() in the code you've downloaded. 15:58.55 henrys: so they are currently rendering to 8-bit (40 bit depth), then just moving the 8 bits to shorts for some reason, right? 15:59.08 henrys: Oh, god, so they've fiddled with the internals of gs? 15:59.48 Robin_Watts: yes which I want to also get us free of. We need a maintainable solution not some patchwork 15:59.49 typical of "do it yourself" customers 16:00.00 I was just reading gdevxxxx.c and gdevxxxxgraph.c 16:00.09 ok the issue is that it has not really tried to paint with that space yet 16:00.11 I suspect 16:00.25 mvrhel_laptop : No it won't have,m its just an image 16:00.31 So we draw the image in that space 16:00.49 once we start drawing it does the creation I think 16:01.01 and yes 16:01.06 Robin_Watts: I think it easier to understand if you read the mods to gxclthrd.c but whatever works. 16:01.07 henrys: they are doing BNM from the contone into planar data in pms_600x600to300x300_MTR_5C 16:01.09 in gs_image_begin_typed 16:01.33 : Hmm, either pdfwrite doesn't go there, or it doens't woprk, just a moment 16:01.44 in gsimage.c line 219 16:02.06 it does a code = gx_set_dev_color(pgs); which then leads to things getting set up 16:02.41 anyway I leave it to ray_laptop and Robin_Watts I have my own chaos to unravel. 16:02.46 kens: I am doing pdfwrite 16:02.57 mvrhel_laptop : me too give me a minute 16:03.04 brb in 2 secs 16:03.11 henrys: what a MESS that code is 16:03.51 Why? Why? Why? Why would they fiddle with it THERE? 16:04.11 ray_laptop: yes I really want to act proactively and get a good working solution or we're going to get in a hole with this one. 16:04.21 mvrhel_laptop : THat works for the imagemask, but not for the image 16:04.24 that much is obvious 16:04.33 For the image, uses_color is false 16:05.01 henrys: Indeed. I think we should send them a strongly worded email saying that we consider them to be working the wrong way. 16:05.22 When they move to 9.10 they should do stuff in the device. 16:05.29 Robin_Watts: I suspect it is because they want it to be multi-threaded. Their device is in the main thread 16:05.45 ray_laptop: Urgh. 16:05.52 mvrhel_laptop : do you follow me ? 16:05.55 Robin_Watts: but they'd be better off (IMHO) just spawning threads in their device 16:07.00 FORK(25346) --- fork starting for 'RSSFeeds', PID == 25346, bot_pid == 27362 --- 16:07.01 FORK(25346) !ERROR! cannot load my module: RSSFeeds 16:07.01 FORK(25346) fork: took 2s for RSSFeeds. 16:07.01 FORK(25346) --- fork finished for 'RSSFeeds' --- 16:07.17 they are probably (like many folks) sort of scared of threads, but I sure hope they know what they are doing in all that mess to make it thread safe. 16:08.34 Robin_Watts, ray_laptop I also don't want to be rude - I'm going to bring in takane-san and consult with him about how best to pursue this. 16:08.49 henrys: PLEASE!!! 16:09.07 ray_laptop: Yes, I bet you're right about them wanting the benefit of multi-threading. 16:09.15 That would explain why they've put it in there. 16:09.16 I'd rather us do it then have them have stuff buried in gxclthrd.c 16:09.48 and those pms BNM functions can't be fast 16:12.21 kens : I am back 16:12.58 OK mvrhel_laptop THe first pass is an image which sets uses_color to false, so we don't execute gx_set_dev_color 16:12.59 henrys: unless you want me to dig into this mess, I'm just going to ignore it until we hear back from them 16:13.11 and work on the urgent cust 532 issue 16:13.18 mvrhel_laptop : THe imagemask (the second call) does have 'uses_color' true so that works 16:13.21 ray_laptop: makes sense 16:13.48 kens: so where do you need to have the icc profile and you don't have it? 16:14.08 Chans: (ghostbot) in:#ghostscript 16:14.29 mvrhel_laptop : The image (first call) ends up innew_pdf_begin_typed_image and there is no Icc_equivalent in the color space, I need one there. 16:14.45 I could do it myself if that's reliable. 16:15.10 ie I can test the icc_equivalent, and if its nULL I cna call gx_set_dev_color 16:15.35 Oh actually, maybe I can't, I'm not sure I have a full graphics state 16:15.49 Seen: Flushed 6 entries. 16:16.06 No, its OK I do have a full graphics state, so I cna do it myslef 16:16.14 If you think that's acceptable 16:16.14 --- Saved uptime records. 16:16.18 henrys, ray_laptop: A smart way to do this might be to allow devices to declare a 'post-render' function that will get called on each band (or buffer) after rendering is done. 16:17.21 Robin_Watts: right. That would let tiffscaled scale the buffers in multiple threads, which would please cust 531 16:17.28 That would get the device the multi-threading stuff for free. 16:17.38 ray_laptop: Hmm. hadn't considered that, but yes. 16:17.55 Robin_Watts: they have BIG IRON 12 core Xeon and use the tiffscaled sometimes I think 16:18.06 tiffscaled uses error diffusion, so each band is not independent. 16:19.00 Robin_Watts: I thought tiffscaled just did thinks like 600 to 200. 16:19.07 kens: so I am never getting to new_pdf_begin_typed_image 16:19.16 what am I doing wrong 16:19.26 * ray_laptop/#ghostscript goes to check the tiffscaled docs 16:19.32 am I supposed to have -dPDFUseOldCMS? 16:19.34 mvrhel_laptop : you need to set -dPDFUseOldCMS=false to get there, other wise you end up in pdf_begin_typed_image 16:19.38 ray_laptop: The downscaler changes resolution and/or color depth. 16:19.43 oh = false 16:20.02 mvrhel_laptop : but the poitn is that the color space at that time has no icc_equivalent, you don;t really need to go there 16:20.07 In particular, it can go from 8bpp -> 1bpp, and for that it uses error diffusion to get much nicer results than simple dithering. 16:20.27 >>> join/#ghostscript marcosw_ (~marcosw@eduroam-245-101.ucsc.edu) 16:20.29 Robin_Watts: I see (having read the docs, now) 16:20.31 kens: well I am just trying to see the stack at that point and why we dont have one 16:20.40 sorry I'm late 16:20.56 ray_laptop: But for non color depth changes, yes, working on the threads would be nicer. 16:21.05 Robin_Watts: BNM is almost as nice and *much* faster, so it should be an option (IMHO) 16:21.30 mvrhel_laptop : OK well if you set -dPDFUseOldCMS you'll end up in the new funstion, if you don't then you end up in pdf_begin_typed_image, but the bew one uses icc_equivalent while the old one does not. 16:21.36 kens: you have a full gstate there 16:21.37 Robin_Watts: and BNM *could* be done in threads 16:21.49 mvrhel_laptop : yes, I did say that in one commetn above 16:21.53 ok 16:22.19 I also said I cna gall gx_set_dev_color, if its appropriate to do so and won't cause nay headaches ;-) 16:22.21 ray_laptop: right. 16:22.44 kens: it really is the only way to do it. until that is done, the profile will not be generated 16:23.29 mvrhel_laptop : No problem, then I will go ahead and add that check throughout (there are a number of places I assume that icc_equivalent is set). I'll do it tomorrow though. Thanks. 16:23.38 ok. 16:23.44 so does this solve question 2 too? 16:24.29 if anybody needs me, just SMS if I'm not responsive here. 16:25.22 marcosw: we'd like to test GX_COLOR_INDEX of size 64 and 32 (compile time) is that okay? 16:25.28 mvrhel_laptop : I don't think so. In that case the colour I'm getting back from the CMS seems to be incorrect. 16:25.54 marcosw: do we test anything that varies at compile time? 16:26.01 mvrhel_laptop : Its a CIEA space, and the colour value is '1' when I render that it comes out as white. When I convert it to RGB it comes out as mostly black 16:26.45 >>> join/#ghostscript sicos (541f1fe3@gateway/web/freenode/ip.84.31.31.227) 16:27.20 good evening 16:28.08 Does somebody know if it is normal with ghostscript to get an inverted tiff file (black is white and white is black) when I use the tiffscaled device with g4 compression to convert a pdf to tif? 16:29.30 sicos: that sounds wrong. 16:29.42 it happens with every pdf that I use 16:30.02 Chans: (ghostbot) in:#ghostscript 16:30.05 When I use g3 compression everything is fine... but I need g4 compression 16:30.20 kens: ok I will take a look 16:30.33 I tried gs 9.06 to 9.10 but all have the same problem 16:30.40 mvrhel_laptop : thanks. I have to go off and deal with dinner now, I'll be back later 16:30.43 sicos: well it sounds like a bug. Why do you *need* g4? 16:31.21 We have some scanner software that does some ocr ... it only accepts fax ccitt 4 compression (g4) 16:31.41 It refuses to accept anything else 16:32.06 Well, report a bug, and we'll look into it 16:32.14 I'll do 16:32.38 kens.. have a nice dinner 16:33.43 sicos: what platform are you running? Did you build gs yourself? 16:33.46 Just another question... Why is the output quality better when I use -r600 with for example downscale factor 6 to get a tiff with 100dpi instead of just using -r100 ? 16:34.14 chrisl .. I'm on Windows and downloaded gs from the download page 16:34.40 I think if you use -r600 you get 600dpi output 16:34.56 chrisl: No, he's right. 16:35.07 I got the problem on my work with windows xp, also have it on a windows 2003 server and at home on windows 8 16:35.38 gs renders at the specific resolution internally. So 600dpi. Then it applies the downscale factor to get to 100dpi. 16:35.57 Ah, I thought it worked the other way round 16:36.17 Normally I used -r100 until I discovered the downscale factor... the result is huge 16:36.27 Didn't know that would make such a difference 16:36.27 No, the downscale happens 'post getbits', so the resolution sets what you get out of getbits. 16:36.43 kens: for when you return. with issue 2 I am never getting to write_color_as_process 16:36.52 sicos: When you are using a downscale factor, we render at 8bpp internally, and then error diffuse down to 1bpp. 16:37.05 error diffusion gives much nicer results than a simple halftone. 16:37.06 FORK(18529) --- fork starting for 'RSSFeeds', PID == 18529, bot_pid == 27362 --- 16:37.07 FORK(18529) !ERROR! cannot load my module: RSSFeeds 16:37.07 FORK(18529) fork: took 2s for RSSFeeds. 16:37.07 FORK(18529) --- fork finished for 'RSSFeeds' --- 16:37.13 But 600dpi down 6 is way overkill. 16:37.21 Does it make a huge speed difference? 16:37.31 use downscaling instead of -r100 16:37.31 You'll probably do just as well with 300dpi down 3. 16:37.46 There will be a performance difference, yes. 16:38.03 Robin: I'm still in the trying out phase so I'll keep that in mind.. thanks for the suggestion 16:38.10 I wouldn't like to predict how huge. 16:38.28 kens: perhaps I am missing some change you have 16:38.29 200dpi down by 2 will effectively draw 4 times as many pixels. 16:38.38 300 down 3 9 times as many pixels. 16:38.52 600 down 6, 36 times as many pixels. 16:39.04 until then, I will fool with mupdf 16:39.12 And I have special case code in there for the 2 and 3 case, IIRC. 16:43.36 So, tor7, how's the chromebook? 16:43.49 sicos: I can't reproduce the problem on Linux - what are you using to view the tiff? 16:44.19 faststone image viewer 16:44.55 i'll try the fax viewer 16:45.12 Okay, I don't know that app, but as long as it wasn't the Windows viewer - it has lots of troubles with tiff 16:45.39 uhm 16:45.49 seems to be a faststone image viewer problem 16:45.56 uhm... sorry about that 16:46.09 Chans: (ghostbot) in:#ghostscript 16:46.11 sicos: ah, phew. 16:46.35 strange... when I use another tool to produce g4 files they all open fine with faststone 16:46.56 so I wonder what bit in the header file of the tiff throws faststone image viewer off 16:47.12 It may be the photometric 16:47.50 Our output is "Photometric Interpretation: min-is-black" 16:47.59 henrys: Where are you seeing the 16bit operation in this stuff? 16:48.26 well nevermind... keep up the good work with ghostscript.. it is a fantastic tool 16:48.31 I'm seeing a copy from a byte array to a short array 16:48.39 henrys: where? 16:49.09 and it sure beats a lott of other tools 16:49.33 sicos: libtiff comes with some useful tools for getting info from tiffs, if you can find it for Windows 16:50.07 gxclthread.c:4944 near that. 16:51.11 ok. I was looking in the mono case, and that doesn't use 16 bits. 16:51.35 unsigned short *avgColor 16:52.26 henrys: yeah, they are copying the CMYK values into the output and adding them. 16:52.42 so they are holding 4 lots of 8 bit values added together in each short. 16:52.58 Then they divide by 4 at the end. 16:53.05 mvrhel_laptop: for RAW_DUMP, should I check "Interleaved" ? 16:53.12 so it's only 8 bit operation, implemented extremely inefficiently. 16:53.25 ray_laptop: the data is planar not interleaved 16:53.41 God, that's a horrible piece of code. 16:53.45 ray_laptop: what are you working on? 16:54.02 Robin: I also tried to open the tiff with the "Microsoft office picture viewer" but that one also doesn't like the tiff :-) 16:54.12 mvrhel_laptop: OK. Thanks. Sorry, I forgot to mention that I was asking about the Photoshop settings, but I guess you figured that out 16:54.20 yes 16:55.08 marcosw came by to say sorry he was late and then left apparently ;-) 16:56.15 ray_laptop: So... this idea of having a 'post process' function seems like a good one to me. 16:56.24 OK, so *finally* got RAW_DUMP to work with cust 532's code 16:56.31 Robin_Watts: yes, indeed 16:56.42 It would be a much nicer solution to this, and has scope for other things. 16:57.06 BUT... I can see that in a lot of cases, people are going to want a guarantee that the post process things are run "in order" 16:57.19 is there any magic downscalefactor formula like 600 downscale 2 for 300 dpi, 400 downscale 2 for 200 dpi and 200 downscale 2 for 100 dpi? 16:57.46 I'm up to the ears with cust 532's pb. Can you suggest what parameters we'd pass when we callout ? 16:57.47 (for instance, if people are doing say, error diffusion, or they are sending data off via DMA, or they are writing it to a file etc). 16:58.05 ray_laptop: Sure. I'll put together a proposal. 16:58.17 mvrhel_laptop : My mistake, you need to set the DEVICE=ps2write -dPDFUseOldCMS=false 16:58.23 oh 16:58.25 ok 16:58.26 Robin_Watts: for DMA, they want the bands in order, not when they are finished, which will be arbitrary order 16:58.35 * kens/#ghostscript dashes off again 16:58.39 ray_laptop: Right, that's my point. 16:59.08 So, possibly we'd want an option to ensure that the bands happen 'in order'. 16:59.21 and writing to a file, would need to have the entire page allocated and do *seek* to write whichever band 16:59.30 Or we could leave it to the function that's called back to wait in turn. 17:00.29 My point is, that even if the callbacks wait to happen in sequence, it would still be a net win overall, I think. 17:00.47 Robin_Watts: I think that doing DMA or file writing is best left to the main thread, but updating a page image in memory can be done randomly 17:01.20 as one thread can get on with rendering while the next one is in the callback. 17:01.21 Robin_Watts: it'll be a win if there is more processing than just writing the bands 17:01.42 sicos: what you mean by "magic"? 17:01.58 so my question is, should we offer an optional 'in order' guarantee? 17:02.08 Chans: (ghostbot) in:#ghostscript 17:02.27 Robin_Watts: can JPEG or PNG be compressed as bands ? 17:02.29 i.e. should the device be able to say "please call this function back after each band, and do so in order". 17:02.35 just the best option between memory usage and speed 17:02.37 ray_laptop: depending on the settings in use, yes. 17:02.50 I mean memory usage, quality and speed 17:03.16 sicos: it rather depends what your goal is. 17:03.36 sicos: there's no magic bullet that's right in all cases 17:03.47 Robin_Watts: having to wait for previous threads means it kills the parallelism 17:03.49 chrisl: good quality for ocring but with good speed 17:04.04 ray_laptop: It *limits* the parallelism, it doesn't kill it. 17:04.35 chrisl: I use a quadcore server with 8gb of memory to do all the conversion jobs 17:05.10 sicos: I don't work with any ocr packages. Best I can suggest is to experiment. Personally, I'd think that you'd want fairly hi res output for accurate OCR operation 17:05.16 sicos: It depends on your input file and the input that the OCR package takes. 17:05.25 Robin_Watts: how so? If thread 1 (the first band) takes longer than thread 2, 3, and 4. then 2, 3 and 4 will have to wait until thread 1 is done and thread 4 has to wait for 1, 2, 3 to finish 17:06.02 Robin_Watts: plus the threads don't know about each other (currently) 17:06.04 ray_laptop: Yes. But as soon as the band processing of 1 is finished, that thread can start processing 5, while we do the post band processing of 2. 17:06.56 Robin_Watts: but if the callout post processing is compute intensive, then we don't get to overlap ! 17:06.57 Robin_Watts: absolutely gorgeous! 17:07.17 so the concurrency is not as smooth as before (i.e. there will be contention), but it's better than nothing. 17:07.21 Robin_Watts: best screen I've ever had (though obnoxiously shiny, but I can live with that) 17:07.22 FORK(15672) --- fork starting for 'RSSFeeds', PID == 15672, bot_pid == 27362 --- 17:07.23 FORK(15672) !ERROR! cannot load my module: RSSFeeds 17:07.23 FORK(15672) fork: took 2s for RSSFeeds. 17:07.23 FORK(15672) --- fork finished for 'RSSFeeds' --- 17:07.30 good keyboard, and trackpad is apple quality 17:07.32 ray_laptop: Indeed. 17:07.41 Robin_Watts: I don't see how it's better than letting the main thread just have it 17:07.51 sicos: also, I'd have thought that using grayscale instead of halftoned output would be preferable for OCR (if the ocr can take it), but I don't really know. 17:07.55 >>> marcosw_ has signed off IRC (Quit: marcosw_) [#ghostscript] 17:07.59 going to get a high speed SD-card tomorrow, so I'll see how it does on dual-booting 17:08.01 in order, after the callout has finished 17:08.13 running crouton to get a chroot:ed ubuntu install works just great though 17:08.14 tor7: and you'll get me a picture..? 17:08.31 shame about linux toolkits not really coping with high-dpi screens :( 17:08.32 that way all of the callout processing is ALWAYS in parallel 17:08.49 sebras-hotel: working on it. one sec. 17:09.03 ray_laptop: OK, I think you've killed my idea of us offering a 'callback in order' option. 17:09.10 Robin_Watts: I really have to get to work now, however. Glad to talk more later 17:09.13 chrisl: at the moment I first convert a pdf to pnggray and then use victor.dll to convert it to g4 format (that is because i thought ghoscript screwed my tiff file up.. I know better now :-)) 17:09.36 chrisl: But I'm probably going to fix that code now that I know it is a faststone image viewer problem 17:09.55 chrisl: so it's no more a 2 step conversion. 17:09.59 tor7: sounds like a nice, square pixel though. :) 17:10.33 sicos: sure, but I'd have thought the pixel "patterns" of the halftone might pose extra problems for the OCR package. 17:11.07 sicos: Does the OCR package only accept 1bpp input files? 17:11.13 yes 17:11.27 tor7: actually if you want to make it easy, you might want to use Line to send it to me... 17:11.37 it want to have ccitt fax 4... so far as I know that is 1bpp 17:11.49 sicos: oh well, so much for that idea 17:12.18 sicos: it is. It's a shame that it only takes 1bpp input, cos it's forcing someone to have made decisions about throwing information away already. 17:12.36 don't shoot the messenger :-) 17:12.57 I still think you'd want high-ish res for best results 17:13.04 Most scanners output 8bpp data, which would be a much more sensible input to an OCR package as it wouldn't have to cope with dithering etc. 17:13.35 chrisl: Given that you need 1bpp input, you probably want high res, but with decent error diffusion. 17:13.39 does the tiffscaled device also support antialiasing? 17:13.45 or is that only possible on png? 17:14.17 sicos: Antialiasing is the trading of spatial information for color depth information. It's kinda hard to do that when you are going to 1bpp. 17:14.45 >>> ray_laptop has signed off IRC (Ping timeout: 272 seconds) [#ghostscript] 17:15.03 But tiffscaled works in 8bpp internally, then scales down, then error diffuses; so the internal representation (before error diffusion) is antialiased. 17:15.07 but for example if you go to tiff gray scale.. does it then make any difference? 17:15.13 ok 17:15.26 And you certainly don't want antialised output for OCR purposes 17:15.47 chrisl: Unless you have overly high res predithered input. 17:16.07 Seen: Flushed 10 entries. 17:16.17 --- Saved uptime records. 17:16.39 I'd assume that you'd want the sharpest defined edges possible for OCR 17:16.45 indeed 17:17.11 chrisl: Imagine that you are trying to OCR something that's come out of a full color CMYK process with colored text in it. 17:17.48 but I'll admit that's a corner case. 17:17.52 tor7: oh! I spy with my little eye, no windows keys! :) 17:18.13 sebras-hotel: the "caps lock" is by default Super_L ;) 17:18.26 tor7: even better! :) 17:18.44 tor7: doesn't even look like it's labeled caps lock. 17:18.54 Chans: (ghostbot) in:#ghostscript 17:18.56 labelled! 17:19.08 What I'm trying to find is the best setting possible for ghostscript. I know the output has to be g4. The input file kan be any kind of pdf in anykind of resolution, fully text or just scanned images 17:19.33 tor7: but when you move that chair, don't unplug the extension cord... 17:19.42 Robin_Watts: I was thinking more of using the output of a RIP that you can control. I'd have thought something like 600dpi, 1bpp error diffusion halftoned would give the best OCR results. 17:20.06 * sebras-hotel/#ghostscript leaves for bed, good night artifexians! 17:20.24 chrisl: Does tiffscaled handle -dDownScaleFactor=1 ? :) 17:20.26 It is an automated proces so there is no man in the middle that can fiddle with the conversion settings 17:20.30 sebras-hotel: good night 17:20.30 sebras-hotel: good night! 17:20.38 good night 17:20.51 sicos: Try: -r600 -dDownScaleFactor=1 17:20.59 >>> sebras-hotel has signed off IRC (Quit: bye) [#ghostscript] 17:21.04 Robin_Watts: well, it didn't throw an error..... 17:21.08 kens: so I see 2 issues 17:21.12 sorry forgot one thing.. the resolution has to be 300 dpi :-) 17:21.33 One is that the equivalent profile was not being used with the call to get_link. I will commit that fix 17:21.38 -r300 -dDownScaleFactor=1 then. 17:21.47 however. that is not the source of the black vs white 17:21.49 or -r600 -dDownScaleFactor=2 17:21.52 That does indeed seem to work] 17:22.54 kens: the main problem is line 463 in gdevpdfg.c 17:23.22 the color values in Converted are coming out white 17:23.41 but the mapping to colors.pure in 463 is not doing what I think you want it to do 17:23.52 Robin_Watts: I assume -r300 -dDownScaleFactor=1 will be faster..... 17:25.08 chrisl: Yes. 17:26.05 kens: let me see if I can fix it... 17:26.09 does .. uhm i think to parameter was called renderingthreads .. speed anything up? 17:26.39 sicos: I doubt it. 17:26.50 sicos: probably not at 300dpi, no 17:27.10 renderingthreads will help the rendering time of the doc. It will not help the error diffusion process, and I suspect that is the slowest bit. 17:28.19 and dBandBufferSpace ? 17:28.37 since i got more then enough of memory in the server 17:29.01 ok. that fixed it. 17:29.04 sicos: do you know if the text is always pure black, or can it be other colours and tints? 17:29.07 sicos: If memory is no object use -dMaxBitmap=10000000 17:29.08 you wanted /256 not /255 kens. 17:29.57 >>> join/#ghostscript marcosw_ (~marcosw@eduroam-245-101.ucsc.edu) 17:30.41 >>> join/#ghostscript ray_laptop (~chatzilla@rrcs-64-183-45-163.west.biz.rr.com) 17:31.21 it can be any kind of pdf 17:31.54 with just scanned color pages in it.. or black and white... it even can be a text based pdf 17:32.28 Okay, so you do want the error diffusion - if the text had always been pure black, then a quicker halftone solution would be viable 17:32.30 I work at an insurrance company and customers can declare there bills through a web portal. I dont know how there pdf files are generated 17:33.22 sicos: I would encourage you to get your bosses to get a support contract for gs. 17:33.22 it can be a paper bill that they scan on just a pdf bill they got from for example there dentist 17:34.13 robin: do you know how much that will cost for a year? 17:34.20 If you are using it as part of a large commercial enterprise (and you are), it would seem reasonable to ensure you have support. 17:34.25 offhand, no. 17:34.42 kens: ok clusterpushing a fix 17:34.52 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 17:34.52 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 17:34.52 Chans: (ghostbot) in:#ghostscript 17:34.53 I already tried to look it up on the ghostscript portal but there aren't any prices overthere 17:34.57 but if you contact sales@artifex.com they can do you a quote. 17:35.08 sicos: Indeed, we tailor prices to circumstances. 17:36.16 well i'm going to call it a night... I think I asked you enough.. thanks for listening 17:37.05 I'll send a mail to artifex.. thanks for the tip 17:37.39 FORK(17128) --- fork starting for 'RSSFeeds', PID == 17128, bot_pid == 27362 --- 17:37.40 FORK(17128) !ERROR! cannot load my module: RSSFeeds 17:37.40 FORK(17128) fork: took 1s for RSSFeeds. 17:37.40 FORK(17128) --- fork finished for 'RSSFeeds' --- 17:38.07 np. 17:39.12 >>> sicos has signed off IRC (Quit: Page closed) [#ghostscript] 17:50.49 Chans: (ghostbot) in:#ghostscript 17:51.32 windoze 8.1 update out this friday.... 17:53.32 and VS 2013 comes out in less than 1 month 17:54.23 mvrhel_laptop: Are you taking orders? :) 17:55.50 >>> marcosw_ has signed off IRC (Quit: marcosw_) [#ghostscript] 17:56.08 So, you can't code for windows 8.1 without VS 2013. That means a month where no one will be able to use Windows 8.1 - so no change there then! :) 17:56.54 Robin_Watts: Maybe I can bring a copy to the next staff meeting 17:57.29 mvrhel_laptop: I'm not in the market for the 8.1 update. I never use my copy of windows 8, personally. 17:57.58 Depending on what VS 2013 brings to the party, it may or may not be worth buying a copy for the company. 18:00.46 true. I will get myself a copy for 8.1 dev. and see what is new 18:01.27 Do MS offer a VS2012->2013 upgrade? 18:01.30 kens: fix for you problem #2 pushed 18:01.36 Robin_Watts: not idea 18:01.39 no diea 18:01.41 idea 18:01.42 mvrhel_laptop : I just got back, thanks, that was quick! 18:02.08 I am eager to get done with gs and fix my mupdf issues... 18:02.09 I can imagine that people who forked out for VS2012 to do win 8 dev are now going to be very annoyed if they have to fork out again for a .1 revision. 18:02.19 oh 8.1 is free 18:02.25 dont know about VS2013 18:02.25 * kens/#ghostscript is keen to finish up the colour code 18:02.41 kens: I am hoping to get you V2 profiles before staff meeting 18:02.48 That would be cool 18:02.53 but I am going to work on mupdf for a bit now 18:03.24 No problem, I have to go back to pdfwrite and the diffs that are produced. Some are progressions some are just slightly different. I need to make sure no more are faults 18:03.30 Robin_Watts: I see what you are saying 18:03.33 yes that would be annoying 18:06.36 kens: did you happen to see 694704 18:06.48 Hmm, not sure, just a momnet 18:06.55 http://weblogs.asp.net/lduveau/archive/2013/07/10/visual-studio-2012-2013-and-windows-8-1-apps-clarifications.aspx 18:07.02 I tried to understand in the interpreter why we do the sethalftone when the device is not a halftone device 18:07.09 but it is not clear to me 18:07.16 So VS2012 will not let you use the 8.1 additions. 18:07.22 mvrhel_laptop : I haven't looked at that bug 18:07.31 MS really hate their developers, don't they? 18:07.31 Chans: (ghostbot) in:#ghostscript 18:07.48 Presumably we set the halftone because the graphics state requiers that we have one 18:07.58 FORK(27693) --- fork starting for 'RSSFeeds', PID == 27693, bot_pid == 27362 --- 18:07.59 FORK(27693) !ERROR! cannot load my module: RSSFeeds 18:07.59 FORK(27693) fork: took 1s for RSSFeeds. 18:07.59 FORK(27693) --- fork finished for 'RSSFeeds' --- 18:08.35 hmm this does seem like a mess 18:08.46 * kens/#ghostscript wonders exactly what new functionality there is in windows 8.1 that VS 2012 apps can't target 18:08.50 I have a friend in the VS marketing group. I will have to ask him about this 18:09.03 window 8.1 has a lot of stuff 18:09.11 for e.g. native pdf rendering... 18:10.33 I would be worried though about app creation compatibility between 8 and 8.1 18:10.52 not sure it makes sense for someone to create something for 8.1 18:11.06 but perhaps everyone with 8 will update 18:11.27 mvrhel_laptop: Well, if the .1 is a free upgrade, ms can hire someone to go round all three of the users houses and update them. 18:11.34 hehe 18:16.20 Seen: Flushed 7 entries. 18:16.20 --- Saved uptime records. 18:16.56 I wonder how many of the broken / invalid PDF's their native rendering will cope with. And how well they'll handle the funky fill-black then imagemask white problem files we've seen. And the missing fonts. And ... 18:17.39 and whether or not they'll let people render into an image file 18:18.34 ray_laptop: 2 possible ways to do this suggest themselves; a new device function, or a dev spec op. 18:18.39 we should license GS to them so they can import PostScript, and take a step toward killing Acrobat 18:19.46 A friend just asked me "does VS2013 have new features, like lower case letters?" 18:20.05 Robin_Watts: why not just a pointer in the gx_device_printer * structure. gdev_prn_open inits it to NULL, they just set it before requesting data in 'print_page' 18:20.41 I don't see a reason we need a spec op or device function 18:20.58 Do all clist things go through a gx_device_printer ? 18:21.29 Robin_Watts: Not pattern-clist, but we don't do MT rendering for those 18:22.05 * kens/#ghostscript is off now, I'll get back to the colour code tomorrow Michael, thanks again. Night all 18:22.16 So I can safely cast dev in clist_render_thread to a gx_device_printer? 18:22.24 >>> kens has signed off IRC (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) [#ghostscript] 18:22.55 I was thinking that it would be good if this callback would work in both clist and non-clist cases. 18:23.08 bbiaw 18:23.08 Chans: (ghostbot) in:#ghostscript 18:24.00 >>> join/#ghostscript marcosw_ (~marcosw@eduroam-245-101.ucsc.edu) 18:27.27 casting from dev to gx_device_printer in clist_render_thread feels very wrong to me. 18:31.44 ok, so the only way we can ever get into the multi-threaded rendering case is if gdevprn.c has set it up. 18:31.53 Robin_Watts: to make the callback work for non-clist devices, we'd have to add it to gdev_prn_get_bits and gdev_prn_get_bits_rectangle if !PRINTER_IS_CLIST(pdev) 18:32.47 ray_laptop: Can we add it there and have that do both clist and non clist cases? 18:32.52 at that point we'd call out with whatever data comes from the underlying mem_get_bits_rectangle 18:33.24 Robin_Watts: no, because those two functions are in the main thread (above the get_bits_rectangle call) 18:33.38 ok. 18:33.49 >>> marcosw_ has signed off IRC (Quit: marcosw_) [#ghostscript] 18:34.01 we also need to make it get called in the clist, but not multithread case. 18:34.29 in the non-clist case, there really won't be any parallel processing since everything else for the page is done 18:34.40 Robin_Watts: yes 18:35.17 >>> join/#ghostscript marcosw_ (~marcosw@eduroam-245-101.ucsc.edu) 18:35.23 ray_laptop: Right, but it means the device writers don't need to worry about which case they are in. 18:35.42 Robin_Watts: right. I understood your intent and agree 18:37.32 Robin_Watts: it would be fun to do a clist display device and have the callback update bands on its page buffer :-) 18:37.49 watch parallel processing in action 18:38.00 interesting. 18:38.31 FORK(18452) --- fork starting for 'RSSFeeds', PID == 18452, bot_pid == 27362 --- 18:38.32 FORK(18452) !ERROR! cannot load my module: RSSFeeds 18:38.32 FORK(18452) fork: took 2s for RSSFeeds. 18:38.32 FORK(18452) --- fork finished for 'RSSFeeds' --- 18:39.00 Chans: (ghostbot) in:#ghostscript 18:39.10 So new printer device proc you reckon. 18:39.17 s/So/So a/ 18:39.21 huh ? 18:39.54 You reckon the way to do this is to have a new printer device proc? 18:40.06 I was just thinking a *post_processing_callback(...) element in the gx_device_printer struct 18:40.15 Ah, ok. 18:40.59 I guess it could be buried in the printer_procs 18:42.41 Robin_Watts: actually, putting it in the gx_printer_device_procs makes sense and is OK with me 18:42.48 ok. 18:43.47 all you have to do is figure out what params it should have (beyond gx_device_printer *) 18:44.21 the buffer device, the band number, the number of lines. 18:49.10 Robin_Watts: seems like enough. The buf_device has the info needed to access the band data 18:49.37 ray_laptop: Yeah. 18:49.50 so the calling function just calls get_bits or get_bits_rectangle on the bdev 18:51.11 and can cast the gx_device_printer to its device struct to get any info needed for the post processing, including, possibly where to put the results 18:52.24 I'm having trouble parsing that. 18:52.43 Robin_Watts: where will the data be processed into ? 18:53.01 ray_laptop: That's device specific. 18:53.49 The callback can choose to work 'in place' on the buffer device, or it can choose to copy to some other secret buffer that gs knows nothing about (but that it finds from within it's gx_device *) 18:53.54 yes, but where does it get the destination if it needs buffering. Or if it allocs it's buffer, how does it return the pointer ? 18:54.31 ray_laptop: Right. That should be hidden in the devices own structure. 18:54.41 Chans: (ghostbot) in:#ghostscript 18:54.48 Robin_Watts: each post_process invocation will need its own buffer. 18:55.15 it can't just scribble is a shared buffer 18:55.44 Robin_Watts: how about adding a *result param 18:55.56 ray_laptop: What would we do with it? I'm against that. 18:56.22 The customers code allocates a buffer, uses the buffer, and then writes the results back into the buffer device. 18:56.30 so the caller can read it out as the results of the getbits. 18:56.48 Robin_Watts: but the buffer device type and how it holds its data is opaque 18:57.18 ray_laptop: It had better not be opaque - the purpose of this post process callback is to work on it. 18:58.23 I'm missing something. In order for the post process to change the data depth or anything else, it CAN'T use the same buffer 18:59.23 the post_process calls the bdev->procs.get_bits to read from the rendered data in whatever format, but it can't scribble back in there 18:59.23 ray_laptop: If it's working 'in-place' then it is limited in what it can do, yes. 18:59.43 ray_laptop: Ah, right. The customers code does NOT get the data using get_bits. 18:59.47 Robin_Watts: but what if the data it wants to create is LARGER than the buffer 19:00.00 ray_laptop: Then it needs to copy it elsewhere. 19:00.40 It can allocate any buffers it likes, and then will have to stash those pointers into a list or something accessed via it's device pointer. 19:00.56 Robin_Watts: so how does each post_process thread tell the main thread where it put the data ? 19:01.32 >>> mvrhel_laptop has signed off IRC (Ping timeout: 268 seconds) [#ghostscript] 19:01.32 ray_laptop: It doesn't tell the main thread of ghostscript. It tells the device. 19:02.11 There will need to be some secret device specific way in which this callback can talk to the "main thread" of the device. 19:02.15 but that's not our concern. 19:02.17 that's what I meant. The main thread print_page calls get_bits which starts the rendering threads 19:03.14 right, and the rendering threads call into this function. 19:04.09 this function is part of the device. It can have any sort of setup it likes to get its results out. 19:04.26 gs doesn't need to be involved. 19:04.38 but it has to know where the data is when the get_bits returns -- so what ? an array of pointers for each line, or each band or something. We need an example implementation 19:05.59 ray_laptop: Well, the easiest way to do this would be for the device to allocate a page sized buffer up front. 19:06.23 Robin_Watts: sort of defeats the clist mode 19:06.36 and then the post process function can map from the rendered image into the page sized buffer. 19:06.43 how about an approach that doesn't need so much memory 19:07.09 Robin_Watts: I'll mull this over. I have to run an errand. bbiaw 19:07.17 an array of pointers would be just as much memory as a full sized buffer, right? 19:07.40 Robin_Watts: not one per line, no 19:08.39 FORK(29280) --- fork starting for 'RSSFeeds', PID == 29280, bot_pid == 27362 --- 19:08.40 FORK(29280) !ERROR! cannot load my module: RSSFeeds 19:08.40 FORK(29280) fork: took 1s for RSSFeeds. 19:08.40 FORK(29280) --- fork finished for 'RSSFeeds' --- 19:08.48 if you're going to have an array of pointers, one per band, presumably by the time that array is fully populated you will have a whole page worth in memory. 19:09.01 i.e. the same amount of memory as a page buffer would have needed. 19:10.39 Chans: (ghostbot) in:#ghostscript 19:11.03 oh, I see. how do we know when to free some of the lines (and invalidate the pointer) 19:11.24 ray_laptop: Device specific. 19:11.43 gs itself is not involved in anything the device does in the post process phase. 19:11.48 I *really* need to run. 19:11.56 sure. go. we can talk later/tomorrow. 19:14.28 >>> chrisl materializes into chrisl_away 19:16.21 >>> ray_laptop has signed off IRC (Ping timeout: 272 seconds) [#ghostscript] 19:16.21 --- Saved uptime records. 19:17.21 Seen: Flushed 3 entries. 19:26.49 Chans: (ghostbot) in:#ghostscript 19:38.49 FORK(378) --- fork starting for 'RSSFeeds', PID == 378, bot_pid == 27362 --- 19:38.50 FORK(378) !ERROR! cannot load my module: RSSFeeds 19:38.50 FORK(378) fork: took 1s for RSSFeeds. 19:38.50 FORK(378) --- fork finished for 'RSSFeeds' --- 19:39.19 >>> join/#ghostscript whoami_ (52ea77af@gateway/web/freenode/ip.82.234.119.175) 19:40.07 hello 19:40.07 somebody said hello 19:40.07 niihau 19:40.55 I am having a ton of problems trying to build mupdf related to openjpeg 19:41.11 Gigs-: Are you using the openjpeg that we supply? 19:41.19 debian doesn't have libopenjpeg1 apparently, so I did the git submodule thing 19:41.32 ok. 19:41.32 thirdparty/openjpeg doesn't populate, but the -patched one did 19:41.48 so I changed the reference in Makethird to the other name, but it's still not compiling 19:42.00 Gigs-: Eh? 19:42.18 What git revision are you on? 19:42.29 Makethird says thirdparty/openjpeg which is an empty dir, there's openjpeg-1.5.0-patched in thirdparty 19:42.48 I did git reset --hard and then pulled, should be up to date right? 19:42.56 I didn't see an autogen script so I'm not sure about the makefiles 19:43.06 Chans: (ghostbot) in:#ghostscript 19:43.11 nor ./configure for that matter 19:43.12 Gigs-: Do git log -1. 19:43.21 and tell me the revision. 19:43.31 Tue Oct 15 11:30:37 2013 +0200 commit d246518b3f3f64ba10475e5043c554011a383a1ccommit d246518b3f3f64ba10475e5043c554011a383a1c 19:44.14 to be honest I could do without openjpeg, jpeg2000 is a nice idea but it's sloooow 19:44.27 if it's not used internally I'll never use it for an output format 19:44.39 OK. Now do: git submodule update --init 19:44.42 k 19:44.58 Directory 'thirdparty/jbig2dec' exists, but is neither empty nor a git repository 19:45.00 I get that 19:45.07 but the first time I did it, it did openjpeg stuff 19:45.19 So delete it, and the -patched one, and retry, 19:45.24 k 19:45.49 nothing happened, I don't think git update replaces missing files 19:46.27 OK. Try completely deleting the thirdparty directory- you haven't got any changed files in there, right ? 19:46.30 no 19:46.44 ok that did it 19:46.50 it's getting curl and openjpeg 19:47.30 ah ok my thirdparty/openjpeg directory populated now, weird 19:47.54 let me try a build 19:48.21 looks like it's working now, thanks for your help 19:48.28 np. 19:52.02 I would like to accelerate the creation of PDF, you have any ideas? (I use already-dNumRenderingThreads = 2-c 30000000 setvmthreshold) 19:53.00 whoami_: Our PDFwrite expert signed off about 4 hours ago. You might want to try again tomorrow. 19:53.13 He works on UK time. 19:54.00 I just have one main lingering question about tint transforms from my essay the other day, FunctionType 0 /Size [ 2 ] /Range [ 0 1 0 1 0 1 0 1 ] /Domain [ 0 1 ] (stream) 00 00 00 00 00 80 FF 00> 19:54.09 And me French time :) 19:54.22 Sorry, you're creating pdfs, and you're using -dNumRenderingThreads? 19:54.32 AIUI, NumRenderingThreads doesn't apply to pdfwrite. 19:55.00 * Robin_Watts/#ghostscript has to step afk for a while, sorry. 19:55.11 yes that accelerate the creation of pdf 19:55.16 did it? 19:55.44 in my tint transform stream, how is it ordered, like C C M M Y Y K K? If that's the case, why is K inverted? 19:59.03 Chans: (ghostbot) in:#ghostscript 20:03.06 Robin_Watts it is in the general framework of a pdf on sending server, then you think that the fastest way to the customer that my program sends the ps file and then creates the pdf on the server 20:07.17 whoami_: where are the PS files now? Are they dynamically generated? 20:08.29 for now I generates pdf with GS / Redmon with a ruby program. 20:08.47 where do the source PS come from? 20:09.27 FORK(7253) --- fork starting for 'RSSFeeds', PID == 7253, bot_pid == 27362 --- 20:09.28 FORK(7253) !ERROR! cannot load my module: RSSFeeds 20:09.28 FORK(7253) fork: took 1s for RSSFeeds. 20:09.28 FORK(7253) --- fork finished for 'RSSFeeds' --- 20:11.10 From printing of user (Printer => Redmon => Ghostscript => PDF) 20:12.13 There are programs to directly let them print to PDF 20:12.38 cutepdf for example 20:12.50 it includes a bundled copy of ghostscript that runs on their machine 20:14.13 I think even redmon can go straight to pdf 20:14.53 Chans: (ghostbot) in:#ghostscript 20:15.07 non malheureusement 20:15.42 well there is no need to go to a server anyway 20:16.32 at least not as PS, you can always send the PDF to a server 20:16.32 --- Saved uptime records. 20:16.48 that way all the clients do their own rendering and speed is not a problem 20:16.58 the purpose is to have a pdf file on my server (for my personal needs) 20:17.33 Seen: Flushed 3 entries. 20:18.24 yeah, I would still render it on the client as they print and then upload the pdf to the server 20:18.37 especially if you are having speed issues on the server 20:18.38 >>> join/#ghostscript ray_laptop (~chatzilla@rrcs-24-43-98-229.west.biz.rr.com) 20:18.55 raaaayyyy 20:19.03 because if the generation of pdf froze programs for several minutes when the pdf are dozens of pages 20:20.10 ghoscript really doesn't do parallel 20:20.33 if you only can handle one at a time you need to redesign your program to be able to run more than one copy of ghostscript 20:21.07 or install gs on all the clients and rendering it there first 20:22.09 I do not understand what you want to do or how or why 20:22.39 there already GS on my clients 20:22.59 so it is the client that is locking up then 20:23.18 I thought you had the opposite problem 20:23.36 yes just send the PS to the server and run ghostscript there 20:24.20 It's not the server but the customers who froze when pdf is too large 20:26.51 it is possible to generate ps file from redmon ? 20:27.09 yes but it will take just as long 20:28.20 set up your server as a print server and use a basic driver on the windows side 20:28.27 either PCL or PS 20:30.03 if you use PCL you will need to use ghostpcl 20:30.53 Chans: (ghostbot) in:#ghostscript 20:31.34 it will be faster to use a native driver and pretend your server is a standard print server from the client side 20:32.23 but will not print secure (The server is on internet) 20:32.44 oh, I don't know then. 20:34.55 I would look at CUPS details if the server is linux 20:35.09 they can probably help you more 20:36.37 customers are on windows so I would have to fight more with samba 20:36.54 no from the client perspective it would be a normal print server 20:38.15 no from the server 20:38.26 https://wiki.archlinux.org/index.php/CUPS_printer_sharing#Between_GNU.2FLinux_and_Windows 20:38.41 >>> ray_laptop has signed off IRC (Ping timeout: 272 seconds) [#ghostscript] 20:38.52 oh the server isn't linux then, well, get another server :) 20:39.12 no but I do not want to use cups 20:39.32 FORK(17529) --- fork starting for 'RSSFeeds', PID == 17529, bot_pid == 27362 --- 20:39.33 FORK(17529) !ERROR! cannot load my module: RSSFeeds 20:39.33 FORK(17529) fork: took 1s for RSSFeeds. 20:39.33 FORK(17529) --- fork finished for 'RSSFeeds' --- 20:39.42 no it's a linux server 20:41.18 but I think you involved my problem too :) 20:45.30 thank you for the help I would spend tomorrow thank you 20:46.30 Chans: (ghostbot) in:#ghostscript 20:50.03 >>> whoami_ has signed off IRC (Ping timeout: 250 seconds) [#ghostscript] 21:02.43 Chans: (ghostbot) in:#ghostscript 21:10.04 FORK(14553) --- fork starting for 'RSSFeeds', PID == 14553, bot_pid == 27362 --- 21:10.05 FORK(14553) !ERROR! cannot load my module: RSSFeeds 21:10.05 FORK(14553) fork: took 2s for RSSFeeds. 21:10.05 FORK(14553) --- fork finished for 'RSSFeeds' --- 21:16.53 --- Saved uptime records. 21:18.13 Seen: Flushed 2 entries. 21:18.13 Chans: (ghostbot) in:#ghostscript 21:30.21 >>> marcosw_ has signed off IRC (Quit: marcosw_) [#ghostscript] 21:30.35 >>> join/#ghostscript stars (~stars@27.34.252.234) 21:34.53 Chans: (ghostbot) in:#ghostscript 21:35.43 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 21:35.43 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 21:40.14 FORK(11169) --- fork starting for 'RSSFeeds', PID == 11169, bot_pid == 27362 --- 21:40.15 FORK(11169) !ERROR! cannot load my module: RSSFeeds 21:40.15 FORK(11169) fork: took 2s for RSSFeeds. 21:40.15 FORK(11169) --- fork finished for 'RSSFeeds' --- 21:46.03 ircCheck: possible lost in space; checking.Tue Oct 15 21:46:03 2013 21:46.03 >ghostbot< TEST 21:46.03 IRCTEST: Yes, we're alive. 21:51.33 Chans: (ghostbot) in:#ghostscript 21:58.58 >>> join/#ghostscript user123 (a5e4a1fc@gateway/web/freenode/ip.165.228.161.252) 22:00.55 >>> stars has signed off IRC (Ping timeout: 272 seconds) [#ghostscript] 22:07.23 Chans: (ghostbot) in:#ghostscript 22:10.09 Hi Guys, can anybody provide commercial licensing fees for Ghostscript and muPDF? 22:10.19 FORK(6984) --- fork starting for 'RSSFeeds', PID == 6984, bot_pid == 27362 --- 22:10.20 FORK(6984) !ERROR! cannot load my module: RSSFeeds 22:10.20 FORK(6984) fork: took 1s for RSSFeeds. 22:10.20 FORK(6984) --- fork finished for 'RSSFeeds' --- 22:17.03 --- Saved uptime records. 22:18.43 Seen: Flushed 1 entries. 22:23.43 Chans: (ghostbot) in:#ghostscript 22:31.11 user123: mail sales@artifex.com to enquire about licensing 22:31.46 >>> tor7 has signed off IRC (Remote host closed the connection) [#ghostscript] 22:31.58 Thanks tor7, i did. twice. no response. 22:32.55 >>> join/#ghostscript Fandekasp (~Fandekasp@27-32-19-26.static.tpgi.com.au) 22:39.33 Chans: (ghostbot) in:#ghostscript 22:40.34 FORK(2780) --- fork starting for 'RSSFeeds', PID == 2780, bot_pid == 27362 --- 22:40.35 FORK(2780) !ERROR! cannot load my module: RSSFeeds 22:40.35 FORK(2780) fork: took 2s for RSSFeeds. 22:40.35 FORK(2780) --- fork finished for 'RSSFeeds' --- 22:53.03 user123: Mail them again, and copy me (robin.watts@artifex.com) in and I'll make sure it gets through. 22:54.16 Thanks Robin. 22:56.33 Chans: (ghostbot) in:#ghostscript 23:03.14 >>> join/#ghostscript marcosw_ (~marcosw@c-98-207-131-178.hsd1.ca.comcast.net) 23:10.54 FORK(32005) --- fork starting for 'RSSFeeds', PID == 32005, bot_pid == 27362 --- 23:10.55 FORK(32005) !ERROR! cannot load my module: RSSFeeds 23:10.55 FORK(32005) fork: took 2s for RSSFeeds. 23:10.55 FORK(32005) --- fork finished for 'RSSFeeds' --- 23:12.03 Chans: (ghostbot) in:#ghostscript 23:12.19 user123: Scott just got the mail. 23:12.25 He should respond pretty quick. 23:13.00 He'll send you a huge list of questions, and just answer them as best you can - the more he understands what you want to do, the more he can tailor the quote to your needs. 23:14.15 Great. Thanks for your help. 23:14.25 no worries. 23:15.59 >>> marcosw_ has signed off IRC (Quit: marcosw_) [#ghostscript] 23:17.13 --- Saved uptime records. 23:18.32 >>> join/#ghostscript mvrhel_laptop (~chatzilla@c-50-159-85-185.hsd1.wa.comcast.net) 23:18.56 >>> join/#ghostscript ray_laptop (~chatzilla@rrcs-64-183-45-163.west.biz.rr.com) 23:19.16 Seen: Flushed 3 entries. 23:26.11 ray_laptop: Hey 23:26.37 I've run myself into a bit of a dead end here. 23:28.00 I'm having some rough output along the edges when going from eps -> pngalpha. I have set the text and graphic alpha bits to 4. Are there any other anti aliasing optimizations I can do? 23:28.10 Chans: (ghostbot) in:#ghostscript 23:29.00 SpNG: You're probably hitting the limits of what pngalpha can do. In particular stuff plotted through clip regions may not be antialiased well. 23:29.12 What res are you trying to get out? 23:29.19 300 x 300 23:29.50 Try: using -r900 -dDownScaleFactor=9 -o out.png -sDEVICE=png16m 23:29.55 Try: using -r900 -dDownScaleFactor=3 -o out.png -sDEVICE=png16m 23:29.57 sorry. 23:30.01 the latter one. 23:30.08 can I get transparency with that output? 23:30.46 gs -dEPSFitPage -g300x300 -dSAFER -dBATCH -dNOPAUSE -sDEVICE=pngalpha -dGraphicsAlphaBits=4 -dTextAlphaBits=4 -r600 -sOutputFile=out.png in.eps 23:30.57 that is the command I'm currently using. I will add the DownScaleFactor 23:31.03 and increase -r 23:31.18 never tried DownScaleFactor with pngalpha. Not sure. 23:31.21 Trying it now. 23:31.44 There is no point in using the AlphaBits with the downscaler. 23:32.12 >>> paulgardiner has signed off IRC (Quit: ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]) [#ghostscript] 23:32.34 ok, I don't think DownScaleFactor works with pngalpha 23:33.29 hmm yeah the results are not better 23:33.45 is my best option to output to a larger file then use another program to resize? 23:34.15 SpNg: Try it and see if it gives you the results you need. 23:34.51 Robin_Watts: I have tested it, and I can get good results, just one more moving piece. I was hoping to use GS to go from eps to raster each time 23:38.14 SpNg: Are you building your own gs ? 23:39.01 Robin_Watts: haha, no way. I just love GS. The more I learn about it, the more I want to use it. 23:39.10 I'm doing a bunch of work with EPS files 23:39.17 So you're not building it from source? 23:39.45 Robin_Watts: were you talking to me about your "dead end" (head or bottom) 23:39.59 Robin_Watts: yes I'm compiling from source 23:40.20 ray_laptop: Yeah. This postprocess thing had me worried. 23:40.31 I think I may see a way through now. 23:41.04 SpNg: if you are starting with eps, you may want to use -dEPSCrop or -dEPSFitPage 23:41.15 The problem is if devices start calling getbits rather than the prn_getbits entries, we might get strange results. 23:41.26 but I think that's a reasonable limitation. 23:41.31 SpNg: nm. I just saw you have that 23:41.35 ray_laptop: yeah I'm using that right now. 23:41.35 FORK(32541) --- fork starting for 'RSSFeeds', PID == 32541, bot_pid == 27362 --- 23:41.36 FORK(32541) !ERROR! cannot load my module: RSSFeeds 23:41.36 FORK(32541) fork: took 1s for RSSFeeds. 23:41.36 FORK(32541) --- fork finished for 'RSSFeeds' --- 23:42.29 ray_laptop: yeah, I'm just trying to increase the output quality on smaller png and jpg rasters from EPS. 23:42.51 any suggestions on resizing software? I have seen ImageMagic, netpbm and GraphicsMagic 23:43.31 Chans: (ghostbot) in:#ghostscript 23:43.43 SpNg: I'm just looking to see if I can find a quick solution to do it all in 1. 23:44.44 Robin_Watts: Thank you. I really appreciate the help! 23:45.10 SpNg: as Robin_Watts pointed out -dGraphicsAlphaBits=4 -dTextAlphaBits=4 are the best we can do. We only do box filter for those, however, not BiCubic 23:45.20 ray_laptop: I suspect mail going to sales@artifex.com is intermittently going wrong. 23:45.34 s/wrong/missing/ 23:45.49 the raster image postprocessing would allow you to use BiCubic or Gaussian or whatever 23:46.01 We've had 3 occasions of people coming on here saying that scott hasn't replied, and when I get the mail resent with me copied in, it gets through fine. 23:46.21 Robin_Watts: Maybe Scott gets so much spam that he ignores it 23:46.31 I'll ask him 23:46.31 He claims never to have seen them. 23:46.37 He might be contacting you :) 23:46.44 ray_laptop: ok good to know 23:47.39 Robin_Watts: don't hesitate to give out his direct email. Also, he gets support@artifex.com email now (AFAIK), so cc support on your response to a potential 23:48.40 Robin_Watts: what are your concerns with the post_process callout ? 23:49.44 ray_laptop: Leave it with me. I think I'm happier now. 23:50.00 If I'm still not happy by the time you arrive tomorrow, we'll discuss it then. 23:50.17 Robin_Watts: I gave the "destination" issue some thought and have sketched out a 'buffer manager' framework for the resutls 23:51.39 Robin_Watts: something we could use in an example implementation that lets us point out what would be needed (locking, etc) and would allow parallel PNG or JPEG or whatever 23:52.18 >>> mvrhel_laptop has signed off IRC (Ping timeout: 240 seconds) [#ghostscript] 23:52.24 Can't do parallel PNG or JPEG without blocking to ensure the processing is 'in order'. 23:52.26 by 'sketch', I mean a mental picture. Nothing on e-paper yet. 23:52.38 >>> join/#ghostscript marcosw_ (~marcosw@c-98-207-131-178.hsd1.ca.comcast.net) 23:53.01 Each band in a PNG would need to be compressed following on from the last one. Can't restart zlib. 23:53.25 Robin_Watts: OK. Well, maybe parallel TIFF (band == StripSize) 23:53.33 And unless we start using restart intervals in JPEG, it's a continuous bitstream too :( 23:55.01 cust 531 uses TIFF anyway, so it's a good "example" 23:55.28 gotta keep the whales happy ;-) 23:59.02 SpNg: This isn't working out trivially. Try me again in about 15 hours time. I must go to bed now :) 23:59.32 >>> marcosw_ has signed off IRC (Quit: marcosw_) [#ghostscript] 23:59.32 Chans: (ghostbot) in:#ghostscript