| | <<<Back 1 day (to 2020/11/08) | Fwd 1 day (to 2020/11/10) >>> | 20201109 |
| vyvup | hi all! I would like to ask a question. During the course of debugging my foomatic-driven printer, I found that running `gs -dDEBUG -dSAFER -dNOPAUSE -dBATCH -sstdout=%stderr -sOutputFile="out%02d.png" -sDEVICE=pnggray -r600x600 -sPAPERSIZE=a4 -c "<</.HWMargins[10.750000 15.000000 10.750000 15.000000] /Margins[0 0]>>setpagedevice" -f foo.ps` works correctly on a handcrafted file `foo.ps` but | 08:45.56 |
| | when running this on the result of `ps2ps2 -sPAPERSIZE=a4 foo.ps` the image is offset by an amount of `pagenr*(hwmarginL, hwmarginB)`. So each resulting page the image creeps more to the topright of the page. Is this expected? | 08:45.57 |
| kens | I've no idea, where did you get 'ps2ps2' from ? | 08:57.44 |
| | But since you are describing hardware matgins, it sounds like its probably expected | 08:58.24 |
| chrisl | ps2ps2 just does: "-q -sDEVICE=ps2write -sstdout=%stderr "-sOutputFile=$2" -dNOPAUSE -dBATCH $OPTIONS "$1"" - so nothing very dubious | 08:59.37 |
| kens | Assuming its the same ps2ps2 | 08:59.49 |
| | that is, ours. | 08:59.53 |
| | And if you apply the HWMargins twice (once on xconversion to PostScript and again on conversion to PNG) then you'd get the margins applied rtwice | 09:00.15 |
| chrisl | Oh, well, *assuming* it's our Ghostscript, as well, then | 09:00.24 |
| kens | TBH I'd need to see an example file, cna complete command lines before deciding whether its correct or not | 09:01.20 |
| | vyvup see this bug report: | 09:13.06 |
| | https://bugs.ghostscript.com/show_bug.cgi?id=703017 | 09:13.06 |
| | If you believe that, using current code, there is a problem, please open a bug report and attach the example file | 09:13.40 |
| | A *new* bug report please, to avoid confusion with the existing r(closed) report | 09:13.59 |
| | vyvup I believe this commit: | 13:32.08 |
| | https://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=40d306bf6707c365996eb1d41782ca3f063311d0 | 13:32.08 |
| | will resolve your problem | 13:32.08 |
| vyvup | @kens no quick way for building and running from ghostscript source, but applying your patch to the ps2write output fixes the problem! Great! | 14:06.40 |
| | Follow up question: reading your reply https://bugs.ghostscript.com/show_bug.cgi?id=703017 it seems that passing output from `ps2write` as input to Ghostscript is unexpected. Why would that be the case? | 14:08.22 |
| kens | Why would you want to ? You might just as well pass the original file | 14:18.38 |
| | Skip the conversion step | 14:18.51 |
| | BTW thanks for testing the change, I had to use teh file from bug 703017 so I couldn't be completely sure it was the same problem, but it looked like it | 14:20.14 |
| vyvup | Not a PS/printing expert but postprocessing / normalizing a PS file (e.g. changing settings, combining PS files into one) and using the output as originals in their own right. | 14:34.34 |
| kens | Well the problem is that you are not merely 'processing' the files. | 14:35.10 |
| | The ps2write family of devices completely interprets the file to marking operations, and then assemboles a new file from those operations (the process is described in vectordevices.htm) | 14:35.46 |
| | Each time you go through that process there is the potential for losing information/fidelity/quality | 14:36.04 |
| vyvup | Ah ok | 14:36.10 |
| kens | So you should avoid it whenever possible. | 14:36.13 |
| | Bear in mind that PostScript is a programming language, so when you 'convert' PostScript to PostScript you are in effect rewriting the program | 14:36.50 |
| vyvup | But isn't it common to do operations on PS files using PS library files (e.g. for nup-ing, etc)? Which output device to use for those kind of PS to PS transforms? | 14:36.57 |
| kens | Imagine what would happen if you used a transcoder to take a C program, rewrite it in Python and then rewrite it again to C. You would lose all the comments, and you might well lose other things too | 14:37.36 |
| | Its generally not common to 'transform' PostScript program, no. | 14:37.56 |
| | The exception is EPS (Encapsulated PostScript) | 14:38.05 |
| | Which is well defined and guaranteed to have no side effects | 14:38.14 |
| | Also PostScript program which conform to the Codumetn Structure Conventions (DSC) can be manipulated in certain ways reliably | 14:38.52 |
| | But that's not what ps2write does. Although its output *is* DSC-compliant so you could modify it in certain ways afterwards, reliably | 14:39.19 |
| | That should read Document Structure Convention, sorry | 14:39.44 |
| vyvup | So what you're saying is that Ghostscript should only be used for the final printing step, not as a tool for assembling original content based on existing PS files? | 14:40.48 |
| kens | Not precisely | 14:41.02 |
| | You can do certain things with it reliably, but its wise to understand the limitations of the process. | 14:41.19 |
| vyvup | So I have learned ;-) | 14:41.30 |
| kens | You can also do certain things 'unreliably' but with > 99% likelihood it'll work. | 14:41.41 |
| | But you really should try to minimise the number of times you run through ps2write/pdfwrite | 14:42.34 |
| | Because there's a risk of problems every time. | 14:42.45 |
| vyvup | I understand | 14:42.52 |
| kens | Also, if you start with PDF and it contains transparency, the PostScript program will be nothing but a huge image | 14:43.02 |
| | If you were to start with PCL and it contained RasterOPs then they would be lost on the output, because PostScript doesn't support tha, and we can't fall back to an image because there's no way to tell in advance | 14:43.44 |
| vyvup | Is there an alternative Ghostscript device that keeps more of the original PS structure intact? | 14:43.47 |
| kens | No. | 14:43.51 |
| | Ghostscript devices **never** see the input | 14:44.04 |
| | All they ever get is the graphics library calls which represent teh marking operations | 14:44.21 |
| vyvup | Ah ok, so what they see is a bit higher level than the rasterized image, but not much | 14:44.53 |
| kens | There are some extensions for passing non-marking operations from PDF files (bookmarks, outlines, annotations etc, etc) but those are non-portable and don't really affect teh discussion | 14:45.04 |
| | vyvup: its quite a bit higher level than the rendered image, but there are things you can do in PostScript which simply can't be 'captured' as marking operations. | 14:45.43 |
| | And some workflows rely uopn certain comments, or certain patterns of code in order to function. Those won't work at all after the program has been through ps2write for example | 14:46.22 |
| vyvup | I see | 14:46.43 |
| kens | I'm not saying its not of value, just exercise caution when using it. | 14:46.43 |
| | Its llike a sharp knife, its a useful tool but it can cut you too, you just need to be careful with it | 14:47.16 |
| vyvup | That also means you have to be careful with filters in a printer spooler as filters can impact each other if you are not careful.. | 14:47.45 |
| kens | Absolutely, the case is very similar | 14:48.16 |
| vyvup | Because it is easy to get a PDF -> ps2write -> cups pipeline where this happens, which I think is my original problem | 14:49.09 |
| kens | Yes, I very strongly suspect this is the problem that the user in bug #703017 had too. Unfortunatley he wasn't able to explain it in a way we could understand | 14:49.49 |
| | This was, obviously, a bug, the page level save wasn't bein executed until after we had done a translate to work around the unprintable margin, which meant that the restore didn't undo it. And then we did it again for the next page, and again.... | 14:50.51 |
| vyvup | It also took some time before I wrapped my head around this. I started from 'why does my print content shift each page' :-) And then there is quite some stuff to investigate with all the filtering that is done in a common Unix printing pipeline :-) | 14:51.15 |
| chrisl | There really shouldn't ever be a case of ps2write output being converted to cups rasters | 14:51.28 |
| kens | Since /.HWMargins is a Ghostscript-specific page device key, and our tyesting doesn't have any devices which have non-zero values, we didn't pick it up | 14:51.47 |
| | chrisl I'm sure that it *needn't* be converted, but with CUPS I think it would be easy to set up such a system by accident | 14:52.29 |
| | Or to process a file outside of CUPS, then take the ps2write output and send it to a printer via CUPS ? | 14:53.11 |
| | I admit I don't understand CUPS very well | 14:53.41 |
| chrisl | I suppose that would be possible - it would probably convert it to PDF using pdfwrite | 14:54.09 |
| | Since cups "spool files" are PDF | 14:54.35 |
| vyvup | In the end what CUPS did was similar to the png case I posted, just some other type of rasterization format | 14:54.37 |
| kens | Hmm, yes, and that shouldn't be a problem | 14:54.47 |
| chrisl | vyvup: But why was it converting to Postscript at all? | 14:55.04 |
| vyvup | Need to say that my setup is a bit more Frankensteinian than regular Cups: I use foomatic-rip directly and thus just use the cups-filter infrastructure | 14:55.36 |
| kens | Fair enough, but it 'looked like' the original bug reporter on 703017 was using CUPS, or something like it | 14:56.04 |
| | Again it wasn't completely clear. I'm not criticising because I suspect language was a barrier here. | 14:56.25 |
| chrisl | vyvup: foomatic is another layer of complication that I don't really understand :-( | 14:56.47 |
| kens | Ahy, seems foomatic is using PostScript as its exchange format, not PDF | 14:57.39 |
| chrisl | WTF??? | 14:57.50 |
| kens | or 'spool file' | 14:57.52 |
| vyvup | My setup is similar to http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/print/cups-filters/pkg/README?rev=1.12&content-type=text/x-cvsweb-markup | 14:58.00 |
| kens | I'm only going by what Wikipedia says, not a totally reliable source | 14:58.06 |
| vyvup | Which ends up doing a2ps -> foomatic-rip | 14:58.29 |
| chrisl | Yeh, I think there is an unnecessary step, there.... | 14:59.01 |
| vyvup | So that a2ps step might introduce such a 'offending' filter chain by accident? | 14:59.02 |
| kens | Err possibly yes | 14:59.11 |
| | chrisl is better informed than me on this subject | 14:59.25 |
| vyvup | Of course it is nice to just have a2ps in front so you can just send anything to the printer | 14:59.28 |
| | but I recently learned you have to be careful with that ;-) | 15:00.04 |
| kens | I don't really knwo much about a2ps | 15:00.16 |
| vyvup | But I'm very happy that my mystery is solved and have learned a lot of stuff in the process. Thanks for the additional info! | 15:01.12 |
| kens | Doesn't 'look' like it shoudl be involving ps2write at that point. | 15:01.18 |
| | OK I'm pleased to hear its fixed, its always nice to sort out a real problem. | 15:01.51 |
| | You can always catch up with us here if you have other problems. | 15:02.06 |
| vyvup | Great | 15:02.13 |
| kens | I should probably mention that we're on discord too if that's easier for you | 15:02.18 |
| chrisl | I have a feeling if you pass Postscript to cups, it will convert it to PDF. Then back to Postscript for the foomatic-rip end of things | 15:02.35 |
| vyvup | Also kind of cool I was able to find an actual issue in such a fundamental thing as Ghostscript ;-) | 15:02.45 |
| kens | Its not that hard, we get quite a few bug reports :-) | 15:03.08 |
| | Even after all these years..... | 15:03.14 |
| | <<<Back 1 day (to 2020/11/08) | Forward 1 day (to 2020/11/10)>>> | |
Log of #ghostscript at irc.freenode.net.