| | <<<Back 1 day (to 2012/04/10) | 2012/04/11 |
| kens | henrys again for the logs. Not to worry about the font cache, its not causing me significant problems. I guess I should check sometiem that it is properly discarding elements as required, but I'm reasonably sure it must be. So its not a leak as far as I'm concerned. | 07:58.40 |
| | henrys I'm not sure what you meant by 'grep them away'. Each time I make a code change the numbers change, so I can't just discard the numbers easily. Also, sadly, VS seems disinclined to let me redirect the output to a file. It works on the command line but not in the debugger (which is werid, because I thought it did) | 08:00.38 |
| | Robin_Watts : henrys the labels I see are almost entirely composed of 'chunk_mem_node_add' | 08:10.57 |
| Robin_Watts | kens: Yes, I was worried that that might be the case :( | 08:38.34 |
| kens | Not to worry. | 08:38.53 |
| | More of a problem is that I can't reproduce the cluster seg faults locally. | 08:39.07 |
| Robin_Watts | I think I can get proper names in there with a small hack. | 08:42.08 |
| kens | WHat do you mean by 'proper names ' ? | 08:42.28 |
| Robin_Watts | The proper client name rather than "chunk_mem_node_add" | 08:44.03 |
| kens | Well, that would be interesting, certainly. | 08:44.15 |
| | Might tell me more about where to conentrate | 08:44.24 |
| | But don't do anything which will take a lot of your time, I can manage fine as it is | 08:44.46 |
| Robin_Watts | I think I have it. | 08:46.49 |
| kens | THat was quick... | 08:47.03 |
| Robin_Watts | Like I say, it's just a small hack. | 08:49.45 |
| | testing it is the slow bit :) | 08:50.24 |
| kens | Well I can try it out quickly | 08:50.34 |
| Robin_Watts | OK, committed. | 08:53.47 |
| kens | Give me a minute | 08:54.00 |
| | OK building now | 08:57.10 |
| | Hmm, did you intend to commit the HPGL path handling at the same time ? | 08:59.14 |
| | Hmm yes that does give a *lot* more information | 09:01.16 |
| | Looks like I haven't compeltely cleaned up fonts yet. | 09:02.57 |
| | I think I need to know the command line Marcos is using fot the PCL interpreter when creating PDF from tehse files, they won't seg fault for me. Tried debug and release builds. | 09:05.29 |
| Robin_Watts | kens: Oh, ass, no. | 09:06.04 |
| | kens: OK, sorry, I committed the wrong thing. | 09:06.51 |
| | I've force pushed the right thing. | 09:06.55 |
| | kens: I can get that command line for you if you want. | 09:07.32 |
| kens | Yes please. | 09:09.06 |
| | Robin_Watts : looked lilke you comiited both the HPGL and the memory fix together | 09:09.24 |
| Robin_Watts | kens: yes, hence my "oh ass". | 09:09.35 |
| kens | The labelling works OK (or so it seems) | 09:09.35 |
| Robin_Watts | I've force pushed a fix. | 09:09.42 |
| kens | Thansk, I'll update my code. | 09:09.54 |
| Robin_Watts | On the dashboard, click on 'logs' then on a log file. Then search for "pcl pdfwrite" | 09:10.29 |
| | And you'll see the exact commands used for each job. | 09:10.43 |
| | ./gs/bin/pcl6 -sOutputFile=./temp/tests_private__customer_tests__hd104dwf.pcl.pdf.ppmraw.600.0.pdf -sDEVICE=pdfwrite -r600 -dNOPAUSE -dBATCH -dClusterJob ./tests_private/customer_tests/hd104dwf.pcl | 09:10.51 |
| | then | 09:10.53 |
| kens | Aha, right, I thought there was a way to do that | 09:10.53 |
| Robin_Watts | ./gs/bin/gs -sOutputFile='| md5sum >>./temp/tests_private__customer_tests__hd104dwf.pcl.pdf.ppmraw.600.0.md5' -dMaxBitmap=30000000 -sDEVICE=ppmraw -r600 -dNOPAUSE -dBATCH -K1000000 -dClusterJob -dJOBSERVER ./temp/tests_private__customer_tests__hd104dwf.pcl.pdf.ppmraw.600.0.pdf | 09:11.05 |
| | actually, I think marcosw has reversed the order somehow :) | 09:11.44 |
| | No, ignore me. | 09:11.57 |
| kens | Hmm -dClusterJob, I wonder what that does ? | 09:12.41 |
| | I guess it must be the -r600 that#'s different. | 09:13.38 |
| | Hmm still doesn't crash, that's disappointing. | 09:19.02 |
| | I may have to try debugging this on a cluster machine :-( | 09:19.37 |
| Robin_Watts | kens: cluster machines are 64bit linux. | 09:21.01 |
| kens | I know, and my VM is 32-bit Linux | 09:21.16 |
| | Anyway, time to go, back in a couple of hours | 09:22.56 |
| tkamppeter | chrisl, hi | 09:49.01 |
| chrisl | tkamppeter: hi | 09:49.40 |
| naveen_ | Hi Robin,I have extended the document interface to offer fz_open_document_with_stream. Can you let me know how to create fz_stream from java ? | 09:51.46 |
| tkamppeter | chrisl, about the slowdown vs. resolution problem, WDYT, should I generally remnder images with 300/360 dpi or should I introduce a Kyocera-only workaround which does this reduction only for Kyocera? | 09:51.52 |
| chrisl | tkamppeter: I think using 300 dpi has been producing acceptable results up to now, so go with the 300/360 dpi. That will also resolve a number of the issues with Ghostscript taking longer to convert PDFs with transparency in them. | 09:54.34 |
| | tkamppeter: IIRC, cups has a "Quality" setting, doesn't it? So maybe "Normal" could be 300/360dpi, and "High/Best" could use the alleged highest resolution from the PPD? ("Fast" could be 150/180 dpi, or something) | 09:57.07 |
| | ppd: I have a question for you: if you scan an A4 page @1200dpi, and then print the image, does it take a long time to print (like the GS output)? | 09:59.50 |
| ppd | chrisl: does it matter which application I print it with? | 10:00.27 |
| Robin_Watts | naveen_: Hi. | 10:00.47 |
| | From java? | 10:00.53 |
| | fz_open_memory is the function that will go from a block of memory to a stream for you. | 10:01.10 |
| | But that's in C. | 10:01.26 |
| | You're doing this with the android port, right? | 10:01.48 |
| chrisl | ppd: I would try something like gimp, as it's less likely to resample the image as it prints. Or even use something that converts the image to PS directly (like tiff2ps), although you might need to hand edit to add the PJL preamble | 10:02.08 |
| ppd | chrisl: well, let's stick to gimp then | 10:02.47 |
| naveen_ | yes Robin.. | 10:03.16 |
| chrisl | ppd: :-) basically, I'm trying to figure if this is a "bug" in the Kyo printer, in which case, a special case in cups would be fine. | 10:03.23 |
| Robin_Watts | So, the java stuff will need to be extended too. | 10:03.38 |
| | Let me look. | 10:03.41 |
| ppd | chrisl: you'll have to wait a few minutes though. I'm back in office after a short break | 10:03.42 |
| chrisl | ppd: no problem - this is definitely "above and beyond" as far as required testing is concerned....... | 10:04.23 |
| | tkamppeter: you said before you had access to an HP PS printer - I take it that does not suffer performance issues if you send it image data at it's highest resolution? | 10:05.26 |
| Robin_Watts | naveen_: In android/jni/mupdf.c see Java_com_artifex_mupdf_MuPDFCore_openFile | 10:05.48 |
| naveen_ | yes,I have it open | 10:06.03 |
| Robin_Watts | I'd imagine we wanted a new function that does more or less the same as that, say: Java_com_artifex_mupdf_MuPDFCore_openArray | 10:06.26 |
| | and instead of passing in a jstring jfilename, you'd pass in a, urm... whatever the incantation for an array is. | 10:07.02 |
| | Then we'd lose the filename = ... stuff. | 10:07.13 |
| | and instead of calling fz_opn_document you'd call fz_open_document_with_stream | 10:07.43 |
| | oh, but before that you'd need to get the address of the array contents from java, and call fz_open_memory on that. | 10:08.20 |
| | (So, it'd be a byte array) | 10:08.38 |
| | Does that make any sense? | 10:08.42 |
| | I can't give you chapter and verse on the exact calls to make without digging a bit - my java jni experience is limited. | 10:09.15 |
| naveen_ | yes, it makes sense.. | 10:09.43 |
| | I have a byte array in java..I'll try to pass that byte array as parameter to fz_open_document_with_stream.. | 10:10.40 |
| | I see something like "â¢fz_open_buffer()"...so is it also possible to use BufferedReader from java? | 10:11.33 |
| Robin_Watts | We have an fz_buffer type in mupdf. It's basically just a wrapper around a block of memory. | 10:13.07 |
| | fz_open_buffer makes a stream from one of those (as opposed to fz_open_memory that operates on a raw memory block). | 10:13.46 |
| | It has nothing to do with Javas BufferedReader. | 10:13.55 |
| naveen_ | ok... | 10:15.08 |
| | let me try with byte array and see if it works... | 10:15.26 |
| Robin_Watts | I'm heading out for a run. back in an hour or so. | 10:17.09 |
| ppd | chrisl: our scanner does only 600x600 dpi. Shall I try it nonetheless? | 10:44.18 |
| chrisl | ppd: you can scan at 600dpi, then use gimp to scale up by 2x to get 1200dpi | 10:47.29 |
| ppd | chrisl: color or grayscale, does it matter for us? | 10:48.02 |
| chrisl | ppd: let's do color, as that's the closest to the cups workflow output. | 10:49.00 |
| ppd | chrisl: this scanner saves as pdf on the server. I can import those into gimp. I can set the resolution as pixels/inch, shall I put 1200 there? | 10:50.52 |
| chrisl | ppd: sure, that sounds okay | 10:51.27 |
| ppd | wow. 9920x14030 pixels. does that sound right for a picture being sent to the printer? | 10:52.52 |
| chrisl | Erm, could be. just a sec | 10:53.35 |
| | ppd: actually that's about double the resolution I'd expect, so maybe a good idea to scale down - so we get about 5546 x 7565 | 10:57.31 |
| ppd | I'll scale down to 5546x7844. it's A4 | 10:58.22 |
| chrisl | Yep, perfect (I just lifted the numbers from the GS created PS from your test job) | 10:59.06 |
| ppd | resolution stays at 1200x1200 in the scale dialog I guess? | 10:59.32 |
| chrisl | <shrug> I guess so..... | 11:00.10 |
| ppd | quite confusing... hmm.. okay. I centered and maximized the pciture on the page. It displays resolution as "689,983x...." | 11:07.21 |
| chrisl | ppd: hmm, would it easier if I created a PS file for you to just stream to the printer? | 11:08.16 |
| ppd | chrisl: obviously | 11:09.12 |
| chrisl | ppd: :-) okay let me do that - it'll take a minute or two | 11:09.39 |
| | Holy crap - BIG file..... | 11:12.04 |
| | ppd: http://www.ghostscript.com/~chrisl/Unbenannt_1-tests.tgz | 11:15.39 |
| | ppd: oh, hang on, forgot something..... | 11:16.11 |
| | ppd: okay, sorry about that - I forgot some of the printer specific preample I had to add, but it's there now: http://www.ghostscript.com/~chrisl/Unbenannt_1-tests.tgz | 11:21.42 |
| chrisl | going to lunch...... | 11:24.51 |
| ppd | nice | 11:28.12 |
| chrisl | ppd: meant to say, in case it's not obvious: two tests in there, one rendered to 1200dpi tiff and the other to 600dpi tiff - then I used tiff2ps to dump the image data in a PS "wrapper". | 11:39.20 |
| | Hmm, cluster seems to be borked :-( | 11:41.03 |
| Robin_Watts | let me see if I can unbork it. | 11:44.43 |
| tkamppeter | chrisl, I have tried with 2 HP printers now, both Ghostscript's processing times and the processing times of the printers are more or less proportional to the number of pixels in the bitmap, the 300 dpi vs. 360 dpi oddness seems to not slow down HP printers. | 11:48.48 |
| Robin_Watts | chrisl: Let's give it a few minutes to see if it recovers from that. | 11:49.37 |
| chrisl | Robin_Watts: cheers - is there an easy way to give it a nudge? It might be good if we weren't reliant on you or Marcos to always do that. | 11:50.28 |
| Robin_Watts | chrisl: We should ask Marcos for a script, yes. | 11:50.50 |
| tkamppeter | chrisl, so generally the fix would be to use a low resolution. Currently the used resolution depends on the user's setting for resolution (not the printers max resolution). | 11:51.09 |
| ppd | chrisl: I'm back. let's feed this stuff to our beloved kyocera crap | 11:51.12 |
| chrisl | tkamppeter: Interesting, it does sound to me like using a lower resolution is worthwhile (although not vital) on other printers. In general, the "rule of thumb" is that you can use HWResolution/3 with virtually no visible quality loss, and anything higher than HWResolution/2 is pretty much a wast of time and bandwidth. Although I would never go below 300dpi for "normal" printing. | 11:52.55 |
| ppd | chrisl: 600 dpi -> processing... | 11:52.55 |
| tkamppeter | chrisl, but this requires that the PPD has a Resolution option with XXXdpi or XXXxYYYdpi settings or any option with PostScript commands setting the resolution. | 11:53.01 |
| chrisl | ppd: I fully expect you'll have to kill the 1200dpi one, possibly the 600dpi one, too. | 11:53.37 |
| ppd | chrisl: yeah. 600 dpi one is still processing. this will take forever | 11:54.42 |
| | should this render in a few seconds on a decent printer? How long am I supposed to wait? | 11:55.51 |
| | real4m2.281s | 11:56.20 |
| | for the 600 dpi one | 11:56.27 |
| tkamppeter | ppd, on my slower HP 720 dpi takes 5 min. | 11:56.37 |
| chrisl | ppd: yeh, kill it - it should *not* take this long! | 11:56.42 |
| ppd | it came out this second | 11:56.50 |
| chrisl | Well, I don't think that's acceptable for what is a pretty common use case (scan'n'print), IMHO - I know I said it before, but I would report this to Kyocera...... | 11:57.42 |
| tkamppeter | chrisl, so I will use the HWResolution/2 approach, or should I better go /4? I do not know whether /3 is that good, deviding by an odd number. | 11:59.33 |
| chrisl | tkamppeter: odd or even shouldn't matter, as long as it's an integer diviser - personally, I'd go for HWResolution/3 with minimum value of 300dpi, and a default of 300dpi is the HWResolution isn't available. | 12:01.12 |
| tkamppeter | chrisl, OK, I will try this. | 12:01.53 |
| chrisl | tkamppeter: the good thing there is that we'll *never* be worse than the old filter, but in some cases, we'll be (very slightly!) better. | 12:03.19 |
| | in terms of output quality, that is | 12:03.33 |
| ppd | chrisl: what exactly would I be telling kyocera if I called them? Can I send them the bug reports or what would be the best? | 12:04.15 |
| chrisl | ppd: usually, there's a webform of some kind on the manufacturer's web site you can fill out. | 12:05.25 |
| ppd | tkamppeter: if you have something for me to test, I'll be here for a few hours | 12:07.53 |
| | chrisl: yes. would be "your printer takes way too long to render valid postscript of this sort (attach ps file here)." appropriate? ;-) | 12:09.03 |
| Robin_Watts | chrisl: cluster seems to be whirring again. | 12:10.05 |
| | naveen_: How goes it? | 12:10.33 |
| chrisl | ppd: something like that. I was think I could make you a 300dpi example, and a 600dpi example (and 1200 if you want!), and you can report that the 300dpi goes like lightening, and the 600dpi like a lethargic snail...... | 12:10.41 |
| | Robin_Watts: thanks. | 12:10.46 |
| ppd | chrisl: that would be bullet-proof | 12:11.52 |
| kens | chrisl Robin_Watts got some cluster questions.... | 12:12.18 |
| chrisl | ppd: it's what I did for the folks who wanted to report their problems to Brother. So did you want the 1200dpi one, too? | 12:12.34 |
| kens | AIUI the /home/marcos/cluster/users/<user> directory is where the personal cluster run binaries are built | 12:12.52 |
| | The log says that cPCL6 is executed by ./gs/bin/pcl6 | 12:13.11 |
| chrisl | I thought it was /home/regression/cluster..... | 12:13.37 |
| kens | But in my tree the ghostpdl/gs/bin directory has no pcl6 executable | 12:13.42 |
| | There's no cluster in /home/regression | 12:14.03 |
| ppd | chrisl: The 600 dpi took 5 minutes where the 300 dpi one took 0.3 seconds. I think that is drastic enough | 12:14.13 |
| chrisl | ppd: fair enough - I'll just double check the test files, and then upload them for you | 12:14.41 |
| kens | chrisl Nor is there a 'users' directory. | 12:14.50 |
| | in /home/marcos/cluster/users/ken/ghostpdl/main/obj there is a PCL6 which is built 'recently' | 12:15.26 |
| | (this is on peeves by the way) | 12:15.41 |
| Robin_Watts | sorry, back. | 12:16.47 |
| | On casper it's /home/regression/cluster | 12:17.10 |
| kens | However, if I run that executable using the cluster command line which repreoduces a seg fault, it doesn't seg fault for me. | 12:17.12 |
| Robin_Watts | On other other cluster nodes it's different | 12:17.37 |
| kens | Not on peeves. I guess I can try casper | 12:17.42 |
| Robin_Watts | kens: OK, so which particular job are you looking at? | 12:17.52 |
| kens | ap301dwo.pcl | 12:18.06 |
| Robin_Watts | what res/options? | 12:18.14 |
| kens | ./gs/bin/pcl6 -sOutputFile=./temp/tests_private__customer_tests__ap301dwo.pcl.pdf.ppmraw.600.0.pdf -sDEVICE=pdfwrite -r600 -dNOPAUSE -dBATCH -dClusterJob ./tests_private/customer_tests/ap301dwo.pcl | 12:18.35 |
| | That's what the log file says | 12:18.52 |
| | Notice the './gs/bin/pcl6' | 12:19.23 |
| | That's not correct for peeves as far as I can see. | 12:19.36 |
| | Note that the log was for inches | 12:19.42 |
| chrisl | it could be just a typo in logging...... | 12:19.55 |
| kens | Quite a typo | 12:20.06 |
| | I beleive it ought to be ./main/obj/pcl6 | 12:20.21 |
| Robin_Watts | Ok, that job ran on inches, not peeves. | 12:20.34 |
| kens | Yes, but it previously failed on other machiens as well, and I don't think I can login to inches | 12:20.58 |
| Robin_Watts | OK. Can you find an example that actually ran on peeves? | 12:21.14 |
| chrisl | ppd: http://www.ghostscript.com/~chrisl/For_Kyocera.tgz | 12:21.18 |
| ppd | chrisl: thanks a lot | 12:21.30 |
| kens | Robin_Watts : I'll try.... | 12:21.38 |
| chrisl | ppd: two tests, one at 300dpi and one at 600dpi. These are about as simple as they get - both contain only the image, and a *tiny* amount of PS boiler plate. | 12:22.11 |
| kens | Robin_Watts : "PWTTCSC3.BIN" I'll just find the log entry | 12:22.20 |
| Robin_Watts | tests_private__pcl__pcl5cats__Subset__PWTTCSC3.BIN.pdf.ppmraw.600.0 | 12:22.48 |
| kens | Yes | 12:22.52 |
| Robin_Watts | ./gs/bin/pcl6 -sOutputFile=./temp/tests_private__pcl__pcl5cats__Subset__PWTTCSC3.BIN.pdf.ppmraw.600.0.pdf -sDEVICE=pdfwrite -r600 -dNOPAUSE -dBATCH -dClusterJob ./tests_private/pcl/pcl5cats/Subset/PWTTCSC3.BIN | 12:23.02 |
| | Command terminated by signal 11 | 12:23.04 |
| | So, let's try that one. | 12:23.06 |
| kens | Again notice the log file says "./gs/bin/pcl6" | 12:23.12 |
| Robin_Watts | Yes, that's to be expected I think. | 12:23.24 |
| kens | Really ? the executable doesn't exist as far as I can tell. Does it get deleted ? | 12:23.45 |
| Robin_Watts | /home/marcos/cluster/gs/bin/pcl6 exists. | 12:24.27 |
| | But it only contains the most recently built exes. | 12:24.41 |
| kens | Hmm, but that probably isn't my copy any more :-) | 12:24.44 |
| Robin_Watts | You need to look in your user dir, as you said. | 12:24.55 |
| | but that explains the logging. | 12:24.59 |
| kens | I'll use the executable in 'my' directory | 12:25.01 |
| | Aha, that does actually seg fault | 12:25.51 |
| Robin_Watts | chrisl: And the cluster is finally running your job. | 12:26.45 |
| chrisl | Robin_Watts: ta! | 12:27.00 |
| | kens: the cluster code copies the pcl6 exe into the gs/bin directory | 12:27.26 |
| kens | chrisl I had inferred that :-) | 12:27.42 |
| chrisl | kens: I was just confirming because I just found it in the code | 12:28.16 |
| kens | Rats, can't maek a debug build, don't have permissions | 12:28.32 |
| | Lets try this from my home | 12:28.55 |
| chrisl | kens: but you're sort now? I feel slightly unclean just *looking* at perl code :-( | 12:29.23 |
| | s/sort/sorted | 12:29.33 |
| kens | chrisl well I'm making progress slowly | 12:29.37 |
| | I need a debug build that goes wrong. | 12:29.48 |
| Robin_Watts | chrisl: And the cluster code is dirty perl :) | 12:30.07 |
| kens | Drat, what's the magic incantation for copy a directory and all its contents recursively ? | 12:30.12 |
| Robin_Watts | cp -pr | 12:30.18 |
| kens | Thanks | 12:30.22 |
| Robin_Watts | (p preserves datestamps, r recurses) | 12:30.31 |
| kens | is just trying to copy the code somwhere that I can build a debug version | 12:30.57 |
| chrisl | Robin_Watts: the cluster code doesn't look much much worse than other perl I've seen (or written!)...... | 12:31.17 |
| kens | Probably slowing down peeves for the cluster.... | 12:31.18 |
| chrisl | kens: Remember, I'm running 64 bit Linux here, so if you need me to look at something for you, I can. | 12:31.40 |
| kens | chrisl I may ask thanks. | 12:31.51 |
| | I'll at least try it myself first :-) | 12:31.59 |
| Robin_Watts | chrisl: The cluster code is (as marcos has said himself) an amalgamation of scripts he uses for testing. | 12:32.19 |
| kens | Hmm, when run from my home directory, it doesn't seg fault :-( I wonder what I did wrong... | 12:32.48 |
| Robin_Watts | as such there are lots of sections of dead code, strange options etc. | 12:32.49 |
| | kens: heisenbug ? | 12:32.58 |
| kens | Robin_Watts : no, it just doesn't seem to have actually copied anything | 12:33.23 |
| chrisl | Robin_Watts: yep, dead code, strange options.... sounds just like perl to me ;-) | 12:33.27 |
| kens | I was hoping it would overwrite my existing folder, look slike it didn't. | 12:33.43 |
| kens | invokes the poerwr of rm -r | 12:34.26 |
| Robin_Watts | cp -prf ? | 12:34.34 |
| | f = force, if memory serves. | 12:34.47 |
| kens | Just deleted the exsiting | 12:34.56 |
| chrisl | ppd: looks like Kyocera's support stuff is regional, so you'll need to find the one for where you're located. | 12:36.26 |
| kens | OK good, copied the executable and it still seg faults. Now for a debug build | 12:37.25 |
| ppd | chrisl: something is different with this 300dpi file you sent me. It takes way longer than the one you sent me before | 12:38.12 |
| chrisl | ppd: huh? I could see it take slightly longer as it has the whole page imaged, rather than just the marked area, but we should be talking less than a second | 12:39.30 |
| ppd | chrisl: not even close. still processing... | 12:39.53 |
| chrisl | ppd: I wonder if it's because it's not compressed? | 12:40.50 |
| kens | Oh great, a debug build doesn't seg fault. | 12:42.05 |
| Robin_Watts | kens: Try a profile build. | 12:42.14 |
| kens | Hmm, got the runes for a PCL profile make ? | 12:42.34 |
| Robin_Watts | make pcl-profile ? | 12:42.52 |
| kens | Was what I was trying, peeves is suddenly very slow | 12:43.11 |
| | It is building though | 12:43.17 |
| | I wouldn't be surprised to find that ti still doesn't fail. | 12:44.00 |
| | I think its memory layout that is causing the 'problem'. | 12:44.15 |
| Robin_Watts | Does a release build you build for yourself on peeves crash ? | 12:44.59 |
| kens | Don't know, haven't tried that yet | 12:45.10 |
| | I'd be surprised if it didn't. | 12:45.20 |
| Robin_Watts | I would try that (after the profile build). If it DOES crash, try cleaning and rebuilding a release build with XCFLAGS="-g" | 12:45.42 |
| kens | profile build does seg fault | 12:45.50 |
| ppd | chrisl: the printer doesn't like this at all. still processing. I think it's hanging | 12:45.59 |
| Robin_Watts | You may find that the profile build has enough information in it for gdb/valgrind to give meaningful backtraces. | 12:46.20 |
| kens | moves to Linux VM instead of Windows ssh | 12:46.27 |
| Robin_Watts | lunches | 12:46.41 |
| chrisl | ppd: well, the only two differences that I can see are that the data is uncompressed, and it's split the image into several smaller images - which I wasn't expecting....... | 12:47.02 |
| kens | TIFF strips ? | 12:47.22 |
| chrisl | Could be, but I thought libtiff hid all that cruft from the calling app, so why do that!?! | 12:47.58 |
| kens | Keeps the images to a sane size ? | 12:48.21 |
| chrisl | kens: I suppose - but we all know what multiple images butting up to each other results in...... | 12:49.08 |
| kens | :-) | 12:49.14 |
| ppd | chrisl: real15m49.431s or the 300 dpi | 12:54.34 |
| chrisl | ppd: well, the good news is that it's not just Ghostscript's Postscript that causes problems for that printer.... ;-) | 12:55.48 |
| ppd | chrisl: good news is that I managed not to throw it out of the window | 12:57.57 |
| | yet | 12:58.03 |
| chrisl | ppd: So, here's a better pair of examples (I hadn't realised how simplistic tiff2ps actually is!): http://www.ghostscript.com/~chrisl/For_Kyocera-2.tgz | 12:59.16 |
| ppd | chrisl: yeah that's the stuff. the 300dpi took 0.3 seconds, the 600dpi 6.7 seconds to transmit | 13:09.01 |
| kens | chrisl what was the difference ? | 13:09.23 |
| chrisl | The image data in the tiff2ps output is uncompressed, in several segments and frankly rather poorly embedded. The new ones are ps2write's output as a single image | 13:10.44 |
| ppd | chrisl: seems kind of acceptable for the 600 dpi image though | 13:11.01 |
| chrisl | ppd: er, that makes no sense at all...... | 13:11.46 |
| ppd | chrisl: I swear I didn't perform black magic on this device | 13:12.18 |
| chrisl | OKay, so I'm looking at the output using your Unbennant 1.pdf file - the first output is GS to convert to tiff, gimp to export to PS, and then ps2write to "refry" the PS, and the second is ps2write straight PDF->PS | 13:16.14 |
| | And teh differences are minute: data length 534026 vs 511311 bytes, image dimensions 4958x7017 vs 4622x6304 | 13:17.52 |
| | ppd: can you try this one, please? http://www.ghostscript.com/~chrisl/Unbenannt_1-600dpi-for-Kyo-3.ps | 13:19.44 |
| ppd | chrisl: bien sur | 13:26.03 |
| | chrisl: real0m19.856s | 13:28.30 |
| | chrisl: with warming up. Don't know if this slows down transmitting | 13:28.55 |
| chrisl | Well, color me confused - I thought we tried 600dpi, and it was dog slow...... | 13:30.22 |
| ppd | chrisl: maybe we forgot to add the special kyocera workaround | 13:30.54 |
| chrisl | ppd: No, that was definitely in there - I guess is must have just been the simplistic tiff2ps output that hurt it. | 13:34.04 |
| | It does make me wonder why the 1200dpi case was *so* slow, though. | 13:35.31 |
| ppd | chrisl: wait. let's try that again | 13:35.52 |
| chrisl | ppd: remember the 1200dpi file I created earlier was also from tiff2ps - I was meaning the 1200dpi output you get with Till's latest cups update (to use the resolution from the PPD). | 13:37.51 |
| ppd | chrisl: ah ok. I uploaded a ps i created with cups in ubuntu in the bug report. Is that with internal 1200dpi? | 13:38.53 |
| chrisl | ppd: I don't know, the cups filters package from Till's ppa ought to work at 1200dpi. | 13:40.49 |
| ppd | chrisl: and this has nothing to do with the dpi setting I can perform in the printer settings, right? | 13:41.26 |
| chrisl | ppd: I don't believe so, I think the resolution in the PPD takes precedence | 13:42.00 |
| kens | ppd chrisl, I'm fairly sure we didn't try 600 dpi. | 13:42.44 |
| ppd | so maybe everything below 1200 dpi works for this printer | 13:44.19 |
| chrisl | Nope, 720 was the resolution that prompted your report..... | 13:44.47 |
| ppd | I mean from our list of resolutions that we tried now | 13:45.14 |
| chrisl | ppd: to reduce confusion (maybe, a little): http://www.ghostscript.com/~chrisl/Unbenannt_1-1200dpi-for-Kyo-3.ps | 13:45.15 |
| kens | 720 is a non-integer multiple of the printers native resolution, so we might expect that to be hard. | 13:45.49 |
| chrisl | ppd: *if* the printer is genuinely printer at 1200dpi, so 1200dpi *should* be quickest of all (other things being equal) since no scaling at all is required. | 13:46.28 |
| kens | Agreed. | 13:46.39 |
| | But if the printer is operating in a reduced resolution mode (300,600) then it might still be slower thatn those resolutions | 13:47.01 |
| naveen_ | Hi Robin, I was able to send byte array to Java_com_artifex_mupdf_MuPDFCore_openArray and view the pdf by making changes in your android app...But when I integrate this into my app..I'm only seeing loading image always..Am i missing something here? | 13:47.09 |
| kens | Also from what Ray said, there is an ASIC for upscaling, so that should be quick too. | 13:47.25 |
| Robin_Watts | naveen_: No idea, sorry. | 13:48.04 |
| naveen_ | ok.. | 13:48.23 |
| Robin_Watts | I'd sprinkle some prints throughout the jni code and watch what happens on the adb log | 13:48.29 |
| naveen_ | I'm not getting any exceptions here..but will try again on that.. | 13:49.19 |
| ppd | chrisl: real1m48.812s for 1200dpi | 13:49.21 |
| chrisl | ppd: okay, so if you update your cups filters package from Till's ppa, you should get the same performance. | 13:50.23 |
| | ppd: Actually, I think I see the problem...... | 13:54.40 |
| | ppd: when you tested the stuff from Till's ppa earlier, you said you selected 300dpi in the CUPS print dialogue - am I correct? | 13:56.36 |
| ppd | chrisl: yes | 13:59.40 |
| chrisl | Okay, that *seems* to put the *printer* into 300dpi mode, but have no effect on the CUPS filter setting, so you end up sending 1200dpi data to, effectively, a 300dpi device | 14:00.40 |
| kens | Ah, scaling down again.... | 14:01.22 |
| | Ray suggested that was slow | 14:01.30 |
| chrisl | Yes, it seems various parts of cups aren't playing nicely together...... | 14:01.56 |
| | ppd: the process you tried earlier (which you attached the result from onto the Ubuntu bug) can you try that again, but with 1200dpi selected in the CUPS print dialogue? | 14:02.44 |
| kens | I guess we are asking for complicated stuff... | 14:02.45 |
| chrisl | consistent dpi through the workflow seems fundamental, to me | 14:03.19 |
| ppd | chrisl: certainly. I'll print it to a file and netcat it then | 14:03.26 |
| chrisl | ppd: to start with, if you don't want to tie up the printer, you could put it somewhere that I look at it - I can then tell you if it's worth trying on the printer. | 14:04.32 |
| | ppd: Or I can tell you what search for in the PS so you can check it yourself | 14:05.36 |
| kens | chrisl can you tell me where to set up the command line arguments in ddd ? I can't seem to find tehm in the menu..... | 14:06.17 |
| chrisl | kens: for the target exe? | 14:06.39 |
| ppd | chrisl: I'll upload it | 14:06.41 |
| kens | chrisl, yes, I have the exe loaded | 14:06.51 |
| chrisl | kens: Program->Run brings up a dialogue you can set the args in there | 14:07.15 |
| kens | Ddd is painfully slow over ssh to peeves | 14:07.19 |
| | chrisl, I'll try that thanks. | 14:07.28 |
| ppd | chrisl:http://www.linergy-gmbh.de/output.ps | 14:07.33 |
| | chrisl: this one with 1200dpi | 14:07.43 |
| chrisl | ppd: yes, that has what we want: << /HWResolution [1200 1200] /PreRenderingEnhance false >> setpagedevice | 14:08.37 |
| | ppd: So we *hope* this should run nicely on the printer in under 2 minutes....... | 14:09.13 |
| ppd | chrisl: still processing... | 14:17.24 |
| chrisl | ppd: so, not done in 2 minutes, then :-( | 14:18.34 |
| ppd | chrisl: not quite | 14:19.12 |
| chrisl | ppd: well, there is a bunch of other stuff that seems to get pulled in from the PPD, possibly based on user settings in the CUPS dialogue - two look possible: EconoMode and Smoothing | 14:22.40 |
| ppd | chrisl: ecoprint is off but there is a so called "KIR" option | 14:25.31 |
| | chrisl: that is set to on | 14:25.39 |
| chrisl | ppd: I don't see a KIR option in the Postscript, but it could be that - can you set it to off, and upload the PS again (or are you getting sick of this?) | 14:26.51 |
| ppd | chrisl: wait a sec | 14:29.19 |
| | chrisl: 1200 dpi again? | 14:29.42 |
| chrisl | please, yes | 14:29.56 |
| ppd | chrisl: hehe, the last 1200dpi came out: real20m27.511s | 14:31.41 |
| | chrisl: ERROR: limitcheck OFFENDING COMMAND: image STACK: -mark- -mark- -mark- | 14:32.42 |
| | chrisl: on the second page. first page lacks a few things... | 14:33.17 |
| chrisl | ppd: that's not good! | 14:33.47 |
| ppd | chrisl: could be because I overwrote output.ps right now | 14:33.54 |
| | chrisl: with this new cups job | 14:34.11 |
| chrisl | that's possible, it told us something, though, which might be useful.... | 14:34.34 |
| henrys | kens2:you would just run from the command line and redirect stderr to a file to get the result but I'm sort of surprised you can't just add that in the VS debug settings. | 14:39.25 |
| ppd | chrisl:http://www.linergy-gmbh.de/output_2.ps | 14:39.35 |
| kens2 | henrys it works on the command line but not VS | 14:39.39 |
| | henrys in VS pcl6 tries to parse teh redirection as part of the command line options. | 14:41.06 |
| chrisl | ppd: That has set Smoothing to "None", if you're feeling brave, you can try it on the printer..... | 14:41.07 |
| Robin_Watts | kens2: http://msdn.microsoft.com/en-us/library/kcw4dzyf(v=vs.90).aspx | 14:42.16 |
| henrys | kens2:work in gdb and arguably that is a VS bug the command line should be interpreted by the shell first - does globbing files works "run *.pcl" | 14:42.24 |
| kens2 | henrys I know its a bug, I'm sure I've had it work before.... | 14:42.47 |
| | Robin_Watts : I know it should work, it doesn't. | 14:43.12 |
| henrys | anyway we also have toolbin/leaks.tcl which parses all the -ZAa output and shows the leaks if memento doesn't work well. | 14:44.22 |
| kens2 | Memento is doing a good job for me | 14:44.37 |
| henrys | okay | 14:44.43 |
| ppd | chrisl: the same old story | 14:45.32 |
| chrisl | ppd: well, it's up to you - do you want to pursue this further? It'll mean an indeterminate number of further tests :-( | 14:48.32 |
| ppd | chrisl: someone's gotta do it. but so far we learned that everything runs pretty smooth with the setting at 600 dpi and 300 dpi, right? | 14:50.45 |
| chrisl | ppd: well, no because the biggest performance hit seems to be coming from some setting pulled in from the PPD, or possibly the compression differences. | 14:52.19 |
| ppd | chrisl: ah okay. the PPD is supplied by kyocera. pretty awkward... | 14:53.23 |
| chrisl | ppd: yes, exactly. I guess the next step is for me to create you a 300dpi test, *with* all the PPD cr*p and see how that gets on? | 14:54.19 |
| ppd | chrisl: you're the boss | 14:55.06 |
| chrisl | ppd: that doesn't fill me with confidence :-( | 14:55.29 |
| Robin_Watts | henrys: Can you spare a couple of minutes? | 14:55.56 |
| | I've reached a point with the HPGL stuff, where I think I may need you to make changes. | 14:56.11 |
| kens2 | OK so I finally managed to get ddd to co-operate long enough to seg fault in the debugger. Result! | 14:59.52 |
| henrys | sure yes, you can just check in the code right and I can enable it locally? | 15:00.02 |
| | Robin_Watts ^^^ | 15:00.47 |
| Robin_Watts | henrys: Yeah. | 15:01.04 |
| | but before I do that... | 15:01.09 |
| | Can you look at my bmpcmp, page 6, number 151 | 15:01.39 |
| chrisl | ppd: This is, from what I can remember, a 300dpi version created in the same way that cups does it, *with* the PPD settings for 300dpi, and the default Smoothing set to Medium: http://www.ghostscript.com/~chrisl/Unbenannt_1-300dpi-1.ps | 15:01.47 |
| Robin_Watts | henrys: 2 paths get stroked in that file. The first: | 15:02.17 |
| | 24.0000 48.0000 moveto % 0x2e00608<0x0,0x2e00658>:0 #curves=0 last=0x2e00658 | 15:02.27 |
| | 24.0000 996.0000 gapto % 0x2e00658<0x2e00608,0x0>:0 | 15:02.29 |
| | correctly displays nothing. | 15:02.34 |
| | The second: | 15:02.36 |
| | 24.0000 48.0000 moveto % 0x2e00e18<0x0,0x2e00e68>:0 #curves=0 last=0x2e00f58 | 15:02.47 |
| | 179.9063 357.4492 gapto % 0x2e00e68<0x2e00e18,0x2e00e98>:0 | 15:02.49 |
| | 217.6992 357.4492 gapto % 0x2e00e98<0x2e00e68,0x2e00ec8>:0 | 15:02.51 |
| | 161.0078 390.1797 lineto % 0x2e00ec8<0x2e00e98,0x2e00ef8>:0 | 15:02.52 |
| | 161.0078 324.7188 lineto % 0x2e00ef8<0x2e00ec8,0x2e00f28>:0 | 15:02.54 |
| | 217.6992 357.4492 lineto % 0x2e00f28<0x2e00ef8,0x2e00f58>:0 | 15:02.55 |
| | closepath % 0x2e00f58<0x2e00f28,0x0>:0 24.0000 48.0000 0x2e00e18 | 15:02.57 |
| | is the one that gives the problem. | 15:02.59 |
| | The 3 linetos are the triangle. | 15:03.19 |
| | The closepath is the extra line. | 15:03.32 |
| | Are we agreed that my code is doing what we expect? | 15:04.19 |
| henrys | seems to be yes | 15:05.02 |
| Robin_Watts | OK. I'll get that committed then. | 15:05.11 |
| henrys | but perhaps the first moveto should be dropped upon receiving the gapto in that mode. | 15:07.00 |
| Robin_Watts | Eh? | 15:07.13 |
| | The first moveto has meaning. | 15:07.29 |
| | Suppose I moveto each of the 4 corners of a square, then close and fill it. | 15:07.51 |
| | In that mode, we'd want to see a square. | 15:07.58 |
| | And I'd make it 'moveto gapto gapto gapto closepath'. | 15:08.24 |
| henrys | oh yes you are right. | 15:08.34 |
| Robin_Watts | hence dropping the moveto would be wrong. | 15:08.35 |
| henrys | if we have this many problems though I expect an upheavel in gl/2 sigh. | 15:09.56 |
| ppd | chrisl: sorry for the delay: takes pretty long so far.... | 15:14.06 |
| chrisl | ppd: so even 300dpi, something in the PPD crap is hurting us - that really is poor :-( | 15:14.41 |
| ppd | chrisl: real1m23.987s | 15:15.04 |
| | chrisl: plus 20 seconds or so for the actual printout | 15:15.19 |
| chrisl | ppd: so sort of acceptable, then | 15:15.38 |
| ppd | chrisl: mmmh | 15:15.55 |
| | chrisl: "sort of" | 15:16.43 |
| chrisl | ppd: the thing is, we can spend the time working out which setting from the PPD causes the slowdown, *but* as mentioned, the PPD comes from Kyocera, we don't have much control over it | 15:16.58 |
| ppd | chrisl: yes. that is true. can't I use some "generic" PPD that does not include this stuff? | 15:17.53 |
| chrisl | ppd: I'm not the person to ask, sorry. | 15:18.18 |
| ppd | chrisl: funny thing I noticed. On this last output the image in the header has visible small black dots. looks "rasterized" | 15:18.26 |
| chrisl | ppd: Hmm, I wouldn't expect that, but who knows..... | 15:19.26 |
| | ppd: I suppose if we track down the problem in the PPD, tkamppeter might have some influence on Kyocera.... | 15:20.56 |
| ppd | chrisl: if that's the only option. funny their ppd worked "ok" with the poppler filter... seems like pure luck | 15:23.40 |
| chrisl | ppd: along with so many other things, that makes very little sense to me :-( | 15:24.38 |
| Robin_Watts | could it be that once you know what in the PPD is causing it, it will explain what the poppler output is doing differently? | 15:25.43 |
| chrisl | That's *possible* but not hugely likely. To be honest, I can't see a significant difference between the poppler output and ours for these case. | 15:26.39 |
| Robin_Watts | could it be something stupid like ours going slightly out of the paper margins and somehow causing a huge slowdown because of that ? | 15:27.32 |
| chrisl | Robin_Watts: yes, it could be something like that - but a simple rectangle clip really shouldn't have a measurable effect on performance, even with an image | 15:28.34 |
| | ppd: This has the bottom half of the PPD settings chopped out: http://www.ghostscript.com/~chrisl/Unbenannt_1-300dpi-2.ps | 15:29.50 |
| ppd | but we have almost 2 minutes with the ppd additions versus 0.3 seconds without | 15:29.55 |
| | chrisl: http://paste.ubuntu.com/925011/ | 15:32.29 |
| chrisl | Oops, I wonder what I did there.... | 15:32.54 |
| kens2 | binary corruption it looks like | 15:33.52 |
| | Odd, there's a '>' in the ASCII 85 data stream. | 15:34.58 |
| chrisl | kens2: no, it's my mistake..... | 15:35.16 |
| kens2 | I think that's legal though | 15:35.24 |
| chrisl | ppd: refreshed version, should work better - I got confused with where the settings started and ended | 15:36.41 |
| | ppd: http://www.ghostscript.com/~chrisl/Unbenannt_1-300dpi-2.ps | 15:36.57 |
| henrys | sometimes it's best to wait a half hour, repeating a soothing mantra, before responding to a customer... | 15:37.47 |
| kens2 | I know that feeling well. WHich email prompted it this time ? | 15:38.13 |
| ppd | chrisl: real1m22.391s | 15:39.53 |
| henrys | 692970 | 15:40.12 |
| ppd | chrisl: plus 30 seconds at least for actual output | 15:40.18 |
| | chrisl: header image looks really bad. not smooth at all | 15:41.44 |
| chrisl | ppd: I'm not too worried about how it looks right now..... | 15:42.09 |
| | ppd: Down to about the top quarter of the PPD settings: http://www.ghostscript.com/~chrisl/Unbenannt_1-300dpi-3.ps | 15:42.36 |
| ppd | chrisl: real1m24.887s plus roughly 30 seconds for the output | 15:45.14 |
| chrisl | ppd: running out of settings.... http://www.ghostscript.com/~chrisl/Unbenannt_1-300dpi-4.ps | 15:47.42 |
| ppd | chrisl: real1m23.664s | 15:51.26 |
| chrisl | ppd: only one setting left.... http://www.ghostscript.com/~chrisl/Unbenannt_1-300dpi-5.ps | 15:53.07 |
| ppd | chrisl: do you receive any compensation money for pain and suffering for this activity? | 15:54.43 |
| chrisl | ppd: it's sort of, vaguely, part of my job - although, this is more effort than we'd normally expend on someone else's broken interpreter...... | 15:56.03 |
| ppd | chrisl: real1m23.359s | 15:56.42 |
| chrisl | ppd: I wonder if this is actually a filters problem - this has no PPD settings left: http://www.ghostscript.com/~chrisl/Unbenannt_1-300dpi-6.ps | 15:58.22 |
| ppd | chrisl: this one will takes as long... | 16:00.09 |
| kens2 | OK pizza time. night all. | 16:01.06 |
| ppd | good night | 16:01.23 |
| | chrisl: real1m23.527s | 16:02.06 |
| chrisl | ppd: running out of ideas, here! http://www.ghostscript.com/~chrisl/Unbenannt_1-300dpi-7.zip | 16:03.51 |
| | ppd: above has the PS data uncompressed, hence I've zipped it for upload - you'll want to unzip it before trying it. | 16:04.31 |
| ppd | chrisl: we have the sad situation where we have a ps file that produces better quality in 0.3 seconds ;-) | 16:07.50 |
| | chrisl: same old story with this file | 16:08.18 |
| chrisl | ppd: finally (I hope!): http://www.ghostscript.com/~chrisl/Unbenannt_1-300dpi-8.ps | 16:09.53 |
| ppd | chrisl: 0.334s | 16:10.24 |
| | "slightly" better | 16:10.47 |
| chrisl | That's probably transmission time - 400k vs 27Mb! | 16:11.34 |
| | So, this is *another* filter problem - bummer :-( | 16:12.01 |
| ppd | the last one 's printing time is what I'd expect for such a simple document | 16:14.46 |
| chrisl | ppd: Okay, well it's easy to change, but I don't know how this will fit into cups - I have a feeling that is the set of options that failed on the Brother printers..... | 16:15.58 |
| ppd | chrisl: would I be able to understand the problem? I'm trying to learn at least a bit when I'm spending whole afternoons debugging buggy hardware ;-) | 16:17.40 |
| chrisl | ppd: basically, PS has various data filters: some for compression, some to encode binary data in transmission friendly form, and some "special purpose" ones. | 16:19.02 |
| | These filters are applied in a "chain", so you can compress, then encode image data by pushing two filters onto the filter chain. | 16:20.37 |
| | In general filters should be independent of each other, and so things like encode->compress->encode is perfectly legal. | 16:21.36 |
| | So, in the way that CUPS currently drives ps2write, the image data is ASCII85Encoded, then compressed with LZWEncode as part of the page data, and the entire compressed page data is then ASCII85Encoded. | 16:23.58 |
| | ppd: still interested, or bored to tears already? | 16:24.16 |
| ppd | chrisl: still interested, but my car pool driver wants to leave | 16:26.46 |
| chrisl | ppd: okay, I'm going to write some of this up on the Ubuntu bug anyway. | 16:27.15 |
| ppd | chrisl: that would be nice! do you still "need" me here for debugging tomorrow or is it pretty clear what needs to be done? | 16:28.32 |
| chrisl | ppd: I think we know what to do, the next time your time will be needed will be when Till works out what he wants to do in CUPS | 16:29.06 |
| ppd | chrisl: so I'll just hang around in the channel. thank you for your efforts! bye for today! | 16:31.01 |
| Robin_Watts | henrys: Deltas are working again for ghostpdl. | 17:02.14 |
| | I'm going to look at making them work for mupdf too. | 17:02.23 |
| henrys | that would be great, interesting to see how we are doing with that business. | 17:05.43 |
| | with mupdf that is. | 17:05.59 |
| Robin_Watts | And we have lift off :) | 17:09.34 |
| | I think I'm going to look at the indetermisms in mupdf for a bit... | 17:10.17 |
| ray_laptop | chrisl_away: (for the logs) I saw your comment in the discussion with tkamppeter. I agree that for images (photos) HWResolution/2 or /3 is plenty, but remember that we may be dealing with text that is in the image due to transparency being used. | 17:19.45 |
| | dropping text down to 300 dpi (from 600) can be seen, particularly for CJK glyphs -- it doesn't make it illegible (usually) but does degrade quality. | 17:21.12 |
| tkamppeter | ray_laptop, thanks, so I will try whether the chrisl_away's findings for the Kyocera also accelerate my HPs and otherwise one should perhaps look into /2 only for HP. | 17:22.54 |
| ray_laptop | tkamppeter: if you have the JEITA test pages, their are some spreadsheets with gobs of tiny glyphs filling them up. You can have a look for yourself to see if 300/360 seems good enough compared to 600/720. | 17:25.20 |
| | In particular, J10 page 5 is really an 'eye-test' :-) | 17:28.20 |
| | tkamppeter: chrisl_away: the other aspect we have to consider is that by rendering at a reduced (1/2 or less) resolution for pages with transparency, the quality won't match pages which are rendered "normally" (to ps2write and rendered by the printer at it's resolution setting) | 17:56.10 |
| | tkamppeter: one last comment, then I'll stop -- Kyocera and HP and others support PCL -- we should see if the bottleneck is in the Kyocera PS by testing 600 dpi pages rendered as an image in PCL. | 17:58.05 |
| | I'm not a real fan of PCL, but since it is a 'dumber' PDL, printers can sometimes handle it more quickly | 17:59.04 |
| tkamppeter | ray_laptop, and if PCL mode is faster recomment HPIJS for all HP and Kyocera PS printers? Problem will be all the extra options in Kyocera's PPDs. | 18:01.38 |
| | s/recomment/recommend/ | 18:02.41 |
| | ray_laptop, chrisl_away's changes for Kyocera make also my HP faster. | 18:03.09 |
| chrisl | tkamppeter: just back for a minute - is that the changes I suggested on the Ubuntu bug? | 18:03.52 |
| | ray_laptop: I did think about the quality issues later, but the investigation had moved on considerably by then - it's a filter combination problem :-( | 18:05.01 |
| tkamppeter | chrisl, yes, your improvement methods for Kyo in the Ubuntu bug improve also HP. | 18:06.09 |
| chrisl | tkamppeter: Oh, good. I've pinged Bruce from the Brother bugs via e-mail, and pointed him at the Kyo report - hopefully he won't mind running a test or two on his Brother printer for us. It would be nice to avoid special cases! | 18:07.36 |
| tkamppeter | chrisl, I am thinking about using " -dEncodeMonoImages=false -dEncodeColorImages=false" only on Brother and not on all printers as currently, as leaving out this compression seems to be a significant slowdown on most printers. | 18:07.52 |
| chrisl | tkamppeter: I'm hoping the Brother might be happy with compressed images and uncompressed page streams, but yes, special casing the Brothers is an option. | 18:09.26 |
| tkamppeter | chrisl, I change the code in a way that for Brother printers nothing will change, but for Kyocera -dCompressPages=false will get added and for all non-Brother (including Kyo and HP) " -dEncodeMonoImages=false -dEncodeColorImages=false" will get removed. | 18:12.53 |
| chrisl_r61 | tkamppeter: fair enough, that should work okay. | 18:17.22 |
| ray_laptop | Can you imagine a PDF renderer written in javaScript ? even at screen/viewer resolutions it is probably slow | 18:21.40 |
| chrisl_r61 | ray_laptop: they're not going to actually do the rendering in JavaScript, are they? I figured the actual rendering would be done by the browser engine. | 18:26.42 |
| rayjj | chrisl: Well the guy wanted the jbig2 code so they could translate it into JS -- can you imagine arithmetic coding in JS ! | 18:39.07 |
| | chrisl: I wonder if the also have FlateDecode, JPEG and JPEG2000/JPX in JS ? | 18:40.41 |
| chrisl_r61 | rayjj: that's pretty darned awful. The slight worry is they might take business from people like us doing a "full" implementation, with something "just about good enough" :-( | 18:40.55 |
| tkamppeter | chrisl_r61, if I do not use -dEncodeMonoImages=false -dEncodeColorImages=false then I get a strange effect: files with -dCompressPages=false get smaller than files without -dCompressPages=false, so I allow page compression and get bigger files. | 18:41.17 |
| rayjj | chrisl: well a free browser isn't really a business | 18:41.33 |
| chrisl_r61 | tkamppeter: I noticed that, too, which feels wrong - I put it down to an oddity in the files I was using, but I guess not..... | 18:42.38 |
| | rayjj: they have a commercial arm, too, don't they? Anyway, it doesn't necessarily stop them taking some business from us at some point....... | 18:43.24 |
| Viktoras | Hello, can anyone help me with gs? I use imagick+gs to convert PDF into JPGs. But there are some files, that: Error: /invalidrestore in --restore-- and GPL Ghostscript 9.05: Unrecoverable error, exit code 1. Can you please give me any hints on this? | 19:01.48 |
| chrisl_r61 | Viktoras: before we can help, you'll have to reproduce directly with Ghostscript, and supply a file that files - we've no idea how ImageMagick calls gs. | 19:03.46 |
| | s/i | 19:03.56 |
| | s/files/fails | 19:04.05 |
| Viktoras | This is reproducible with gs directly also | 19:05.43 |
| | As for files, I will have to ask my boss for permission, as they are company's documents. | 19:06.33 |
| chrisl_r61 | Viktoras: in that case you should probably use http://bugs.ghostscript.com/ so you can (or we can) mark the file as private. We'll also need a command line. | 19:07.37 |
| Viktoras | When I open the document with Foxit Reader it says, that file contains interactive form fields. And I suppose also electronically signed. Could any of these be an issue? | 19:08.08 |
| chrisl_r61 | Ghostscript should ignore interactive forms, I'm not sure about electronic signing, but I'd expect us to ignore that, too. | 19:09.05 |
| Viktoras | And this is the command line: | 19:09.44 |
| | gswin32c.exe -q -dQUIET -dPARANOIDSAFER -dBATCH -dNOPAUSE -dNOPROMPT -dMaxBitmap=500000000 -dEPSCrop -dAlignToPixels=0 -dGridFitTT=0 "-sDEVICE=jpeg" -dTextAlphaBits=4 -d GraphicsAlphaBits=4 "-r72x72" -sOutputFile="out-%d.jpg" test.pdf | 19:09.52 |
| chrisl_r61 | The first thing to try is remove the "-q -dQUIET" options - if you're trying to debug a problem, you really want verbose output! | 19:10.56 |
| | Viktoras: but I don't see a particular problem with that command line | 19:11.37 |
| Viktoras | And, what I guess is the reason to all this: **** This file had errors that were repaired or ignored. | 19:12.27 |
| | **** The file was produced by: | 19:12.27 |
| | **** >>>> Amdocs Document Designer <<<< | 19:12.27 |
| | I had 9.00 that was just dying, 9.05 called directly does out put the files, but still dies at the end | 19:13.12 |
| chrisl_r61 | what do you mean "dies at the end"? | 19:13.36 |
| Viktoras | I mean "GPL Ghostscript 9.05: Unrecoverable error, exit code 1" and so on. | 19:14.11 |
| chrisl_r61 | Hmm, I was hoping it might tell you *what* was wrong (or thinks is wrong) with the PDF | 19:15.11 |
| Viktoras | http://pastie.org/private/dizazaxrxh72zgk3ejvv4q | 19:16.58 |
| | Maybe this will describe better than me) | 19:17.09 |
| chrisl_r61 | Viktoras: sorry, that doesn't really tell me anything - often GS will show an error or warning before the "Error reading a content stream", but not in this case. | 19:19.54 |
| Viktoras | I see, so I guess only the file can tell anything significant in this situation? | 19:20.26 |
| chrisl_r61 | Viktoras: 'fraid so, yes. | 19:20.49 |
| Viktoras | Allright. Thanks for response) I will get permissions and post a ticket. | 19:21.43 |
| chrisl_r61 | Viktoras: okay, I can't remember if the bug creator can make an attachment private, so if not, ping someone on here, and well do it. | 19:22.53 |
| Viktoras | Ok. Thanks! Wish you a good evening. Bye. | 19:24.26 |
| chrisl_r61 | Same to you! | 19:24.38 |
| ray_laptop | mvrhel: I noticed that you are moving on to working on the Avadhut problem. What's the status on the planar spot color stuff ? | 21:27.42 |
| | mvrhel: BTW, I just upgraded to RAdmin 3.4 (I was at 2.2 and it stopped working, but when I upgraded -- for free - it works). It seems a little better, but it's hard to tell. If you get it, MAKE SURE AND SET YOUR OWN PORT # (don't use the default). | 21:29.21 |
| | mvrhel: when I used the default port the RAdmin logs showed hundreds of attempted logins every day -- and that was 4+ years ago. It's probably worse now | 21:30.22 |
| | I now have all internet traffic into my Windows system blocked except for that port (it's on an internal network in back of peeves) | 21:31.21 |
| | if you have a 'firewall' on your router, you may need to enable the port for whatever you pick. | 21:32.26 |
| mvrhel | hi ray_laptop | 21:55.41 |
| | I was just taking an initial look on Avadhut's issue to get a feel for it | 21:56.04 |
| | the status on the planar spot stuff is that I have about 2 files that render wrong in the cluster test | 21:56.38 |
| | and they are ones that make my head hurt a bit. I am going to jump back on them in a bit | 21:57.00 |
| | ok enough work for Avadhut. back to planar sep land | 22:13.35 |
| | I think I am going to have to look into this pdf file to understand what all is going on | 22:14.56 |
| | hmm trying to use mupdfclean to do some expansions and it fails | 22:35.08 |
| | seoming about "compression bomb detected" | 22:35.21 |
| | Robin_Watts: any ideas | 22:35.32 |
| | I really don't want to go off and debug this | 22:36.10 |
| | I wonder what a compression bomb is | 22:36.23 |
| | oh interesting | 22:37.09 |
| | bbiaw | 22:51.16 |
| Robin_Watts | mvrhel: Hi | 22:58.25 |
| | I hate the compression bomb code. | 22:58.49 |
| | just nobble the if to never trigger. | 22:59.05 |
| | (stm_read.c, line 113) | 22:59.41 |
| | Forward 1 day (to 2012/04/12)>>> | |
IRC Logs