| | <<<Back 1 day (to 2016/03/17) | 20160318 |
| Dodfr | hi | 08:54.37 |
| ghostbot | Welcome to #ghostscript, the channel for Ghostscript and MuPDF. If you have a question, please ask it, don't ask to ask it. Do be prepared to wait for a reply as devs will check the logs and reply when they come on line. | 08:54.37 |
| Dodfr | on Windows, once Ghostscript printer has been added to the system is there a way it call an external app as soon the .ps has been created ? and is there a way for the driver to produce PDF directly instead os PS ? | 08:57.21 |
| kens | If you want to execute an application when PostScript has been produced, you ned a Port Monitor such as RedMon. That can execute arbitrary commands. | 09:01.09 |
| | No you cannot produce PDF directly (at least on systems up to Windows 7) because there is no printer driver to do so. | 09:01.39 |
| Dodfr | RedMon ? yes i've seen this tool so I can use it to monitor then wait it triggers then call ps2pdf | 09:02.55 |
| | or monitor the /save_ps/ directory for a new .PS to be created (and closed) then work on it | 09:04.02 |
| kens | You don't wait until it 'triggers' that isn't how it owrks. However, it is part of the mechanism for using Ghostscript to 'print to PDF' on Windows. Don't use ps2pdf, call Ghostscript directly | 09:04.08 |
| Dodfr | ok thanks for the advice | 09:04.37 |
| kens | http://pages.cs.wisc.edu/~ghost/redmon/ | 09:04.57 |
| Dodfr | I am trying to make some Print2FaxMail gateway | 09:04.59 |
| | yes I already downloaded it yesterday | 09:05.21 |
| | so the goal is that a soon the user printed the document I open some addressbook then send the .pdf to the mail2fax gateway | 09:06.42 |
| tor8 | Robin_Watts: could you give me the 10 mile overview of pkm, so I know what I'm looking at here? | 11:51.21 |
| Robin_Watts | tor8: 1bpc cmyk output. | 11:51.55 |
| | The gs pkmraw device renders 1bpc cmyk, then converts to rgb to output as a pam. | 11:52.29 |
| | The new mupdf code is more like the pamcmyk4 device from gs, but pkm is catchier. | 11:52.55 |
| tor8 | ah, so a 1-bpc PAM? | 11:53.05 |
| Robin_Watts | Basically we render to 8bpc cmyk, then convert down to a 1bpc halftoned bitmap. | 11:53.36 |
| | Then I output that as an 8bpp cmyk bitmap (with each pixel being either 0 or 0xff) | 11:53.56 |
| tor8 | oh, so it gets upscaled again? so that's what the 'pkm' array is all about. | 11:54.27 |
| Robin_Watts | so yes, it's effectively a 1-bpc PAM, but most pam readers barf on non MAXVAL 255 things. | 11:54.33 |
| | yes. | 11:54.43 |
| | It's basically there to give something that ray can time. | 11:55.02 |
| tor8 | I was just going to ask if MAXVAL 1 would work | 11:55.09 |
| | but apparently not :) | 11:55.13 |
| Robin_Watts | I have a memory of having run into that particular pitfall before. | 11:55.36 |
| | And this matches what gs does. | 11:55.46 |
| | oh, ass. I need to invert the table so I can remove the 255^ stuff. | 11:56.30 |
| tor8 | Does assert(0 && "message") work? or just assert(!"message") | 11:58.08 |
| | it looks odd seeing NULL == :) | 11:58.21 |
| Robin_Watts | assert !message would work. | 11:58.28 |
| | Updated version online. | 11:59.37 |
| tor8 | and yes, inverting the 'pkm' bits_to_bytes array so you can drop the 255^ inversion would be nice | 11:59.39 |
| Robin_Watts | done. | 11:59.51 |
| tor8 | Robin_Watts: a byte of all zeroes will output a row of eight 255s ... is that inversion intended? | 12:01.00 |
| | because fz_bitmap has 0 meaning on, or something? | 12:01.14 |
| Robin_Watts | PAMs have opposite meaning to PPMs, I think. | 12:01.45 |
| | Certainly this gives the right results. | 12:02.15 |
| tor8 | might be pam viewers inverting cmyk data? | 12:02.26 |
| | to account for additive/subtractive stuff | 12:02.38 |
| Robin_Watts | maybe. | 12:02.43 |
| tor8 | for RGB PAMs, 255 is white | 12:02.53 |
| Robin_Watts | for CMYK PAMs this is doing the right thing. And the sense of bitmaps is the same for cmyk and for mono. | 12:03.28 |
| tor8 | Robin_Watts: huh, imagemagick has the image oddly inverted when displaying cmyk pam files | 12:06.31 |
| | but the text is also black | 12:06.39 |
| | so I'm thinking it may not actually cope with cmyk | 12:06.48 |
| Robin_Watts | tor8: I was using imagemagick convert to change from pam to png to view it. | 12:07.02 |
| | and http://ghostscript.com/~robin/pamview.html | 12:07.36 |
| tor8 | oh, imagemagick convert seems to cope with cmyk ... it's just the 'display' that goes wrong :/ | 12:08.33 |
| Robin_Watts | tor8: consistency. gotta love it. | 12:08.49 |
| malc_ | lovely, registration walled DDI in the wild | 12:09.00 |
| tor8 | Robin_Watts: okay, it seems to work but it looks like pbm output is broken | 12:10.47 |
| Robin_Watts | tor8: Oh, pants. | 12:10.59 |
| | will fix. sorry. | 12:11.26 |
| tor8 | $ mutool draw -c gray -o out.pbm pdfref17.pdf 1144 | 12:11.27 |
| | Unsupported colorspace for this format | 12:11.27 |
| Robin_Watts | mono | 12:12.07 |
| tor8 | oh. | 12:13.29 |
| Robin_Watts | I see what I broke. | 12:13.30 |
| tor8 | Robin_Watts: we don't invert colors when writing regular CMYK 8-bpp PAMs | 12:14.03 |
| | so I think the halftoning is inverting bits? | 12:14.15 |
| | which is confusing for pbm | 12:14.25 |
| Robin_Watts | Fixed version up now. | 12:16.01 |
| | So, in the halftoning, we set a bit, if the contone value is less than the threshold value. | 12:16.34 |
| | so that would appear to suggest that white (0xFF) would never end up with set bits. | 12:17.51 |
| tor8 | yeah. I think a lot of older bitmap stuff assumes 0=white and 1=black | 12:18.35 |
| Robin_Watts | I'm confused actually... when we render greyscale, do we use 0 = black, 0xFF = white ? | 12:19.00 |
| tor8 | in pbm, black is 1 | 12:19.10 |
| | yes, our grayscale is 0=black, 255=white | 12:19.22 |
| Robin_Watts | right. | 12:19.27 |
| tor8 | but the halftoning inversion is 'correct' and inverts to BlackIs1 for fz_bitmap to output directly to pbm | 12:19.47 |
| Robin_Watts | So, I could reverse the halftoning logic to be >= (which I think would be nicer) | 12:19.52 |
| tor8 | so we need to either flip the halftoning to blackis0 and then invert in the pbm output, or leave as is now and invert in pkm output | 12:20.22 |
| Robin_Watts | The halftones contain values from 1 to 255. | 12:20.29 |
| tor8 | I can live with either, as long as we document that black is 1 or 0 in the fz_bitmap and halftoning functions | 12:20.54 |
| Robin_Watts | Gah. white is 255. 255 is never smaller than any halftone value, thus white never gets a set bit. That all makes sense. | 12:21.50 |
| | set bits in the bitmap mean black. | 12:21.56 |
| | So bitmaps have BlackIs1 | 12:22.23 |
| tor8 | yes. | 12:22.26 |
| Robin_Watts | For cmyk output, white is 0. | 12:22.49 |
| | hence the halftoning for cmyk is wrong. | 12:22.58 |
| | I should reverse the tests in the do_threshold_4 routine. | 12:23.18 |
| tor8 | Robin_Watts: does the halftoning do gamma curves? | 12:23.28 |
| | in that case, we need to make sure to feed it the proper ranges for additive/subtractive color spaces | 12:23.43 |
| Robin_Watts | (in our contone cmyk output, white is 0,0,0,0 right?) | 12:23.47 |
| tor8 | yes, contone cmyk PAM white is 0,0,0,0 | 12:24.02 |
| Robin_Watts | tor8: If you want gamma then you need to pickle it into the halftone tables. | 12:24.06 |
| tor8 | I was wondering if it's already pickled | 12:24.18 |
| Robin_Watts | tor8: Not into the default one. | 12:24.29 |
| tor8 | and if the halftone table assumes additive or subtractive colors | 12:24.41 |
| Robin_Watts | (which I stole from gs) | 12:24.44 |
| tor8 | because if it assumes one and we feed it the other, the output will look too dark/bright | 12:25.03 |
| Robin_Watts | OK, so EITHER I need to reverse the sense of the tests in do_threshold_4, and re-reverse the pkm table, OR we need to live with the fact that for CMYK bitmaps we have BlackIs0 | 12:27.17 |
| | tor8: In the 16x16 threshold table we use, every value from 2...255 appears exactly once. | 12:28.05 |
| | (and 1 appears twice, 0 does not appear). | 12:28.14 |
| | That implies no gamma to me. | 12:28.22 |
| tor8 | kens or rayjj might have some experience here, what do cmyk devices actually use? | 12:30.23 |
| Robin_Watts | For gs's rendering, k=1 => black | 12:37.27 |
| | c=1 => red | 12:38.01 |
| | so that's BlackIs1. | 12:38.17 |
| | I think I'd rather live with the meaning of Bitmap bits flipping depending on whether we're in an additive/subtractive color space than have to have the thresholding routines doing different things. | 12:39.37 |
| | We can always revisit this if we ever actually get a customer :) | 12:39.56 |
| tor8 | yeah. traditional mono bitmaps assume a subtractive grayscale... that's where we get into trouble. | 12:42.45 |
| | commit LGTM | 12:42.56 |
| kens | Sorry was at lunch. In general printers use 1 = bit is set in the current component and 0 = bit is not set. There used to be (rare) 'write white' devices which were inverted, but I haven't seen one of those in years | 12:43.02 |
| tor8 | Robin_Watts: it would be nice though, if blackIs1 for both grayscale and cmyk fz_bitmaps | 12:44.57 |
| Robin_Watts | tor8: That would mean me reversing the thresholding tests. | 12:45.22 |
| | which I can do, but it's potentially inconsistent. | 12:45.44 |
| tor8 | and then we still need to pre or postprocess grayscale | 12:46.40 |
| | I think I'd also be happy with preserving 0=0 and 1=255, so that we just need to invert bitmaps when writing to pbm | 12:50.10 |
| Robin_Watts | That would slow the pbm writing code down. | 13:00.03 |
| tor8 | invert, try { write } always { invert } ? | 13:00.23 |
| Robin_Watts | Urgh. | 13:01.11 |
| tor8 | do_threshold_1 can threshold one way, and do_threshold_4 the other? | 13:01.20 |
| Robin_Watts | tor8: Yes. | 13:01.32 |
| tor8 | in case we want blackIs1 for both grayscale and cmyk bitmaps | 13:01.41 |
| Robin_Watts | That would give us blackis1 in all cases. | 13:01.52 |
| tor8 | I think that's the ideal approach for approaching printers | 13:01.54 |
| | and that sentence came out all funny :) | 13:02.05 |
| Robin_Watts | tor8: Another updated commit to do that then. | 13:07.56 |
| Robin_Watts | foods. | 13:08.52 |
| tor8 | Robin_Watts: great. LGTM. | 13:10.50 |
| | chrisl: more troubles.. StandandSymbolsPS has the wrong glyph names. | 13:28.09 |
| | in the type1, pi is named uni0070 (latin small letter p) | 13:28.35 |
| | in the truetype, pi is U+F070 'pi' in the MicroSoft Symbol Area | 13:28.57 |
| | HenryStiles: would it be too much to ask URW to provide a change log for the fonts? | 13:33.33 |
| kens | Based on prior experiences I don't htnk they will be able to. Because I don;t thnk they maintain the fonts like that, I 'suspect' they build the fonts for us uniquely each time. WHich is why we get all these problems. | 13:34.39 |
| Robin_Watts | rayjj: Sure. If you pull again now you can get timings for .pkm too. | 14:50.35 |
| chrisl | tor8: sorry missed that - for some reason my irc client didn't scroll with the conversation...... Hmm, those glyph names make no sense at all..... :-( | 15:12.26 |
| | Forward 1 day (to 2016/03/19)>>> | |
IRC Logs