| | <<<Back 1 day (to 2011/10/09) | 2011/10/10 |
| BamJangles | ok.. our company is thinking abotu buying ghostscript to parse pclxl pcl5 and ps files for page information like color and black and white and page sizes. ive done some testing and this seems achievable by renerding the files into an image and looking at the colors on each page. my question is, how difficult would it be to convert ghostpdl into a usable dll supporting pclx and ps. IE that | 01:51.05 |
| | way we could just probe the image output in memory. And would it be possible to have it fairly compatible with future versions | 01:51.05 |
| | rendering even | 01:51.30 |
| LaoLang_cool | hello | 10:32.45 |
| | In mupdf, how to set pdf zoom radio to 100% | 10:33.00 |
| kens | ping chrisl | 12:14.02 |
| chrisl | kens: poing | 12:15.23 |
| kens | poing ? You ball has a crack in it... | 12:15.54 |
| | can you take a quick look at #692576 please ? | 12:16.10 |
| chrisl | Looking now..... | 12:16.18 |
| kens | It is now fixed, but I think its something you did recently | 12:16.22 |
| | If I use -dDisableFPAI then teh output is wrong as per the customer report | 12:16.34 |
| | otherwise its OK. | 12:16.42 |
| | I don't have an untarnished 9.04 to test against | 12:16.54 |
| chrisl | I'll check it a sec | 12:17.26 |
| kens | Thanks. | 12:17.33 |
| | I expect Marcos will be happy not to do a bisect if you know the answer quickly | 12:17.52 |
| chrisl | It's probably the fix for not generating fake vertical metrics for "real" CIDFontType 2 fonts | 12:19.50 |
| kens | Could be, its recent enough that I kind of remember you fixing the problem.... | 12:20.10 |
| chrisl | Yep, I see the problem in 9.04...... | 12:21.26 |
| kens | So it has been fixed, that's good anyway. | 12:21.43 |
| chrisl | Yep, it is that fix | 12:24.17 |
| kens | Excellent, so you can put that in the bug thread and close it :-) | 12:24.33 |
| chrisl | Done | 12:27.06 |
| kens | Bugger, VS just crashed..... | 12:27.16 |
| LaoLang_cool | hi, any mupdf guys alive? | 12:38.30 |
| kens | tor does not appear to be here. | 12:38.42 |
| LaoLang_cool | kens: yes | 12:38.56 |
| kens | Speak of the devil. Tha'ts spooky | 12:39.47 |
| | tor8 did you see LaoLang_cool's question earlier ? | 12:48.07 |
| tor8 | kens: yeah, I saw it pop up on the irclog and realized my irc window wasn't running :) | 12:48.39 |
| | LaoLang_cool: when you start mupdf it's at 100% zoom | 12:48.50 |
| | I have a patch sitting in a bug report that will let you type in the zoom level similar to the way you can type in a page number to go to | 12:49.20 |
| LaoLang_cool | tor8: tor8 nice | 12:50.04 |
| | will wait it go into the trunk | 12:50.12 |
| kens | OK, yet another refinement to text reneering modes, anyone want to run a sweepstake on how many regression files fail with this change ? | 12:59.03 |
| kens | goes to fortify with caffeine. | 13:01.17 |
| BusError | I'm running ghostscript oh a small arm board, with 64MB of ram; it seems I run out of memory for any cups jobs that uses gstoraster; are there any configuration I can tweak to make gs less memory hungry ? | 14:08.23 |
| kens | lower resolution is a good start :-) | 14:08.45 |
| | monochrome instead of colour. | 14:08.57 |
| | you can decrease the size of caches | 14:09.09 |
| BusError | well, the resolution is printer dependant (600dpi)... and it's a monochrome printer | 14:09.17 |
| kens | If you have a disk you can run in banded mode instead of page mode | 14:09.22 |
| BusError | I itred the "-c 30000000 setvmthreshold" | 14:09.41 |
| kens | 64Mb should be plenty for 600 dpi monochrome | 14:09.43 |
| BusError | thats what I had assumed | 14:09.53 |
| Robin_Watts | BusError: When cups calls gs, it sets a variable to set the rip max cache size. | 14:09.57 |
| | called something like RIPMAXCACHESIZE | 14:10.09 |
| kens | This is CUPS ? | 14:10.10 |
| BusError | I use to ran gs in 8MB of ram on mu Sun 3/60 :-) | 14:10.16 |
| kens | Oh yes, cups.... | 14:10.18 |
| | First, don't use CUPS.... | 14:10.34 |
| BusError | I tweaked gstoraster.c already | 14:10.44 |
| | kens, any other printer subsystem that will 1) announce printers on the lan 2) simulate a ps printer 3) proxy to a non-ps one ? | 14:11.25 |
| kens | There are many, but they are all commercial as far as I know | 14:11.43 |
| | You could always write your own :-) | 14:12.00 |
| BusError | I'm making a small printer proxy for the family's ipads. runs on a mini2440. i sorta had assumed it'd be just fine, really | 14:12.36 |
| kens | ping marcosw_ (not expecting an answer but...) | 14:14.07 |
| BusError | my system works, if I add swap.. but swap on a SD card is like no-no. it's also horendously slow, since it's using like 180MB ram on a 64MB system... on flash | 14:14.50 |
| kens | BusError : your first job will be to find out why its using so much memory | 14:14.51 |
| | So you should probably start by tkaing one of he PS files and running it on a desktop GS to see if it does the same. | 14:15.15 |
| Robin_Watts | BusError: A good start would be to find exactly the command line that's being used. | 14:15.36 |
| kens | You can also try running GS on the board with a real simple 'hello world' file to make sure that works OK. | 14:15.41 |
| | Robin_Watts : is also correct, you need to know how CUPS is exercising GS | 14:16.30 |
| BusError | well, I use gltoraster, part of gs distro; so the 'source' I assume is the file received from the network... | 14:17.12 |
| kens | That will be a PostScript file though (I assume, I'm not familiar with eitehr CUPS or gstoraster) | 14:17.53 |
| BusError | http://pastebin.ca/2088689 | 14:18.04 |
| kens | It may contain stuff that alters the GS setuo | 14:18.08 |
| BusError | I also get that "undefined" error, thats seem related to ICC profiles not present (?).. I wonder if there could be a link... | 14:18.42 |
| kens | Yeah, loads of weird CUPS stuff. | 14:18.45 |
| | Are you using the released GS or the current master to build ? | 14:19.14 |
| BusError | personally friggin hate printers anyway :-) | 14:19.26 |
| | 9.0.4 GPL | 14:19.31 |
| kens | undefined in setpagedevice is fatal | 14:19.37 |
| | I'd use the current master | 14:19.58 |
| | There have been CUPS and ICC fixes. | 14:20.11 |
| BusError | BTW took me a good day to have gs cross compiling cleanly, and Ipm not exactly a newbie :/ | 14:20.36 |
| kens | Its non-trivial, certainly | 14:20.46 |
| | THe pastebin looks like a more fundamental problem though. THat looks more like a driver problem than a VM error | 14:21.23 |
| | But I'd need the source file to go with it in order to investigate | 14:21.44 |
| | There is a way to capture that, but I'm not sure how. | 14:22.06 |
| Robin_Watts | pops to post office, then gets lunch. | 14:22.29 |
| BusError | nor me. I'll hunt | 14:22.30 |
| kens | chrisl any way to capture CUPS input ? | 14:22.47 |
| | tee or something ? | 14:22.55 |
| BusError | here's my giant sed hack to 'fix' ghostscript: http://pastebin.ca/2088690 | 14:23.06 |
| kens | Means nothing to me ;-) | 14:24.09 |
| BusError | well lets say it involves yanking all the libs that are embedded, and old... and then hacking the Makefile /post/ configure | 14:28.55 |
| | which is funny, since ghostscript was one of the very early program to use a configure script, way back then ;-) | 14:29.27 |
| kens | The library source we supply with GS is known to work, if you insist on not using that source, tehn bad things may happen. | 14:29.29 |
| | I'd stick with the library sources supplied with GS | 14:29.54 |
| BusError | well I run on a small platform, if everyone starts duplicating the libs they like, you don't go very far | 14:30.04 |
| kens | Your choice, but if you are not using our library source then we cannot duplictae your setup. | 14:30.25 |
| | which means we may not be able to duplicate your bugs. | 14:30.37 |
| | we are having that very discussion with a Linux distor maintainer at the moment | 14:30.51 |
| | distro | 14:30.58 |
| | Not ahat I'm saying that is your current probolem, but if I were you I'd start with source that is known to work. | 14:31.28 |
| BusError | heh, what about shipping your own libc then ? if you extend that argument, you should ship the libs. Oh and a compiler too | 14:31.48 |
| kens | You cna extend arguments too far.... | 14:32.21 |
| | Its like the difference between a Mac and a PC, with a Mac you know (fairly well and used ot know a lot better) whats in it. With a PC you're always guessing. | 14:33.09 |
| | We do allow you to use other sources if you really want to, we just say that we can't support you like that. | 14:33.27 |
| | So, since you have a problem, I'd suggest that you start by using source that works, rather than a hodg-podge of unknown vintage and provenance | 14:34.03 |
| chrisl | kens: sorry, was out for a bit....... | 14:40.08 |
| kens | S'ok | 14:40.14 |
| | was wondering if you know a way to capture a cups stream ? Can we write a 'GS' script using Tee or something ? | 14:40.36 |
| chrisl | We could, but I'm sure there's a better way - didn't add it to the FAQ? | 14:44.52 |
| kens | No idea ;-) | 14:45.03 |
| chrisl | BusError: there were several problems with how the CUPS device implemented the RIP_MAX_CACHE "feature" (hack, IMHO). It was changing the size of the page buffer, and then not actually telling Ghostscript what it had done, for one thing - and that caused a crash. | 14:47.57 |
| | kens: https://wiki.ubuntu.com/DebuggingPrintingProblems#Capturing_print_job_data | 14:49.31 |
| BusError | I'm using the latest stable of both cups & gs -- is it something that is fixed in unstable versions? | 14:50.05 |
| chrisl | Yes, fixed in GS in our git repos | 14:50.27 |
| kens | chrisl thanks, its for BusError, I'm suggesting he needs to capture teh CUPS input, and then use teh GS command line + CUPS to reproduce hte problem. | 14:50.48 |
| | I did also suggest using the current master since there are both ICC and CUPS fixes in it.... | 14:51.02 |
| | Before entering the hared libraries vs known working religious debate | 14:51.56 |
| chrisl | Yes, *and* ICC *with* CUPS fixes - there was at least one for how devcups uses ICC profiles...... | 14:52.00 |
| BusError | is there a huge delta from 9.04 <->master ? | 14:52.02 |
| kens | Define 'huge'. | 14:53.05 |
| | Git will show you which changes have been comiited since then. | 14:53.17 |
| | IMO the differences are not huge and are wortth having, you may not agree | 14:53.42 |
| BusError | just wondering if it's worth cherry picking, I like starting from a "stable" archive, otherwise you end up having no idea what was/not built etc | 14:54.49 |
| | I'll check the log | 14:55.04 |
| kens | Cherry-picking gets you into the problem where a fix relies on a previous fix, and it may not be obvious (weven to the original authour) | 14:55.18 |
| chrisl | BusError: I argue the opposite - if you cherry pick, you're dealing with totally untested code combinations - at least grabbing from our master, you have a git SHA1 key which has been tested. | 14:57.11 |
| marcosw_ | kens: ping to you | 16:06.03 |
| kens | aha marcos! | 16:09.03 |
| | I'm having trouble reproducing a problem. | 16:09.13 |
| | can you look at my last regression report ? | 16:09.23 |
| | on the dashboard | 16:09.31 |
| marcosw_ | kens: I have a meeting starting in a few minutes, but Ii'll take a look afterwards. | 16:16.59 |
| kens | thanks marcosw_ Its the seg faults I can't reproduce. | 16:17.19 |
| | If you can tell me how, that would be great. | 16:17.28 |
| | I think its the created PDF files causing the problem, so I need to know how to create those mainly | 16:17.51 |
| marcosw_ | probably need a 64 bit linux system :-) | 16:17.58 |
| Robin_Watts | kens: Have you looked in the logs to see the exact command line used? | 16:18.07 |
| kens | In that case, its probably not my fault. | 16:18.15 |
| | Robin_Watts : No, I started looking at something else | 16:18.37 |
| | In the hope it would fix both ;-) | 16:18.45 |
| Robin_Watts | kens: You can get to the logs from the dashboard. | 16:18.52 |
| kens | yes, but the missing text was a more obvious problem | 16:19.40 |
| BusError | has anyone managed to get mupdf to be used as a cups RIP ? | 16:29.35 |
| kens | It doesn't ouput CUPS foramt rasters. | 16:30.01 |
| BusError | well it outputs various other formats... and cups has an imagetoraster it seems... | 16:30.28 |
| Robin_Watts | BusError: tkamppeter is the cups expert. | 16:30.29 |
| chrisl_x100 | mupdf maxes out at 300 dpi, doesn't it - or has tor8 changed that restriction? | 16:39.27 |
| Robin_Watts | chrisl_x100: That's not an architectural limitation. | 16:39.46 |
| | (AFIAK) | 16:39.53 |
| BusError | I see it defined at 300 | 16:41.05 |
| | might have a try at using it... it's rendering is certianly "good enough" for normal use, and the footprint is nice | 16:42.45 |
| Robin_Watts | BusError: Presumably you'd be looking at pdfdraw ? | 16:43.14 |
| | There is a flag to that to tell it to halftone to black and white. | 16:43.25 |
| BusError | yeah... | 16:43.36 |
| ray_laptop | BusError: it probably would not be hard to add cups raster to mupdf, but the problem is that cups emits LOTS of settings as device parameters to Ghostscript for the 'cups' device. mupdf does not have a 'device parameter' concept in its architecture (much to Tor's relief I'm sure) | 16:57.15 |
| BusError | well, I could copy /some/ of the ones that make sense from gstoraster, and ignore the rest :-) | 16:58.45 |
| | just to see if it works... | 16:58.56 |
| ray_laptop | chrisl: I don't think mupdf has a 300 dpi limit | 16:58.57 |
| Robin_Watts | ray_laptop: It's possible that the viewer is set not to zoom further than that. | 16:59.24 |
| ray_laptop | Robin_Watts: I was thinking of the command line option for pdfdraw | 16:59.45 |
| Robin_Watts | ray_laptop: The problem may be that pdfdraw doesn't use banding. | 17:00.27 |
| BusError | yeah I was targetting pdfdraw... | 17:00.32 |
| Robin_Watts | and it renders in contone throughout and converts down at the end. | 17:00.39 |
| BusError | it does... or so the comment claims | 17:00.41 |
| ray_laptop | I thought pdfdraw _did_ support banded rendering | 17:00.58 |
| BusError | whoops... actualy the other comments says the contrary :> | 17:01.28 |
| Robin_Watts | Certainly the technologu supports it. I didn't think we'd hooked it up though. | 17:01.34 |
| chrisl_x100 | ray_laptop: in mupdf-0.8/apps/pdfapp.h "#define MAXRES 300" - I don't know about more recent releases | 17:02.02 |
| ray_laptop | consults the source | 17:02.07 |
| Robin_Watts | chrisl_x100: That's for the viewer. | 17:02.55 |
| chrisl_x100 | I couldn't get pdfraw to go higher either, but that was a while ago..... | 17:03.24 |
| ray_laptop | where's tor ? | 17:03.28 |
| Robin_Watts | And I see no banded support in pdfdraw, yet. | 17:03.30 |
| | (Though it would be pretty trivial to add). | 17:03.46 |
| | ray_laptop: While on the subject of banded rendering... | 17:03.54 |
| | I have a gs command line, using pamcmyk4 that gives different results on 32bit and 64bit linux. | 17:04.20 |
| | It includes -dMaxBitmap=10000 and -K1000000 | 17:04.48 |
| ray_laptop | I'm _sure_ that pdfdraw used to support rendering via bands -- tor probably ripped it out (the easiest way to address a bug report about banded rendering) | 17:04.50 |
| Robin_Watts | ray_laptop: It supports rendering via a display list... | 17:05.16 |
| | (Returning to the gs thread) It looks to me like the difference between 32 and 64bit linux results are down to banding being different. | 17:06.34 |
| | which means we get slightly different rounding in the tile_by_steps calls. | 17:06.51 |
| | and stuff shifts by a pixel. | 17:06.59 |
| ray_laptop | Robin_Watts: check the git log for mupdf... Fri Jun 25 01:57:29 2010 +0200 Clear the pixmap buffer between bands.... Wed Jun 23 16:34:10 2010: Automatically switch to using bands if the resulting image size is too large in pdfdraw | 17:07.03 |
| Robin_Watts | ray_laptop: Fair enough. | 17:08.15 |
| tor8 | chrisl_x100: the 300 dpi limit is only for the viewer, so we don't gobble up all available ram and then some when you zoom in since we're being dumb and rendering the whole page | 17:08.18 |
| ray_laptop | but maybe this is just for images encountered during the rendering to the page | 17:08.25 |
| | tor8: I see references to banding in 'pdfrip' -- did that go away ??? | 17:09.16 |
| Robin_Watts | ray_laptop: I was wondering if you had any insight into why there might be a difference between 32 and 64bit banding setups for the same params ? | 17:09.44 |
| tor8 | ray_laptop: I think we lost the banding for pdfdraw somewhere along the switch to the new display list, and I haven't put it back in. I should put that on my TODO list. | 17:10.03 |
| BusError | seesm that the rendering was moved out of there... ray_laptop the "drawpnm" refered in that commit is no longer there, so he must have made a more generic version... | 17:10.22 |
| tor8 | or robin_watts can cook it up on a slow day? | 17:10.24 |
| chrisl_x100 | tor8: I was sure I had to hack the code to test with 720 dpi a while back - I was some performance comparisons at the time | 17:10.28 |
| ray_laptop | Robin_Watts: Sorry, I'll drop mupdf (it is really frustrating that it is so poorly documented) and get back to your question | 17:10.31 |
| | Robin_Watts: so 'tile_by_steps' is the pattern painting, and that's where you are seeing a 32/64 bit diff ?? | 17:12.05 |
| Robin_Watts | will take mupdfs clear code/lack of documentation over ghostscripts wildly inaccurate/arcane/out of date docs any day :) | 17:12.08 |
| | tile_by_steps is being called to copy a pattern tile into the output, yes. | 17:12.46 |
| ray_laptop | Robin_Watts: I agree about not liking inaccurate docs | 17:12.48 |
| | Robin_Watts: and is this tiling from a clist or from a pattern bitmap ? | 17:13.15 |
| Robin_Watts | From a pattern bitmap. | 17:13.23 |
| | I can see the calls that are made to the tiling stuff; the tile is 64 pixels high or something. | 17:14.04 |
| ray_laptop | Robin_Watts: and are the bitmap tiles the same ? (i.e. the tile positioning differs) | 17:14.07 |
| Robin_Watts | and in one version it gets called with y=64, phase=0, and in the other it gets y=128, phase=64 or something like that. | 17:14.28 |
| | So yes, it's the tile positioning that differs. | 17:14.41 |
| | As far as I can tell, it's a perfectly reasonable rounding difference - it's the kind of thing we're never going to avoid if we're using floats. | 17:15.13 |
| | What interests me more is *why* it gets called differently in the 2 versions. | 17:15.34 |
| | All I can imagine is that the banding is set up differently for some reason. | 17:15.48 |
| | (is there a debug flag that shows how many lines per band etc?) | 17:16.12 |
| ray_laptop | Robin_Watts: in a debug build -Z: shows this | 17:16.32 |
| | Robin_Watts: but the default BufferSpace (which determines the default BandHeight) is the same between 32 and 64 | 17:18.02 |
| | Robin_Watts: you can force a particular band size using -dBandHeight=____ | 17:18.26 |
| Robin_Watts | Ok. On 64bit linux: | 17:18.44 |
| | [:]width=2479, band_width=2479, band_height=2564, nbands=2 | 17:18.55 |
| | On 32bit windows: | 17:19.01 |
| | [:]width=2479, band_width=2479, band_height=2572, nbands=2 | 17:19.13 |
| | (32bit windows and linux agree on the result, btw - I don't have a 32bit linux instance open to test there at the moment) | 17:19.41 |
| ray_laptop | Robin_Watts: ahh... The 'line_pointers' _are_ differenent between 32 and 64, and they are taken out of the BufferSpace and then the remainder is used for the band bitmap | 17:20.26 |
| Robin_Watts | ray_laptop: Right. | 17:20.35 |
| ray_laptop | so there are 2500+ pointers that are 8 instead of 4 bytes | 17:21.02 |
| Robin_Watts | Any chance we could always calculate line pointers as if they were 64bit ? | 17:21.08 |
| | It would mean that 32bit and 64bit banded mode would stand a chance of agreeing. | 17:21.37 |
| kens | heading off now, night all | 17:23.08 |
| Robin_Watts | also plank vs pamcmyk4 fails in some cases for a similar reason, I think. | 17:23.36 |
| ray_laptop | Robin_Watts: in base/gdevmem.c see 'gdev_mem_line_ptrs_size' (line 341) | 17:24.50 |
| Robin_Watts | Hmm. Forcing the bandheights to be the same with -dBandHeight=2500 doesn't solve it :( | 17:25.17 |
| ray_laptop | Robin_Watts: OK, well, that makes it at least easier to compare the tiling coordinates, right ? | 17:26.21 |
| Robin_Watts | ray_laptop: I'll put my debug code back in both versions in a mo. | 17:26.40 |
| ray_laptop | Robin_Watts: if we wanted to use 64-bit for the line pointer space and default band height calculation, we'd also have to fix 'gdev_mem_max_height' -- to places use sizeof(byte *) | 17:29.06 |
| | s/to places/two places/ | 17:29.17 |
| | Robin_Watts: it looks like the 'raster' alignment is also different. The 32-bit Windows ARCH_ALIGN_LONG_MOD is 4 and on 64-bit linux it is 8. | 17:33.12 |
| | Robin_Watts: see the chain of macros that make up 'bitmap_raster' in gxbitmap.h | 17:34.36 |
| Robin_Watts | OK, so it's clear to me that we should expect different band setups for the same memory on 32/64 bit setups. | 17:35.21 |
| | And it's clear to me that that will cause differences - just as well we only have 64bit cluster nodes, eh? | 17:35.44 |
| | What isn't clear to me, is why forcing the bandHeights to be the same should still give different results. Will look into that a bit more. | 17:36.12 |
| ray_laptop | Robin_Watts: yes, by default. We _could_ force the 64-bit alignment and the 8 bytes for the line_pointer space calculation, but ... | 17:36.21 |
| | Robin_Watts: did you make sure (with -Z:) that you were getting the same band height. The parameter is -dBandHeight= NOT -dbandHeights= | 17:37.18 |
| Robin_Watts | Yes, I mystyped there. | 17:37.34 |
| | I did make sure. | 17:37.38 |
| ray_laptop | Robin_Watts: OK. Just checking | 17:37.49 |
| | so at least we know what it is NOT | 17:38.10 |
| Robin_Watts | ray_laptop: No worries. I'd rather people pointed out possible obvious mistakes rather than me losing hours... | 17:38.23 |
| | I'm still seeing a difference in the tiling position. | 17:41.02 |
| ray_laptop | Robin_Watts: or rather, it is not simply the BandHeight. | 17:41.03 |
| Robin_Watts | [T]i=-1 j=3 x,y=(151,155)=>(151,170) w,h=(-26,1) x/yoff=(0,15) | 17:41.17 |
| | on linux, but on windows: | 17:41.22 |
| | [T]i=-1 j=3 x,y=(151,154)=>(151,170) w,h=(-26,1) x/yoff=(0,16) | 17:41.34 |
| | I'll look more later. | 17:43.23 |
| | I have to pop out for a bit. If mvrhel2 appears, tell him I have a fix for 692569 I'd like to check with him. Thanks. | 17:44.36 |
| ray_laptop | Robin_Watts: OK. I'll leave it up to you. ping me if you want to chat (and if I'm not online, ask someone to call me) | 17:44.41 |
| Robin_Watts | ray_laptop: Thanks. | 17:44.50 |
| greycat | ghostscript 9.04, HP-UX 11.11. gs -dNOPAUSE -sOutputFile=xxx -g612x792 -r72.0x72.0 -sDEVICE=pswrite greg-input -c quit gives me 'gsicc_set_profile(): allocation of profile default_gray.icc handle failed' and ''gsicc_init_iccmanager(): cannot find default icc profile' and dumps core. | 18:35.28 |
| | Is there a second step needed to install these profiles/resources that isn't covered by "make install"? | 18:36.07 |
| Robin_Watts | greycat: No. | 18:40.59 |
| | By default, i think we set COMPILE_INITS=1, which means the profiles should get built into the binary. | 18:41.31 |
| | If you're building with COMPILE_INITS=0 then they are looked for on disc. | 18:41.51 |
| greycat | gs --help says "Initialization files are compiled into the executable." among other things, but I don't know if that covers the icc profiles | 18:42.09 |
| Robin_Watts | I would think it should. | 18:42.24 |
| ray_laptop | greycat: Robin_Watts: yes, the 'iccprofiles' directory is copied into the %rom%iccprofiles/ internal | 18:46.28 |
| greycat | any ideas why it's failing to find them, and then dumping core? | 18:46.56 |
| | --help says the search path includes %rom%Resource/Init/ and %rom%lib/ but I don't see %rom%icprofiles/ on there | 18:48.14 |
| | err, iccprofiles | 18:48.23 |
| ray_laptop | greycat: the first message comes when an allocation fails | 18:48.35 |
| | greycat: it's not supposed to dump core, but just to exit | 18:49.11 |
| | i.e., return error code -1 which is unrecoverable | 18:49.39 |
| | greycat: but as to why the call to 'gsicc_get_profile_handle_buffer' is returning NULL, I couldn't say. | 18:50.54 |
| | greycat: do you get a prompt when you just do: gs -sOutputFile=xxx -g612x792 -r72.0x72.0 -sDEVICE=pswrite | 18:53.32 |
| greycat | No. Same two lines of errors and core dump. | 18:53.58 |
| ray_laptop | greycat: please open a bug and tag it for component 'Color' (it'll be assigned to mvrhel) | 18:55.12 |
| Robin_Watts | Is Michael travelling back today? | 18:55.34 |
| ray_laptop | Robin_Watts: don't know, offhand | 18:55.54 |
| | Robin_Watts: ha. beat you to the cluster :-) | 18:56.52 |
| | finally getting around to fixing the pnglapha bug | 18:57.22 |
| ray_laptop | can't type today :-( | 18:57.34 |
| BusError | ok mupdf generates pretty clean 1 bits halftone, you just have to ask for a pbm output | 19:02.36 |
| | mupdf/pdfdraw that is | 19:02.58 |
| Robin_Watts | BusError: I know. I wrote the code :) | 19:10.36 |
| BusError | I'm just diving a bit into it here :-) | 19:11.22 |
| ray_laptop | Robin_Watts: does that use threshold array or FS screening ? | 19:11.37 |
| Robin_Watts | threshold array. | 19:11.46 |
| ray_laptop | crud. looks like peeves temp is full. I'll fix it now... | 19:13.04 |
| greycat | ah, it's compiling with -O instead of -g ... that's why gdb can't find anything. | 19:15.13 |
| Robin_Watts | reboot. bbs. | 19:17.23 |
| alanh | hi all | 22:27.57 |
| | trying to statically link ghostscript | 22:28.11 |
| | but base/sha2.c symbols conflict with ones from /usr/lib/libcrypto.a | 22:28.26 |
| | Forward 1 day (to 2011/10/11)>>> | |
IRC Logs