| | <<<Back 1 day (to 2018/05/13) | 20180514 |
| lilatomic | Hi all, I was trying to use the inkcov device, but the formatting of the output is coming out wrong: | 04:21.37 |
| | would here be a good place to work out if I'm using it wrong or if it's a bug with ghostscript? | 04:22.16 |
| kens | lilatomic (for the logs) Yes you can talk to us here, the best time is UK or US office hours. As to what hte problem is, you're going to have to be mpre explicit about ht eproblem. Its hard to see how the formatting of the output from the inkcov device could be wrong. | 06:58.23 |
| lilatomic | @kens when running gs -dBATCH -dNOPAUSE -dQUIET -q -sDEVICE=inkcov -sOutputFile=%stdout% file.ps, I get the following output: https://pastebin.com/pmQz02Mm | 13:13.51 |
| | instead of the Page and the CMYK declarations following one after the other, they're in someway grouped together. So the first 10 CMYK statements are printed, then 9.5 page statements (half is interrupted), then more CMYK statements. | 13:16.53 |
| | This only seems to happen when run on .ps files, .pdf files only have the CMYK output and do not have the "%%[Page: ]%%" declarations | 13:21.18 |
| chrisl | It's almost certainly because the streams aren't being flushed in the correct order | 13:21.52 |
| lilatomic | That sounds reasonable. My understanding is that the stream flushing is internal to ghoscript's code, and I can't just change a system setting somewhere; is this correct? | 13:27.06 |
| chrisl | Yes, it's something that'll need fixing "properly" in the code | 13:28.01 |
| kens | Probably deserves a bug report | 13:33.19 |
| chrisl | I think it will have to be, because I don't have time to look right at this moment - and I'll definitely forget! | 13:35.40 |
| lilatomic | ok, I'll write one up | 13:36.02 |
| chrisl | Thanks | 13:36.18 |
| lilatomic | side question, are the "%%[Page: ]%%" declarations supposed to be something which can be suppressed with the "-sstdout=/dev/null" option? I'm not sure if it should, but I've tried it and it doesn't seem to suppress it. | 13:39.39 |
| chrisl | Those come from the Postscript job, so no | 13:40.05 |
| | Or, at least, I don't think so | 13:40.32 |
| kens | I think that's soemthign included by the Windows PostScript printer driver | 13:41.00 |
| lilatomic | oh ok, that explains why I couldn't get it to work :P | 13:45.00 |
| | I'm not sure that it's the Windows PostScript driver, it happens on Ubuntu as well | 13:45.36 |
| chrisl | It's a common construct with DSC compliant (or allegedly DSC compliant files) | 13:46.16 |
| kens | It coudl even be the GS DSC parser doing it | 13:46.40 |
| | I can't recall offhand | 13:46.45 |
| lilatomic | would the best component for this be "other driver"? | 13:58.32 |
| chrisl | Yeh, that'll be fine | 13:59.02 |
| lilatomic | ok, submitted. Thank you very much for your help! | 14:09.52 |
| kens | NP thanks for the report | 14:10.02 |
| lilatomic | one last thing: does ink_cov take the same arguments as inkcov? I can't find ink_cov mentioned in the documentation (in either the Use.htm or in the Devices.htm) | 14:19.46 |
| kens | I suspect its a contributed device | 14:20.03 |
| | Hmm apparently ink_cov at least is ours | 14:21.08 |
| | ink_cov seems to takte no specific parameters at all | 14:22.09 |
| | In fact they are both defined in gdevicov.c | 14:22.48 |
| | They differe only in the output page | 14:23.17 |
| | Apparently ink_cov gives 'ratecoverage' I have no idea what that means | 14:24.12 |
| lilatomic | ok, thanks! | 14:24.46 |
| rnissl | Hi, does 9.23 JPEG Passthrough have any impact when feeding pdfwriter with pdfs as input? | 14:53.24 |
| kens | Yes | 14:53.48 |
| | That's the entire point of the exercise | 14:53.56 |
| rnissl | Hi kens, I think we talked about that about a year ago and you had that on your todo list ;-) | 14:54.37 |
| kens | provided you are not changing the resolution or colour spac eof the DCT encoded image, it will not be decompressed and recompressed | 14:54.38 |
| | Coudl be :-) | 14:54.47 |
| | I did finally get round to it | 14:54.53 |
| | NB there's a small bug with it at the moment | 14:55.06 |
| | Which some PDF readers dislike | 14:55.12 |
| rnissl | can you provide more details please? I was about to switch from 9.21 to 9.23 as 9.22 had an issue and now, 9.23 has one too :-( | 14:57.02 |
| kens | What the bug ? | 14:57.11 |
| | Its pretty simple | 14:57.14 |
| | Although we pass the DCT encoded data through unchanged, we still need to execute teh DCTDecode filter | 14:57.33 |
| | because otherwise (for PostScirpt input) we don't know when we've consumed the image | 14:58.02 |
| | The problem is (and I didn't realise this when coding it) that the DCTDecode filter eats the EOD | 14:58.20 |
| | So it never gets sent to the output | 14:58.29 |
| | Most PDF consumers don't care | 14:58.36 |
| | THey are happy that they had enough image dtaa, and the stream length is correct. | 14:58.53 |
| | One consumer (I forget which) complains. | 14:59.04 |
| rnissl | ok, but the PDF is not 100 % to the specs, is it? | 14:59.41 |
| kens | Like so many, many. many other PDF files | 15:00.00 |
| | I have on right here where the number of pages in teh document is a floating point number | 15:00.24 |
| rnissl | ok, then I'll give it a try. This happens only when input is PDF or in general when input is a jpg image? | 15:01.30 |
| kens | Any DCT encoded input | 15:01.41 |
| rnissl | ok | 15:01.44 |
| kens | You can always turn off JPEG passthrough | 15:01.51 |
| | And of course, its only relevant to the pdfwrite family of output devices | 15:02.07 |
| | rendering is, of course, unaffected | 15:02.17 |
| rnissl | so /QFactor set with setdistillerparams has no impact on such images if passthrough is on | 15:03.47 |
| kens | Provided you aren't doing something which requires us to alter the image, no. | 15:04.14 |
| | Eg subsampling to a different resolution or changing the colour space | 15:04.26 |
| rnissl | is there a rough schedule for 9.24, e. g. autumn 2018? | 15:07.13 |
| kens | The same schedule as always. Ghostscript is released twice a year, in March and September | 15:07.34 |
| rnissl | ok, I think this will be just in time ;-) | 15:08.19 |
| | thanks for the info kens, bye. | 15:08.32 |
| kens | NP | 15:08.35 |
| | Forward 1 day (to 2018/05/15)>>> | |
Log of #ghostscript at irc.freenode.net.