00:02.31 Opened logfile log/20130226. 00:02.28 I messed up ~1/2 of the cluster nodes, but they'll recover on their own in a couple of hours. 00:02.55 >>> marcosw has signed off IRC (Quit: marcosw) [#ghostscript] 00:04.05 Chans: (ghostbot) in:#ghostscript 00:10.38 >>> join/#ghostscript ray_laptop (~chatzilla@rrcs-64-183-45-163.west.biz.rr.com) 00:15.36 FORK(19944) --- fork starting for 'RSSFeeds', PID == 19944, bot_pid == 1005 --- 00:15.37 FORK(19944) !ERROR! cannot load my module: RSSFeeds 00:15.37 FORK(19944) fork: took 2s for RSSFeeds. 00:15.37 FORK(19944) --- fork finished for 'RSSFeeds' --- 00:19.37 Chans: (ghostbot) in:#ghostscript 00:26.08 >>> join/#ghostscript Fandekasp (~Fandekasp@p5172-ipngn100202yosemiya.okinawa.ocn.ne.jp) 00:35.09 Chans: (ghostbot) in:#ghostscript 00:46.10 FORK(19475) --- fork starting for 'RSSFeeds', PID == 19475, bot_pid == 1005 --- 00:46.11 FORK(19475) !ERROR! cannot load my module: RSSFeeds 00:46.11 FORK(19475) fork: took 2s for RSSFeeds. 00:46.11 FORK(19475) --- fork finished for 'RSSFeeds' --- 00:48.46 Seen: Flushed 1 entries. 00:51.11 Chans: (ghostbot) in:#ghostscript 00:52.02 --- Saved uptime records. 01:07.03 Chans: (ghostbot) in:#ghostscript 01:07.03 ircCheck: possible lost in space; checking.Tue Feb 26 01:07:03 2013 01:07.03 >ghostbot< TEST 01:07.04 IRCTEST: Yes, we're alive. 01:07.45 >>> ray_laptop has signed off IRC (Ping timeout: 248 seconds) [#ghostscript] 01:08.15 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 01:08.15 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 01:10.37 leak: 1 nuh{} items deleted; now have 28 01:16.16 FORK(11878) --- fork starting for 'RSSFeeds', PID == 11878, bot_pid == 1005 --- 01:16.17 FORK(11878) !ERROR! cannot load my module: RSSFeeds 01:16.17 FORK(11878) fork: took 2s for RSSFeeds. 01:16.17 FORK(11878) --- fork finished for 'RSSFeeds' --- 01:22.48 Chans: (ghostbot) in:#ghostscript 01:46.24 FORK(31995) LOG: last message repeated 3 times 01:46.24 FORK(31995) --- fork starting for 'RSSFeeds', PID == 31995, bot_pid == 1005 --- 01:46.25 FORK(31995) !ERROR! cannot load my module: RSSFeeds 01:46.25 FORK(31995) fork: took 2s for RSSFeeds. 01:46.25 FORK(31995) --- fork finished for 'RSSFeeds' --- 01:52.31 LOG: last message repeated 3 times 01:52.31 --- Saved uptime records. 01:55.58 Chans: (ghostbot) in:#ghostscript 02:07.18 ircCheck: possible lost in space; checking.Tue Feb 26 02:07:18 2013 02:07.18 >ghostbot< TEST 02:07.18 IRCTEST: Yes, we're alive. 02:12.27 Chans: (ghostbot) in:#ghostscript 02:17.00 FORK(1553) --- fork starting for 'RSSFeeds', PID == 1553, bot_pid == 1005 --- 02:17.01 FORK(1553) !ERROR! cannot load my module: RSSFeeds 02:17.01 FORK(1553) fork: took 2s for RSSFeeds. 02:17.01 FORK(1553) --- fork finished for 'RSSFeeds' --- 02:25.00 >>> join/#ghostscript marcosw (~marcosw@67.169.6.130) 02:27.19 >>> marcosw has signed off IRC (Client Quit) [#ghostscript] 02:27.59 Chans: (ghostbot) in:#ghostscript 02:47.18 FORK(12317) --- fork starting for 'RSSFeeds', PID == 12317, bot_pid == 1005 --- 02:47.19 FORK(12317) !ERROR! cannot load my module: RSSFeeds 02:47.19 FORK(12317) fork: took 1s for RSSFeeds. 02:47.19 FORK(12317) --- fork finished for 'RSSFeeds' --- 02:53.26 --- Saved uptime records. 02:59.54 Chans: (ghostbot) in:#ghostscript 03:10.54 ircCheck: possible lost in space; checking.Tue Feb 26 03:10:54 2013 03:10.54 >ghostbot< TEST 03:10.54 IRCTEST: Yes, we're alive. 03:16.46 Chans: (ghostbot) in:#ghostscript 03:17.42 FORK(16634) --- fork starting for 'RSSFeeds', PID == 16634, bot_pid == 1005 --- 03:17.43 FORK(16634) !ERROR! cannot load my module: RSSFeeds 03:17.43 FORK(16634) fork: took 1s for RSSFeeds. 03:17.43 FORK(16634) --- fork finished for 'RSSFeeds' --- 03:29.48 >>> join/#ghostscript tkamppeter_ (~till@p5DDBB210.dip.t-dialin.net) 03:32.28 Chans: (ghostbot) in:#ghostscript 03:33.48 >>> tkamppeter has signed off IRC (Ping timeout: 264 seconds) [#ghostscript] 03:47.50 FORK(1017) --- fork starting for 'RSSFeeds', PID == 1017, bot_pid == 1005 --- 03:47.51 FORK(1017) !ERROR! cannot load my module: RSSFeeds 03:47.51 FORK(1017) fork: took 1s for RSSFeeds. 03:47.51 FORK(1017) --- fork finished for 'RSSFeeds' --- 03:48.40 Chans: (ghostbot) in:#ghostscript 03:53.42 --- Saved uptime records. 04:04.52 Chans: (ghostbot) in:#ghostscript 04:10.46 >>> matteo has signed off IRC (Quit: No Ping reply in 90 seconds.) [#ghostscript] 04:11.32 >>> join/#ghostscript matteo (~matteo@openwrt/developer/matteo) 04:15.32 ircCheck: possible lost in space; checking.Tue Feb 26 04:15:32 2013 04:15.32 >ghostbot< TEST 04:15.32 IRCTEST: Yes, we're alive. 04:18.26 FORK(28122) --- fork starting for 'RSSFeeds', PID == 28122, bot_pid == 1005 --- 04:18.27 FORK(28122) !ERROR! cannot load my module: RSSFeeds 04:18.27 FORK(28122) fork: took 1s for RSSFeeds. 04:18.27 FORK(28122) --- fork finished for 'RSSFeeds' --- 04:20.52 Chans: (ghostbot) in:#ghostscript 04:48.44 FORK(32474) --- fork starting for 'RSSFeeds', PID == 32474, bot_pid == 1005 --- 04:48.45 FORK(32474) !ERROR! cannot load my module: RSSFeeds 04:48.45 FORK(32474) fork: took 1s for RSSFeeds. 04:48.45 FORK(32474) --- fork finished for 'RSSFeeds' --- 04:53.50 LOG: last message repeated 3 times 04:53.50 >>> join/#ghostscript marcosw (~marcosw@67.169.6.130) 04:53.50 --- Saved uptime records. 05:08.28 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 05:08.28 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 05:08.58 Chans: (ghostbot) in:#ghostscript 05:18.58 FORK(21364) --- fork starting for 'RSSFeeds', PID == 21364, bot_pid == 1005 --- 05:18.59 FORK(21364) !ERROR! cannot load my module: RSSFeeds 05:18.59 FORK(21364) fork: took 1s for RSSFeeds. 05:18.59 FORK(21364) --- fork finished for 'RSSFeeds' --- 05:19.58 ircCheck: possible lost in space; checking.Tue Feb 26 05:19:58 2013 05:19.58 >ghostbot< TEST 05:19.58 IRCTEST: Yes, we're alive. 05:25.28 Chans: (ghostbot) in:#ghostscript 05:34.19 >>> join/#ghostscript ray_laptop (~chatzilla@rrcs-64-183-45-163.west.biz.rr.com) 05:42.00 Chans: (ghostbot) in:#ghostscript 05:49.18 FORK(6060) --- fork starting for 'RSSFeeds', PID == 6060, bot_pid == 1005 --- 05:49.19 FORK(6060) !ERROR! cannot load my module: RSSFeeds 05:49.19 FORK(6060) fork: took 1s for RSSFeeds. 05:49.19 FORK(6060) --- fork finished for 'RSSFeeds' --- 05:54.16 --- Saved uptime records. 05:57.42 Chans: (ghostbot) in:#ghostscript 06:06.12 >>> marcosw has signed off IRC (Quit: marcosw) [#ghostscript] 06:10.28 >>> ray_laptop has signed off IRC (Ping timeout: 248 seconds) [#ghostscript] 06:14.04 Chans: (ghostbot) in:#ghostscript 06:19.32 FORK(12862) --- fork starting for 'RSSFeeds', PID == 12862, bot_pid == 1005 --- 06:19.33 FORK(12862) !ERROR! cannot load my module: RSSFeeds 06:19.33 FORK(12862) fork: took 1s for RSSFeeds. 06:19.33 FORK(12862) --- fork finished for 'RSSFeeds' --- 06:24.44 ircCheck: possible lost in space; checking.Tue Feb 26 06:24:44 2013 06:24.44 >ghostbot< TEST 06:24.44 IRCTEST: Yes, we're alive. 06:30.24 Chans: (ghostbot) in:#ghostscript 06:49.48 FORK(9561) --- fork starting for 'RSSFeeds', PID == 9561, bot_pid == 1005 --- 06:49.49 FORK(9561) !ERROR! cannot load my module: RSSFeeds 06:49.49 FORK(9561) fork: took 1s for RSSFeeds. 06:49.49 FORK(9561) --- fork finished for 'RSSFeeds' --- 06:54.30 --- Saved uptime records. 07:02.58 Chans: (ghostbot) in:#ghostscript 07:04.27 >>> join/#ghostscript setmeaway (oosool3@118.45.149.65) 07:18.20 Chans: (ghostbot) in:#ghostscript 07:19.56 FORK(6690) --- fork starting for 'RSSFeeds', PID == 6690, bot_pid == 1005 --- 07:19.57 FORK(6690) !ERROR! cannot load my module: RSSFeeds 07:19.57 FORK(6690) fork: took 1s for RSSFeeds. 07:19.57 FORK(6690) --- fork finished for 'RSSFeeds' --- 07:29.00 ircCheck: possible lost in space; checking.Tue Feb 26 07:29:00 2013 07:29.00 >ghostbot< TEST 07:29.00 IRCTEST: Yes, we're alive. 07:32.12 >>> chrisl_away materializes into chrisl 07:34.10 Chans: (ghostbot) in:#ghostscript 07:39.17 >>> felipe has signed off IRC (*.net *.split) [#ghostscript] 07:39.17 >>> henrys has signed off IRC (*.net *.split) [#ghostscript] 07:39.17 >>> matteo has signed off IRC (*.net *.split) [#ghostscript] 07:39.17 >>> tkamppeter_ has signed off IRC (*.net *.split) [#ghostscript] 07:39.17 >>> deleet has signed off IRC (*.net *.split) [#ghostscript] 07:39.19 >>> xymox has signed off IRC (*.net *.split) [#ghostscript] 07:39.19 >>> Fandekasp has signed off IRC (*.net *.split) [#ghostscript] 07:39.19 >>> mvrhel_laptop has signed off IRC (*.net *.split) [#ghostscript] 07:41.46 >>> chrisl has signed off IRC (*.net *.split) [#ghostscript] 07:41.46 >>> saper has signed off IRC (*.net *.split) [#ghostscript] 07:41.46 >>> claudiu____ has signed off IRC (*.net *.split) [#ghostscript] 07:41.46 >>> Gigs- has signed off IRC (*.net *.split) [#ghostscript] 07:41.46 >>> Robin_Watts has signed off IRC (*.net *.split) [#ghostscript] 07:41.46 >>> sivoais has signed off IRC (*.net *.split) [#ghostscript] 07:41.46 >>> wordToDaBird has signed off IRC (*.net *.split) [#ghostscript] 07:41.46 >>> setmeaway has signed off IRC (*.net *.split) [#ghostscript] 07:41.46 >>> Gigs has signed off IRC (*.net *.split) [#ghostscript] 07:41.46 >>> xreal has signed off IRC (*.net *.split) [#ghostscript] 07:41.46 >>> alexcher has signed off IRC (*.net *.split) [#ghostscript] 07:41.46 >>> plinnell has signed off IRC (*.net *.split) [#ghostscript] 07:41.46 >>> sh4rm4 has signed off IRC (*.net *.split) [#ghostscript] 07:41.46 >>> UukGoblin has signed off IRC (*.net *.split) [#ghostscript] 07:41.46 >>> madmoose has signed off IRC (*.net *.split) [#ghostscript] 07:41.46 >>> JakeSays has signed off IRC (*.net *.split) [#ghostscript] 07:41.46 >>> ray_work has signed off IRC (*.net *.split) [#ghostscript] 07:41.46 >>> mace has signed off IRC (*.net *.split) [#ghostscript] 07:41.46 >>> jghali has signed off IRC (*.net *.split) [#ghostscript] 07:41.46 >>> sebras has signed off IRC (Ping timeout: 256 seconds) [#ghostscript] 07:50.14 Chans: (ghostbot) in:#ghostscript 07:50.50 FORK(1467) --- fork starting for 'RSSFeeds', PID == 1467, bot_pid == 1005 --- 07:50.51 FORK(1467) !ERROR! cannot load my module: RSSFeeds 07:50.51 FORK(1467) fork: took 1s for RSSFeeds. 07:50.51 FORK(1467) --- fork finished for 'RSSFeeds' --- 07:51.17 >>> join/#ghostscript kens (~Miranda@232.94.125.91.dyn.plus.net) 07:51.17 >>> join/#ghostscript sebras (~sebras@casper3.ghostscript.com) 07:51.17 >>> join/#ghostscript setmeaway (oosool3@118.45.149.65) 07:51.17 >>> join/#ghostscript matteo (~matteo@openwrt/developer/matteo) 07:51.17 >>> join/#ghostscript tkamppeter_ (~till@p5DDBB210.dip.t-dialin.net) 07:51.17 >>> join/#ghostscript Fandekasp (~Fandekasp@p5172-ipngn100202yosemiya.okinawa.ocn.ne.jp) 07:51.17 >>> join/#ghostscript plinnell (~mrdocs@opensuse/member/mrdocs) 07:51.17 >>> join/#ghostscript mvrhel_laptop (~chatzilla@c-24-17-196-27.hsd1.wa.comcast.net) 07:51.17 >>> join/#ghostscript Robin_Watts (~chatzilla@91.85.37.231) 07:51.17 >>> join/#ghostscript sh4rm4 (~sh4rm@gateway/tor-sasl/sh4rm4) 07:51.17 >>> join/#ghostscript henrys (~henrys@c-50-134-235-109.hsd1.co.comcast.net) 07:51.17 >>> join/#ghostscript xreal (~andreas.n@unaffiliated/xreal) 07:51.17 >>> join/#ghostscript jghali (~jghali@ADijon-157-1-106-124.w90-56.abo.wanadoo.fr) 07:51.17 >>> join/#ghostscript claudiu____ (uid2488@gateway/web/irccloud.com/x-geyqjozuacuhdniu) 07:51.17 >>> join/#ghostscript ray_work (~ray_dual@rrcs-64-183-45-162.west.biz.rr.com) 07:51.18 >>> join/#ghostscript chrisl (~chrisl@cpc1-ando5-2-0-cust33.15-1.cable.virginmedia.com) 07:51.18 >>> join/#ghostscript wordToDaBird (~bobliving@pool-173-63-22-181.nwrknj.fios.verizon.net) 07:51.18 >>> join/#ghostscript saper (saper@wikipedia/saper) 07:51.18 >>> join/#ghostscript xymox (~xymox@unaffiliated/contempt) 07:51.18 >>> join/#ghostscript sivoais (~zaki@unaffiliated/sivoais) 07:51.18 >>> join/#ghostscript alexcher (~alexcher@pool-173-49-254-118.phlapa.fios.verizon.net) 07:51.18 >>> join/#ghostscript Gigs (~Gigs@pdpc/supporter/28for7/gigs) 07:51.18 >>> join/#ghostscript madmoose (~Hat@chef.nerp.net) 07:51.18 >>> join/#ghostscript mace (~mace@debian/developer/mace) 07:51.18 >>> join/#ghostscript JakeSays (~quassel@71.195.236.35) 07:51.18 >>> join/#ghostscript felipe (~felipe@unaffiliated/felipe) 07:51.18 >>> join/#ghostscript Gigs- (~Gigs@pdpc/supporter/28for7/gigs) 07:51.18 >>> join/#ghostscript deleet (~deleet@chronos.andreferreira.com) 07:51.18 >>> join/#ghostscript UukGoblin (~jaa@unaffiliated/uukgoblin) 07:53.26 >>> join/#ghostscript tor8 (~tor@c-f77c71d5.04-50-6c756e10.cust.bredbandsbolaget.se) 07:54.46 --- Saved uptime records. 08:00.26 >>> mvrhel_laptop has signed off IRC (Ping timeout: 240 seconds) [#ghostscript] 08:02.20 >>> tkamppeter_ materializes into tkamppeter 08:06.06 Chans: (ghostbot) in:#ghostscript 08:21.08 FORK(30029) --- fork starting for 'RSSFeeds', PID == 30029, bot_pid == 1005 --- 08:21.09 FORK(30029) !ERROR! cannot load my module: RSSFeeds 08:21.09 FORK(30029) fork: took 1s for RSSFeeds. 08:21.09 FORK(30029) --- fork finished for 'RSSFeeds' --- 08:32.58 ircCheck: possible lost in space; checking.Tue Feb 26 08:32:58 2013 08:32.58 >ghostbot< TEST 08:32.58 IRCTEST: Yes, we're alive. 08:38.02 Chans: (ghostbot) in:#ghostscript 08:51.28 FORK(30682) --- fork starting for 'RSSFeeds', PID == 30682, bot_pid == 1005 --- 08:51.29 FORK(30682) !ERROR! cannot load my module: RSSFeeds 08:51.29 FORK(30682) fork: took 1s for RSSFeeds. 08:51.29 FORK(30682) --- fork finished for 'RSSFeeds' --- 08:54.15 LOG: last message repeated 3 times 08:54.15 >>> part/#ghostscript matteo (~matteo@openwrt/developer/matteo) 08:55.36 --- Saved uptime records. 09:08.30 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 09:08.30 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 09:09.46 Chans: (ghostbot) in:#ghostscript 09:11.16 leak: 1 nuh{} items deleted; now have 29 09:22.16 FORK(3640) --- fork starting for 'RSSFeeds', PID == 3640, bot_pid == 1005 --- 09:22.17 FORK(3640) !ERROR! cannot load my module: RSSFeeds 09:22.17 FORK(3640) fork: took 1s for RSSFeeds. 09:22.17 FORK(3640) --- fork finished for 'RSSFeeds' --- 09:25.28 Chans: (ghostbot) in:#ghostscript 09:36.22 ircCheck: possible lost in space; checking.Tue Feb 26 09:36:22 2013 09:36.22 >ghostbot< TEST 09:36.22 IRCTEST: Yes, we're alive. 09:37.17 >>> join/#ghostscript femfum (5532182d@gateway/web/freenode/ip.85.50.24.45) 09:41.40 Chans: (ghostbot) in:#ghostscript 09:46.03 >>> kens has signed off IRC (Read error: Connection reset by peer) [#ghostscript] 09:49.31 >>> join/#ghostscript kens (~Miranda@232.94.125.91.dyn.plus.net) 09:53.06 >>> join/#ghostscript paulgardiner (~chatzilla@smtp.glidos.net) 09:53.06 FORK(2532) --- fork starting for 'RSSFeeds', PID == 2532, bot_pid == 1005 --- 09:53.07 FORK(2532) !ERROR! cannot load my module: RSSFeeds 09:53.07 FORK(2532) fork: took 1s for RSSFeeds. 09:53.07 FORK(2532) --- fork finished for 'RSSFeeds' --- 09:55.46 --- Saved uptime records. 09:57.52 Chans: (ghostbot) in:#ghostscript 09:59.35 >>> join/#ghostscript glaucous (~quassel@h-186-180.a189.priv.bahnhof.se) 10:00.41 >>> part/#ghostscript glaucous (~quassel@h-186-180.a189.priv.bahnhof.se) 10:03.56 >>> Fandekasp has signed off IRC (Ping timeout: 240 seconds) [#ghostscript] 10:13.54 Chans: (ghostbot) in:#ghostscript 10:23.58 FORK(2837) --- fork starting for 'RSSFeeds', PID == 2837, bot_pid == 1005 --- 10:23.59 FORK(2837) !ERROR! cannot load my module: RSSFeeds 10:23.59 FORK(2837) fork: took 1s for RSSFeeds. 10:23.59 FORK(2837) --- fork finished for 'RSSFeeds' --- 10:40.36 ircCheck: possible lost in space; checking.Tue Feb 26 10:40:36 2013 10:40.36 >ghostbot< TEST 10:40.36 IRCTEST: Yes, we're alive. 10:42.43 >>> join/#ghostscript Fandekasp (~Fandekasp@platinum-static25142.nirai.ne.jp) 10:43.44 >>> join/#ghostscript Srini (~Srinivasa@202.153.39.66) 10:43.49 Hi all here 10:45.17 I am trying to extract fonts from a pdf file... pdfinfo shows the fonts tobe cid identity-h fonts... extractFonts.ps failed to extract the fonts... trying to build mupdf on ubuntu... it is not compiling and installing pdfextract ... can anyone help me out please! 10:45.37 Chans: (ghostbot) in:#ghostscript 10:45.44 Is there a sure way of extracting fonts from pdf? 10:46.49 Srini: bulding from source or from a package manager? 10:52.10 Seen: Flushed 2 entries. 10:53.50 Robin_Watts, I build mupdf from sources 10:53.55 git ghostscript 10:54.05 FORK(30118) --- fork starting for 'RSSFeeds', PID == 30118, bot_pid == 1005 --- 10:54.06 FORK(30118) !ERROR! cannot load my module: RSSFeeds 10:54.06 FORK(30118) fork: took 1s for RSSFeeds. 10:54.06 FORK(30118) --- fork finished for 'RSSFeeds' --- 10:54.09 it did not build pdfextract 10:54.18 is there a patch? 10:54.49 make all ? 10:54.50 I tried apt-get install mupdf-tools, even then it id not install the pdfextract :( 10:55.04 Robin_Watts, yes make all 10:55.06 OH, well, now you get mutool, right? 10:55.23 "mutool extract" is the new equivalent to pdfextract 10:55.47 Robin_Watts, it did not create a mutool also! 10:55.57 --- Saved uptime records. 10:56.02 Did you "make all" ? 10:56.16 Yes I did! 10:56.30 Hi, someone could advise me on how to share PostScript code, via web place (like GitHub or PasteBin), with code-highlighting? (usually we work with VIM editor and TOhtml method) …thanks! 10:57.37 make all should have left mutool in build/debug 10:58.00 Robin_Watts, you are right it is! 10:58.11 so maybe you want make all build=release 10:59.40 Robin_Watts, and make install followed by that? 10:59.45 >>> Fandekasp has signed off IRC (Ping timeout: 248 seconds) [#ghostscript] 10:59.55 make install build=release 11:01.10 Robin_Watts, That was help! 11:01.16 Thanks! 11:01.20 np 11:01.40 Chans: (ghostbot) in:#ghostscript 11:05.53 Robin_Watts, gs can convert pdf to html? 11:06.34 Sorry if I am singling out you Robin_Watts ! 11:07.07 Srini: gs cannot convert pdf to html, no 11:07.27 chrisl, Thanks! 11:07.33 np 11:09.25 Time for us to sue LG? 11:09.31 http://www.theregister.co.uk/2013/02/25/lg_acquires_webos/ 11:11.14 I wonder why they would want it...... 11:11.31 For Smart TVs 11:11.56 Yeh, but why start with WebOS 11:14.09 Srini: No, but mupdf can, in some sort of way. 11:14.21 mudraw -tt in.pdf > out.html 11:16.33 sorry if my question about PS syntax-highlighting seems to have no sense, but the main web sites to share code, don't have the PostScript language available 11:17.45 Robin_Watts, Formatting like bold italic subscript superscript is not possible that way? it is plan text? 11:17.47 femfum: I don't know any pastebin type site with PS syntax highlighting - if you find one, let us know! 11:18.07 Chans: (ghostbot) in:#ghostscript 11:18.51 * chrisl/#ghostscript has to head out for a while..... 11:18.55 >>> chrisl materializes into chrisl_away 11:20.08 chris1_away: yes, of course …we ask why :-) 11:21.37 Srini: Information is put into the css. 11:22.17 femfum: Cos in order to syntax highlight you have to have some structure, and ps is practically structure free. 11:24.01 Robin_Watts, Yes! 11:24.04 Thanks! 11:24.14 FORK(12070) --- fork starting for 'RSSFeeds', PID == 12070, bot_pid == 1005 --- 11:24.15 FORK(12070) !ERROR! cannot load my module: RSSFeeds 11:24.15 FORK(12070) fork: took 1s for RSSFeeds. 11:24.15 FORK(12070) --- fork finished for 'RSSFeeds' --- 11:24.15 you're welcome. 11:29.00 Robin_Watts: I agree, but, for example, visually is better to follow a large program with the VIM PS syntax on enabled 11:34.08 Chans: (ghostbot) in:#ghostscript 11:52.16 Seen: Flushed 4 entries. 11:54.32 FORK(24697) --- fork starting for 'RSSFeeds', PID == 24697, bot_pid == 1005 --- 11:54.33 FORK(24697) !ERROR! cannot load my module: RSSFeeds 11:54.33 FORK(24697) fork: took 1s for RSSFeeds. 11:54.33 FORK(24697) --- fork finished for 'RSSFeeds' --- 11:56.28 --- Saved uptime records. 12:06.22 Chans: (ghostbot) in:#ghostscript 12:14.46 Robin_Watts: hm, I wonder why "mutool" has pulled in all the cmap and font resources... 12:23.10 Chans: (ghostbot) in:#ghostscript 12:25.06 FORK(9791) --- fork starting for 'RSSFeeds', PID == 9791, bot_pid == 1005 --- 12:25.07 FORK(9791) !ERROR! cannot load my module: RSSFeeds 12:25.07 FORK(9791) fork: took 1s for RSSFeeds. 12:25.07 FORK(9791) --- fork finished for 'RSSFeeds' --- 12:31.20 right, somewhere in the 'forms' branch merge back in september... 12:38.42 Chans: (ghostbot) in:#ghostscript 12:51.43 >>> femfum has signed off IRC (Ping timeout: 245 seconds) [#ghostscript] 12:52.48 Seen: Flushed 1 entries. 12:54.44 Chans: (ghostbot) in:#ghostscript 12:55.14 FORK(20939) --- fork starting for 'RSSFeeds', PID == 20939, bot_pid == 1005 --- 12:55.15 FORK(20939) !ERROR! cannot load my module: RSSFeeds 12:55.15 FORK(20939) fork: took 1s for RSSFeeds. 12:55.15 FORK(20939) --- fork finished for 'RSSFeeds' --- 12:57.00 --- Saved uptime records. 13:02.59 Robin_Watts, tor8: a few commits on paulg/master, if you have a moment 13:04.31 paulgardiner: can I pick your brain about some pdf_forms things? 13:04.40 sure 13:04.50 pdf_form.c has a function measure_text which calls pdf_run_glyph 13:05.25 doing that pulls in the interpreter when linking, and the interpreter pulls in the big font data blobs 13:05.43 now, I have no problem with forms requiring the interpreter 13:06.05 but I need to understand why mutool.c pulls in pdf_form.c 13:06.47 (as a bit of history, we have pdf_new_document_no_run just to let mutool tools that don't need the interpreter avoid pulling in the huge data blobs) 13:07.42 what if you remove pdf_form.c from the build? Do the unresolved functions point at any reason? 13:08.24 tor8: update doc/example.c with regards to -lpng. I might do it, but it will take some time... 13:08.40 paulgardiner: /facepalm should've tried that! 13:08.40 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 13:08.40 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 13:08.55 sebras: I'm just curious why you put it there. I can take it out easily enough. 13:09.02 we've *never* ever used libpng in mupdf 13:09.21 paulgardiner: so, fz_free_widget and pdf_update_appearance 13:09.49 tor8: I think this was before the git submodule things... 13:10.16 Chans: (ghostbot) in:#ghostscript 13:10.19 sebras: we've still never used libpng... 13:10.22 tor8: Ah. Possibly pdf_update_appearance should be in pdf_annot.c 13:10.40 ... but I'm unsure what else it would drag in. 13:11.29 fz_free_widget should be in doc_interactive.c shouldn't it? 13:11.32 Hmmm. Come to think of it pdf_update_appearance does need to measure test 13:11.42 leak: 1 nuh{} items deleted; now have 30 13:11.57 tor8: Yes, I'd have thought so 13:12.28 tor8: d'oh! you're right of course! *puts head in a brown paper bag* 13:12.32 paulgardiner: update_annot is a bigger headache 13:13.17 paulgardiner: since I think load_page may be called by some tools without wanting to actually run the page contents 13:14.55 paulgardiner: hm. it may help looking at the current stuff instead of the merge that introduced pulling in the data blobs... 13:15.43 so doc_interactive needs a lot of pdf functions from pdf_forms, but that's probably okay (though the dependency going that way is a bit...odd) 13:15.59 there's still update_appearance and pdf_field_type being called in pdf_annot.c 13:16.51 but now there's more than just measuring text that pulls in the interpreter 13:17.46 I'm pretty sure pdf_field_type could move to pdf_annot.c (or a separate file) without dragging too much with it. 13:18.29 With update_appearance, I'm unsure as to why I arranged for it to be called on loading the annotations. 13:19.50 paulgardiner: I've been trying to keep the mupdf code in "layers" where the bottom layer that deals with objects, streams, filters and the xref etc doesn't depend on the content stream interpreter or device interface 13:19.57 of course, it's not always easy! 13:20.08 not when pdf_xref is the dumping ground for all manners of caches etc 13:20.19 so maybe we should just give up that thought and not worry too much 13:20.52 still, if it can be arranged to not have hard linked dependencies, I consider it a big win in terms of code separation and clarity 13:21.22 and if that requires hacks like filling in function pointers to avoid hard linking, then that's a clear reminder of where the abstraction falls down 13:25.03 We have this strange split between fz_annot and fz_widget, which are under-the-hood the same thing, but obtained in different ways. 13:25.24 FORK(5538) --- fork starting for 'RSSFeeds', PID == 5538, bot_pid == 1005 --- 13:25.25 FORK(5538) !ERROR! cannot load my module: RSSFeeds 13:25.25 FORK(5538) fork: took 1s for RSSFeeds. 13:25.25 FORK(5538) --- fork finished for 'RSSFeeds' --- 13:25.33 paulgardiner: there's also the question whether it's worth keeping them in the fz namespace 13:25.53 nothing but pdf will be using annots and widgets, as far as I can tell 13:26.03 Chans: (ghostbot) in:#ghostscript 13:26.26 That was the abstraction that fz_interactive was supposed to help with. 13:26.58 yes, but re-evaluating decisions occasionally is not to be frowned on :) 13:27.18 if it's working out, then great! if it's just making your work more troublesome, ... 13:27.20 I totally agree. 13:28.04 there's now a set of annotation types in fitz.h which probably only makes sense for PDF 13:28.46 the fitz doc_interactive.c forwarding layer is simple enough I guess that it doesn't pose a big headache 13:29.04 but API decisions like that makes one wonder where the abstraction starts leaking too much 13:30.13 Yes, I see what you mean about the annotation types 13:31.26 I'd imagined the abstraction left open the possibility to deal with another file type one day that had some of the interactive features of pdf, but as you say having types that are pdf specific blows that away 13:31.46 yup. that's what I meant. 13:32.34 Also, at the time, the only other option seemed to be to add lots of new indirected doc functions, but I guess just testing if a doc is a pdf and then casting is an alterntive. 13:33.16 yeah. maybe a pdf_document *pdf_cast_document(fz_document *doc) and that returns NULL if it's not a PDF 13:33.24 Ah yes 13:33.55 Do we not have a meta function? 13:34.10 Robin_Watts: I hate the meta function... 13:34.22 Even if we do, pdf_cast_document is nice 13:34.37 but yes, the meta function should be able to return the document type 13:34.47 Then drop all the fz_interactive stuff 13:35.03 We use the meta function to find out if it's a pdf document, and if so, we can cast. 13:35.11 and we can implement pdf_cast_document using that. 13:35.24 I don't think any of this will help unlink update_appearance... other than perhaps make the code look simpler so we can understand what's going on better 13:35.29 so the users get a nice function, and we don't bloat the document interface. 13:35.45 making the code simpler is worthwhile in any case! 13:35.53 Robin_Watts: yeah. sounds good 13:35.59 tor8: yes 13:37.40 I could make that change when I've finished sorting out why I'm getting opaque highlights. 13:38.01 paulgardiner: removing both doc_interactive and pdf_form we get link erros from pdf_load_annots and pdf_update_annot to update_appearance and field_type 13:38.48 paulgardiner: maybe we can split pdf_annot.c into non-interactive and interactive halves 13:39.17 and your mixing of widget and annot when they're both the same pdf structures under the hood, I'll leave that choice up to you 13:39.21 The problem is avoinding updating appearance streams on the load call 13:39.57 >>> join/#ghostscript femfum (553dff6a@gateway/web/freenode/ip.85.61.255.106) 13:40.29 paulgardiner: that's where we synthesize appearance streams if they're missing? 13:41.10 Yes, and update ones that have been left dirty by their values being altered without their appearance streams 13:42.02 In the absence of forms, the only time we need to update annots are when they haven't had appearance streams to start with, yes? 13:42.11 Hmmm and somewhere we deal with the possible change due to the mouse being down over a widget 13:42.21 right. that makes sense to do when loading an annot. so we should probably not load annots in mutool tools. 13:42.31 Chans: (ghostbot) in:#ghostscript 13:42.40 Robin_Watts: well, we were getting away without doing that at all before form support was added. 13:42.53 ... but maybe it is desireable in any case 13:42.59 What tor8 says is simpler, I think. 13:43.13 If we can avoid loading annots in mutool tools, we should be OK. 13:43.52 With an ifdef? 13:44.22 No, we shuffle all the load_annots stuff into a different partitioning of the files. 13:44.25 paulgardiner: by not calling pdf_page 13:44.41 and by shuffling functions around in files 13:45.27 Ah right.... ish 13:45.58 not calling pdf_page? Not getting that bit 13:50.15 paulgardiner: nvm, it doesn't matter 13:50.24 I've nailed the two functions that pull in the interpreter in pdf_form.c 13:50.38 paulgardiner: (I meant pdf_load_page) 13:50.57 right 13:51.04 pdf_measure_text, pdf_text_stride and pdf_load_font/drop_font are the entry points we need to isolate 13:51.53 and they're all used by update_text_appearance, called by pdf_update_appearance 13:51.57 so we're out of luck there! 13:52.22 Yep. It's definitely update_appearance that is the problem 13:52.32 To return to what I was saying before... 13:52.55 If update_appearance is only really needed if we have forms... 13:53.05 Seen: Flushed 4 entries. 13:53.12 and forms is only really needed if we are running the interpreter... 13:53.52 Really in update_appearance we should fill in all missing annoations. 13:54.12 then can we isolate update_appearance via a function pointer that is set/not set in pdf_open_document/pdf_open_document_no_run 13:55.32 FORK(28021) --- fork starting for 'RSSFeeds', PID == 28021, bot_pid == 1005 --- 13:55.33 FORK(28021) !ERROR! cannot load my module: RSSFeeds 13:55.33 FORK(28021) fork: took 1s for RSSFeeds. 13:55.33 FORK(28021) --- fork finished for 'RSSFeeds' --- 13:57.08 The need to generate appearance streams isn't forms specific, but still perhaps if you don't intend to run them, there is no point to generating them 13:57.18 --- Saved uptime records. 13:57.44 Seems fair to me. 13:58.12 Chans: (ghostbot) in:#ghostscript 13:59.16 Alternatively there may be a simple way to avoid calling update_appearance from load_annots, and instead ensuring that it is called before running them 13:59.50 A 'needs_update' flag stored somewhere? 14:00.45 The need updating in two cases: they don't exist or the widget object has a Dirty flag set 14:01.23 both of which you can spot when running them? So no flag may be required? 14:01.55 Yes. The problem though, is there may be code that assumes they exist and will fall over if they don't 14:02.16 though such code would be better fixed 14:02.32 right, but we could implement an 'ensure_updated' call, and insert that in various places ? 14:02.56 update_appearance is a ensure call 14:03.15 It does nothing unless one of those two conditions hold 14:03.33 ok, so basically it's a matter of moving the pdf_update_appearance call from load_annots to 'just in time' before stuff is used. 14:04.01 I'd like to think so. :-) 14:05.00 Perhaps just move it to pdf_run_annot. 14:05.09 now is when you want a wall-sized printout of a graph of all object and function dependencies 14:08.09 I'd have thought moving it from load to run had some chance of solving the link problem. 14:08.33 Other than pdf_widget_type 14:12.24 >>> chrisl_away materializes into chrisl 14:13.02 There's some chance it would mess up partial update because that keys on changes to the appearance streams. 14:13.03 paulgardiner: okay, I think splitting pdf_annot.c into interactive/non-interactive functions and moving the update_appearance to running time should solve the dependency 14:13.21 there's a lot of dependencies on pdf_annot.c from various files 14:13.29 pdf_xref has the annot enumerator 14:13.51 but if we ditch the fz_interactive, I think that enumerator can be move away from the function pointer table in pdf_xref 14:13.51 Chans: (ghostbot) in:#ghostscript 14:15.26 I think we can do both those things independently. 14:15.48 It's actually fz_interactive that kept the widget enumerator out of the xref 14:16.50 Does this need doing for the release? 14:19.27 it would be good if we could (since it blows up mutool from 1.2M to 8.1M, but I won't force the issue 14:20.16 The blowing up of mutool can be solved without removing fz_interactive fz_annot fz_widget etc. 14:21.43 >>> femfum has signed off IRC (Ping timeout: 245 seconds) [#ghostscript] 14:22.31 I could have a go at moving pdf_widget_type into pdf_annot.c and calling update_appearance from run rather than load... oh hang on... we'd then need run_annot to be moved out of pdf_annot.c 14:25.34 FORK(17010) --- fork starting for 'RSSFeeds', PID == 17010, bot_pid == 1005 --- 14:25.35 FORK(17010) !ERROR! cannot load my module: RSSFeeds 14:25.35 FORK(17010) fork: took 1s for RSSFeeds. 14:25.35 FORK(17010) --- fork finished for 'RSSFeeds' --- 14:25.37 I could also have a go at getting rid of fz_interactive et al, of course. 14:28.46 But it would be really nice to get my current commits in before the latter. :-) 14:30.26 Chans: (ghostbot) in:#ghostscript 14:31.50 paulgardiner: yes. I've looked through the non-android ones and they look fine (given the subsequent rejigging of interactive and annot/widget back into mupdf.h we've been talking about) 14:32.26 question is what to do about the release, do it now with the bloated mutool exe or wait? 14:34.56 The changes just for avoiding the bloat might be few, although it looks like we do need to split pdf_annot.c, but between run and load, rather than interactive and noninteractive. 14:36.48 We have a meeting later. henrys is good at making decisions. 14:39.13 paulgardiner: run would be part of interactive 14:39.25 *could 14:39.27 oh ok. that makes sense 14:40.05 which leaves very little non-interactive. feel free to come up with some other organisation between annot.c and form.c if you wish. 14:42.45 releasing soon is priority, if there were something very important to put in then we can delay more - but we commit to a February release and there are 2 days left. Just enough for the rc to fail and be fixed ;-) 14:43.08 I have the opaque, text-highlight-markup problem fixed now. I guess I could have a go at this. It should be fairly quick provided it doesn't break partial update in some mysterious way. 14:43.43 I am a little worried about breaking partial update. 14:45.15 But I could try and if partial update is broken then let the release go without it. 14:45.30 without the changes I mean 14:46.40 Chans: (ghostbot) in:#ghostscript 14:53.16 Seen: Flushed 4 entries. 14:53.58 >>> join/#ghostscript femfum (553dff6a@gateway/web/freenode/ip.85.61.255.106) 14:56.12 FORK(30618) --- fork starting for 'RSSFeeds', PID == 30618, bot_pid == 1005 --- 14:56.13 FORK(30618) !ERROR! cannot load my module: RSSFeeds 14:56.13 FORK(30618) fork: took 1s for RSSFeeds. 14:56.13 FORK(30618) --- fork finished for 'RSSFeeds' --- 14:57.48 --- Saved uptime records. 15:01.14 paulgardiner: fair enough. 15:02.32 unless we think a coupke of days freeze on other than bug fixes is safer 15:02.52 release now. 15:02.56 fix later. 15:03.06 Chans: (ghostbot) in:#ghostscript 15:05.33 Robin_Watts: tor8's checked my non-android commits (other than the one tiny one I just pushed). Be handy if you could give the android ones a check over. 15:07.07 looking now. 15:07.29 ta muchly 15:09.45 >>> join/#ghostscript mvrhel_laptop (~chatzilla@c-24-17-196-27.hsd1.wa.comcast.net) 15:09.59 How come ReaderView needs docHeight, but not docWidth ? 15:10.26 I don't know. Eclipse told be it wasn't used. 15:11.10 indeed, it seems not to be. 15:18.25 pdf_delete_annot... 15:18.45 if you pass in an annot that's not in the page, you'll get bad results. 15:18.56 and it'll crash if you pass annot == NULL 15:20.18 Chans: (ghostbot) in:#ghostscript 15:20.47 Yeah, it would be safer to just return. I'll update that once you've done. 15:22.41 Suppose I delete an annotation, so it moves onto the deleted list. Then I do an update, so it moves onto the tmp list. Then I delete another annotation, and do another update. Won't the first tmp list get lost ? 15:23.01 I see the problem with NULL. Would one not in the list be a problem? other than its being strange not to be there. 15:23.21 It's a sign that someone might be passing in an annot from the wrong page. 15:23.33 Good point. 15:23.55 If you try to delete an annotation from the wrong page, nothing should happen. 15:24.16 I'd vaguely prefer "death_row" to "tmp_annots" :) 15:24.18 delete;update;deleteupdate is ok I think 15:24.26 how so? 15:24.34 page->tmp_annots = page->deleted_annots 15:25.18 delete A makes deleted_annots = A, A->next = NULL; 15:25.32 update makes tmp_annots = A, delete_annots = NULL 15:25.42 delete B makes deleted_annots = B, B->next = NULL 15:25.57 update makes tmp_annots = B, delete_annots = NULL. Where has A gone ? 15:26.16 FORK(26866) --- fork starting for 'RSSFeeds', PID == 26866, bot_pid == 1005 --- 15:26.17 FORK(26866) !ERROR! cannot load my module: RSSFeeds 15:26.17 FORK(26866) fork: took 1s for RSSFeeds. 15:26.17 FORK(26866) --- fork finished for 'RSSFeeds' --- 15:26.43 "death_row_annots", better name than "death_row" actually. 15:26.45 ah. Usage it to call update just before enumating the changed annotations. Next call to update will throw away ones you didn't enumerate. 15:27.03 ok, so it's safe because of usage. 15:27.18 (that's internal usage, not usage by callers, right?) 15:29.05 wierd indentation in jni/mupdf.c at line 1500ish. In "Android: implement annotation deletion" 15:29.13 No external, but defined usage. The only way it was intended to work. You are about to do a partial update. You call update which handles all dirty widgets and sorting out the right appearance streams. Then you enumerate the changed annotations so that you know which rectangles to draw 15:29.44 Could we always update on the start of an enumeration to be sure? 15:30.01 or would that be slow/break stuff? 15:30.02 You also call update when you are about to draw the whole page, but then you don't want the rectangles, and you never will want the current ones 15:31.25 >>> Srini has signed off IRC (Read error: Connection reset by peer) [#ghostscript] 15:31.53 update means prepare any dirty stuff and set up a list of annotations changed since the last update call in case I need them. 15:32.35 paulgardiner: Right. So if it's expected/assumed that you will always do that before starting an enumeration, can we not force an enumeration to do it anyway? 15:32.46 Or would that redo work unnecessarily ? 15:33.43 Possibly, but then you'd have to do the first step of enumeration even when you didn't need the result just to get the dirty things accounted for and to give you a starting point for the next call. 15:34.09 paulgardiner: I don't follow. 15:34.19 I'm not saying we should remove update from the API. 15:34.56 You mustn't call update twice before an enumation 15:35.00 Just that rather than designing an API that relies on us doing update before an enumeration, wouldn't it be nicer to not have that restriction? 15:35.04 ah, why not? 15:35.37 because then dirty rectangles might be lost ? 15:36.04 Yes, and you want them to be in the draw-the-whole-page case. 15:36.19 paulgardiner: Ok, that sounds... fragile to me. 15:36.19 Chans: (ghostbot) in:#ghostscript 15:38.09 What would be less so? given that not only do you want to avoid accidently missing a rectangle, you also want to avoid accidently drawing one that you already drew 15:50.10 (For the logs, sorted on the phone. My objection is withdrawn. One possible idea would be to rename 'update' to be 'prepare_for_redraw') 15:51.55 paulgardiner: OK, the rest of the stuff looks good to me. 15:52.33 >>> femfum has signed off IRC (Ping timeout: 245 seconds) [#ghostscript] 15:53.13 Chans: (ghostbot) in:#ghostscript 15:53.32 meeting in 5, coffee time 15:53.42 Seen: Flushed 4 entries. 15:56.44 FORK(1529) --- fork starting for 'RSSFeeds', PID == 1529, bot_pid == 1005 --- 15:56.45 FORK(1529) !ERROR! cannot load my module: RSSFeeds 15:56.45 FORK(1529) fork: took 1s for RSSFeeds. 15:56.45 FORK(1529) --- fork finished for 'RSSFeeds' --- 15:58.10 --- Saved uptime records. 16:00.14 looks like everything is moving along well. We should be able to have a quick meeting. 16:01.13 henrys: When we had to do the reflow, you said "do a PDF -> HTML extraction". 16:01.33 Was that a requirement from the potential customer, or you thinking of the best way to get something going fast? 16:02.21 fast - I think there should be a longer term project to do native reflow but we don't have the bandwidth now. 16:02.57 It may be that we could get much better results by implementing our own scalable view. We'd get better font matching, better indents etc. 16:03.00 OK. 16:03.59 I did want to bring up an overarching concern: have we done a careful feature check of the native android app and know what we are missing? 16:05.02 Of *what* native android app? 16:05.13 I'm looking at the nexus 16:05.28 There is no standard android app, it's different on every device. 16:05.43 OK, the standard nexus app. I would assume we have not, as none of us 3 have a nexus. 16:06.27 but there is a standard pdf viewer that goes with the OS release - ice cream jelly bean etc. no? 16:06.32 I think my S2 had Polaris Office 16:06.37 henrys: no. 16:07.04 paulgardiner has been working on the annotation stuff with the intention of matching the mobile Adobe Reader thing, I think. 16:07.26 That's been my initial target 16:07.36 Different vendors bundle different PDF apps with their kit. There is no standard app for us to match. 16:08.23 who is the vendor for native pdf on the nexus? 16:08.39 I have jelly bean on my transformer prime, and it has a different PDF app to jelly bean on the nexus, which is still different to jelly bean on the samsung SIII. 16:08.39 Chans: (ghostbot) in:#ghostscript 16:09.04 henrys: I *think* it might be derived from Repligo? 16:09.53 so I guess the question is do those apps have any obvious important feature that we are missing and could put on Paul's todo list. 16:09.57 I think I'm right in thinking that Sony use QuickOffice, and that's recently changed to using Adobe as the PDF engine. 16:10.37 henrys: Well, matching Adobe Reader for annotations seems like a good first step. 16:11.10 mvrhel_laptop reported, IIRC, that reflow on on of his devices included images, but it was fairly braindead. 16:11.24 (For every image on the page, stick it in the output). 16:11.29 yes that is in the works. I am asking if there is anything else we are sorely missing? 16:12.11 hence images used in patterns would appear as standalone images etc. 16:13.05 I am not aware of anything missing from our app compared to the apps I've looked at, but can't claim to have done an exhaustive sweep. 16:13.16 We're still behind Adobe Reader with annotatoin creation, but catching up. 16:13.42 Does Adobe Reader do forms or javascript? 16:14.39 next show it would be unpleasant to go through "Does it do this cool thing that this other app does?" again that's what I'm trying to avoid. I'll look at my app also. 16:14.59 Robin_Watts: Strangely, it does forms without javascript. 16:15.05 all cool things should be implemented ;--) 16:15.29 should we talk about the release this meeting? 16:15.49 tor8? 16:16.28 I'd be happy for us to release now, as is, no further fiddling. 16:16.41 The issue with mutool being a bit larger than we'd like is no biggy IMHO. 16:16.49 I've had a quick look at what we discussed earlier (re unbloating mutool) and run into problems. 16:17.16 mutool users are running on the desktop, +/- 6Meg ain't going to matter a damn. 16:17.49 It's nice to fix it if we can, but it doesn't make or break a release. 16:18.57 I don't think we can quite as easily as we'd previously suspected. 16:19.57 phone call 16:21.29 sorry I'm back 16:22.17 seems like something that would get stuck in tor8's craw his okay with it? 16:22.50 Robin_Watts: changes you requested are done and pushed. 16:23.49 so I'll just chase after tor8 sometime today about the release. 16:24.05 thanks for the meeting 16:24.15 Chans: (ghostbot) in:#ghostscript 16:25.28 cheers henrys 16:26.36 mvrhel_laptop: ping ? 16:26.39 right, so release now 16:27.09 FORK(17375) --- fork starting for 'RSSFeeds', PID == 17375, bot_pid == 1005 --- 16:27.10 FORK(17375) !ERROR! cannot load my module: RSSFeeds 16:27.10 FORK(17375) fork: took 1s for RSSFeeds. 16:27.10 FORK(17375) --- fork finished for 'RSSFeeds' --- 16:27.26 tor8:was that a question? 16:27.31 if so yes 16:27.40 henrys: it was an acknowledgement. 16:27.47 Robin_Watts: with or without v8? how did we do with the tech preview release? 16:29.04 I do think mvrhel_laptop should start coming to the forms meeting - which should probably just become the mupdf meeting, but it might be early for him. 16:30.01 mvrhel_laptop: do you have your windows 8 app in a git somewhere? 16:31.25 good morning 16:31.36 tor8: I could add it in the mupdf project if you want 16:31.44 I have it in my local copy 16:32.26 mvrhel_laptop: you could do like I, robin and paul and host a personal repo on casper in ~/repos/mupdf.git 16:32.40 oh ok. I will do that then 16:33.22 we have a rule that everything that hits the main repo has to go through a review by one other person 16:34.00 tor8: sounds reasonable. I will get my personal repo in place this week 16:34.16 and your personal repo is yours to do with as you wish. rebase and amend commits freely. 16:34.41 >>> join/#ghostscript marcosw (~marcosw@69-170-62-211.static-ip.telepacific.net) 16:34.56 hi marcosw 16:35.03 morning henrys 16:35.23 I haven't really been following the bugs carefully do we need to go over them after the meeting or are they up to date? 16:35.34 marcosw ^^^ 16:35.56 tor8 I think I have only one mupdf related change that I needed which is #ifdef __cplusplus extern "C" { #endif sort of thing 16:36.08 I think we are up to date. There are a couple of minor issues assigned to support. 16:36.27 mvrhel_laptop: extern "C" { #include "mupdf.h" } doesn't work for you? 16:36.28 in the fitz header 16:36.48 tor8: We should probably add that in the header. It's considered polite, I think. 16:36.52 it's what we force the sumatrapdf folks to do :) 16:36.59 ugh. I don't want to be polite to C++. 16:37.02 it did not work for some reason. I can go back and look again though 16:37.23 If there is no more mupdf business, I have a gs question for mvrhel. 16:37.24 I did try that at the time I remember 16:37.38 * tor8/#ghostscript considers adding variable names like "class" and "template". 16:37.46 :) 16:38.31 mvrhel_laptop: if it doesn't work, knowing why would be good. if there's a valid reason we can add the ifdef c++, but my antipathy towards c++ would prefer not to 16:38.33 Robin_Watts: I can talk about gs 16:38.45 mvrhel_laptop: I've been looking at bug 693653, which is about a slowdown when using shadings. 16:38.59 I think the basic reason for the slowdown is "we now do it properly". 16:39.03 tor8: ok I will reinvestigate this week 16:39.26 but in the discussion, alex has claimed that there is a problem with gx_icc_is_linear_in_line 16:39.29 (see comment 12) 16:39.36 ok hold on 16:39.56 Chans: (ghostbot) in:#ghostscript 16:42.17 Robin_Watts: I would need to see this running to know what is going on exactly. icclink->link_handle should have the number of input and output components 16:42.30 and the output components should match the number of the device profile 16:42.46 but let me take a closer look at remap_fast 16:43.51 mvrhel_laptop: I am assuming that the icclink passed in is somehow related to the cs and the device :) 16:44.06 yes. it is calculated early on in the shading code 16:44.57 Could the icclink not be calculated from the other params passed into this function? 16:45.08 or would that take longer than just passing it in? 16:48.50 is there a case where ndes = gsicc_get_device_profile_comps(dev_profile) is not the number we are going out to? 16:49.14 I am not aware of one. 16:49.16 Robin_Watts: so the icclink is calculated way before we ever get to this point 16:49.39 but alexcher's comment lead me to think that maybe he had seen such a case. 16:49.42 alex? 16:49.51 mvrhel_laptop: Would this function be faster if we use remap_buffer rather than remap_color? 16:49.53 that would be very strange 16:50.03 if we have a buffer of colors it would be faster 16:50.26 i.e. make 1 call for 3 colors into the ICC rather than 3 calls for 1 color each. 16:51.03 In the next function, we make 7 calls, when we could make one. 16:51.33 oh yes this is the linear test stuff 16:51.53 yes, we could pack them into a single buffer, transform and then do the linear test 16:52.13 I don't know if with that few of colors if it will make much timing difference Robin_Watts 16:52.28 The whole bug is about decompose_linear_color taking a long time. 16:53.46 Robin_Watts: do we know what commit made it take a long time? I am wondering, since there were some shading bugs that I fixed in the last year where we were not doing things that we should have been doing. Those included transparency I think though. 16:53.55 Each time we recurse (to split the range in half) we check to see if the colorspace is linear in the required region. 16:54.02 Robin_Watts: yes 16:54.07 mvrhel_laptop: I know exactly what caused it to be slow :) 16:54.07 Seen: Flushed 6 entries. 16:54.26 uhoh 16:54.26 it's probably slow because it is unlinear ;-) 16:54.43 originally (years ago, before I joined the company) the code used to decompose to single pixel level. 16:55.18 Then (not so long ago, but still before I joined) it was changed to only decompose to 1pt accuracy. 16:55.31 This was much faster, but less accurate. 16:55.51 and noticeably so, so we got a bug report. 16:56.43 so last year, I reverted the optimisation, with the option of having a #define in there to set MAX_SHADING_RESOLUTION, so people could opt for the faster speed if they wanted it. 16:57.20 I see. so you gave them a taste of speed 16:57.21 >>> join/#ghostscript ray_laptop (~chatzilla@rrcs-64-183-45-163.west.biz.rr.com) 16:57.31 Chans: (ghostbot) in:#ghostscript 16:57.31 FORK(624) --- fork starting for 'RSSFeeds', PID == 624, bot_pid == 1005 --- 16:57.32 FORK(624) !ERROR! cannot load my module: RSSFeeds 16:57.32 FORK(624) fork: took 1s for RSSFeeds. 16:57.32 FORK(624) --- fork finished for 'RSSFeeds' --- 16:57.53 I thought it might be possible to use the MAX_SHADING_RESOLUTION trick in the case where we are using linear color fills, but having tested that, it produces unacceptable results (IMHO, see my bmpcmp page if you're interested). 16:58.23 --- Saved uptime records. 16:58.44 As it is, we now take 250 seconds instead of 4 (in the inaccurate, pre color corrected days), but we get it right. 16:59.17 oh yes the one image has some bad contours. some don't look too bad though Robin_Watts 16:59.25 Robin_Watts: I'm back. 16:59.57 Robin_Watts: there is probably def. room for speed up in the linear check code 17:00.05 especially if that is a hot spot that you are seeing 17:00.17 I made no attempt to optimize at the time 17:00.23 mvrhel_laptop: At the moment, I'm still trying to get my head around the whole thing. 17:00.27 alex: hi. 17:00.41 how many times do we check to see if a colorspace is linear ? 17:00.54 as long as it is still nonlinear ;) 17:01.05 It's not "is the colorspace linear". It's "is the colorspace linear in this region". 17:01.24 and we recheck repeatedly until the region is small enough that it's linear. 17:01.34 can't we do a more complete check ONCE and mark it as linear (most colorspaces are pretty linear) 17:01.59 alex: in comment 12 you talk about ndes coming from the wrong place. Have you ever seen a case where ndes is the wrong value? 17:02.31 Robin_Watts: Yes, in this bug. 17:02.33 ray_laptop: At every stage of the decomposition, if it's not already linear, we check to see if it has become so. 17:03.10 hence a colorspace that is essentially linear throughout will only be checked once. 17:03.39 alexcher: With this example file? Right. 17:03.44 if ndes is wrong, then that is a bug that I would like to look at. alexcher, is there anything special I need to do to catch this case? 17:04.15 Only 1 output component is generated. The following code compares wild core for linearity. 17:05.12 chrisl:so I guess you have heard mupdf release is imminent hopefully 17:05.14 mvrhel_laptop: I think I've posted everything. 17:05.35 alexcher: ok I will take a look at it 17:05.36 alexcher: You also talk about converting more colors at once by keeping them in a single array... is that to avoid repeated gsicc_remap_fast calls within the gx_icc_is_linear code ? or elsewhere? 17:05.53 henrys: yep, I will keep an eye out for it 17:06.16 good to get it out before march 1 (rapidly approaching) 17:06.37 Robin_Watts: if you would rather me not poke into this since you have already started, I can back off and keep working on my windoze app. not sure what you have on your plate 17:06.46 henrys: Doing the mupdf commercial release is trivial - takes only minutes 17:06.55 Robin_Watts: Yes. Probably this will not be so significant when other errors are fixed. 17:07.23 mvrhel_laptop: I'd appreciate you looking at it, if you wouldn't mind. 17:07.53 I can see various places where we can safe some time, but no massive algorithmic fixes. 17:08.01 s/safe/save/ bah. 17:08.18 Robin_Watts: ok. first I will look at seeing if I can catch the ndes issue 17:08.25 we don't think a profile is needed with 693653? 17:08.45 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 17:08.45 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 17:09.03 henrys: I'll do a profile, but it would be better to profile after the known bugs are fixed. 17:09.25 okay 17:09.31 I'm gonna have to run away for about 10 minutes in the next 10 minutes or so - anyone want me for anything? 17:09.39 Robin_Watts: There's another problem there. I've initialized the arrays, i.e. made this code work a little close to the original intent. And another branch broke completely. 17:09.39 Not me 17:09.53 Robin_Watts: fine for me. 17:10.05 ray_laptop:have you inherited smask? 17:10.50 my initial thinking was alexcher would do the work with help from others. but if you have the cycles ... 17:10.51 alexcher: This is the "cleaning the buffers" thing? 17:10.57 henrys: before we profile, let me see if I can catch the bug that alexcher mentioned. if the ndes values is wrong, then that would/could give wacky results 17:11.22 mvrhel_laptop: okay 17:11.53 kens:I'm going to check in the xps code shortly but I'll probably just continue working on it. I've grown fond of it. 17:12.10 he has been assimilated. 17:12.19 Robin_Watts: Initializing first 3 elements is enough. 17:13.10 alexcher: OK. so we should understand/fix that too before I profile. 17:13.15 I have had a chance to dive into the XPS C API - it is very difficult for me to believe folks are going to relatively their fairly simple gdi code without extreme pressure from MS 17:13.36 Chans: (ghostbot) in:#ghostscript 17:13.47 s/relatively/change 17:13.49 THe XPS API is OK, I had to reaqd it a bit to get the printing going 17:14.20 ]From my POV I'm done with XPS printingfor now, I cna take an existing XPS file and print it to a designated printer 17:14.48 SO for a GSPrint, we just need to run xpswrite to generate an XPS file, then send it to the printer. 17:15.13 Robin_Watts: Currently profiling shows that about 30% of time is spent by LCMS, but this happens because the shading is decomposed into smallest possible fragments. 17:15.18 If you wanted a tighter integration we could do something that builds an internal XPS file. 17:15.27 henrys: sorry -- I was working on the changes, but Yes, I took the SMask bug and know how to make it work 17:15.43 henrys but I htink an xpswrite device should not be tied to the WIndows API :_) 17:15.46 kens:oh okay can you set arguments though, so we can fix the bugs? 17:15.54 kens:certainly not 17:16.12 henrys, at the moment my code just takeds an existing XPS file 17:16.24 THere aren't really any arguments to give, other than the printer name 17:16.41 If you want flourishes we can pop up a printer dialog to set up the printer defaults 17:16.48 ray_laptop: can I ask you a cust 532 question? 17:17.26 chrisl: sure -- do we need a private chat ? 17:18.01 kens:what I meant about difficult is creating an xps document. It is horribly complex a bizillion objects to do very simple stuff, I don't think that is going to fly unlesss microsoft pulls out gdi 17:18.14 ray_laptop: No I don't think so - their latest font bug is a broken CFF that the "new" C parser fixes. Are we happy giving them that as a 8.71++ patch? 17:18.58 chrisl: as long as it builds with their pre 9.00, sure 17:19.12 henrys, yes certainly creating an XPS file is hard and complex (like writing a PDF file but with no advantages). You can make an internal XPS document comparatively easily using the WIndows API though. But I agree, as long as there is a legacy path, (ie GDI) nobody is going to use the XPS pritn path 17:19.48 chrisl: note that they _are_ moving to 9.0x and so it's only a patch on the older products (that are already heavily patched with fixes that are now in 9.0x) 17:19.49 ray_laptop: Yep, I've got it integrated and seems to be working. But I was going to leave the "heavy" testing to them...... 17:21.14 chrisl: yes, they will run it through their QA process, but if you tell them the nature of the changes and what to check (i.e. all text) then that might help them 17:22.11 ray_laptop: yeh, I'll do that 17:22.21 kens:can you override the page size? see http://bugs.ghostscript.com/show_bug.cgi?id=691921 comment 5 17:22.43 chrisl: you should also let them know that it is already fixed in the newer code, and that we have extensively tested it in 9.0x 17:22.58 chrisl: which release had this ? 17:23.00 henrys We can certainly pop up a print dialog so that the suer can select the appropriate media 17:23.25 ray_laptop: 9.00 introduced the C CFF parser 17:23.26 I haven't gone that far because I wanted to talk to you about how you saw this going. Maybe we can talk at the meeting in 2 weeks 17:23.43 kens:I thought they were aware of that but wanted unattended processing, maybe marcosw remembers. 17:24.13 henrys I *think* we cna set up a XPS job ticket, but again I haven't looked at this in detail to see whatr's in it 17:24.15 they can pop up the printer dialog now. 17:24.23 chrisl: OK, thanks. So you can tell them that the 9.06 code they have been testing has this same code. That will help them feel more comfortable 17:24.28 henrys, no, they have to set up the prtiner *default* before starting 17:24.40 ray_laptop: sure will do 17:25.09 In our case we would pop up a dialog after starting to print, and user can select settigns for that print job only 17:25.55 henrys, I'll make a point of reading the docs before the meeting so I can talk sensibly about this again, its been a few weeks since I last looked into this 17:25.56 kens:I imagine the printer default is set once and left alone - then they want batch (no interaction) processing, but I am not 100% 17:26.32 henrys, this is the sort of thing I wanted to discuss :-) What exactly we want this 'GSPrint replacement' to be able to do.... 17:26.51 I'll look at the job ticket and see what control we have 17:27.15 mvrhel_laptop: do you think you can start making the mupdf meetings, be nice to have you weigh in since you are working on the windows platform. 17:27.16 ? 17:27.37 henrys: yes what time are they? 17:27.46 1 hour before this one :-) 17:27.47 an hour before the gs meeting 17:27.57 FORK(22656) --- fork starting for 'RSSFeeds', PID == 22656, bot_pid == 1005 --- 17:27.58 FORK(22656) !ERROR! cannot load my module: RSSFeeds 17:27.58 FORK(22656) fork: took 1s for RSSFeeds. 17:27.58 FORK(22656) --- fork finished for 'RSSFeeds' --- 17:28.10 henrys: sure. I will plan on it 17:28.17 great 17:29.09 kens:I'll look at the print stuff also. 17:29.13 >>> join/#ghostscript rooligan (~gandaro@p579B5C5A.dip.t-dialin.net) 17:29.13 >>> rooligan has signed off IRC (Changing host) [#ghostscript] 17:29.13 >>> join/#ghostscript rooligan (~gandaro@wikipedia/Gorlingor) 17:29.43 Chans: (ghostbot) in:#ghostscript 17:31.29 kens:I was thinking the printer would be a windows only device and a subclass of xpswrite, but I don't know what sort of minefield that will be. 17:31.46 henrys yes I was assuming it would be a winpdws only thing 17:32.09 I would suggest adding it as a bolt-on to xpswrite, but subclass works too 17:32.35 I was thinking in terms of having xpswrite create a temp file, then xpsprint sending it to the printer, then deleting the file. 17:32.49 so xpswrite would remain unchanged 17:33.19 yes it uses the regular outputfile mechanism now 17:33.43 THat was what I was thinking. If we write to a temp location we can then print the file and finally delete it 17:33.44 other stuff for the meeting we are 3 minutes over 17:34.14 you're still plugging away on cm yes? 17:34.20 kens ^^^ 17:34.30 henrys yes afraid so 17:34.46 Currently constructing a test file for all possible combinations of colour spaces, vector and images 17:35.12 Bascially it works right now, but I haveto test all the edge cases, then start adding enhancements 17:35.41 right 17:35.50 I can now test all spaces with vectors and type 1 images 17:36.06 Still to do imagemasks (don't expect problems) and type 3 and 4 images 17:36.23 THen I cna look at 12 and 16 bit images, which we handle very badly at present 17:41.00 693663 is definitely a problem for PXL because the resolution options are really just 300 and 600. 17:41.03 Ah crap the print ticket is in XML :( 17:41.19 kens:you were expecting ??? 17:41.37 expceting XML, hoping for somethign nicer :-( 17:41.51 It shows a certain consistency that Microsoft are not known for :) 17:41.52 henrys 693663 he should set the resolution to 300 then 17:42.24 Or get more memory 17:42.55 OK off to make dinner, bye all 17:44.00 >>> kens has signed off IRC (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) [#ghostscript] 17:44.41 chrisl, alexcher: have we really looked into these cairo files to make sure we can't be more lazy about installing pdf14? I guess we did look at that a while back. 17:45.58 oh wait ray_laptop was going to have banding for all devices and then cleverly mark bands transparent. right? 17:45.58 Chans: (ghostbot) in:#ghostscript 17:46.49 so 693663 should say the problem will be fixed when that is done, yes? 17:47.22 henrys: yes, we did look at spotting such "pointless" transparency, but for a reason which currently escapes me, we concluded it wouldn't work - too slow, for "real" files 17:48.58 IIRC, one of the files I looked at contained an all opaque softmask, so we'd need to process all the samples to check it, but I think there were other issues with other files 17:49.26 henrys: ps2write doesn't support banded operation (nor does pdfwrite). hence any magic trickery that ray may do in the clist will not help those cases. 17:49.58 Robin_Watts: the plan is to use a clist for the transparency flattening for those devices 17:50.19 so the devices would use the clist without knowing they were using the clist ? 17:51.07 They'd probably need updated to accept the flattened groups in bands, if required 17:51.10 alexcher: so I am running the test file with a gray device, and I never see a case where ndes is not 1. what do I need to do to see the issue you mentioned? the comments in the bug do not provide any guidance 17:51.25 well I thought he was going to do something like the pattern clist machinery, but ray_laptop should answer 17:51.56 henrys: I have the 'cleverly mark bands' for transparency. 17:52.33 the question is will it work with any device? 17:52.37 henrys: and putting in a clist for "other" devices is on the list (when the bitmap exceeds the MaxBitmap setting) 17:53.26 So the answer to 693663 is: it's in the works 17:53.35 not: go away 17:54.26 Seen: Flushed 7 entries. 17:55.07 henrys: sure that is covered in 689805? 17:55.36 alexcher: any hints on where and how you see the issue with ndes, would be much appreciated 17:55.58 chrisl: oh okay right, I can shutup now. 17:56.41 henrys: the goal is to work with any raster device. High level devices that render transparency to a memory device will use it 17:56.48 I guess ken's comment could have made it clearer that we have a plan being tracked under 689805 17:57.28 ray_color:okay so pxcolor will need work to use it. 17:57.41 high level devices that handle transparency directly (that grab the pdf14 compositor actions) won't use it 17:58.18 FORK(13187) --- fork starting for 'RSSFeeds', PID == 13187, bot_pid == 1005 --- 17:58.19 FORK(13187) !ERROR! cannot load my module: RSSFeeds 17:58.19 FORK(13187) fork: took 1s for RSSFeeds. 17:58.19 FORK(13187) --- fork finished for 'RSSFeeds' --- 17:58.58 --- Saved uptime records. 17:59.23 henrys: "high level" devices like pxlcolor render transparent pages to a bitmap. The default pdf14 compositor in gdevp14.c snags all drawing operations and the pxlcolor device only gets called at end of page with a full page bitmap 17:59.41 ray_laptop:I take that back pxcolor will work 17:59.46 oh what you said 18:00.54 henrys: probably will work without mods. Note that this will NOT work without mods to use clist to render large bitmaps that don't use transparency 18:01.51 got it 18:01.51 Chans: (ghostbot) in:#ghostscript 18:02.18 but to add this for really large bitmaps to something like the display device won't be too bad, but "normal" painting operations to 'vector' devices won't get picked up unless the page uses transparency 18:08.37 >>> ray_work has signed off IRC (Quit: bye for now) [#ghostscript] 18:12.23 >>> marcosw has signed off IRC (Quit: marcosw) [#ghostscript] 18:17.26 Chans: (ghostbot) in:#ghostscript 18:20.07 mvrhel_laptop: gs -r87 -sDEVICE=bmp16m -o /dev/null enac1.pdf 18:21.19 mvrhel_laptop: Just put a breakpoint in gx_icc_is_linear_in_line(). The first break has this problem. 18:22.04 mvrhel_laptop: I'm using 64-bit Linux. 32-bit Linux is also slow. 18:23.16 ok. so is bmp16m gray? 18:23.29 mvrhel_laptop: No, it's RGB. 18:23.34 mvrhel_laptop: No. 18:23.39 ok so ndes is coming out as 3 for me 18:23.47 which I would expect 18:23.59 >>> join/#ghostscript ||arifaX (~quassel@unaffiliated/arifax/x-427475) 18:24.02 I thought the issue was a gray issue 18:24.15 I need to head out now unfortunately for about an hour to the kids school 18:24.22 mvrhel_laptop: But CMS generates only 1 component. 18:24.42 ok let me step in there real quick 18:25.55 ok. yes. there is an issue 18:26.14 I wonder if there is something going wrong because of the 16 bit case 18:26.27 I will look at this more when I return now that I can see 18:26.36 thanks alexcher 18:28.47 FORK(32192) --- fork starting for 'RSSFeeds', PID == 32192, bot_pid == 1005 --- 18:28.48 FORK(32192) !ERROR! cannot load my module: RSSFeeds 18:28.48 FORK(32192) fork: took 2s for RSSFeeds. 18:28.48 FORK(32192) --- fork finished for 'RSSFeeds' --- 18:30.12 >>> chrisl materializes into chrisl_away 18:33.28 Chans: (ghostbot) in:#ghostscript 18:40.29 paulgardiner: ping 18:41.04 >>> join/#ghostscript marcosw (~marcosw@eduroam-230-64.ucsc.edu) 18:47.24 >>> ||arifaX has signed off IRC (Remote host closed the connection) [#ghostscript] 18:49.30 Chans: (ghostbot) in:#ghostscript 18:54.43 Seen: Flushed 6 entries. 18:59.14 --- Saved uptime records. 18:59.41 FORK(21235) --- fork starting for 'RSSFeeds', PID == 21235, bot_pid == 1005 --- 18:59.42 FORK(21235) !ERROR! cannot load my module: RSSFeeds 18:59.42 FORK(21235) fork: took 2s for RSSFeeds. 18:59.42 FORK(21235) --- fork finished for 'RSSFeeds' --- 19:03.10 >>> join/#ghostscript malc_ (~malc@188.123.241.147) 19:05.12 Chans: (ghostbot) in:#ghostscript 19:07.01 tor8: hi, hit a very interesting issue today, after some transform_rect (for a very tall argument 10K+ pixels high), the result has a height of 6.. furthermore i can not reproduce it on my home machines (not on x86_64 neither on ppc32), perhaps that rings any bells for you? [oh and futhermore mupdf on that other machine which i will only have access tomorow kills X (the pdf contains only one page, though this one page is rather gargantuan hight wise, this 19:20.41 malc_: What architecture were you seeing the strange result on ? 19:20.50 Can we see the file? 19:21.00 Chans: (ghostbot) in:#ghostscript 19:22.21 Robin_Watts: x86_64, it's just a pango-view -o moo.pdf output of some ~7.5KLOC source file, since i'm not sure what fonts were embedded the file would have to wait till tomorow 19:23.17 Robin_Watts: i sortof ruled out optimization problem given that same thing happens with debug and release builds and both gcc and clang produced binaries exhibit same behavior 19:23.28 pretty weird if anyone would have been interested in my opinion 19:24.00 malc_: Well, it's probably an overflow of some sort, obviously. 19:24.44 given that mupdf is not really gcc -Wall friendly it might be 19:29.18 http://ghostscript.com/~robin/MuPDF-9.apk <- New android build for testing. 19:29.48 FORK(28209) --- fork starting for 'RSSFeeds', PID == 28209, bot_pid == 1005 --- 19:29.49 FORK(28209) !ERROR! cannot load my module: RSSFeeds 19:29.49 FORK(28209) fork: took 1s for RSSFeeds. 19:29.49 FORK(28209) --- fork finished for 'RSSFeeds' --- 19:33.34 Robin_Watts: btw. any answer to the question i asked few days ago? 19:36.46 Chans: (ghostbot) in:#ghostscript 19:43.46 apparently not 19:43.46 >>> malc_ has signed off IRC (Quit: leaving) [#ghostscript] 19:52.48 Chans: (ghostbot) in:#ghostscript 19:55.04 Seen: Flushed 2 entries. 19:59.26 --- Saved uptime records. 19:59.57 FORK(24884) --- fork starting for 'RSSFeeds', PID == 24884, bot_pid == 1005 --- 19:59.58 FORK(24884) !ERROR! cannot load my module: RSSFeeds 19:59.58 FORK(24884) fork: took 2s for RSSFeeds. 19:59.58 FORK(24884) --- fork finished for 'RSSFeeds' --- 20:08.30 Chans: (ghostbot) in:#ghostscript 20:15.36 mvrhel_laptop: do you have a file laying around that has nested SMasks ? (or Robin_Watts) ? 20:16.39 I have the test_smask2.pdf rendering correctly now. Two simple changes 20:18.08 the changes ended up being almost what I thought was needed last week when I dove into this, but finding out where in the mess to put them took the time (PS debugging is much harder than C, so I spent too much time tracing the C code) 20:25.02 Chans: (ghostbot) in:#ghostscript 20:30.11 FORK(29537) --- fork starting for 'RSSFeeds', PID == 29537, bot_pid == 1005 --- 20:30.12 FORK(29537) !ERROR! cannot load my module: RSSFeeds 20:30.12 FORK(29537) fork: took 2s for RSSFeeds. 20:30.12 FORK(29537) --- fork finished for 'RSSFeeds' --- 20:31.15 I sure am glad user jobs jump in ahead of commit tests :-) 20:41.40 Chans: (ghostbot) in:#ghostscript 20:44.56 letting the cluster tell me what my changes break 20:52.18 ray_laptop: Excellent! 20:52.30 No, I don't have any such files (that I know of), sorry. 20:52.51 >>> rooligan has signed off IRC (Quit: Leaving) [#ghostscript] 20:55.24 Robin_Watts: np. The cluster pointed me to some differences that I need to investigate. I'm hoping that many will be progressions, but that is just my optimistic nature ;-) 20:55.24 Seen: Flushed 2 entries. 20:57.42 Chans: (ghostbot) in:#ghostscript 20:59.28 --- Saved uptime records. 21:00.39 FORK(31145) --- fork starting for 'RSSFeeds', PID == 31145, bot_pid == 1005 --- 21:00.40 FORK(31145) !ERROR! cannot load my module: RSSFeeds 21:00.40 FORK(31145) fork: took 1s for RSSFeeds. 21:00.40 FORK(31145) --- fork finished for 'RSSFeeds' --- 21:03.55 ray_laptop: Have you bmpcmp'd ? 21:09.32 !WARN! PERL: readdir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 862. 21:09.32 !WARN! PERL: closedir() attempted on invalid dirhandle DEBIAN at ./src/IRC/Schedulers.pl line 869. 21:09.59 ray_laptop: I can't find the bug that had the softmask in softmask file 21:10.07 I think it is in the data base though 21:10.17 the regression suite I mean 21:11.36 >>> marcosw has signed off IRC (Quit: marcosw) [#ghostscript] 21:12.44 >>> join/#ghostscript marcosw (~marcosw@eduroam-230-64.ucsc.edu) 21:13.11 >>> join/#ghostscript marcosw_ (~marcosw@eduroam-230-64.ucsc.edu) 21:13.11 Chans: (ghostbot) in:#ghostscript 21:13.11 >>> marcosw has signed off IRC (Read error: Connection reset by peer) [#ghostscript] 21:13.12 >>> marcosw_ materializes into marcosw 21:14.33 ok. so the issue with ndes is a pdf14 color chameleon issue 21:14.41 As I suspected 21:15.02 should be easy to fix this 21:15.05 bbiab 21:18.41 I have the file Bug690535.pdf that shows problems. Starting with that one... 21:19.01 time for lunch... 21:19.39 ray_laptop: Did you run bmpcmp ? 21:23.17 >>> ray_laptop has signed off IRC (Ping timeout: 255 seconds) [#ghostscript] 21:27.05 >>> join/#ghostscript Fandekasp (~Fandekasp@platinum-static25142.nirai.ne.jp) 21:29.16 Chans: (ghostbot) in:#ghostscript 21:31.07 FORK(21020) --- fork starting for 'RSSFeeds', PID == 21020, bot_pid == 1005 --- 21:31.08 FORK(21020) !ERROR! cannot load my module: RSSFeeds 21:31.08 FORK(21020) fork: took 1s for RSSFeeds. 21:31.08 FORK(21020) --- fork finished for 'RSSFeeds' --- 21:34.21 >>> plinnell has signed off IRC (Remote host closed the connection) [#ghostscript] 21:40.51 Can I convert fonts to paths and keep copying chars? Acrobat can do I this. 21:44.33 Chans: (ghostbot) in:#ghostscript 21:55.53 Seen: Flushed 4 entries. 21:59.45 --- Saved uptime records. 22:01.10 Chans: (ghostbot) in:#ghostscript 22:01.21 FORK(7689) --- fork starting for 'RSSFeeds', PID == 7689, bot_pid == 1005 --- 22:01.22 FORK(7689) !ERROR! cannot load my module: RSSFeeds 22:01.22 FORK(7689) fork: took 2s for RSSFeeds. 22:01.22 FORK(7689) --- fork finished for 'RSSFeeds' --- 22:02.09 >>> marcosw has signed off IRC (Quit: marcosw) [#ghostscript] 22:17.02 Chans: (ghostbot) in:#ghostscript 22:32.09 FORK(26906) --- fork starting for 'RSSFeeds', PID == 26906, bot_pid == 1005 --- 22:32.10 FORK(26906) !ERROR! cannot load my module: RSSFeeds 22:32.10 FORK(26906) fork: took 1s for RSSFeeds. 22:32.10 FORK(26906) --- fork finished for 'RSSFeeds' --- 22:37.07 LOG: last message repeated 3 times 22:37.07 >>> paulgardiner has signed off IRC (Quit: ChatZilla 0.9.90 [Firefox 18.0.2/20130201065344]) [#ghostscript] 22:43.19 ircCheck: possible lost in space; checking.Tue Feb 26 22:43:19 2013 22:43.19 >ghostbot< TEST 22:43.19 IRCTEST: Yes, we're alive. 22:48.23 Chans: (ghostbot) in:#ghostscript 22:59.44 >>> join/#ghostscript marcosw (~marcosw@c-67-164-54-215.hsd1.ca.comcast.net) 23:00.04 --- Saved uptime records. 23:02.39 FORK(15216) --- fork starting for 'RSSFeeds', PID == 15216, bot_pid == 1005 --- 23:02.40 FORK(15216) !ERROR! cannot load my module: RSSFeeds 23:02.40 FORK(15216) fork: took 1s for RSSFeeds. 23:02.40 FORK(15216) --- fork finished for 'RSSFeeds' --- 23:04.25 Chans: (ghostbot) in:#ghostscript 23:07.43 >>> marcosw has signed off IRC (Quit: marcosw) [#ghostscript] 23:20.47 Chans: (ghostbot) in:#ghostscript 23:33.23 FORK(30518) --- fork starting for 'RSSFeeds', PID == 30518, bot_pid == 1005 --- 23:33.24 FORK(30518) !ERROR! cannot load my module: RSSFeeds 23:33.24 FORK(30518) fork: took 1s for RSSFeeds. 23:33.24 FORK(30518) --- fork finished for 'RSSFeeds' --- 23:47.19 ircCheck: possible lost in space; checking.Tue Feb 26 23:47:19 2013 23:47.19 >ghostbot< TEST 23:47.19 IRCTEST: Yes, we're alive. 23:52.25 Chans: (ghostbot) in:#ghostscript