| | <<<Back 1 day (to 2012/07/10) | 2012/07/11 |
| scott_b | Robin_Watts: I just read up on the Mitchell filter and it's all about UPscaling quality. My test of ImageMagick 15 or so filters concluded the simple box filter is best and fastest for downsampling. My test image was a blueprint sheet with text and lines. I don't know how cpu intensive the Mitchell filter is but if it doesn't fall back to a simple box filter when output is less than input, it may be wasting a lot of cycles. | 01:48.53 |
| ray_work | scott_b: Yes, I totally agree | 01:49.45 |
| | IMHO, downscaling (at least past 2:1) is fine with nearest neighbor | 01:50.36 |
| | IMHO, the Mitchell filter (and other digital filter derived methods) are for upscaling | 01:52.39 |
| scott_b | Robin_Watts: I've been trying to digest what you mean by min(1, x/f). Since the output is grey, starting with box filter x/(f*f) and then saying if x > 0 and less then minimum make it minimum. (that may be exactly what you meant.) That would make sense. | 01:53.00 |
| | ray_work: Yes, and since you would take an icon and upscale it to match printer res and take a huge image and downscale it to screen res, when you are downscaling is not the time to do unnecessary work since the pixel count is huge. When upscaling, the pixel count is very small (in comparison) so you can usually afford to spend more cycles per pixel. | 01:54.58 |
| chrisl_away | .away | 06:25.21 |
| kens | Robin_Watts : tor8 maybe one of you would like to comment on: | 08:10.41 |
| | http://stackoverflow.com/questions/11396951/editing-a-pdf-with-mupdf | 08:10.41 |
| chrisl | Geez, if he can't work it out from the example apps, I don't fancy his chances of implementing it himself anyway | 08:15.35 |
| kens | Sure, but I thought an answer wold be nice, because Google returns hits when people are searching | 08:16.08 |
| | And I don't feel competent to answer it myself :-) | 08:16.26 |
| chrisl | kens: So how was NY? Was it so good that it explains why they named it twice? | 08:16.51 |
| kens | It was too hot.... | 08:19.08 |
| chrisl | That does not surprise me! | 08:19.31 |
| kens | Melanie enjoyed the shopping, seems to have been the highlight of the trip | 08:19.31 |
| | Apparently teh whole of the US (pretty much) is enduring a heat wave right now | 08:19.54 |
| chrisl | I think that's one of the causes of the fires over henrys's way | 08:20.26 |
| kens | Yes I think so | 08:20.34 |
| chrisl | I'd be happy to package up some of our rain, and send it over :-( | 08:20.48 |
| kens | It meant that the temperature on Saturday was ~38 degrees, I think they would welcome a break.... | 08:21.01 |
| | It did return to seasonal average on Monday in NY, only 28 degrees | 08:21.27 |
| chrisl | Even 28 is probably pretty unpleasant in the city | 08:22.06 |
| kens | It was OK, 38 was too much though | 08:22.16 |
| | Apparently the record July temp in NYC is 39 | 08:22.31 |
| chrisl | Yeh, that's down South levels - don't want that! | 08:22.48 |
| kens | Its why I was online Saturday, STella & Melanie went shopping (by hopping from one air-conditioned shop to the next) while I stayed i the cool dark hotel lobby and used the free WiFi | 08:23.46 |
| chrisl | Very wise - I think I'd hate the shopping even more than the heat..... | 08:24.33 |
| kens | Me too :-) | 08:24.43 |
| | Apparebtly they decided they didn't want me with them under the circumstances | 08:25.06 |
| chrisl | Probably didn't want you tutting away about the amount they were spending ;-) | 08:25.41 |
| kens | That's possible too..... | 08:25.57 |
| | Melanie's luggage came back 4 kilos heavier than on the way out | 08:26.12 |
| chrisl | And I don't think NY shops charge by the kilo! | 08:26.47 |
| kens | Menatime the check-in staff kept asking me if my checked luggage was my cabin bag. | 08:27.03 |
| tor8 | kens: okay, answered to the best of my knowledge | 08:32.57 |
| kens | Thanks tor8 | 08:37.44 |
| | Time to go | 09:23.17 |
| | back later | 09:23.21 |
| Robin_Watts | Apparently a US airlines flight 'sunk' into the softened runway at reagan international airport yesterday due to the heat. | 09:49.33 |
| tor8 | Robin_Watts: I'm off to my sisters birthday, I'll be AFK most of the rest of the day. If there's anything urgent, drop me an SMS. | 11:22.52 |
| Robin_Watts | tor8: will do. have fun. I'm buried in gs today :( | 11:23.41 |
| Robin_Watts | just buys $1400 of camera equipment and has it delivered to marcos. | 12:01.46 |
| | That's a camera + 2 lenses, which works out at £848 quid. The camera body alone would cost £800 here. This whole exchange rate thing for consumer electronics just takes the piss. | 12:03.17 |
| kens | Its not new, been ging on for ages | 12:03.42 |
| chrisl | Robin_Watts: what's the camera, then? | 12:03.51 |
| Robin_Watts | yeah, but this is the worst example I've seen. | 12:03.56 |
| | Canon 650D. | 12:03.59 |
| | (and the 2 STM lenses) | 12:04.03 |
| chrisl | I didn't really get on with the Canon DSLRs I looked at - they seemed quite lens heavy to me. | 12:05.13 |
| Robin_Watts | More so than any other DSLR ? | 12:05.35 |
| | I've been using a canon SLR since I was 21, so I'm used to the heft. You can try the 650D with the lovely 40mm pancake lens at the meeting. Stupidly thin :) | 12:06.48 |
| chrisl | Yeh, I opted for a "budget" model Nikon which felt better balanced to me. It's all personal, though | 12:07.08 |
| Robin_Watts | Ah, once you've used a Nikon, you can never swap to a canon or vice versa. | 12:08.17 |
| | Zoom rings work in opposite directions :) | 12:08.26 |
| chrisl | My previous SLR was a Praktika (forget the model) - decidedly Soviet build quality (like a tank!) | 12:08.47 |
| Robin_Watts | There were some cameras like like that had such a shutter 'click' that the whole camera would shake. | 12:10.17 |
| | I'm crap enough about holding a camera steady anyway. | 12:10.38 |
| chrisl | Yeh, the Praktika is like that. Luckily the rest of the body is hefty enough that it does have too bad an effect | 12:12.44 |
| | What I'd really like is a digital "back" for my dad's Nikon F, but they only do that kind of thing for medium format cameras. | 12:13.45 |
| Robin_Watts | Morning mvrhel_laptop | 12:16.50 |
| mvrhel_laptop | morning Robin_Watts | 12:17.01 |
| | hmm interesting comments in the logs about using nearest neighbor for down scaling. I disagree with that. Aliasing artifacts will occur often | 12:18.11 |
| Robin_Watts | from ray? yes, I absolutely agree. | 12:18.27 |
| | downscaling with filtering is more important that upscaling with filtering. | 12:18.43 |
| mvrhel_laptop | yes I agree | 12:18.48 |
| Robin_Watts | Both gs and mupdf now use the same algorithm for downscaling, and it gives good results. | 12:19.34 |
| mvrhel_laptop | yes. I thought you had done work on that | 12:19.49 |
| Robin_Watts | mupdf never filters when upscaling though. | 12:19.52 |
| | (It could, but we've disabled it) | 12:20.02 |
| | image_render_interpolate_icc vs mage_render_interpolate | 12:21.00 |
| | When is the latter ever called these days ? | 12:21.05 |
| mvrhel_laptop | hold on, need to look at code | 12:21.41 |
| chrisl | For UseFastColor, at least? | 12:22.22 |
| mvrhel_laptop | no. UseFastColor is actually just a different CMM and is opaque to the graphics library | 12:22.58 |
| Robin_Watts | Looks to me like I'd need to get into this routine with a bpp that is >8 and != 16. | 12:23.25 |
| | or not have a profile loaded. | 12:23.35 |
| chrisl | Oh, okay - I seem to remember seeing it being called, but that may have been a bug | 12:23.58 |
| Robin_Watts | so "practically never" | 12:24.02 |
| chrisl | Robin_Watts: make it return an error, and do a clusterpush? | 12:24.27 |
| Robin_Watts | chrisl: Cunning. | 12:24.38 |
| chrisl | ;-) | 12:25.01 |
| mvrhel_laptop | I think the sep device uses the non icc method | 12:25.23 |
| Robin_Watts | tifsep ? | 12:25.39 |
| mvrhel_laptop | yes. and psdcmyk. also cups | 12:25.47 |
| | if(!gx_device_uses_std_cmap_procs(penum->dev, penum->pis)) { use_icc = false; } | 12:26.04 |
| Robin_Watts | mvrhel_laptop: OK. I'll (try to) get it working for the icc case, then port it back across. | 12:26.07 |
| mvrhel_laptop | if we have non standard procs | 12:26.16 |
| | since in that case we have to go through the special device procs | 12:26.39 |
| | and cant transform a buffer all at once | 12:26.51 |
| | color transform that is | 12:27.39 |
| | chrisl: I think that patch will be OK for Bug 693176. Does it pass the clusterpush? | 12:32.26 |
| chrisl | mvrhel_laptop: yes, it passes the cluster. I want to spend a little more time on it - if possible, I'd like to understand why COMPILE_INITS has an effect on it | 12:37.46 |
| mvrhel_laptop | right. that is a puzzle | 12:38.13 |
| chrisl | Having said that, I don't plan to spend a lot more time on it, as I think righting the profile out there is the right thing to do, now, anyway | 12:38.56 |
| | s/righting/writing | 12:39.10 |
| mvrhel_laptop | yes | 12:39.16 |
| tkamppeter | mvrhel_laptop, so is the patch for bug 693176 OK? Can I use it in the Ubuntu packages? | 13:12.10 |
| mvrhel_laptop | tkamppeter: if chrisl commits it then yes | 13:25.19 |
| tkamppeter | mvrhel_laptop, but seems that chrisl did not commit it yest, as the bug is ot closed and no commit reference is there. His last words there are only asking you whether the patch is OK. | 13:42.56 |
| mvrhel_laptop | and I talked to him about it above tkamppeter | 13:43.17 |
| | it is likely that it will be committed, but that is up to him | 13:43.40 |
| chrisl | tkamppeter: I will almost certainly commit the change by the end of the day - a little patience would not go amiss! | 13:44.31 |
| tkamppeter | chrisl, sorry. | 13:50.44 |
| chrisl | tkamppeter: I'm almost certain that fix is correct, the only niggle for me is why COMPILE_INITS made a difference - my feeling is that it shouldn't have | 13:53.32 |
| alexcher | I'm going to move gc flag into the main instance (minst). Does anybody have any objections or comments? | 13:54.54 |
| Robin_Watts | alexcher: I'm not sure how that solves the problem. | 13:55.28 |
| | The problem, AIUI, is that spaces hold a pointer to a variable, and we fail to clear those pointers out when that variable falls out of scope. | 13:56.13 |
| | You're proposing to put that variable somewhere else, right? | 13:56.49 |
| | Does that mean it will never fall out of scope, so the pointers will never need to be cleared out ? | 13:57.13 |
| | Or are you proposing to put the pointers in the main instance, rather than in every space ? | 13:57.55 |
| alexcher | Robin_Watts: Yes, minst is in stable memore and never goes out of scope. | 13:57.58 |
| Robin_Watts | OK, so I can see that will kind of work. | 13:58.28 |
| | It doesn't feel neat though. | 13:58.38 |
| chrisl | alexcher: did we establish whether the interpreter context actually changes (rather than moves) during gs_call_interp()? | 13:58.41 |
| Robin_Watts | Do the spaces all share a pointer to some underlyign object anyway? | 13:59.05 |
| alexcher | Robin_Watts: yes, all spaces point to the stack. | 13:59.37 |
| Robin_Watts | I've just had a quick look at the code, and it looks to me that all spaces have a gs_lib_ctx pointer. | 14:00.01 |
| | Can we not put the gc_signal variable in there? | 14:00.16 |
| | Then none of the spaces need to hold a pointer to the variable at all. | 14:00.35 |
| | They can just write to mem->gs_lib_ctx->gc_signal, which seems neater to me. | 14:00.56 |
| | (or at worst, we can only have to hold 1 pointer to a variable, rather than n) | 14:01.17 |
| alexcher | Robin_Watts: I need to check how gs_lib_ctx is allocated. | 14:01.34 |
| Robin_Watts | I have to pop out for a bit. bbs. sorry. | 14:01.44 |
| | alexcher: I'm sure you'll find a neat solution. | 14:01.53 |
| alexcher | chrisl: I still don't have a full picture. | 14:03.05 |
| chrisl | alexcher: it's strange because this has clearly been thought about, given the comment at line 463 in interp.c...... | 14:04.11 |
| Robin_Watts | I suspect this code predates us having a central lib_ctx. | 14:05.38 |
| | so having a single pointer wasn't an option before. | 14:05.57 |
| | possibly it also predates us changing spaces. | 14:06.28 |
| chrisl | That doesn't explain *how* the dangling pointers remain, though | 14:06.37 |
| Robin_Watts | set_gc_signal runs through the current set of spaces setting the pointer. | 14:07.06 |
| | If we use it to set a pointer, then we change the current set of spaces (remove one), then set_gc_signal to NULL, the space we removed will still have the pointer set. | 14:07.46 |
| chrisl | If we remove a memory space, surely it should then disappear and play no part in GC..... | 14:08.15 |
| Robin_Watts | chrisl: I was thinking that we might 'replace' one space with another? | 14:08.30 |
| chrisl | We can't be left with inaccessible spaces | 14:08.45 |
| Robin_Watts | i.e. we might have space A, then replace that with space B, the idea being we'd work with space B for a while, then destroy it and put space A back in? I admit that all this is way out of my comfort zone though. | 14:09.33 |
| chrisl | But then, we'd still have access to A in order to get it back again | 14:10.03 |
| Robin_Watts | but might A not be one of the spaces indexed by the context for a while? | 14:11.30 |
| chrisl | But we'd still need a record of it *somewhere* | 14:12.00 |
| | In which case, the bug would be that set_gc_signal() wasn't traversing that list of dormant memory spaces to null out the pointer | 14:13.04 |
| Robin_Watts | Right. | 14:14.15 |
| | But by moving the pointers from being one per space to being just having 1 in the gs_lib_ctx, we'd sidestep the problem entirely. | 14:14.41 |
| | because rather than going space->gc_signal, we can go space->lib_ctx->gc_signal | 14:15.32 |
| chrisl | Robin_Watts: sure, the only thing with that is that it means putting interpreter specific information in the lib context | 14:15.46 |
| Robin_Watts | and it doesn't matter how many spaces we create/destroy etc. | 14:16.02 |
| | It does mean that, yes. | 14:16.12 |
| chrisl | But that's a minor thing, IMHO..... | 14:16.28 |
| Robin_Watts | Although I think you can argue that the gc mechanism is lib level rather than interpreter level. | 14:16.54 |
| chrisl | Robin_Watts: it's in psi, although there's a fair amount of supporting stuff in base, too | 14:17.43 |
| | Oh, but I think gs_lib_ctx might be movable..... | 14:17.51 |
| Robin_Watts | Well, presumably the code must cope with that being moved already. | 14:18.26 |
| chrisl | Yes, of course, sorry I was thinking of the current setup with a pointer to the flag - doh! | 14:18.56 |
| | alexcher: would it be a lot of work to have the memory spaces all work off one flag in gs_lib_ctx, or minst or wherever? | 14:20.00 |
| alexcher | chrisl: we can just pass a different pointer to set_gc_signal() | 14:21.38 |
| chrisl | alexcher: I was thinking about Robin_Watts's suggestion about doing away with the per memory space pointer. | 14:22.37 |
| Robin_Watts | We can still pass the same pointer to set_gc_signal. The point of this exercise is to reduce set_gc_signal from being a loop over spaces, to being a single set within lib_ctx. | 14:22.51 |
| alexcher | chrisl: The changes that use minst are quite simple. I need to lokk more into gs_lib_ctx case. | 14:23.00 |
| chrisl | alexcher: I think it would be "nicer" if we could dispense with each memory space having it's own pointer to the flag (and so have them access it directly in one of the contexts), *but* that's an aesthetic thing, rather than functional | 14:26.21 |
| | alexcher: in other words, probably not worth it if it would be a lot of extra effort...... | 14:27.00 |
| Robin_Watts | My feeling is that it's an overall simplification to the code, but alex is the man on the spot, so I'll defer to his judgement. | 14:29.57 |
| chrisl | huh, I can't actually see where signal_value is actually used....... | 14:37.28 |
| alexcher | chrisl: It's assigned back to ticks_left in interp(). | 14:44.24 |
| chrisl | alexcher: I mean I can't see where the memory spaces actually use dereference the pointer - mem->gc_status.psignal | 14:50.19 |
| | tkamppeter: patch for Bug 693176 committed. | 14:59.26 |
| | alexcher: I guess what I'm wondering is whether the mem->gc_status.psignal pointer is actually required any more..... | 15:00.39 |
| tkamppeter | chrisl, thank you very much, will put it into Ubuntu Quantal and also as update into Precise. | 15:04.33 |
| chrisl | tkamppeter: np - it was certainly a strange one! | 15:05.04 |
| Robin_Watts | chrisl: Remove the set of the pointer and clusterpush :) | 15:49.39 |
| | Or better, set it to be 1 :) | 15:49.46 |
| karl_heinz | on a scale of 1 to 10, how much does working with PDF suck | 15:50.24 |
| chrisl | karl_heinz: 12...... | 15:50.39 |
| Robin_Watts | karl_heinz: Compared to working with pcl? | 15:50.47 |
| karl_heinz | I've never done anything with pcl, and have done only a little with PDF, but it really is a pain from what I can tell | 15:51.20 |
| chrisl | Robin_Watts: pcl isn't even on the same scale! | 15:51.28 |
| ray_laptop | karl_heinz: the mupdf "pdfclean -d" helps with PDF's because it makes the PDF readable (or gs's toolbin/pdfinflt.ps) | 18:11.27 |
| | karl_heinz: for PCL you _really_ need the PCL disassembler | 18:11.42 |
| Robin_Watts | ray_laptop: He wasn't working with pcl at all. That was just me making a point. | 18:12.15 |
| ray_laptop | karl_heinz: the biggest 'gotca' with PCL is the horrible state of the spec. At least PDF has a decent spec (at least up until ISO got control of it) | 18:12.47 |
| Robin_Watts | Sections of the PDF spec are pretty poor too. | 18:13.07 |
| ray_laptop | Robin_Watts: Just commenting in case anyone ever is fool enough to dig into PCL (that's what henrys is for) | 18:13.31 |
| Robin_Watts | The major problem with PDF is that they didn't say "you do it like this", they said "you can do this, or this, or this, ooh, or this..." | 18:13.32 |
| ray_laptop | Robin_Watts: true that it has a lot of flexibility in creating PDF docs that complicate a reader, but make it easier for a writer. Of course, it make it possible for a writer to make horrible PDF's (e.g. Cairo) | 18:14.50 |
| brennan | hello all | 18:34.17 |
| Robin_Watts | hi. | 18:35.27 |
| brennan | Question: I am playing around with mupdf, and can successfully extract png files based on page number, but what I'm trying to do is extract a range of pages to a separate pdf | 18:36.07 |
| | any suggestions? | 18:36.10 |
| Robin_Watts | mubusy clean in.pdf out.pdf 1-10 | 18:36.35 |
| | Depending on what version of mupdf you are using you may want to use: | 18:37.05 |
| | pdfclean in.pdf out.pdf 1-10 | 18:37.15 |
| | or mupdfclean in.pdf out.pdf 1-10 | 18:37.22 |
| | The tool has changed names a few times. | 18:37.35 |
| brennan | Ah I see the clean tool in my dir, one moment! | 18:37.48 |
| | Success. Any known issues with various pdf versions? I'm going to check out the bug reports next | 18:38.53 |
| Robin_Watts | pdfclean is not perfect. | 18:40.15 |
| | Just yesterday I found a file it barfed on. | 18:40.31 |
| | I haven't had time to look into why yet. | 18:40.39 |
| brennan | i had been using another library, and some it just barfed all over on | 18:41.02 |
| | (pdftk) | 18:41.36 |
| ray_laptop | brennan: if you have a file that mupdfclean barfs on, please try it with gs (so we can make sure we can handle it): e.g, gs -sDEVICE=pdfwrite -o out.pdf in.pdf | 18:43.22 |
| | brennan: or: gs -- toolbin/pdfinflt.ps in.pdf out.pdf (this will inflate the output, but we'd also like to know if it chokes) | 18:44.19 |
| brennan | in my testing at the moment, the files that pdftk barfed on, work with mupdfclean... | 18:44.53 |
| ray_laptop | brennan: or you can just open a mupdf bug and our main support guy will try it with gs | 18:45.03 |
| brennan | brb | 18:45.07 |
| | awesome | 18:47.25 |
| ray_laptop | ugh. This isn't good. valgrind reports several times: | 18:47.30 |
| | ==22771== Address 0xd5ac9b8 is 0 bytes after a block of size 4,000,120 alloc'd | 18:47.32 |
| | ==22771== at 0x4C25153: malloc (vg_replace_malloc.c:195) | 18:47.33 |
| | ==22771== by 0x9B3BD7: gs_heap_alloc_bytes (gsmalloc.c:183) | 18:47.35 |
| | have any of you ever seen this before (i.e., is it a false positive). Note the 'bytes after a block of size' offset is different, but it always seems to be the same size block | 18:48.36 |
| henrys | ray_laptop:I haven't seen that one, no - are you allocating the framebuffer? | 18:53.00 |
| Craigwd_2000 | I'm running PPC Mac OS X 10.5.8 on a Mid-April 2006 eMac with DL SuperDrive w/ 160 GB HD that I upgraded to 2 GBs of RAM (I know it's a Mid-April 2006 eMac because when I restored it using its Restore DVD it said in the Apple Setup Assistant/Wizard that it was registered to a a school in HI & coconutIdentityCard said it was built on April 12th of 2006...). I'm planning on trying to use a HP LaserJet 6L with the GPL Ghosts | 18:54.44 |
| | 8.71 binary that I downloaded from openprinting.org & I was wondering if it was built with the ljet4/ljet4dither built-ins enabled/how do I check that or do I just need to hack together two more .PPD files for the drivers built-into GPL Ghostscript itself...? | 18:54.44 |
| henrys | bbiab | 18:55.44 |
| ray_laptop | Craigwd_2000: you can see what devices are built in to gs with: gs -h | 18:58.43 |
| Craigwd_2000 | Ray_laptop: Thanks for the command/hint there... | 18:59.19 |
| | Ok: It appears I have lj4dith installed/enabled but I'm probably missing/need to create its PPD & the OpenPrinting site provides no pre-generated .PPD file for it or anything at all so I might need some help here... | 19:01.38 |
| ray_laptop | Craigwd_2000: 8.71 is pretty old, but AFAIK ljet4 is usually built in, but I don't know of a "ljet4dither" (there is a "lj4dith" that is usually built-in as well, I think) | 19:03.44 |
| | Craigwd_2000: the lj4dith uses Floyd Steinberg error diffusion which sometimes doesn't image too well on laser printers. It it usually for ink jets | 19:04.43 |
| Craigwd_2000 | I might even have V. 9.05 of GS installed via a pre-release MacTex 2012 GPL Ghostscript 9.05 .dmg file too though... :) | 19:06.48 |
| brennan | any ideas on what mupdf costs? | 19:07.15 |
| Robin_Watts | brennan: We have a range of different schemes. | 19:14.21 |
| | traditionally we've licensed per copy sold, but that works poorly when people want to give away apps using mupdf and then make money by selling content. | 19:14.51 |
| | So, your best bet is to contact Scott Sackett (scott.sackett at artifex.com) and talk to him. | 19:15.24 |
| ray_laptop | brennan: as henrys mentioned to you yesterday, please contact Scott.Sackett@artifex.com | 19:15.32 |
| brennan | I wasn't in yesterday? | 19:15.49 |
| Robin_Watts | He'll fire back a terrifying list of questions at you, but just answer them as best you can. | 19:15.53 |
| brennan | Just found mupdf a few hours ago :) | 19:16.02 |
| ray_laptop | brennan: sorry -- I thought it was you. My bad | 19:16.15 |
| Robin_Watts | brennan: Someone else was, and asked the same question. I think ray is confusing the two of you :) | 19:16.15 |
| brennan | oh okay. sorry ! | 19:16.28 |
| ray_laptop | Robin_Watts: is mem_planar_fill_rectangle_hl_color yours or mvrhel's ? | 19:16.49 |
| | mvrhel_laptop: RU here ? | 19:16.55 |
| Robin_Watts | hl_color = mvrhel. | 19:17.03 |
| ray_laptop | Robin_Watts: that's what I thought. Thanks. | 19:17.20 |
| | I found something TOTALLY bogus in it -- hard to tell how it ever worked | 19:17.45 |
| Robin_Watts | brennan: Talk to scott and hopefully you can find a licensing scheme that works for both of us. | 19:17.49 |
| | ray_laptop: It's really new code, so such things are not entirely suprising. | 19:18.20 |
| brennan | Sent him an email | 19:18.23 |
| Robin_Watts | fab. | 19:18.27 |
| brennan | Honestly just looking to use internally, on a limited number of machines | 19:18.46 |
| Robin_Watts | And GPL use is no good to you? | 19:19.02 |
| Craigwd_2000 | No: Ray_laptop: apparently according to the Docs. that I read on the openprinting.org site Ghostscript either used to or still does contain a ljet4 & ljet4dither driver for the HP LaserJet 4/4M/4M Plus/4 Plus that's known to also drive the LaserJet 6L that I own too... | 19:19.26 |
| Robin_Watts | GPL says you can do what you like internally. It's the moment you distribute it to anyone else that you have problems. | 19:19.53 |
| brennan | oh perfect | 19:19.58 |
| ray_laptop | brennan: the other thing some companies get from us that just use it internally is a support contract | 19:20.56 |
| brennan | I will look into that. Thanks! | 19:21.11 |
| ray_laptop | brennan: you can still report bugs, but it gives your bugs priority in being handled | 19:21.40 |
| brennan | ray_laptop: thanks for you all your help. I'm sure I will be back | 19:22.49 |
| Craigwd_2000 | According to their info your best bet is to use the ljet4dither driver which gives you true/real 1200 by 1200 Resolution printouts at the cost of using a lot more tonor too though... | 19:23.30 |
| ray_laptop | Robin_Watts: mvrhel_laptop: the mem_mapped_fill_rectangle_hl_color was not converting the 'rect' values to int before passing them to the device's fill_rectangle | 19:24.00 |
| Robin_Watts | That would seem... suboptimal. | 19:24.31 |
| ray_laptop | Robin_Watts: yeah, it apparently was the cause of scribbling where we should not. | 19:25.22 |
| | cured my 'blocker' SEGV | 19:25.53 |
| Robin_Watts | Fab. | 19:26.07 |
| ray_laptop | re-runnng valgrind to see if there are any more "Invalid write" issues | 19:26.31 |
| Craigwd_2000 | I did however happen to see a device for GS with the name of ljet4d which may actually in reality be a shortened form of the much longer ljet4dither/deprecated/old fashioned name... :) | 19:29.03 |
| ray_laptop | bbiab | 19:46.18 |
| mvrhel_laptop | ray_laptop: that commit was a lot of code. not surprised that there was/is an issue. | 19:56.52 |
| | thanks for finding the issue | 19:57.05 |
| ray_work | mvrhel_laptop: I am surprised that it didn't cause more problems. | 20:01.11 |
| mvrhel_laptop | me too. | 20:01.40 |
| ray_work | I suspect there is a problem in the planar fill_rectangle as well since it was writing out of bounds when it got those (huge) bogus w, h values | 20:02.08 |
| | I'll have a look into that before committing | 20:02.25 |
| | mvrhel_laptop: also I'm surprised that Windows didn't gripe about it. | 20:02.45 |
| | which I will also have a look at | 20:02.54 |
| scott_b | Robin_Watts: I'm trying to wrap my mind around the stream process so I can be of some help. This is what I've figured so far, please correct if I'm wrong: fz_open_faxd returns a stream which when 'ran' (or read from) returns one row at a time. In pdf_open_image_decomp_stream, we can insert our new downsampling filter, which will return fewer and shorter rows instead of the full res (to the caller which is building the full image). The way we install the | 20:12.52 |
| Robin_Watts | scott_b: Sounds good so far. I'm just going to dinner, but will read the logs when I get back. | 20:16.54 |
| scott_b | :) | 20:18.52 |
| ray_work | Craigwd_2000: the (probable) reason that using 1200x1200 uses more toner is that the dither pattern does not take into account 'dot gain' (the actual dot imaged is MUCH larger than 1/1200" square). This also makes lighter shades in images darker. | 20:38.51 |
| | Craigwd_2000: transfer functions can take care of these, as well as using halftones (stochastic or ordered) that are pre-linearized for a certain device. The latter is better since it provides 256 levels | 20:40.25 |
| scott_b | Robin_Watts: it looks like the description of a stream, eg: 'Open a stream for reading uncompressed data.' is describing the output of the stream (what is read from it) as opposed to what it is reading. This makes sense as I start to understand streams but was confusing at first. | 20:42.18 |
| ray_work | Craigwd_2000: this avoids large steps in the lighter shades when a transfer function is used that tends to map many shades of the source image to just a few shades attainable with the halftone pattern | 20:42.24 |
| brennan | hey all, i'm back :) | 20:47.03 |
| | question: The mupdfclean does a fantastic job, handling all of the problem pdfs i've thrown at you | 20:48.08 |
| | is there a command line utility for merging two pds.. say "Big.pdf" then adding "small.pdf" to the end of it | 20:49.15 |
| henrys | Craigwd_2000:the "d" ljet4d is for duplex. | 20:49.44 |
| Robin_Watts | brennan: Not yet. | 20:50.22 |
| scott_b | If the same utility had the option to read a multipage and write separate pdfs, I think some of my customers could use that. | 20:51.53 |
| Robin_Watts | scott_b: Call pdfclean multiple times. | 20:53.20 |
| scott_b | Robin_Watts: I guess now I need to get familiar with git so I can start to create a patch against the latest. I'm proficient with subversion but haven't used git. | 20:55.02 |
| brennan | any recommendations on a separate utility to merge/append? | 20:55.02 |
| Robin_Watts | scott_b: Git rocks. But attempting to use git believing it to be a "better subversion" is doomed to fail. | 20:55.42 |
| | I recommend reading at least the first few chapters of progit. It's available on the net. | 20:56.02 |
| | http://git-scm.com/book/ | 20:56.23 |
| scott_b | thx | 20:56.34 |
| Robin_Watts | brennan: We have no tools to merge yet, | 20:57.40 |
| | except for gs. | 20:57.51 |
| brennan | ah | 20:58.06 |
| Robin_Watts | gs -sDEVICE=pdfwrite -o out.pdf in1.pdf in2.pdf in3.pdf etc. | 20:58.12 |
| | but that will lose you stuff like structural information, etc. It just keeps the contents. | 20:58.45 |
| brennan | I'm generally dealing with paperwork that has been faxed to pdf, so that wouldn't matter as much | 21:05.10 |
| scott_b | Robin_Watts: I'll try my hand at getting a stream filter defined. For structure, which module would be the best place to put it? And is there a simple but efficient box filter function anywhere? (x/(f*f)) | 21:33.13 |
| Robin_Watts | scott_b: Either I'd create it in the same file as the function it's being used it, or I'd create a new file alongside that one. | 21:34.03 |
| Robin_Watts | gets something that's not completely broken, and therefore decides to call it quits for the night. | 21:34.45 |
| karl_heinz | sometimes a programming job is a curse | 21:40.00 |
| sebras | scott_b: after knowing the basic git commands I recommend ftp://ftp.newartisans.com/pub/git.from.bottom.up.pdf and http://nvie.com/posts/a-successful-git-branching-model/ | 22:01.25 |
| | Forward 1 day (to 2012/07/12)>>> | |
IRC Logs