| | <<<Back 1 day (to 2012/05/20) | 2012/05/21 |
| alexcher | Who knows what's mupdf/bovine_gcc.mak referenced from ghostpdl/Makefile ? | 04:34.47 |
| | And why mupdf is a subdirectory in ghostpdl ? | 04:35.43 |
| Jon87 | How do I print my PDF document with ghostcript which setting first page to tray one and second page to tray two? | 07:03.45 |
| kens | Jon87 that's a totally ambigous question. | 07:04.10 |
| Jon87 | I'm on my assignment and this requirement is a silent printing command done on window services | 07:04.13 |
| kens | Then basically, you can't | 07:04.24 |
| Jon87 | So i need to trigger the print dialog? | 07:04.43 |
| kens | No, the answer is still 'you can't' unless you are doing something unusual. | 07:05.10 |
| | Let me get you a URL | 07:05.14 |
| Jon87 | i see, thanks | 07:05.22 |
| kens | http://stackoverflow.com/questions/10617038/how-to-bypass-media-selection-command-to-printer-when-using-ghostscript-rip-ps-f | 07:06.07 |
| | Also: | 07:06.57 |
| | http://stackoverflow.com/questions/10635982/print-multiple-pages-to-a-printer-when-sdevice-is-an-image-format | 07:06.57 |
| Jon87 | From the post, im advice to convert my PDF file to PS first. Follow by assignment the print commands? | 07:07.30 |
| kens | Jon87 that was a suggestion. | 07:07.42 |
| Jon87 | I see | 07:07.47 |
| kens | It would only work if the destination priner was also a PostScript printer | 07:08.04 |
| | In which case, you would have to have a good reason to convert the PostScript file to PostScript.... | 07:08.22 |
| | In your case, since the input is PDF, converting to PostScript makes some sense, but only if you can be sure teh printer is a PostScript printer | 07:10.15 |
| Jon87 | I will need to double check on the printer selection. Since at university, we are provided with some Sharp MFP, which has different trays for our loading | 07:13.39 |
| Robin_Watts | Stupid crashy windows. | 09:08.20 |
| tor8 | d'oh! namespace conflict between mupdf and pdfwrite :( | 10:56.34 |
| | no wonder it crashes... | 10:56.42 |
| | it's calling the wrong pdf_open_document()! | 10:56.51 |
| kens | can change the pdfwrite one to gdev_pdf... | 10:57.20 |
| tor8 | kens: I'm updating the old mooscript branch to the latest mupdf so alexcher will have an easier time. | 10:57.59 |
| | yes, I think we'll need to rename one or the other; or rely on fragile linker workarounds. | 10:58.25 |
| kens | Lets do the rename. | 10:58.46 |
| | I'm happy for gdev_ prefixes in pdfwrite, I'm fairly sure there a re a number already like taht | 10:59.14 |
| | and pdfwrite's naming convention is best described as 'absent' | 10:59.29 |
| tor8 | kens: right :) | 11:01.28 |
| | mupdf reserves the fz_, pdf_ and xps_ namespaces so it'd be best if we can avoid stomping on those from ghostscript | 11:02.19 |
| | the xps_ ones conflict with ghostxps, but that's not an issue yet | 11:02.36 |
| | let's get pdf working first :) | 11:02.49 |
| kens | Yep :-) | 11:02.54 |
| Robin_Watts | tor8: If we had to we could do some macrotastic hacks so mupdf reserved fz, mupdf, muxps etc. | 11:04.19 |
| kens | Lets keep it sane, rename the pdfwrite ones that clash with a gdev_ | 11:05.07 |
| | or pdfwrite_ either is good for me | 11:05.19 |
| Robin_Watts | pdfwrite_ would seem to be a nice choice :) | 11:05.51 |
| kens | I agree, but I thikn pdfwrite already uses gdev_ in some places | 11:06.08 |
| | I *think* for device methds but I'm not certain | 11:06.18 |
| | yes, actually pdfwrite uses gdev_ for device methods so we shouldn't corrutp that. | 11:08.10 |
| | just stck a pdfwrite_ in front of any name clashes then | 11:08.24 |
| diverdude | Is there a program i can use to annotate PDF files? Like insert notes and highlights? | 11:21.00 |
| tor8 | pdf_open_document is the only conflict so far (from what I can tell of the linker warnings at least) | 11:21.00 |
| sebras | diverdude: the only one I know of is Adobe's Acrobat. | 11:48.58 |
| | diverdude: Currently mupdf is unable to do this, but you probably already know this. :) | 11:49.24 |
| diverdude | sebras: pdf is good in many ways, but when it comes to having to collaborate on a document, MS Word is superior :/ | 11:51.06 |
| sebras | diverdude: I don't think PDF originally was meant as a collaboration platform. I guess that was more an after though on Adobe's part... | 11:56.58 |
| diverdude | sebras: yeah...but latex results either in pdf or ps...so thats the problem | 11:58.05 |
| alexcher | tor8: What's bovine_gcc.mak ? | 12:03.28 |
| Robin_Watts | alexcher: I think that's a makefile that's designed to make mupdf. | 12:07.13 |
| | So that all our products can be built from the top level ghostpdl makefile. | 12:07.45 |
| | Maybe originally for the cluster? (Though it doesn't use it) | 12:08.04 |
| alexcher | Robin_Watts: It's called from ghostpdl/Makefile but doesn't exist anywhere. | 12:11.35 |
| | Robin_Watts: This assumes that mupdf is a subdirectory in ghostpdl. | 12:12.24 |
| | Robin_Watts: Should mooscript rely on the same directory structure ? | 12:14.26 |
| Robin_Watts | alexcher: I would assume so - but tor8 should be the one to know. | 12:15.26 |
| tor8 | alexcher: it's probably a remnant from an old attempt to build mupdf within the ghostscript build system | 12:48.12 |
| | alexcher: I have updated the mooscript branch locally to work with the newest mupdf. | 12:48.39 |
| | there is one issue I still need to fix then I can push | 12:48.49 |
| Robin_Watts | Quick sanity check please? | 13:23.50 |
| | gdevtsep.c line 1873 | 13:24.02 |
| | OK, ignore me :) | 13:24.15 |
| kens | That was easy :-) | 13:24.38 |
| henrys | good Monday morning all | 13:54.45 |
| | just got to see 15 minutes of the eclipse yesterday which was awesome, then clouds... | 13:55.35 |
| Robin_Watts | Morning henrys. cool. | 14:03.19 |
| henrys | mvrhel:early today. | 14:15.04 |
| Robin_Watts | Urm... chrisl? | 14:17.11 |
| | oh, no it'll be tor8 spamming ghostscript-logs | 14:17.33 |
| tor8 | oh noes... so that's why the push is taking forever | 14:17.52 |
| | probably a year or two's worth of commits... wonder if there's a safe way to abort it | 14:18.49 |
| chrisl | Robin_Watts: Urm, yes? | 14:19.19 |
| Robin_Watts | chrisl: Sorry, I saw spamming going on on ghostscript-logs and it was your review that erroneously caught my eye. | 14:19.50 |
| chrisl | Fair enough.... | 14:20.41 |
| tor8 | Robin_Watts: has the ciabot shut up yet? I killed the push, moved the hooks out of the way and pushed and moved the hooks back. we ought to have a better script... | 14:22.56 |
| Robin_Watts | mvrhel: I'm looking at adding the downscaler to tiffsep at the moment. | 14:23.13 |
| | tor8: not yet. | 14:23.18 |
| | At the moment tiffsep only does 8bpp, right? | 14:23.31 |
| | 8bpc, I mean. | 14:23.40 |
| chrisl | Robin_Watts: I've been wondering: how does tiffscaled handle it when we render in bands? | 14:26.23 |
| Robin_Watts | very nicely. | 14:26.29 |
| | :) | 14:26.36 |
| chrisl | :-) Doesn't the banding mess up the error diffusion? | 14:27.04 |
| Robin_Watts | Basically instead of devices calling 'get_bits' they call 'downscaler_get_bits' | 14:27.10 |
| | the downscaler_get_bits get_bits a line at a time into a buffer and downscales that. | 14:27.30 |
| tor8 | alexcher: I have updated the mooscript branch to work with the latest mupdf. building it is still difficult though. | 14:27.39 |
| Robin_Watts | so the downscaler is blissfully unaware of the banding. | 14:28.02 |
| tor8 | you have to build mupdf first, then ghostscript, then make a libgs.a manually from the object files | 14:28.03 |
| | then you can run the mooscript branch makefile to build and link | 14:28.12 |
| chrisl | Robin_Watts: yeh, the downscaler isn't a challenge, but the error diffusion must need some "trickery", I'd have thought? | 14:28.55 |
| Robin_Watts | The downscaler is the error diffuser. | 14:29.13 |
| | errors are kept in a separate buffer. | 14:29.36 |
| chrisl | Ah, I see - thanks | 14:29.52 |
| Robin_Watts | chrisl: It was merely a happy accident that it worked out as nicely as it did. | 14:30.11 |
| | I'd like to push tiffsep1 into tiffsep, which will mean we will be able to do error diffusion on that too. | 14:30.56 |
| | but I don't know whether that's going to present problems with overprint etc. Need mvrhels input. | 14:31.43 |
| chrisl | Robin_Watts: when I'd contemplated something similar before, I was going to (try) make the rendered bands overlap enough to hold the error data, and "clip" when writing out to file. | 14:32.06 |
| Robin_Watts | That'd be nasty, IMHO, as the presence/absence of bands should be transparent to the caller. | 14:32.38 |
| chrisl | This was in Jaws, and it would have been transparent to the caller ("writing out to file" was the wrong phrase to use - handing off of the raster would be more appropriate) | 14:33.52 |
| Robin_Watts | right. | 14:34.46 |
| chrisl | I was looking to make error diffusion "appear" like an "in-process" option, rather than a "post-process" option | 14:37.15 |
| Robin_Watts | yeah. | 14:37.24 |
| | I was (and continue to be) too cowardly to consider that option. getbits is a nasty hairy mess as it is. | 14:37.55 |
| chrisl | But the interested customer lost interest, and I got diverted onto whatever the next crisis...... | 14:38.25 |
| henrys | I've used versions of msvc that had a shell which set up all the environment variables so I could use nmake without fooling with anything - I don't see that in VS 2008. | 14:45.27 |
| Robin_Watts | henrys: It's there. | 14:45.46 |
| henrys | found it, thanks | 14:46.43 |
| Robin_Watts | Start => All Programs => Microsoft Visual Studio 2008 =>Visual Studio Tools => Visua... | 14:46.54 |
| | ok :) | 14:46.56 |
| alexcher | tor8: Would you please comment on bovine_gcc.mak and relative position of ghostpdl and mupdf directories ? | 14:50.14 |
| kens | henrys can you try the bug #693046 please ? | 14:51.10 |
| | Witgh HEAD | 14:51.15 |
| henrys | kens:yes I will I saw the fix glad that's fixed. | 14:52.15 |
| kens | Well I can't be *sure* its fixed :-) | 14:52.30 |
| | But I'm quite hopeful | 14:52.35 |
| henrys | If somebody wants to weigh in on Guillaume most recent question I'm all ears. | 15:02.11 |
| kens | I must have missed it | 15:02.28 |
| henrys | just came in | 15:02.34 |
| kens | Oh, just arrived, will go read it | 15:02.37 |
| | No size limitation is a problem, can't use tiff. | 15:03.33 |
| | JPEG is lossy, what about PNG ? | 15:03.45 |
| henrys | PNG was my thought I was hoping for someone to say, yes above 4G works. | 15:04.48 |
| Robin_Watts | realises why he's had no email all day - didn't restart thunderbird after a crash this morning. | 15:04.58 |
| kens | henrys apparently PNG uses 32-bits for width and height, and flate with predictor compression. Assuming Guillaume doesn't want to produce more than 2^32 samples in each direction PNG should be fine. | 15:08.56 |
| | The compression should br=e reaosnably good, and its what we would use for PDF so its a good comparison | 15:09.18 |
| Robin_Watts | PNG also uses a 32bit length field per chunk. | 15:09.22 |
| | the IMG data appears in a single chunk in a PNG, so you can't have more than 4Gig. | 15:09.41 |
| kens | Really ? That's not going to be enough I think | 15:09.54 |
| Robin_Watts | Actually.... no. | 15:09.59 |
| | There can be multiple IDAT chunks. | 15:10.11 |
| henrys | he's doing large plot contone | 15:10.23 |
| kens | Ah, that's what I thought bu I have only scanned the specd | 15:10.25 |
| Robin_Watts | We'd have to check that we can output with multiple IDAT chunks. | 15:10.41 |
| kens | I don't know if our PNG output can handle multipe IDAT chunks though | 15:10.49 |
| | great minds and all that | 15:10.56 |
| Robin_Watts | I wouldn't have thought it was a tough test to do - other than finding a PNG consumer that can load images > 32767 pixels wide/high. | 15:11.18 |
| kens | :-) | 15:11.25 |
| | Worth trying GIMP | 15:11.42 |
| | Assuming our PNG can output multiple chunks then I think that is the best comparison to a PDF equivalent | 15:12.39 |
| | The overhead will be insignifcant compared to the size of the compressed data in both cases. | 15:13.01 |
| Robin_Watts | indeed. | 15:13.11 |
| | I don't know if we support PNG predictors; if not, we should look at it - that could make filesizes much smaller. | 15:13.48 |
| kens | I thougth PNG required predictor ? | 15:14.14 |
| | Even if our PNG outptu doesn't handle multiple IDAT chunks, it probably woulbdn't be hard to add | 15:15.40 |
| chrisl | I suppose it would be too much to expect that libpng would just "do the right thing" if it was fed that much data....... | 15:15.50 |
| kens | I was hoping it might | 15:16.03 |
| Robin_Watts | PNG files are written with a predictor byte at the start of each line. | 15:16.06 |
| | IIRC 0 means no predictor. | 15:16.16 |
| kens | Oh, OK | 15:16.21 |
| henrys | there are 2 issues we have to be able to output PNG's > 4G and consume that output wrapped as a PDF. Neither of which I've tried. | 15:16.23 |
| Robin_Watts | other values mean different things. | 15:16.27 |
| | henrys: outputting, as kens says should be relatively easy to fix. | 15:16.45 |
| | (if we don't support it already - I bet the PNG lib has it transparently done) | 15:17.03 |
| | consuming it - that's a matter of some postscript programming, in viewlib.ps right? | 15:17.34 |
| kens | As a PDF or as a PNG ? | 15:17.51 |
| henrys | postscript isn't going to be able to handle something that size or are you thinking of chopping up the image. | 15:18.33 |
| Robin_Watts | Confused. You say "consume that output wrapped as a PDF" | 15:19.56 |
| kens | Two requirements | 15:20.06 |
| Robin_Watts | how is that wrapping done? | 15:20.14 |
| kens | 1) TO test teh solution (image in a a PDF) | 15:20.17 |
| | 20 TO actually impleemnt the solution | 15:20.26 |
| | PNG is a good answer to 1 | 15:20.32 |
| Robin_Watts | do you want a C tool to take a PNG and give you a PDF with it in ? | 15:20.36 |
| henrys | yes hpgl2 -> PNG -> PDF -> PDF RIP | 15:20.41 |
| kens | But we need to know if the PDF we create can be consumed by GS later | 15:20.46 |
| henrys | PDF RIP may equal Ghostscript or Adobe | 15:21.07 |
| Robin_Watts | Right, well, a C tool is pretty trivial. | 15:21.13 |
| kens | I htought we would write a device to create the PDF directly | 15:21.28 |
| | Why read multi-gigabytes of data just to write them back out.... | 15:21.52 |
| Robin_Watts | kens: I see, yes, we could do that. | 15:22.00 |
| henrys | my read of this situation is they're going to need something that works with an Adobe RIP also. I'm going to throw it back to him - try PNG, report bugs, done... | 15:22.38 |
| Robin_Watts | So we aren't really interested in 'wrapping PNGs in PDF' or 'producing PNGs' at all. | 15:22.56 |
| kens | Yes, PNG should aallow him to investigate the solution, pretending the PNG wasa PDF | 15:23.03 |
| Robin_Watts | We're interested in "producing a PDF with a flate compressed image in it". | 15:23.19 |
| kens | I believe so, yes | 15:24.16 |
| | Because you can't do ROPs in PDF | 15:24.24 |
| henrys | bah I'm completely confused I thought you could produce a PDF with a png compressed image is that not the case? | 15:26.36 |
| kens | I am not sure | 15:26.49 |
| | You cna certainly create one with a flate compressed image | 15:26.59 |
| chrisl | PNG is not a required filter in PDF, best not to rely on it | 15:27.16 |
| henrys | I didn't think flate would support the sizes we needed. | 15:27.42 |
| Robin_Watts | You can't just take a PNG and roll it into a PDF, no. | 15:27.51 |
| kens | Flate is just a filter | 15:28.02 |
| Robin_Watts | BUT PDF images support flate decode, with the PNG predictor types. | 15:28.12 |
| | so you can just move the compressed data from one to the other. | 15:28.28 |
| | henrys: Why not? | 15:28.32 |
| | Flate as a filter doesn't care how much data you throw through it. | 15:28.44 |
| | It only ever searches in the last 32K. | 15:28.52 |
| henrys | I assumed our stream code would blow up. Maybe not. | 15:29.21 |
| Robin_Watts | The problem is likely to be that PDF images probably have a maximum 32K x 32K size. | 15:29.23 |
| kens | I don'ty think that's true, let me check | 15:30.08 |
| | Width and Height are integers, so the spec limits them to 2^32 | 15:31.29 |
| | 2^32 - 1 to be precise :-) | 15:31.50 |
| henrys | brb | 15:32.15 |
| Robin_Watts | yes, I've just done the same check :) | 15:32.20 |
| kens | Acrobat has a page size limit | 15:32.23 |
| | 14,400x14,400 | 15:32.34 |
| Robin_Watts | But I'll bet that lots of implementations barf at a size smaller than that. | 15:32.46 |
| kens | That's what the UserUnit kludge is for. But that's an Acrobat limit | 15:32.50 |
| | Robin_Watts : then we cna say 'ah but the spec says its legal' | 15:33.06 |
| | Especially if Acrobat will open it :-) | 15:33.16 |
| | OK the size of a page is (without using UserUnit) 200x200 inches | 15:33.49 |
| Robin_Watts | So, if we were to design a device, we might be wise to subdivide the page until width and height are < 65536. | 15:33.58 |
| kens | So if that is large enough for Guillaume he should be OK | 15:34.07 |
| Robin_Watts | I don't imagine that would be massively hard. | 15:34.07 |
| | oh, 14400 then. | 15:34.21 |
| kens | That's 14,400 units | 15:34.31 |
| | Not pixels | 15:34.40 |
| Robin_Watts | Right. Well, subdivide as appropriate then :) | 15:34.49 |
| chrisl | It shouldn't be a problem to split the image into tiles, with a pixel or two overlap. | 15:34.55 |
| kens | well it allowsup to 200x200 inches | 15:35.00 |
| | And we can use UserUnit if that's not enough | 15:35.13 |
| | Wihtout tiling | 15:35.22 |
| chrisl | If the amount of image data proves a problem in a single image, tiling is an option | 15:36.09 |
| kens | Yes, I just don't think its required | 15:36.19 |
| chrisl | Seems crazy to allow gigabytes of image data per image, and then have a 200 inch limit on the page size! | 15:37.06 |
| kens | That's Acrobat for you. Remember thsi is not a *PDF* limitation | 15:37.29 |
| henrys | If somebody has all the info and wants to respond have at it... I don't think it make much difference he's not going to succeed throwing these huge images around. | 15:42.27 |
| tor8 | alexcher: bovine_gcc.mak doesn't exist. I don't know why it's referenced from ghostpdl/Makefile (probably slipped in with another commit) | 15:43.42 |
| henrys | can we please change the word bovine to something more serious? | 15:44.16 |
| | kens:the txtwrite fix seems to work. | 15:47.29 |
| kens | Great, thanks henrsy I wil close the bnug then | 15:47.42 |
| henrys | we could have a device that produced some specified sized bands of pdf's. | 15:50.24 |
| kens | Yes, there are many things we could do by puytting an image (or images) in a PDF file | 15:50.52 |
| tor8 | henrys: the 'bovine' makefile is a test makefile that slipped in by accident with a ghostxps commit. it shouldn't be there. | 15:51.59 |
| henrys | but really he can figure that out - he can write his own device. Meanwhile experimenting with PNG's should give him some idea of what is going on. | 15:52.22 |
| kens | Yes, exactly so | 15:52.34 |
| mvrhel | good morning. | 15:54.49 |
| henrys | mvrhel:you signed in earlier but that must have been your network coming alive or something. | 15:55.57 |
| mvrhel | Robin_Watts: ok. thanks for the tiff scalar work. I do still need to fix the AA | 15:57.02 |
| | henrys: yes. I turned on the machine when I got up | 15:57.25 |
| | then got everyone out the door | 15:57.32 |
| Robin_Watts | mvrhel: Doesn't the scaler mean we don't need AA any more ? | 15:57.35 |
| mvrhel | well what about psdcmyk? | 15:57.43 |
| | I am sure it has the same issue | 15:57.49 |
| | or if anyone adds in devn support to a future device | 15:58.00 |
| Robin_Watts | It probably does. I could probably hook the scaler to that too. | 15:58.01 |
| mvrhel | ok. if you can do this for any general device | 15:58.22 |
| Robin_Watts | All you do is call the downscaler rather than calling get_bits_rectangle. | 15:58.23 |
| mvrhel | then we dont need that | 15:58.25 |
| | oh | 15:58.30 |
| | that makes life easy | 15:58.37 |
| Robin_Watts | It's *almost* working. | 15:58.52 |
| mvrhel | I was not aware that was how it worked Robin_Watts | 15:58.52 |
| | cool! | 15:58.56 |
| Robin_Watts | The downscaler can convert bit depths at the same time (8 bpc -> 1bpc with error diffusion) | 15:59.27 |
| mvrhel | very good | 15:59.35 |
| Robin_Watts | so with a suitable flag, we can do a tiffsep1 equivalent. | 15:59.52 |
| henrys | Robin_Watts:could the downscaler be enabled dynamically with any device? | 15:59.59 |
| Robin_Watts | henrys: I am NOT hiding the downscaler in getbits :/ | 16:00.20 |
| | but lots of devices call through the downscaler (png16m, most tiff variants) already | 16:01.01 |
| | (I'm trying to think of a better argument than "I don't want to". I'm sure there is a technical reason somewhere) | 16:04.06 |
| chrisl | Robin_Watts: It would change the API? | 16:05.38 |
| henrys | okay I was thinking it would be cool if anyone writing a device had that in the device class hierarchy. | 16:06.28 |
| Robin_Watts | If you're writing a device, it's easy to hook up. | 16:08.38 |
| | You have to watch for DownScaleFactor in the getparams/putparams. | 16:08.58 |
| | And in your print_page you init the downscaler. Instead of calling getbits you call downscaler_getbits, and then you fin the downscaler. | 16:09.37 |
| | And you have to output dev->width/factor rather than dev->width pixels obviously. | 16:09.56 |
| henrys | right it would mean changeing getbits to take output width and if the ratio to dev->width were 1 it would behave as usual. | 16:10.51 |
| Robin_Watts | I could conceivably do it as a device. | 16:12.00 |
| | so that calling into my device would forward to the real device with a bigger width etc. but that's a massive can of worms, and not easy for people. | 16:12.40 |
| kens | OK time to go, night all | 16:31.57 |
| rayjj__ | has anyone (Scott?) already looked into the Evolver Group (evolver.de) to see if they should be a supported outfit ? (re: bug 693007) | 16:48.37 |
| Robin_Watts | I think I just found a bug in the planar devices getbits stuff. | 16:49.15 |
| | It's never shown up before because we've never called gitbits for more than one line at a time. | 16:49.33 |
| | OK. tiffsep works with the downscaler. | 16:53.00 |
| henrys | rayjj__:I know scott sent something to them yes. | 16:55.54 |
| Robin_Watts | mvrhel: ping | 16:58.06 |
| mvrhel | Robin_Watts: yes | 16:58.17 |
| Robin_Watts | Suppose I add a new flag to tiffsep to make the downscaler target 1bpp. | 16:58.31 |
| | a) what should that flag be called. | 16:58.41 |
| | b) are there any implications with overprint etc? | 16:59.01 |
| henrys | rayjj__:I updated the bug. | 16:59.23 |
| Robin_Watts | (I'm not sure overprint makes sense with antialising or the downscaler in play) | 16:59.24 |
| mvrhel | when does the halftoning occur in this case? | 16:59.32 |
| Robin_Watts | mvrhel: No halftoning. | 16:59.48 |
| mvrhel | hold on phone | 16:59.55 |
| Robin_Watts | We draw to 8bpp contone throughout, then error diffuse down to 1bpp at the same time as downscaling. | 17:00.05 |
| | np. | 17:00.08 |
| Robin_Watts | fetches tea | 17:00.28 |
| mvrhel | Robin_Watts: I don't see how they would be any issues with this | 17:01.55 |
| | s/they/there/ | 17:02.04 |
| Robin_Watts | Ok. Is there anyone that would complain about error diffusion rather than halftoning? | 17:08.24 |
| | -dBitsPerComponent=1 ? | 17:12.22 |
| rayjj__ | Robin_Watts: since the AA is per plane, I don't see why overprint shouldn't be OK. Overprint true might have one plane with AA edges overprinted on another plane. | 17:18.28 |
| | Robin_Watts: actually, overprint false where the AA has one plane 'fading out' and another plane 'fading in' might introduce more "strange" color blends, but AA in CMYK works that way already | 17:19.46 |
| Robin_Watts | rayjj: Right. It was the case where an AA pixel contains contributions from source pixels that have different outputs due to overprint. | 17:20.32 |
| | (i.e. if overprint is intended to insist that no pixel has a mixture of 2 specific inks on it, AA might break that) | 17:21.05 |
| rayjj__ | Robin_Watts: folks printing on electrophotographic engines (laser/LED, etc.) typically have trouble imaging dispersed dot (they have a minimum dot size) | 17:21.06 |
| Robin_Watts | Right. Well, bringing the downscaler and 1bpp into tiffsep brings MinimumFeatureSize in too | 17:21.37 |
| rayjj__ | Robin_Watts: I don't think anyone will be concerned about that. After all, unintended offsets between planes when printing mix inks anyway, as does any 'trapping' | 17:22.48 |
| | Robin_Watts: as long as we have MinFeatureSize with the ED, then we should be OK. | 17:23.26 |
| Robin_Watts | ED ? | 17:23.40 |
| rayjj__ | Robin_Watts: Error Diffusion (not Erectile Dysfunction) | 17:24.01 |
| Robin_Watts | I'm sure I've had emails about that... | 17:24.02 |
| | right. | 17:24.05 |
| | Does tiffsep1 have MFS | 17:24.26 |
| | ? | 17:24.28 |
| rayjj__ | Robin_Watts: sorry. Two conversations interleaved is a bit confusing. What was your "?" | 17:26.28 |
| Robin_Watts | Does tiffsep1 have MFS? | 17:26.37 |
| rayjj__ | Robin_Watts: the exisiting tiffsep1 uses whatever halftone is defined (turns the 'order' into a threshold array). | 17:27.42 |
| Robin_Watts | Oh, it does MFS like that. | 17:28.02 |
| rayjj__ | Robin_Watts: but doesn't apply MFS in that if there is a pattern with single pixel dots by themselves, they will NOT be expanded -- just imaged through the threshold arry | 17:28.53 |
| | so, I guess the answer is "no" it doesn't currently have MFS | 17:29.12 |
| | and single weight lines don't get 'fattened' | 17:29.44 |
| | Robin_Watts: I thought you question was whether people would object to ED with tiffsep1. The answer is that as long as the ED doesn't image dots too small when halftoning light shades, it is fine | 17:31.16 |
| Robin_Watts | rayjj: No halftoning. | 17:31.40 |
| | Sorry, ignore that. | 17:31.46 |
| | If I add 1bpp operation to tiffsep, then I was interested to know if the fact we get MFS with it would count as a "new feature". | 17:32.32 |
| rayjj__ | Robin_Watts: tiffsep with downscaling and 1bpp will do halftoning (ED), right ? | 17:32.36 |
| Robin_Watts | yes. | 17:32.46 |
| rayjj__ | Robin_Watts: then getting MFS (which tiffsep1 doesn't have) will be a new feature, yes | 17:33.17 |
| Robin_Watts | cool. | 17:33.33 |
| rayjj__ | Robin_Watts: but not using the defined screening is not compatible and some people that have invested in their screens may object. Color management is VERY sensitive to the halftoning | 17:34.49 |
| Robin_Watts | Right. Those people can keep using tiffsep1, cos they won't be wanting antialiasing. | 17:35.21 |
| rayjj__ | Robin_Watts: seems like having an option to screen using ED or the current screen (using threshold array from the order) would avoid that | 17:35.48 |
| | besides threshold array based halftoning is faster | 17:36.05 |
| Robin_Watts | Yes, we can add new downscaling cores to the downscaler to do that. | 17:37.04 |
| rayjj__ | Robin_Watts: I seem to recall that we discussed that as an option a ways back (back when you did the downscaler) | 17:37.06 |
| | Robin_Watts: so, does MFS affect the ED output (make the minimum dot a MFSxMFS dot, adjusting the error appropriately) ? | 17:40.28 |
| Robin_Watts | yes. | 17:40.36 |
| | Actually, I think it's not MFS*MFS | 17:41.42 |
| rayjj__ | Robin_Watts: what is it ? | 17:42.14 |
| Robin_Watts | MFS varies between 1 and 4, and that varies between a 1x1, 2x1, L shaped and 2x2 feature. | 17:42.35 |
| | IIRC. | 17:42.44 |
| rayjj__ | Robin_Watts: I see -- sort of like what I have in the stochastic threshold array generator -- except I went up to 3x3 | 17:43.26 |
| Robin_Watts | Doing 3x3 is harder due to the way ED works. | 17:43.51 |
| rayjj__ | Robin_Watts: I think 2x2 is fine -- after that they can go to traditional screening | 17:44.44 |
| | Robin_Watts: implementing MFS with threshold_array will slow it down a bit | 17:45.39 |
| | back to real work (for cust 532). | 17:47.35 |
| Robin_Watts | I have 1bpp working too. | 18:15.06 |
| | got to go get helen. | 18:15.13 |
| | bbs. | 18:15.15 |
| | Forward 1 day (to 2012/05/22)>>> | |
IRC Logs