| <<<Back 1 day (to 2019/07/30) | Fwd 1 day (to 2019/08/01) >>> | 20190731 |
swiftgeek | ps2ps2 seems to output always ps3 format for me | 03:59.28 |
| on ghostscript 9.27 | 03:59.50 |
| so i guess something went wrong with ps2write? | 04:02.20 |
| oh nvm i guess i was looking at wrong thing | 04:05.53 |
| still whatever it is it hangs my printer | 04:20.17 |
| oh got error this time | 04:21.50 |
| http://dpaste.com/3J67P09.txt | 04:23.16 |
kens | swiftgeek, there's no point in sending us a [icture of the problem, if you think you've found a bug you should report it. You will need to include the original file and the command line you used. Note that the ps2write device isn't capable of producing level 3 output. PostScript language level 3 isn't a format, its a language | 07:09.38 |
swiftgeek | kens: confused it with the adobe 3.0 thing on the top, but at this point i'm not sure what is happening | 07:21.11 |
kens | 3.0 is the version of Document Structuring Convenntion being used. 3.0 is the most recent, and its very old | 07:21.48 |
| If you want help with your problem you'll need to make the inptu file and command line available, and the easiest way to do that is a bug report | 07:22.43 |
| which also means it won't get forgotten about | 07:22.52 |
swiftgeek | welp i can't get into shell of the printer or get any debug other than that dpaste thing | 07:23.26 |
| my guess is that it's somehow ran out of memory | 07:23.44 |
kens | No, you need to send us the original file, and the comamnd line you used to get the PostScript output. | 07:23.57 |
| We can debug PostScript output | 07:24.02 |
chrisl | I would suggest a good first step would be to see if Ghostscript can consume it's own (ps2write) output. | 07:24.14 |
kens | That would be my first port of call :-) | 07:24.25 |
swiftgeek | http://h5ai.swiftgeek.net/Notebooks/JHL90/GPIO%20Table%20JHL90.pdf | 07:24.49 |
| and just ps2ps2 without options | 07:25.07 |
kens | Hmm I never use tha shell script | 07:25.28 |
swiftgeek | well i need to use it to print something directly via network | 07:25.44 |
kens | Wht Operating system is this ? Which version of Ghostscript ? What word size (32 or 64) ? | 07:25.47 |
swiftgeek | 9.27 x86_64 | 07:26.04 |
kens | OS ? | 07:26.28 |
swiftgeek | archlinux | 07:26.41 |
kens | OK so where did you get GS ? Was it a package, or built from our source ? | 07:26.57 |
swiftgeek | pacakge | 07:27.04 |
| *package | 07:27.09 |
kens | Then it may be a problem with changes made by the packager. I'll need a minute to try this locally | 07:27.26 |
swiftgeek | there are no changes made by packager in arch | 07:27.40 |
chrisl | Well, that PDF must have transparency in it, because it seems to just end up as a couple of big images | 07:28.25 |
kens | Probably its a Cairo PDF then | 07:28.45 |
chrisl | pdf-Tex apparently | 07:29.15 |
kens | Well the output works for me feeding it back into GS | 07:29.29 |
| Also Acrobat Distiller | 07:30.03 |
chrisl | The one guess I could make would be to disable the image compression | 07:30.27 |
swiftgeek | pdf created via libreoffice (and trimmed with pdfjam) | 07:30.30 |
| i'm not aware of any images :D | 07:30.48 |
chrisl | The Postscript output is just two image | 07:31.00 |
kens | The presence of transparency means that ps2write has to render the whole page to an image | 07:31.09 |
| A 3rd party PostScript rip also renders the file without problem | 07:31.32 |
swiftgeek | i don't recall ability to set anything transparent in libreoffice | 07:31.42 |
chrisl | As expected, disabling transparency makes no difference to the output | 07:31.53 |
swiftgeek | (and i tried because i wanted transparent text in few places) | 07:31.56 |
kens | PDF producers often use transparency (pointlessly) | 07:32.02 |
| idiv | 07:32.17 |
chrisl | None of the calls to idiv look suspicious | 07:32.43 |
kens | There's no 5000 in there either | 07:33.16 |
| Give me a minute and I'll stick my output file on | 07:33.38 |
| DopBox | 07:33.43 |
swiftgeek | chrisl: how did you disable transparency ? | 07:34.48 |
chrisl | -dNOTRANSPARENCY | 07:35.01 |
swiftgeek | chrisl: that prints fine | 07:36.24 |
chrisl | It's not really a solution, though, since a file with genuinely transparent objects won't print correctly | 07:37.42 |
kens | My output file is here: | 07:37.46 |
| https://www.dropbox.com/s/6m6jfrx5scp7xw3/out.ps?dl=0 | 07:37.46 |
swiftgeek | dropbox requires registering now lol | 07:38.43 |
| oh there is a skip | 07:38.57 |
kens | Yeah I had to renew my password, it had expired due to lack of use | 07:39.06 |
| The original PDF file has transparency Group objects on each page, has multiple Form XObjects, each of which has a transparency Group | 07:39.44 |
swiftgeek | so i have to use that parameter to print libreoffice docs lol | 07:40.55 |
| kens: yeah it hangs on yours as well | 07:41.19 |
kens | Well I'd have to point the finger at your printer | 07:41.31 |
swiftgeek | welp | 07:41.43 |
kens | But its possible its simply exhausting resources, because those are fairly large images | 07:41.49 |
swiftgeek | i will be replacing that with custom allwinner board soon ™ | 07:41.56 |
kens | You could try setting -r300 or -r150 to drop the resolution of the images and see if it helps | 07:42.21 |
swiftgeek | http://h5ai.swiftgeek.net/Embedded/HP1320n/Formatter/ | 07:42.30 |
| are there any printers out there with ghostscript inside? | 07:45.28 |
kens | Very, very few | 07:45.38 |
swiftgeek | any oshw ? :D | 07:45.47 |
chrisl | The images are LZW compressed, and we've had problems with poor LZW implementations before | 07:46.04 |
kens | chrisl it looks to me more lie its a problem with PutObject or GetObject | 07:46.25 |
| Those do a ObjectRegistryMaxLength idiv and ObjectRegistry<axLength is 50000 | 07:46.46 |
| swiftgeek: can you put your PostScript file somewhere please ? | 07:47.08 |
chrisl | kens: I'm just thinking through the issues we had with Brother and Kyo printers... the symptoms were not always obviously related to the cause | 07:47.38 |
kens | Yes, and you're right of course, poor LZW implementations have been problematic in the past | 07:48.05 |
swiftgeek | well can't really debug, it uses some more obscure headers for debug, with different pin count | 07:48.36 |
| and SoC is custom as well | 07:48.48 |
chrisl | I'm assuming this is an HP printer? | 07:48.59 |
swiftgeek | yes | 07:49.03 |
| well | 07:49.13 |
kens | Hmm, well I could try my printer, its an HP | 07:49.14 |
swiftgeek | formatter part is | 07:49.18 |
| otherwise canon | 07:49.21 |
chrisl | So the Postscript is from Canon? | 07:49.33 |
swiftgeek | interpreter ? from hp (formatter) | 07:49.49 |
| or video card if you prefer | 07:49.55 |
chrisl | Hmm, even that doesn't help much, considering the number of different Postscript interpreters HP use :-( | 07:50.35 |
| Although, I don't think we ever hit an issue with Adobe PS | 07:51.07 |
swiftgeek | yeah i would probably need to dump firmware from it, but without pinout it will be hard to get anything from this coldfire | 07:51.10 |
| also fun thing | 07:52.02 |
chrisl | We've debugged in the past by instrumenting Postscript, but it's a slow, painful process... and I doubt we have time right now | 07:52.05 |
swiftgeek | if i attempt to print this via network driver | 07:52.13 |
| it starts complaining about paper jam | 07:52.30 |
| so i think this file has definitely exploit in it somewhere | 07:52.59 |
| xD | 07:53.01 |
kens | -dCompressStreams=false might produce uncompressed images | 07:53.19 |
| That might work | 07:53.23 |
swiftgeek | i will reboot printer just to be sure xD | 07:53.42 |
chrisl | kens: I still get LZW image data | 07:54.46 |
kens | drat | 07:54.59 |
swiftgeek | seems to be hanging | 07:55.40 |
| (printer should have 126MiB of ram to spare) | 07:56.17 |
chrisl | That may be a lot, it may be not much - depends on the implementation | 07:56.53 |
swiftgeek | btw from what i have noticed, most if not all of those older laserjets are actually canon with hp formatter (and plastic bits) | 08:00.07 |
chrisl | Well..... my LaserJet 400 printer the ps2write output from 9.26 just fine (if a bit slow) | 08:00.59 |
swiftgeek | that looks new ;D | 08:01.25 |
chrisl | Depends on your definition of "new" | 08:02.29 |
swiftgeek | chrisl: still canon though | 08:03.11 |
| not sure which one | 08:03.24 |
chrisl | The bit we're interested in is HP | 08:03.49 |
swiftgeek | or reverse if you would ever want to replace it with linux board running ghostscript :D | 08:05.19 |
| sadly can't find it easily | 08:07.39 |
| ah the ps thing | 08:09.15 |
| http://h5ai.swiftgeek.net/Notebooks/JHL90/GPIO%20Table%20JHL90.ps | 08:09.17 |
kens | yes that's essentially the same as ours | 08:10.47 |
| and also works when run through GS and Distiller | 08:11.26 |
swiftgeek | -r150 didn't seem to work | 08:12.22 |
kens | Well then its probably not the sheer size | 08:13.21 |
swiftgeek | oh it kinda worked | 08:13.30 |
kens | Most likely a problem with the LZW implementation as Chris said | 08:13.33 |
swiftgeek | first page yes, 2nd nope | 08:13.37 |
kens | Hmm | 08:13.44 |
| Well you coudl do it as 2 pages | 08:13.50 |
swiftgeek | and quality dropped visibly | 08:13.53 |
kens | 2 files that is | 08:13.56 |
| The quality will eb worse, certainly | 08:14.04 |
| Instea dof rendering the image at 720 dpi its 150 dpi | 08:14.15 |
swiftgeek | well just wanted to say that -r150 definitely engaged | 08:14.27 |
kens | You could try 300 I guess | 08:14.27 |
| The thing is changing the resolution will also change the LZW data | 08:14.48 |
| So it may not trigger the decoding error | 08:14.56 |
swiftgeek | well since 2nd page was blank it definitely triggered it xD | 08:15.10 |
kens | Triggered 'something' | 08:15.24 |
swiftgeek | hmmmmm | 08:15.26 |
| are those transparent things | 08:15.35 |
kens | Could still be resoruce exhaustion perhaps | 08:15.36 |
swiftgeek | 100% transparent ? | 08:15.39 |
kens | either 100% transparent or 100% opaque | 08:15.50 |
| I think in this case there is *no* transparency at all | 08:16.02 |
| everything is opaque | 08:16.07 |
| But the transparency stuff is in there, and we can't tell in advance that it has no effect | 08:16.25 |
swiftgeek | i mean you mentioned that pdf contains transparency | 08:16.27 |
kens | It contains Group objects | 08:16.38 |
swiftgeek | ah | 08:16.38 |
kens | Which are a transparency feature | 08:16.43 |
| But they don't actually *do* anything | 08:16.50 |
| Its just that we can't tell, at least not without parsing the entire content of the page before we render it which would be slow | 08:17.11 |
swiftgeek | i though it would possible to detect such thing and enable dNOTRANSPARENCY automatically | 08:17.16 |
kens | We'd have to parse the entire page | 08:17.29 |
| Which woudl slow down every job for the benefit of those badly constructed files | 08:17.47 |
| we'd slow down everyone | 08:17.51 |
swiftgeek | -dAUTOTRANSPARENCY /s | 08:18.15 |
kens | It would be very slow, you can have soft mask images, which would mean we'd have to examine every sample of every image | 08:18.51 |
| We already do a degree of checking, we look for certain objects in teh resource tree, and we only use constanat alpha as a check if its no 1, things like that | 08:19.37 |
swiftgeek | so you say it's better to blame poppler/cairo at this point for this mess :P | 08:20.46 |
kens | Well the producer is embedding transparency directives in a file which doesn't use it | 08:21.19 |
| I'd say that is the fault of the producer and expecting the consumer to detect and rectify the problem is unreasonable :-) | 08:21.42 |
chrisl | The only way to tell *for sure* whether transparency in a job has a "real" effect is to render the file with and without transparency enabled, and compare the output - that's not really feasible | 08:21.58 |
swiftgeek | chrisl: well in this case document doesn't have any | 08:22.24 |
| so if something was added it would be like 100% transparent | 08:22.37 |
kens | Yes but the consumer can't easily tell that | 08:23.00 |
chrisl | swiftgeek: We'll investigate adding prescience to Ghostscript when we have the time | 08:23.11 |
kens | PDF transparency is, well, complictaed.... | 08:23.13 |
swiftgeek | pdf is complicated :D | 08:23.22 |
| chrisl: just wanted to point out that rendering doesn't have to be done, i uncropped way too many images from pdfs | 08:24.16 |
chrisl | swiftgeek: And our point is: how do we *know* that, in the general case | 08:24.51 |
swiftgeek | well i just imagined that it would be possible to just look at alpha channel of objects but i don't know anything about the format irl | 08:25.46 |
chrisl | The problem is that PDF transparecy isn't simply alpha blending | 08:26.09 |
kens | Like I said, PDF transparency is complictaed | 08:26.27 |
swiftgeek | pdf spec works in mysterious ways | 08:26.35 |
kens | alpha blending is the simplest part | 08:26.39 |
| And we do check for an alpha which is neither 0 nor 1 | 08:26.53 |
| If constant alpha is the only kind of transparency, and CA and ca are always either 0 or 1, then we don't regard the file as using transparency | 08:27.40 |
| But transparency groups mean the file is *always* transparent | 08:28.00 |
| Because we can't trivially determine the result of a trnsparency group | 08:28.12 |
| Your file has a Group for each page. Each page contents is nothign but a Form XObject (which is dumb as well), each of the Forms also has a Group | 08:28.56 |
swiftgeek | tried disabling transparency in printing options of libreoffice but result is the same | 08:35.10 |
kens | I suspect its the back-end graphics library, not LibreOffice itself | 08:35.47 |
| So presumably Cairo, its certainly looks a lot like Cairo output | 08:35.58 |
swiftgeek | so out of libreoffice -> poppler -> cairo, cairo is to blame? | 08:37.15 |
kens | 'blame' is perhaps too strong. Assuming Cairo is involved then I would say that its output is sub optimal | 08:37.51 |
| Since it involves transparency on the output when there is none | 08:38.04 |
swiftgeek | great other poppler backend is called splash | 08:39.16 |
| there is no way i will be able to find info how to switch to that xD | 08:39.28 |
kens | Not familiar with that | 08:39.34 |
chrisl | I thought splash was bitmap/pixmap only, no vectors | 08:41.08 |
swiftgeek | oh i guess that it's true looking by source tree | 08:42.45 |
kens | chrisl do you want to answer #701376 or leave ti to me ? | 08:45.43 |
| I'm guessing he's not using our solution | 08:46.01 |
chrisl | kens: I'll reply, I suppose | 08:46.54 |
kens | OK thanks | 08:47.00 |
chrisl | Having said that, I've no idea what he's bleating about...... | 08:47.43 |
kens | Well, no arch.h | 08:48.02 |
| Which would suggest (to me) that he's using his own solution and not our namke-based solution | 08:48.18 |
chrisl | Yeh, but all he says he's doing is adding a couple of options to nmake | 08:48.23 |
kens | Which means he isn't running genarch | 08:48.24 |
chrisl | 'I do this by adding these options to the nmake process XCFLAGS="-DGS_THREADSAFE=1 -USEUNICODE=1"' | 08:48.52 |
kens | Hmm | 08:48.53 |
| I guess then he should be asked how he's running name | 08:49.12 |
| And how he's adding the flags | 08:49.48 |
| Like I said, I can do it if you wold prefer | 08:50.04 |
chrisl | You use XCFLAGS at the nmake command line | 08:50.15 |
kens | I know but I'm not convinced he's doing that | 08:50.41 |
| Oh God, its achmea :-( | 08:51.09 |
| swiftgeek: One last thing you could try. put: | 08:57.51 |
| -c "<</EncodeColorImages false>> setdistillerparams" -f | 08:57.51 |
| immediately before the inptu filename | 08:57.56 |
| That will produce a *much* larger file, ~370 MB | 08:58.08 |
| The images are uncompressed which may get round your problem (or may not) | 08:58.21 |
| Given the size of the image data I'm suspicious that its simply that there is too much data for the printer | 08:58.44 |
swiftgeek | that's way above of my free ram in printer ;D | 08:59.21 |
kens | Its 2 pages | 08:59.31 |
| So half that per page | 08:59.37 |
| And PostScript is stream-based so it *shouldn't* be trying to read the whole thing | 08:59.54 |
swiftgeek | still above | 09:00.03 |
kens | It shouldn't matter | 09:00.16 |
| Unless you are trying to store the whole file in the printer memory | 09:00.31 |
| Which isn't how PostScript normally works | 09:00.37 |
| It reads the data as it arrives and discards it as it goes. | 09:00.53 |
| You do need to be able to read one scan line of image data of course | 09:01.02 |
| But that's a lot less than the data here | 09:01.13 |
swiftgeek | -c\ " | 09:03.10 |
kens | ? | 09:03.40 |
swiftgeek | to make it work, \ was missing | 09:04.12 |
kens | You shouldn't need a '\' | 09:04.24 |
swiftgeek | with ps2ps2 i do | 09:04.42 |
kens | Well I wouldn't use the script personally | 09:05.01 |
| just do -sDEVICE=ps2write -sOutputFile=<out.ps> | 09:05.17 |
| I dislike the inane complexity of the scripts | 09:05.35 |
swiftgeek | in any case | 09:05.41 |
| it's feeding but so slowly | 09:05.49 |
| it will take forever | 09:05.53 |
kens | Well sending that much data will take a while | 09:06.02 |
swiftgeek | looks like days | 09:06.13 |
kens | Well again you coudl decrease the resolution. I expect 720 dpi is above the resolution of your printer | 09:06.47 |
| And for contone data you don't even need to match it. | 09:07.01 |
| I'd expect 300 dpi would produce reasonable results | 09:07.13 |
swiftgeek | -dNOTRANSPARENCY works fine :P | 09:07.31 |
kens | That's another solution, but if you ever find a file which actually *uses* transparency, then the rendered output will be incorrect | 09:07.58 |
| Assuming the job runs to completion on your pritner I'd venture a guess that the LZW decode filter is faulty. | 09:08.32 |
swiftgeek | well i'm just pushing ps over 9100 | 09:08.55 |
| <<<Back 1 day (to 2019/07/30) | Forward 1 day (to 2019/08/01)>>> | |