| | <<<Back 1 day (to 2014/08/06) | 2014/08/07 |
| mvrhel_laptop | hi rayjj | 03:29.29 |
| | thanks for the spread sheet | 03:29.41 |
| | any idea why we differ so much on the PLRM.pdf? | 03:30.25 |
| | I think I was using a version that only had 100 pages iirc | 03:30.45 |
| | I wonder if that could make any sort of difference | 03:30.57 |
| | rayjj: so how was the pcl content created? | 03:32.01 |
| rayjj | mvrhel: I don't know. Henrys did it and sent a tarball | 04:24.37 |
| | mvrhel: as far as the PLRM.pdf -- I created a version from Acrobat that only had 100 pages and that's the timings I used. The file I got from you had 912 pages | 04:26.10 |
| | After the suggestion from robin_watts_mac, I have upgraded my raspbian and am rebuilding to re-test. | 04:27.19 |
| | at least it might show toolchain sensitivity (or not) | 04:27.50 |
| kens | rayjj your problem with the PLRM is almost certainly CIDFonts. CIDFonts were added in a supplement, they are not present in the original level 2 specification. Since ps2write doesn't support CIDFonts they end up coming out in type 3 fonts, which are assembled ad-hoc as required. SO yes, you get lots of duplication. I've mentioned before it would be useful to do a ps3write which supports CIDFonts, but I can't see any likelihood o | 07:20.49 |
| | f having the time to do it any time soon. | 07:20.49 |
| shay- | Hi, v9.06 is the latest free version for commercial use right? Are there any security updates available for this version? | 09:35.13 |
| kens | THe latest version of Ghostscript is 9.14, *all* versions of Ghostscript are available under the AGPL, which is not quite the same as 'free'. | 09:35.48 |
| | No version of Ghostscript is free for commercial use | 09:36.06 |
| shay- | kens: hmm according to the changelog all versions starting with 9.07 are under AGPL, 9.06 is available under GPL. | 09:40.07 |
| kens | shay- : yes, and before that it was the V2 PL and before that the AFPL. I didn't want to confuse the issue by mentioning individual licences. As I said, none of the versions of Ghostscritp are free for commercoial use, but depending how you use it, it may be possible to use Ghostscrtip in a commercial environment. You need to adhere to the licence. There is not much difference between teh GPL and AGPL. | 09:41.57 |
| | that shoudl read V2 GPL | 09:42.11 |
| shay- | kens: alright thank you, but back to the actual question, if there is a security fix in 9.14 (or 9.15) will is be also available for 9.06? | 09:43.56 |
| kens | shay- : that isn't really a meaningful question in our method of operation. We don't do 'fixes' the code is open source and we release it every 6 months. In this sense release just means we tag it with a version number and build binaries. | 09:45.10 |
| | We only do patches for our commercial customers, not for free users. | 09:45.25 |
| shay- | kens: alright thank you very much | 09:45.45 |
| kens | Free users can either use the version they have, upgrade to the current release, or apply individual commits themselves | 09:45.48 |
| jogux | kens: although, presumably, any security fixes made to 9.14/9.15 would be AGPL, so if you apply them to 9.06 you no longer have a GPL 9.06. | 09:46.44 |
| kens | jogux : that would be a pretty murky area of licencing | 09:47.06 |
| | But a strict interpretation of the licence would certainly imply that | 09:47.28 |
| chrisl | I think, in practice, it depends on the size of the patch | 09:48.02 |
| | But backporting fixes (especially several versions) can be a problem | 09:48.38 |
| kens | Yes, as several people have discovered, often a fix relies upon previous fixes. Identifying the whole chain can be a problem. THis is why we won;t do patches for even our paying customers sometimes | 09:49.22 |
| | And also why we limit the number of versions we're prepared to offer that support for. | 09:49.50 |
| chrisl | kens: ping | 11:15.30 |
| kens | chrisl pong | 11:15.38 |
| chrisl | What version of Acrobat do you have? | 11:15.47 |
| kens | X | 11:15.51 |
| | I have some older versions too | 11:15.56 |
| | The newer versions are in the cloud, so I'm not upgrading to those | 11:16.22 |
| chrisl | Can you do me favour, and make a PDF in Acro X of the first 100 pages of the PLRM? "Pages extract..." or whatever | 11:16.34 |
| kens | OK, just a moment | 11:16.44 |
| | Where do you want it ? | 11:17.26 |
| chrisl | e-mail it to me? | 11:17.38 |
| kens | OK its only 452 Kb | 11:17.53 |
| | OK on its way | 11:18.51 |
| chrisl | Thanks, got it | 11:18.59 |
| kens | That was quick :-) | 11:19.06 |
| chrisl | Maybe gmail is getting better with practice! | 11:19.24 |
| kens | :-D | 11:19.30 |
| chrisl | kens: btw, if I convert the PLRM.pdf via pdfwrite with -dLastPage=100 I get a pdf that generates a warning: "**** Warning: File has an invalid xref entry: 210. Rebuilding xref table." | 11:22.16 |
| kens | Hmm, well I don't know what would cause that. | 11:22.35 |
| chrisl | No, it's kind of weird - does it warrant (or do you want) a bug? | 11:23.16 |
| kens | Up to you, it can't be common (given how many people seem to be doing this sort of thing) | 11:23.38 |
| | I won't get to it any time soon though | 11:23.52 |
| chrisl | Probably very few: but I know it works the vast majority of the times I use it | 11:24.20 |
| kens | lunches | 11:27.52 |
| mvrhel_laptop | hi kens2: did you look at the None color bug? I can spend a bit of time on it today | 13:49.25 |
| kens2 | mvrhel_laptop : I looked at it and got myself tied in knots | 13:49.38 |
| mvrhel_laptop | oh great. I will see if I can tell what he is talking about first | 13:50.03 |
| kens2 | So I gave up. NB its not a bug as such, its Zoltan asking questions about pieces of the code he probably shoudn't be messing with again | 13:50.11 |
| mvrhel_laptop | right | 13:50.18 |
| | that is what I was trying to understand | 13:50.32 |
| kens2 | I'm not sure why he's asking about image1_setup, I really think he shold leave that alone..... | 13:50.35 |
| mvrhel_laptop | well, I will only spend a bit of time on it if its not a "bug" | 13:51.30 |
| kens2 | From my perspective I don't see that image1_setup needs to care what the colour space is set to, I don't think it actually uses it, so his question doesn't seem to make much sense. But then, posting it as a bug doens't make much more sense either :-) | 13:52.01 |
| mvrhel_laptop | right | 13:52.17 |
| kens2 | I've just noticed that his email later talks about the device begin_image method, so I may try this again using pdfwrite, since it actually does have a begin_image method, and needs the ink names to be correct. | 13:52.57 |
| mvrhel_laptop | oh good point | 13:53.10 |
| kens2 | I'll just finish what I'm doing here and stash it | 13:53.14 |
| mvrhel_laptop | hmm I only have the email from the 25th | 13:53.39 |
| kens2 | AFAIK that's all there is | 13:53.53 |
| | The bug link is in that email | 13:54.00 |
| | nobody seems to have commented on support or in the bug thread | 13:54.22 |
| mvrhel_laptop | kens2: so a color space could have multiple None entries but he seems to be asking about multiple things like PANTONE 485 C which I would not expect to see | 13:57.46 |
| kens2 | Well, up to a point he's defintiely correct. When I run the file here I see tht in image1_setup, the deviceN ionk names haev a duplicate entry (2 inks, same name) | 13:58.29 |
| | I have no idea if that's a problem, if the colour space is correctly initialised a t this point or what. | 13:58.49 |
| mvrhel_laptop | with real ink names (i.e. not None?) | 13:59.14 |
| kens2 | But.... Whatever happens in imge1_setup, inside the interpreter, doesn't have any bearing on what the devicde method gets, IMO | 13:59.24 |
| mvrhel_laptop | good point | 13:59.39 |
| kens2 | mvrhel_laptop : they are name indices, but the numbers are the same | 13:59.40 |
| | Oooh, I have a TM at last. It looks like it might be wrong, but still..... | 14:02.06 |
| mvrhel_laptop | TM? | 14:02.22 |
| kens2 | Sorry, Tm, a Text Matrix emission in my PDF output | 14:02.37 |
| | Still trying to capture fallback glyphs as outlines instead of bitmaps | 14:03.10 |
| | The last step is to get the text matrix set correctly, I've been having some trouble with this | 14:03.29 |
| mvrhel_laptop | kens2: ok. np I thought you were still working on the DeviceN stuff and was very confused. I will take a look | 14:04.04 |
| kens2 | mvrhel_laptop : I'll look at it in a moment, just wanted to get this tested and then stashed. I'll poke the pdfwrite begin_image routine and see what it gets for a colour space | 14:04.40 |
| mvrhel_laptop | oh ok | 14:04.51 |
| | thanks | 14:04.55 |
| kens2 | OK stashed the code, now to rebuild the current master | 14:05.21 |
| | Hmm, I'll assume he means begin_typed_image | 14:06.32 |
| | Hmm, that's not good. THe pdfwrite output has 2 inks with the same name :-( | 14:09.31 |
| | I have a sneaky suspicion this may actually be a bug | 14:09.45 |
| | ROFL I think Zoltan is the one with the problem! The colour space of the image is defined as having 2 inks the same, and doesn't include a /None....... | 14:12.57 |
| | THis is what's in the PDF file: | 14:13.19 |
| | 24 0 obj | 14:13.19 |
| | [ /DeviceN [ /Cyan /Magenta /Yellow /Black /PANTONE#20485#20C | 14:13.19 |
| | << | 14:13.19 |
| | >> ] | 14:13.19 |
| | endobj | 14:13.20 |
| | Oops, let me try that again | 14:13.30 |
| | "24 0 obj | 14:13.41 |
| | "[ /DeviceN [ /Cyan /Magenta /Yellow /Black /PANTONE#20485#20C | 14:13.41 |
| | "/PANTONE#20485#20C /PANTONE#20Violet#20C ] /DeviceCMYK 14 0 R | 14:13.41 |
| | "<< | 14:13.41 |
| | " /Colorants 23 0 R | 14:13.41 |
| | ">> ] | 14:13.41 |
| | "endobj | 14:13.41 |
| | SO inks 5 and 6 are the same, just as the image code shows it | 14:14.02 |
| | THere is no '/None' anywhere in the PDF file | 14:14.23 |
| | mvrhel_laptop : shall I reply to him ? | 14:15.00 |
| | The bug is assigned to you, so if you want to deal with it I certainly don;t mind | 14:15.31 |
| mvrhel_laptop | kens2: oh that is the issue | 14:15.59 |
| kens2 | THe issue seems to be that his PDF file doesn't have the ink setup he thinks it does :-) | 14:16.19 |
| mvrhel_laptop | that is weird. when I do open it up with Acrobat 9 it does claim there is a None entry | 14:16.34 |
| | 9 pro that is | 14:16.48 |
| kens2 | Really ? I wonder if we're looking at the same file, did you use the one from the email or the one from the bug report ? | 14:16.54 |
| mvrhel_laptop | the one from the email | 14:17.00 |
| kens2 | Ah, I used the oine in the bug report | 14:17.07 |
| | I'll check the one in the email | 14:17.19 |
| | Interesting, you're quite correct, for both files. | 14:17.58 |
| | I wonder if Acrobat maps the duplicate ink to /None | 14:18.08 |
| mvrhel_laptop | It must be doing something like that. let me read the spec on this | 14:18.42 |
| | the names must be different from one another except the None entry | 14:19.12 |
| | as I thought | 14:19.15 |
| kens2 | Indeed, its not sensible to have duplicates | 14:19.23 |
| mvrhel_laptop | so really this is not a valid pdf | 14:19.32 |
| kens2 | I would agree, its not. Whether we should detect this is less clear | 14:19.59 |
| | Also what we should do about it..... | 14:20.06 |
| mvrhel_laptop | kens2: well we handle it as if it were None in that we drop the extra one | 14:20.28 |
| kens2 | I'm fairly sure I could catch the duplicate inks in the DeviceN colour processing in the PS interpreter | 14:20.31 |
| | mvrhel_laptop : Do we ? Or do we map both inks to the same separation ? | 14:20.57 |
| mvrhel_laptop | good question | 14:21.25 |
| kens2 | According to the Acrobat preview, there is nothin on the /None plate | 14:21.43 |
| | I'll hack the file to change the second ink name and look at that | 14:22.00 |
| mvrhel_laptop | ok | 14:22.11 |
| kens2 | Yes, the duplicate ink makes no marks, so its not obvious what we do, whether we print both on the same plate, or drop one | 14:23.21 |
| | Typical that Acrobat lies about the inks in the PDF file | 14:24.15 |
| | So anyway, do you want to reply to Zoltan or shall I ? | 14:25.16 |
| henrys | mvrhel_laptop, rayjj : we really should investigate these numbers before the meeting. How can plrm be that much faster in PCL. Is the Type 1 vs. Type 42 parser the difference. I canât imagine it would be that different | 14:25.41 |
| | rayjj: can you put the files from the test on casper and Iâll profile. | 14:26.20 |
| mvrhel_laptop | kens2: if you don't mind doing it please go ahead | 14:27.07 |
| kens2 | OK No problem | 14:27.13 |
| mvrhel_laptop | thanks kens2 | 14:27.17 |
| henrys | chrisl: any ideas why pcl would be faster in a file dominated by text. | 14:27.22 |
| | ? | 14:27.26 |
| | chrisl: are there large difference between TT and T1 youâve noted ? | 14:27.54 |
| mvrhel_laptop | brb | 14:41.03 |
| kens2 | chrisl ping | 14:41.38 |
| mvrhel_laptop | henrys: yes. at minimum it would be nice to have an explanation for the difference | 15:06.45 |
| henrys | mvrhel_laptop: I did find a better pcl6 driver and I expected good result but something awry here | 15:07.35 |
| mvrhel_laptop | henrys: so you created all the pcl files using what driver? | 15:08.16 |
| henrys | hp laserjet 400 color M451dw | 15:10.25 |
| | mvrhel_laptop: it is pcl6 not pcl5 | 15:11.18 |
| mvrhel_laptop | ok | 15:17.37 |
| | henrys: I am going to make you a new gsview with the NOCACHE option added | 15:31.05 |
| henrys | okay | 15:31.21 |
| mvrhel_laptop | henrys: so that was just for the conversion to XPS command line right? | 15:31.26 |
| henrys | yes. | 15:32.16 |
| mvrhel_laptop | ok this is a first. the metro portion of windows has crashed and gone away | 16:25.14 |
| kens | henrys I'm going to leave the fiels from Adrian for you. Its true that pdfwrite produces 2 pages (second one blank), but so does pcl6 for me | 16:25.20 |
| | mvrhel_laptop : and now you're stuck in limbo ? Or cna you get to the desktop ? | 16:25.35 |
| mvrhel_laptop | while I still have my desktop applications running | 16:25.36 |
| henrys | kens:okay | 16:25.40 |
| mvrhel_laptop | the desktop background is gone | 16:25.47 |
| | all my desktop apps are running | 16:25.53 |
| | and I can't get to the tile screen | 16:26.02 |
| kens | I've had that in Windows 7 when WIndows explorer (not Internet explorer) crashes | 16:26.06 |
| jogux | mvrhel_laptop: sounds like a good result to me | 16:26.12 |
| mvrhel_laptop | ok that is what happened. windows explorer crashed | 16:26.25 |
| kens | jogux : I don't think you cna logout if you can't get back to the tiles | 16:26.28 |
| mvrhel_laptop | right | 16:26.34 |
| | actually ctrl alt del gets me to a spot where I can restart | 16:27.07 |
| | brb | 16:27.09 |
| kens | OK well that's not too bad then | 16:27.17 |
| | Just wait til MS take that away too :-) | 16:27.29 |
| | TIme to go, night all | 16:28.18 |
| rayjj | mvrhel_laptop: how do I do that? I *hate* the tile screen ;-) | 16:28.44 |
| | darn. I hope mvrhel comes back. | 16:31.07 |
| | mvrhel: I have to re-run the timing :-( (that's the bad news). The good news is that after the apt-get update + upgrade, the PLRM.pdf is 46.5 seconds (faster than before) | 16:32.21 |
| | mvrhel_laptop: and it corresponds to your timings better. | 16:32.37 |
| | I'll get those today | 16:32.47 |
| mvrhel_laptop | rayjj: ok thanks. what did you change? | 16:32.58 |
| | some linux stuff? | 16:33.18 |
| rayjj | mvrhel_laptop: apt-get update, apt-get upgrade changed just about everything | 16:33.34 |
| mvrhel_laptop | lok | 16:33.40 |
| | ok | 16:33.42 |
| rayjj | it took 6 hours | 16:33.49 |
| mvrhel_laptop | wow | 16:33.51 |
| rayjj | and then I had to rebuild the gxps, gs and pcl6 (which had a problem so I have to do that yet) | 16:34.28 |
| chrisl | kens, henrys sorry, I forgot to change my status..... | 16:37.10 |
| kens | :-) I was about ot go.... | 16:37.21 |
| chrisl | kens: I thought you'd gone | 16:37.41 |
| kens | Did you have a chance to look at he problem on AIX ? | 16:37.45 |
| | Its the only one we still owe a reply to (apart from the new one from Adrian) | 16:38.04 |
| rayjj | and the amazing thing is that gxps does the 100 page PLRM in 21.7 sec. It's strangs because it zooms through the first 29 pages in 3.1 seconds, then page 30 takes 7.7 seconds, then the others after that run slightly slower than before page 30 | 16:38.25 |
| chrisl | kens: I haven't - it does ring a bell though. I thought it was fixed | 16:38.47 |
| kens | Marcos supplied htem a patch, but it didn't build on AIX, its soemthing to do with FAPI and UFST, and probably bytre ordering | 16:39.16 |
| | Mail from Catalin Miclaus on 05/08/2014 | 16:39.44 |
| chrisl | Yeh, IIRC, there is patch that fixes it. I'll try to find it | 16:39.53 |
| kens | OK as far as I can see it hasn't been sent to the customer, though I could of course be wrong. | 16:40.22 |
| rayjj | henrys: can you generate XPS output (using the stock "Microsoft XPS Document Writer" for J9, J11 and J12 (the same way you did the PCL) | 16:40.28 |
| kens | And Sriram can wait until tomorrow now. | 16:40.37 |
| henrys | rayjj: I didnât use stock ms pcl driver - itâs has horrible output, I used HPâs driver. | 16:41.33 |
| chrisl | kens: yes, the current code has stuff to handle the PCLswapHdr() thing - I'll find the commit | 16:41.34 |
| kens | Thanks chrisl. | 16:41.45 |
| | henrys, the Unicode thing came back, I suspect they just need to use current code, I bet they are using 9.05 or something like that | 16:42.08 |
| chrisl | Didn't they say 9.07? | 16:42.25 |
| henrys | rayjj: but yes Iâll do it if you want let me know | 16:42.33 |
| kens | Could be, I don't recall exactly | 16:42.37 |
| henrys | kens: okay let me finish up adrian then Iâll move on to that | 16:43.05 |
| chrisl | "Note: We are using GhsotScript 9.07." | 16:43.09 |
| kens | chrisl, aha, then the answer is 'use up to date code', same as for MuPDF. Of course that will then spawn a 'request to share current code' | 16:43.43 |
| chrisl | Request away..... | 16:44.01 |
| kens | OK I really am off now.... | 16:46.10 |
| rayjj | oops. I forgot the -r600 (or -r1200). I put the other args in a file and left it out on purpose so I could do both, then tested without it. Maybe that's how mvrhel got his times ? | 16:48.21 |
| | henrys: for the PCL, I'd like to add the note about which driver. And for the XPS, let's just use MS's | 16:49.08 |
| henrys | rayjj: letâs keep thing reproducible by putting your test files on casper and including a pointer to the test files in the results email report. | 16:49.34 |
| rayjj | henrys: sounds like a good idea | 16:50.01 |
| | I'll upload them in a bit | 16:50.15 |
| henrys | chrisl: this unicode stuff is only a problem on windows right? | 16:52.22 |
| chrisl | henrys: yep | 16:52.30 |
| henrys | so Iâll create a pdf with his filename and make sure itâs fixed now and broken before and we should be satisfied | 16:53.08 |
| chrisl | Do we know if they use the executable or the API? | 16:54.03 |
| henrys | command line see the last email | 16:54.42 |
| chrisl | Oh, it should be fine then | 16:55.01 |
| | henrys: the PLRM has it's fonts embedded as Type 1. I'd assume the PCL producer doesn't convert type 1 to TTF? | 17:07.20 |
| henrys | chrisl: acrobat reader did produce TTâs - there is a bitmap variant of tt I didnât check that. | 17:08.43 |
| chrisl | henrys: I don't think we support the bitmap TTF font | 17:09.25 |
| rayjj | if the PLRM has Type 1 fonts, why does ps2write do all of the CharProc nonsense ? | 17:09.41 |
| chrisl | Dunno. As Ken mentioned, that's usually when it's a CIDFont | 17:10.47 |
| henrys | chrisl: Iâm pretty sure we do support have a few pcl test cases. | 17:11.45 |
| | I could believe bitmaps would be quite a bit faster than t1 but still the document should have good caching something seems fishy | 17:12.30 |
| chrisl | henrys: only if they have special handling in the PCL world - we specifically disable TTF bitmaps because it causes problems with PDF and Postscript when using TTFs off disk | 17:12.38 |
| henrys | anyway when rayjj posts his file Iâll comparitively profile and that will tell us what is going on. | 17:13.22 |
| chrisl | rayjj: practically all the fonts in the PLRM are custom encodings, that could account for ps2write falling back to type 3 | 17:13.22 |
| rayjj | the gs produced ps2write takes a LONG time (24 sec) loading all the stuff before the first page is output (and uses 30 Mb of VM) then finishes the pages in 106.7 sec | 17:14.10 |
| henrys | rayjj: stock ms driver is probably a bad idea. We should use a postscript printer driver for a specific âgoodâ printer | 17:14.40 |
| | is ms postscript notoriously bad | 17:15.11 |
| | s/is/isnât/ | 17:15.18 |
| chrisl | henrys: handling TTFs from PCL is considerably simpler than anything in the Postscript world. But I wouldn't have thought it would make a noticable difference. | 17:15.28 |
| henrys | chrisl: agreed itâs too much difference | 17:16.52 |
| rayjj | using Acorbat's "save as PostScript" starts the first page after only 6 seconds, but then it runs the pages more slowly (total time 129 sec) | 17:16.54 |
| chrisl | henrys: don't forget, there is quite an overhead in the PDF interpreter, too. | 17:17.28 |
| henrys | chrisl: I wouldnât bat an eye at pdf being slower, I know postscript and pcl text times are comparable | 17:18.43 |
| chrisl | henrys: it's heavily dependent on the construction of the Postcript, then | 17:19.11 |
| | rayjj: we'll always have a fairly heavy startup time with the ps2write output - it's a natural result of how ps2write was implemented. | 17:20.03 |
| henrys | chrisl: right that is the kind of time difference Iâd expect for disabling the cache, I wonder if something in the ps is horking up the cache hit rate | 17:20.40 |
| mvrhel_laptop | rayjj: I did not leave out the -r on my times. | 17:20.53 |
| | otherwise 600 and 1200 would be the same... | 17:21.01 |
| rayjj | OK, so gxps time at 600 dpi is MUCH slowerr. It also has the stall after page 29 (page 30 takes 13 sec) and subsequent pages are slower than 1-29 (which take 9 sec). about 10 sec per page :-( | 17:21.50 |
| | mvrhel_laptop: I know, I was kidding. | 17:21.57 |
| | so XPS is probably a bad idea. | 17:22.20 |
| henrys | XPS is always a bad idea ;-) | 17:23.39 |
| rayjj | I am surprised that 600 dpi is so much slower than 72 dpi for xps. With PS it is only 1.3x slower. With XPS it is 32x slower :-( | 17:30.19 |
| | errand. bbiab (I'm rebuilding PCL on the Pi) | 17:33.43 |
| mvrhel_laptop | henrys: speaking of XPS, the version of gsview with the -dNOCACHE for the XPS creation is in my gsview directory on caspar. | 17:34.38 |
| henrys | mvrhel_laptop: okay Iâll get to it shortly | 17:35.46 |
| chrisl | henrys: interesting: if I select the option in Acrobat so shared fonts/resources are loaded at the beginning of the PS, (rather than incremental download), it goes quite some faster | 17:36.03 |
| mvrhel_laptop | I need to pull in a patch from ray into gsview then I am going to wrap up these slides for the linux talk and then get back to SOT | 17:36.15 |
| rayjj | chrisl: the ProcSet loading isn't the problem -- it's the screwy way the fonts are handled. That and loading all the glyphs at the start chews up memory. If the glyphs were recognized so that we only had the unique ones, it would be OK to load them at the start | 17:37.30 |
| chrisl | rayjj: this is *Acrobat* Postscript | 17:38.06 |
| rayjj | chrisl: where's that option ? | 17:38.09 |
| chrisl | When you do File->Export->Postscript...... | 17:38.46 |
| rayjj | the ProcSet from Acrobat PS (of the PLRM) loads on the Pi in 6 sec | 17:39.07 |
| chrisl | Hit the "Settings" button, and select "Postscript Options" | 17:39.31 |
| henrys | Ideally a print driver would notice the fonts are on the printer â¦. thatâs the problem with the generic drivers. | 17:39.37 |
| chrisl | henrys: that doesn't work | 17:39.48 |
| henrys | chrisl: it doesnât work with a real postscript printer? | 17:45.14 |
| chrisl | henrys: I've seen too many different versions of TimesRoman and other fonts.... | 17:45.53 |
| rayjj | chrisl: on my laptop that makes the PLRM_100.ps go from 12.5 seconds down to 8.8 | 17:46.40 |
| | I'll try that on the Pi after it finishes building pcl6 | 17:46.58 |
| chrisl | rayjj: with my cross compiled exe on the pi it goes from 243 seconds to 156 | 17:47.23 |
| rayjj | chrisl: I wonder why the cross compile is so bad. my native compile is 61.6 sec (at 600 dpi) | 17:48.33 |
| | no, that's the PDF. The PS is 106 sec | 17:48.57 |
| | but still. I wonder if FP is being done in s/w | 17:49.24 |
| chrisl | rayjj: I selected hardware fp. But I suspect the static linked ulibc isn't as optimised for speed as the glibc on the pi | 17:50.31 |
| rayjj | bbiaw | 17:53.14 |
| nemo | rayjj: hey. you've been super helpful already, but | 19:20.34 |
| | rayjj: one more question ⺠| 19:20.40 |
| | gs -dQUIET -dBATCH -dNOPAUSE -dNOGC -dPDFSETTINGS=/screen -sDEVICE=pdfwrite -dColorImageResolution=120 -dColorImageFilter=/FlateEncode | 19:20.49 |
| | I was trying to force non-lossy | 19:20.55 |
| | just to see how much smaller the PDF would get | 19:21.01 |
| | unfortunately, I don't see any difference in the resulting PDF | 19:21.16 |
| | same file size, and when printed, same jpeg blocks around print | 19:21.25 |
| | around text I mean | 19:21.31 |
| | hm | 19:21.38 |
| | maybe there's another option besides ColorImageFilter | 19:21.47 |
| | like GrayScaleImageFilter | 19:21.52 |
| | or something | 19:21.56 |
| mvrhel_laptop | tkamppeter: are you there? | 19:22.19 |
| nemo | yep. still DCT | 19:22.55 |
| | $ strings hq2.pdf | grep Filter.*DCT | wc -l | 19:23.09 |
| | 228 | 19:23.09 |
| | (doc is 228 pages) | 19:23.27 |
| | let's try GrayImageFilter and GrayImageResolution | 19:24.00 |
| mvrhel_laptop | ok. slides are done | 19:28.34 |
| nemo | rayjj: ooooooooh https://groups.google.com/forum/#!topic/comp.text.pdf/MFMQl-KRryk | 19:36.04 |
| | /GrayImageDict << /QFactor 0.25 /Blend 1 /HSamples [2 1 1 2] /VSamples [2 1 1 2] >> | 19:36.12 |
| | ⥠| 19:36.15 |
| rayjj | mvrhel_laptop: timings aren't really that much different after the upgrads | 19:36.17 |
| nemo | this looks like just what I wanted | 19:36.19 |
| mvrhel_laptop | rayjj: ok | 19:36.34 |
| robin_watts_mac | rayjj: Morning. So upgrades didn't help. | 19:38.52 |
| | Did using a mutool clean produced plrm100.pdf help? | 19:39.07 |
| rayjj | nemo: The docs for 9.14 are at http://www.ghostscript.com/doc/9.14/Readme.htm and http://www.ghostscript.com/doc/9.14/Ps2pdf.htm has the options | 19:39.23 |
| | In that doc Note 7: The default image parameter dictionary is << /QFactor 0.9 /Blend 1 /HSamples [2 1 1 2] /VSamples [2 1 1 2] >> | 19:40.29 |
| | robin_watts_mac: hi. Just a little. eg. PLRM with pcl6 went from 31.1 to 30.4 | 19:41.41 |
| | robin_watts_mac: which might just mean I didn't run it often enough the first time to get that time | 19:42.11 |
| robin_watts_mac | Ey? How does a pdf change help with pcl6? | 19:42.16 |
| | oh, upgrades, right. | 19:42.27 |
| nemo | rayjj: weird | 19:47.02 |
| | rayjj: the jpegs produced had really bad artifacting | 19:47.09 |
| | QFactor 0.9 is equiv to quality of 90% no? | 19:47.21 |
| | admittedly this was 9.10 | 19:48.52 |
| rayjj | robin_watts_mac: and the mutool extracted 100 page PDF is slower than the one Acrobat created (71.5 vs 61.6 seconds) | 19:48.52 |
| robin_watts_mac | 2112 seems odd. | 19:48.53 |
| | rayjj: Odd. | 19:49.16 |
| rayjj | robin_watts_mac: that's an even number ;-) But I don't even know if that's what we use -- that's just what's in the doc) | 19:50.07 |
| | robin_watts_mac: that was just one run -- a second time gave 69.8 sec | 19:51.20 |
| henrys | robin_watts_mac: about the unicode fix, his filename works for me in 9.14. Is there some reason other fix unicode related later than that? | 19:52.21 |
| | Oh I see the temp path stuff⦠right. Iâll point them to 9.14 for the filename fix then tell them there was another unicode change for the temppaths for which they can wait until 9.15 thanks robin_watts_mac | 19:55.23 |
| rayjj | mvrhel_laptop: I wish I knew why your PLRM.pdf times were so much better than mine | 19:57.37 |
| henrys | do we have both input files? | 20:03.03 |
| mvrhel_laptop | unfortunately I am working from a friends house down in hood river OR right now. I dont have my pi with me :( | 20:07.49 |
| | hold on I may have this here | 20:13.09 |
| rayjj | mvrhel_laptop: "this" ? | 20:13.56 |
| | mvrhel_laptop: did you build with gcc on the Pi or something else ? | 20:14.27 |
| mvrhel_laptop | I mean the file | 20:14.35 |
| | I built on the Pi | 20:14.45 |
| | I was looking for my PLRM.pdf input file | 20:15.00 |
| | looks like I just did -dFirstPage and -dLastPage | 20:20.52 |
| | Also I was running A4 | 20:24.45 |
| | I can't see where that would make a diff. | 20:25.01 |
| | rayjj: do you want me to send you my pdf file | 20:25.10 |
| | just to make sure there is not a diff there | 20:25.17 |
| nemo | gdb --args gs -dQUIET -dBATCH -dNOPAUSE -dPDFSETTINGS=/screen -sDEVICE=pdfwrite '-sOutputFile=output.pdf' -dColorImageResolution=120 -dGrayImageResolution=120 -c .setpdfwrite '/AutoFilterGrayImages false /GrayImageFilter /DCTEncode /GrayImageDict << /QFactor 0.9 /Blend 1 /HSamples [2 1 1 2] /VSamples [2 1 1 2] >> /ColorImageFilter /DCTEncode /ColorImageDict << /QFactor 0.9 /Blend 1 /HSamples [2 1 1 2] /VSamples [2 1 1 2] >> /MonoImageFilte | 20:27.33 |
| | so. this was my latest experiment | 20:27.41 |
| | unfortunately gs is segfaulting on large files again :-/ | 20:27.53 |
| mvrhel_laptop | open a bug | 20:28.02 |
| | but I would suggest simplifying things as best you can first | 20:28.44 |
| | rayjj: I copied my PLRM.pdf file to my home directory on caspar | 20:29.23 |
| | I recall Robin and I getting the same results when i was testing mupdf | 20:33.40 |
| nemo | hm. looks similar to the other one | 20:40.04 |
| | mvrhel_laptop: yeah. that's gonna be difficult since you'll probably want to reproduce and I doubt they'll allow me to post the PDF :( | 20:40.26 |
| | ah. no crashing in a different area from the other time | 20:40.42 |
| | other time was solved by specifying the filter, was crashing in select | 20:40.54 |
| | this one is crashing in close | 20:40.57 |
| | also taking a lot longer to crash | 20:41.03 |
| | sclose s_close_filters psdf_end_binary pdf_end_image_binary | 20:41.21 |
| mvrhel_laptop | the pdf file can me marked as private | 20:41.28 |
| | so that only artifex employees will see it | 20:41.35 |
| nemo | mvrhel_laptop: there's still no way they'd let you have it | 20:41.39 |
| mvrhel_laptop | s/me/be/ | 20:41.42 |
| nemo | sighs and grabs latest gs source | 20:41.53 |
| robin_watts_mac | Right. Time to explore Easter Island. Back later. | 20:48.12 |
| mvrhel_laptop | bbiaw | 21:04.12 |
| nemo | hm | 22:23.56 |
| | gs built from source is not segfaulting | 22:24.02 |
| | sooo guess you guys fixed it or something | 22:24.07 |
| | should check the segfault I got earlier I suppose | 22:24.23 |
| rayjj | nemo: sometimes we fix things :-) | 23:23.06 |
| | nemo: segfaults are fairly high priority, even from free users | 23:23.30 |
| robin_watts_mac | "Please give us the latest MuPDF". First, find your ass. You may use both hands. | 23:45.26 |
| rayjj | robin_watts_mac: the upgrade _is_ proving to be worthwhile. I'll send mvrhel updated charts in case he wants to change his slides | 23:46.45 |
| robin_watts_mac | oh, cool. | 23:47.04 |
| rayjj | once this finishes I'm going to guess at which gs mvrhel was using and see if I can get to his PLRM number | 23:47.43 |
| | Forward 1 day (to 2014/08/08)>>> | |
IRC Logs